Some good-hearted criticism (Was: Biggest Haskell unit in the
Juan Carlos Arevalo Baeza
Mon, 25 Jun 2001 21:22:54 -0700
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.
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology Engineer | mailto:firstname.lastname@example.org
Ronin Entertainment | ICQ: 101728263
(my opinions are only mine)
JCAB's Rumblings is so off-line O:-(