There are some interesting design choices in Nimrod. I read the tutorial and it not only explained how to use the language; it also sometimes mentioned reasons for some of the features and many of those reasons are about efficiency. The compiler requires forward declarations because looking ahead would slow down compilation. Recursive types need to be defined together in a single type statement because, "anything else would require arbitrary symbol lookahead which slows down compilation." And multidimensional openarrays are forbidden because they are rarely needed and cannot be implemented efficiently.
Perhaps I have been spoiled by languages like Java and Haskell which are more concerned with helping me get things done than with doing things efficiently, but I would rather not have my language mandate that everything I write be manually optimized. If I write a program that takes a little longer to compile than it could, I still consider it the compiler's duty to compile it. It's my time to waste. And if I want multidimensional openarrays, then please accept that I don't care about efficiency and give me multidimensional openarrays.
Methods that have dynamic dispatch on all arguments is a nice feature. I expect there are some interesting things that can be done with that, though tracking down exactly what verion of a method might be ultimately called could be troublesome. At least with single dispatch it is easier to keep track of all the various versions of a method.
I don't mind minimalist support for object oriented programming in principle. After all, object oriented programming can be done in any language, but lack of multiple inheritence is troublesome. If you need a class that can take on more than one role, such as being passed to a sort procedure that expects a TList, but is also able to be passed to lookup that expects a TMap, then you need a work-around. It seems that you are forced to use composition in place of inheritence by creating an adapter class. For example, your class TBox could be a subclass of TList, and then you can have another class called TMapBox that is a subclass of TMap and contains a TBox.
Nimrod makes this relatively painless since classes can be defined with a brief notation and defining two classes in the same module gives them total access to each other's private members, but it seems far more confusing than it would be if TBox could have simply been both a TMap and a TList.
If multiple inheritence by adapter is difficult to read then it may be a part of a general carelessness toward reabability in the design of Nimrod. Another example is the concept of a var parameter which allows a procedure to modify a variable that is being passed as an argument. In C if you want to do that you pass the address of your variable and everyone can see you are doing that when the function is called. When this is done in Nimrod the arguments that might be modified look exactly like any other arguments; you just have to know that the procedure might be changing them.
I would have expected the use of var parameters to be discouraged, but it seems to be seriously encouraged. The built-in procedure new is used for dynamic allocation, but instead of returning a pointer to the new memory, it takes a pointer as an argument. Every procedure that returns a value also has a result variable which apparently exists mostly to make it easier for a procedure to return a value that it gets from a procedure call that modifies its arguments.
On the other hand I very much approve of how Nimrod makes parameters unmodifiable by default. The vast majority of functions never intend to modify their parameters, but parameters aren't declared to be const nearly as often because it is an unnecessary chore. I often wish that languages would stop asking us to flag parameters that can't be modified and instead ask us to flag parameters that can be modified.
Macros are a fun idea. They are awfully powerful, and when you want to get something done it is nice to feel that you have almost no limits, but it can't really be a good thing. Being able to read code easily is far more important than being able to write it easily, and when macros are involved it's hard to even be sure what language you are trying to read. I can't fault Nimrod for having a powerful macro system, but I hope it is used very rarely. It's disturbing that even the != operator is a macro.
I can't help but think that if the designers of Nimrod would put the cleverness that they put into the macro system into the rest of the language they could find a way to get rid of most of the need for macros. For example, there is the when statement which is essentially a macro version of an if statement, where if the when condition is true then the else clause doesn't even get type-checked. Deliberately not type-checking part of a program is surely a bad sign for reliability. You can even declare a variable inside a when and then use it outside the when. I don't see what all the dangerous trickery of when is trying to accomplish that couldn't be managed more safely with a simple if.
RSS Feed