I just read this page and the four linked blog posts. There isn’t very much consistency in the detail about what constitutes simple/boring Haskell, short of an admonition against so-called “fancy types” enabled by some GHC extensions and a bit of name-dropping about certain packages. The motivation seems to be aimed at making Haskell development in industry have less variance so that it can grow more quickly, in the name of “inclusion”. There’s also some odd animosity toward researchers’ tendency to use Haskell as a research tool, as though somehow this causes industry practitioners to reach for fancy types over simple/boring Haskell.
I agree with the idea of preferring simple code over complex code, but I find myself repelled by the arguments in all four posts and the “isn’t it obvious” attitude of the landing page.
The authors’ message might be more well received if they framed this in terms of the tradeoffs between examples of simple/boring implementations and their fancy types counterparts. Right now it reads like a crusade and smacks of more unnecessary division in the Haskell community.
I think any of these kinds of software development “manifesto” documents read like a crusade. I’m all for shipping boring simple Haskell code, but I agree a better approach would just be a bunch of “cookbook” style articles demonstrating building simple things with simple Haskell.
I realize that this was made in the context of recent discussions, e.g. those blog posts. But what makes it an “initiative”? If I put the badge on a project, what am I saying? That my project is plain Haskell2010? That I use some blessed list of extensions? Which?
Haskell memes are eating themselves, it would seem.
There are as many opinions on what constitutes Simple Haskell as there are people who have them.
We don’t want to endorse any one view, but promote the the general idea.
Following that are three bland paragraphs about the corporate benefits of accessibility, maturity, and (not) leaking complexity.
Does anybody really want for their code to be used by corporate hackers who aren’t going to contribute any money or time back to their library? Does anybody really want to bend over backwards and ensure compatibility with a corporation-approved list of ancient standards and extensions? Not really, I bet. But everybody loves “simple”.
For my open source projects I’m not too concerned with it, but as someone who’s dealt with one bait and switch after another in the corporate world taking Haskell jobs only to make it 6 or 12 months in and management starts getting irrationally twitchy about having the business successfully running on code that’s written in Haskell, I hope that empty gestures like this might be the start of the spin we need to stop Haskell from getting constantly evicted from the corporate world.
I just read this page and the four linked blog posts. There isn’t very much consistency in the detail about what constitutes simple/boring Haskell, short of an admonition against so-called “fancy types” enabled by some GHC extensions and a bit of name-dropping about certain packages. The motivation seems to be aimed at making Haskell development in industry have less variance so that it can grow more quickly, in the name of “inclusion”. There’s also some odd animosity toward researchers’ tendency to use Haskell as a research tool, as though somehow this causes industry practitioners to reach for fancy types over simple/boring Haskell.
I agree with the idea of preferring simple code over complex code, but I find myself repelled by the arguments in all four posts and the “isn’t it obvious” attitude of the landing page.
The authors’ message might be more well received if they framed this in terms of the tradeoffs between examples of simple/boring implementations and their fancy types counterparts. Right now it reads like a crusade and smacks of more unnecessary division in the Haskell community.
I think any of these kinds of software development “manifesto” documents read like a crusade. I’m all for shipping boring simple Haskell code, but I agree a better approach would just be a bunch of “cookbook” style articles demonstrating building simple things with simple Haskell.
What is this?
I realize that this was made in the context of recent discussions, e.g. those blog posts. But what makes it an “initiative”? If I put the badge on a project, what am I saying? That my project is plain Haskell2010? That I use some blessed list of extensions? Which?
Who’s behind this?
To me this reads as an attempt to create an “enterprise Haskell” which can then be used to sell consulting hours - implementation or training.
Haskell memes are eating themselves, it would seem.
Following that are three bland paragraphs about the corporate benefits of accessibility, maturity, and (not) leaking complexity.
Does anybody really want for their code to be used by corporate hackers who aren’t going to contribute any money or time back to their library? Does anybody really want to bend over backwards and ensure compatibility with a corporation-approved list of ancient standards and extensions? Not really, I bet. But everybody loves “simple”.
For my open source projects I’m not too concerned with it, but as someone who’s dealt with one bait and switch after another in the corporate world taking Haskell jobs only to make it 6 or 12 months in and management starts getting irrationally twitchy about having the business successfully running on code that’s written in Haskell, I hope that empty gestures like this might be the start of the spin we need to stop Haskell from getting constantly evicted from the corporate world.
I knew my time would come! http://www.monohaskell.com/