For the sake of brevity, I'll model this blog post after the things I don't like about the language, and modifications I would make. There are too many things about the language I really like, so starting off like that would really eat up some time.
To get one thing straight, I'll pop up this disclaimer: I know nothing about functional programming. At all. I just tend to drill into a language, ignoring the design methodologies that went into and whatever. So, make no mistake: I have no idea what I'm talking about.
Things I would change:
- The match construct throws an exception if there is an unmatched item. This is suprisingly useful in theory; in practice however the exception provides so little detail that its barely worth it. It should at least spit out what the match variable was. C'mon man, gimme a hint or something, Christ.
- The match construct syntax. The match construct is powerful - it is easily the sweetest thing I've laid eyes on. But the syntax is the ugliest I've ever seen. Personally, I would just totally rip Boo's "given when" syntax and call it "match when" and whistle innocently. The problem with the match syntax is that its completely foreign to everything else in the language for no apparent reason. I cannot think of one reason for the syntax to be laid out in such a hard to type (finger acrobatics, maximum!) and hard to stare at manner. It looks like a twitchy, "shit, let's just do what the old guys did" implementation. I'd 21st century-ize that sucka.
- Explicit return statements. Recently, a pattern I've developed is using return statements to avoid processing the rest of a method without having to drop an exception. This is extremely handy for methods that can return null, or a default object. This seems thoroughly impossible with Nemerle, unless you're willing to use the match construct at the very beginning of a method. This of course means two or three relatively small match bodies, and then one huge match body for the "rest" of the method. I like implict returns, but I wanna be able to be explicit, too.
- N10005. The reason Nemerle sample code is littered with ignore() functions. The reason sample code scrolls an entire screen of N10005's because nobody wanted to type ignore() everywhere. Man, that might be cool or hip when you're running on a framework where every return value is important, but some of the time all it this return data is, is extracellnous information that we don't need. I don't really wanna type ignore(). I'm sorry. I don't. I'm lazy.
- Fuse braces and indentation. Boo/Python really turned me on to indentation based syntax. Hell, I was going to indent anyway. I would fuse'em in Nemerle: start a block with a brace, end a block with a brace. Otherwise, use indentation for syntax. There we go. Kung-fu with both syntaxes, now. Nemerle offers an -i switch, but that's almost as good as not offering indentation-based syntax at all.
Anyway, that's it. There. I posted a blog entry. Now, don't expect another one for awhile.
1 comment:
It is kind old post but things have been changed.
1. There is explicit return
using Nemerle.Imperative;
def f(a)
{
when (a > 10) return 100;
10;
}
2. There is indentation syntax.
#pragma index
using System;
def f()
"A"
class P
static Main() : void
Console.WriteLine(f());
3. There is IDE support for: VS2008, VS2010, SharpDevelop.
Post a Comment