10 ms·

I've been around long enough to remember when OOP was the savior who would free us from the previous generation of trillion-dollar disasters (spaghetti code, CA

I've been around long enough to remember when OOP was the savior who would free us from the previous generation of trillion-dollar disasters (spaghetti code, CASE tools, DFDs), and I'm sure someone will be writing "Functional Programming - The Trillion Dollar Disaster" in 10-20 years. In other words, I don't do hype or fads anymore.

trilila 7y ago
This. Thank you. Thank you for thinking rationally.
flyingcoder 7y ago
Can we just agree that programming is a trillion dollar disaster in general?
- dgellow 7y ago
  If during that same period programming as a whole generates more than a trillion dollar, is it an issue then? Or just an operation cost? :-)
  - kazinator 7y ago
    It's okay to break, as long as you break even?
teekert 7y ago
Seems like the whole world does the hype and then moves on to me.
gluegadget 7y ago
FP already existed at the time that OOP emerged as the savior. What currently in-practice paradigms do you think are likely to save us in 10-20 years?
- kjeetgill 7y ago
  Sorta! I don't think enough credit is given to how Functional Programming as a paradigm has shifted and changed over the years. It's grown and developed a lot. There was definitely a time when having first class functions and functions as params was a big focus of Functional Programming. It opens the doors to a lot of expressive idioms. The inclusion of closures was an important part of this. This wave was definitely all about expressability more than structured reasoning. I'm talking lispy homoiconic macroy goodness. Later Functional Programming thought was focused in the direction of ML/Haskelly/OCamly languages with a stronger focus on function purity, immutability, side-effect management, type inference, abstract algebra, and static guarantees of program structure and correctness. Sure the ideas existed before, but they're hard to reason about until they're distilled into a paradigm/doctrine. And Functional Programming did that. Like OOP, I think both waves of Functional Programming had a big impact on the programming landscape by introducing and popularizing a new vocabulary to a broader audience. The situational application of them will always come with experience and so every "fad" has the baggage of over application once it goes mainstream. OOP with Java, Javascript's framework explosion, 500 blog posts about monads, etc.
danielscrubs 7y ago
Depends on what you mean with Functional Programming. Do you think we will ever see: "Math - The Trillion Dollar Disaster"? Because we really ought to go that way (more proofs like Idris/Agda). > “Simplicity is a great virtue but it requires hard work to achieve it and education to > appreciate it. And to make matters worse: complexity sells better.” > ― Edsger Wybe Dijkstra
- GuiA 7y ago
  Unless the tooling makes it trivial - which is still a long, long time away, if possible - I’m not sure there is a world where the increased cost of formal verification (mostly in terms of engineers who know what they’re doing) makes sense for things like line of business PHP/node.js websites, internal python apps, bash scripts, etc.
  - danielscrubs 7y ago
    100% agree, but I'm hopeful.
- kjeetgill 7y ago
  > Do you think we will ever see: "Math - The Trillion Dollar Disaster"? Close! We have "Lies, Damn Lies, and Statistics". Tongue-in-cheek aside, it's one of those things where the more good you do the more bad you do. If X has a trillion dollars of good impact, it'll more trivially have a few million of bad impact at least. It's like a weird inverse Amdahl's law. OOP definitely solved a huge class of issues for a lot of people better than the "average state-of-the-art" at the time, and introduced a lot of people to even reasoning around concepts like encapsulation and abstraction. Was it the best thing ever for all time forever and ever? Did it have contemporary ideas that could have been perfect forever? Sure. Does that mean it did more harm than good. Questionable.
- nikofeyn 7y ago
  > Because we really ought to go that way (more proofs like Idris/Agda). proofs are not everything in software. what do you do if you're handed a massive code-base in idris and are asked to make a change, a change that requires jumping through all sorts of hoops due to the type system? constrained type systems are fine but along some vectors of software development, they actually increase brittleness. maybe not brittleness at run-time but at develop and maintenance time.
