Simon Peyton Jones - Haskell is useless

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] [this video]

I think Simon Peyton Jones says it best about Haskell : [this 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)

"A good example is the notorious video interview [this 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.

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] [this 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 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: [this 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]

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 [this 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]