In this blog I talk about some of the personal programming I do as a hobby. By trade I'm a Java and database developer but I've dabbled in Haskell, front-end development, etc. I'm currently working as an architect but still enjoy getting my fingers dirty in code!

Tuesday, February 23, 2016

Haskell Through of Disillusionment

I'm going through a hard pass with Haskell. I still love the language, of course, but some things in the ecosystem bother me as they impact seriously both the fun of writing Haskell and my productivity.

Sometimes it's the lack of good development environment that gets me. I have failed with EclipseFP to build a community and gather enough support, but it doesn't seem that other efforts go that much further. I contribute to Leksah and haskell-ide-engine, and there a plugins now for Atom or other modern editors, but when I do a spot of Android development I see what a good IDE is and how much I miss in Haskell.

But today it's more the open source libraries issues that irks me. It's great that we have loads of libraries, and they're open source and usually good quality. But of course the maintainers are all volunteers, and sometimes have better things to do. But there are a few libraries that I use in my code that now actually stop me from progressing. I have provided enhancements or bug fixes that I need for my projects as pull requests, and they languish in the maintainers' inboxes for months. So what am I to do? Hound the maintainers? Fork the library to apply my patches? Rewrite my code so it doesn't use that library but another, better maintained? Not use libraries but write everything myself? And of course if I offer to take over maintainership I'll end up being overloaded and will perpetuate the problem. I suppose the best approach will be to offer to be one of MANY maintainers for the library, so that I can merge my changes and release on Hackage if the others maintainers are otherwise busy/uninterested. I'm not sure how that can work in the general case, though, if loads of people are maintainers for loads of libraries, I believe that having one person with the vision and the drive for a project is best, but for little libraries it may not matter much.

3 comments:

0.)Thank You for your fine work1.)This confirms the diagnosis of the 'system integrationchallenge/problem'1a.)parts of 'THE PROBLEM' include cabal hell;conflicts on names (hiding), etc.2.) nonprofit, open-source, specialist global amorphousorg AKA 'HASKELL' or substitute word Java - no... that'sa nightmare is important for the world runs on softwareand not really ... mathematics.

3.) the global challenge of non-profits is talent management.Mismatch is much more dynamic and I argue effectivein the 'real world market' - hire and fire.4.) personal experience: no, never in my non-profit experience have I thought of FIRING/termination only thelast resort - leave it in better shape and MOVE ON.that means resignation. that is the organization culture.5.) case examples: Haskell is 'experimental' and research oriented - highly influenced by academics.6.) a success is stack version 1.03 x86_64. It doestake 'patiences' and even troubleshooting/hacks to get it'reasonable mode' on Void Linux - static compiled with musllibrary.

7.) perspective: I am not a full 'engineer', have hadother careers however even I know that the follwing isunsafe - risky - 'impure'?7a.)case: Apple gotofail gotofail repeat twice7b.)case: vuln reports on glibc

8.)conclusion Strategy: maybe the process of position ofmaintainer - should be 'rotated or team bundled'?

9.)the routine strategy is reasonable patches, processacceleration - insert humor here - cartoon with Linus,founder swearing - after all it is 'obsoleted C specializedcode'and i can't think of not good but great solutionsfor after all python has 2x and 3x versions