Q1: What makes Nemerle better then other languages? (i.e. Why it's cool?)

Kamil Skalski:

Currently for me it is bringing the extensibility (macros) and ease of use (type inference, pattern matching) into the world of enterprise frameworks and commonly used object-oriented model for programming. This way developers have much more freedom in their designs and even the most complex (but innovative) of their ideas can be coded in a readable, elegant and statically-typed way.

Michał Moskal:

What I'm doing right now is automated theorem proving. It requires a lot of proof-of-concept implementations and testing. And of course there are hardly any books that will tell you: you need to do this and that, and even if there are you need to figure out the details yourself.

I've found that Nemerle is great at sketching implementation. You write some code, think a bit, change it, write some more, change it, test it. IMHO it is almost as good at it as interpreted, untyped languages. There are a few reasons.

One is type inference. Hmm... "let's change this list into dictionary", in C# you change:

List<int> foo = new List<int>();

into

Dictionary<int,int> foo = new Dictionary<int,int>();

in Nemerle you change:

def foo = []

to

def foo = Hashtable()

which is like a 10 times less annoying (even with intellisense).

The next reason is macros. I've written a few special-purpose macros, for example one that makes objects backtrackable (you can save their state at some point and restore it later). When I add a new field to such an object, I only need to mark it with [Copy] and everything is fine. In C# I had to add it in 4 places. Again this is not that important if you know what do you want to code upfront. But I don't. Another example are the profiling macros (and no, regular profilers don't do the job for me).

Pattern matching is also very useful here, and also extensible — you can go and add some special cases here and there.

The last reason is indentation syntax. It makes the program visually 20% shorter.

And of course, the performance is critical in automated theorem proving. Nemerle delivers something like 60-30% of raw C performance (on Mono). The difference is offset by the more advanced heuristics that you can code more easily code in Nemerle.

To wrap it up: Nemerle is great language for sketching of code almost as easily as in P-languages (Python, Perl, PHP), that will however deliver much better performance.

Q2: Why Nemerle is not mainstream yet? (and When will it be mainstream, as you think?)

KS:

My guess is that people do not value static typing and functional programming approach so much yet. But it is slowly changing — some of the language features provided by Nemerle are also available through languages like Python or Ruby, but in a dynamically-typed and imperative setting. I think that together with increasing complexity of IT projects (demand for static typing) and usage of parallel computing, Nemerle (or languages introducing similar features and approach) will become mainstream.

MM:

It either takes a major industry company backing it or several years and a lot of luck for a language to become mainstream. One regularity I see here is that successful open source initiatives to create programming languages are exclusively imperative, dynamic languages like Perl, Python and PHP (unless you call OCaml mainstream). Maybe this is because they are easier to design right and implement right. The other reason might be that they are easier to learn. Nemerle has a quite steep learning curve. There are benefits at some point of this curve but you don't really see them, until you try to write something bigger than a few dozens of lines.

Q3: Why have you decided to create new language at all (because there are a lot of different languages available)? Was it your first language designed?

MM:

So I guess I was the one to come out with the idea. It wasn't my first language. Before that I've implemented a kind of bourne Unix shell (interpreted of course).

Then an object-oriented C++-like language designed for writing AI-like bots for computer games. It run on a special-purpose virtual machine, and I guess wasn't very useful.

Than there was Ksi, which was a very low-level language, that could be used as a target for compilers of more sophisticated languages. It was very tightly bound to GCC internal syntax. It was implemented as a GCC frontend.

Then there was Gont, which was a cross between C and ML. It had parametric polymorphism and functional values, all in a C-like syntax with a conservative garbage collector that allowed for reasonably easy C interoperability. This was my first bootstraping compiler (i.e. one that was able to compile itself). The lesson learned was a/ don't try to use C-like syntax at all price and b/ even easy interop isn't easy enough — it has to be zero-cost.

The lesson a/ was the reason why Nemerle once looked much like Caml. Now I think it looks fine — we've managed to find the right spot between curly-braceness and functional-programming-friendliness. Lesson b/ was the reason to choose .NET.

As far as I can tell nobody seriously used any of these languages (except, of course, for Nemerle).

And now I'm in the world of first order logic, a language set in stone a hundred years ago

Q4: Macros are in the air since Lisp times. How do you think, why are they still not mainstream? (Maybe they are too complex for mainstream developer?)

KS:

Yes, I think that complexity in development and debugging of macros is one of the reasons why they were not fully adopted in mainstream languages. But I think that the main problem is that they were always either attached to the language not acceptable as mainstream by other reasons or simply badly implemented (like in C preprocessor macros). We hope that having powerful macros available in easy to use and portable language can change this situation.

Q5: C# 3.0 offers a number of features similar to Nemerle ones but it doesn't allow developers to extend language syntax. Why do you think giving developers an ability to modify language itself is better then having a restricted, well-designed set of language extensions in each new version (like they do it in C#)?

KS:

Developer who is fully aware of the language's power, always has the ideas for extensions, which would be useful in his problem domain. There is no such thing like "well-designed set of language extensions", software development is too diverse and fast-changing to define universal set of constructs for any task. It's like saying "we won't allow developers to create libraries, it's better to have single centralized kernel/framework, which we will simply update each year with new functions". Just take a look at "for (type x : collection)" construct in Java — it took almost 10 years of forcing developers to use those ugly iterators, until they added this ultra-simple language construct.

Q6: MS way for metaprogramming is external tools and external languages (DSL Tools for VS). Why do you think extending existing language with macros is better?

KS:

Probably the greatest advantage of macros is better integration and easier usage. You do not need to remember about additional classes, which have to be regenerated in specific circumstances, you don't even need to know about their existence — with appropriate macro it will just work. You can apply macros to every part of your code, altering your program at any depth with instant advice from compiler about the results. And moreover, everything stays unified — once you know the core language, jumping into macros is not too difficult and lets you stay in the same mindset.

Q7: Have Nemerle changed your own coding style?

KS:

I think that having all the features from different paradigms available in one language thought me to better understand the advantages and disadvantages of given approach to coding some solution. Also, I learned to use more declarative style of programming in practice — it all comes from functional programming where you concentrate rather on writing "transformers" of data, instead of "mutators", but only being able to use this approach with rich .NET libraries on everyday tasks did work for me.