7 ms·

ORM is the Vietnam of Computer Science, because OOP is the Vietnam of Computer Science: A 25-year failed experiment in boosting productivity of masses of medioc

ORM is the Vietnam of Computer Science, because OOP is the Vietnam of Computer Science: A 25-year failed experiment in boosting productivity of masses of mediocre programmers using this one true silver bullet.

booleandilemma 9y ago
Hi, mediocre programmer here. OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state. What alternative did you have in mind? Functional programming?
- TeMPOraL 9y ago
  Breaking up a problem recursively into stateful components is completely orthogonal to OOP.
  - thesmallestcat 9y ago
    As is coupling state and function. Parent's comment is a good demonstration of the inertia of misinformed adherence to OOP.
    - halter73 9y ago
      Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal? A succinct definition of OOP would be nice to combat the misinformation you're complaining about. The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP. > object-oriented which groups code together with the state the code modifies, Maybe that's a little too succinct, because I think it's also worth noting how [2] > In OOP, computer programs are designed by making them out of objects that interact with one another. I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either. I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed. [1] https://en.m.wikipedia.org/wiki/Programming_paradigm https://en.m.wikipedia.org/wiki/Programming_paradigm [2] https://en.m.wikipedia.org/wiki/Object-oriented_programming https://en.m.wikipedia.org/wiki/Object-oriented_programming
      - thesmallestcat 9y ago
        The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy. I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types. I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
        halter73 9y ago
        I probably put too much stock in the "As is" at the beginning of your post. A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing. I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
        deleted 9y ago
        [deleted]
        unscaled 9y ago
        OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java. These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.
      - coding123 9y ago
- fizixer 9y ago
  > What alternative did you have in mind? My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders. [1] https://en.wikipedia.org/wiki/Programming_paradigm https://en.wikipedia.org/wiki/Programming_paradigm
- IncRnd 9y ago
  The design principles of modularity and stateful components exist independent of an OOP.
- whorleater 9y ago
  > It's natural to break large systems into component parts recursively, and to let components have their own state The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP
  - deleted 9y ago
    [deleted]
  - simonh 9y ago
    And now we're slinging obnoxious insulting mud. Lovely. Thank you for your contribution. I'm going to be that guy. Citation please, even one statement anywhere by an author if an OOP language or of a book on OOP where they say it's the only way to do that.
    - Tomis02 9y ago
      They don't have to say it, it's implied by omission. When OOP proponents keep repeating that it breaks a program into smaller, more manageable parts, it's easy for beginning programmers to assume that this is a defining feature of OOP and that it's somehow specific to it.
- Pica_soO 9y ago
  It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming. When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach. Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version. Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability? PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic. Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update? In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece. TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.
- naasking 9y ago
  > OOP is the most popular paradigm because it works the best for the greatest number of people and projects It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic. > It's natural to break large systems into component parts recursively, and to let components have their own state. That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.
  - seanmcdirmid 9y ago
    What other paradigm focuses on components with encapsulated state? Definitely not functional! Isn't any nounish "thing" with state an object anyways? Why else could it be?
    - di4na 9y ago
      Because there are no "nounish" things. It is a false construct. Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
      - seanmcdirmid 9y ago
        Hewitt never said actors weren't objects, quite the opposite actually. Heck, simula (the first OOP language) objects were very actor like. Grand parent is talking specifically about encapsulating state and not just behaviors.
        di4na 9y ago
        Simula objects were not a Actor like, they were exactly like today object. Smalltalk originally was like Actors, and it is what spawned the idea in Hewitt mind. Our Objects of today come straight from Simula. Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.
