Commercial Haskell should go after Python / Julia, not Rust

#41

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
#42

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
#43

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.

#44

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.

#45

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

#46

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
#47

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.

#48

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
#49

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.

#50

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
#51

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
#52

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
#53

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
#54

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
#55

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
#56

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
#57

That goes more into my criticism of the library ecosystem, no? The documentation often expects a level of skill or experience that’s beyond the basic level needed to be productive in Haskell; i.e, it’s typically geared at intermediate or advanced Haskellers, and is thus newbie hostile.

But I can see what you mean, if you define the level of Haskell needed to be productive as being able to work independently with the libraries, there is a considerable skill requirement and Haskell is “hard”. On the other hand, for production purposes, if there’s hand-holding or internal guides on how to use the libraries employed, then this needn’t be a problem.

@kindaro

This is just my opinion on libraries that are needed, but:

Accelerate, as far as I can tell, has not substantially improved from its condition last year, where Accelerate was bound by default to older 8.x GHCs. The GitHub version seems to be updated, and I’m trying to get that working right now.

Brick and vty is a relatively key library for TUI, but while its maintainer put out a request for assistance back in the 2010s, it’s only now beginning to get work done on providing Windows support.

There’s the issue with Haskell Tensorflow (Google seems to have abandoned it) and the slow maturation of Hasktorch (there’s a disclaimer on the Github saying that the Hackage version’s use is discouraged).

As far as necessary libraries in general, many libraries need simpler APIs that are more suitable to newbies, because while many people can get past HPFFP or other Haskell learning materials, when they get to the actual Haskell ecosystem, they have maxigit’s experience, which can get people to give up.

In general, Haskell libraries tend to be designed for a very high level of power and composability, but while that’s a good thing in general, it’s often very newbie hostile.

I remember clearly Aeson failing to impress an acquaintance, for instance, because while the type structure ensured greater safety, it was, well, less ergonomic, and at the time, I couldn’t figure out how to work directly with the Value type.

1 Like
#58

I love it. May have to steal that format for other things!

2 Likes
#59

image

13 Likes
#61

If I may I digress a bit, and use another way of looking at it:

I have noticed a subtle (developer) cultural thing, people slapping “rust-based” onto their project with pride. It’s like fashion, you want to be “in”, in the cool kids camp.

I think it would be out of character for Haskell to be the “cool kid” again, it would be like middle aged person going to a rave party.

Using this lens, I think what Haskell could go after is to find a cool kid spokes man to revamp the image of Haskell, iff we think staying culturally relevant is the key to survive as a project.

3 Likes