3 ms·

Totally pure stateless programs are not the norm in functional programming. E.g. the functional core imperative shell pattern. It's also not just a syntax diff

Totally pure stateless programs are not the norm in functional programming. E.g. the functional core imperative shell pattern. It's also not just a syntax difference, mainstream languages are embracing immutability more and more, often as a default. The point is that calling FP academic is a tired trope and even if it is far from the dominant paradigm, there is clearly practical lessons to be learned whatever paradigm you program in.

c_crank 3y ago
The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. A Haskell program covered in piles of monads to abstract all state away still follows the functional core imperative shell pattern, because the runtime is the imperative shell. This doesn't make such a thing desirable for other languages. The practical lesson I learned from dabbling with functional programming in academia is that functional programming is often impractical and does not offer any of the purported benefits of better code.
- TuringTest 3y ago
  Monads are just one design pattern for handling state, and not the only way. It's no different than having an OOP using dependency injection everywhere - it's a design decision that you use only when it makes architectural sense. A shell is not more imperative than a processor - both are Turing machines, a completely functional mathematical object. Seeing them as imperative is a semantic interpretation of the people watching it, not an inherent property.
  - c_crank 3y ago
    Functional languages have either converged on either just allowing mutable values or relying on Monads as the ways of handling state. I'm not aware of a third solution.
    - TuringTest 3y ago
      You can just use the classic temporal logic approach, where state is passed explicitly as a parameter and the new state is returned. This is what state monads are doing anyway under a hidden syntax, and for simple cases it may be easier that building a full dedicated monad.
- jabradoodle 3y ago
  > The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. Most mainstream languages are old, they can't be immutable my default without breaking backwards compatibility. I'm talking about the design direction of languages that are already based on mutability. For example, Java added Records which are immutable, as well as overhauling the date/time api with an immutable version. > This doesn't make such a thing desirable for other languages. I've used this pattern in other languages, none of this is a silver bullet that makes software engineering easy; but I do find it makes some code much easier to test and reuse.

c_crank 3y ago

The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. A Haskell program covered in piles of monads to abstract all state away still follows the functional core imperative shell pattern, because the runtime is the imperative shell. This doesn't make such a thing desirable for other languages. The practical lesson I learned from dabbling with functional programming in academia is that functional programming is often impractical and does not offer any of the purported benefits of better code.

TuringTest 3y ago
Monads are just one design pattern for handling state, and not the only way. It's no different than having an OOP using dependency injection everywhere - it's a design decision that you use only when it makes architectural sense. A shell is not more imperative than a processor - both are Turing machines, a completely functional mathematical object. Seeing them as imperative is a semantic interpretation of the people watching it, not an inherent property.
- c_crank 3y ago
  Functional languages have either converged on either just allowing mutable values or relying on Monads as the ways of handling state. I'm not aware of a third solution.
  - TuringTest 3y ago
    You can just use the classic temporal logic approach, where state is passed explicitly as a parameter and the new state is returned. This is what state monads are doing anyway under a hidden syntax, and for simple cases it may be easier that building a full dedicated monad.
jabradoodle 3y ago
> The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. Most mainstream languages are old, they can't be immutable my default without breaking backwards compatibility. I'm talking about the design direction of languages that are already based on mutability. For example, Java added Records which are immutable, as well as overhauling the date/time api with an immutable version. > This doesn't make such a thing desirable for other languages. I've used this pattern in other languages, none of this is a silver bullet that makes software engineering easy; but I do find it makes some code much easier to test and reuse.