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:-(