11 ms·

In my opinion Haskell's capabilities to help implement general-purpose SW (services, compilers, GUI, game-dev, systems) are way over-hyped. Sure, it's nice to

In my opinion Haskell's capabilities to help implement general-purpose SW (services, compilers, GUI, game-dev, systems) are way over-hyped. Sure, it's nice to implement parsers/compilers in it (see ̶N̶̶̶i̶̶̶x̶̶̶, Elm, DHall) and it's to some extent popular for backend web development, but I don't think the strong static type system is such an advantage as advocates want you to believe. Of course it's safer (and faster) than dynamic languages like Python (Ruby, JavaScript), but in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go. In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. Furthermore it's still the case, that there's not much really interesting SW made in it. Some years ago you could argue, it's because of familiarity, but (static typed) functional programming is part of CS curricula for at least 10 to 20 years now. Lastly it's just incredible hard to estimate runtime characteristics (clock-time, memory usage), because you never know which compiler optimizations kick in or not. It's a nice language, but again, I don't think it's such a panacea as proponents often tell you. And to be snarky: If Haskell is such an advanced language to make implementing reliable SW such a breeze, it should be part (maybe as a dependency) of more SW. EDIT: Nix is implemented in C++ as correctly pointed out in a comment.

rowanG077 4y ago
I only agree with the runtime characteristics point. It's very hard to get an idea of what is efficient or not sometimes. But on every other point I believe Haskell is magnitudes better for general software development then mainstream languages.
- amelius 4y ago
  Perhaps the ideal language is then a combination of two approaches: Haskell in the outer loops, Rust in the inner loops?
  - marcosdumay 4y ago
    The Python code using C libraries you get on machine learning is a nice model. There is no reason why you can't recreate it with Haskell + Rust. But it has one drawback that it's relatively slow to pack stuff to send between languages. On Python everything is so slow that this doesn't make much of a difference, but on the Haskell + Rust scenario you will want much larger library blocks.
  - pyrale 4y ago
    You will lose the benefits of both type systems if you try to combine them. Rust doesn't really track effects, while Haskell doesn't care about memory.
- picozeta 4y ago
  That's my point (sry I edited my post, when you already replied). It's a good programming languages, but being "magnitudes better" is absolutely not true in my experience.
agumonkey 4y ago
I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. About the last point, my tiny observations is that language too advanced don't get used as dependencies.. they get ignored until the crowd matures enough to get the ideas in their own ways and pull a gene transfer. - lisp idioms (map, filter, destruct) => all dyn langs - react / vue .. basically let over lambda and closure based programming (I even believe vue provide/inject is near equal to dynamic variables) wait until someone there likes to thread state or rng seeds through 'chains of functions' and you'll see monads pop up
- armchairhacker 4y ago
  Haskell does have advanced tools though. Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Haskell’s LSP is making rapid progress and there are many formatters and linters. Tooling still has a way to go, but I don’t think that’s all. Haskell’s abstraction is just too much when you need to design something which is ultimately kind of straitforward, and most apps are (design app, game, utility app, web server, etc.) I do think Haskell is more than a research language, it does have some use in practical, mainstream programming. In particular, Haskell is great at anything which is “input to output”, like compilers or document converters. Or in a program which is ultimately complex, and not just for optimization but “math” complexity, like math programs or simulators. In those programs the implicit laziness actually comes in handy. But Haskell for a real-time video game or editor, and you’re just wrapping everything in an IO monad or some restricted stateful equivalent, and executing most of the instructions in sequence anyways.
  - tinco 4y ago
    Why would you wrap things in an IO monad for a real time video game? There's a whole lot of code you can do purely functionally in video games that can make it very nice. I've done a couple small projects in Blueprint which is a purely functional programming language embedded in UnrealEngine 4 and I enjoyed it a lot. Blueprint notably does not expose any type classes, at least not when I tried it a couple years ago, but it felt very expressive for building complex game logic.
sa46 4y ago
Dan Luu has a take on this: http://danluu.com/butler-lampson-1999/ http://danluu.com/butler-lampson-1999/
- picozeta 4y ago
  Thanks, interesting article.
