@satoshi778
I do wonder if multicore is our real strength. FP languages need a GC (unless completely linear as in linear lisp) and most GC’s I have seen do no scale linearly with the number of cores. Garbage is not produced uniformly at the same rate by HECs nor can be effectively work-stealed without cache performance impact. And I say this as someone who likes out generational moving stop-the-world garbage collector.
2 Likes
I think you are missing the point of using JS and Python. It is much easier for a person to learn python/JS and start working on some code. As a result, it takes little cost for a company to hire (fairly incompetent) python dev and train them with minimal effort. Also explains why Go is made as so, and is getting decent adoption. Such devs are dirt cheap in terms of labor and handling.
Can we expect the same for Haskell? Eh, I do not see it.
3 Likes
This thread motivated me to take some time to interview some of the people I know as to why they would choose Python over Haskell. The result is here: Why (some) Python programmers don't choose Haskell · GitHub
The most interesting aspect of this sample is that these people are researchers who are not afraid of category theory / monads.
These opinions are not my own (I choose Haskell for everything 
), but I hope they can help the Haskell community understand why more people don’t choose Haskell.
Some of the general themes:
- Haskell just isn’t very well known.
- Python has so many libraries.
- Python has good, beginner friendly tooling.
- I am using Python and my collaborators are already using Python, would need a good reason to change.
- Students can pick up Python very quickly.
- With Python you (or a collaborator, or a student) can always “muddle through”. With Haskell you may just get stuck.
- Haskell seems “locked down” (types? purity is handcuffs? no imperative programming?)
- Unfamiliarity with functional programming.
- Haskell code in the wild looks very complicated compared to Python code in the wild.
14 Likes
I can criticize your assertion in multiple ways; i.e, we can really streamline Haskell teaching processes (as shown by production Haskell shops, which are more attached to teaching efficiency than pure FP) to get fairly good efficiency.
Hasura, for instance, got off the ground by hiring Indian programmers without Haskell experience and training them. That seemed to have worked in their early stage, then they went to hire Well-Typed to clean up their code base, and eventually migrated to Rust.
There are Haskell firms that claim 2-week on-boarding times for non-Haskellers, and there are also Haskell firms that expect 4 weeks on-boarding, but that is equivalent to their experience with non-Haskell languages.
On the other hand, you are right insofar as I wouldn’t consider it desirable for Haskell to turn into a “codemonkey” language, not because of disdain for codemonkeys, but because there are already a lot of bad Haskell codebases out there, as evinced by reports from Eric Normand, hasufell, and others.
Bad Haskell codebases deliver bad Haskell experiences, and word of bad Haskell experiences leaks out. It’s bad for the brand.
On the other hand, if Hasura wants to hire skilled Indian developers and train them on Haskell, or a Chinese firm might want to exploit the local level of mathematics education, what’s the problem? Or, in LaurentRDC’s case, there are a lot of domain experts with relatively strong mathematics backgrounds who might be better off working with Haskell than Python.
I think the point to be emphasized is that if Haskell does decide to go after Python’s use cases, we should be going after their high-end use-cases, not the commodity coder market.
I think, at the end of the day, this thread just comes out to a plea for Haskell to:
-Have tooling that’s easier to use (we’re working on it, and great progress has been made)
-Have better educational materials and on-boarding (not exactly there yet, but there’s been a lot of work on teaching Haskell in a practical way).
-Have a better ecosystem that is both broader and friendlier to newbies (we’re weakest here, but there are still a lot of dedicated Haskellers working on newer libraries as well as keeping older libraries modern).
The urgency comes more in that prominent Haskell firms have already moved away from Haskell, because Rust is sufficient “worse is better” (and is strictly better in other respects), and keeping industrial Haskell use just stable may require new approaches.
Meta is rumored to be nixing some Haskell systems, although exactly which isn’t known, and Meta is still a Haskell Foundation Monad-tier donor. Collegevine is obsoleting much of their Haskell infrastructure, choosing Ruby instead for faster prototyping, back when IHP wasn’t a big thing. Tsuru Capital ran off to Rust. Hasura rewrote in Rust.
Digital Asset seems to have downgraded from Monad-tier to Applicative-tier, and there could be a variety of reasons for thus.
On the gains side, I can think primarily of Juspay, which is comparably sized to Hasura, but working in financial services; Co-star seems a bit scammy (they’re an astrology provider, after all), but they’re a small shop to which Haskell seems central to their business model (sure, we’re astrology, but you’re okay with crypto, no?). There’s LaurentRDC’s proprietary trading firm conducting a Haskell experiment; what other companies have hopped aboard the Haskell bandwagon of late?
1 Like
Thanks so much for this! To me, this feels like it boils down to, essentially, ‘I’m not using Haskell because no-one else is using Haskell’. And, sad to say, that’s not a bad argument… to overcome that problem, any language would have to be truly exceptional compared to the competition.
On the other hand, I think this may be biased by the fact that these people identify as researchers, not developers. In my experience as a research student in physics, researchers don’t really care too much about programming: they need it to get their job done, and beyond that they’re not really interested. Actual developers seem to be much more flexible than researchers in terms of switching between programming languages.
4 Likes
Perhaps it’s time to show how those up-front restrictions can be worthwhile: instead of just being multi-threaded by default, make Haskell parallel by default:
So what would be needed for this to happen in GHC?
2 Likes
I’ve always thought that it would not be impossible to tweak the garbage collector to spark some threads to speculatively evaluate thunks. You’d need rollback and timout mechanisms to avoid errors and infinite loops. And for it to be effective you’d also need a good heuristic on which thunks to evaluate this way.
As I dimly recall, there was an experiment (and associated paper) which described something like that, albeit for a sequential implementation: it would reduce e.g. fst (x, y) to x during the collection, because it could ascertain that fst's argument was already evaluated.
That’s not an experiment, it is a crucial part of the garbage collector we use today!
https://homepages.inf.ed.ac.uk/wadler/topics/garbage-collection.html
Yes, that is the technique I was trying to recall - if it’s still being used in GHC, that could be a useful place to start (after multi-threading by default is firmly established ;-)…
I suggest starting with conservative parallelism first:
-
if there was going to be a problem, it would have eventually appeared during sequential evaluation anyway.
-
a simple compile-time heuristic could be used, relying on the results of strictness analysis to nominate sub-expressions suitable for parallel evaluation.
1 Like
End of the day, going to researchers on their own is a lost cause, because Haskell’s ecosystem has no hope of matching Python’s in the foreseeable future. It’s more usecases like LaurentRDC’s that are interesting; i.e, you have domain experts working in a larger firm who are not professionally-trained developers, and Haskell helps to improve their code quality for the engineering side of development.
A lot of this keeps on reminding me of Gabriella Gonzalez’s video on marketing Haskell, wherein she argues that Haskell’s niche might be building eDSLs, except that lots of people have issues with FP’s tendency toward eDSL, tightly binding developers to a codebase and making it hard to onboard.
But a lighter version might work; i.e, wrap mature and applicable libraries, provide a bunch of convenience functions that are easy to use, and only teach enough Haskell to use the resulting eDSL.
tl;dr Pythonistas is the wrong crowd
To go back to your original topic “Commercial Haskell should go after Python/Julia no Rust”.
I think you are making an interesting point, in that Haskell shoulg go after X no Rust. Where people seem to disagree is targetting Python an Julia
Rust
They have been some defection indeed from Haskell to Rust. From what I understand is Rust offers some predictiblity in term of memory and CPU that Haskell can’t at the moment (mainly due to GC). I’m not sure raw speed is what matter the most, apart from time critical application Haskel is far from fast enough for most applications.
I see Rust as C++ done right.
I was a C++ “pro” 20 years ago . I got interested into Haskell because C++ template was/is a pain, yet I didn’t like to write the same stuff twice. Haskell polymorphic functions was what got me into it, not FP, not purity, not lazyness just the fact that I could write f x = x + 1 (and that the compiler would tell me if I couldn’t). Then I saw pattern matching being able to write things like
case args of
[] -> doSomething
["--path", path] -> doSomethingwith path
...
Was amazing etc (I don’t if you can do it nowadays in Python).
Had Rust being there at the time, I probably would have chose Rust vs Haskell (it took me a few years to decide between Haskell, OCaml and F#).
If I look at apps I was writting at the time, I think Rust would have been the best choice (vs Haskell) I think the management would have gone to C#.
So indeed, Rust fill a gap where Haskell can’t compete for now
Python/Julia
@bradrn made the distinction between research and developper. I think the main distinction “is the software the end product or is it a tool to make the end product”.
If I am paid to build a website, the website is the end product. I am paid to build the app not to use it.
If I am paid to migrate a database to another one and instead of doing it manually I write something to do it for me. The end product is the new migrated database not the software.
If I have to analyse the sales of the last few years to produce a forecast the end product is the forecast.
Depending on our job and the task we might be on one side or the other. For software developpers the end goal is usually software, for research is data. But researchers might reuse their “tools” over and over and try to get it right (in a software developper point of view).
So people are either a developper or what I’ll call an auto-user. Adding to that is are they paid for it, or it as a hobby. Also, we kind of agree that Haskell is hard to sell to auto-user, regardless of the fact they might beneficiate from it.
I understand that most paid Julia user are researcher and are doing so to analyse and produce data. As such, they are mainly auto-user, so Haskell is a hard sell.
Most Python users are I auto-users (even if they are paid for it). Migrating a database is a good example. You might be paid to do so, but you are not paid for the bit of software, but the result of executing it.
Ok, we are talking of “Commercial”. The main pythonista paid in a developper context (as opposed to auto-user) are probably website dev, like Django user . There is already a stiff competition with Ruby and Node. I don’t see them as a viable target for evangelisation.
2 Likes
We agree entirely that auto-users are not good candidates for Haskell evangelization, but I think I disagree as to the reason.
I don’t think that Haskell is so complex that it cannot appeal to auto-users, but simply that for auto-users, it’s the ecosystem that is the most important part, and Haskell’s ecosystem for most use-cases where auto-users predominate is inferior, and we are unlikely to make much headway on it.
As for web developers, I think that was Michael Snoyman’s idea, wasn’t it? The ecosystem and tooling was just outrageously immature at the time, and while Michael Snoyman did a lot of work to make Haskell viable for that purpose (and even if you dislike Stack, as I do, you have to admit that Stack was a great revolution, and it is still the best tool for certain use cases), Haskell still has very poor market share in that field.
But I wouldn’t think that Haskell is completely dead there; IHP seems to be making good progress, vs Ruby, Haskell is substantially more performant, and vs Node, Node lacks performance and is actually a minority itself.
As far as going after Python though, while Haskell cannot compete in the vast majority of use cases because of Haskell’s dearth of ecosystem (and the Codon compiler suggests that Haskell might even eventually lose in terms of performance), I think the basic direction is sound, only because trying to go after Python means that Haskell has to address two key weaknesses.
The two main spaces where Haskell loses out to other languages is ease of learning and ecosystem.
But ease of learning does not have to be a major problem; moving toward dialects as with C++ helps to simplify onboarding, and Haskell already has a strong tendency toward eDSL; it’s going to be dialectical anyways. Moreover, we’re getting a lot more pragmatic books on Haskell, although I think my wish for an update of Real World Haskell will likely never come to pass.
Ecosystem-wise, let’s just admit it, Haskell’s ecosystem needs substantial improvement, and more importantly, careful guardianship and directed development. There are packages that used to be useful that have bitrotted. Haskell is considered a “general purpose language”, but there are lacuna in Haskell’s ecosystem that make that more of a technical term. And of the libraries that exist, API design can be lacking, and, as LaurentRDC has pointed out, documentation, both “hard” and “soft” (tutorials, examples, prototypes) documentation can see improvement.
If I were to choose a domain for Haskell to make a push, it would probably be web frontend programming:
- Work is under way for GHC to officially support compiling to JS/WASM. It may appear that there isn’t much enthusiasm for “Haskell on the frontend” because GHCJS has existed for a while (and a few other Haskell-JS experiments), and there isn’t that much commercial use of it. But an “experimental” fork of GHC which lags behing master and official support are, in my opinion, two entirely different things. I would not personally consider Haskell for frontend today for a “serious” project, but may very well do so soon when GHC support is solid.
- Languages like Elm/Purescript/ReasonML have shown that there is significant appetite for functional programming on the frontend.
- The current area where Haskell has seen the most adoption is arguably web backend, which is closely related to web-frontend, so there is some “network effect” potential here. Furthermore, the idea of “isomorphic” apps, or just simply code reuse between backend and frontend is very attractive. This is probably the only reason Javascript was ever even considered for backend programming, despite all the ways in which it’s not obviously suitable for the backend, for example.
And web frontend programming is a huge space. Making inroads in that domain would make Haskell much more visible and well known.
8 Likes
Ugh, how concrete is the evidence? I mean, Haskell is well-known for being difficult, so I believe the burden of proof showing otherwise is on you. I think you need some kind of credible research to disprove the general consensus.
1 Like
https://news.ycombinator.com/item?id=23621930
Google’s experience with Haskell
https://news.ycombinator.com/item?id=21916629
Max Gabriel at Mercury claims the time to become productive is 4-6 weeks.
https://news.ycombinator.com/item?id=35442409
Claim of time to first commit is 1 week for multiple people, but unsubstantiated.
https://news.ycombinator.com/item?id=14148786
Guy claims he got a simple Haskell app up in 1-2 weeks of what seems to be self-learning.
There’s also someone who hung around FP Discord, a C++ programmer, who decided to speed-run Haskell and built a compiler as his first project. This… didn’t go well, mainly because while he managed to get a fairly advanced Haskell project working in 3 months, he burnt out.
IIRC, there’s someone at Hacker News (I’m searching for the comment) who can do 2-4 weeks onboarding for non-Haskellers.
Compare this to, say, Ying Wang blowing 3 months to go through HPFFP: A Pythonista's Review of Haskell > Ying Wang
I mean, it’s not exactly good, and any hopes of getting Haskell to be taught as quickly as Python are delusional. But if we are obsessed with pure pragmatism, and are willing to constrain the dialect, the time needed to train an idiom of production and productive Haskell is not going to be as high as you think it is.
Moreover:
It’s just good practice to learn Haskell by doing and refactoring; I consoled the disappointed C+±er by pointing out that he was basically trying to do the equivalent of learning Template Metaprogramming before writing his hello world.
2 Likes
I have to disagree. Most people when they get started don’t use or need the ecosystem. People will reach for Python just because you open a csv do a a few calculation and generate a new without having to install anything. The same goes for tooling. People start learning and using Python because you don’t need tools. They just use notepad and there you go.
The fact is, Haskell is hard, period. You can make it smoother with good tooling but that doesn’t change the fact that it’s hard. It is even part of its appeal.
It’s like Math. You can say Math is easy, have teachers making it fun , but people hate Math. Even most software developpers hate Math.
There is an ongoing question about do you to be good at Math to learn Haskell. The answer is no. But if you don’t like Math, chances are that you won’t like learning Haskell neither. And you need to be willing to learn Haskell to use it.
In my carreer, I have some success in evangelisating Python. I never manage to convert anybody (that I know personnaly) to use Haskell. I have people interested, asking questions, but they all gave up at the end. Coincidently, they didn’t like Math either. I probabry would have more success when I was still at Uni, surrounded by Mathophiles.
2 Likes
maxigit: to cut a long response short, what do you think about the following tutorial?
Of course, I’d consider this tutorial not really “teaching” Haskell, but we’ve discussed Pythonistas, and honestly, it seems that quite a lot of them don’t really know Python either.
The story I’ve heard is that when Juspay adopted Purescript, there was an utter dearth of useful learning resources, and people just looked for phrasebooks and just modified code samples, and somehow the project worked. Presumably, the developers got better by the time they adopted Haskell.
In the same regard, if you wish to put Haskell into production use, there is no need for your developers to truly learn Haskell, only a limited dialect selected by competent Haskellers to make onboarding relatively easy.
3 Likes
Yesterday, whilst updating my XMonad config, I spent about 20mn trying to convert swapUp to a ManageHook. The final code was return $ Endo swapUp. If you prefer, I took me 20mn to write return $ Endo. That type of things is unacceptable for pretty much everybody.
5 Likes
Which libraries are needed? Which libraries need to be documented? What do you mean by «API design can be lacking»? Can you draw a roadmap from here to success?
4 Likes