lomnakkus 9y ago
I cannot upvote this enough. The "silver bullet" bit is the primary point, though I'll say I've found very few actual uses of OOP-as-described-in-the-mainstream in my ~30 year carreer. Polymorphism, sure! Composition, sure! Information Hiding[1], sure! Modularity, sure! Implementation inheritance, ooh, sounds interesting[2]. The only problem with that sales pitch is that you don't actually have to combine all of them into a single concept ("OOP"). They are pretty much all orthogonal. [1] That's was actually called Abstraction before "OOP" was invented as "a thing" in the mainstream. Well, it still is, but it's just that it applies beyond "public/private/package" scope (and the like). For example, O'Caml has "modules" which give you abstraction at what would be equivalent to Java's package scope. Amazing, I know. /s [2] To be fair, I was absolutely entranced by the promise of implementation interitance[3]: What can I say, I was young and naive, and knew only Turbo Pascal and Delphi. With considerably more experience I consider it a fundamental mistake to include such a construct in your language. [3] As was the rest of the industry, at least I had the excuse of inexperience. Such mistakes we've (collectively) made! :)
goatlover 9y ago
Are there actual facts to back up claims to productivity boosts or failures with a given paradigm across large numbers of programmers and organizations? I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use. Maybe a functional, non-mutable approach is better, but until it has a similar widespread use and enough time for people to complain about it and suggest new superior paradigms, I'm not sold on the truth of these claims. It sounds more like preference and opinion than fact. Also, I can't help but wonder if it's the C++/Java model of OOP that's more than issue than OOP itself. Would the same complaints be made of Smalltalk? Personally, I prefer the OOP of Ruby than that of Java, and don't really see a problem with using it.
- userbinator 9y ago
  I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use. If other languages were used, perhaps they would not need to be so complex and resource-consuming, but this is also why any "actual facts" which you're looking for are difficult to find: you'd need to essentially do the same project multiple times in different languages and perform a very highly controlled comparison, and there are numerous other confounding factors. Failures or successes alike can easily be spun into blaming the languages. IMHO there is no one perfect paradigm for everything, and the only failure is in promoting one as panacea or trying to view all of programming in the same way. I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity.
  - maxxxxx 9y ago
    "I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity." That's it. Rigid ideology is the real problem. In software engineering and other areas too, eg politics.
- pmarreck 9y ago
InclinedPlane 9y ago
OOP isn't the problem, the problem is putting faith in the concept of silver bullets. OOP is a useful technique, like many others. I've seen "overly OOP" code that will make your head spin, but more often than not I've seen code that could have been a bit more object oriented. The problem is the cargo cult mentality that you can just follow something formulaically and then magically you'll get amazing results. There are plenty of highly useful techniques and tools, including OOP, but you have to do the work, you have to apply the techniques skillfully and conscientiously. You have to know when you're just adding complexity with your design and when you're managing it well.
mpweiher 9y ago
> failed experiment [..] one true silver bullet Well, let's unpack this a bit. No Silver Bullet – Essence and Accident in Software Engineering[1] was written in 1986 by Turing Award winner and author of The Mythical Man Month Fred Brooks. His thesis was that there was no single technology or technique which by itself promises even one order of magnitude of improvement within a decade. However, he did write this of OOP: "Object-oriented programming. Many students of the art hold out more hope for object oriented programming than for any of the other technical fads of the day. I am among them" [2] In addition to OOP, the biggy he identified was reuse, mostly in COTS. "A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road." 20 years after the original essay, there was a retrospective at OOPSLA. Here is what Brooks had to say[3]: "Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself. The most promising attack continues to be re-use, and re-use of COTS programs in particular. " And of course he is absolutely right. OOP has delivered massive increases in productivity, we are successfully tackling problems of far bigger complexity than we did back then. Just as a small example, the WWW was invented by a single person in a couple of months in his spare time! On NeXTStep a highly OO platform. Replicating that with lesser tech took a team a year, and they had to leave out editing, which was in the original. And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code. So the idea that OO is a failed "silver bullet" is nothing short of ridiculous. It has succeeded, and in succeeding has pushed us against new frontiers of our ignorance. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet [2] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf http://worrydream.com/refs/Brooks-NoSilverBullet.pdf [3] http://dl.acm.org/citation.cfm?id=1297973 http://dl.acm.org/citation.cfm?id=1297973
- Tomis02 9y ago
  > And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code. That's a really bad argument. We reuse vast amounts of non-OO code too(libpng, libjpeg, libwhatever). We don't reuse code because it's written in a paradigm, but because we need it. Since OO spread like a virus (some argue it was for the better, I argue it was for the worse) and is now the most popular paradigm, it makes sense it will have produced lots of frameworks, but it doesn't mean OOP was needed to write and use them.