- mastazi 4y ago
  Interesting take but I find the RISC argument to be completely flawed in light of ARM/M1. Even accepting the distinction (which I don't agree with) between "non RISC-y" ARM (v7 and earlier) and "RISC-y" (v8 and later), Apple M1 is "RISC-y" by that definition (instruction set ARMv8.5A)[1]. And it's doing well. [1] Line 256 https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/AArch64TargetParser.def#L256 https://github.com/llvm/llvm-project/blob/main/llvm/include/...
  - klelatti 4y ago
    It’s a really odd take given that by 2015 Apple was already on Arm v8 for the iPhone and the performance gains over v7 were clear. Calling it ‘hopeless’ seems incredibly wide of the mark.
  - astrange 4y ago
    ARMv8 is a well designed architecture that I don't think is "RISC" because eg it has some complex addressing modes, SIMD, and other good ideas. It is more RISC than ARMv7 was. And I think if it was targeting smaller CPUs with less wide decoders, being more x86-like ("CISC") and having variable length instructions would be better.
lopatin 4y ago
Thoughts and prayers to all the people whose heads just exploded by reading that Haskell doesn't gain you that much compared to Go. (I tend to agree)
sfvisser 4y ago
> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. I don’t see how this is true. These common abstraction make reading code incredibly easy most of the time. Many Haskell libraries are based on compositional building blocks. Seeing a monoid, functor or monad instance gets you 90% there in understanding the usage. It’s really the superpower of Haskell that I miss (and badly reimplement) in every other PL.
- feanaro 4y ago
  Completely agreed, but I guess this just doesn't click with some people as well as it did with me (empirically).
- smegma2 4y ago
  I was also wondering about this. I can't think of an example of a library implementing Functor in a surprising way, or in a way that somehow differs from another library.
  - ParetoOptimal 4y ago
    Exactly! And free theorems and polymorphism means even more things work as someone that understands the core abstractions would expect them to.
sidkshatriya 4y ago
> Sure, it's nice to implement parsers/compilers in it (see Nix, Elm, DHall) [...] Nix is implemented in C++, not Haskell
- picozeta 4y ago
  Oh, I thought it was Haskell. Thanks, fixed.
skavi 4y ago
> functional programming is part of CS curricula for at least 10 to 20 years now My school (UIUC) only just added a functional programming course to the CS course map in 2021. Of course you could always take a functional programming course if you wanted to, but not many do.
- lopatin 4y ago
  Interesting. I graduated a decade ago and remember taking CS421 where you implement part of an OCaml compiler in OCaml. I thought that it was required because I don't think I would have chosen it myself. It ended up being my favorite course in all of school.
  - skavi 4y ago
    That’s exactly what they added: https://grainger.illinois.edu/academics/undergraduate/majors-and-minors/ce-map-before-fa2021 https://grainger.illinois.edu/academics/undergraduate/majors...
rbn3 4y ago
>Furthermore it's still the case, that there's not much really interesting SW made in it. TidalCycles would like to have a word with you. Easily one of the most interesting and unusual pieces of SW that currently exists.
- eggy 4y ago
  I played with Tidal when it first came out for music. I do like it. To me though, I prefer Grace[1] (CM, Lisp) and Extempore[2] (Scheme, xtlang). You can work within the grammar of music, or you can program your own DSPs. Xtlang in Extempore is a pretty neat DSL created by Andrew Sorensen. To me Tidal was mainly rhythm-based. I am sure it has evolved since then, but it felt like a coding sequencer or pattern generator. I liked Sporth, (Soundpipe + Forth), but it appears something has occurred on the internets that I am not aware of. The repo is still here[3], but it is not being worked on any longer from what I have read there. If interesting and unusual is your thing for generative music, check out Orca[4]. That has eaten hours of my time far more than Tidal for me. [1] http://commonmusic.sourceforge.net/ http://commonmusic.sourceforge.net/ [2] https://extemporelang.github.io/ https://extemporelang.github.io/ [3] https://git.sr.ht/~pbatch/soundpipe https://git.sr.ht/~pbatch/soundpipe [4] https://100r.co/site/orca.html https://100r.co/site/orca.html
pyrale 4y ago
> In my opinion Haskell's capabilities to help implement general-purpose SW (services, compilers, GUI, game-dev, systems) are way over-hyped. Haskell usage in companies is currently niche at best. It's hard to know what you would consider reasonable use of the language if you believe it's currently overhyped. Maybe your idea of hype relies on conference talks or some other metric I don't get? > in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go. Rust is pretty similar to Haskell in terms of type system experience, the main difference being that, when you don't really care about how memory is used, Rust forces you to handle it. Any GC'd language will feel refreshing if you're annoyed by that. Aside from that, I don't challenge that Rust is a great language to program in. Java's usability is built on a fundamentally different model: it benefits from decades of investment in IDEs, and all professional java users I know use it extensively. While a haskeller will rely on types to perform refactoring, a java dev will refactor using the IDE, with an equivalent peace of mind. Java's typesystem is poor, but it doesn't really matter in users' development experience. I don't have much positive stuff to say about Go, and even less about its typesystem. You may find better advocates for this one. > Lastly it's just incredible hard to estimate runtime characteristics Most use cases don't care about that. You quoted Java earlier, a language in which most devs never ever really delve into runtime performance and simply let the runtime do its stuff. As it turns out, it's usually good enough. It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem. > If Haskell is such an advanced language to make implementing reliable SW such a breeze Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad?
- picozeta 4y ago
  > [...] Maybe your idea of hype relies on conference talks or some other metric I don't get? Yes, I'm referring to programmer circle related social networks (HN, r/programming, ...). > It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem. Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction. > Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad? Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations, but are likely to be underwhelmed if it does not solve their problems in a vastly superior way.
caconym_ 4y ago
In trying to figure out why Haskell hasn't been widely adopted, I think it's very hard to disentangle legitimate criticisms of the language (unpredictable performance, overcomplicated and bizarre APIs, etc.) from the simple fact that learning it with an imperative background is like starting from scratch, even for experienced programmers. This is true even if you look at the base language, without involving Template Haskell or any of the weird language extensions. Ultimately, asking programmers to relearn how to be programmers (or, more relevantly, asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language. To be clear, I learned Haskell for fun and got to what I'd consider an intermediate level of expertise. It was an incredibly enriching experience, and gave me a new perspective on programming in general. But it was hard, and the rabbit hole just keeps going---sure, you can juggle monads in your sleep, but are you proficient with the `lens` library? No? Well, I can recommend you a pile of textbooks that might help.
- anitil 4y ago
  This is where I'm at. I don't know if I'll ever get useful software out of it, but I really enjoy the mental challenge. I actually find it a bit of an ugly language to look at (backticks, hanging single quotes etc) but I like how it reveals the underlying structure of problems that I haven't been able too replicate in other languages. Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.
  - toastal 4y ago
    Hanging single quotation marks? You mean the ‘prime’ symbol? This comes up a lot in math to generate more variables that need a similar name—that’s why it ends up in Haskell and related languages. It’s not something weird. Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.
- y2bd 4y ago
  What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time. If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.
lmm 4y ago
> Of course it's safer (and faster) than dynamic languages like Python (Ruby, JavaScript), but in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go. 20 years ago you would've been saying C++. Rust is closer to the Haskell of 20 years ago than it is to most languages of 20 years ago. Hell, one could make a decent argument that Java 17 is closer to the Haskell of 20 years ago than it is to the Java of 20 years ago. Even Python is feeling the need to add types (and increasingly more people are using TypeScript rather than vanilla JavaScript), even Go is feeling the need to add generics... > In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. This is completely backwards IME. In most languages, every new framework comes with its own abstractions that you have to learn (whether that's, IDK, Spring Beans, ActiveRecord, React Hooks, ...). Haskell-like languages where there are a few standard meta-abstractions like Monad/Applicative/Functor make it an order of magnitude easier to pick up a new framework, because they mean core abstractions work the same in every framework. All that said, I do kind of agree with your conclusions, but I think that's more about the industry being dishonest about its priorities. IME Haskell really does deliver what it says: for less than twice the effort of something like Python, you can write software that approximately never has bugs, in the sense that it will always do what it was specified to do. But most of the industry doesn't actually care about getting rid of bugs; they'd rather have buggier software in less development time (and if that means more maintenance effort in the long term, well, who cares).
- ParetoOptimal 4y ago
  > Haskell-like languages where there are a few standard meta-abstractions like Monad/Applicative/Functor make it an order of magnitude easier to pick up a new framework, because they mean core abstractions work the same in every framework. Exactly! The abstractions are less leaky, more sound, and give this gift and feeling of universality, unrivaled composition, and cohesion.
bigDinosaur 4y ago
I still think Elm is a better example for reliable (web) software development. I've simply never had a similar experience in terms of the high amount of type safety enforced by the compiler. Interestingly I found I was much less fatigued after programming in it (and this applies for Haskell too) because the problems one has to solve aren't really stupid ones. (I don't recommend it for production only because it has been partially abandoned, it seems, but it if hadn't been and the community had kept growing it would have been awesome). I don't think your snarky section is that relevant, because it's hardly like the best technology wins. Software engineering has a bias towards either irrelevant nonsense to pad resumes or extreme conservatism.
- palerdot 4y ago
  > I don't recommend it for production only because it has been partially abandoned Why do you say that? Sure, there were some dramas around how the language/ecosystem should evolve and almost all external opinions are not considered. But again, you could argue that Elm is consistent because of this heavy handed approach to language design. I'm just wondering why you would consider it as `partially abandoned`.
  - bigDinosaur 4y ago
    Too many high profile community members basically saying that it's impossible to work with the core team on improvements, with no clear communication that there even is a core team left any more, and bugs in the standard library/compiler that haven't gone fixed despite being one line changes. Many, many pull requests with such fixes have gone ignored for 3+ years. No indication of any possibility for a superior FFI or at least a path forward for the evolution of the current one. The language itself is still mostly fine, so long as you don't run into its limitations. I still wouldn't recommend it going forward for the above reasons, though. Too many warning signs and contributor goodwill unnecessarily burnt. Evan is a perfectionist and clearly has no interest in developing a feature if he can't see the use case for it (his response to negative numbers in case..of expressions was a classic example). Personally I think it's all a bit of a shame, Elm is one of my favourite things ever in web development. I really, really wanted/want it or something similar to succeed in terms of major projects being written in it.
1vuio0pswjnm7 4y ago
What about pandoc. https://en.wikipedia.org/wiki/Pandoc https://en.wikipedia.org/wiki/Pandoc Author is not a "dev" nor a self-proclaimed "engineer". He has no computer science, maths, EE or physics degrees listed on his CV. He does list several languages. None are computer languages. He suggests the programs he has written may be "structured procrastination". http://johnmacfarlane.net/macfarlane-cv.html http://johnmacfarlane.net/macfarlane-cv.html https://www.johnmacfarlane.net/BayHac2014/ https://www.johnmacfarlane.net/BayHac2014/ https://usesthis.com/interviews/john.macfarlane/ https://usesthis.com/interviews/john.macfarlane/ I think Dhall looks interesting. Like MacFarlane, I am free to choose any language I find satisfying for procrastination purposes.
- ParetoOptimal 4y ago
  > Author is not a "dev" nor a self-proclaimed "engineer". He has no computer science, maths, EE or physics degrees listed on his CV. He does list several languages. To piggy-back on this I'm a professional Haskell programmer with no degree and my math education stopped at shaky pre-calculus.
whateveracct 4y ago
> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. This is the opposite of my experience as a professional of many years. Most Haskellers I know think that this thing you're complaining about is extremely helpful, actually. The fact that every library gives you shared instances for wildly different things makes them easier to use. If you give me an Applicative instance, I'll be able to use it in so many ways. It's a shared abstraction language. No other PL compares. At the end of the day, none of the languages you mention come close to being able build complicated programs out of smaller ones like Haskell can. It's all gunk, inherently. I use my brain to write all those languages in an exhausting way. I barely do hard thinking with Haskell ever. Whether it be gamedev, web services, parsers .. I thank god every day I don't have to live like a normal programmer. My mind would be so tired.
- ParetoOptimal 4y ago
  > I use my brain to write all those languages in an exhausting way. I barely do hard thinking with Haskell ever. Whether it be gamedev, web services, parsers .. I thank god every day I don't have to live like a normal programmer. My mind would be so tired. I feel this. On slower days where I manage to eek out good productivity I joke that Haskell is the secret weapon of dumb and lazy people that managed to somehow not be lazy learning Haskell.
  - whateveracct 4y ago
    I like it for side projects for the same reason. It feels like you're always making progress even when you can't find time or energy. I have made a lot of progress on my indie game while doing the dishes because Haskell is so easy to do in your subconscious.
mbrodersen 4y ago
I know Haskell quite well but never reach for it when programming. Languages like F# and ocaml gives me most of the benefits of functional programming without having to deal with the unpredictability of lazy evaluation and the 10 level deep pollution of a single IO call. Also, when it comes to leading edge type systems, Haskell is falling behind. Dependently Typed languages like Agda and Idris are way more interesting from an advanced type system point of view.
- ParetoOptimal 4y ago
  > Dependently Typed languages like Agda and Idris are way more interesting from an advanced type system point of view. Yeah, but with Haskell you have a usable healthy ecosystem for real world code now.
  - mbrodersen 4y ago
    Yep that is correct. Which is why I am using Agda/Idris to expand my mind and F# for real world applications since F# can use the full .NET ecosystem.
ParetoOptimal 4y ago
> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. Can you give one example of this?
ParetoOptimal 4y ago
> Lastly it's just incredible hard to estimate runtime characteristics (clock-time, memory usage), because you never know which compiler optimizations kick in or not. When you use it as a faster safer Python this almost never matters in the real world.
haspok 4y ago
I think people are missing the fact that Haskell was created for programming language research, and not for commercial purposes. It is somewhat of an accident that people started using it outside of its original domain. It was never meant for "general purpose SW".
- jose_zap 4y ago
  The motivation for Haskell included building large applications. It was not solely a research language, but the culmination of years of research in non strict functional languages: https://www.haskell.org/onlinereport/preface-jfp.html https://www.haskell.org/onlinereport/preface-jfp.html
cies 4y ago
> you don't gain that much if you compare it to something like Rust, Java or even Go. Some languages have no implicit nullabillity and proper sum-types and exhausivity checks. This is what the main benefits of Haskell come from IMHO. Langs like Rust, Elm, OCaml/Reason/ReScript and Kotlin (even TypeScript) to some extend have this. Go and Java dont have this, and I miss them every time I use these languages.
foxes 4y ago
>And to be snarky... Lol, that is not how things work at all. An idea can be better and still be a minority. The imperative mindset has a lot of momentum.
substation13 4y ago
The big wins from Haskell are immutability, pure functions by default, and expression-orientation... not the type-system, in my view. As to why it's not more popular? Well the entire industry caught OOP fever during Java's heyday, so platform holders pushed languages that were similar - see JavaScript, C#, Visual C++, etc... Now this paradigm has huge inertia, and smart software engineers are able to make it work (just about) anyway. In other words, an accident of history got us caught in a local minimum. Things are shifting though. The most popular framework in the world in probably React, and it's a (pretty crummy) implementation of functional programming concepts. It's not hard to find OOP thought-leaders advocating for immutability, effect systems and so on. Implementation inheritance is going the way of the singleton. I agree that Haskell in particular suffers from being lazy, which has genuine problems in practice.
- baq 4y ago
  > I agree that Haskell in particular suffers from being lazy, which has genuine problems in practice. - tooling is (used to be) bad - compiler is hostile to new users - even the simplest code is nigh undebuggable - gotchas like foldl vs foldr due to lazy evaluation
bitmapper 4y ago
I don't really think many people are calling it a panacea. From my experience in the community most people I know who write Haskell write it for productivity reasons (including me, I'd rather be using Idris 2 with algebraic effects though.) I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case. I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell. I use Haskell at my work for our main application, and we've been looking at adopting a style guide like https://kowainik.github.io/posts/2019-02-06-style-guide https://kowainik.github.io/posts/2019-02-06-style-guide And about interesting applications in Haskell, I'd consider https://hasura.io/ https://hasura.io/ pretty interesting! EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.
deleted 4y ago
[deleted]

rowanG077 4y ago

I only agree with the runtime characteristics point. It's very hard to get an idea of what is efficient or not sometimes. But on every other point I believe Haskell is magnitudes better for general software development then mainstream languages.

amelius 4y ago
Perhaps the ideal language is then a combination of two approaches: Haskell in the outer loops, Rust in the inner loops?
- marcosdumay 4y ago
  The Python code using C libraries you get on machine learning is a nice model. There is no reason why you can't recreate it with Haskell + Rust. But it has one drawback that it's relatively slow to pack stuff to send between languages. On Python everything is so slow that this doesn't make much of a difference, but on the Haskell + Rust scenario you will want much larger library blocks.
- pyrale 4y ago
  You will lose the benefits of both type systems if you try to combine them. Rust doesn't really track effects, while Haskell doesn't care about memory.
picozeta 4y ago
That's my point (sry I edited my post, when you already replied). It's a good programming languages, but being "magnitudes better" is absolutely not true in my experience.

agumonkey 4y ago

I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. About the last point, my tiny observations is that language too advanced don't get used as dependencies.. they get ignored until the crowd matures enough to get the ideas in their own ways and pull a gene transfer. - lisp idioms (map, filter, destruct) => all dyn langs - react / vue .. basically let over lambda and closure based programming (I even believe vue provide/inject is near equal to dynamic variables) wait until someone there likes to thread state or rng seeds through 'chains of functions' and you'll see monads pop up

armchairhacker 4y ago
Haskell does have advanced tools though. Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Haskell’s LSP is making rapid progress and there are many formatters and linters. Tooling still has a way to go, but I don’t think that’s all. Haskell’s abstraction is just too much when you need to design something which is ultimately kind of straitforward, and most apps are (design app, game, utility app, web server, etc.) I do think Haskell is more than a research language, it does have some use in practical, mainstream programming. In particular, Haskell is great at anything which is “input to output”, like compilers or document converters. Or in a program which is ultimately complex, and not just for optimization but “math” complexity, like math programs or simulators. In those programs the implicit laziness actually comes in handy. But Haskell for a real-time video game or editor, and you’re just wrapping everything in an IO monad or some restricted stateful equivalent, and executing most of the instructions in sequence anyways.
- tinco 4y ago
  Why would you wrap things in an IO monad for a real time video game? There's a whole lot of code you can do purely functionally in video games that can make it very nice. I've done a couple small projects in Blueprint which is a purely functional programming language embedded in UnrealEngine 4 and I enjoyed it a lot. Blueprint notably does not expose any type classes, at least not when I tried it a couple years ago, but it felt very expressive for building complex game logic.

sa46 4y ago

Dan Luu has a take on this: http://danluu.com/butler-lampson-1999/ http://danluu.com/butler-lampson-1999/

picozeta 4y ago
Thanks, interesting article.
mastazi 4y ago
Interesting take but I find the RISC argument to be completely flawed in light of ARM/M1. Even accepting the distinction (which I don't agree with) between "non RISC-y" ARM (v7 and earlier) and "RISC-y" (v8 and later), Apple M1 is "RISC-y" by that definition (instruction set ARMv8.5A)[1]. And it's doing well. [1] Line 256 https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/AArch64TargetParser.def#L256 https://github.com/llvm/llvm-project/blob/main/llvm/include/...
- klelatti 4y ago
  It’s a really odd take given that by 2015 Apple was already on Arm v8 for the iPhone and the performance gains over v7 were clear. Calling it ‘hopeless’ seems incredibly wide of the mark.
- astrange 4y ago
  ARMv8 is a well designed architecture that I don't think is "RISC" because eg it has some complex addressing modes, SIMD, and other good ideas. It is more RISC than ARMv7 was. And I think if it was targeting smaller CPUs with less wide decoders, being more x86-like ("CISC") and having variable length instructions would be better.

lopatin 4y ago

Thoughts and prayers to all the people whose heads just exploded by reading that Haskell doesn't gain you that much compared to Go. (I tend to agree)

sfvisser 4y ago

> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. I don’t see how this is true. These common abstraction make reading code incredibly easy most of the time. Many Haskell libraries are based on compositional building blocks. Seeing a monoid, functor or monad instance gets you 90% there in understanding the usage. It’s really the superpower of Haskell that I miss (and badly reimplement) in every other PL.

feanaro 4y ago
Completely agreed, but I guess this just doesn't click with some people as well as it did with me (empirically).
smegma2 4y ago
I was also wondering about this. I can't think of an example of a library implementing Functor in a surprising way, or in a way that somehow differs from another library.
- ParetoOptimal 4y ago
  Exactly! And free theorems and polymorphism means even more things work as someone that understands the core abstractions would expect them to.

sidkshatriya 4y ago

> Sure, it's nice to implement parsers/compilers in it (see Nix, Elm, DHall) [...] Nix is implemented in C++, not Haskell

picozeta 4y ago
Oh, I thought it was Haskell. Thanks, fixed.

skavi 4y ago

> functional programming is part of CS curricula for at least 10 to 20 years now My school (UIUC) only just added a functional programming course to the CS course map in 2021. Of course you could always take a functional programming course if you wanted to, but not many do.

lopatin 4y ago
Interesting. I graduated a decade ago and remember taking CS421 where you implement part of an OCaml compiler in OCaml. I thought that it was required because I don't think I would have chosen it myself. It ended up being my favorite course in all of school.
- skavi 4y ago
  That’s exactly what they added: https://grainger.illinois.edu/academics/undergraduate/majors-and-minors/ce-map-before-fa2021 https://grainger.illinois.edu/academics/undergraduate/majors...

rbn3 4y ago

>Furthermore it's still the case, that there's not much really interesting SW made in it. TidalCycles would like to have a word with you. Easily one of the most interesting and unusual pieces of SW that currently exists.

eggy 4y ago
I played with Tidal when it first came out for music. I do like it. To me though, I prefer Grace[1] (CM, Lisp) and Extempore[2] (Scheme, xtlang). You can work within the grammar of music, or you can program your own DSPs. Xtlang in Extempore is a pretty neat DSL created by Andrew Sorensen. To me Tidal was mainly rhythm-based. I am sure it has evolved since then, but it felt like a coding sequencer or pattern generator. I liked Sporth, (Soundpipe + Forth), but it appears something has occurred on the internets that I am not aware of. The repo is still here[3], but it is not being worked on any longer from what I have read there. If interesting and unusual is your thing for generative music, check out Orca[4]. That has eaten hours of my time far more than Tidal for me. [1] http://commonmusic.sourceforge.net/ http://commonmusic.sourceforge.net/ [2] https://extemporelang.github.io/ https://extemporelang.github.io/ [3] https://git.sr.ht/~pbatch/soundpipe https://git.sr.ht/~pbatch/soundpipe [4] https://100r.co/site/orca.html https://100r.co/site/orca.html

pyrale 4y ago

> In my opinion Haskell's capabilities to help implement general-purpose SW (services, compilers, GUI, game-dev, systems) are way over-hyped. Haskell usage in companies is currently niche at best. It's hard to know what you would consider reasonable use of the language if you believe it's currently overhyped. Maybe your idea of hype relies on conference talks or some other metric I don't get? > in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go. Rust is pretty similar to Haskell in terms of type system experience, the main difference being that, when you don't really care about how memory is used, Rust forces you to handle it. Any GC'd language will feel refreshing if you're annoyed by that. Aside from that, I don't challenge that Rust is a great language to program in. Java's usability is built on a fundamentally different model: it benefits from decades of investment in IDEs, and all professional java users I know use it extensively. While a haskeller will rely on types to perform refactoring, a java dev will refactor using the IDE, with an equivalent peace of mind. Java's typesystem is poor, but it doesn't really matter in users' development experience. I don't have much positive stuff to say about Go, and even less about its typesystem. You may find better advocates for this one. > Lastly it's just incredible hard to estimate runtime characteristics Most use cases don't care about that. You quoted Java earlier, a language in which most devs never ever really delve into runtime performance and simply let the runtime do its stuff. As it turns out, it's usually good enough. It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem. > If Haskell is such an advanced language to make implementing reliable SW such a breeze Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad?

picozeta 4y ago
> [...] Maybe your idea of hype relies on conference talks or some other metric I don't get? Yes, I'm referring to programmer circle related social networks (HN, r/programming, ...). > It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem. Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction. > Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad? Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations, but are likely to be underwhelmed if it does not solve their problems in a vastly superior way.

caconym_ 4y ago

In trying to figure out why Haskell hasn't been widely adopted, I think it's very hard to disentangle legitimate criticisms of the language (unpredictable performance, overcomplicated and bizarre APIs, etc.) from the simple fact that learning it with an imperative background is like starting from scratch, even for experienced programmers. This is true even if you look at the base language, without involving Template Haskell or any of the weird language extensions. Ultimately, asking programmers to relearn how to be programmers (or, more relevantly, asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language. To be clear, I learned Haskell for fun and got to what I'd consider an intermediate level of expertise. It was an incredibly enriching experience, and gave me a new perspective on programming in general. But it was hard, and the rabbit hole just keeps going---sure, you can juggle monads in your sleep, but are you proficient with the `lens` library? No? Well, I can recommend you a pile of textbooks that might help.

anitil 4y ago
This is where I'm at. I don't know if I'll ever get useful software out of it, but I really enjoy the mental challenge. I actually find it a bit of an ugly language to look at (backticks, hanging single quotes etc) but I like how it reveals the underlying structure of problems that I haven't been able too replicate in other languages. Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.
- toastal 4y ago
  Hanging single quotation marks? You mean the ‘prime’ symbol? This comes up a lot in math to generate more variables that need a similar name—that’s why it ends up in Haskell and related languages. It’s not something weird. Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.
y2bd 4y ago
What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time. If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.

lmm 4y ago

> Of course it's safer (and faster) than dynamic languages like Python (Ruby, JavaScript), but in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go. 20 years ago you would've been saying C++. Rust is closer to the Haskell of 20 years ago than it is to most languages of 20 years ago. Hell, one could make a decent argument that Java 17 is closer to the Haskell of 20 years ago than it is to the Java of 20 years ago. Even Python is feeling the need to add types (and increasingly more people are using TypeScript rather than vanilla JavaScript), even Go is feeling the need to add generics... > In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. This is completely backwards IME. In most languages, every new framework comes with its own abstractions that you have to learn (whether that's, IDK, Spring Beans, ActiveRecord, React Hooks, ...). Haskell-like languages where there are a few standard meta-abstractions like Monad/Applicative/Functor make it an order of magnitude easier to pick up a new framework, because they mean core abstractions work the same in every framework. All that said, I do kind of agree with your conclusions, but I think that's more about the industry being dishonest about its priorities. IME Haskell really does deliver what it says: for less than twice the effort of something like Python, you can write software that approximately never has bugs, in the sense that it will always do what it was specified to do. But most of the industry doesn't actually care about getting rid of bugs; they'd rather have buggier software in less development time (and if that means more maintenance effort in the long term, well, who cares).

ParetoOptimal 4y ago
> Haskell-like languages where there are a few standard meta-abstractions like Monad/Applicative/Functor make it an order of magnitude easier to pick up a new framework, because they mean core abstractions work the same in every framework. Exactly! The abstractions are less leaky, more sound, and give this gift and feeling of universality, unrivaled composition, and cohesion.

bigDinosaur 4y ago

I still think Elm is a better example for reliable (web) software development. I've simply never had a similar experience in terms of the high amount of type safety enforced by the compiler. Interestingly I found I was much less fatigued after programming in it (and this applies for Haskell too) because the problems one has to solve aren't really stupid ones. (I don't recommend it for production only because it has been partially abandoned, it seems, but it if hadn't been and the community had kept growing it would have been awesome). I don't think your snarky section is that relevant, because it's hardly like the best technology wins. Software engineering has a bias towards either irrelevant nonsense to pad resumes or extreme conservatism.

palerdot 4y ago
> I don't recommend it for production only because it has been partially abandoned Why do you say that? Sure, there were some dramas around how the language/ecosystem should evolve and almost all external opinions are not considered. But again, you could argue that Elm is consistent because of this heavy handed approach to language design. I'm just wondering why you would consider it as `partially abandoned`.
- bigDinosaur 4y ago
  Too many high profile community members basically saying that it's impossible to work with the core team on improvements, with no clear communication that there even is a core team left any more, and bugs in the standard library/compiler that haven't gone fixed despite being one line changes. Many, many pull requests with such fixes have gone ignored for 3+ years. No indication of any possibility for a superior FFI or at least a path forward for the evolution of the current one. The language itself is still mostly fine, so long as you don't run into its limitations. I still wouldn't recommend it going forward for the above reasons, though. Too many warning signs and contributor goodwill unnecessarily burnt. Evan is a perfectionist and clearly has no interest in developing a feature if he can't see the use case for it (his response to negative numbers in case..of expressions was a classic example). Personally I think it's all a bit of a shame, Elm is one of my favourite things ever in web development. I really, really wanted/want it or something similar to succeed in terms of major projects being written in it.

1vuio0pswjnm7 4y ago

What about pandoc. https://en.wikipedia.org/wiki/Pandoc https://en.wikipedia.org/wiki/Pandoc Author is not a "dev" nor a self-proclaimed "engineer". He has no computer science, maths, EE or physics degrees listed on his CV. He does list several languages. None are computer languages. He suggests the programs he has written may be "structured procrastination". http://johnmacfarlane.net/macfarlane-cv.html http://johnmacfarlane.net/macfarlane-cv.html https://www.johnmacfarlane.net/BayHac2014/ https://www.johnmacfarlane.net/BayHac2014/ https://usesthis.com/interviews/john.macfarlane/ https://usesthis.com/interviews/john.macfarlane/ I think Dhall looks interesting. Like MacFarlane, I am free to choose any language I find satisfying for procrastination purposes.

ParetoOptimal 4y ago
> Author is not a "dev" nor a self-proclaimed "engineer". He has no computer science, maths, EE or physics degrees listed on his CV. He does list several languages. To piggy-back on this I'm a professional Haskell programmer with no degree and my math education stopped at shaky pre-calculus.

whateveracct 4y ago

> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries. This is the opposite of my experience as a professional of many years. Most Haskellers I know think that this thing you're complaining about is extremely helpful, actually. The fact that every library gives you shared instances for wildly different things makes them easier to use. If you give me an Applicative instance, I'll be able to use it in so many ways. It's a shared abstraction language. No other PL compares. At the end of the day, none of the languages you mention come close to being able build complicated programs out of smaller ones like Haskell can. It's all gunk, inherently. I use my brain to write all those languages in an exhausting way. I barely do hard thinking with Haskell ever. Whether it be gamedev, web services, parsers .. I thank god every day I don't have to live like a normal programmer. My mind would be so tired.

ParetoOptimal 4y ago
> I use my brain to write all those languages in an exhausting way. I barely do hard thinking with Haskell ever. Whether it be gamedev, web services, parsers .. I thank god every day I don't have to live like a normal programmer. My mind would be so tired. I feel this. On slower days where I manage to eek out good productivity I joke that Haskell is the secret weapon of dumb and lazy people that managed to somehow not be lazy learning Haskell.
- whateveracct 4y ago
  I like it for side projects for the same reason. It feels like you're always making progress even when you can't find time or energy. I have made a lot of progress on my indie game while doing the dishes because Haskell is so easy to do in your subconscious.

mbrodersen 4y ago

I know Haskell quite well but never reach for it when programming. Languages like F# and ocaml gives me most of the benefits of functional programming without having to deal with the unpredictability of lazy evaluation and the 10 level deep pollution of a single IO call. Also, when it comes to leading edge type systems, Haskell is falling behind. Dependently Typed languages like Agda and Idris are way more interesting from an advanced type system point of view.

ParetoOptimal 4y ago
> Dependently Typed languages like Agda and Idris are way more interesting from an advanced type system point of view. Yeah, but with Haskell you have a usable healthy ecosystem for real world code now.
- mbrodersen 4y ago
  Yep that is correct. Which is why I am using Agda/Idris to expand my mind and F# for real world applications since F# can use the full .NET ecosystem.

ParetoOptimal 4y ago

> Lastly it's just incredible hard to estimate runtime characteristics (clock-time, memory usage), because you never know which compiler optimizations kick in or not. When you use it as a faster safer Python this almost never matters in the real world.

haspok 4y ago

I think people are missing the fact that Haskell was created for programming language research, and not for commercial purposes. It is somewhat of an accident that people started using it outside of its original domain. It was never meant for "general purpose SW".

jose_zap 4y ago
The motivation for Haskell included building large applications. It was not solely a research language, but the culmination of years of research in non strict functional languages: https://www.haskell.org/onlinereport/preface-jfp.html https://www.haskell.org/onlinereport/preface-jfp.html

cies 4y ago

> you don't gain that much if you compare it to something like Rust, Java or even Go. Some languages have no implicit nullabillity and proper sum-types and exhausivity checks. This is what the main benefits of Haskell come from IMHO. Langs like Rust, Elm, OCaml/Reason/ReScript and Kotlin (even TypeScript) to some extend have this. Go and Java dont have this, and I miss them every time I use these languages.

foxes 4y ago

>And to be snarky... Lol, that is not how things work at all. An idea can be better and still be a minority. The imperative mindset has a lot of momentum.

substation13 4y ago

The big wins from Haskell are immutability, pure functions by default, and expression-orientation... not the type-system, in my view. As to why it's not more popular? Well the entire industry caught OOP fever during Java's heyday, so platform holders pushed languages that were similar - see JavaScript, C#, Visual C++, etc... Now this paradigm has huge inertia, and smart software engineers are able to make it work (just about) anyway. In other words, an accident of history got us caught in a local minimum. Things are shifting though. The most popular framework in the world in probably React, and it's a (pretty crummy) implementation of functional programming concepts. It's not hard to find OOP thought-leaders advocating for immutability, effect systems and so on. Implementation inheritance is going the way of the singleton. I agree that Haskell in particular suffers from being lazy, which has genuine problems in practice.

baq 4y ago
> I agree that Haskell in particular suffers from being lazy, which has genuine problems in practice. - tooling is (used to be) bad - compiler is hostile to new users - even the simplest code is nigh undebuggable - gotchas like foldl vs foldr due to lazy evaluation

bitmapper 4y ago

I don't really think many people are calling it a panacea. From my experience in the community most people I know who write Haskell write it for productivity reasons (including me, I'd rather be using Idris 2 with algebraic effects though.) I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case. I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell. I use Haskell at my work for our main application, and we've been looking at adopting a style guide like https://kowainik.github.io/posts/2019-02-06-style-guide https://kowainik.github.io/posts/2019-02-06-style-guide And about interesting applications in Haskell, I'd consider https://hasura.io/ https://hasura.io/ pretty interesting! EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.

deleted 4y ago

[deleted]