Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nimrod: A new approach to metaprogramming

nimrod-lang.org

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Nimrod: A new approach to metaprogramming

#11

Post by andrewflnr »

progman wrote: post #8

Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…

What do you mean by "Nimrod is where Python should be"? The two languages are aimed at very different use cases.

Re: Nimrod: A new approach to metaprogramming

#12

Post by rdtsc »

A GC with a deadline is what caught my attention, seemingly can specify a max pause time (in ms) and GC wont' take longer than that. That is very good for soft realtime stuff -- games, audio processing.

Also, Nimrod has a very nice library. Definitely has enough "batteries" in it to get started.

http://nimrod-lang.org/lib.html

Just a few impressive ones: http client, server, json parsing, actor support, redis db driver, zmq, cairo graphics, OpenGL wrappers, even Lua and Python support.

That looks very appealing, anyone using, what is your experience with it?

Re: Nimrod: A new approach to metaprogramming

#13

Post by pcwalton »

RyanZAG wrote: post #7
wwwtyro wrote: post #4

Cool project. How does it accomplish the realtime GC max pauses of 1-2 ms after compiling to javascript? Wouldn't the js implementation's GC have the final say on GC pauses? Thanks.

Just being optimistic, probably. You could write a fairly trivial program that builds and discards massive trees that will force GC to take greater than 1-2ms simply on freeing memory. Maybe they mean in regular operation or something - but then what is regular? I guess they have to claim impossible feats to get interest given just how many languages there are already.

It's deferred reference counting, so the 1-2ms claim is perfectly reasonable because all it has to scan is the stack (though if they want to break cycles they will have to do something costlier). The downsides are all of the downsides of reference counting, plus the fact that last I looked Nimrod's GC is not thread safe. That last one is a huge downside IMHO. I think DRC is interesting but I'm not much of a fan of it, honestly: it doesn't solve the big downsides of RC (cycles and thread safety being super expensive) while giving up RC's biggest advantage (prompt reclamation).

Re: Nimrod: A new approach to metaprogramming

#14

Post by twotwotwo »

ibudiallo wrote: post #5

Impossible to navigate the site on mobile . For some reason it says swipe so it is supposed to work well on mobile device.

It's using http://nimrod-lang.org/talk01/Slidy2/scripts/slidy.js -- that does indeed seem to try to support swipe navigation on mobile, but I had trouble with it on Chrome Beta for Android.

Re: Nimrod: A new approach to metaprogramming

#15

Post by progman »

andrewflnr wrote: post #11
progman wrote: post #8

Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…

What do you mean by "Nimrod is where Python should be"? The two languages are aimed at very different use cases.

Nimrod provides the features which I wanted to have when I developed with Python: type system, Perl regex, range subtypes, easy C interface. native compiler(s). I know PyPy but Nimrod needs much less space to compile.

Re: Nimrod: A new approach to metaprogramming

#16

Post by RyanZAG »

pcwalton wrote: post #13
RyanZAG wrote: post #7

Earlier quoted context omitted.

Just being optimistic, probably. You could write a fairly trivial program that builds and discards massive trees that will force GC to take greater than 1-2ms simply on freeing memory. Maybe they mean in regular operation or something - but then what is regular? I guess they have to claim impossible feats to get interest given just how many languages there are already.

It's deferred reference counting, so the 1-2ms claim is perfectly reasonable because all it has to scan is the stack (though if they want to break cycles they will have to do something costlier). The downsides are all of the downsides of reference counting, plus the fact that last I looked Nimrod's GC is not thread safe. That last one is a huge downside IMHO. I think DRC is interesting but I'm not much of a fan of it…

Deferred means you eventually have to do the work. Same for reference counting - when you free that last element it will have to actually do the freeing. If you've filled up ram and are allocating objects fast then you can either crash or do some garbage collection and if the tree is large it will have to take more than 1-2ms.

Re: Nimrod: A new approach to metaprogramming

#17

Post by progman »

TylerE wrote: post #9
progman wrote: post #8

Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…

For embedded use it's probably ok, anywhere C is ok. It statically links the bits of the stdlib you use but dead code elimination seems to work pretty well. A simple word counting script I just wrote compiles down to about 52k on 64bit OS X. (Src: https://gist.github.com/tylereaves/7711302 )

Thanks - but your example is Python code ??

Re: Nimrod: A new approach to metaprogramming

#18

Post by hcarvalhoalves »

progman wrote: post #8

Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…

> Nimrod actually is where Python should be.

I guess you meant "what I wanted Python to be".

I don't see how Nimrod is a natural evolution of Python. Static types and meta-programming by templates are far from anything Python proposes. I believe not even the syntax comparison applies too much, it's syntax is more reminiscent of Pascal than Python itself.

Re: Nimrod: A new approach to metaprogramming

#19

Post by TylerE »

progman wrote: post #17
TylerE wrote: post #9

Earlier quoted context omitted.

For embedded use it's probably ok, anywhere C is ok. It statically links the bits of the stdlib you use but dead code elimination seems to work pretty well. A simple word counting script I just wrote compiles down to about 52k on 64bit OS X. (Src: https://gist.github.com/tylereaves/7711302 )

Thanks - but your example is Python code ??

No, it's Nimrod. I set it to python in gist because that's the closest to nimrod for syntax highlighting purposes.

Edit: Apparenetly not...there are alot more modes in there but the UI exposing them is easy to miss

Re: Nimrod: A new approach to metaprogramming

#20

Post by lars »

wwwtyro wrote: post #4

Cool project. How does it accomplish the realtime GC max pauses of 1-2 ms after compiling to javascript? Wouldn't the js implementation's GC have the final say on GC pauses? Thanks.

I have no idea what Nimrod is doing, but I suppose one could output JS where a heap is simulated through a TypedArray, such that the JS GC only has a single memory reference to keep track of. Then you could give guarantees on GC performance, given reasonable assumptions about the JS runtime.
Post reply on HN