ernst_klim 7y ago
> I'm sure someone will be writing "Functional Programming - The Trillion Dollar Disaster" I'm sure no one wouldn't. From my experience of working with GObject, C++, smalltalk and CLOS, I dare say that OOP is an inherently terrible idea. OOP is harmful because it mixes two concepts you don't want to be mixed: open recursion and encapsulation. OOP forces you to model your code as a state machine, where the transition logic is obfuscated (OOP people call it abstraction for some reason), hidden behind virtual methods, inheritance and abstraction. This means you send a message to an object, and that triggers a chain of state transitions which is totally hidden (aka object could call a parent's method, parent's method could call some of the virtual methods, which sends message to some other object and so on). This terrible implicitness makes your code obfuscated and impossible to debug, especially in presence of locks and parallelism. Hence this recent trend of hatred towards inheritance and OOP in general. Now, regarding Functional Programming. If you would draw an axis where to the left would be implicit paradigms, and to the right would be explicit ones, Procedural programming would be in the middle. Procedural programming is very explicit, all state transitions are obvious, safe those which exploit side effects. Side effects is the only thing that make Procedural programming implicit (and buggy). OOP is significantly more implicit that procedural programming, because even the logic is obfuscated with virtual methods and late binding/open recursion. Then FP on this implicit->explicit axes would be at the explicit pole, since FP tries to make the effectful code explicit, hence it's inherently good and less buggy, while OOP code is inherently more buggy. Each bug I meet in Gstreamer or our C++ codebase is extremely hard co comprehend and debug due to these obfuscated state transition, while debugging our OCaml codebase is a breeze. I wouldn't say that message passing is always a bad thing, it's good in one case: when the logic is not known in advance, for example when you have a distributed system where nodes work independently and send message on occasion (aka actors). Although this case has its own underwater rocks.
- ernst_klim 7y ago
  A simple example on how open recursion is harmful. Consider we have a object which computes the factorial: class computer = object(self) method factorial x = if x = 0 then 1 else x * self#factorial (self#pred x) method pred x = x - 1 end Now, somebody redefines `pred` class computer_enhanced = object inherit computer method pred x = x end Now factorial simply hangs in infinite loop (until stack overflow). This example is very trivial, but when you have dozens of methods, mutable variables, locks, parallelism, and you redefine a virtual method (aka adding a recursive call changing the state transition graph) without knowing precisely how other methods work, this ends with annoying bugs, deadlocks and very hard to debug.

trilila 7y ago

This. Thank you. Thank you for thinking rationally.

flyingcoder 7y ago

Can we just agree that programming is a trillion dollar disaster in general?

dgellow 7y ago
If during that same period programming as a whole generates more than a trillion dollar, is it an issue then? Or just an operation cost? :-)
- kazinator 7y ago
  It's okay to break, as long as you break even?

teekert 7y ago

Seems like the whole world does the hype and then moves on to me.

gluegadget 7y ago

FP already existed at the time that OOP emerged as the savior. What currently in-practice paradigms do you think are likely to save us in 10-20 years?

kjeetgill 7y ago
Sorta! I don't think enough credit is given to how Functional Programming as a paradigm has shifted and changed over the years. It's grown and developed a lot. There was definitely a time when having first class functions and functions as params was a big focus of Functional Programming. It opens the doors to a lot of expressive idioms. The inclusion of closures was an important part of this. This wave was definitely all about expressability more than structured reasoning. I'm talking lispy homoiconic macroy goodness. Later Functional Programming thought was focused in the direction of ML/Haskelly/OCamly languages with a stronger focus on function purity, immutability, side-effect management, type inference, abstract algebra, and static guarantees of program structure and correctness. Sure the ideas existed before, but they're hard to reason about until they're distilled into a paradigm/doctrine. And Functional Programming did that. Like OOP, I think both waves of Functional Programming had a big impact on the programming landscape by introducing and popularizing a new vocabulary to a broader audience. The situational application of them will always come with experience and so every "fad" has the baggage of over application once it goes mainstream. OOP with Java, Javascript's framework explosion, 500 blog posts about monads, etc.

danielscrubs 7y ago

