His comment is being taken out of context. He is talking about Haskell before they figured out how to add effects. As he says [1], a program without effects is useless, as it doesn't do anything except make the computer hot. Then they figured out how to combine — in a single language — effectful computations, and effect-free ones, without making them pollute each other. The type-system keeps them apart. This makes Haskell useful. So in summary, he is not saying modern-day Haskell (which has effects) is useless.
No, he’s saying that it is a language closer on the spectrum to useless than useful- and that is because side effects are an afterthought/discouraged rather than a first class citizen.
The only potential for misunderstanding the headline is if you fail to see that it’s hyperbole. Otherwise I don’t see how it’s being taken “out of context”.
No, that's not what he's saying. The original post you are responding to is correct - he produces a quadrant that maps "usefulness" to "safety". Safety was dealt with by removing side effects. Nowhere does he state that side effects are an afterthought or discouraged, what he says is that they need to work out how to seperate code that produces side effects from code that has no side effects.
And of course, lambda calculus is even more useless.
But you can still make a nice universal machine that can run any computable function from stdin to stdout, by parsing a lambda term from the start of stdin, and applying it to the remainder [1].
FP is clearly useful for data transformations, and this is where you've seen it catch on in Python and even Java. Outside of that, for as theoretically elegant it is, the reality of using it for real-world, stateful systems is messier, and the fact that none of them have gotten any traction beyond hobby projects or one-off uses says something.
There’s plenty of real-world FP systems written in Scala.
In general, FP is not a problem today, because data mutation usually happens in some kind of external database, and the programs people have to write are just stateless transformations of incoming requests (http or other kinds, depending on the application).
> and the fact that none of them have gotten any traction beyond hobby projects or one-off uses says something.
What are you talking about? One of the world's most resilient systems was written in Erlang (the AXD301)... and was dynamically typed at that, lol. Not to mention WhatsApp, Discord, and others.
Based on a thread a few days ago, I think a lot of people who have never used FP before don't seem to realize that outside of Haskell, it's generally very easy to do state in functional languages. Also, they aren't constantly copying entire data structures every time you modify them which some people just refuse to believe for some reason.
The company I work for operates primarily with a monolith Haskell service. There are many companies that use Haskell, not least including Meta. The idea that FP isn't used in real-world projects is, at the very least, outdated; and, at the very worst, flat-out wrong.
IO distinguishes execution (of actions) from evaluation (of expressions).
To execute an `action :: IO Ty' for a value of `a :: Ty', you use <-
do (a :: Ty) <- (action :: IO Ty)
..
The 'function' rand is not really a function, but an action. It doesn't make sense to ask which int rand() evaluates to, and we can't equationally reason about rand() as an int. We cannot factor it from `rand() + rand()', or replace it with `2 * rand()' because it is not an int! Haskell is explicit about this, `rand :: IO Int' an action that produces an Int when (effectfully) executed.
The addition of actions doesn't make sense `rand + rand': Num-eric operations do not automatically lift over IO Int.[1] Instead we explicitly write `liftA2 (+) rand rand'. Shorthand for
do r1 <- rand
r2 <- rand
pure (r1 + r2)
where r{1,2} are Ints. The separation between evaluation and execution means we can factor rand out while still executing it twice.
do let r :: IO Int
r = rand
r1 <- r
r2 <- r
pure (r1 + r2)
This factors out the 'recipe', not the value it produces. To factor out the result of the IO-action, we just use a single bind/draw <-.
do r1 <- rand
pure (r1 + r1)
[1] This can be changed with Applicative lifting:
{-# Language DerivingVia #-}
deriving via Ap IO a
instance Num a => Num (IO a)
I still wonder why Haskell sans IO isn't a thing. Seems like it would be a really great way to define/implement rules for a rules engine that supported it. I guess you'd still have to worry about OOM or CPU thrashing, but in general it seems like it would be a very expressive language offering a secure sandbox and guaranteeing functional purity for such tasks.
Haha, that's exactly what I'm trying to avoid. We're looking at adopting openpolicyagent. Which frankly, a modern JSON-oriented datalog may be ideal. But this whole time I keep thinking, this would be so much easier in Haskell. Granted, the rest of my team would probably find it equally confusing. Maybe even moreso? IDK, it'd be an interesting experiment. If such a thing as Haskell-based policy agent existed.
Simple Haskell could be a thing, there have been some efforts in the community but none really crystalized. Frankly, I don't think the problem is so much difficult I/O, but rather too many language extensions, competing toolchains, and some missing libraries.
The suggestion is to use pure Haskell for the rules DSL only. The surrounding system that applies any side effects would presumably not be written in that language.
For those who may not know it: SPJ was employed at Microsoft Research for a long time. He recently moved to Epic Games, where he co-developed the Verse language.
Readit News
[1] https://youtu.be/iSmkqocn0oQ?t=202
The only potential for misunderstanding the headline is if you fail to see that it’s hyperbole. Otherwise I don’t see how it’s being taken “out of context”.
But you can still make a nice universal machine that can run any computable function from stdin to stdout, by parsing a lambda term from the start of stdin, and applying it to the remainder [1].
[1] https://www.ioccc.org/2012/tromp/hint.html
What are you talking about? One of the world's most resilient systems was written in Erlang (the AXD301)... and was dynamically typed at that, lol. Not to mention WhatsApp, Discord, and others.
Based on a thread a few days ago, I think a lot of people who have never used FP before don't seem to realize that outside of Haskell, it's generally very easy to do state in functional languages. Also, they aren't constantly copying entire data structures every time you modify them which some people just refuse to believe for some reason.
https://woodrush.github.io/blog/lambdalisp.html
Simon Peyton Jones – Haskell is useless [video] - https://news.ycombinator.com/item?id=23957953 - July 2020 (1 comment)
Haskell People - https://news.ycombinator.com/item?id=15371448 - Sept 2017 (97 comments)
A previous discussion from 2007: http://lambda-the-ultimate.org/node/2356
To execute an `action :: IO Ty' for a value of `a :: Ty', you use <-
The 'function' rand is not really a function, but an action. It doesn't make sense to ask which int rand() evaluates to, and we can't equationally reason about rand() as an int. We cannot factor it from `rand() + rand()', or replace it with `2 * rand()' because it is not an int! Haskell is explicit about this, `rand :: IO Int' an action that produces an Int when (effectfully) executed.The addition of actions doesn't make sense `rand + rand': Num-eric operations do not automatically lift over IO Int.[1] Instead we explicitly write `liftA2 (+) rand rand'. Shorthand for
where r{1,2} are Ints. The separation between evaluation and execution means we can factor rand out while still executing it twice. This factors out the 'recipe', not the value it produces. To factor out the result of the IO-action, we just use a single bind/draw <-. [1] This can be changed with Applicative lifting:https://www.microsoft.com/en-us/research/wp-content/uploads/...
There are more ways to implement rule engines and rules than to learn Haskell. One of them could be to use Prolog.
Isn't that just Haskell without the use of IO... ? Which is already a thing...
It's a good idea, and Facebook actually does something like this for their spam filtering rules: https://engineering.fb.com/2015/06/26/security/fighting-spam...
They made the claim that the primary function (lol) of Haskell was to discover new PL ideas which then got adopted by the major languages.
For those who may not know it: SPJ was employed at Microsoft Research for a long time. He recently moved to Epic Games, where he co-developed the Verse language.
Erik Meijer, he's in the video :)
I didn't editorialize the title. The original title I posted was "Simon Peyton Jones — Haskell is useless".
FYI: Simon is a major contributor to the design of the Haskell programming language and a lead developer of the Glasgow Haskell Compiler (GHC).