booleandilemma 9y ago

Hi, mediocre programmer here. OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state. What alternative did you have in mind? Functional programming?

TeMPOraL 9y ago
Breaking up a problem recursively into stateful components is completely orthogonal to OOP.
- thesmallestcat 9y ago
  As is coupling state and function. Parent's comment is a good demonstration of the inertia of misinformed adherence to OOP.
  - halter73 9y ago
    Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal? A succinct definition of OOP would be nice to combat the misinformation you're complaining about. The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP. > object-oriented which groups code together with the state the code modifies, Maybe that's a little too succinct, because I think it's also worth noting how [2] > In OOP, computer programs are designed by making them out of objects that interact with one another. I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either. I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed. [1] https://en.m.wikipedia.org/wiki/Programming_paradigm https://en.m.wikipedia.org/wiki/Programming_paradigm [2] https://en.m.wikipedia.org/wiki/Object-oriented_programming https://en.m.wikipedia.org/wiki/Object-oriented_programming
    - thesmallestcat 9y ago
      The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy. I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types. I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
      - halter73 9y ago
        I probably put too much stock in the "As is" at the beginning of your post. A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing. I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
      - deleted 9y ago
        [deleted]
      - unscaled 9y ago
        OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java. These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.
    - coding123 9y ago
fizixer 9y ago
> What alternative did you have in mind? My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders. [1] https://en.wikipedia.org/wiki/Programming_paradigm https://en.wikipedia.org/wiki/Programming_paradigm
IncRnd 9y ago
The design principles of modularity and stateful components exist independent of an OOP.
whorleater 9y ago
> It's natural to break large systems into component parts recursively, and to let components have their own state The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP
- deleted 9y ago
  [deleted]
- simonh 9y ago
  And now we're slinging obnoxious insulting mud. Lovely. Thank you for your contribution. I'm going to be that guy. Citation please, even one statement anywhere by an author if an OOP language or of a book on OOP where they say it's the only way to do that.
  - Tomis02 9y ago
    They don't have to say it, it's implied by omission. When OOP proponents keep repeating that it breaks a program into smaller, more manageable parts, it's easy for beginning programmers to assume that this is a defining feature of OOP and that it's somehow specific to it.
Pica_soO 9y ago
It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming. When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach. Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version. Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability? PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic. Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update? In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece. TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.
naasking 9y ago
> OOP is the most popular paradigm because it works the best for the greatest number of people and projects It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic. > It's natural to break large systems into component parts recursively, and to let components have their own state. That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.
- seanmcdirmid 9y ago
  What other paradigm focuses on components with encapsulated state? Definitely not functional! Isn't any nounish "thing" with state an object anyways? Why else could it be?
  - di4na 9y ago
    Because there are no "nounish" things. It is a false construct. Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
    - seanmcdirmid 9y ago
      Hewitt never said actors weren't objects, quite the opposite actually. Heck, simula (the first OOP language) objects were very actor like. Grand parent is talking specifically about encapsulating state and not just behaviors.
      - di4na 9y ago
        Simula objects were not a Actor like, they were exactly like today object. Smalltalk originally was like Actors, and it is what spawned the idea in Hewitt mind. Our Objects of today come straight from Simula. Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.

lomnakkus 9y ago

I cannot upvote this enough. The "silver bullet" bit is the primary point, though I'll say I've found very few actual uses of OOP-as-described-in-the-mainstream in my ~30 year carreer. Polymorphism, sure! Composition, sure! Information Hiding[1], sure! Modularity, sure! Implementation inheritance, ooh, sounds interesting[2]. The only problem with that sales pitch is that you don't actually have to combine all of them into a single concept ("OOP"). They are pretty much all orthogonal. [1] That's was actually called Abstraction before "OOP" was invented as "a thing" in the mainstream. Well, it still is, but it's just that it applies beyond "public/private/package" scope (and the like). For example, O'Caml has "modules" which give you abstraction at what would be equivalent to Java's package scope. Amazing, I know. /s [2] To be fair, I was absolutely entranced by the promise of implementation interitance[3]: What can I say, I was young and naive, and knew only Turbo Pascal and Delphi. With considerably more experience I consider it a fundamental mistake to include such a construct in your language. [3] As was the rest of the industry, at least I had the excuse of inexperience. Such mistakes we've (collectively) made! :)

