[Haskell-cafe] Non-technical Haskell question

[Graham Klyne]

I find myself agreeing with the implied likely response to all of the 
points you raise below.

I'd say that any attempt to proselytize Haskell (or any new technology) 
needs to start from a clear view of one kind of application that it is 
particularly good for.  Then, focus on building a "bridgehead" for that 
narrow application area.

For example, I've been using Haskell to experiment with reasoning tasks on 
Semantic Web data -- it's an application for which Haskell seems to be 
eminently well-suited, for the following reasons, among others:

* functional expression (as opposed to imperative) means that the reasoning 
programs are more closely related to the reasoning tasks being performed.

* its type system ensures that necessary formalities of mapping concepts to 
representations are fully expressed.

* lazy evaluation makes search-and-backtrack patterns very easy to program.

* Higher order functions facilitate separation of concerns.

In short, for this kind of application, I find that I spend most of my time 
thinking about the problem space, relatively little time programming 
supporting "scaffolding", and very little time debugging (once I've got the 
types to match up).

This is my story.  I don't know if there's anything here you can use.

#g
--

At 10:45 03/12/04 -0500, Jason Bailey wrote:
>Here are some questions that I would expect to get from business.
>
>Q:"What have I heard about this technology?"
>A: Probably nothing. Haskell isn't very well known in the programming 
>community (out of 6 co-workers asked, one had used Haskell in a single 
>college class), let alone the business community. Business has become very 
>wary about accepting technologies that are obscure.
>
>Q:"What can I do with this language that I can't do now?"
>A:Well nothing. It can certainly do some things better then the current 
>languages out there, but its just another general purpose language.
>
>Q:"Will it require training?"
>A: Oh yes, we're talking about a different way of looking at programs. On 
>the surface level it should be fairly easy to pick up but it will take 
>some time before the engineers are able to produce decent work. Oh and 
>there are no training classes we can send people to. They will have to 
>learn on their own.
>
>Q:"Whats the market like for Haskell programmers?"
>A: Well there isn't one. Which means that if business was going to 
>advertise for someone with haskell programming knowledge they are going to 
>end some spending a premium on them.
>
>Q:"Why should we support yet another programming language?"
>A: Because this is a better language. (Wouldn't work as an answer but I 
>would give it a try. )
>
>And this is just the business side. I kinda shudder at the thought of 
>telling a room full of engineers that they need to abandon their current 
>status as object level gurus and learn some language that the majority of 
>them have never heard of. :)
>
>I think the most important aspect of getting haskell acceptance is mind 
>share. Both from a  programming perspective and a business perspective. 
>People need to have heard of haskell and be familiar with the concepts 
>behind it before they will be willing to give it a try. Also the larger 
>the corporation the less likely this is going to happen. But with mind 
>share I can see smaller corps and smaller IT departments moving over to it.
>
>Jason
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact