Juan Carlos Arevalo Baeza writes:

And it's a good quest. I see three problems that prevent me from seeing Haskell as a "Real World" language.

First, compiler support. Second, debugging tools.

I agree these could be much better (though I don't think people really whacked on your code with their debugging tools). Unfortunately, research groups (the people who develop the compilers) don't have the resources to both do research and push hard enough on portability, ease of installation, documentation, etc. It'd be great to have people whose full time job was to tie up all the loose ends in the tools (portability, error messages, documentation, etc., etc.), help people use the tools effectively, develop cool libraries, provide consulting services, etc. In other words, it'd be nice to have a Cygnus-like company to support Haskell developers the way Cygnus supports C/C++ developers. Is there a market out there that would make a Cygnus-like company viable? (There are definitely skilled people who would like to form such a company.)

Third, it lacks expressiveness. I know it's all meant to make it a simple and robust language, but still, to make "Real World" applications you have to care more for what the programmer needs than what the language needs. A certain amount of controlled and documented ambiguity is a good thing if it enhances the possibilities for the programmer.

Can you give some examples of what you mean? [I felt our semantics for exception handling had all the ambiguity you could ever want in a language and then some :-)]

A parallel meta-language, even a limited one, would be even better.

If you mean "parallel" as in multi-processor? The work of Hans-Wolfgang Loidl, Kevin Hammond, Phil Trinder, SimonPJ and others on separating "algorithms" from "strategies" seems to be just what you're asking for.

Better scoping wouldn't hurt either (after C++, I just cannot live without those nifty nested namespaces).

Haskell has had qualified names (roughly corresponding to C++'s foo::bar) for a while now. When is this not enough? (I'm curious about the answer, not just trying to flip you off.) btw Java-style hierarchial module names are coming to Haskell (implemented in GHC, NHC and Hugs). See the libraries mailing list for some details.

And explicit performance-tuning constructs would be a blessing, rather than having to hack them in in some indirect way (i.e. the "force" function for monadic parsers, etc...).

The force function is very, very domain specific. It doesn't even make sense to talk about it if you're not talking about parser combinators (maybe only monadic parser combinators). So the best thing to do is to use a well-tuned parser library (or a parser generator) and let the implementor worry about it. Apart from providing good libraries and a nurturing environment in which those libraries can live (see libraries mailing list), there's really not much that the language can do. That said though, it'd be great to be able to add strictness annotations to functions and to be able to use unpointed types (like GHC's Int#). Anyone who has looked at the ugly hacks I added to Hugs' Pretty library (to overcome Hugs' lack of Int#) will see just what I mean. [To be more precise, what I want is that values of type Int# should be strictly evaluated (like Int# in GHC) - I don't care whether Int# is boxed or unboxed (a representation detail).] There's probably a few other things that could be done (suggestions welcome).

my FP background is indeed limited, and therefore I might "still" be missing some points here.

There's a risk that you might view the Haskell'98 report as defining the state of the language. In fact, many Haskell programmers rely on extensions like: - multi-parameter type classes - functional dependencies - existential types - overlapping instances - implicit parameters - concurrency support - exception handling (both synchronous and asynchronous) - the foreign function interface (i.e., ability to call back and forth from C, Java, .net) (The C story is very well developed, Java and .net are starting to become available.) - the "hslibs" libraries (which work on GHC, Hugs and, I believe, NHC) and include support for Posix, Win32, X11, HTML, XML, parser combinators, building test harnesses, and a lot, lot more. Unfortunately, we seem to be stuck between Haskell'98 whose explicit design goal was to be stable and Haskell 2 in which backward compatability (which lead to increasingly unfortunate design decisions in Haskell 1.0--98) would be largely ignored. We don't seem to be ready for Haskell 2 yet: some of the above ideas clearly need revised before being standardised, some are too new to even know if they need revised, some ideas (like those in O'Haskell) haven't even made it into a mainstream implementation. In the meantime, different compiler groups are adding features according to their particular research interests and standardising between themselves as the need arises. (I'm not sure that this is a bad thing - compatability between compilers is limited more by lack of manpower than by lack of agreement or by misunderstanding and communication. The only bad thing is that newcomers might reasonably expect the language standard to reflect the state of the art.)

The FP way of thinking has hit hard on me, though. I just coded a bunch of parametric functional parsers in C++ using template metaprogramming

A language that doesn't affect the way you think about programming is not worth knowing. -- the 'fortune' program -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/

At 9:32 PM -0500 6/25/01, Bernard James POPE wrote:

... I think Miranda replaced Pascal as the first language taught to students, but that was a long time ago and I wasn't here at the time.

The switch from imperative to functional must be the hardest, both politically and pedagogically. Does anyone recall how it came about?

... The use of Haskell is filtering up through the later-year subjects, as both staff and students become more comfortable with it. I think that many of our students do not appreciate some of the strong features of declarative programming until third or fourth year when they are faced with larger (more difficult) programming tasks.

I've had several students from my Haskell-based first course (i.e., subject) thank me later on, but the vast majority, lacking reinforcement, seem to lose their ability to think functionally.

There is still a conception amongst some of the students that FP is not really part of "Real World" programming, and that it is merely of interest to academics.

If I could say that about my fellow academics, I would be delighted! Thanks for the enlightenment. Is my envy showing? --Ham ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu hrichrds@swbell.net ------------------------------------------------------------------