goatlover 9y ago

Are there actual facts to back up claims to productivity boosts or failures with a given paradigm across large numbers of programmers and organizations? I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use. Maybe a functional, non-mutable approach is better, but until it has a similar widespread use and enough time for people to complain about it and suggest new superior paradigms, I'm not sold on the truth of these claims. It sounds more like preference and opinion than fact. Also, I can't help but wonder if it's the C++/Java model of OOP that's more than issue than OOP itself. Would the same complaints be made of Smalltalk? Personally, I prefer the OOP of Ruby than that of Java, and don't really see a problem with using it.

userbinator 9y ago
I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use. If other languages were used, perhaps they would not need to be so complex and resource-consuming, but this is also why any "actual facts" which you're looking for are difficult to find: you'd need to essentially do the same project multiple times in different languages and perform a very highly controlled comparison, and there are numerous other confounding factors. Failures or successes alike can easily be spun into blaming the languages. IMHO there is no one perfect paradigm for everything, and the only failure is in promoting one as panacea or trying to view all of programming in the same way. I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity.
- maxxxxx 9y ago
  "I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity." That's it. Rigid ideology is the real problem. In software engineering and other areas too, eg politics.
pmarreck 9y ago

InclinedPlane 9y ago

OOP isn't the problem, the problem is putting faith in the concept of silver bullets. OOP is a useful technique, like many others. I've seen "overly OOP" code that will make your head spin, but more often than not I've seen code that could have been a bit more object oriented. The problem is the cargo cult mentality that you can just follow something formulaically and then magically you'll get amazing results. There are plenty of highly useful techniques and tools, including OOP, but you have to do the work, you have to apply the techniques skillfully and conscientiously. You have to know when you're just adding complexity with your design and when you're managing it well.

mpweiher 9y ago

> failed experiment [..] one true silver bullet Well, let's unpack this a bit. No Silver Bullet – Essence and Accident in Software Engineering[1] was written in 1986 by Turing Award winner and author of The Mythical Man Month Fred Brooks. His thesis was that there was no single technology or technique which by itself promises even one order of magnitude of improvement within a decade. However, he did write this of OOP: "Object-oriented programming. Many students of the art hold out more hope for object oriented programming than for any of the other technical fads of the day. I am among them" [2] In addition to OOP, the biggy he identified was reuse, mostly in COTS. "A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road." 20 years after the original essay, there was a retrospective at OOPSLA. Here is what Brooks had to say[3]: "Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself. The most promising attack continues to be re-use, and re-use of COTS programs in particular. " And of course he is absolutely right. OOP has delivered massive increases in productivity, we are successfully tackling problems of far bigger complexity than we did back then. Just as a small example, the WWW was invented by a single person in a couple of months in his spare time! On NeXTStep a highly OO platform. Replicating that with lesser tech took a team a year, and they had to leave out editing, which was in the original. And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code. So the idea that OO is a failed "silver bullet" is nothing short of ridiculous. It has succeeded, and in succeeding has pushed us against new frontiers of our ignorance. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet [2] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf http://worrydream.com/refs/Brooks-NoSilverBullet.pdf [3] http://dl.acm.org/citation.cfm?id=1297973 http://dl.acm.org/citation.cfm?id=1297973

Tomis02 9y ago
> And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code. That's a really bad argument. We reuse vast amounts of non-OO code too(libpng, libjpeg, libwhatever). We don't reuse code because it's written in a paradigm, but because we need it. Since OO spread like a virus (some argue it was for the better, I argue it was for the worse) and is now the most popular paradigm, it makes sense it will have produced lots of frameworks, but it doesn't mean OOP was needed to write and use them.