Who's old enough to remember the "crisis" around Object Oriented? There was a time when the majority of mainstream programmers didn't really know what Object Oriented was, there was a lot of marketing noise confusing the situation, and skeptics declared it all to be snake oil.
I think Objects won in the end, though. Or is it still common for someone to write a big heap of procedural code, use polymorphism once, then call the whole thing, "Object Oriented?"
It seems that the inventor of object-oriented programming was one of those skeptics. Alan Kay apologized for his poor choice of words, for the resulting confusion, and for the widespread misapplication of his ideas.
Unfortunately, many of today's common practices sound a lot like his description of how the term object-oriented is often misapplied. Most programmers that I have met still misunderstand object-oriented programming, and use it as an excuse for complicated or bloated code.
Objects won the popularity battle, to be sure. I think the jury is still out on whether OO is inherently a better form of programming in any other sense than approaches that are not built around objects.
There's plenty of anecdotal evidence to suggest either way, but unfortunately true comparative research based on significant real world projects is always going to be hard to find. Most of us don't write industrial-scale code twice, and even if we did, we couldn't do it with the same team and starting from the same knowledge base in both cases.
I do find it interesting that as other non-trivial abstraction tools have become more widespread, the emphasis on using objects as the tool for every job seems to have diminished substantially, though. When all you've got is objects or plain old procedural code in otherwise much the same context, objects are a potentially useful extra tool in the box. On the other hand, now that we have everything from convenient array/dictionary types in many modern dynamically-typed languages to awesomely powerful and expressive type systems in various functional languages, things are becoming much more interesting again.
I wonder if functional programming can escape the traps Object Oriented programming fell into? For one thing, the barriers to entry are seemingly higher. How much half-baked functional programming is out there?
Most of us don't write industrial-scale code twice, and even if we did, we couldn't do it with the same team and starting from the same knowledge base in both cases.
Big companies are pretty short-sighted. Above a certain size threshold, companies should implement much of their critical user-facing software at least twice. Basically, they should be engaging in A/B testing. Why? Isn't this wasteful? I don't think so. From my experience, both inside companies and as a customer, software can have an impact on employee effectiveness well beyond a factor of two. There is always room for improvement. The best way to discover places to improve is through experimentation. Not doing this, is to leave these potential improvements on the table.
Perhaps a level of granularity below that of an entire application would be better.
> I wonder if functional programming can escape the traps Object Oriented programming fell into?
I'm not sure I would agree that OO has "fallen into a trap". I think OO, whether the Kay version or the C++/Java/whatever version, takes a certain approach: essentially, that one entity in any operation is considered "special". This approach can work nicely in some applications, such as a lot of GUI design work, but doesn't fit into all contexts as neatly.
That means sometimes building your design in an OO fashion is helpful, and sometimes it gets in the way. The interesting question is whether, for any given project, the benefits of the helpful side outweigh the hassle of working around the structure when it isn't helpful.
I think in the early days of OO, a lot of people assumed without evidence that the balance was usually on OO's side. Today, as other approaches with other abstraction tools are more widely known and once trendy ideas like Singletons have had their practical weaknesses revealed through experience, many of us wouldn't take the same bet.
I don't know what to think of Singleton being a trendy idea. Then again, I guess screwdrivers were a trendy idea once. (The hardware thing, not the drink, though it applies there as well.)
> I don't know what to think of Singleton being a trendy idea.
I suppose, like Agile processes and OO, Design Patterns introduced some ideas with real merit, but some people got way too hung up on the less meritorious ideas that came along for the ride.
I think Objects won in the end, though. Or is it still common for someone to write a big heap of procedural code, use polymorphism once, then call the whole thing, "Object Oriented?"