Object Orientation failed because it's too hard to understand? I blinked in incredulity. Object Orientation hasn't failed, but we're coming to appreciate its short comings as a sole design paradigm. For C programmers, C++ gave them access to variable execution via polymorphism (without ugly function pointers) and more flexible scoping via classes. In languages that provide first class and anonymous functions polymorphism is a lot less useful and closures provide better scoping flexibility than classes. Languages that have these features make it obvious how restrictive C++ is in binding this functionality in with the type system. In languages like ruby, python, javascript, lisp and smalltalk object orientation serves in its proper place as a type definition system and people use it appropriately. It's only C++ that has failed us.
"closures provide better scoping flexibility than classes. Languages that have these features make it obvious how restrictive C++ is in binding this functionality in with the type system."
C++ can/does do anonymous functions (for example, see boost lambda), and can even give you most of what you want from first-class functions and closures (using functors). The parts that you don't get are due mostly to the fact that C++ doesn't have built-in garbage collection. It's a speed limitation, not a type-safety limitation.
Now for my rant: there seems to be a backlash against type safety in this forum that I don't understand. Granted, if all you ever do is develop dinky webapps with your best friends, permissive languages allow for rapid development (mostly because they let you get away with murder). However, once you have more than a few developers and a few tens of thousand lines of code, the benefits of strict typing become rapidly apparent. The chaotic, free-for-all mentality of languages like Ruby is great for rapid prototyping, but it kinda sucks for developing in more formal scenarios.
It may be "harder" to develop with strongly typed languages, but that's usually an indication that you're having to think a bit before you act. That's rarely a bad thing!
"there seems to be a backlash against type safety in this forum"
You've said what I've been thinking for many months now.
We've also got a strong contingent of anti-MS ranters.
As to the merits of the article -- there are none. Oddly enough, I can't make a case against his argument because he doesn't have one, save his ultimate realization that it was the language itself. "It came to me in a dream" is a very difficult thing to take issue with.
We've also got a strong contingent of anti-MS ranters.
I've been having to work in MFC recently for a client, and boy...
If you ever needed a reminder why some people dislike C++ so much, just work with MFC. It's one of the worst bastardizations of C++ I've ever seen (of course, to be fair, one has to admit that much of the really sucky stuff in MFC was done before the C++ standards were very good, and long before the compilers caught up).
Writing C++ using std:: and boost:: and other libraries written in "Modern C++" is pure bliss compared to doing it the "Microsoft Way".
I mean MS in terms of the entire corporation, ie, all that comes from MS is bad.
Last time I wrote in MFC was about five years ago. As I recall, I got up to speed by reading a couple books which went over basic application design stuff in Win32.
Didn't seem too bad to me -- I even did some COM stuff and some hooks and such. But like I said, that was a while ago. I wasn't a crazy fan or anything, but the tools did the work I wanted to do.
But see, that's the point - C++ is intended to be multi-paradigm, and MS made it one-dimensional. Stdlib and Boost both take advantage of multiple paradigms while the MFC is a framework prison whence there is no escape.
But it's not OOP's fault, and to the degree that Microsoft had to release something early (in order to support their Win32 framework) and keep supporting it -- it's not their fault either.
You can go with a lightweight (?!?!) framework around your API, a la MFC, or more of a true framework, like OWL. But in either case, comparing a what? 12-year old framework system with something more recent isn't exactly apples and apples.
I'm not trying to make excuses but heck, the whole reason we grow new frameworks is because old ones get too bloated and brittle.
Rock on with Boost, but don't compare apples and oranges. Maybe it's me, but professionals are supposed to know the hard-to-use crap and should be able to swim around in that stuff like a fish in water.
Hey -- just my two cents. No matter how you cut it, C++ is a killer language when it comes to complexity -- and that's without the freaking frameworks!
I suspect that a lot of the C++ bashing you see comes from A) Experience with Microsoft Tools; B) Experience with 90s era C++ code bases, often produced by teams "trained up" in it.
Modern C++ done "the boost way" is a great language. I have rewritten perl prototypes in modern C++ with hardly any code expansion, but with huge performance and deployability gains.
Boost::lambda is a poor substitute for an actual lambda. Every time I have attempted to use it in a non-trivial way, I gave up because writing a one-off function object was clearer and required less code. (Albiet spread out more.)
Your claim that you can achieve everything in C++ misses the point. Sure, I can write lots of function objects every time I want to apply a function to a data structure (and I do), but I also have to write a lot of tedious code to do it. That tedious code increases the size of my code base, which increases the likelihood of errors and its cognitive load. You can write object-oriented programs using ANSI C, but your code base is going to be much larger than if you did it in a language with actual OO support.
When a programming concept has first-class support in a language, programs that use that concept are going to be shorter, clearer, and less likely to have bugs related to that concept's implementation.
Luckily, true anonymous function support will be a part of C++0x.
"Your claim that you can achieve everything in C++ misses the point."
Well, no. I was responding to a comment that implied that it was impossible to do things like anonymous functions and closures in C++, due to the restrictions of the type system. That's wrong.
You'll get no argument from me that C++ is verbose.
Well templates do let you do just about everything being a meta-programming language - however libraries rarely use them and they are very complicated to implement yourself.
I've not found static typing to be a big productivity win. I think it disallows a small subset of bugs. Like most people I've been a C++ programmer because it was the highest performance language with the best support for operating and window systems. I'm gleefully looking forward to it playing a smaller and smaller part of my programming work.
These strong-typing/weak-typing debates are the programmer's equivalent of skirt-length trends. The strong type system of C++ was a direct reaction to the deficiencies of the cast-happy, C-style of coding that came before; now we're back to dynamic typing. Ten years from now, after this generation of college grads has been burned while using the latest silver bullet for real projects, we'll be back to something more static. And around we go...
Anyone who experienced the C->C++ transition can tell horror stories about problems due to the (ab)use of C's type system in real code...and C wasn't even that weak! Even Perl coders have learned this lesson the hard way (hence the introduction of "use strict"). But I digress.
Maybe you're right, and strong typing doesn't matter that much for the new generation of apps. My instinct however, is that the current hipness of dynamic typing is a (somewhat justified) over-reaction to the ugliness of C++. Meanwhile, a lot of babies are being thrown out with a little bit of bathwater....
I think better type inferencing may bring strong typing back in vogue.
I think what really makes programming in a "dynamic" language significantly more pleasant is not having to type (on the keyboard) type (int, Object, etc.) declarations. A strictly, statically typed language with a good type inferencing engine, like Scala or Haskell, makes a lot of this go away.
I understand (though don't have enough experience to verify) that there are times that the type inferencing occasionally makes things harder when you get a type error and can't identify its source. But certainly a win overall compared to explicit types everywhere.
Wasn't really my point, I just took the diversion to talk about static typing. If static typing comes back as the thing I think C++ will still be crap. I think the productivity gains in the language I mentioned have everything to do with built in list types, first class functions, closures and anonymous functions. Good libraries built on those things help a lot as well.
> have more than a few developers and a few tens of thousand lines of code, the benefits of strict typing become rapidly apparent.
The argument is that comprehensive test suites can substitute for strict typing. I don't buy it as practical, but that's the argument, and I can at least see the reasoning.
The other point is that you can avoid tens of thousands of lines of code and lots of developers in dynamic languages. You're way more likely to keep the thing in a form where two or three guys have it all in their heads and can keep it small and well factored. Strict typing is critical when you're making changes to code you don't understand really well. But you're more likely to understand all the code really well when it's small and you're on a small team.
"Object Orientation failed because it's too hard to understand? I blinked in incredulity"
With great respect, I suggest: If you know what a closure is, you may have trouble understanding how OO is difficult to understand for many other people. The kind of people who have never heard of a closure, and whose eyes glaze over as you try to explain that a closure is an inside-out object and an objct is an inside-out closure.
The fact that the guy thinks OOP is the pinnacle of the dark art of programming doesn't bode well for his credibility on the topic of designing programming paradigms.
I can't even fathom what would be difficult to understand about OOP, unless, like I suspect, he is forcing the Kingdom of Nouns onto a problem that isn't well suited for it.
Or, we are failing ourselves, but otherwise you are completely right. There is nothing in the article explaining why author thinks that "Object Oriented Programming has Failed Us".
Anyway, this is a good way to trick Hacker News:
1. Write curious title with some programming term in it.
2. Write some random thoughts in the article body mentioning the term.
3. Submit to HN
4. Traffic!
I cringed at the comparison to mathematical proofs and the "multidimensional" aspects of programming (whatever that means), but the thesis was good, and I'm interested in how the HN community can expound on it... hence, the upvote.
How is the thesis good? The thesis states: average developers are too dumb to grok object-oriented programming so that some alternative simpler method for data hiding and encapsulation needs to be adopted. Only the really smart people should be allowed to dabble in the dark arts of OOP, and only then if they've been properly mentored by an elite priesthood.
Programming is hard. Let's go shopping. The article comes near, but does not directly address the fact that OOP is just one of several techniques and language features that have, over the years promised to make programming easy. People either fail to understand and properly adopt the new techniques or they do adopt the new techniques and simply find something else that makes programming hard.
The best we can hope for is that a technique expands what is within the reach of the average programmer. The problem of the day gets moved to the solved category and we move on to bigger and better things, which are also hard. Those of us who enjoy programming and earn a living from it should hope that this cycle is not broken.
I really hate to say this, as much as I like object
oriented programming but, I really think we might be better
off if we went back to procedural programming for the bulk
of the applications that we write and left the object
oriented stuff to people who really understand it and for
problems that can not be solved any other way.
Meanwhile, back at the lab, we need to come up with a
programming environment that most people understand
naturally. We need to do usability studies on the
languages we develop just like we test applications we
develop for users. Instead of trying to simplify what we
are already doing, which continues to provide solutions
that only programmers understand, we need to provide
solutions that are no longer programmer centric.
It seems to be natural to do GUI-centric programming as in Visual Basic. People like attaching ideas to things that they can see. I think that the real problem is that there is an Impedance Mismatch between current GUIs and the domain. Once we have solved this, then the natural way to program won't conflict so drastically with good Object Oriented practices.
I'm not sure if we can get there before we reach the level of GUIs in Minority Report, but I think we won't need quite all of that.
Meanwhile, back at the lab, we need to come up with a programming environment that most people understand naturally. We need to do usability studies on the languages we develop just like we test applications we develop for users.
Isn't that how Vista was designed? Wouldn't it be a better idea to have a really curious and imaginative person (an artist, if you will) work on the language that will last 100 years?
On the other hand, I think this article borders on a good criticism of Arc: could it be that PG's focus on writing a language is misguided? Maybe it would be a better idea to focus on something more abstract: in particular, on inventing better fundamental representations for our programs (as Alan Kay did, when he thought about OOP)? I'd imagine Paul's response would be that macros -the "blurring of the line" between interpreter and interpreted- is the mind-opening change in representation. Does the problem lie in helping people cross this line?
It's also how Mac OS X, Windows XP, Windows 95, and most of their precursors were designed. There's just been an acceptance amongst OS designers that testing with real humans is the only way to know if things are actually easy.
Programming languages are unique, however, in that the people building them are often also the users (and the more this is true, the better the language tends to be). C was designed to build UNIX, while ADA was designed for a customer...and we know which one survived.
But, I also simply can't buy the "people understand naturally" logic. People understand very little "naturally"...and even if you include pre-existing knowledge (like English, or spatial skills) in this "natural" knowledge you still end up with a pretty horrendous and limited programming language. Explaining an algorithm in English almost always takes a lot more "code" than writing it in a decent high level language.
testing with real humans is the only way to know if things are actually easy
Yes, yes, of course, sorry for being unclear - I just meant that we shouldn't rely on design-by-focus-groups or design-by-committee exclusively, that imaginative solutions require creativity, and for that you need someone with taste.
People understand very little "naturally"...
Well, OOP utilizes our spacial skills, at least in the form of all those pretty UML graphs? There is certainly a lot of thinking left to do about how exactly we understand programming languages, both on macro and micro levels - what metaphors we use to understand scope, objects, functional concepts, etc. It's from this thinking that new language designs will arise.
CRC cards on 3x5" card-stock are better than UML. Otherwise, I agree. Until GUIs for applications are as natural as passing 3x5 cards around, there's going to be an impedance mismatch between the GUI and the domain.
Ada has a pretty impressive record in safety critical systems; something that cannot be said of C. Aircraft software systems and many air traffic control systems in particular are all written in Ada.
And yet, somehow, I've never seen a single line of live ADA code...and there are literally hundreds of millions of lines of C code doing work right now. Not only that, someone is almost certainly starting a new program written in C right now...and now...and now...and now. And...you, guessed it, now.
I'm sure Ada had a useful life, possibly even in a niche where C would never be an effective tool. I was just saying that design-by-committee, even with a lot of user input, is probably not the right way to build a timeless programming language, and that building a language while using the language probably is.
Ada never caught on as a general purpose programming language, but a subset of it lives on in PL/SQL, the embedded language in Oracle. It's not the most flexible or elegant language, but it's easy enough to learn and extremely reliable. It's all about choosing the right tool for the job. Sure you can run C in-process with your database, but unless you really, really have to it's a bit pointless to risk i.
I find it very hard to agree with thesis when there is absolutely no backing information about how OO programming is "hard". What are the difficulties people are having with OO? How can I take this article seriously when it's nothing more than a statement followed by some fluff followed by a few half-thought suggestions. Who are these 'people these people who 'really understand' OO programming?
Am I one of them?
Are you?
How are we to know with no example of HOW OO is hard? What exactly is so hard about it? Class Apple extends Fruit. apple = new Apple(). apple.eat(). Makes sense to me. How are people using it wrong? Is the real issue that people don't understand when to use it?
Here's a similar article:
Playing poker is hard. A lot of people really don't understand how to play poker. People that play poker should stop, and start playing go fish. They should leave poker to the professionals that understand poker. All poker books should now become go fish books.
I don't think this article is particularly well-written. However, I do agree with the conclusion. For web-based programming, object oriented programming is simply ridiculous in all but a small number of cases. That's why the Lampshade framework I wrote is purely procedural, and why I'm able to write software on top of it so quickly. Client-side GUI programming is a different story, in my opinion.
In general, just because you're capable of understanding complex, abstract concepts doesn't mean that it's always best to use them.
For web-based programming, object oriented programming is simply ridiculous in all but a small number of cases.
Agreed. Functional programming seems to make a lot more sense. Fundamentally, isn't a web server just a function f: url -> html? Sure, databases and sessions complicate things, but even in these cases, functional structures seem a lot more elegant (in a mathematical sense) than OOP ones.
For any programming, OOP brings some advantages. What you might be decrying is over-the-top abuse of OOP patterns. Certainly, for most programming, abuse of design patterns is unwarranted.
However, taking, as an example, Ruby, which is both a functional and OOP language, the OOP features make the language a lot nicer.
Anyway, that article is completely daft. And I refuse to take any advice about programming from someone who spells "linear" as "linier". Shame there's no down-mod button.
> However, I do agree with the conclusion. For web-based programming, object oriented programming is simply ridiculous in all but a small number of cases.
I read his conclusion as that object oriented programming has failed us because it is too hard to understand, and we need a new, simpler, more accessible, dumbed-down programming paradigm. He is advocating programming for non-programmers, which has been tried many times before and has always met the worst kind of failure (universal disdain by "real" programmers).
I would say we've had it for a while now. Ever seen the things that people on a trading desk do with Excel? Or maybe VB, when they get daring.
Generally something that gets the job done that they want it do.
However, it is not going to be very extensible, no one besides the person who wrote it will be able to understand it (and maybe not even him), they will have no idea what to do if they want it to go faster, or if they need to make it work on the web, or integrate some data feed that doesn't have any easy way to import into Excel, or...
In summary, we have programming for non-programmers, it works as well as can be expected, but sometimes you really, really need a programmer.
"...and left the object oriented stuff to people who really understand it and for problems that can not be solved any other way."
And an example of such a problem would be...?
The single biggest problem with "language war" threads like this is that people actually believe this is the "only way". "Better way"? Maybe. "Only way"? Hardly.
Anything you can do in your language (object oriented or not), I can do in mine. Maybe not as slick, but it can be done.
