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…
Nimrod: A New Approach to Metaprogramming [video]
21–30 of 84 posts
Re: Nimrod: A New Approach to Metaprogramming [video]
#22I 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
Re: Nimrod: A New Approach to Metaprogramming [video]
#23Earlier 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.
Re: Nimrod: A New Approach to Metaprogramming [video]
#24Earlier 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.
So you need less explicit error-checking everywhere with a language that support exceptions.
Re: Nimrod: A New Approach to Metaprogramming [video]
#25I 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.…
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]
#26Earlier 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.
Of course I might be missing something as I'm not that familiar with Go.
Re: Nimrod: A New Approach to Metaprogramming [video]
#27Earlier 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…
Or like object types in OCaml. They also use structural typing.
Re: Nimrod: A New Approach to Metaprogramming [video]
#28Earlier 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.
You mean Modula-2 (1978) co-routines?
Re: Nimrod: A New Approach to Metaprogramming [video]
#29Earlier 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…
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]
#30On 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 .
Do you know how does it compares with Dylan's macros?