[nem-en] loving Nemerle

[Kamil Skalski]

2005/10/25, Greg Fitzgerald <garious at gmail.com>:
> Nemerle developers,
>
> Since Nemerle version 0.2, I have been watching the growth of Nemerle,
> but haven't had any side-projects big enough to justify setting Ruby
> aside and start coding in Nemerle.

Thank you for staying with us and the real adventure begins now ;-)

> About a month ago, I one project finally got big enough that I got
> sick of dealing with the subtle bugs that come up in interpreted
> languages, and I wanted something that would run much faster.

Do you feel that performance side of the language fulfilled your expectations?
We are aware that Nemerle compiler isn't too fast itself, but we
believe that this is neither
due to poor generated code nor general .NET performance, but rather
the complexity of
algorithms involved in compilation (type inference, macros etc.).
We welcome any opinions or benchmarks about the performance.

>
> A few thousand lines later, I just wanted to shoot you guys an email
> and say how much I am enjoying coding in Nemerle.  At first I was a
> bit turned off in how strict the compiler is, but as I got used to the
> language and the type-inference, I now think the compiler is just
> awesome.  Its strictness has saved me *so* much debugging time.  I
> love how I can write a few hundred lines of code all at once, fight
> the compiler a little, and then all of a sudden, everything just
> works.  It's a big change from the world of interpreted languages.

This was also my feeling when I tried OCaml over pure C. Things tended
to Just Work
after a few compile errors, which needed to be corrected.
Unfortunately OCaml's syntax and lack of libraries prevented me from
doing any real programming there. And here we come to Nemerle :-)

Lately I use Java and Eclipse at work and my impression is quite good
- IDE is instantly giving me feedback about errors I am doing in my
code and I can immediately fix them, that is great feature. I guess
this is the future direction for at least 10-15 years in programming,
having a good, type-inferenced language with generics and a good IDE
which would instantly give programmer some hints about what compiler
knows about his code.
Sadly, we are not too far in Nemerle with regard to IDE support.

> As much as I love using Nemerle's functional libraries, I must say
> that my favorite part of Nemerle is the excellent integration of
> generics.  Using only Nemerle.Collections for my data structures, I
> have yet to write a single line of code, outside of class interfaces,
> where I had to explicitly tell the compiler the type.  Great job guys!

Yes, type inference on the expression level works really nice (big
thanks to Michal).
It still fails in some complex cases with nested local functions, but
this is still getting better. Of course the most lacking feature is
the inference for global methods signatures.

>
> Looking back at my Ruby code, Nemerle turns out to be not much longer.
>  Nemerle's closure syntax is a little heavier, Nemerle asks you to use

We are considering the addition of C#3.0 like lambda syntax:
fun (x) { x.Name } turns into
x => x.Name

actually it should Just Work after introducing following macro:

macro @=> (p, body) {
   <[ fun ($p) { $body } ]>
}

but probably there would still be some syntax issues, because => is
used in matching.

> parentheses a bit too often, and Nemerle requires you declare
> variables.

Well, sometimes parentheses are a little bit ugly to write, but from
all my experience they save you many bugs (especially with compiler
instantiously kicking your code in IDE).
Variables, well I think that seeing the place where given variable
appears in the scope is
worth those few additional keystrokes... For example if you have

...
name = "Foo";
do_this ();
do_that ();
...

you never know if it is: local variable, instance field, static field,
field imported from other class, etc.
And it is usually a BIG difference in semantics whether given
identifier is a local value or a field.

> Other than those few little differences, I'm blown away
> that I can even attempt to compare a rapid-prototyping, interpreted
> language to a statically-typed, compiled language.

>From time to time I hear the discussion about leveraging the problems
of static typing
with dynamic "holes" in the program. It is indeed a quite interesting
topic, but I tend to
think, that the real issue is that compilers are often simply not able
to understand
how the program should be typed. IMHO current .NET/Java object-model is quite
flexible and most real-life problems/programming tasks have an
acceptable representation in it. It's just that C# and Java require
you to write all the types manually.

Also, from time to time I see some nice, elegant solutions in untyped
languages, which
involve dynamic extensibility of object-model during execution. What
is surprising is that
many of them are possible to implement in a static way by the use of macros.
(just a quick, maybe not the best example
http://d.hatena.ne.jp/akiramei/20051021#p1)

>
> Great job, keep it up, and I very much look forward to trying out the
> indentation-based syntax in a future release.  And are there plans to
> infer types of private class methods?  (cuz i'll gladly test-drive
> that too :)

Thanks! I'm also curious if people will find the indentation syntax
useful in Nemerle.
Some already tried: http://d.hatena.ne.jp/akiramei/20051020#p1
Indeed, language have a different feel this way, though I would be a
little bit scary about white spaces ruling semantics of my program...
We are planning a new release soon and this feature will be there for everybody.

Yes, the inference on global level is a planned feature:
http://nemerle.org/bugs/view.php?id=213
And it is quite probable that Michal will implement it sooner or
later, as this is a subtopic of his PhD studies.

--
Kamil Skalski
http://nazgul.omega.pl