“Late” is good. The alternative is “never”. The entire initiative hangs by a thread, as there aren’t many people working on adding dependent types to GHC.
I’m rather lucky to be able to work on Dependent Haskell at Serokell, but if I get hit by a bus or if the funding runs out, I can only hope that someone else will pick up where I left off.
I made a type
Of course you can use Haskell without understanding Monads, but would hire someone to work on a haskell code base which doesn’t want to learn and understand Monads
Should have been “would you hire somene … ?”
Maybe it makes a difference.
Anyway, I don’t think I disagree. What I am just trying to say is that people who find monads “fun and enjoyable” (I’m one of them) are usually not the one who learn a program language reluctantly.
I’m more oriented on breaking down resistance to Haskell; i.e, there can be dialects of Haskell that resemble what people are used to, without alienating industrial users by telling them they have to complete a master’s degree in functional programming (which, of course, doesn’t exist) before they can start using Haskell.
The idea is more slow infiltration; i.e, start with main = do, wire together library functions, then learn how an FP language can achieve the same things an imperative language can, as opposed to throwing HaskellBook at someone and hoping it sticks.
Given the average knowledge of industrial users (Haskell has been attacking at the high-end, but Rust is starting to block that off), showing Haskell that the average developer or IT manager can understand is useful.
Re: @hasufell: I agree with your points concerning how Haskell can be branded. I just disagree strongly with the notion of introducing and pushing Haskell through its most cutting edge and experimental features; i.e, the average developer or IT manager would feel professionally threatened by what is really a completely different paradigm, rendering much of their existing knowledge useless, and infiltrating Haskell by its similarity to what they already know would be more successful.
Are you sure pythonistas are willing to move to Haskell (or any other static typed lang)?. I’ve been a python developer (exclusively in the field of data science) for 8 years, and whenever I proposed to my colleghes to use a different language (commonly scala's spark) or to use python’s type hints I’ve got the response: “I prefer to quit than using types”
Moreover, not just one, but two managers have told me “stop proposing typed language” (they did kindly, written down seems more dramatic that the actual conversation). The simple reason: most developers I work with do only know python. They are completely unaware that languages with types exists, and when they see type hints in a python code, the tend to frustrate because they add verbosity to the language.
Notice that me background is exclusively data science/data engineering, and my sample of coworkers are phicisits, mathematicians, electric engineers, etc… probably just 5% of my coworkers have had a degree in CS. So probably I am biased, but I’d say pretty much 0 pythonistas would like work with Haskell
Yes, some people don’t like type. I remember when I was writting C++ (20 years ago).
People hated compilation errors but like runtime error. With compilation errors, they felt they hit a wall . They frustrated with the compiler refusing to understanding them. Rutime errors was a different story, they could debug and see what was going wrong. Telling them that the compiler was their friend trying to help them didn’t work.
I’ve noticed the same thing. Large amount of resistance to consider anything else but the status quo.
However, I refuse to believe that there are people out there who are so set in their ways that they wouldn’t consider an alternative. Rather, there needs to be a very high upside for some people.
I can’t help with data scientists, quants and data engineers, but here’s something for managers.
I work in proprietary trading, and I’ve been tasked with assessing the cost of production bugs. Every bug in production costs two things:
We have a failure rate that’s pretty low. I can’t give the numbers exactly, but think in units of bugs / month. And yet, in the past year, just in terms of Python’s TypeError and related errors, i.e. things that static typing would have caught at compile-time, we could have saved something on the order of person-years. Assuming that new bugs pop up as new ones get squashed – which is likely given that we keep expanding to new products and markets --, there is a tangible financial incentive to consider static typing. In fact, we have been experimenting with Haskell for this purpose, and now we have firm numbers backing our decision.
TBH, while this isn’t proper TyDD, a funny thing you can do with HLS is just write a function or value, and watch the shadowed type signature change. When you are doing something wrong, the types make no sense. When you’ve completed your definition, just click on the code shadow and your type signature shows up.
One of the big advantages of Haskell’s approach to type signatures is that we don’t actually need the type signature in code most of the time. The type inference engine is powerful enough to guess the types most of the time, and an type-sigless style can work, albeit be smelly.
Do your Pythonista coworkers accept docstrings? Knowing what I know of the Python community, I wouldn’t be surprised if there were Pythonistas who hate docstrings, but introducing a type signature, something that strictly exists outside the code and comments existing code, might work.
I hope this isn’t too shocking, and I hope no one actually ships code into production without type signatures, but as a way of getting crap under the radar, the ability to avoid type signatures 95-99% under the time IS a way to sell strict static typing to dynamic typing addicts. Gradually, they’ll discover that it’s better to have a type signature most of the time, just to get the compiler to give better errors on what went wrong, just as some Haskellers go so far as to type sig all their where-clause code.
Also, for Python code golfers, one of the interesting parts of Haskell to me is that it is actually quite easy to get idiomatic Haskell code to be so terse as to be unreadable. We literally introduce garbage and unnecessary names just so that someone reading the code knows what the hell is going on. That’s a sellable feature.
I wouldn’t be surprised if there were Pythonistas who hate docstrings, but introducing a type signature, something that strictly exists outside the code and comments existing code, might work.
If we’re being pedantic (pydantic?) “type signatures” (I think the normal nomenclature in Python is “type hints”) are available at run time in Python, and are able to be used to determine behaviour. I have worked with Python programmers who never run a type checker like mypy over their code, but write types, just so they can use libraries like pydantic or fastapi.
No type inference, way less useful typing errors, way more cryptic messages, I think during these 20 years there has been great progress in static typing and compilers (and not only in Haskell/FP).
Haskell has type sigs. We use them all the time because they’re idiomatic, but your code will often run if you leave them off. This idiom mostly happens with newbies and people who are learning Haskell, because taking the type signature off makes Haskell a bit simpler to read and write.
I think the main problem comparing with Python is that Python has many target users. For example, Python is a great scripting language, and a great language for prototyping. The thing I love about Haskell is it forces you to think about the types you actually want and handle all the cases, but that’s not always what you want. If I want a quick script that’s mostly portable, fairly small/limited in scope, and I’m fine with making assumptions, Python is perfect.
If we’re talking about production systems, etc etc, I’m 100% on board with evangelizing Haskell more. But we should recognize that there are valid use cases for keeping things in Python, even as a die-hard Haskell enthusiast as myself
I just wanted to both expose a class of users you may not have been aware of, as well as to clarify that type hints in Python are very much things that are used at run time (which seemed at odds with the statement “strictly exists outside the code”), in contrast to languages like Typescript or Haskell (after typeclass dictionaries have been inserted) where they are erased.
Taking the type signatures off often makes Haskell a lot harder to read IMO, but that’s a discussion for another time. However, even ignoring ambiguity and all the language extensions that interfere with inference, there are cases where they are genuinely mandatory, for example polymorphic recursion.
data Splitting a = Val a | Split (Splitting (a,a)) deriving Show
collect :: Splitting a -> [a] -- See what happens when you remove this
collect (Val x) = [x]
collect (Split x) = concatMap (\(a,b) -> [a,b]) (collect x)
Why do you … “want” more commercial adoption ?
IIRC : In this talk Uncle Bob says “Memory is cheap, dirt cheap - everyone has in its pocket a thumb drive or a phone with an sdcard orders of magnitude larger than our wildest dream in 2000 … the real next fight of moore’s law is multicore programming … and Haskell (and FP) shines at it”
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.
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.)
I concur with what you said prio. But never say never 
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.