An interesting post on the XL mailing list today about a language called Nemerle. Nemerle is kind of like SML with macros, some dynamic typing and a C#-ified syntax. My only real grudge against it so far is that it’s Yet Another Garbage Collected Language, meaning, naturally, that it does not fit in my Holy Quest to bring high-level programming to low-level problems. Such is life. I think Forth is still the closest thing available to what I want for this particular Quest, which is a shame because it’s still so far away from what could be done.
ML Kit is so close in so many ways. Its problem was simply that it followed SML too closely, afraid to add keywords to the language. What it really needed was a way to specify at a high level how the programmer expected a function to consume memory, so that it could be checked at compile-time and massive memory leaks could be flagged down and fixed. Instead, you just get memory leaks if everything isn’t coded just so. Defeats the purpose of strong type safety, now doesn’t it?
Anyway, back to where I wanted to put this discussion, which is metaprogramming. It’s nice to see metaprogramming starting to really come into the spotlight in pragmatically-driven languages. Metaprogramming is important; not only because there are certain problems that should simultaneously be solved at compile time and not be included in a language, but also so that code can be written in terms of the problem domain. (A while ago I talked about Concept Programming; now that I’ve read that entire site, I can confidently say that this is how code should be done.)
So, Nemerle goes on my list of “Languages that I should play with.” I think I’m also putting Haskell on that list; we’ll see if its ideology is compatible with mine. Functional programming solves a lot of problems and avoids a lot of traps that imperative programming gleefully pushes you into (and I will probably write a long entry about exactly how), but I don’t think it’s always a win for every problem.