Simon Peyton Jones - Haskell is useless

I was particularly thinking about things like order and group in list comprehensions[1]. Turns out the paper introducing them was actually from 2007, so maybe it's not that recent :). (I thought it was newer than that.) [1]: [LINK] Here is a random video I found earlier where SPJ talks both about this in particular and the exchange of ideas between Haskell and .NET in general: [VIDEO]

I think Simon Peyton Jones says it best about Haskell : [VIDEO] He says Haskell is useless. Without even debating that (it can certainly be useful for certain classes of programming problems), you can see his point : The goal of Haskell was to start from an ideal view (pure functional programming without side effects) and try and see how to make that eventually practical for everyday programming, without sacrificing the pure core of the language . You have languages, like F# (or even C# !) that takes lessons from Haskell, with at the same time being practical for pretty much every programming task (their platform , .Net, makes them useless for a lot of use cases, but that is another problem) And on the other side (in my opinion), you have languages like Go, being pretty dismissive about pretty much everything learned from languages like Haskell. I respect the point of view of Go's creator, i just disagree with it, and don't see any project i could do in Go that i wouldn't prefer doing in Scala/OCaml/C#. But more power to people who want to do great things in Go ! Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list of languages i have listed, and OCaml is probably much more complicated to learn, even if it is way simpler than Haskell, so even if i don't agree with the design choices, i can see why Go could gain traction (apart from the fact that it is Google powered)

Sign. Yet another discussion full of trolling pros and cons of FP vs. OO Guys, listen to Simon Peyton Jones himself: "Haskell is useless". He's discussing stuff with Erik Meijer in this video: [VIDEO]

Disappointed that this wasn't actually a workshop for families. Cambridge used to use (still uses?) ML as a first language for CS undergrads, making its obscurity a strength (it is a new experience for most students). I see one of the abstracts talks about a "classless society" as a pun relating to object orientation. This makes me groan a bit, as there seems to be a general tendency in FP to make superficial quips, puns or observations like this while the community of FP programmers remains totally divorced from reality. A good example is the notorious video interview [VIDEO] in which Simon Peyton Jones laments the fact that pure functional programming languages just make the CPU heat up and nothing else (i.e. they have no useful side effects.) He probably wasn't being completely ingenuous but it comes across as a lack of self-awareness: FP is all about calculation and expressions, the program is an input and the value it evaluates to is the output... That's all you can expect. You need some other paradigm to "do" things, IO monads notwithstanding. Conan Elliot has a fun blog post on the c preprocessor which dances around this issue a bit: [LINK]

"A good example is the notorious video interview [VIDEO] in which Simon Peyton Jones laments the fact that pure functional programming languages just make the CPU heat up and nothing else (i.e. they have no useful side effects.)" You're not the first person I've seen that's misunderstood this video, I can only guess at why... One thing it's probably worth remembering is that Haskell has been a research platform for many years, and some of the Haskell features that people take for granted today did not exist in earlier versions. SPJ is not saying that Haskell is useless now, but it was close to useless for creating programs for a number of years. As a case in point, try to imagine Haskell without monads. Hopefully knowing that Haskell did not have monads at one point helps you understand the historical context of this discussion.

Simon Peyton Jones himself does not count Haskell among the “useful” languages (Simon Peyton Jones - Haskell is useless): [VIDEO]

Awesome! I assume you intentionally released this on a Friday just to eat up everyone's weekends :) Thanks for the hard work. As I dig in, I'm hoping that Rust will fit in the "useful and safe" sweet spot in Simon Peyton Jones's diagram here: [VIDEO]

>Maybe 'aninhumer has a point - restricting the language is kind of the opposite goal of making it expressive/powerful. My point was more that safety is a separate, important metric of language quality. It often conflicts with expressiveness, but not necessarily. See also SPJ's "Haskell is Useless" video: [VIDEO]

> .. role model .. And don't forget, the superior way to project confidence [1] in your 'precious'. [1]: [VIDEO]

I feel like the author didn't do this as a way to bash Clojure but to try and progress Common Lisp. Anecdotally, I remember Hickey saying something about a stagnation in the CL community, so if Clojure inspires cross-pollination of ideas then that's a good thing. For instance, Simon Peyton Jones describes [1] how they took the ideas around STM from 'unsafe' languages and put it into Haskell, developed it further, and then later the 'unsafe' languages took the Haskell innovations and put it back into their languages. Clojure isn't perfect, and Common Lisp isn't perfect, but hey, they're better than programming in assembly. We should be stoked about someone trying to innovate; why do these posts always turn into language wars? [1] [VIDEO] around 3:50, but the video is short so it's worth watching the whole thing.

