Let me second this. I've worked on a few different supply chain problems over the last five years and Haskell *as a language* would have been perfect—if it only had more libraries. I did do some work in Haskell (which was great), but it just didn't make sense in other areas :/. Modeling problems have a combination of mathematical and domain-specific complexity that lets Haskell's types and expressiveness really shine. Functional programming is a natural fit for this area; most of the Numpy/Python code I see at work sticks to immutable operations. It would not be much of an exaggeration to call Pandas a purely functional DSL embedded in Python. I taught Haskell to one of my colleagues with a PhD in operations research, and he said it was the first time a programming language matched how he thought about his work. Tooling wouldn't necessarily be a bottleneck either. I still believe that friendly and stable tooling is important, but the state of Python tooling—somehow less consistent and more confusing than Haskell's tools—shows that people will work around tooling issues if everything else falls into place. Missing foundational libraries? Not so much. On Sat, Sep 11, 2021 at 10:53 PM Dominik Schrempf < dominik.schrempf@gmail.com> wrote:
Hi!
I am referring to the impressive talk/show/thought-provoking message about "The Historical Futurism of Haskell" delivered by Andrew Boardman at the Haskell Love Conference. I am not sure if I am allowed to link to the talk myself, since it is password protected, and was part of a conference. Maybe this can be done by the conference organizers, or by Andrew himself, if they please.
In summary, and please add your comments or correct me, Andrew discusses that we truly believe that Haskell --- as a statically typed, lazy, pure, and functional language -- is an incredibly powerful tool, that should be made available to everybody now and for the next thirty years. However, he argues that this power is hard to access because we have a lot of "adequate" tooling for a fantastic language. He adds that we need superb tooling in order for "beginners to learn faster, and experienced programmers to accelerate productivity". He refers to overhauling programming environments to reflect data flow across and within functions and to "setting higher standards" for ourselves so that we finally "lift ourselves out of the pit of adequacy". He also asks whether it is really necessary to be in "crisis mode" to invest into fundamental changes of the ecosystem (escalation of commitment).
I deeply agree, and wanted to thank Andrew for his talk. Personally, to me it seemed that Andrew was more referring to the programming environment than to the set of available libraries, although this may not have been his intention. I wanted to express that in my opinion, and in order to drive Haskell forward, we need a qualitative, reliable, performant, and well maintained "standard" library. Haskell has many "adequate" libraries but few superb ones. And while I understand that the immense advantages of being an open source community also come at a cost: a lot of work we do in our free time, because we have limited funding for improving libraries or development environments. Many libraries are maintained by one individual who may have the time and resources (or not) to look at standing issues or possibilities for improvements.
In particular, I am a mathematician/statistician working in evolutionary biology. I work with multivariate distributions (hardly any of those are readily available on Hackage), I work with a lot of random numbers (the support for random sampling is mediocre, at best; 'splitmix' is standard by now but not supported by the most important statistics library of Haskell), I work with numerical optimization (I envy Pythonians for their libraries, although I still prefer Haskell because what I achieve, at least I get right), I work with Markov chains (yes, I had to write my own MCMC library in order to run proper Markov chains), I need to plot my data (there is no superb standard plotting library available in Haskell). By now, I do maintain library packages providing answers to some of these problems, but it was (and is) a lot of work.
Finally, I want to thank all library developers for their impressive work, thank you! And still, I think it is not enough. In my opinion, these are all examples where Haskell needs to improve if we want to broaden the adoption among the general public. Do we have the resources?
Thank you! Dominik _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.