Related
I was reading the transcription of Steve Yegge's Dynamic Languages Strike Back presentation, when I noticed this comment when he begins to discuss trace trees:
I'll be honest with you, I actually have two optimizations that couldn't go into this talk that are even cooler than this because they haven't published yet. And I didn't want to let the cat out of the bag before they published. So this is actually just the tip of the iceberg.
What are the optimizations he was referring to?
Update
Several days ago, I asked this question in a comment on the article. However, comment moderation is turned on (for good reasons), so it hasn't appeared yet.
Update
It has been a couple weeks since I first tried to reach the author. Does anyone else know another way to contact him?
Take a look at this: https://blog.stackoverflow.com/2009/04/podcast-50/
EDIT: Difficult to find specific (confirmed) references however, this paper perhaps gives some information regarding this: http://people.mozilla.org/~dmandelin/tracemonkey-pldi-09.pdf
and this blog post which appears related: http://andreasgal.wordpress.com/2008/08/22/tracing-the-web/
Might not be related as it is a Microsoft research paper from March 2010: http://research.microsoft.com/pubs/121449/techreport2.pdf
Pure speculative on my part but it appears (at least to me) that there are two major forms of performance, that at the developer level (IDE) and that at the compiler level which this subject of trace trees addresses hence the "continuous optomization" during execution to get the trace inline for the hot spots. This then leads me quickly to areas of optomization related to multi-cores and how to utilize the trace tree somehow in that regard (multi-core environments). Interesting stuff considering the currently theoretical non-static type speed speculation as compared to the speed winners in static type utilized in current C and the performance potential to be gained. I recall a discussion I had with a hardware engineer years ago (1979) where we speculated that if we could just capture the 'hot' execution paths we could get a huge gain in performance by keeping it "ready to run" in situ somehow - this was way prior to the work at HP in this regard (1999?) and unfortunatly we did not get further than the discussion stage due to other commitments. (I am rambling here I think...:)
OR, was this just related to the GO language? hard to tell in some respects.
You can watch that video from youtube under the StanfordUniversity channel: http://www.youtube.com/watch?v=tz-Bb-D6teE
You can add comments there too. Maybe someone will come to your rescue.
For most programming tasks, you've got quite the selection of languages to choose from, and good strong communities behind plenty of them. But when you need to work with a database, there's really only one viable choice these days: SQL. Sure, there are different companies with different implementations and dialects, but you're still looking things up with
SELECT columns
FROM table
JOIN other_table ON criteria
WHERE other_criteria
It wasn't always this way, though. As late as the early 90s, there was no single obvious way to interact with a database. But today, there is. And with the way computer languages tend to proliferate rather than converge, I find that a bit odd. What historical and technical factors led to SQL's almost complete dominance of the database access domain?
It's like this Winston Churchill quote:
Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.
There were alternative database technologies before 1970 when the relational model was first proposed. There have been alternatives the whole time since then, and there are new alternatives today.
But of all the alternatives, no solution besides SQL provides as good a balance for:
Widespread standardization
Popular and long-lived products such as Oracle
Plays nicely with many application programming languages
Support for formal data modeling, strong data integrity, ACID transactions
Here's a reference from the Codd Wikipedia article - some detail on how SQL 'won out'.
Committee on Innovations in Computing and Communications: Lessons from History: The Rise of Relational Databases.
Edgar F Codd started the madness.
Enjoy!
Codd and Churchill aside, SQL isn't a horribly bad language for defining and querying table-based datasets. As another general said, "It got there the firstest with the mostest."
One factor is that data persists. It is a lot harder to replace/migrate a company's data than its applications. Applications can come and go, coded in the latest 'flavor of the month' language, but the database platform lives on. This is a bit like a QWERTY effect. While the QWERTY keyboard layout is known to be inefficient, it persists because there would a massive cost in switching to anything else.
Secondly, there is massive market domination by Oracle and IBM (and more recently Microsoft). While they might not agree on every detail, neither has seen a benefit to a non-SQL interface to their databases. I used Ingres back in the early 90s when its QUEL was being pushed out by SQL.
Thirdly, there's a benefit to the application developers (especially the likes of SAP and Oracle) to have a standard(ish) platform to sit on.
I suppose the flip side to this question is why do we need/want so many different programming languages.
I've been searching the web for some time now. I am looking for small sample exercises for OOD practice (& for some internal TDD workshops).
If there is one single place, where this need is being served, please point me to it.. and close this question
Constraints:
Language-agnostic real world problem
Small : Something that takes an hour to two at max to solve (or has sub-parts that can fit this constraint).
Not Algorithm centred : Not be focussed on just solving a computational task. (There are multiple sites that serve this category.) Involve > 2 interacting entities.
Solved by multiple people, preferably yourself : Goodness verified. Links preferred. Please do not post something that may be a good exercise... subjective
Similar SO question 60109, but the answers dont meet my need here. I found that I've lost my touch (was thrashing ideas) with OOD after prolonged exposure to a day-job. Need to get it back..
Update: Are we collectively out of short OOP exercises ? I was hoping that I'd have a bunch to pick from. However my web-searches (this is a diff exercise in formulating the right search string) and the lack of responses here seem to indicate otherwise. Maybe I posted to SO at a bad time.. in which case bumping this thread for more responses.
http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
http://schuchert.wikispaces.com/Monopoly%28r%29
Jeff Bay's Object Calisthenics. Following these will improve your OO skills.
Bill Wake's spreadsheet TDD challenge
Dave Thomas' CodeKata
Kindness,
Dan
From the AGPPnP book by Robert Martin aka UncleBob
CoffeeMaker Mark IV - Page 2 has the problem statement
Questionnaire Practice Problem
A problem I've worked on in a couple of different jobs is that of writing some generic, data-driven survey/questionnaire functionality. It's not majorly complex, but has enough interesting avenues to be a good OOD practice problem I think. It's definitely real-world and crops up in a lot of places.
You can start off thinking about how to structure a Survey. It is obviously made up of Questions, but do you also want Categories? Can a Question have subquestions? Can a subquestion have subquestions? How deep can you go?
A question probably needs to have potential Scores. What types of scores can you have? What types of questions can you have (multiple choice, multiple answer, freetext, etc.)?
Once you've got the basic business logic, you can also think about how you display a survey . Maybe you have a SurveyRenderer and a QuestionRenderer? How do you decide how to render different types of questions? (Maybe you use a Strategy pattern... as in this SO question.) How do you render a read-only version of the survey?
You can also think about persistence. How do you record responses to a blank questionnaire? How does your object graph of a survey get mapped into a database (or some other backing store), and vice versa?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How do I explain loose coupling and information hiding to a new programmer? I have a programmer who I write designs for, but who can't seem to grasp the concepts of loose coupling and information hiding.
I write designs with everything nicely broken down into classes by function (data access is separate, a class for requests, a controller, about 5 classes total). They come back with a modified design where half the classes inherit from the other half (and there is no "is-a" relationship), and many public variables.
How can I get across the idea that keeping things separate makes it easier to maintain?
Ask him if it's a good idea to let you borrow $10 by giving his wallet to you for a moment and taking the money yourself.
The problem is your expectations, not the developers lack of skill. You talk about loose coupling and information hiding as if these are simple facts or mechanical techniques - they are not. Software development is a craft and the only way to get better at a craft is to practice it and slowly and incrementally improve.
You are looking for a shortcut. You want the developer to experience an "ahah!" moment and suddenly see the wisdom in your design. I say, don't hold your breath.
Adopt the mindset of a mentor. If you want him to improve his design skills, don't "hand" him a design, let him to design it! Then review the design with him. This will give him experience, a deeper sense of ownership and more willingness to listen to your suggestions before he is knee deep in implementation.
An aside - I notice that people look for these shortcuts all the time with abstract skills but not with more "physical" skills. Take tennis for example. If you were a tennis coach and a new player kept hitting his forehands long, you wouldn't just show him a YouTube video of a Roger Federer forehand and expect him to "get it". A great forehand takes YEARS of experience as you learn the feeling and use it in different scenarios - its not your muscles learning, its your brain. It is no different with software design. You get good at it by doing it over and over again. You slowly learn from your mistakes and get better at appreciating the consequences of each individual design decision.
The best way to explain these kinds of concepts is to use analogies. Pick something non-programming related and use that to explain the abstract design concepts.
The following image is pretty good at explaining the need for loose coupling:
Try to come up with stuff like this that will amuse and pertain to your new programmer.
Theory will only get you so far.
Make him try to add new features to code he's written a while ago. Then rework the old code with him so it's loosely coupled and ask him to add the same features.
He will certainly understand the avantages of writing good code.
There's nothing like a physical analogy. Walk out to your car and point out how everything complicated, hot and dangerous is pretty well isolated from the fragile human. Sit in the driver's seat and point out some of the important gauges; for example, the coolant temperature, tachometer and speedometer. Note how the gauges are remarkably similar: they all take a scalar value (from somewhere) and represent it by moving a needle to a position between min and max.
However, if you think about what's being measured, the strong motivation to maintain that isolation (aka loose coupling or information hiding) becomes a lot more obvious.
"How would you like to measure the coolant temperature? By looking at a gauge or by sticking your finger into near-boiling liquid?"
"How would you like to measure the engine rotational speed? By looking at a gauge or by letting a multi-thousand RPM crankshaft rip the flesh from your bones as you try to estimate it by hand?"
"How would you like to measure the car's speed? By looking at a gauge or by dragging your foot on the ground as you're roaring down the highway?"
From there, you can build on the concepts of "your coolant temperature gauge is-a gauge. It isn't-a boiling liquid" and so forth to more complicated concepts.
Loose coupling: The parts of a watch may be replaced by others with out breaking the whole watch. For instance you can remove one hand and it will still work.
Information hiding: The clock hands doesn't know that behind them there's a machinery.
Additional concept
High cohesion: All the elements in the watch "module" are strongly related. In this specific scenario, a battery would belong to another module or namespace.
Show him this presentation. Though it's mainly about DI, it's downright brilliant and up to the point.
I would try sitting down with him and working through a couple of peieces of code with him looking over your sholder and you explaining why you are doing what you are doing as you go along. I've found this is normally the best way to explain things.
Ask him to make a change you know it will be hard because of his design and show him how that would happen using yours.
If he complains, tell him the truth: business will ask more bizarre changes, it's a matter of time he will see that.
Just don't talk to him. That should teach him about information hiding. ;-)
I like a credit card for an example.
You have a credit card.
A credit card represents your credit history. It has a balance and a APR. It has permissions and an entire financial state. It has a id, an expiration date, and a security code. The magnetic strip summarizes all of this.
When you go to your local credit-card-accepting establishment, they don't need to know that. They don't want to know that, and it is often very dangerous if they do know that. What they need to "know" is that there is a magnetic strip which will take care of all of this, and (sometimes) that the person holding the card has id to match the name printed on the card.
Giving them more information is either (in the best case) useless, or (in the worst case) dangerous. Requiring them to know which bank to check with, making sure they know how to calculate your particular APR, or allowing them to check your balance is simply silly at that point.
If he's misinterpreting your designs, perhaps a couple pair-programming sessions will be enough to get them on track. I do have to agree with #ThomasD and will expand upon it -- the encapsulation going on here could be you. It could be a simple case of misinterpretation instead of them not understanding the concepts.
I think that OO concepts really need to be learnt practically. One really needs to do these things to understand. I go to school (engineering) and most of my peers don't really get the concept. They know in general that loose coupling is 'good' but not why. They also don't know how to achieve loose coupling. I am working on my final year project now and I got through to them by making them part of the design process. (It helped that they really did understand how and why and had an inkling of its importance)
Given your situation, here is what I would suggest:
1. Make them follow your design exactly (at least for a couple of weeks). If they want to deviate, have them discuss what and why with you. [Time constraints may not permit this].
2. Sit with them on whichever part of the design you are doing next and explain some o0f your design choices to them, with examples. Somethings that are obvious to you may need to be pointed out to them.
3. Be on the lookout for examples, both of good design and bad design and show them how that works better.
The most important task here is of delegation. You have to show them what good code looks like, maybe train them for a couple of hours. Then you agree on when to review and how you can help them (whithin your limited free time (?)) do the task well. The main thing is to get them to identify with and understand good design. Doing these things will help them 'buy-in' to the design. Once they feel it is their design, I am sure they will do better work.
Overall, I think you need to put your foot down and get them to code it right, without stifling their creativity.
I don't really have too much experience in the area. I am just giving my opinion on the subject, based on what worked for me. I hope this helps.
Note
I'd like to add that OO concepts can be learnt from books, while their application can be learnt only by practice. I have added this note in response to a comment by Christopher W. Allen-Poole.
Well if you have to explain it to them then I'm forced to ask: are they really a programmer?
Tell them they need a "college do over"?
That's a hard one because it's such a basic concept. Personally I wouldn't want to handle it because it's like someone is getting paid to learn stuff they should already know but life isn't always ideal.
I'd approach it by finding a problem that's simple enough to solved relatively simple. Public variables are usually handled best by trying to find the source of a problem when you can't see what's changin gthe variables. You can design a scenario for that.
The over-inheritance may not be their fault. They may have learnt in a course designed in the 90s that's trapped in the idea that "everything must inherit". I remember the old examples of Manager extends Employee. It's just BAD. Thing is people get taught this nonsense. Still.
For C++ the Scott Meyer Effective C++ series is probably worth poniting them to (assuming they can be bothered to read something). For Java, Josh Bloch's Effective Java ("favor composition") is along the same lines. Not sure about C#.
These sorts of books give a better approach to inheritance vs composition and also give some good examples of why inheritance is (as Josh Bloch puts it) an "implementation detail". I've also heard it described as "inheritance breaks encapsulation".
I saw a good example once of inheritance vs composition with extending the capabilities of a List in Java and how inheritance required you to know implementation details of the parent to do correct whereas composition didn't. I'll see if I can find it.
If you do Unit Testing, explain it in terms of test-writing. Alternatively, Abstract Classes and Interfaces both use loose coupling and information hiding to great effect. If you explain it to him in terms of other concepts he may already have a handle on, he'll be more likely to appreciate the concept quickly.
Programs are systems of interacting parts.
For a system of interacting parts to work together requires connections between these parts.
The more connections, the more costly the program.
For a fixed number of parts, a system whose parts are unnecessarily connected is more costly than a system whose parts are necessarily connected.
Unneccessary connections can only be formed in a system whose parts are unnecessarily exposed to connections from other parts.
Minimising unneccessary exposure of parts to connection from other parts is fundamental to cost-effective program development.
Loose coupling and information hiding are the fundamentals of connection-exposure minimisation.
This is not optional knowledge for a programmer.
This is fundamental.
You cannot be a cost-conscious programmer without this knowledge.
Asking how to explain loose coupling and information hiding to a new programmer is like asking how to explain surgery to a new surgeon? Or to explain architecture to a new architect? Or how to explain flying to a pilot.
If your, 'New programmers,' don't know loose coupling and information hiding, then they are not, 'New programmers;' they are potential programmers.
Curiously, it probably won't help to tell them to read the original two papers:
i)Loose coupling: 'Structured design,' by W.P. Stevens, G.J. Myers and L.L. Constantine.
ii)Information hiding: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
Just like the move from 16 bit to 32 bit windows applications where processes were given their own address space. This stopped any other process from being able to kill your application when it "accidently" walked over your data.
Moving processes to different address spaces was like treating each process as a class, and hiding the memory internally and decoupling the processes by forcing interprocess communication to only happen via an expected interface ( eg Windows Messages ).
loose coupling means the external code should use the object of derived non abstract class through abstract base class. if any change occur in set of class on which it depend then not neccessory to change in external code i.e. external code really exhibit loose coupling.
I've been studying OOP for quite a while now and I have a good grasp of the theory. I read the Head First book on OOP and, while it reinforced a lot of the theory, I found the case studies to be somewhat trivial.
I find that I'm applying OOP principles to my code each day, but I'm not sure if I'm applying them correctly. I need to get to the point where I am able to look at my code and know whether I'm using inheritance appropriately, whether my object is cohesive enough, etc.
Does anyone have any good recommendations (books, online guides, blogs, walk-throughs, etc.) for taking the next step in developing solid OOP skills?
I am working primarily in .NET (visual basic), but I welcome suggestions that incorporate various platforms.
Read Refactoring by Martin Fowler, and apply it to your own work.
It will take you through a litany of malodorous characteristics of software code that describe how to detect improperly constructed classes, and even more importantly, how to fix them.
Consider looking into Design Patterns. Although it seems like they aren't commonly used in enterprise applications (I've seen them more commonly used in API's and Frameworks than embedded into enterprise code), they could be applied to make software simpler or more robust in a lot of situations if only developers knew how to apply them.
The key is to understand the design patterns first, then with experience you'll learn how to apply them.
There is a Head First book on design patterns that teaches the concept pretty simply, although if you want a book that really covers design patterns in detail, check out the Gang of Four design patterns book, which is basically what made design patterns mainstream and is referred to almost every time the topic is brought up.
Design patterns can be applied in pretty much any object-oriented language to some degree or another, although some patterns can be overkill or over engineering in some cases.
EDIT:
I also want to add, you should check out the book Code Complete 2. It's a very influential book in the world of software development. It covers a lot of different concepts and theories. I learn something new every time I read it. It's such a good book that if I read it every 6 months to a year, I look at it from a different perspective that makes me a better programmer just by re-reading it. No matter how much you might think you know, this book will make you realize just how little you really know. It's really a great book. I can't stress how much you should own this book.
If you already have the basics, I believe only experience will get you further. You say you are not sure if you are applying the principles correctly, but there is no one correct way. Code you write today, you'll look at in 6 months time, and wonder why you wrote it that way, and probably know of a better, cleaner way of doing it. I also guarantee that after 10 years, you'll still be learning new techniques and tricks. Don't worry too much about it, it will come, just read as much as you can, and try and apply what you read in small chunks.
I am currently half-way through the following book:
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
I cannot recommend this book strongly enough in terms of learning a real-life, professional-grade, practical approach to drafting and applying a well-formed and iterative design strategy before diving into code.
I, too, read the "Head First" book and felt that I was much better off for having read it.
After having a few years of working-world experience, I now view the Craig Larman book that I am recommending to be a perfect "next step" for me.
About the Presence of "UML" in this Book Title:
Whether you have positive feelings or negative feelings about UML notation, please do not let that influence your decision to buy the book (ISBN 0131489062) in either direction.
The prominence of "UML" in the title is misleading. While the author does use and explain UML notation, these explanations are extremely well-woven into relevant design discussions, and at no time does this book read like a boring UML spec.
In fact, here is a quote taken directly from the book:
What's important is knowing how to think and design in objects, which is a very different and much more valuable skill than knowing UML notation. While drawing a diagram, we need to answer key questions: What are the responsibilities of the object? Who does it collaborate with? What design patterns should be applied? Far more important than knowing the difference between UML 1.4 and 2.0 !
This book at times seems like it is "speaking to" a lead architect or a project manager. What I mean to say by that is that it assumes that the reader has significant control over the planning and direction of a software project.
Nonetheless, even if you are only responsible for some very small piece of your company's projects and products, I would still recommend this book and encourage you to apply some "scaled down" modifications of the book's advice to your piece of the project.
My OOP epiphany came from Grady Booch's book, way long time ago. Suddenly I realized why objects were good.
While polymorphism is cool, encapsulation is 75% of why objects are cool. It is sort of like an interface: you see the buttons but not the wiring. Before objects, only the most disciplined coders kept their grubby fingers off the internal bits of other people's procedures (it was called "structured programming").
Object make it easy to Do the Right Thing. Inheritance and polymorphism are little bonuses.
One way to learn about objects is to read other peoples' code. I learned a lot by reading the source code for the Delphi VCL framework. Even just looking at the documentation for Java will help you see what a single object class should do and how it is designed to be used by other objects.
Start a project of your own and pay attention when you want to sub-class your own classes and find that you have to go back and break up some protected methods so you can override just one piece of a process instead of replacing all of it. See how ancestors talk to descendants by calling abstract functions. In other words, go make a lot of mistakes and learn from them.
Enjoy!
Frankly, re-reading old David Parnas papers on information hiding helps me get in the right state of mind. The case studies may not be directly applicable but you should be able to get some useful generalizations out of them.
My epiphany happened when I tried to implement a very OO problem (dynamically and recursively building SQL statements) in VB6. The best way to understand polymorphism or inheritance is to need it and not be able to use it.
One thing that will definitely help you is working on a well-known, respected open source project. Either dig through the source code and see how things are done or try to make some additions / modifications. You'll find that there isn't one style or one right answer for most problems, but by looking at several projects, you'll be able to get a wide view of how things can be done. From there, you'll begin to develop your own style and will hopefully make some contributions to open source in the process.
I think you have to attempt and fail at implementing OO solutions. That's how I did it anyway. What I mean by fail is that you end up writing smelly code while successfully delivering a working solution. After it's written you'll get a feel for where things didn't quite feel right. You may have some epiphanies, and/or you may go and hunt for a slicker solution from other programmers. Undoubtedly you'll implement some variation of standard design patterns by accident. In hindsight, a light will click on (oh! so that's what a visitor is for), and then understanding will accelerate.
As others have said, I think tooling through some good OO open source code is a good idea. So is working with more experienced programmers who would be willing to critique your work. However understanding comes through doing.
You might want to try to read (and write) some Smalltalk for a while. Squeak is a free implementation that can show you the power of a fully object-oriented environment (unlike java or .net). All library code source is included. The language itself is incredibly simple. You'll find that java and c# are slowly adding the features well-known to Smalltalk since 1980.
Tortoise HG is extrodanarily well designed piece of OO open source software (written in Python).
If you already understand the basics, building something from scratch in a fully object oriented language will be a good step in fully understanding OOP software architecture. If you don't know Python, Python Essential Reference will take you through the language in full in a few days to a week.
After you understand the language take a look through the software above and you'll have all sorts of epiphanies.
To understand basically anything thoroughly, you need to have a decent knowledge of at least one abstraction level above and one level below it. In the case of OO, others have mentioned design patterns as the layer above OO. This helps a lot to illustrate why OO is useful.
As far as the layer below OO, try to play around with higher-order functions/late binding for a while and get a feel for how these relatively simple constructs are used. Also, try to understand how OO is implemented under the hood (vtables, etc.) and how it can be done in pure C. Once you grok the value of using higher order functions and late binding, you'll quickly realize that OO is just a convenient syntax for passing around a set of related functions and the data they operate on.