Depends on what you mean with Functional Programming. Do you think we will ever see: "Math - The Trillion Dollar Disaster"? Because we really ought to go that way (more proofs like Idris/Agda). > “Simplicity is a great virtue but it requires hard work to achieve it and education to > appreciate it. And to make matters worse: complexity sells better.” > ― Edsger Wybe Dijkstra

GuiA 7y ago
Unless the tooling makes it trivial - which is still a long, long time away, if possible - I’m not sure there is a world where the increased cost of formal verification (mostly in terms of engineers who know what they’re doing) makes sense for things like line of business PHP/node.js websites, internal python apps, bash scripts, etc.
- danielscrubs 7y ago
  100% agree, but I'm hopeful.
kjeetgill 7y ago
> Do you think we will ever see: "Math - The Trillion Dollar Disaster"? Close! We have "Lies, Damn Lies, and Statistics". Tongue-in-cheek aside, it's one of those things where the more good you do the more bad you do. If X has a trillion dollars of good impact, it'll more trivially have a few million of bad impact at least. It's like a weird inverse Amdahl's law. OOP definitely solved a huge class of issues for a lot of people better than the "average state-of-the-art" at the time, and introduced a lot of people to even reasoning around concepts like encapsulation and abstraction. Was it the best thing ever for all time forever and ever? Did it have contemporary ideas that could have been perfect forever? Sure. Does that mean it did more harm than good. Questionable.
nikofeyn 7y ago
> Because we really ought to go that way (more proofs like Idris/Agda). proofs are not everything in software. what do you do if you're handed a massive code-base in idris and are asked to make a change, a change that requires jumping through all sorts of hoops due to the type system? constrained type systems are fine but along some vectors of software development, they actually increase brittleness. maybe not brittleness at run-time but at develop and maintenance time.

ernst_klim 7y ago

> I'm sure someone will be writing "Functional Programming - The Trillion Dollar Disaster" I'm sure no one wouldn't. From my experience of working with GObject, C++, smalltalk and CLOS, I dare say that OOP is an inherently terrible idea. OOP is harmful because it mixes two concepts you don't want to be mixed: open recursion and encapsulation. OOP forces you to model your code as a state machine, where the transition logic is obfuscated (OOP people call it abstraction for some reason), hidden behind virtual methods, inheritance and abstraction. This means you send a message to an object, and that triggers a chain of state transitions which is totally hidden (aka object could call a parent's method, parent's method could call some of the virtual methods, which sends message to some other object and so on). This terrible implicitness makes your code obfuscated and impossible to debug, especially in presence of locks and parallelism. Hence this recent trend of hatred towards inheritance and OOP in general. Now, regarding Functional Programming. If you would draw an axis where to the left would be implicit paradigms, and to the right would be explicit ones, Procedural programming would be in the middle. Procedural programming is very explicit, all state transitions are obvious, safe those which exploit side effects. Side effects is the only thing that make Procedural programming implicit (and buggy). OOP is significantly more implicit that procedural programming, because even the logic is obfuscated with virtual methods and late binding/open recursion. Then FP on this implicit->explicit axes would be at the explicit pole, since FP tries to make the effectful code explicit, hence it's inherently good and less buggy, while OOP code is inherently more buggy. Each bug I meet in Gstreamer or our C++ codebase is extremely hard co comprehend and debug due to these obfuscated state transition, while debugging our OCaml codebase is a breeze. I wouldn't say that message passing is always a bad thing, it's good in one case: when the logic is not known in advance, for example when you have a distributed system where nodes work independently and send message on occasion (aka actors). Although this case has its own underwater rocks.

ernst_klim 7y ago
A simple example on how open recursion is harmful. Consider we have a object which computes the factorial: class computer = object(self) method factorial x = if x = 0 then 1 else x * self#factorial (self#pred x) method pred x = x - 1 end Now, somebody redefines `pred` class computer_enhanced = object inherit computer method pred x = x end Now factorial simply hangs in infinite loop (until stack overflow). This example is very trivial, but when you have dozens of methods, mutable variables, locks, parallelism, and you redefine a virtual method (aka adding a recursive call changing the state transition graph) without knowing precisely how other methods work, this ends with annoying bugs, deadlocks and very hard to debug.