4 ms·

Lots of words. What's the conclusion? OOP is bad? Or maybe it is incompetent people who manage to f.. things up no matter what you give them or people with the

by FpUser 7y ago

Lots of words. What's the conclusion? OOP is bad? Or maybe it is incompetent people who manage to f.. things up no matter what you give them or people with the agenda going on holy crusades?

ChrisMarshallNY 7y ago
No, OOP is not "Bad." I'm not feeling particularly argumentative. I apologize if what I wrote upset you. I suspect that we may actually agree on most things. In some cases, it is not the best tool for the job, but I find that I tend to use OOP for almost everything I do; large or small. It isn't of much use in small utility scripts, though, and some languages are just not written to natively support it. In those cases, procedural (or FP) is the way to go. There are new-ish methodologies, like functional programming, and protocol-oriented programming, that deprecate "classic" OOP. Some folks are using these as backing for declaring OOP "dead." I suspect that might be a bit...premature. My current fave lang is Swift, which pretty much allows you to use any methodology you want, or mix them together (Will it blend? That is the question). I have found that it isn't helpful for me to "write off" any methodology, and most of my work is actually a hybrid approach; with elements of multiple methodologies. BTW: I'm a "lots of words" kind of guy. Prolix, JAMES Prolix...
- FpUser 7y ago
  "There are new-ish methodologies, like functional programming, and protocol-oriented programming, that deprecate "classic" OOP. Some folks are using these as backing for declaring OOP "dead." Those are anything but new-ish. In programming new often means that some old concept suddenly becomes fashionable. Myself I do not restrict to any single paradigm and use what I believe is the most suitable for current task.
  - ChrisMarshallNY 7y ago
    Note the "-ish". I know that they aren't actually new, and that many "new paradigms" are actually rebranded old stuff (I have been writing software since the early 1980s, and have seen these waves sweeping through the industry; often, with some amusement). What does happen, though, is that a canon develops, based on these technologies, and [actual] new techniques get created, based on them. Some of these are nightmares, and need to be strangled before they can crawl off the slab, but sometimes, a gem comes up. I write about some of my experiences around that here: https://littlegreenviper.com/miscellany/concrete-galoshes/#either-or https://littlegreenviper.com/miscellany/concrete-galoshes/#e... I remember writing "object-oriented" software for classic C, in the late 1980s. I called it the "faux object" pattern, and was based in state being kept in a structure that was passed around functions. I refined and formalized the idea when I encountered Apple's QuickDraw GX in the early '90s (I suspect that may be the only good thing that I ever got from that sad debacle). I used the faux object pattern in an SDK I designed in 1994, and it's still being used to this day. Back then, you couldn't pass OOP across module connections, so we had to figure out a way to do it with C. Nowadays, I can easily pass Swift extensions and virtual implementations across SDKs; no sweat. It's cool.
  - afiori 7y ago
    In my uninformed opinion many of these "nothing new" cases happen because the newcomer actually solved some (maybe minor) pain point in usability of the old solution. Maybe combined with some good old nostalgia. In general I agree that people should study more the past, but I do not see any point in dismissing new trends just because the do not market their full genealogy upfront.

by FpUser 7y ago

Lots of words. What's the conclusion? OOP is bad? Or maybe it is incompetent people who manage to f.. things up no matter what you give them or people with the agenda going on holy crusades?

ChrisMarshallNY 7y ago

No, OOP is not "Bad." I'm not feeling particularly argumentative. I apologize if what I wrote upset you. I suspect that we may actually agree on most things. In some cases, it is not the best tool for the job, but I find that I tend to use OOP for almost everything I do; large or small. It isn't of much use in small utility scripts, though, and some languages are just not written to natively support it. In those cases, procedural (or FP) is the way to go. There are new-ish methodologies, like functional programming, and protocol-oriented programming, that deprecate "classic" OOP. Some folks are using these as backing for declaring OOP "dead." I suspect that might be a bit...premature. My current fave lang is Swift, which pretty much allows you to use any methodology you want, or mix them together (Will it blend? That is the question). I have found that it isn't helpful for me to "write off" any methodology, and most of my work is actually a hybrid approach; with elements of multiple methodologies. BTW: I'm a "lots of words" kind of guy. Prolix, JAMES Prolix...

FpUser 7y ago
"There are new-ish methodologies, like functional programming, and protocol-oriented programming, that deprecate "classic" OOP. Some folks are using these as backing for declaring OOP "dead." Those are anything but new-ish. In programming new often means that some old concept suddenly becomes fashionable. Myself I do not restrict to any single paradigm and use what I believe is the most suitable for current task.
- ChrisMarshallNY 7y ago
  Note the "-ish". I know that they aren't actually new, and that many "new paradigms" are actually rebranded old stuff (I have been writing software since the early 1980s, and have seen these waves sweeping through the industry; often, with some amusement). What does happen, though, is that a canon develops, based on these technologies, and [actual] new techniques get created, based on them. Some of these are nightmares, and need to be strangled before they can crawl off the slab, but sometimes, a gem comes up. I write about some of my experiences around that here: https://littlegreenviper.com/miscellany/concrete-galoshes/#either-or https://littlegreenviper.com/miscellany/concrete-galoshes/#e... I remember writing "object-oriented" software for classic C, in the late 1980s. I called it the "faux object" pattern, and was based in state being kept in a structure that was passed around functions. I refined and formalized the idea when I encountered Apple's QuickDraw GX in the early '90s (I suspect that may be the only good thing that I ever got from that sad debacle). I used the faux object pattern in an SDK I designed in 1994, and it's still being used to this day. Back then, you couldn't pass OOP across module connections, so we had to figure out a way to do it with C. Nowadays, I can easily pass Swift extensions and virtual implementations across SDKs; no sweat. It's cool.
- afiori 7y ago
  In my uninformed opinion many of these "nothing new" cases happen because the newcomer actually solved some (maybe minor) pain point in usability of the old solution. Maybe combined with some good old nostalgia. In general I agree that people should study more the past, but I do not see any point in dismissing new trends just because the do not market their full genealogy upfront.