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:
Sometimes you have to contact the maintainer directly, some people unsubscribe from pull request notifications.
0.)Thank You for your fine work
1.)This confirms the diagnosis of the 'system integration
challenge/problem'
1a.)parts of 'THE PROBLEM' include cabal hell;
conflicts on names (hiding), etc.
2.) nonprofit, open-source, specialist global amorphous
org AKA 'HASKELL' or substitute word Java - no... that's
a nightmare is important for the world runs on software
and not really ... mathematics.
3.) the global challenge of non-profits is talent management.
Mismatch is much more dynamic and I argue effective
in the 'real world market' - hire and fire.
4.) personal experience: no, never in my non-profit experience have I thought of FIRING/termination only the
last 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 does
take 'patiences' and even troubleshooting/hacks to get it
'reasonable mode' on Void Linux - static compiled with musl
library.
7.) perspective: I am not a full 'engineer', have had
other careers however even I know that the follwing is
unsafe - risky - 'impure'?
7a.)case: Apple gotofail gotofail repeat twice
7b.)case: vuln reports on glibc
8.)conclusion Strategy: maybe the process of position of
maintainer - should be 'rotated or team bundled'?
9.)the routine strategy is reasonable patches, process
acceleration - insert humor here - cartoon with Linus,
founder swearing - after all it is 'obsoleted C specialized
code'
and i can't think of not good but great solutions
for after all python has 2x and 3x versions
10.)perhaps the best strategy is:
four branches
branch 1: simplified for the learers
branch2 : python coder moves to haskell - go with stack
branch 3: low level using cabal. (cabal still breaks
at least for me)
branch 4: mid level - full use of leksah, etc.
branch 5: advanced level - that is YOU
branch 6: super-advanced level - etc.
dead and 'twisted branches' may be move to the alternative
tree trunk, perhaps?
IMHO. My opinion could change and it could be wrong.
the assumption is practical and even competitive with
'other languages'
Post a Comment