1–10 of 86 posts
But I wonder if this is mostly a matter of taste. In small programs, the end result of a Haskell program is the same as a Python program. Is there a threshold after which Haskell's purely functional paradigm shines the most?
Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the chaos tames you.
System w/ immutable data structures lose a factor of two or so in performance in some cases. FORTRAN programmers won’t accept them, distributed “big data” systems will spend a lot of time marshaling and unmarshaling data and won’t accept any slowdown in their parsing code. The same could be true for something like that SAT solver.
Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects. Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the ch…
So, I would say the advantage of a pure functional programming language is that it enforces and encourages writing pure code. You can still write in the style to some degree in python, but you don’t get all of the idioms language support to make functional programming really nice.
I notice a difference in my code when I write in a pure language.
There are some cases where you really want in place mutation— graph algorithms are good example—but for most other things, I feel like functional programming wins because of how you can think about your code, and less about code actually can or cannot do.
Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects. Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the ch…
You can unit test without mock objects because you're following functional patterns.
I consider taste a benefit, regardless of what your taste may be. There’s other things to weight, too, of course! But if the end result is that you enjoyed your time more than you would have if you were slinging Java, that’s not without merit.
Beware of the Turing tar-pit
in which everything is possible
but nothing of interest is easy.
-- Perlis:54
Haskell is syntactic sugar on top of the Von Neumann architecture (likewise Python, Rust, COBOL, Smalltalk, etc.)
The Von Neumann architecture is inherently stateful. Anything with volatile memory is.
Functional programming is an idiom, not a technology. To the degree functional programming is a technology, it is one for analog computers.
Good luck. My time has been wasted trying to be clever.
It does, IMO, give you less foot guns related to state though. While I still actually like other paradigms, functional programming really limits how clever you can be with state. You can only pass things around immutability via parameters (At least with Haskell specifically) instead of making a confusing taxonomy of objects with unique APIs, for example.