Good informative post, thanks !
A small typo.
Did you mean to write Haskell there ? I didn’t quite understand the point being made.
Thanks for noticing.
What I mean by the latter is that Haskell can displace C++ by wrapping C++; i.e, instead of the interface being written in C++ for Sigma and SC’s Mu codebase, it’s written in Haskell instead. It is not wholly replacing C++; Haskell does not have the high and predictable performance needed for that, but it is replacing part of a C++ system.
You can consider this, to an extent, being Haskell replacing C++ by having a powerful type system that can increase code correctness and expressivity.
In contrast, Haskell is not sufficiently better than Rust for these purposes that it’s worthwhile building a Haskell interface for a Rust application.
I have been criticized in the past for wanting too much Haskell adoption, and I think people new to Haskell tend to go through such a phase, where they’re incredibly besotted with Haskell and would like everyone to use it.
However, given current trends, encouraging Haskell adoption is somewhat similar to simply wanting Haskell adoption to stay at current levels, since there are Haskell users dropping the language for Rust.
The thesis of this thread is that Haskell has a hard time competing with Rust right now because for high-performance applications, Rust is has more and more predictable performance, while having a larger ecosystem, a larger pool of developers, and being easier to train for.
However, performance and safety is not the only benefit of Haskell’s nature as a pure, strongly and expressively typed language; Haskell is also capable of being extremely terse and being, for a developer trained in the FP paradigm, easy to write.
That is to say, Haskell is suitable to attack Python’s use cases, and in doing so, maintain its social and library ecosystem. Haskell isn’t the best qualified for this purpose; half of Python’s strength is its extensive and easy-to-use ecosystem, which Haskell lacks. However, I think Haskell still has sufficient advantages in performance, safety, and expressiveness to compete with Python, and moreover, trying to compete with Python will ultimately come down to whether or not Haskell has a competitive ecosystem that is both broad and easy to use.
I would say that if Python’s use cases get targeted, the side effect will be a broader and easier-to-use Haskell ecosystem, which is a net gain.
As far as scripting goes, I wouldn’t consider Haskell optimal because Haskell is typically compiled (interpreter without O2 tends to perform relatively badly, although generally it’ll outperform Python substantially), and because Haskell’s syntax requires names wrapping your script, whereas OCaml and Python can execute commands on the top-level. However, Haskell’s terseness makes it competitive enough, and the scripting ecosystem, while not ideal, seems sufficient. If you absolutely demand top level scripts, script :: IO (); script = {…;} using the brackets and semicolon to override significant whitespace and write everything on the first column.
For prototyping, I think most are aware of the old Aegis code prototype study that Hudak (RIP) published? https://www.cs.yale.edu/publications/techreports/tr1049.pdf
You can use Ada as a benchmark in this regard; Haskell took less than half the time of the equivalent Ada code to prototype (C++ never completed), and around 3 times that of a logic-programming Lisp, while creating code with greater maturity than either.
It’s just that, while, apparently, there was interest in Haskell as a prototyping language in the 90s and 00s, Haskell didn’t evolve into that direction, and I’d consider the standard TyDD idiom neither excellent nor terrible for prototyping (write your types, build up a program as undefined, then fill in the blanks is pretty competitive, but it’s easy to get the types wrong when you’re doing exploratory programming) . On inquiries in /r/Haskell, some Haskellers seem to have obtained a level of success with Haskell prototyping, but the advice seems contrary to standard TyDD.
While I’d consider Haskell as a scripting language relatively explored (it’s easy to try, there are libraries for it), the prototyping direction is interesting precisely because while some Haskellers have had success, many Haskellers regard Haskell as unsuited for such. That suggests that the Haskell prototyping space is ripe for exploration and development.
1 Like
As a small, final comment, I talk to a Clojurian who hates Haskell and I like our Socratic conversations as a way to refine ideas and get out of the Haskell bubble.
He’s a staunch dynamic typing advocate, and while he’ll use type hinting and mypy in Python, he’s viewing it as for “inferior” programmers as we’ve agreed that he’s a professional “s-code” cleaner, and mypy gets bugs out of his codebases quite well.
The effective question we’ve been discussing is whether or not there’s a space for purely type-inferred code in Haskell; of course, as Probie has shown, there are cases where even Haskell98 / Haskell2010 type inference will fail.
Considering prototyping, I think there is.
Put another way, every red-blooded Haskeller is pretty addicted to having type signatures to their code and can list 50 different reasons skipping top-level type signatures is a terrible idea.
However, when it comes to prototyping, getting your types wrong is a real risk, and writing in a type-inferred idiom is useful. There’s obviously readability tradeoffs, but there’s a fairly easy way to handle this; put the types in comments.
This has two benefits.
First, the absence of top-level type signatures is an obvious “DO NOT SHIP” warning signal for prototype code; it makes prototype code distinct.
Second, when you’re trying to get dynamic typing advocates to embrace the advantages of static typing, it helps for them to think of type signatures as comments; my point about docstrings is that while you can have a substantial community of Pythonistas who hate static typing, the population of people who object to docstrings is much, much smaller. Having them think of type signatures as comments to improve the readability of code is a useful starting point to have them experience the advantages of modern static typing over dynamic typing as well as more antiquated forms of static typing.
It also helps because all their code, as they adapt to Haskell, will start off as prototype code anyways. Their code is unlikely to pass code review, and moving into a “no type sigs, commented out type sigs mean prototype code” idiom is both useful for indicating what should not hit production, as well as segueing them into a statically-typed idiom.
I use stack scripts often, sometimes interpreted, sometimes compiled automatically as needed by stack script --compile. I could optimise with stack script --optimize, but I rarely bother. Even in interpreted mode, these normally feel plenty fast to me, other than a little (fraction of a second) startup delay when interpreted.
(Such scripts are great, but we shouldn’t expect them to cover all the same use cases as shell scripts. I don’t think Haskell will ever become as good as shell at gluing other programs together.)
3 Likes
I concur with what you said prio. But never say never 
1 Like
After long thoughts, I still cannot get rid of the impression that haskell is focused in research. Not only that dependent types and linear types give off the feel, but seeing that haskell is used in settings typically adjacent to the research (experimentation of novel ideas). It seems to me that lots of programming language research is being done with haskell, and this sparks the little usage in industry.
If so, wouldn’t it be better to focus on research efforts rather than trying to cling to the dwindling industry base? It does not help that there is a looming crisis in software/tech sector, which could decimate the industry.
On the contrary, it’s industry use where Haskell is growing and we have vast potential for more growth. There’s not really any room for Haskell to grow in academia! Can you imagine Haskell use doubling in academia? I can’t. Can you imagine Haskell use growing tenfold in industry? Yes, I can easily imagine that. In fact I think that would be a very unambitious goal.
11 Likes
Interesting, but I do think haskell use could double or more in academia. It’s not like entire academia is only using haskell. In particular, I do not see much haskell usage outside of programming languages research, so haskell could certainly expand there given appropriate opportunities.
Meanwhile, I disagree that haskell use could grow a lot in industry. We are already seeing some shrinkage, while degree upon which could be debatable. Most problematically, industry usage is mainly driven by profit motives, and I do not see haskell’s strength there in current environment. Companies (nowadays) do not care about safety and correctness, they prefer delivering new features quick with least cost as possible. This explains why JS and Python is booming in industry. Meanwhile, haskell is exactly opposite of that.
2 Likes
You don’t if you can write code which compiles at the first try. I personnaly can’t.
At the first (serious) compiling error, the only salvation is often to start adding you typ sigs so that the compiler knows what you are trying to do (you are closing the boundaries of the problem) and can then tell you what is wrong. I some time add type signatures to local bindings to help understand compile error.
So, in theory, yes the code will run without type signatures. In practice it is nearly impossible to write something usefull without writting any. So the selling argument to dynamic typist that they have the benefit of strong typing without having to write any signatures hit reallity unfortunately, pretty soon.
2 Likes
TBH, the trick is more HLS these days, i.e, HLS’s type highlighting gives you, first, a predicted type of your code, and second, will squiggly your type errors as you code.
By just using HLS as an IDE, you can get both “if it compiles, it works” and “it’ll compile the first time” because the type errors will get caught at the development stage, not at the compilation stage.
@Abab9579 The problem with Haskell as a research language is that Haskell is 30 years old. Much of the best and most innovative research in Haskell happened near Haskell’s birth; we still see interesting research these days, like with the delimited continuations primitives, refinement types, linear types, but the pace is much more gradual.
Moreover, Idris has a more advanced type system than Haskell, and will have such for the foreseeable future given the lateness of dependent types. So if you want to do purely theoretical research on type systems, Idris is probably a better bet.
As far as Haskell shrinkage goes; yes, we are seeing shrinkage, but that’s only because we oriented ourselves around safety and correctness, and Rust provides a good-enough solution, paired to better performance, a relatively-easier learning curve, and a bigger developer pool.
However, the point of this thread is that we should see it as an opportunity.
You are right that for most applications, industry doesn’t care about correctness. But correctness isn’t the only strength Haskell has; Haskell can also be more expressive than Python, while being substantially faster.
Despite Hudak talking about Haskell’s prototyping advantages, this is not something we’ve been focusing on, because we’ve been seeking to compete via correctness. Now, with correctness no longer being a viable avenue of competition (we still win vs Rust, but all the other factors make us lose), how about working on ergonomics instead, where Haskell tends to blow Rust out of the water?
An alternative to Rust that is less performant, but substantially more ergonomic, is something that’s competitive (or else everyone would be programming in C). An alternative to Python that is more performant, ergonomic, and correct is also something that’s competitive.
3 Likes
I’m really not convinced we’re seeing shrinkage. I’d like to see some concrete evidence either way. (Granted some notable industrial users have moved away from Haskell, but to show shrinkage you have to demonstrate that equal numbers are not taking up Haskell.)
5 Likes
I don’t think we actually have. People will be tired of me bringing this up again, but:
- lazy IO is all over base
- it took a couple of decades to fix the
type FilePath = Stringdebacle (and will take a couple more) - our Numbers are rather awkward
- the posix compatibility layer for windows is scary… yes, we have a new windows IO manager using proper Win API, but how many decades did that take?
- directory package has questionable cross platform functions
I could go on… but that’s exactly my point: Haskellers seem to have an odd view of what “correctness” is, attributing it more to restrictive, fancy types, rather than robust and well designed primitives.
11 Likes
Agreed, and I elaborate by saying that the important question is what we can compete on, not what local optimum we’ve fallen into by accident. I would say Haskell’s value proposition lies in correct and ergonomic general purpose software development, but we’ve got a long way to go to actually deliver on that proposition.
1 Like
Is this your real world experience with Haskell ?
2 Likes
Sadly, the answer is, “This is true when the language server works.”, and it’s not that hard to break HLS. But we’re slowly getting better at this.
The problem is with or without HLS if I write f a without type signatures and f and a don’t fit, the compiler (and therefore HLS) as no way to tell if a is of the wrong type (I need to convert it somehow) or f as the wrong type (I wrote f = map (+1) but I meant f = map (map (+1) …
Ok I don’t use HLS. Maybe I should I see how it could help with this …
@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