

Nimrod: A New Approach to Metaprogramming [video] - dom96
http://www.infoq.com/presentations/nimrod

======
skrebbel
I am _very_ intrigued by Nimrod. The language seems to have goals that overlap
with e.g. Rust, but with a bunch of really interesting design decisions (e.g.
GC by default, but first class support for manual memory management). Given
the amount of force driving Rust (and Rust's PR machine), compared to Nimrod
which seems to be really pushed forward by one single person, I'm really
impressed by how far Nimrod got.

I really want to start using Nimrod for real work.

~~~
DorianMarie
To support the fact it's mainly one guy:
[https://github.com/Araq/Nimrod/graphs/contributors](https://github.com/Araq/Nimrod/graphs/contributors)

His name is Andreas Rumpf and he is really impressive.

~~~
pjmlp
Very impressive, but not sure if one should depend on tools with a Bus factor
of one.

------
dom96
Slides: HTML ([http://nimrod-code.org/talk01/slides.html](http://nimrod-
code.org/talk01/slides.html)) and PDF ([http://nimrod-
lang.org/talk01/slides.pdf](http://nimrod-lang.org/talk01/slides.pdf))

~~~
_pmf_
Thank you!

------
idlewan
I really enjoy the language so far. For me, it's the perfect middleground
between C and python: a fast compiled language, and one where you can be as
productive as in python.

I also tend to prefer catching errors early, and having a typed language that
warns and errors at compile-time is great.

~~~
joshbaptiste
heh.. sounds like Go

~~~
pjmlp
Go is not that modern, for those of us that know the alternative world of
Algol family of languages.

~~~
TheCoelacanth
Go basically only has one modern feature (goroutines). Beyond that it's a
throwback to Java version 1.

~~~
skybrian
Go interfaces are also new.

~~~
klibertp
I looked at [http://golangtutorials.blogspot.com/2011/06/interfaces-in-
go...](http://golangtutorials.blogspot.com/2011/06/interfaces-in-go.html) and
the only new aspect of Go interfaces I see is that they are implicit - they
are considered implemented if the type implements functions that interface
defines and you don't need to explicitly write "implements Something". This is
a handy shortcut, but it doesn't look like a "serious feature". It also looks
a bit like polymorphic variants in OCaml.

Of course I might be missing something as I'm not that familiar with Go.

~~~
skybrian
Actually it's a big improvement for large-scale programming due its effect on
library dependencies. In Go you can easily declare an interface that matches a
type in someone else's library without creating a hard dependency on that
library. You can also superset and subset interfaces easily. That way you get
loose coupling (almost like "duck-typing") in a mostly statically checked
language.

Contrast with Java where you'd have to both create a new interface and write
an adapter class in a separate "glue" library that has hard dependencies on
both libraries.

~~~
pjmlp
On the other hand when looking at type X you don't don't which set of
interfaces it supports.

Not very good for large scale programming, I would say.

As for comparing with Java, well, yes it is true.

However there are plenty of strong typed languages which offer similar
capabilities.

~~~
skybrian
I don't think it matters that much from a library maintainer's point of view.

If you you want to change a public method and can find all the type's usages,
an IDE or search engine can tell you which call sites will break. (Or just
compile everything and see what happens.)

If you can't find all the type's usages, you're screwed anyway because any
change that would break an interface will also break a call site that calls a
method directly, without using an interface. So having all the interfaces
declared right there doesn't help that much.

~~~
pjmlp
> I don't think it matters that much from a library maintainer's point of view

From a large scale application developer point of view it matters a lot.

In code bases developed by 50+ developers across multiple sites, it is
important to be able to look to a _struct_ definition and be aware what
interfaces in the code base are supported.

------
dded
Near the top of Nimrod's homepage ([http://nimrod-lang.org/](http://nimrod-
lang.org/)) is the following quotation, which leads me to believe that the
language creators think they have picked a good name:

 _The most important thing in the programming language is the name. A language
will not succeed without a good name. I have recently invented a very good
name and now I am looking for a suitable language._ \-- D. E. Knuth

But "Nimrod" might not be as good of a name as they hope. The biblical Nimrod
was a "mighty hunter", and the name may have that connotation in Europe: the
British seem to have always had a warship or a warplane (or both) named
_Nimrod,_ for instance. But in the US, due to the ironic use of the name by
Bugs Bunny to address Elmer Fudd, we tend to associate "Nimrod" with
incompetence and gullibility.

~~~
dded
I'm not sure why this is down-voted. Connotations differ in different
cultures; I merely point out that "Nimrod" does not have a universally
positive connotation.

If this is connotation is intentional, perhaps as humor, please just tell me
I'm not getting the joke.

~~~
dom96
I believe that the reason the name Nimrod was picked was because according to
the Bible Nimrod was the first king.

The fact that the word has a negative connotation in the US is a bad
coincidence. It however seems too late to change the name now.

But is it really so bad? Many people use Git and in Britain 'git' has similar
negative connotations, as Nimrod does in the US.

~~~
dded
> But is it really so bad?

I don't know. It's not like "Gimp", which is viewed by some as insulting to
handicapped people. But it wasn't clear to me that the Nimrod developers were
even aware of the US connotations, so I brought it up.

Perhaps the "Git" comparison is apt; as far as the US is concerned, that's the
sort of name that's been picked.

------
wcbeard10
From the little I know about metaprogramming, it sounds analogous to doing
string manipulations in a language, and then eval'ing it (which is heavily
frowned upon, at least in python).

How is this understanding wrong?

~~~
skybrian
It's a bit higher level, roughly like generating HTML using a templating
library that auto-escapes to avoid XSS attacks. There are fewer ways to screw
up and since it happens at compile-time, it's more secure.

Generally speaking, if you would normally do something using reflection, you
can also do it using code generation, which should compile to faster code
(since you're not interpreting it at runtime) but possibly at the cost of code
bloat and making the code harder to follow.

------
M2
Nimrod is a really good general-purpose language with a clear and readable
syntax

------
rayiner
On a related note, the most principled approach to macros for an infix
language I've yet seen is Honu (brought to you by the Racket people):
[http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf](http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf).

~~~
breuleux
Funny you should say that, because I've been working on my own approach this
month: [https://github.com/breuleux/liso](https://github.com/breuleux/liso)

I'm probably going to post about it soon in more detail, if people are
interested.

~~~
klibertp
What is your use case? Very nice project, BTW.

Personally I didn't find myself wanting all of the Racket syntax to be
transformed. but I certainly more than once wanted to have a form which would
offer infix syntax for everything inside, like TCL's `expr` (IIRC). There's
[https://github.com/marcomaggi/Infix/blob/master/infix/infix....](https://github.com/marcomaggi/Infix/blob/master/infix/infix.sls)
but I don't know if it works with Racket. Having a `lang` for infix notation
seems like a good alternative: everything that would benefit from it (mainly
maths in my case) would be in a separate file anyway.

So you have at least one interested person now :)

------
stuhood
Given the current trends in language design, it's interesting that Nimrod
declares itself an imperative language, and that this talk doesn't discuss
lambdas at all.

~~~
klibertp
Both lambdas and closures are there: [http://nimrod-
lang.org/manual.html#closures](http://nimrod-lang.org/manual.html#closures)

There is some support in the library for things like map, filter.

It's not the focus of a language though, which is ok - I love FP, but it's not
like it's the only way forward. Diversity is good.

------
laichzeit0
Heh. The name nimrod has a very insulting connotation where I live. Nimrod: an
inept person.

Really we actually use it as an insult to people, e.g. "man that guy is such a
nimrod", "you're a nimrod". Very weird choice for a name :)

~~~
desal
You can thank bugs bunny for that

[http://en.wikipedia.org/wiki/Nimrod#Idiom](http://en.wikipedia.org/wiki/Nimrod#Idiom)

