Live data from Hacker News

Nimrod: A New Approach to Metaprogramming [video]

infoq.com

21–30 of 84 posts

Re: Nimrod: A New Approach to Metaprogramming [video]

#21
post #8

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 real…

If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.

Re: Nimrod: A New Approach to Metaprogramming [video]

#22
post #3

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.

heh.. sounds like Go

No. It has polymorphism and metaprogramming, things that Go (at least parametric polymorphism) eschews.

Re: Nimrod: A New Approach to Metaprogramming [video]

#23

Earlier quoted context omitted.

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

Go interfaces are also new.

I hear people saying this all the time. Why? For me they are similar to type-classes+records but without polymorphism. Care to elaborate?

Re: Nimrod: A New Approach to Metaprogramming [video]

#24
post #10

Earlier quoted context omitted.

With Nimrod's macro, you can do awesome things. It can improve readability a good deal. Here's an example I made: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Go version: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

The Nimrod version is shorter, but it seems harder to tell whether error-checking is done right.

Nimrod has exceptions. I am catching them (https://github.com/idlewan/nawak/blob/specialpages/nawak_mon...) and returning a 500 error page with the detailed exception message.

So you need less explicit error-checking everywhere with a language that support exceptions.

Re: Nimrod: A New Approach to Metaprogramming [video]

#25
post #3

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.

I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback. 1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.…

Oh, it does bring a lot to the table that C and Python don't have. You're totally right, it is not a middleground per se, it is just the language I was looking for.

If I try to answer your points:

-> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also. The 'var' in procedure arguments could be considered the opposite of the 'const' of C/C++. Everything is const by default in Nimrod, but if you want something modified in place you indicate it.

-> 2) Herm... I got nothing. I haven't used include, I didn't see the use for it yet.

-> 3) 'when' is compile-time, 'if' is at runtime.

-> 4) Unnecessary? varargs is quite useful. For example, if you use redis, you can do db.del("akey", "anotherone", "otherkey"), instead of having to fiddle with an array. Varargs makes some calls cleaner.

-> 5) "The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions." from the Nimrod manual (http://nimrod-lang.org/manual.html). It forces you not to name functions and variables too closely. So you won't be able to have different things named myStuff and my_stuff because it will refer to the same variable or proc. You enforce your own writing style. That is debatable. You have others enforcing a style, like with gofmt. The case insensivity did not disturb me, though (but I admit it surprised me at first).

Re: Nimrod: A New Approach to Metaprogramming [video]

#26

Earlier quoted context omitted.

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

Go interfaces are also new.

I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... 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.

Re: Nimrod: A New Approach to Metaprogramming [video]

#27

Earlier quoted context omitted.

Go interfaces are also new.

I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... 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…

> It also looks a bit like polymorphic variants in OCaml.

Or like object types in OCaml. They also use structural typing.

Re: Nimrod: A New Approach to Metaprogramming [video]

#28
post #12

Earlier quoted context omitted.

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

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

> Go basically only has one modern feature (goroutines).

You mean Modula-2 (1978) co-routines?

Re: Nimrod: A New Approach to Metaprogramming [video]

#29
post #25

Earlier quoted context omitted.

I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback. 1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.…

Oh, it does bring a lot to the table that C and Python don't have. You're totally right, it is not a middleground per se, it is just the language I was looking for. If I try to answer your points: -> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also. The 'var' in procedure arguments could be considered the opposite of the 'cons…

1) I'm not a fan of both the name `proc` and `var` because it allows you to mix inplace editing with return values and makes a mess of the (IMO, precise) meanings "function" and "procedure" have.

If I were starting a new language, I wouldn't pass the opportunity of disallowing mixing these concepts, so there's a way to reason about pure functions.

3) I get that, but it feels like something that could've been optimized away by the compiler, they didn't bothered and instead bloated the syntax. Not a fan of the naming too.

4) Just IMHO, but this kind of magic feels out of place on a static language. In something like Python, variable arguments aren't as opaque since there's an underlying object being passed around (a list or a dict), and your arguments can be of any type.

Re: Nimrod: A New Approach to Metaprogramming [video]

#30
post #6

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 .

I'll take the time to read the paper later.

Do you know how does it compares with Dylan's macros?

Post reply on HN