> programming languages are meant to ease the task of creating computer programs as opposed to writing assembly by hand
This! The haskell ecosystem is missing a certain kind of pragmatism. There's a lot of beautiful type abstractions, talking about monads, etc., but not enough builders doing actual application development. In my opinion it's not the language that is bad, but the ecosystem. Missing documentation, missing tooling and infrastructure, no focus on actually building applications.
We're trying to fix that with IHP, a new haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of haskell.
6 months after it's release it's already the second biggest haskell framework, and we just had a new record of weekly active users last week. To me this shows that by fixing the ecosystem haskell can reach a lot more than it's currently doing.
This indeed seems to be the main/only point of criticism in this post that is valid: however, it is not that Haskell has no "pragmatic" libraries to get stuff done (e.g. WAI/Warp, Yesod, Servant, ... are top notch, practical libraries if you are writing network/HTTP services). They do seem to drown in the sea of libraries/blog posts that are focused on the academic/abstract stuff. The end result does not feel consistent, and reminds me of the horrors we had with the early C++ metaprogramming efforts: it looks cool, but you end up fighting the language and produce unreadable code.
For Haskell to become a successful "industrial" language, I think most of the dependent-typing stuff should probably go (to Idris/Agda etc.), so that a clear and consistent Haskell subset can be defined.
The other arguments in the article are just weak. The rant about data not having a type, is missing the point. Sure, often you receive data that you need to inspect to know what it is. You can easily do this in Haskell (just label it with the UnknownData type), and have a function that inspects it and returns, depending on the contents, the right type). The big advantage is that you don't have to keep on doing this same check.
Types being the cause of difficulty in refactoring when business requirements change, is the opposite of my experience. In large dynamically typed codebases, being sure that a large refactor caught everything, is very hard / costly in test coverage. I have seen this go wrong many times. Having the compiler point out what you have missed, based on the types, is very helpful.
While I think the arguments are a bit weak, I do agree that it is at least unclear if Haskell is a sound choice as a production language at this time. Fighting against an ecosystem is not something you want to be doing while building your product. But in contrast to the author, I do think this is fixable, and see steps happening in the right direction (e.g. with IHP, but also with the efforts around the Haskell Foundation and the Haskell Language Server)
> but not enough builders doing actual application development.
It's simply because the community is small.
People compare Haskell to other languages like Java or JS like there's an equal amount of manpower, and therefore, if not everything has a library, it must be because haskellers are slacking on useless stuff. It is not.
Other small languages communities have exactly the same issues, it's not specific to haskell. The only thing that is specific is outsiders feeling entitled to an ecosystem and blaming "these damn fp ivory tower types" for not providing it.
No, it's really not. Haskell is a pain in the ass to program in. It's a language developed for mathematicians, not the real world. It makes the same mistakes as OpenCyc and expert systems.
I know assembly, C, C++, Scheme, Common Lisp, Python, MATLAB, C#, some D, some Javascript, some Mathematica. Programming in Haskell looks promising initially, but just drains all the joy and productivity out of my programming.
> [Haskell] just drains all the joy and productivity out of my programming.
It's fine that you don't like the language. I mean, not everyone has to enjoy a language. On the other hand, there's a difference between voicing an opinion, which is personal, and making claims like:
> Haskell is a pain in the ass to program in. It's a language developed for mathematicians, not the real world.
Because then, you are discarding other people's experience about the language, while you claim your own experience is relevant.
> > [Haskell] just drains all the joy and productivity out of my programming.
> It's fine that you don't like the language. I mean, not everyone has to enjoy a language. On the other hand, there's a difference between voicing an opinion, which is personal, and making claims like ...
Indeed. Different people find different things fun:
I don't think that quote is complete enough though. If you really believe that programming languages are just tools for building programs (in particular "useful" programs that make money) then yes, Haskell has not much to offer you over PHP or Ruby and other languages in that vein.
On the other hand if you are interested in research, exploring the extent of the design space for programming languages and what you can (or can't) express in them, then Haskell is an excellent language for you. Both for the community of like-minded researchers and for the flexibility of the language/compiler itself.
On a wider scale, I've always liked https://josephg.com/blog/3-tribes/ as an explanation for why this topic comes up again and again and again. The writer of the article is more of a "type 3" programmer. He wants to build a house but does not care much which tools he uses as long as they don't get in the way. It is the end result they are interested in, not the process. Haskell is, by design as a research language, more process oriented than result oriented. And yes, you can still get results with it as IHP and SC and Jane Street have shown. But they seem to be the exceptions that show the norm.
- You can change features of your product easier thanks to the type system. Doing a big refactoring with rails always adds many bugs. With haskell you spend less time on doing these kind of changes because the compiler tells you what needs to be changed.
> With haskell you spend less time on doing these kind of changes because the compiler tells you what needs to be changed.
This. I think what all the other folks in this thread that are just throwing shade on Haskell after struggling through a tutorial (admittedly, it can be pedagogically difficult to introduce concepts compared to Python or Ruby or JS, etc).
Perhaps Haskell will never beat C++ & friends (Rust, C, maybe Swift?) at performance, but what it will beat is the myriad other web apps written in Python and Ruby, which I bet a lot of folks on this site use. All that it lacks are the same levels of batteries-included frameworks like Django and Rails.
I can't even begin to mentally enumerate the number of times I've seen Python (and, much less often, Ruby) codebases at the places I've worked that were critical to the infrastructure (often having been the outgrowth of the initial POC that got the product started) that were mysterious Monoliths, which if you tried to change would be some Hydra situation: for every bug fixed, another 2 or 3 or 10 are created.
Perhaps if a team of really well-disciplined Python professionals can go 0-60 very quickly due to the language's flexibility, but it counts on that discipline being maintained going forward in the code, and training new hires or hiring only experts to work on the project.
Haskell is basically like encoding this discipline into the compiler itself. You don't have to spend time praying that your test suite is adequate (although tests are still needed) or picking over the minutiae of some pull request trying to remember all the things that the `|` operator may have been overloaded with from that "coding ninja" who decided to put esoteric things in your Python codebase did before he got poached by some other company and peaced out without documenting anything.
For all of the pitfalls that Haskell has from a language perspective (which can often be avoided by using an alternate prelude), the advantages when compared to other modern languages made for "moving fast and breaking things" are very prominent: I no longer have to wonder what the `data_object` parameter of my `update_callback_param_cache` method is supposed to be and waste minutes of my life desperately grepping through the code or, if possible, `pdb`ing my way through a live version and trying to trigger that code path.
Your example is live updating html in a browser, NOT live updating the type system. In other words, your evidence is trivial, unrelated to your main claim, and unconvincing.
> If you really believe that programming languages are just tools for building programs (in particular "useful" programs that make money) then yes, Haskell has not much to offer you over PHP or Ruby and other languages in that vein.
I'd agree with this generally. During grad school I loved hacking my research on haskell.
But this doesn't seem to be a consistent claim from the community. It'd be helpful if the core maintainers published this somewhere. Because I consistently get haskellers telling me that I'd be more productive as an engineer and my programs would have fewer errors if only I worked in Haskell.
Some other languages do have this sort of vision statement (or, at least a fairly well implied one) that makes it clear what they are offering and what they aren't. C++ wants to give you speed and flexibility without overhead for things you aren't using. That's been consistent for decades.
> Because I consistently get haskellers telling me that I'd be more productive as an engineer and my programs would have fewer errors if only I worked in Haskell.
i still think it's true
i have worked in haskell and i currently get paid to write more mainstream languages.
the mainstream languages are literal wastes of my time in comparison. not my money tho, so i'm fine with my employer paying me to waste time.
> programming languages are meant to ease the task of creating computer programs as opposed to writing assembly by hand.
is wrong: Assembly is certainly a programming language, which the author acknowledges when writing `writing assembly`.
As mentioned elsewhere, the whole blog post appears to be a troll post and should definitely not be taken as a part of a sober discussion on programming languages.
He should have written “as opposed to writing object code by hand,” because assembly does save some effort there. Some architectures were even designed around making assembly code more readable, rather than making it the compiler’s problem.
Not sure if you are the right person to talk to but there's a small mistake on the front page. Missing "language" in functional programming language (at least on my phone)
This! The haskell ecosystem is missing a certain kind of pragmatism. There's a lot of beautiful type abstractions, talking about monads, etc., but not enough builders doing actual application development. In my opinion it's not the language that is bad, but the ecosystem. Missing documentation, missing tooling and infrastructure, no focus on actually building applications.
We're trying to fix that with IHP, a new haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of haskell.
6 months after it's release it's already the second biggest haskell framework, and we just had a new record of weekly active users last week. To me this shows that by fixing the ecosystem haskell can reach a lot more than it's currently doing.
Check it out: https://ihp.digitallyinduced.com/ GitHub: https://github.com/digitallyinduced/ihp