Some good-hearted criticism (Was: Biggest Haskell unit in the world)

[Juan Carlos Arevalo Baeza]

At 12:32 PM 6/26/2001 +1000, Bernard James POPE wrote:

    Disclaimer: Sounds like I'm the gloomy guy writing on this list. Don't 
let that deceive you: I'm actually a happy guy. And excited about Haskell, 
even if it doesn't sound that way. Really.

    :-)

>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.
>
>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. We try
>hard to refute this notion.

    And it's a good quest. I see three problems that prevent me from seeing 
Haskell as a "Real World" language. First, compiler support. Yes, if I'm 
not mistaken, there are several current compilers (4) and interpreters (2) 
out there, but they all have serious problems in terms of efficiency (of 
the compiler itself and of the code generated) and logistics (getting 
compilers to install and work properly, file management, etc...). Hugs is 
the only one that seems solid enough in most fronts, but it's IMHO only 
usable for small programs and for testing. GHC... well, I'm still 
struggling with my own personal quest to get a binary of the latest version 
to work for my platform (Windows).

    Second, debugging tools. So far, I haven't been able to figure out why 
my program (a parser for C++ comments and strings) generates stack 
overflows. Nothing I've been able to think up has been of any help. Neither 
has the suggestions I got from the mailing list. GHC is supposed to have 
nice profiling utilities but it won't work in my installation no matter 
what I try (the program crashes), and, in any case, I haven't seen in the 
documentation any stack-debugging options.

    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. A parallel 
meta-language, even a limited one, would be even better. Better scoping 
wouldn't hurt either (after C++, I just cannot live without those nifty 
nested namespaces). 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...).

    Then again, my college background is in Telecommunications Engineering, 
not CS, and my programming background, although extensive, went through the 
Assembler->Pascal->C->College->C++ route, so my FP background is indeed 
limited, and therefore I might "still" be missing some points here.

    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 
(similar to the Haskell monadic parsers, but of course non-monadic). Faster 
than light, and uglier than sin, but it does work indeed.

    So, now I repeat my plea for help. At this point, I don't care much if 
I don't get the program to work. But I _NEED_ to know what was wrong. Maybe 
one of you teachers might want to use the program as an exercise in 
diagnosing a program for the students? I can send it in a pinch: it's just 9K.


    Salutaciones,
                               JCAB

---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza    | http://www.roningames.com
Senior Technology Engineer          | mailto:jcab@roningames.com
Ronin Entertainment                 | ICQ: 101728263
                        (my opinions are only mine)
JCAB's Rumblings is so off-line O:-(