5 ms·
Haskell is Useless (2011) [video]
- seanparsons 3y agoBeen posted a bunch of times in the past: https://hn.algolia.com/?q=haskell+useless https://hn.algolia.com/?q=haskell+useless
- dang 3y agoLooks like these are the only comments though, unless I missed something? Simon Peyton Jones – Haskell is useless [video] - https://news.ycombinator.com/item?id=23957953 https://news.ycombinator.com/item?id=23957953 - July 2020 (1 comment) Haskell People - https://news.ycombinator.com/item?id=15371448 https://news.ycombinator.com/item?id=15371448 - Sept 2017 (97 comments)
- refulgentis 3y agoI don't know what I'm supposed to take away from this. (beyond the well-established Haskell-esque effects bad)
- curryhoward 3y agoCitation needed on "well-established". I find myself often benefiting from Haskell's disciplined approach to effects.
- refulgentis 3y ago" (beyond the well-established Haskell-esque effects bad)" read that as: "beyond the well-established idea, from Haskell, that side effects are troublesome and need to be explicitly modelled and thought about."
- curryhoward 3y agoAh, I think your clarification makes a lot more sense than your original phrasing, because Haskell's position is indeed that side effects are bad, not that effects are bad. The bad thing is "side", not "effects".
- mrkeen 3y agoAnother possible takeaway is to start from something 'principled' (for whatever definition of principled you like) and then add functionality, rather than starting on shaky ground and trying to patch it up later. From memory the example in the video was 'pure functions first - then figure out IO'. But it could just as easily apply to memory safety, or nulls. Why build a new language with state-of-the-art static analysis for detecting nulls, when you could just refrain from putting nulls into your new language?
- tromp 3y agoAnd 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]. [1] https://www.ioccc.org/2012/tromp/hint.html https://www.ioccc.org/2012/tromp/hint.html
- boxfire 3y agoYou can run a friggin full 32 bit lisp on the untyped lambda calculus! https://woodrush.github.io/blog/lambdalisp.html https://woodrush.github.io/blog/lambdalisp.html
- dehrmann 3y agoFP 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.
- sodapopcan 3y ago> 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.
- tadfisher 3y agoThe 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.
- breadwinner 3y agoHis 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. [1] https://youtu.be/iSmkqocn0oQ?t=202 https://youtu.be/iSmkqocn0oQ?t=202
- ShamelessC 3y agoNo, 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”.
- chris_wot 3y agoNo, 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.
- ShamelessC 3y agoWhat you just said seems to be in agreement with what I said.
- chris_wot 3y agoYou stated that "side effects are an afterthought/discouraged" and I stated that "nowhere does he state that side effects are an afterthought or discouraged".
- hiddencost 3y agoI took a Haskell course in grad school from someone who contributed to Haskell. 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.
- golergka 3y agoWhy not? That's primary function of many research entities of various sorts in very different industries.
- richrichie 3y agoRust may not exist without Haskell!
- betaby 3y agoI don't see why not.
- curryhoward 3y agoFor one, Rust's "trait" system, which is a foundational part of the language that enables a lot of Rust's expressivity, is a limited imitation of Haskell's "type classes". Rust would be a very different language without it.
- _a_a_a_ 3y agoExactly what I understood, that Haskell was intentionally a language laboratory.
- int_19h 3y agoThat's why Microsoft keeps paying the bills. Designers of LINQ in C#, for example, mentioned Haskell more than once as one of their inspirations.
- louthy 3y ago> Designers of LINQ in C# Erik Meijer, he's in the video :)
- daxfohl 3y agoI 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.
- actionfromafar 3y agoAt some point you would need to see the results of the rules applied, thus, you'd need IO.
- curryhoward 3y agoThe 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. 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-with-haskell/ https://engineering.fb.com/2015/06/26/security/fighting-spam...
- daxfohl 3y agoLooks like it has become abandonware, or at least the component they open sourced. Oh well, such is life in the Haskell ecosystem. https://github.com/facebook/Haxl https://github.com/facebook/Haxl
- nextos 3y agoSimple 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.
- wubrr 3y ago> I still wonder why Haskell sans IO isn't a thing Isn't that just Haskell without the use of IO... ? Which is already a thing...
- behnamoh 3y agoAll— 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).
- jasode 3y agoFyi... The Youtube upload date is Dec 2011 but it was actually recorded circa July 2007 and originally posted on Microsoft's Channel9. A previous discussion from 2007: http://lambda-the-ultimate.org/node/2356 http://lambda-the-ultimate.org/node/2356
- Iceland_jack 3y agoIO 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)
- Iceland_jack 3y agoSee "Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" by Simon Peyton Jones https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...