4 ms·

> what you need is really just Data structure + Algorithm Lets hope your not in charge of building that new complex air traffic control system, bank lending sy

> what you need is really just Data structure + Algorithm Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system. Did you learn nothing of over a decade of large projects using data-flow modeling (structured analysis)?

cjblomqvist 4y ago
Can you elaborate? I'd love to have have more arguments for why FP is not the holy grail it's sometimes made out to be!
- aryehof 4y ago
  Email me if you want to chat about it. I'm loathe to write a treatise here sorry.
ernst_klim 4y ago
The core illusion of OOP is that it makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. When in fact you can have architecturally separated modules without objects just fine, and all objects bring is the complexity of finite state machines talking to each other via complex message protocols. Sometimes you indeed need some virtual dispatching, but most of the time procedure is a better abstraction, and function is even better. Instead of making complex parts of the system simpler, OOP usually makes simple parts complex. Hence the need for frameworks. In functional or procedural worlds people just take libraries and glue them together. In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. Hence OOP evolved towards megalibraries which have it all. > Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system. Many of these are doing fine being written in procedural style though.
- al_mandi 4y ago
  > In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.
  - ernst_klim 4y ago
    > That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.
- aryehof 4y ago
  > makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. This Kay-esque focus on _messages_ has fudded the OO space for too long now. The so called "magical view" of OO - "it's all about messages". The actual original inventors saw an object as a representation of a phenomena, real or imagined. They (particularly Kristen Nygaard) sought a way to model phenomena, concepts and the interactions between them. Consider that this is the design viewpoint that Bjarne Stroustrup actually sought to add to the C language. Step back from a focus on state machines, message protocols and a technical plumbing viewpoint. FP has its place, particularly where the focus is on the transformation of data. But don't extrapolate that as applicable to all types of computing application. As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. That involved data modeling and typically separately modeling the functional processes that modified that data. Did we learn anything?
mattmein 4y ago
Data structure + algorithm is a valid way of building large programs. That is basically how Clojure is designed, and it works pretty well for big applications. Functional programming in aviation: https://m.youtube.com/watch?v=0x3EIqBrZxw https://m.youtube.com/watch?v=0x3EIqBrZxw Functional programming in banking: https://www.finextra.com/newsarticle/36297/nubank-buys-firm-behind-clojure-programming-language https://www.finextra.com/newsarticle/36297/nubank-buys-firm-...
- jcelerier 4y ago
  Can you show one large-ish GUI software written in Clojure? Something like, idk, Blender, DaVinci Resolve, Unreal Engine...
  - RedShift1 4y ago
    The problem with that is that (nearly?) every GUI toolkit is object oriented so you can't escape it if you want to write GUI programs.
    - jcelerier 4y ago
      clojure was introduced in 2007, there have been many GUI toolkits that have been implemented entirely from scratch in other languages since then. QML+QtQuick, Dart+Flutter, Nuklear in C, Nana or neoGFX in C++, etc etc
    - ernst_klim 4y ago
      > The problem with that is that (nearly?) every GUI toolkit is object oriented Except for things like React which are more or less functional reactive programming, but in case of react its stateful. Functional reactive programming exist, and GUI is not obliged to be OO
  - thom 4y ago
    The Defold game engine IDE is written in Clojure, using cljfx, a React-like wrapper around JavaFX: https://defold.com/ https://defold.com/

cjblomqvist 4y ago

Can you elaborate? I'd love to have have more arguments for why FP is not the holy grail it's sometimes made out to be!

aryehof 4y ago
Email me if you want to chat about it. I'm loathe to write a treatise here sorry.

ernst_klim 4y ago

The core illusion of OOP is that it makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. When in fact you can have architecturally separated modules without objects just fine, and all objects bring is the complexity of finite state machines talking to each other via complex message protocols. Sometimes you indeed need some virtual dispatching, but most of the time procedure is a better abstraction, and function is even better. Instead of making complex parts of the system simpler, OOP usually makes simple parts complex. Hence the need for frameworks. In functional or procedural worlds people just take libraries and glue them together. In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. Hence OOP evolved towards megalibraries which have it all. > Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system. Many of these are doing fine being written in procedural style though.

al_mandi 4y ago
> In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.
- ernst_klim 4y ago
  > That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.
aryehof 4y ago
> makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. This Kay-esque focus on _messages_ has fudded the OO space for too long now. The so called "magical view" of OO - "it's all about messages". The actual original inventors saw an object as a representation of a phenomena, real or imagined. They (particularly Kristen Nygaard) sought a way to model phenomena, concepts and the interactions between them. Consider that this is the design viewpoint that Bjarne Stroustrup actually sought to add to the C language. Step back from a focus on state machines, message protocols and a technical plumbing viewpoint. FP has its place, particularly where the focus is on the transformation of data. But don't extrapolate that as applicable to all types of computing application. As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. That involved data modeling and typically separately modeling the functional processes that modified that data. Did we learn anything?

mattmein 4y ago

Data structure + algorithm is a valid way of building large programs. That is basically how Clojure is designed, and it works pretty well for big applications. Functional programming in aviation: https://m.youtube.com/watch?v=0x3EIqBrZxw https://m.youtube.com/watch?v=0x3EIqBrZxw Functional programming in banking: https://www.finextra.com/newsarticle/36297/nubank-buys-firm-behind-clojure-programming-language https://www.finextra.com/newsarticle/36297/nubank-buys-firm-...

jcelerier 4y ago
Can you show one large-ish GUI software written in Clojure? Something like, idk, Blender, DaVinci Resolve, Unreal Engine...
- RedShift1 4y ago
  The problem with that is that (nearly?) every GUI toolkit is object oriented so you can't escape it if you want to write GUI programs.
  - jcelerier 4y ago
    clojure was introduced in 2007, there have been many GUI toolkits that have been implemented entirely from scratch in other languages since then. QML+QtQuick, Dart+Flutter, Nuklear in C, Nana or neoGFX in C++, etc etc
  - ernst_klim 4y ago
    > The problem with that is that (nearly?) every GUI toolkit is object oriented Except for things like React which are more or less functional reactive programming, but in case of react its stateful. Functional reactive programming exist, and GUI is not obliged to be OO
- thom 4y ago
  The Defold game engine IDE is written in Clojure, using cljfx, a React-like wrapper around JavaFX: https://defold.com/ https://defold.com/