Let's get this out of the way: Rust is great. Rust apologia like this article is not so great. > As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe. There's a bit of mental gymnastics going on here. The word "unsafe" is performing double duty, since it means "memory safety not guaranteed by the compiler" in Rust and it means something else entirely when you are talking about C++, since memory safety was never guaranteed by the compiler in the first place. The other problem with this statement is that linked lists in C or C++ aren’t really that hard to get right, in fact, they’re easy. Maybe you draw out a diagram on pen and paper before you write the code, but you’re unlikely to be facing segfaults. I admit I’m biased here, because I’ve been using Haskell for something like 15 years now, but I feel like the Haskell community acknowledges that Haskell’s type system gets in the way and prevents you from doing useful, interesting work, and that even a great library ecosystem isn’t enough to overcome this. That’s how safety generally works. It’s harder to write programs that do useful things, but in exchange, it’s also harder to write programs that behave unpredictably or do dangerous things. Because Rust and Haskell put you in such restrictive type systems, sometimes you have to break out to get real work done. Haskell’s pitch, in my mind, is, “Let’s make it easy to reason about side effects

I find this post a bit wordy but interesting. It notably points out well how the two approaches to deal with the state of a system, using versions or overwriting it, are in competition since a long time and in various domain of computer sciences. Alan also cites a paper about [Worlds: Controlling the Scope of Side Effects]( [LINK] ). A hot topic in the functional programming world. That paper makes me remember that ideas from FP and OO can mutually improve (an idea well developed in this short video [VIDEO] .

I did a little digging and even started reading "System design from provably correct constructs: the beginnings of true software engineering". From what I can see, it's mostly garbage used to sell the products of the HOS company. James Martin was on the board Higher Order Software, Inc. A company that despite claiming being able to provide "bug free software" went out of business. Here's Edsger Dijkstra debunking the books written about HOS. [LINK] An evaluation by the US Navy concluded. "the HOS literature tends to advertise their ideas and products more than making a contribution in substance to the field of Computer Science. The author recommends that USEIT not be used in the TRIDENT program or any program development at NSWC. Even for a high level system specification, USEIT is not seen as a good choice. A mathematical functional notation or a PROLOG-like notation appears better suited for that purpose. The examples in the Appendices of this report, especially Appendices C, D, and E, show that a LISP-style mathematical notation is more compact and normally easier to read than the control map notation of USEIT. On a more positive note, the author considers the functional approach to system development and programing very promising. Systems so conceived and programs so constructed are more amenable to analysis and therefore, in principle, more reliable and better manageable." [LINK] So are we just talking about functional programming when we say HOS? If so, the pros and con

At some point, you need to modify some state, otherwise your program/language is useless. And that's not me saying that, I am just quoting, or at least paraphrasing, Simon Peyton Jones: [VIDEO] And of course a lot of so-called "functional" programs just outsource their state management to some sort of relational database. And the people talking about their creation will praise the state-less-ness of their creation. Unironically. What can you do? ¯\_(ツ)_/¯ Anyway, more practically, the vast majority of workloads do not have computation as their primary function. They store, load and move data around. Computers, generally, don't compute. Much. For those workloads, a paradigm that tries to eliminate the very thing that the problem domain is about, and can only get it back by jumping through hoops, is arguably not ideal. [LINK]

> learning Haskell has changed the way I write code in any language I think that's the bottom line. The creator of Haskell confirmed and explained: [VIDEO]

Well F# obviosly never gained enough momentum and C# has to grow somewhere so why not in this direction. All "big" languages are gaining more and more functional and declarative features each version. I always remember this chat by Simon PJ, the "father" of Haskell about convergence of languages in features [VIDEO]

WTF is going on in this thread? How did we become so sensitive, Haskell has had a lot of criticisms here at HN, never saw any flags/downvotes. People argued vehemently but without any animosity. Maybe something to be learned here [VIDEO]

These are two issues, which a theoretically orthogonal but in practice not so much. These are known as soundness and completeness. A good talk on topic [1] Rust will reject a lot of sound programs, and that's a huge performance hit. You are hitting the incompleteness wall with multiple mutable borrowing, closures in structures are a huge source of pain as well. And usually the answer from the community is "use handlers instead of pointers", but this gives you, surprise surprise, manual resource management alike that in C, and the compiler won't help much. Of course this is all subjective but for me the ergonomics of Rust is far too bad. It's a good step in right direction along with ATS, but I really hope we could do better than this. [1] [VIDEO]

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. [1] [VIDEO]

That must of course be "Haskell is useless" [VIDEO] But apart from that, his enthusiasm can even make the mseemingly most boring topic interesting. I'd personally start either at "the story of Haskell" Escape from the Ivory Tower [LINK] Or something more recent, about Epic's Verse [LINK]