Object Oriented Programming has Failed Us
blog.dmbcllc.com
blog.dmbcllc.com
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!
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.
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 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.
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.
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".
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.
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.
Talk about a black hole of tool-chain hell...
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!
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.
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.
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.
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.
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.
This link is currently in the #2 position on the front page. I wonder if the people who up voted it actually read it or just agreed with the thesis?
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.
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 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.
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.
*grammar
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?
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.
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.
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.
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.
In general, just because you're capable of understanding complex, abstract concepts doesn't mean that it's always best to use them.
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.
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.
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).
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 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.