
What Do You Think Is Impeding Haskell From Getting Mainstream Adoption? - lelf
http://www.forbes.com/sites/quora/2014/04/29/what-do-you-think-is-impeding-haskell-from-getting-mainstream-adoption/
======
malandrew
It's missing bugs that most developers consider features. I know that sounds
snarky, but its roughly accurate. Haskell is great for not only what features
the language has but also what features the language does not have. It's
practically impossible to shoot yourself in the foot with it.

Assuming widespread adoption was a goal, I think Haskell could stand to learn
from the Rust community. They could force you to explicitly declare when you
want to write unsafe code. Rust does something like this with pointers. You
need to go out of your way to use an unsafe pointer, but you can do so in the
name of expediency.

I would love it if more language chose to gently coerce me into writing better
code than one that doesn't allow me to write bad code. The former reduces the
learning curve that normally kills adoption. A language you never adopt is a
language you never learn from.

Coding in any language really should be a conversation. Besides executing the
instructions you give it, languages should also be designed to teach you to
code more intelligently and using its idioms.

Just the other day I was thinking about how you would take an abstract syntax
tree and analyze functions to determine which ones are extremely similar and
could be reduced to a fewer lines of code. Take this code from
sequelize/sequelize for example:

[https://github.com/sequelize/sequelize/blob/master/lib/hooks...](https://github.com/sequelize/sequelize/blob/master/lib/hooks.js#L143)

Any sufficiently smart static analyzer should be smart enough to highlight the
reduncy and highlight duplication to make you aware of it and make you think
about how to reduce it. That could could be reduced to this pattern:

    
    
        [ 'beforeValidate', 
          'afterValidate', 
          'beforeCreate', 
          'afterCreate',
          'beforeDestroy',
          'afterDestroy',
          'beforeDelete',
          'afterDelete',
          'beforeUpdate',
          'afterUpdate',
          'beforeBulkCreate',
          'afterBulkCreate',
          'beforeBulkDestroy',
          'afterBulkDestroy',
          'beforeBulkUpdate',
          'afterBulkUpdate'
        ].forEach(function(methodName) {
          Hooks[methodName] = Hooks.addHook.call(this, methodName, name, fn);
        });
    

129 lines down to 16; Even the generation of that array could be reduced to
one that constructs that array from individual words. That would probably be
excessive code deduplication though.

------
narag
The reason PHP got so popular is not it was included with Apache (?) but that
it allowed to _get shit done_ (GSD).

That it got wildly popular is because GSD usually just involved cutting some
example code and pasting it on a web page changing some literal strings.

The GSD thing I would also say of C++, Perl and Ruby. Java, not so much. That
was another story.

About Haskell, I don't know it. But I'm curious: does it allow you to GSD?

~~~
malandrew
Not so much GSD, but it does allow you to GSR ... Get Shit Right. When
correctness is a goal, languages like Haskell, Java and Ada are may be the
better tool for the job. They impose restrictions the force you to design
correctness (Haskell) or impose bureaucracy (Java) that make it more likely
that code does what it is supposed to do.

Haskell could achieve the same success as Java by teaching how to think about
achieving correctness in thought. This often means teaching people to take the
concrete concepts in a domain they know and move down successive levels of
abstraction until you've broken down your problem into many pure functions.
Few developers have given enough thought that this is second nature to them
and fewer still are give jobs where they are afforded the luxury to do the
necessary thinking up front about a problem to write things correctly the
first time.

Businesses demand to see progress. If a language doesn't allow to quickly show
progress to your peers, it's less likely to see adoption. With haskell
complete solutions may only come together at the end when you put all your
provably correct functions together.

Dynamic loosely typed language also lets you explore your problem space in
code, whereas haskell forces you to explore your problem space as abstract
ideas. When you don't know what you're building because the problem domain is
foreign then the former feature is an asset for most developers.

