- More Haskell jobs would emerge
- People would find it easier to introduce Haskell in a work place
- Less C in the world
- More reliable software
- Elegance and beauty
Of course, there are also downsides to Haskell being more popular:
- Bigger communities aren't always as friendly
- Commercialisation will loose some benefits of Haskell (open source etc.)
- The volume of beginners will outweigh the experienced professionals
- Managers might push Haskell for entirely unsuitable things
So, question, do we want Haskell to be more popular. At the moment I quite like the fact that when programming I can be much faster than other people, and have far fewer errors. It would however be nice if I could get a job doing Haskell at some point, rather than becoming a C monkey once more, which will be doubly painful after experiencing so much Haskell.
My personal view on how Haskell can be made more popular:
- Remove features, generalise features, do not add features. I don't understand/know rank-n types, template Haskell, GADT's, impredictive polymorphism, arrows... Beginners don't want to know either! Getting the features right is good, which may mean adding features, but not necessarily.
- Continue to be polite and helpful
- Promote Haskell as a programming course
- Promote Haskell to experienced programmers looking for something new
- DO NOT promote Haskell in industry, if you force this on to people, they'll just discover we are not ready for this yet!
In my opinion, we do plenty of advertisments already. There is not nearly enough coding going on, Cabal could benefit from extra contributors, I know Yhc could etc. When the tools are ready the users will come, and then if they don't come naturally, we can prod them. Until that time the steady flow of new users is plenty.
4 comments:
One could argue that many of the feature examples you give are generalizations. For impredicative polymorphism and rank-n types, I know I didn't understand at first why they were disallowed. Putting them in the language allows a more consistent view of types by bringing polytypes/type schema closer to usual types.
So, perhaps we shouldn't teach beginners impredicative polymorphism or rank-n types, but leave them there if need be. Beginners who are interested in generalization will run across the need for these and see that these are the larger concepts that they were already familiar with.
The same might be said for GADTs, which have "generalized" right in the name. :-)
Hi Jim,
Yes, I agree, many of the features are generalisations. So should we kill normal algebraic data types? Are there disadvantages of GADT's we don't yet know? Rank-n types cost us inference, is that too high a price to pay?
I'm not saying any of those features are wrong, I'm saying we need to take time to decide if they are the right generalisation, and once we (the Haskell community) have decided what Haskell really is, then we can go and tell people "this is Haskell" - instead of talking about Haskell + random extensions.
If I was in industry, I wouldn't use GADT's at all. Their type checking behaviour changes between releases - entirely unacceptable for a commercial interest. That said, in a few years, they may be exactly what is wanted.
[Random point: why the hell do I have to pass a Captcha to post to my own blog!]
I would love to see Haskell become more popular - it'd mean I could use it at work!
I think there are some mundane but rather important issues with Haskell though that need resolving - mainly fairly boring things to do with syntax and facilitating software engineering practises which the academics aren't necessarily interested in refining. And I think these do act as obstacles to its use in big commercial projects - at least those which aren't heavily comp-sci / science / math - related.
I'm just trying to learn Haskell and the type system is driving me nuts. GADT's don't make it worse, they are a huge relief. I just spent hours of head scratching trying to figure out how to write types for expression nodes (say in a C compiler) without having to write more and more deeply nested expressions and handle a lot of bogus cases. The answer turned out to be GADT's. So I think they are really essential for beating back the type-system bureaucracy that the Lispers keep bagging on.
Post a Comment