38 ms·

What Do You Think Is Impeding Haskell From Getting Mainstream Adoption?

5 points by lelf 13y ago

narag 13y ago
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?
- deleted 13y ago
  [deleted]
- malandrew 13y ago
  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.
malandrew 13y ago
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.js#L143 https://github.com/sequelize/sequelize/blob/master/lib/hooks... 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.

5 points by lelf 13y ago

narag 13y ago

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?

deleted 13y ago
[deleted]
malandrew 13y ago
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.

malandrew 13y ago

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.js#L143 https://github.com/sequelize/sequelize/blob/master/lib/hooks... 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.