Live data from Hacker News

Nimrod: A New Approach to Metaprogramming [video]

infoq.com

71–80 of 84 posts

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

#72
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…

To support the fact it's mainly one guy: https://github.com/Araq/Nimrod/graphs/contributors His name is Andreas Rumpf and he is really impressive.

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

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

#73
post #62
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…

Just one thing to point out - people wrongfully consider that an alternative to a non-deterministic GC is necessarily a manual memory management. There are automatic and deterministic memory management mechanisms, e.g. smart pointers in C++, Rust.

Fully agree.

To reinforce your point, many are unaware that the various forms of reference counting are also GC algorithms in CS speak.

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

#74
Near the top of Nimrod's homepage (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.

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

#75

Earlier quoted context omitted.

> the only new aspect of Go interfaces I see is that they are implicit This is not a new thing. Structural subtyping has been around since the earliest formal treatments of subtyping in the early 80s. OCaml's subtyping relation is structural. There's a related notion of row polymorphism that was first formalized in the late 80s. As far as I know, it hasn't been widely adopted, but is the subject of ML Poly/R. Elm's e…

> This is not a new thing Yeah, what I wanted to say was "the only aspect worth noting" or something similar. I knew about structural typing and vaguely remembered that row polymorphism exists (but I'm not really sure what it is). Actually I wanted to play with Joy for a couple of times now, but it seems unmaintained and rather hard to approach. I ended up learning some Forth and (little) some of Factor instead. I th…

I'd definitely recommend Cat. It's a very neat language. The reference implementation is written in C#, but I recall seeing a page at one time listing a few implementations in other languages. Unfortunately, I can't seem to find that page now. The Cat website does have an online interpreter, though.

http://www.cat-language.com/interpreter.html

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

#76
post #74

Near the top of Nimrod's homepage ( 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…

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.

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

#77
post #76
post #74

Near the top of Nimrod's homepage ( 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…

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.

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.

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

#78
post #77
post #76

Earlier quoted context omitted.

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.

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.

> 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.

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

#79
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…

> I really want to start using Nimrod for real work.

I have actually used both Rust and Nimrod for real work (same project, first Rust then rewrite in Nimrod). My experience is that Nimrod is far easier to handle than Rust. It feels like Python with the native speed of C. There are a lot of nice features built into Nimrod, for instance native Perl regular expressions and seamless import of C functions. As for me it is the most productive language I ever encountered. I know many languages.

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

#80
post #32

Earlier quoted context omitted.

There's really no reason not to use the GC though. It's very lightweight and quick.

Nimrod's GC is not thread safe, last I checked. So if you aren't careful to avoid races on shared memory, you can segfault. Also, you incur full heap scans to clean up cycles.

Yes it is. Threads don't share a GC - there's no implicit sharedness. Memory is copied between threads. And of course, it doesn't prevent manual management of shared memory (just not GCd) so you CAN use locks to do so. Just like other languages.

I turn off the cycle collector in my realtime apps. I prefer designing a clean, solid system that isn't reliant on cycles without my direct knowing. I guess that's just my inner control freak though.

Post reply on HN