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.
Nimrod: A New Approach to Metaprogramming [video]
61–70 of 84 posts
Re: Nimrod: A New Approach to Metaprogramming [video]
#62I 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.
Re: Nimrod: A New Approach to Metaprogramming [video]
#63Earlier quoted context omitted.
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…
> 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 think I'll give Cat a shot, I'm not a fan of CLR, but I'd really like to know how you can type concatenative language.
Re: Nimrod: A New Approach to Metaprogramming [video]
#64Earlier quoted context omitted.
While you're right for probably most classes of application, this is not an absolute truth. There are reasons not to use the GC - eg you're developing a browser, or a GC for a language, and many besides. I see a similar thread where you made a similar statement, so in favor of not rehashing that whole thread, here it is: https://news.ycombinator.com/item?id=7061533
Oh, I strongly disagree with that logic. A browser is exactly the sort of situation where a GC is useful. I mean, it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve.
There are many reasons for leaks in Firefox, and none of them had to do with not using GC for everything. In fact, there were failed attempts to do exactly that (XPCOMGC), which failed due to performance problems. A lot of those "leaks" were just cases of using too much memory, which pervasive GC actually hurts due to the lack of prompt deallocation (which deferred reference counting loses).
GCs are simply not appropriate for every use case.
Reference counting is not a panacea; once you start wanting to break cycles (which history tells us you will), you start having to deal with stopping the world or concurrent collection. If you don't have thread-safe GC, then you have to either copy all data between threads (which limits the concurrent algorithms you can use) or you lose memory safety.
Finally, your implicit claim (that Rust's safe memory management is more vulnerable to leaks than GC) is untrue. Rust's safe manual memory management is no more vulnerable to leaks than GC. The compiler automatically destroys memory when it is no longer reachable.
Re: Nimrod: A New Approach to Metaprogramming [video]
#65Earlier quoted context omitted.
If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.
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.
Re: Nimrod: A New Approach to Metaprogramming [video]
#66Given 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.
Both lambdas and closures are there: 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.
Re: Nimrod: A New Approach to Metaprogramming [video]
#67Earlier quoted context omitted.
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.
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 ca…
> 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.
Re: Nimrod: A New Approach to Metaprogramming [video]
#68On 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 .
Funny you should say that, because I've been working on my own approach this month: https://github.com/breuleux/liso I'm probably going to post about it soon in more detail, if people are interested.
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.... 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 :)
Re: Nimrod: A New Approach to Metaprogramming [video]
#69Heh. 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 :)
Re: Nimrod: A New Approach to Metaprogramming [video]
#70Heh. 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 :)
You can thank bugs bunny for that