Chris Gray wrote:

...

I'm not sure what your curriculum is, but take a undergrad and grad course in programming languages. They are usually called something like Introduction to Programming Languages, Fundamentals of Programming Languages, etc. You probably won't learn new languages to the extent of being an expert, but you will learn a ton about them.

Usually, you just learn Scheme in these courses (according to my limited experience with 4 or 5 universities).

It probably varies from school to school. The undergrad course I took was a survey of various topics, and we were introduced to Prolog, ML, and possibly Smalltalk. The grad version was pretty much a focus on lamba calculus, and we used Scheme, ML, and possibly ELF. -- Matthew Donadio (m.p.donadio@ieee.org)

...

From a practical perspective, unless you want to pursue a career in academia, you should focus on a language like Java or C++, since these are far more marketable than Haskell.

I disagree.

I'm not sure what you're disagreeing with? That Java and C++ are more marketable than Haskell? That focusing on Java or C++ is a bad idea? I'm not saying ignore Haskell. I'm saying if you spend x amount of time on Haskell then you should spend 2x or 3x on C++ or Java working with the language and surrounding modules/APIs.

A very important skill these days is the ability to pick up a new language quickly. Being familiar with how very different kinds of programming language work is going to get you a long way there.

True.

Maybe it's just me, but if I were a manager managing a large C++ project, I would seriously consider preferring someone who knew a lot of different kinds of languages but not C++ very well to someone who only knew C++ but did know it well. I'm paying for the learning curve anyway.

Unfortunately, it probably *is* just you, which is a pity. As and when you get into management, you'll have a queue of people longing to work for you, believe me! :-) The majority of software project managers in industry recruit people who, as far as is possible, have spent the last several years doing exactly what the job is going to entail. Some might have vaguely heard of functional programming, most wouldn't know what Haskell was if you dropped it on their collective heads. I tried for years to convince various managers to use functional languages, but only ever succeeded once, briefly, and even then they chickened out and had everything re-coded in C++ anyway. The problem isn't usually anything to do with how good a programmer they think you are, how good the language is, or even how much time and money they might save. There is a terror of ending up with a large amount of code, written in an unusual language, that they then couldn't support. In the case I mentioned, the C++ rewrite ended up so complicated (it's an in-memory SQL database engine, weighing in at nearly 17000 lines of code) that as-yet no one but me has attempted to make any changes to it anyway. Another, non-trivial, problem is that corporate managers only like using tools from well-defined, well-supported companies. Everyone wants Visual C++ for this reason. In one project, I was even forced to rewrite a lot of code because the management didn't trust gcc, and the library I was using wouldn't compile on VC++ because it needed partial template specialisation. In many cases, it is literally impossible to persuade management to use open source software, because it is perceived as lower quality and less well supported than commercial software, even though the reality is frequently the opposite of this. I hate to have to say this for all kinds of reasons, but what the FP world *really* needs is for something called 'Microsoft Visual Haskell' to ship as standard with some new future version of Visual Studio, and be supported by a big, expensive marketing effort targeted specifically at corporate managers. Particular attention would have to be given to interoperability with other languages, so managers could be convinced that they had a way out. Even with this, there's no guarantee of takeup -- one customer of mine started out quite happy to use all kinds of technologies, but got burnt, and as a consequence is now extremely conservative. Oddly enough, it was a Microsoft technology, DCOM, that burnt them, because it just quite simply doesn't work properly over anything other than a simple local network, and completely can't handle any network infrastructure that does any kind of address translation. This is in the process of being replaced with a low-level, Berkeley Sockets TCP/IP implementation, which is (they acknowledge) probably what they should have done in the first place. DCOM only managed to burn them this badly because it seemed to work brilliantly, then fell down only when they started to sell their product to larger clients who had bigger, more complex networks split across multiple sites via VPNs. This same customer wont use .NET, because they are afraid of a similar along-the-line disaster. It's also worth mentioning that they have the most technically enlightened management I've come across in years -- these people are by no means stupid or ignorant, it's just very important to recognise that commercial companies want to protect their investment above all else, so they are not keen on taking technical risks. I'm writing from the perspective of someone who has spent 20 odd years in commercial programming, mostly as a contractor. I've been a manager myself on quite a few projects, so I know the issues on both sides of the divide. -- ---------------------------------------------- / __ + / Sarah Thompson **** / / (_ _ _ _ |_ / * / / __)(_|| (_|| ) / sarah@telergy.com * / / + / http://findatlantis.com/ / ----------------------------------------------

Sarah Thompson (sarah@telergy.com) wrote:

I hate to have to say this for all kinds of reasons, but what the FP

world *really*

needs is for something called 'Microsoft Visual Haskell' to ship as standard with some new future version of Visual Studio, and be supported by a big, expensive marketing effort targeted specifically at corporate managers. Particular attention would have to be given to interoperability with other languages, so managers could be convinced that they had a way out.

... [various industry-attitude "horror stories" snipped out] ...

I appreciate Sarah's dose of reality here: I've seen plenty of the sort of thinking she describes during the (short, infrequent) periods I've crept out of my ivory tower and into the real world. Of course with the .NET support of Haskell and the F# effort at Microsoft, we may ultimately get what she describes (wasn't there even an internal MS Visual Haskell at some point?). But before we accept "what the FP world *really* needs", I think we ought to recognize the assumptions behind this claim, i.e., the statement should perhaps read: "IF we want Haskell (or FP more generally) to be widely accepted in the business world, THEN what the FP world *really* needs is ..." And, personally, I'm not sure I *want* to see FP be widely accepted in the business world. I suppose this is some sort of heresy, given the seemingly universal desire by all language adherents to see "their" languages grow to wider and wider acceptance, but I rather like the close-knit feel of the community as it is, and I cherish the set of design principles that community shares. Do we really want every snake-oil salesman around hawking Haskell seminars at $2K per weekend to stuffed auditoriums of business people, showing them how to write imperative code in a monad to do things that might be better done with map or filter? Could we accept an ISO standard that elevated unsafePerformIO and such-like to a new level of acceptability? I think it was John Launchbury who made a case at the Pittsburgh Haskell Workshop for letting Haskell stake out a certain extreme on the language design spectrum, one which supports formal reasoning through functional purity; I think this is a noble purpose the language serves. We even seem to be having some influence on the mainstream of language development: the recently-announced enhancements to Java read like a subversive attempt to inch that language toward FP style (and, hmmm, there is Martin Odersky's name on some of the Expert Group listings :) ); see http://java.sun.com/features/2003/05/bloch_qa.html. Of course, it would be nice to have more "warm bodies" to devote to projects like standard GUI libraries, browser plug-ins, IDEs, language inter- operability, etc. (no sleight intended to current efforts). But I think this is a question of getting more of the *right* people involved, rather than spreading the word to the business masses. Personally, I try to help in this effort by teaching my (liberal arts undergrad) students about FP and its sensibilities and then steering the best of them to compatible graduate schools. It may not be much, but I think quality is more important than quantity (besides, with recent FP class sizes of 6 and 9, I really can't contribute much quantity anyway! People like Manuel Chakravarty can probably afford to do both, see http://www.cse.unsw.edu.au/~chak/teaching.html). So, call me an elitist and bring the torches to my (ivory) tower door, but I have to question whether *broad* acceptance is what FP (or Haskell) really needs. -- Fritz Ruehr

