[Haskell-cafe] Comment on "The Historical Futurism of Haskell" by Andrew Boardman

[Anton Antich]

I love Haskell, as probably anybody who has finally understood “how to cook it”. Took me 3 attempts to really get it though - and my experience is quite similar to a lot of developers with imperative background. I’ve worked with large teams of developers both in the enterprise environment as well as in some 20 startups I’ve invested into. I’ve tried to push haskell on all of them, half-seriously, to try to understand why wouldn’t they use it? 

I would say the most popular reason by far is - very steep learning curve for any imperative programmer.

Not the libraries (even if we could use more for some specific domains), not the tooling (even though I can envision an IDE for Haskell that would make development experience such a delight - imagine visualizing monad transformer stacks and function composition with types?!), not that GUI sucks (we really need a good GUI library) - but difficulty learning the concepts to become proficient.

Somewhat arrogant approach of the libraries authors to the documentation - the whole “type signature *is* documentation” - doesn’t help either.

So, again, I love Haskell, went a difficult road understanding how it should be taught by mastering it myself, which actually lead me to writing a book on teaching Haskell from the first principles, focusing on types, but gently and in pictures so that it’s accessible - https://leanpub.com/magicalhaskell - for which id love feedback by the way :)

But we need to teach FP much better in CS schools - there are a zillion courses on Python and how Many on Haskell? We have to write more tutorials and much friendlier documentation. We have to explain real world patterns much better and with more examples - normally all Haskell docs and even examples are way too abstract, which is solid science but doesn’t help for the mass adoption. And then, yes, we need libraries and tooling.

Best wishes,
- A.

> On 12 Sep 2021, at 18:17, Dominik Schrempf <dominik.schrempf at gmail.com> wrote:
> 
> 
> Henning Thielemann <lemming at henning-thielemann.de> writes:
> 
>>> On Sun, 12 Sep 2021, Dominik Schrempf wrote:
>>> 
>>> I work with Markov chains (yes, I had to write my own MCMC library in order to
>>> run proper Markov chains),
>> 
>> I don't know what proper Markov chains are, at least I wrote my own simple lazy
>> Markov chain generator years ago that fulfilled my needs:
>>   https://hackage.haskell.org/package/markov-chain
>> 
>> I have also written a package for Hidden Markov models:
>>   https://hackage.haskell.org/package/hmm-lapack
> 
> Thank you for mentioning this. I was playing around with 'markov-chain' some
> time ago! I was referring for something more generic, for example, where the
> transition rate/probability matrices can be directly defined. I am not so
> familiar with hidden Markov models. With respect to the term "proper", thanks
> for picking that up :); I should have been more specific: I was referring to
> Markov chain Monte Carlo samplers. For a reference implementation, please see
> the 'mcmc' library in R [1], for a feature-rich one, e.g., 'PyMC3' [2].
> 
>> 
>>> 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.
>> 
>> If you write packages that fulfill the needs of your applications, that's
>> certainly better than writing impressive frameworks where no one knows 
>> whether it is usable, at all. :-)
> 
> You are right, we want to avoid impressive but unusable frameworks. I was
> referring to the following question: "For a given goal, which features do I have
> to implement myself in order achieve the goal?" With the existing set of Haskell
> libraries, I make the following observation too often (or too early in my stack
> of requirements): "This feature is not available (or not readily available), I
> need to implement it myself." For example, at the moment I am working on a
> library for estimating covariance matrices from sample data. This is not at all
> my area of expertise. In Python and R, well maintained state-of-the-art methods
> are readily available (e.g., shrinkage based estimators such as the Ledoit-Wolf
> estimator, or oracle approximating shrinkage, as well as estimators based on
> Gaussian graphical models such as the graphical lasso --- actually, there is a
> glasso library on Hackage but it seems unmaintained, lacks documentation, and
> improvements from newer findings in the last 10 years).
> 
> I hope I made myself clear. I don't want to naysay. I really enjoy Haskell per
> se! I am a big fan.
> 
> Dominik
> 
> [1] https://mran.microsoft.com/snapshot/2015-02-27/web/packages/mcmc/index.html
> 
> [2] https://docs.pymc.io/
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210913/6a3e2739/attachment.html>