6 ms·

"For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words

"For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names. How does that discredit or put into question the "mental model of command and control, or structured design concepts" If anything I feel the failure of OO languages is that they have been afraid of baking in proven design patterns/principles that reoccur over and over (ie. Gang of Four and a few more since then). Yesterday i was staring at some undocumented OpenCV code trying to figure out why there was some pointer that kept showing up in random places. After a very confusing 30 minutes i figured out it was actually the pImpl idiom. Now why do we have to have to reimplement the pImpl idiom each time? why can't this be a keyword?. The amount of code bloat and confusion that a visitor introduces is the prime reason I never use them. (There was an interesting proposal at CppCon 2 years ago that addressed this, but as far as I know it's not gone anywhere) The problem is that the most OO language trace back to C　which　IS a half-assed language from the perspective of "concurrency, state, and hell even the basics such as cyclic loops within a event based system" and most languages that do OO have been half baked on top of that foundation.

pjmlp 10y ago
I can think of a good list of OO languages that don't have anything to do with C. Also the pImpl is a consequence of C++ not adopting modules and instead rely on C linkers, nothing to do with OOP.
- kabdib 10y ago
  Yup. We were looking at alternate runtimes in some OS / userland projects at Apple in the late 80s. You don't need vtables, and you can do better than static struct layout. You have to do some work at code load-time. C++'s initial lack of a real string type and simple collection types pretty much doomed the language. (Instead they did iostreams? I've been using C++ since early CFront days, and have never used that misbegotten API).
  - pjmlp 10y ago
    I guess I am one of the few people on the planet than enjoys using iostreams when I need to use C++. :) Then again, I never needed to know all their little details. Yeah implementing string, array and collection types was a kind of rite of passage for every C++ developer, back when the compilers were still trying to catch up with C++ARM. I believe appealing to the C culture was one of the reasons those types weren't initially available, as C++ was already considered too bloated by the C community even without them. Nowadays their three major compilers are written in C++.
kmiroslav 10y ago
> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.
- optforfon 10y ago
  Sorry, I mean "drawbacks". One of the reoccurring complaints about OO is that it leads to huge codebases. Lots of articles about how X rewrote some Java program in Y and it's not 10x smaller and 100x more maintainable. This is a consequence of languages being designed to be minimal in terms of keywords - trying to push off as much as possible on to library writers. Unfortunately this seems to have serious limitations and all the boilerplate can't seem to be hidden in library wrappers
  - kmiroslav 10y ago
    "Huge code base" is a pretty vague metric. Huge in what, lines of code? Binary size? I'd argue that neither of these are really a good measure, I'm more interested in the concepts that a source file captures than its size in kb, because these concepts correlate directly to how easy it will be to evolve that code base in the future. There is a point of diminishing return in trying to make the code too compact, which basically means you're optimizing in one dimension at the detriments of all the others.
  - dursk 10y ago
    The problem there is that any re-write, even staying within OO, is going to result in the codebase being smaller.
- infinite8s 10y ago
  Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 that's still true today - "those infra-red urinals in public restrooms know more about what we are doing than our computers today."

pjmlp 10y ago

I can think of a good list of OO languages that don't have anything to do with C. Also the pImpl is a consequence of C++ not adopting modules and instead rely on C linkers, nothing to do with OOP.

kabdib 10y ago
Yup. We were looking at alternate runtimes in some OS / userland projects at Apple in the late 80s. You don't need vtables, and you can do better than static struct layout. You have to do some work at code load-time. C++'s initial lack of a real string type and simple collection types pretty much doomed the language. (Instead they did iostreams? I've been using C++ since early CFront days, and have never used that misbegotten API).
- pjmlp 10y ago
  I guess I am one of the few people on the planet than enjoys using iostreams when I need to use C++. :) Then again, I never needed to know all their little details. Yeah implementing string, array and collection types was a kind of rite of passage for every C++ developer, back when the compilers were still trying to catch up with C++ARM. I believe appealing to the C culture was one of the reasons those types weren't initially available, as C++ was already considered too bloated by the C community even without them. Nowadays their three major compilers are written in C++.

kmiroslav 10y ago

> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.

optforfon 10y ago
Sorry, I mean "drawbacks". One of the reoccurring complaints about OO is that it leads to huge codebases. Lots of articles about how X rewrote some Java program in Y and it's not 10x smaller and 100x more maintainable. This is a consequence of languages being designed to be minimal in terms of keywords - trying to push off as much as possible on to library writers. Unfortunately this seems to have serious limitations and all the boilerplate can't seem to be hidden in library wrappers
- kmiroslav 10y ago
  "Huge code base" is a pretty vague metric. Huge in what, lines of code? Binary size? I'd argue that neither of these are really a good measure, I'm more interested in the concepts that a source file captures than its size in kb, because these concepts correlate directly to how easy it will be to evolve that code base in the future. There is a point of diminishing return in trying to make the code too compact, which basically means you're optimizing in one dimension at the detriments of all the others.
- dursk 10y ago
  The problem there is that any re-write, even staying within OO, is going to result in the codebase being smaller.
infinite8s 10y ago
Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 that's still true today - "those infra-red urinals in public restrooms know more about what we are doing than our computers today."