Andrew J Bromage wrote:

Maybe it's just me, but if I were a manager managing a large C++ project, I would seriously consider preferring someone who knew a lot of different kinds of languages but not C++ very well to someone who only knew C++ but did know it well. I'm paying for the learning curve anyway.

The problem is that Dilbert is usually closer to real life than most people think. I had a software manager who actually believed we could speed up a program by removing the comments from the code. -- Matthew Donadio (m.p.donadio@ieee.org)

So are there companies that pay people to write in Haskell, .. I do know of Galois Connections in Oregon; are there others?

Sure. If you look through the Haskell Community and Activities Reports (doesn't anyone read those anymore?-), you'll find some Haskell employees (apart from the obvious Microsoft and the secretive Galois, Xilinx, National Semiconductor, Aetion Technologies and Reid Consulting have been mentioned, Tom Pledger has been writing about a Haskell-like DSL for business data processing he is working on for his employer, the PDF group at Heriott-Watt lists some industrial collaborators, ..). We haven't seen reports about Sandburst/ BlueSpec, and there have been contributors with commercial affiliations who haven't admitted to any connections between their work and Haskell interests, so I'm sure there are more silent runners.. It would be nice to hear from others using Haskell on their jobs, even if there's no official company policy about it and no prospect of new Haskell-related jobs at their place (only Galois and Cesarini Consulting are listed in the Haskell "positions in industry" category at haskell.org - perhaps there should be a more general "current Haskell employers" category instead?-).

or indeed in any functional language?

Now, that is an entirely different situation: if one includes Lisp, Scheme, Erlang, etc. (not to mention in-house languages) then commercial fp applications are so long-established that functional programmers are hired and fired like anyone else. The weekly job summaries on comp.compilers used to be helpful.. A completely different question is whether anyone is hiring right now.. Good Luck! Claus http://www.haskell.org/communities http://www.haskell.org/jobs.html