6 ms·

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 sh

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.

timr 18y ago
"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!
- greendestiny 18y ago
  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.
  - timr 18y ago
    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....
    - greendestiny 18y ago
      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.
    - jimbokun 18y ago
      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.
- DanielBMarkham 18y ago
  "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.
  - aggieben 18y ago
    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".
    - kingkongrevenge 18y ago
      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.
    - DanielBMarkham 18y ago
      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.
- kingkongrevenge 18y ago
  > 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.
- scott_s 18y ago
  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.
  - timr 18y ago
    "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.
raganwald 18y ago
"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.
Xichekolas 18y ago
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.

timr 18y ago

"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!

greendestiny 18y ago
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.
- timr 18y ago
  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....
  - greendestiny 18y ago
    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.
  - jimbokun 18y ago
    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.
DanielBMarkham 18y ago
"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.
- aggieben 18y ago
  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".
  - kingkongrevenge 18y ago
    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.
  - DanielBMarkham 18y ago
    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.
kingkongrevenge 18y ago
> 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.
scott_s 18y ago
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.
- timr 18y ago
  "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.

raganwald 18y ago

"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.

Xichekolas 18y ago

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.