I am the person that would be the one most likely to adopt haskell in the company I work in. Now, I don't and I won't even though I used it for several pet projects and I would say have learned a lot of haskell and associated patterns.
It's not that haskell doesn't have merits. However I feel like they are oversold. While you can build programs that lack certain error classes, they are not bug free and at the same time debugging often was a lot harder than in other languages. The laziness is especially problematic in that regard.
Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth.
Another important problem is the docs. For some reasons they hardly contain examples. You don't get adoption that way. Even if the maintainers feel that the type signatures are documentation enough.
And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process.
Although I think the post is very clear describing the reasons why Haskell isn't attractive in business, this part rubbed me the wrong way:
> Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”).
Thinking about readability or usability as emotions and social factors, rather than as first level concerns, is a non starter to me, and I find it extremely off putting that the author seems to pile up those qualities in the marketing "group", as if they were not real properties of a language.
You can design a drill in a way that makes it the most scientifically correct at using the power it's supplied efficiently, but if the design hurts the users hands and requires months of training to operate, any worker will throw it in the trash, because they can drill things just fine with a regular tool.
(I'm not necessarily saying that Haskell is that drill, just saying that usability should never be treated with condescension when you're designing tools).
The thing is that, at least in my experience, "feels readable" is indeed emotional territory. More specifically people relate favourably to things they are comfortable with and most programmers are comfortable with ALGOL/C syntax. Show them something unfamiliar, eg. Haskell, and they will say it's weird and unreadable. That statement is usually not based on careful assessment, it's a gut reaction.
I think what they're getting at in writing about how people are not given the right frameworks to reason about a tool's usability they're saying that people might say something "feels readable" without knowing whether it's actually easier for them to parse. Similarly for other statements. Someone might say a tool "feels fast" without actually knowing if it's faster for their problem domain than another viable tool. An analogy in the art world is that drawing lines which imply motion behind a character might make them "feel faster" but are they actually moving at all?
I took his point to be that things like "feels readable" and "feels fast" and to do with feelings rather than actual quantifiable things that could reasonably be compared between languages.
So it isn't that those things aren't important; just that they are subjective
We dance around this issue in the comments to every Haskell story, but the reason Haskell is hard to market is that it's bad. It's a research language being shoehorned into production by a few people who really love it. Some details of this have been given in this thread; let me suggest the following threads for more:
Yes, the Haskell community hates that guy and considers him a troll. But he does functional programming professionally as part of a private consultancy and wrote a book on OCaml. If anyone's equipped to understand what's wrong with Haskell, it's him.
Haskell has had 30 years to get its act together. Any benefits it has are drowned out by a sea of buggy tooling and accidental complexity (monads, etc.).
Ask yourself this: if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?
> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?
The young economist looks down and sees a $20 bill on the street and says, “Hey, look a twenty-dollar bill!”
Without even looking, his older and wiser colleague replies, “Nonsense. If there had been a twenty-dollar lying on the street, someone would have already picked it up by now.”
Industry makes collective bad engineering decisions all the time, usually driven by secondary factors like institutional momentum or hiring constraints. Did you read the article? It talked about a bunch of things like that.
If you equate market cap with quality, then Java is probably the best language of all time.
> wrote a book on OCaml
I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. OCaml is nice compared to most crap, but as someone who’s spent years working with both, Haskell wins almost every time.
It’s interesting, actually - I don’t know anyone who’s used Haskell and doesn’t like it. Almost everyone who vocally complains about it hasn’t really used it.
Reading that guy’s reddit posts, I have to conclude he’s some kind of troll - most of the things he criticizes Haskell for are way worse in OCaml, or just completely disconnected from reality.
> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?
Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc.
However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws.
We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.
Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.
I read those two links. If I ignore some of the points that were valid 10 years ago but not anymore (e.g., there's now stack), and if I ignore some of the personal anecdotes, I come away feeling like much of what is said is not necessarily wrong but is nevertheless an exceptionally negative take. I think you can make almost any tool sound broken and unusable if you use nasty enough and strong enough language about a few examples.
Also, there really is very little substance behind the actual language criticism. It's hard to make a blanket statement that typeclasses are "overkill"; they seem to be showing up all over the place in new languages. Similarly, type annotations are incredibly useful and are also showing up all over the place these days outside of Haskell-land. The point on non-strict evaluation is by far the strongest and most legitimate.
jdh30, the author of both comments, is a massive OCaml fanboy and Haskell hater. I've seen him try to take Haskell performance numbers and interpret them using the wrong units to make them look worse. I'd take anything that he says about Haskell with a big, big grain of salt!
With respect to availability of talent pool: my alma mater used to teach Haskell as the introductory programming language, and from what I’ve heard from people who were around then it was great for faculty and students. However, a very large corporate donor pressured the university to switch to Java in the early 2000s, because that’s what they used internally and they wanted a large local supply of pre-trained fungible labor. Now only a small fraction of the top students who study advanced topics in PL or compilers or what-have-you will come out of the university knowing how to use Haskell. I think this is deeply unfortunate - if society could quantum tunnel through to the point where Haskell was the safe, readily hireable corporate choice, the state of software (especially corporate software) would be a lot better off.
CS programs for undergraduate majors have a real dilemma. What programming language should they teach their students. My own kids are studying CS in college so I've seen the curriculums for a number of universities, and I've spoken to the faculty responsible for the language choices at some top programs. To me, there isn't an obvious best programming language to study as an undergraduate.
Some schools have a bifurcated curriculum, like Indiana University which has a program in Informatics for those planning to go into a career the requires programming and software engineering skills and a program in CS for those perhaps planning on going into grad school. There, learning Haskell might make sense in the CS program, but does it make sense for other students that want to get out and get a job?
My own daughter studied at a school where her first CS class was taught in Scheme (Racket). It, to me, looked like an excellent introduction to programming for someone majoring in CS. They used a book I approved of, How to Design Programs/2ed by Felleisen, et. al. Would Haskell have been better? Maybe, but I predict that more kids would have serious problems with a language like Haskell that is burdened with more challenging concepts and ecosystem. Perhaps Lisp/Scheme is a gentler introduction to applicative programming than Haskell. However most schools start with Python or Java.
I understand the arguments for a strongly typed functional programming language like Haskell (my own university research was in program verification many years ago).
Early on in CS programs students usually take one or two classes on data structures and algorithms. Data structures in my opinion needs to be taught in C. Haskell, Lisp/Scheme, Python, Java, and even modern C++ are so high level that teaching data structures in these languages ends up with students not learning the proper use of these languages' standard libraries.
At some point undergraduates should have an introduction to systems programming, the best text in this area is Computer Systems: A Programmer's Perspective/2ed by Randal E. Bryant and David R. O'Hallaron. This is a great book for undergraduate CS majors. This book requires C programming. So to me, it makes sense to teach data structures in C since students will need to understand it for their first exposure to systems programming.
Where should Python fit in the curriculum? It's arguably the most versatile programming language. What about Javascript? When should CS majors be exposed to it. Modern Java is a big language so one semester of use isn't going to be enough and it's too important to ignore. What about C++? It takes years of working with it to become a good but not expert programmer in C++. Should it be a part of the curriculum?
So my own recommendations for an undergrad CS program's language choices would be:
* Python -- for intro to programming, a course on algorithms, and a machine learning course
* C -- for an early class on data structures and a later class on systems programming
* Java -- software engineering, and a compiler course
* Lisp -- programming languages smorgasbord course, and an AI course
* Javascript -- taught as part of a web-applications class
* Haskell or OCaml (or maybe Rust) -- intro to functional programming and program verification
What do HN readers think about this list? I'm glad I don't have to make the real decisions there are just too many languages that students need to learn in just a few years.
As far are my own background I have spent a great deal of time pursuing three different degrees from three different universities in CS. I've been the instructor for university courses for CS majors twice and taught perhaps 40 week long classes to professional programmers within a Fortune 500 company. I've also interviewed and hired many senior developers for my own company.
If your alma mater is what I'm thinking of (UT Austin) I can maybe share some insight on the current situation. The introductory courses are all still taught in Java and the lower-division systems courses are taught in C. From what I know about the curriculum it is entirely possible for a student to go their entire undergraduate career without expanding from these two languages (maybe they'll need Python for a class or two). This past semester I took our PL course which was taught in Haskell. I thought it was an interesting course and strengthened my base in FP (my high school taught CS courses in Racket where I started my foundation). However this was not a large class and from discussion with peers there is generally little interest in learning "esoteric" languages such as Haskell.
One of the best ways to get adoption is to have people take initial risks and build real world serious product with a serious team/company backing behind it.
Erlang got a big boost when it came out WhatsApp scaled it up with a billion users, with tiny team and only a few servers.
React/React Native got boosted by Instagram adopting it to build their production mobile app.
Rails had 37signals/Basecamp and Github/Shopify/early Twitter/etc.
Haskell needs some more famous commercial "killer-app" examples for real businesses and real teams. And yes I'm very familiar with the current selection of popular Haskell examples.
Currently I only ever hear Haskell (and Ocaml for that matter) being used by engineers for backend engineery things (parsing programming languages, fighting spam, tooling) mostly for OSS tools.
On a positive note, PureScript is trying to position itself as a practical Haskell and making a bit of success. One helpful reason is they have a nice app/company leading the way as a production app with Lumi [1], with their founder playing a key role on the language/ecosystem dev side as well: https://www.lumi.dev/blog/purescript-and-haskell-at-lumi
This is what Haskell needs more of - and critical a company promoting/blogging about their progress using Haskell as well as contributing back into the community.
Another big one is simply a sort of 'starter kit' which guides you with best practices on how to architect a serious Haskell app (ie, using STM, free, etc). React has plenty of starter kits. For Rust CLI apps there is a great starter kit https://github.com/iqlusioninc/abscissa
I'd love to see a similar starting point micro-framework for starting a new Haskell app that makes a bunch of importation decisions for you and guides the structure of the project.
Anyone using Haskell to drive their business is making a huge mistake in my experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has centered around whatever the latest version of GHC is, with its millions of language extensions and breaking the world with changes like https://gitlab.haskell.org/ghc/ghc/issues/10365 and https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of.... Which is fine if you're doing research or building tools for fun! But it makes an absolutely awful industrial experience when you want to ship features and not get stuck on a bit rotted version of GHC.
edit: It's unfortunate that people are downvoting me for offering my experience, especially on a post that wants to make Haskell more attractive to being used in the industry.
The idea of "marketing Haskell" to me is akin to marketing math and mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it is succinct. Yes, the benefits of its algebraic type system are many and very real -- if your code compiles, it is correct in many important ways. No one can argue with any of that.
But... most people who look into Haskell lose steam as soon as they realize they actually must understand and be able to reason about functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. It's a shame.
> The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Moreover, if you throw enough bodies writing Java at a project for a long-enough period of time, it will produce a result or fail with a fairly predictable set of cashflows, which is itself a low quantifiable risk that’s very easy for a business to plan for.
This is a very MBA-like lens through which to examine software development. It's not wrong, but it's also a recipe for mediocrity, which is a great way to damage your culture and sit around wondering why you can never get ahead of your competition.
The deeper question is why is software quality only loosely correlated, if at all, with business outcomes?
The pessimists will point to Equifax et. al. and tell you that the market simply doesn't care, that businesses can go through downtime after leak after catastrophic failure and their stock will never take a hit. And there's some truth to that. The end consumer actually doesn't really care about the bad news. There's not much that any company in the business can do about that.
But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. The value of correctness isn't in the two months after you begin, it's in the two months after your latest release five years from now. It requires vision, patience, already-available human capital, and leadership to realize the benefits.
> If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter.
If you give your talent the opportunity to work on a Haskell project and they're walking out the door when it's difficult to find Haskell work to begin with, then you, the manager, failed in deciding which talent to hire. If you're looking for a support contract to hedge against the loss of in-house talent, then you've already failed. If you think that legal solutions will protect you against market failure, then you've already failed. Haskell isn't trying to market to these people in the first place, why should it start?
codebase organization was nonintuitive and I blame type-level programming
compilation was so slow and bad that other programs on my laptop started to die
the feature I was adding was something that would be library-provided in a normal web language
none of the operators have names and are very hard to google; I had to search for things like 'haskell tilde asterisk arrow'. Impossible to know what's from libs vs core language. Lots of explanatory docs online were like 'oh we don't pronounce this one'.
Core abstractions have no definition ('to explain that I would have to explain monads but you won't understand monads so GFY'). Monads are just sub rosa dependency injection .
lang doesn't protect you from runtime crashes but does apparently protect you from knowing where the program crashed
This is a very lucid piece on PL adoption in general. When I think about programming languages, I do think rather emotionally (which is fine, emotions are early warning systems).
I liked the linked author's points about the pre-requisites for marketing a solution:
It is memorable
It includes a key benefit
It differentiates
It imparts positivity
When I think about the most popular languages, they do have all of these:
Rust:
Memorable: very. It's basically everywhere you look
Has a key benefit: going C++ fast without the C++ footguns, memory-safe, WASM integration
Differentiates: Using Rust is definitely choosing a particular set of technical tradeoffs
Imparts positivity: the community is known to be welcoming, feels cool, cute crab. People re-write existing software in Rust just because it feels good!
Yet Haskell has almost none of these:
Memorable: I mean, yeah, but it's not being shown to people, and I can't point to a bunch of software. Tools I know of include PostgREST, Hasura, Nix, hledger, which is better than nothing.
Key benefit: Hand waving about "being more correct", unlike Rust which has reams of "Microsoft claims 60% of its bugs are memory-errors" articles, and in any case TFA's point is that this needs to be a different message because correctness isn't gonna sell it.
Differentiates: This is definitely true, almost too much
Imparts positivity: Not really feeling this one with Haskell. People feel good when they figure out a monad is a container & a lens is a path through a data structure, but attempts to explain to others these things feel condescending. Does Haskell even have an animal mascot? (serious question.) Also "stumps" a lot of people and people feel bad about it. There's no "import antigravity" equivalent feeling with Haskell.
This sounds pretty sombre for Haskell, though it's been an academic language a long time, and could probably stay alive that way.
One positioning possibility is maybe with the Frontend dev world becoming more and more functional and pure-oriented, positioning itself like reasonML, as a way to write and reason about declarative pure UIs. But I don't think the existing Haskell community cares too much about that world.
Idk, I'm going to just keep writing Rust and JS, the already most loved and popular languages.
I love haskell. What I love about it is the type system and pureness. In python, I loathe refactoring because of how fragile it often is. I hate finding out that I misunderstood what to even pass a function. I want the what haskell brings to those issues. I hate how hard haskell is to debug and how incredibly hard performance is to reason about. I want what python (or another imperative language) brings to those issues. I wonder if haskell had been strict by default rather than lazy by default, if its adoption would be different today.
There are certainly pieces of haskell that would make all our lives easier, and I can't wait for them to make their way into mainstream industry work one way or another.
The author of the article has an interesting contact page:
"To contact me via email run one of the following scripts to generate my contact information. I find this is an effective filter against the deluge of emails from recruiters."
The "scripts" are offered in Haskell, x86-64 Assembly and Python. Solution is pretty obvious though, no need to run them actually.
"The hard economic truth for engineers is that technical excellence is overwhelmingly irrelevant"
No. Technical excellence matters a lot when used appropriately, but competing with javascript and python is not where haskell is going to win.
There IS a language with HUGE success that is: declarative, strongly typed with type inference, lazy, and no side effects. It's called SQL[1].
That's where Haskell could shine -- compared with SQL. Imagine Maybe rather than NULLs, a sane language, multiple returns, a much better type system, etc. Python and Java can't touch SQL, but haskell could.
Ask any marketer — it's (almost) never the marketing. Or, rather, it's never the marketing of the "hype and subterfuge" kind. No product dominates the market for decades due to hype and subterfuge, let alone hype and subterfuge deployed decades earlier. It's always the product. It's just that what matters about the product to most people is often not what matters to some minority that insists that “technical excellence” is defined by their own preferences. In the famous VHS vs. Betamax war, the technically superior product won, it’s just that it was superior in matters that appealed to many and inferior in matters that appealed to few. The few famous cases where it was the marketing (diamond rings, maybe?) stick in our mind because they're the exception, not the rule. Blaming marketing problems is often an excuse to overlook product problems.
Second, the problem with the message of "code written in Haskell is more correct than code written in other [more popular] languages," isn't that the industry doesn't care about correctness. Correctness translates to cost (to a degree), and the ability to write software as correct as it needs to be more cheaply is actually quite compelling. Rather, the problem with it is that it's simply not true (or, rather, hasn't been shown to be true), certainly not to any degree big enough to matter. That, in and of itself, does not make it a terrible message; after all it's just harmless hype, right? What makes it a terrible message is that it is very clearly not (shown to be) true and yet some Haskellers seem to actually believe it, drunk on their own kool-aid, which makes you think of them as out of touch with reality. At best, it's an emotion (it "feels" more correct), which you've mocked, rather than any sort of "critical thinking," that you present as the desirable standard.
Third, the mistake in the perception of the economics of software is not the importance of correctness — that can have an easily measurable impact. It's in the importance of code. Programmers in general, but Haskellers in particular, are obsessed with code. As a result, they grossly overestimate its importance to software. Ask yourself how long it takes you to produce, say, 1000 lines of code of sufficient quality, and then look at a software produced at your company and divide the size of the codebase by the number you came up with. You'll find that the true cost is several times that. The "pure" cost of producing code is not where most of the cost of developing software is. Maybe it's in what you mockingly call "emotions", but it certainly isn't in programming-language semantics. Also, before presenting managers' priorities, it's better to actually speak to actual managers; they just might have some useful insight here, plus, it's what a culture of technical excellence demands, no?
All of that means that unless your language has some clear and direct effect on the bottom line — which, these days, usually means it has good performance and/or observability, a good ecosystem, or a monopoly of sorts on some distribution platform -- there is no "message" that can make it popular, other than "it's easy and it's fun." While perhaps not a sufficient requirement for success, this can create a supply of qualified developers that at least won't put your language at a disadvantage.
And here's another tip: if your retrospective introspection isn't painful, doesn't discuss any serious and conspicuous flaws with the product, and still paints you as being somehow right after all and everyone else as being somehow wrong — it's probably not true. Worse, it seems untrue. And not calling your own practice one of "engineering excellence" and others' as "throwing enough bodies" can't hurt, either. In other words, I don't know what a good marketing message for Haskell would be, but this post is a good example of a bad one.
> All of that means that unless your language has some clear and direct effect on the bottom line — which, these days, usually means it has good performance and/or observability, a good ecosystem, or a monopoly of sorts on some distribution platform -- there is no "message" that can make it popular, other than "it's easy and it's fun." While perhaps not a sufficient requirement for success, this can create a supply of qualified developers that at least won't put your language at a disadvantage.
I think this approaches the heart of the problem. Whatever the advantages of haskell may be, the disadvantages run extremely deep. Haskell is notoriously difficult to debug and optimize (both memory and cpu usage). It is interesting and influential, but trying to abstract away the order of operations as a core of the language just didn't pan out. All of that is before issues of IDEs, libraries, compilation times etc. It has been around for 30 years, at some point it needs to be called a worthwhile experiment so people can move on from clenching their fists that no one else is as clever as they are.
The more I think about it, my ideal language would be the exact opposite. Something extremely clear and straight forward with minimal complexity and maximum infrastructure.
This is a slightly loaded question, but is a Haskell codebase harder to work on than one in a reasonable non-functional language?
Maybe it's because the bugs are generally less common and easier to fix, but when I look at Haskell codebases it seems like it's quite difficult to achieve the same level of "separation" one would in (say) Java - i.e. an average Haskell file seems to purely consist of many loose free functions (often with very short names!).
I might be missing the point but the aforementioned always pushed me away from Haskell - great language, but seems to have legibility as an afterthought (as opposed to python, which is an awful language, does manage to enforce some sort of legible coding style)
In my experience, even bad Haskell codebases are easier to work with than mainstream language ones. Once I got over the learning curve, I barely think very hard when programming Haskell. It's all mechanical.
For this reason, I find code style to not affect me in Haskell. I've seen a bunch of different styles and I'm never taken aback. The code is all simple & mechanical to reason about.
I've been able to refactor other people's "bad code" without much effort too. This is after others have said the code is bad and unfixable. It just takes a good attitude and the same mechanical approach as always.
At the end of the day, I think a lot more about the business problem in Haskell than other languages. I hate having to think about code & simulate a computer in my head. But if you wish to use other languages and pay me to think like a computer, feel free! It's your money.
You can think of modules as Java classes and get the same sort of code separation fwiw.
I've found it to be easy to work personally, if you want long names of functions in your code if it helps you should. Common libraries might not have long names for functions, but you'll find the same thing for the most part if you look at the API of collections in various languages for example.
Oddly now I find it really legible compared to other languages, you can still make things obtuse if you really want to, but the flow seems so much clearer.
I would say compared to Java (as you mentioned it) there's much less separation because things invariably gravitate towards big balls of mud containing lots of state. But in Haskell the function you're looking at is only tied to the functions and data types it uses, no more, no less.
Yes, you are missing the point. It is very common for people to miss it when they only have experience in OOP, and very hard to adjust to the required paradigm.
Good Haskell code is not organized the same way as good OO code. While in OO you will have separated instances that take complete care of different business concerns, in Haskell you will abstract the care into different parts, and integrate the business concerns into a few instances that take complete care of them.
I’d suspect the difficulty comes from the paradigm shift.
I’ve personally switch code to functional style and it has simplified and reduced code for me. Granted if you don’t know how monads work it could be very confusing.
What about tooling? Haskell being such a powerful language would take off a lot more if there was a very hand-holding, Jetbrains-like IDE that gave you everything you needed and pointed out the problems in your code in real time. Or at least that's what I think, having never worked with haskell in a professional capacity. What are some day to day devtool stacks like in real companies?
I made the decision to stop using Haskell for things I consider "professional" use a couple years ago. No matter how much I love the idea of the language, there's a couple superficial things it gets wrong and one fundamental thing, or at least I believe it's fundamental, perhaps some academics have proof one way or the other.
The superficial things are things that are not really part of the language, but more of its standard library, part of the 'prelude', or things the community has agreed upon:
- the I/O monad (and others) can throw errors
- prelude is full of bad practice like use of strings and linked lists
- there's something wrong with how function names can't be namespaced
There's more than this, and they're not just things I came up with, they've been fought over in the community at length. Other preludes exist, I/O libraries that don't throw errors, even whole different systems for doing I/O exist. It's not that solutions are hard or impossible, they're there, it's just that the way the language is managed it's not likely that they'd ever be applied in a way the entire community, and especially those drawn to it by any marketing would experience them.
Maybe I'm making a fool of myself and things changed in the past couple of years, things were really developing at a rapid pace when I left, but it seemed all the improvements happened around haskell, not to the language itself. When Stack and LTS-Haskell emerged it was the most amazing thing that I saw happening to Haskell in like 10 years, but given the lackluster response Snoyman received from the core team it seemed like they didn't even realize it even though the entire community had like an upheaval.
In my opinion, Haskell's marketing is fine. It's being marketed to every college student anywhere that goes to a good enough university that it teaches functional programming. In addition to that there's raving fans (myself included) that extoll its virtues to anyone who would hear. What it needs is a better retention rate. It needs that people who learn it, immediately realise it's fit for production use, that it's not just a fun experiment and a educative way of looking at things. For that we need something like a Haskell 2.0, designed by the community to incorporate everything we learned about Haskell's flaws and make it an absolute powerhouse of productivity. Maybe Haskell should be split into two flavors, one the teaching language with the linked lists, strings and funny pattern matching, and one that's got a prelude that will set you up with the perfect base to build the next compiler, database, service or web application.
If all those smart people who learn Haskell and tinker with for a bit, actually stayed around and used it to build awesome stuff, Haskell would truly have an enormous foot print on the world.
(not really relevant but the fundamental thing is that Haskell's performance is really hard to predict, this is true for many garbage collected languages, but for Haskell it seems to be extra bad because of the way its paradigm just doesn't map 1:1 to how computers are built)
Marketing Haskell as an industry language is starting to feel a bit like a forlorn hope. After 30 years of getting passed by a variety of new languages that are supposedly inferior, hoping that Haskell will make industrial in-roads seems a bit silly to me.
I mean, try if you want to. It's no skin off my back. But it doesn't seem like it'll work.
[+] [-] wirrbel|5 years ago|reply
It's not that haskell doesn't have merits. However I feel like they are oversold. While you can build programs that lack certain error classes, they are not bug free and at the same time debugging often was a lot harder than in other languages. The laziness is especially problematic in that regard.
Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth.
Another important problem is the docs. For some reasons they hardly contain examples. You don't get adoption that way. Even if the maintainers feel that the type signatures are documentation enough.
And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process.
[+] [-] kace91|5 years ago|reply
> Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”).
Thinking about readability or usability as emotions and social factors, rather than as first level concerns, is a non starter to me, and I find it extremely off putting that the author seems to pile up those qualities in the marketing "group", as if they were not real properties of a language.
You can design a drill in a way that makes it the most scientifically correct at using the power it's supplied efficiently, but if the design hurts the users hands and requires months of training to operate, any worker will throw it in the trash, because they can drill things just fine with a regular tool.
(I'm not necessarily saying that Haskell is that drill, just saying that usability should never be treated with condescension when you're designing tools).
[+] [-] pwm|5 years ago|reply
[+] [-] easygenes|5 years ago|reply
[+] [-] rfergie|5 years ago|reply
So it isn't that those things aren't important; just that they are subjective
[+] [-] awinter-py|5 years ago|reply
[+] [-] spekcular|5 years ago|reply
1) https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... 2) https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_oc...
Yes, the Haskell community hates that guy and considers him a troll. But he does functional programming professionally as part of a private consultancy and wrote a book on OCaml. If anyone's equipped to understand what's wrong with Haskell, it's him.
Haskell has had 30 years to get its act together. Any benefits it has are drowned out by a sea of buggy tooling and accidental complexity (monads, etc.).
Ask yourself this: if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?
Time to move on.
[+] [-] centimeter|5 years ago|reply
The young economist looks down and sees a $20 bill on the street and says, “Hey, look a twenty-dollar bill!”
Without even looking, his older and wiser colleague replies, “Nonsense. If there had been a twenty-dollar lying on the street, someone would have already picked it up by now.”
Industry makes collective bad engineering decisions all the time, usually driven by secondary factors like institutional momentum or hiring constraints. Did you read the article? It talked about a bunch of things like that.
If you equate market cap with quality, then Java is probably the best language of all time.
> wrote a book on OCaml
I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. OCaml is nice compared to most crap, but as someone who’s spent years working with both, Haskell wins almost every time.
It’s interesting, actually - I don’t know anyone who’s used Haskell and doesn’t like it. Almost everyone who vocally complains about it hasn’t really used it.
Reading that guy’s reddit posts, I have to conclude he’s some kind of troll - most of the things he criticizes Haskell for are way worse in OCaml, or just completely disconnected from reality.
[+] [-] todd8|5 years ago|reply
Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc.
However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws.
We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.
[+] [-] somewhereoutth|5 years ago|reply
Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.
[+] [-] nilkn|5 years ago|reply
Also, there really is very little substance behind the actual language criticism. It's hard to make a blanket statement that typeclasses are "overkill"; they seem to be showing up all over the place in new languages. Similarly, type annotations are incredibly useful and are also showing up all over the place these days outside of Haskell-land. The point on non-strict evaluation is by far the strongest and most legitimate.
[+] [-] sjakobi|5 years ago|reply
[+] [-] ashtonkem|5 years ago|reply
That is the most succinct explanation I've ever seen of Haskell.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] centimeter|5 years ago|reply
[+] [-] todd8|5 years ago|reply
Some schools have a bifurcated curriculum, like Indiana University which has a program in Informatics for those planning to go into a career the requires programming and software engineering skills and a program in CS for those perhaps planning on going into grad school. There, learning Haskell might make sense in the CS program, but does it make sense for other students that want to get out and get a job?
My own daughter studied at a school where her first CS class was taught in Scheme (Racket). It, to me, looked like an excellent introduction to programming for someone majoring in CS. They used a book I approved of, How to Design Programs/2ed by Felleisen, et. al. Would Haskell have been better? Maybe, but I predict that more kids would have serious problems with a language like Haskell that is burdened with more challenging concepts and ecosystem. Perhaps Lisp/Scheme is a gentler introduction to applicative programming than Haskell. However most schools start with Python or Java.
I understand the arguments for a strongly typed functional programming language like Haskell (my own university research was in program verification many years ago).
Early on in CS programs students usually take one or two classes on data structures and algorithms. Data structures in my opinion needs to be taught in C. Haskell, Lisp/Scheme, Python, Java, and even modern C++ are so high level that teaching data structures in these languages ends up with students not learning the proper use of these languages' standard libraries.
At some point undergraduates should have an introduction to systems programming, the best text in this area is Computer Systems: A Programmer's Perspective/2ed by Randal E. Bryant and David R. O'Hallaron. This is a great book for undergraduate CS majors. This book requires C programming. So to me, it makes sense to teach data structures in C since students will need to understand it for their first exposure to systems programming.
Where should Python fit in the curriculum? It's arguably the most versatile programming language. What about Javascript? When should CS majors be exposed to it. Modern Java is a big language so one semester of use isn't going to be enough and it's too important to ignore. What about C++? It takes years of working with it to become a good but not expert programmer in C++. Should it be a part of the curriculum?
So my own recommendations for an undergrad CS program's language choices would be:
* Python -- for intro to programming, a course on algorithms, and a machine learning course
* C -- for an early class on data structures and a later class on systems programming
* Java -- software engineering, and a compiler course
* Lisp -- programming languages smorgasbord course, and an AI course
* Assembly -- hardware architecture/digital design course
* Javascript -- taught as part of a web-applications class
* Haskell or OCaml (or maybe Rust) -- intro to functional programming and program verification
What do HN readers think about this list? I'm glad I don't have to make the real decisions there are just too many languages that students need to learn in just a few years.
As far are my own background I have spent a great deal of time pursuing three different degrees from three different universities in CS. I've been the instructor for university courses for CS majors twice and taught perhaps 40 week long classes to professional programmers within a Fortune 500 company. I've also interviewed and hired many senior developers for my own company.
[+] [-] ethanzh|5 years ago|reply
[+] [-] turndown|5 years ago|reply
[+] [-] gowld|5 years ago|reply
[+] [-] zabzonk|5 years ago|reply
No source specified - ignore.
> if society could quantum tunnel
Oh dear.
[+] [-] dmix|5 years ago|reply
Erlang got a big boost when it came out WhatsApp scaled it up with a billion users, with tiny team and only a few servers.
React/React Native got boosted by Instagram adopting it to build their production mobile app.
Rails had 37signals/Basecamp and Github/Shopify/early Twitter/etc.
Haskell needs some more famous commercial "killer-app" examples for real businesses and real teams. And yes I'm very familiar with the current selection of popular Haskell examples.
Currently I only ever hear Haskell (and Ocaml for that matter) being used by engineers for backend engineery things (parsing programming languages, fighting spam, tooling) mostly for OSS tools.
On a positive note, PureScript is trying to position itself as a practical Haskell and making a bit of success. One helpful reason is they have a nice app/company leading the way as a production app with Lumi [1], with their founder playing a key role on the language/ecosystem dev side as well: https://www.lumi.dev/blog/purescript-and-haskell-at-lumi
This is what Haskell needs more of - and critical a company promoting/blogging about their progress using Haskell as well as contributing back into the community.
Another big one is simply a sort of 'starter kit' which guides you with best practices on how to architect a serious Haskell app (ie, using STM, free, etc). React has plenty of starter kits. For Rust CLI apps there is a great starter kit https://github.com/iqlusioninc/abscissa
I'd love to see a similar starting point micro-framework for starting a new Haskell app that makes a bunch of importation decisions for you and guides the structure of the project.
[+] [-] moreaccountspls|5 years ago|reply
edit: It's unfortunate that people are downvoting me for offering my experience, especially on a post that wants to make Haskell more attractive to being used in the industry.
[+] [-] cs702|5 years ago|reply
But... most people who look into Haskell lose steam as soon as they realize they actually must understand and be able to reason about functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. It's a shame.
[+] [-] solatic|5 years ago|reply
This is a very MBA-like lens through which to examine software development. It's not wrong, but it's also a recipe for mediocrity, which is a great way to damage your culture and sit around wondering why you can never get ahead of your competition.
The deeper question is why is software quality only loosely correlated, if at all, with business outcomes?
The pessimists will point to Equifax et. al. and tell you that the market simply doesn't care, that businesses can go through downtime after leak after catastrophic failure and their stock will never take a hit. And there's some truth to that. The end consumer actually doesn't really care about the bad news. There's not much that any company in the business can do about that.
But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. The value of correctness isn't in the two months after you begin, it's in the two months after your latest release five years from now. It requires vision, patience, already-available human capital, and leadership to realize the benefits.
> If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter.
If you give your talent the opportunity to work on a Haskell project and they're walking out the door when it's difficult to find Haskell work to begin with, then you, the manager, failed in deciding which talent to hire. If you're looking for a support contract to hedge against the loss of in-house talent, then you've already failed. If you think that legal solutions will protect you against market failure, then you've already failed. Haskell isn't trying to market to these people in the first place, why should it start?
[+] [-] awinter-py|5 years ago|reply
codebase organization was nonintuitive and I blame type-level programming
compilation was so slow and bad that other programs on my laptop started to die
the feature I was adding was something that would be library-provided in a normal web language
none of the operators have names and are very hard to google; I had to search for things like 'haskell tilde asterisk arrow'. Impossible to know what's from libs vs core language. Lots of explanatory docs online were like 'oh we don't pronounce this one'.
Core abstractions have no definition ('to explain that I would have to explain monads but you won't understand monads so GFY'). Monads are just sub rosa dependency injection .
lang doesn't protect you from runtime crashes but does apparently protect you from knowing where the program crashed
[+] [-] rockmeamedee|5 years ago|reply
I liked the linked author's points about the pre-requisites for marketing a solution:
When I think about the most popular languages, they do have all of these: Rust:Memorable: very. It's basically everywhere you look Has a key benefit: going C++ fast without the C++ footguns, memory-safe, WASM integration Differentiates: Using Rust is definitely choosing a particular set of technical tradeoffs Imparts positivity: the community is known to be welcoming, feels cool, cute crab. People re-write existing software in Rust just because it feels good!
Yet Haskell has almost none of these:
Memorable: I mean, yeah, but it's not being shown to people, and I can't point to a bunch of software. Tools I know of include PostgREST, Hasura, Nix, hledger, which is better than nothing. Key benefit: Hand waving about "being more correct", unlike Rust which has reams of "Microsoft claims 60% of its bugs are memory-errors" articles, and in any case TFA's point is that this needs to be a different message because correctness isn't gonna sell it. Differentiates: This is definitely true, almost too much Imparts positivity: Not really feeling this one with Haskell. People feel good when they figure out a monad is a container & a lens is a path through a data structure, but attempts to explain to others these things feel condescending. Does Haskell even have an animal mascot? (serious question.) Also "stumps" a lot of people and people feel bad about it. There's no "import antigravity" equivalent feeling with Haskell.
This sounds pretty sombre for Haskell, though it's been an academic language a long time, and could probably stay alive that way.
One positioning possibility is maybe with the Frontend dev world becoming more and more functional and pure-oriented, positioning itself like reasonML, as a way to write and reason about declarative pure UIs. But I don't think the existing Haskell community cares too much about that world.
Idk, I'm going to just keep writing Rust and JS, the already most loved and popular languages.
[+] [-] 6gvONxR4sf7o|5 years ago|reply
There are certainly pieces of haskell that would make all our lives easier, and I can't wait for them to make their way into mainstream industry work one way or another.
[+] [-] weinzierl|5 years ago|reply
"To contact me via email run one of the following scripts to generate my contact information. I find this is an effective filter against the deluge of emails from recruiters."
The "scripts" are offered in Haskell, x86-64 Assembly and Python. Solution is pretty obvious though, no need to run them actually.
[+] [-] jeffdavis|5 years ago|reply
No. Technical excellence matters a lot when used appropriately, but competing with javascript and python is not where haskell is going to win.
There IS a language with HUGE success that is: declarative, strongly typed with type inference, lazy, and no side effects. It's called SQL[1].
That's where Haskell could shine -- compared with SQL. Imagine Maybe rather than NULLs, a sane language, multiple returns, a much better type system, etc. Python and Java can't touch SQL, but haskell could.
[1] http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-...
[+] [-] sjakobi|5 years ago|reply
[+] [-] pron|5 years ago|reply
Second, the problem with the message of "code written in Haskell is more correct than code written in other [more popular] languages," isn't that the industry doesn't care about correctness. Correctness translates to cost (to a degree), and the ability to write software as correct as it needs to be more cheaply is actually quite compelling. Rather, the problem with it is that it's simply not true (or, rather, hasn't been shown to be true), certainly not to any degree big enough to matter. That, in and of itself, does not make it a terrible message; after all it's just harmless hype, right? What makes it a terrible message is that it is very clearly not (shown to be) true and yet some Haskellers seem to actually believe it, drunk on their own kool-aid, which makes you think of them as out of touch with reality. At best, it's an emotion (it "feels" more correct), which you've mocked, rather than any sort of "critical thinking," that you present as the desirable standard.
Third, the mistake in the perception of the economics of software is not the importance of correctness — that can have an easily measurable impact. It's in the importance of code. Programmers in general, but Haskellers in particular, are obsessed with code. As a result, they grossly overestimate its importance to software. Ask yourself how long it takes you to produce, say, 1000 lines of code of sufficient quality, and then look at a software produced at your company and divide the size of the codebase by the number you came up with. You'll find that the true cost is several times that. The "pure" cost of producing code is not where most of the cost of developing software is. Maybe it's in what you mockingly call "emotions", but it certainly isn't in programming-language semantics. Also, before presenting managers' priorities, it's better to actually speak to actual managers; they just might have some useful insight here, plus, it's what a culture of technical excellence demands, no?
All of that means that unless your language has some clear and direct effect on the bottom line — which, these days, usually means it has good performance and/or observability, a good ecosystem, or a monopoly of sorts on some distribution platform -- there is no "message" that can make it popular, other than "it's easy and it's fun." While perhaps not a sufficient requirement for success, this can create a supply of qualified developers that at least won't put your language at a disadvantage.
And here's another tip: if your retrospective introspection isn't painful, doesn't discuss any serious and conspicuous flaws with the product, and still paints you as being somehow right after all and everyone else as being somehow wrong — it's probably not true. Worse, it seems untrue. And not calling your own practice one of "engineering excellence" and others' as "throwing enough bodies" can't hurt, either. In other words, I don't know what a good marketing message for Haskell would be, but this post is a good example of a bad one.
[+] [-] CyberDildonics|5 years ago|reply
I think this approaches the heart of the problem. Whatever the advantages of haskell may be, the disadvantages run extremely deep. Haskell is notoriously difficult to debug and optimize (both memory and cpu usage). It is interesting and influential, but trying to abstract away the order of operations as a core of the language just didn't pan out. All of that is before issues of IDEs, libraries, compilation times etc. It has been around for 30 years, at some point it needs to be called a worthwhile experiment so people can move on from clenching their fists that no one else is as clever as they are.
The more I think about it, my ideal language would be the exact opposite. Something extremely clear and straight forward with minimal complexity and maximum infrastructure.
[+] [-] mhh__|5 years ago|reply
Maybe it's because the bugs are generally less common and easier to fix, but when I look at Haskell codebases it seems like it's quite difficult to achieve the same level of "separation" one would in (say) Java - i.e. an average Haskell file seems to purely consist of many loose free functions (often with very short names!).
I might be missing the point but the aforementioned always pushed me away from Haskell - great language, but seems to have legibility as an afterthought (as opposed to python, which is an awful language, does manage to enforce some sort of legible coding style)
[+] [-] whateveracct|5 years ago|reply
For this reason, I find code style to not affect me in Haskell. I've seen a bunch of different styles and I'm never taken aback. The code is all simple & mechanical to reason about.
I've been able to refactor other people's "bad code" without much effort too. This is after others have said the code is bad and unfixable. It just takes a good attitude and the same mechanical approach as always.
At the end of the day, I think a lot more about the business problem in Haskell than other languages. I hate having to think about code & simulate a computer in my head. But if you wish to use other languages and pay me to think like a computer, feel free! It's your money.
You can think of modules as Java classes and get the same sort of code separation fwiw.
[+] [-] seanparsons|5 years ago|reply
Oddly now I find it really legible compared to other languages, you can still make things obtuse if you really want to, but the flow seems so much clearer.
I would say compared to Java (as you mentioned it) there's much less separation because things invariably gravitate towards big balls of mud containing lots of state. But in Haskell the function you're looking at is only tied to the functions and data types it uses, no more, no less.
[+] [-] marcosdumay|5 years ago|reply
Good Haskell code is not organized the same way as good OO code. While in OO you will have separated instances that take complete care of different business concerns, in Haskell you will abstract the care into different parts, and integrate the business concerns into a few instances that take complete care of them.
[+] [-] chrischen|5 years ago|reply
I’ve personally switch code to functional style and it has simplified and reduced code for me. Granted if you don’t know how monads work it could be very confusing.
[+] [-] phreack|5 years ago|reply
[+] [-] ghostwriter|5 years ago|reply
[+] [-] colehasson|5 years ago|reply
https://www.youtube.com/watch?v=cijsaeWNf2E
[+] [-] tinco|5 years ago|reply
The superficial things are things that are not really part of the language, but more of its standard library, part of the 'prelude', or things the community has agreed upon:
There's more than this, and they're not just things I came up with, they've been fought over in the community at length. Other preludes exist, I/O libraries that don't throw errors, even whole different systems for doing I/O exist. It's not that solutions are hard or impossible, they're there, it's just that the way the language is managed it's not likely that they'd ever be applied in a way the entire community, and especially those drawn to it by any marketing would experience them.Maybe I'm making a fool of myself and things changed in the past couple of years, things were really developing at a rapid pace when I left, but it seemed all the improvements happened around haskell, not to the language itself. When Stack and LTS-Haskell emerged it was the most amazing thing that I saw happening to Haskell in like 10 years, but given the lackluster response Snoyman received from the core team it seemed like they didn't even realize it even though the entire community had like an upheaval.
In my opinion, Haskell's marketing is fine. It's being marketed to every college student anywhere that goes to a good enough university that it teaches functional programming. In addition to that there's raving fans (myself included) that extoll its virtues to anyone who would hear. What it needs is a better retention rate. It needs that people who learn it, immediately realise it's fit for production use, that it's not just a fun experiment and a educative way of looking at things. For that we need something like a Haskell 2.0, designed by the community to incorporate everything we learned about Haskell's flaws and make it an absolute powerhouse of productivity. Maybe Haskell should be split into two flavors, one the teaching language with the linked lists, strings and funny pattern matching, and one that's got a prelude that will set you up with the perfect base to build the next compiler, database, service or web application.
If all those smart people who learn Haskell and tinker with for a bit, actually stayed around and used it to build awesome stuff, Haskell would truly have an enormous foot print on the world.
(not really relevant but the fundamental thing is that Haskell's performance is really hard to predict, this is true for many garbage collected languages, but for Haskell it seems to be extra bad because of the way its paradigm just doesn't map 1:1 to how computers are built)
[+] [-] ashtonkem|5 years ago|reply
I mean, try if you want to. It's no skin off my back. But it doesn't seem like it'll work.
[+] [-] xixixao|5 years ago|reply