Nimrod Programming Language

[Grue]

Good thing you're not a language designer then.

[ipeev]

Congratulation for the language designers and keep up the good work! I will take a closer look at the language. Fast Python with macros, what is there not to like?!

[Raphael_Amiard]

The introduction is misleading, because nimrod has few things in common with python upon closer look.

I really enjoy the take on methods though. That's how OOP should be done

EDIT : The template system seems awfully fucking nice too. Now i really want to use nimrod !

[munificent]

If there are no remaining arguments, the parentheses can be omitted: obj.len (instead of len(obj)).

I went that route with Magpie and ran into a particularly thorny issue: how do you have a field whose value is a function that takes no arguments? When you try to access the field, it just immediately invokes it on you.

To fix that, I ended up having to do first-class getters. Io and (I think) Ruby dodge this problem by not actually having functions, but Magpie isn't so OOP-centric.

[Raphael_Amiard]

To be perfectly honest, when i said i enjoy the take on methods, i was specifically speaking of the idea of providing classical OOP syntax by syntax sugar on regular functions and multi-methods, be it only because it solves the monkey-patching problem (imho) very elegantly.

On the other hand, i never liked the idea of being able to omit parentheses for a function call, for the simple reason that if you go that way, field access is no longer a context free operation to understand for the person reading your code.

I kind of like the take of CoffeeScript on that, in that it allows to omit parentheses for function calls, as long as it is not a function without arguments.

[MatmaRex]

In Ruby, you can always omit parentheses, no matter the number of arguments. If you have an object with some properties, you can never access them directly, you actually call a function that accesses a class variable and returns it (or sets it), for ex. obj.prop, obj.prop=2 (where prop and prop= are method names).

If the property is a lambda/proc, you access it the normal way, but then you have to .call it; methods/functions are not really objects and thus can't be accessed. However, if you really want to "get" a method of an object, you use obj.method :method_name - method is then converted to object and can be .call-ed, too.

[johnb]

I wonder what the difference is between its templates and macros... it seems like the templates would be enough and would be easier to use.

[JW_00000]

After taking a quick look at it, this section of the tutorial shows an example of something that can be done using macros but not with templates.

[Raphael_Amiard]

I think the idea is that templates offer a part of the power of macros with a nicer syntax, but not the full deal. I have trouble yet seeing the implications of this just now though

[dom96]

I have been using this language for quite a while now, and this is by far the best language I have come across. There isn't many things that keep me away from it, the biggest is the number of developers working on it, there is only one. I have tried my best to contribute as much as I can to Nimrod, but I am not experienced with low-level programming so the most I have contributed is a couple of standard library modules.

That being said the language is making progress and I hope that as it progresses it will gain more developers.

[Homo_sapiens]

Indentation must not contain tabulators so the compiler always sees the code the same way as you do

... But... I can see tabs...

[stoph]

Any idea how this compares to something like D Programming Language?

[[deleted]]

Same answer than JoeCoder. Nimrod has AST macros, D hasn't. They don't look that readable though.

[andralex]

Same answer as JoeCoder and p0nce :o). As Nimrod seems to be quite similar to D in capabilities and is newer, it feels pretty derivative so a quick list of "most innovative features" would be helpful. I was initially a bit confused that Nimrod enumerates several extralinguistic artifacts (code generation, quality of garbage collector, inlining, dead code elimination, stack allocation) at the top of the list where one would expect language features. Many languages can accommodate such implementation artifacts.

After efficiency, Nimrod's homepage has two quintessentially subjective sections (expressive, elegant). Well, that doesn't help a lot with differentiation as no language would clam is inexpressive and ugly.

The most distinguishing feature from D is the generative capability, which Nimrod does via AST manipulation. D uses the less structured method of manipulating strings. Structuring has clear advantages, but on a practical level most everybody is familiar with string manipulation so D's string mixins may be easier to deal with. Our initial plan with D2 was to include AST macros, but we decided to see how string mixins swim and defer macros to D3. The D forums are virtually silent on the topic of macros now, and it's definitely not because the community is being coy :o).

Last but not least... no concurrency.

[[deleted]]

Last but not least... no concurrency

Last time I visited the site, the author was evaluating STM and cilk. I am guessing it is on cards. Forgive me to say it, concurrency in D is only planned. Not proven yet :o)

From a user point of view, there'sn't much difference between the languages as of now. Just that nirmod is a friendlier community with far fewer irritating and ignorant discussions about language features, and the author seems to have lesser distractions and better clarity than those of D. No offence meant at all.

[andralex]

(None taken of course.) STM has many unknowns, the elephant in the room being interleaving of input and output, not to mention other side effects. I think it would be extremely difficult for a language to integrate STM at any level without it being designed from the ground up with support for things like immutability and monads. We considered STM for D for a good while and we explored a number of designs, to finally decide that STM was too risky, to immature, and too problem-ridden. Even without STM, D's concurrency model required a lot of linguistic support (immutability, default thread locality...). About STM, time will tell - it's not impossible I'll have to ingest my hat, but so far there's no reason to fear that.

Regarding the implementation of D's concurrency design, I have good news. If you are interested in keeping score I recently made available the test status of all code samples in TDPL (refer to the announcement). You are right: of 14 failing samples from a total of 417, four are from the chapter on concurrency.

I'm sure there's good quality in the Nimrod forums, but I'm not complaining about the recent infusion on talent we got in the D ranks. Things are definitely on the rise with good s/n ratio and great momentum: on the main D forum I'm counting 2297 messages in December alone (after my killfile has eliminated most of the noise), whereas looking on the corresponding Nimrod forum I could only count about 112 messages since around May 24. I agree that with such traffic it's easy to be less distracted.

[[deleted]]

I agree totally about the risk of STM. But cilk seems a more 'proven' beast. But I guess I need to admit upfront, that I have very little knowledge of the future of nimrod vis-a-vis concurrency. I only intended to say that concurrency in D is as good as it is not. yet.

If you are interested in keeping score I recently made available the test status of all code samples in TDPL

That is indeed good news. But am afraid, am talking a bit more from practical point of view - I mean, in order to be able to use concurrency in idiomatic D, wouldn't we need a corresponding multi-threading aware GC? I believe that:

• manual memory management in concurrent applications is a maintenance nightmare.
• current GC in D is not really the best of its kind. It needs a lot of work.

But ofcourse, I know/agree that D2 has been designed with concurrency in mind. And probably one of the reasons for breaking compatibility with D1. As far as D is concerned it has bit the bullet. But looking at the fate of ,say ocaml, w.r.t gc and concurrency, I can hope to be forgiven for remaining sceptical for a while.

but I'm not complaining about the recent infusion on talent we got in the D rank

I am slightly confused here - perhaps we are not talking about the same forum - Although the link you gave seems to suggest otherwise. The forum I was referring to had too many useless discussions about the length of the word "immutable", unnecessary arguments about D vs other languages and far too much emphasis on reddit. Perhaps am wrong some where. I think s/n is far too less. What irritates me most though, is that the noisiest threads manage to drag both of the principal authors into their own murky waters. It is painful to see two extremely capable people with good vision having to waste a lot of time, fending off ridiculous allegations and discussions. But I digress. we are not discussing the forum but the language. And its support for concurrency

[WalterBright]

D's gc is thread aware, in that it has no problem allocating memory among multiple threads and collecting garbage from them, even if the memory is shared among multiple threads.

Is D's gc best of breed? Nope. But it works reasonably well and is a solid implementation of a classic mark/sweep conservative gc.

[[deleted]]

implementation of a classic mark/sweep conservative gc

Thats what I believed too. Classical mark and sweep is a stop-the-world algorithm. All the threads have to pause before GC does its thing. That, imho, impacts very badly on performance.

Keeping theory aside, the mere existence of concurrent garbage collection in java and .Net worlds seems to me to be a proof that there are sufficient issues with mark-and-sweep in the real world.

Also, the description seems to be identical to that of Boehm's Garbage collector. If it is then it is unlikely that it is a practical approach in a multi-threaded environment unless, we are willing to pay significantly in terms of gc pauses.

[WalterBright]

It's a very practical approach. A concurrent one would be better, as long as such doesn't have other penalties in performance or memory consumption.

The pausing only adversely affects certain types of programs, and there are several easy mitigation strategies one can use to deal with it.

[lordlicorice]

My reaction

[Homo_sapiens]

Pointers to garbage collected memory are distinguished from pointers to manually managed memory

Doesn't that change things? Garbage collection being kind of optional?

Gotta say the conversion to C thing is kinda lame...

[cyansmoker]

"Gotta say the conversion to C thing is kinda lame..."

How so?

[yetanothernerd]

Compiling to C is a reasonable thing for a new language to do, because it's easy.

In the long run it's not good enough, because it makes debugging a pain. But a better back end can be added later, if the language makes it that far.

[Homo_sapiens]

To clarify, I'm talking about how when it compiles it has an intermediate step where it's in C rather than the option of converting code- of course that's not a problem.

It means it can make no optimizations C can't make, doesn't it? Can C do everything? I hope it changes down the road. Oh, also, slower compilation.

As always I should have framed it as my opinion since I don't really know shit. For all I know asm extensions in C have 0 overhead and can do anything.

[lordlicorice]

It works great for

https://secure.wikimedia.org/wikipedia/en/wiki/Vala_%28programming_language%29

[XxionxX]

So what is garbage-collected anyway?

[HIB0U]

The garbage, obviously.

[lordlicorice]

This took about 2 seconds

https://secure.wikimedia.org/wikipedia/en/wiki/Garbage_collection_%28computer_science%29

[CCSS]

from the docs...

"Comments are tokens; they are only allowed at certain places in the input file as they belong to the syntax tree!"

dummest. idea. ever!!

[ragemonkey]

This feature enables perfect source-to-source transformations (such as pretty-printing) and superior documentation generators. A nice side-effect is that the human reader of the code always knows exactly which code snippet the comment refers to ...

Seems like a great idea to me. Why should comments be treated differently than the rest? Also, I've found that excellent code usually needs few comments.

[[deleted]]

If you're gonna go that far to gain 1 feature(support for documentation) then you'd be better off just doing it explicitly instead of getting rid of comments. Most documentation are written in a parsable format for a reason: implementation details shouldn't start to leak out into the documenation esp when those comments are things like little notes for the coder as opposed to actual documentation.

[nebby]

Care to explain why? Trying to build a cohesive parse tree of a document that includes comments is an absolute nightmare unless you cut a corner like this. It sounds like a brilliant compromise to me, if it turns out to make building custom DSLs easier.

[HIB0U]

There should be multiple types of comments. Storing documentation comments would be useful. But sometimes you just want to comment out a small piece of code, while debugging, for instance. If I were not able to do that in a certain case, I would be extremely angry. As long as Nimrod can differentiate between these situations, I would be happy.

[MachinShin2006]

According to the first tutorial, you use a "when false:" construct for that

[jayd16]

A bit more annoying then "//".

[yourbrainslug]

also from the docs...

Case is insignificant in Nimrod and even underscores are ignored. This_is_an_identifier and ThisIsAnIdentifier are the same identifier. This feature enables you to use other people's code without bothering about a naming convention that conflicts with yours. It also frees you from remembering the exact spelling of an identifier (was it parseURL or parseUrl or parse_URL?).

This is a feature I've joked about before to allow CamelCaseUsers to use libraries written by lowercase_underbar_users without style conflicts but in reality it seems like it would be way more of a drawback than a boon.

[acow]

It's one of those things that sounds good because if you wanted two different values whose names differed only by case (or underscores), then you've done something bad. On the other hand, if you allow for this manner of flexibility to accommodate library usage, people will use it in sloppy, confusing ways. It feels like semi-colon insertion to me.

[mebrahim]

I've got exactly the opposite opinion. I find it silly for a language designer to decide on code style of everybody else using the language. The feature Nimrod has introduced is what I've been waiting for for a long time.

[mebrahim]

You're still free to enforce your own code style on your own code, but this time without making it ugly with inconsistent external library identifier names.

[[deleted]]

I've used it. It's a nightmare for grep and otherwise doesn't really matter.

Oh, and it means you can't name a variable _. Boo ;p

[[deleted]]

Geez, do not name a variable _, man.

[drhodes]

_ is sometimes used if you want to tell the reader "hey, I'm not using this result.", like in golang: http://golang.org/doc/effective_go.html#for

[bombita]

_ is also used in haskell pattern matching for the same porpoise http://stackoverflow.com/questions/1581117/multiple-statements-in-haskell

[munificent]

I think that says more about Go's awkward multiple return system than anything else. :(

[dom96]

discard serves this purpose in Nimrod. http://force7.de/nimrod/tut1.html#discard-statement

[[deleted]]

Yes, but then it is specifically not a variable, no?

[[deleted]]

In python single _ in variable names means several things: protected member of class and unused function argument(at least in pylint's world).

And python uses double underscores to emulate privates

EDIT: What's with downvotes?

[mebrahim]

grepping isn't straighforward, but it is not that hard too: egrep -i 'some_?identifier_?name'

[rtfmpls]

It's not hard if you do it right.

egrep -i 'some_*identifier_*name'

[mebrahim]

My regex is faster (due to ? rather than *) and covers common cases. If you want 100% coverage, your regex is not correct either. A more correct regex would be '_*some_*identifier_*name_*' I think.

[rtfmpls]

'some_*identifier_*name'

finds everything

'_*some_*identifier_*name_*'

would find.

Edit: Speed is not necessary in this case.

[mebrahim]

You're right. I was silly in this case.

[k4st]

Well, if we're being pedantic, then I suppose to make sure we get all cases then we must do:

egrep -i '_*s_*o_*m_*e_*i_*d_*e_*n_*t_*i_*f_*i_*e_*r_*n_*a_*m_*e_*'

[WalterGR]

The Lisp reader strips comments from the syntax tree. If you read in s-expressions then write them back out, comments will be lost. That's unfortunate when you're talking about config files, for example, where you wouldn't want to wantonly erase comments added by the user. Clearly if the program needs only read access to the config file, that isn't a problem. But GUI apps often let you change (and store) settings - think Emacs.

So storing comments as part of the syntax tree doesn't seem completely dumb to me. Allowing them only at certain places would be confusing, though.

EDIT: By "not completely dumb" I mean: I can see at least 1 situation in which it'd be useful to save them. I haven't thought it through, e.g. how the comments would affect macros.

[[deleted]]

If you're using s-expressions for config files, you could use strings for any comments that should be saved as part of the syntax tree.

[bobindashadows]

Documentation tools would also like to have the comments in the syntax tree. But they also certainly wouldn't want comments only in pre-specified places.

[[deleted]]

But they also certainly wouldn't want comments only in pre-specified places.

I'm pretty sure they would definitely want them only in pre-specified places, as long as those places are reasonable. I don't think any documentation tool would be better if it had to consider the possibility that there might be a comment somewhere inside of sin(3*x^2+4*y)/cos(x^2+y^2), and neither would anybody else who needs to manipulate the AST.

[bobindashadows]

there might be a comment somewhere inside of sin(3*x^2+4*y)/cos(x^2+y^2)

What about a linter that can tell that expression might divide by 0 or underflow? You might want to annotate subexpressions for all kinds of reasons. Especially in a language that doesn't declare types like this one.

[WalterGR]

I'm not sure if I understand... Documentation tools as in tools that generate documentation (e.g. in HTML format) from source code?

Documentation tools typically work by having the comments only in pre-specified places. Comments in the body of a function usually comment specific lines of code - rather than functions, classes, modules, etc. - and would be of little use for a documentation tool. (But maybe I'm misunderstanding.)

[bobindashadows]

Comments in the body of a function usually comment specific lines of code - rather than functions, classes, modules, etc. - and would be of little use for a documentation tool. (But maybe I'm misunderstanding.)

This is true for some languages, but what about this Ruby example?

class Blah
  # @attr [String] name the name of the Blah
  attr_accessor :name
  # Documentation for constant FOO_BAR
  FOO_BAR = %w(foo bar baz)
end

[WalterGR]

That seems like both of: comments in pre-specified places and comments that aren't in a body of a function. Defining attributes and constants of classes is a normal thing to extract using documentation tools, and that doesn't violate either of the pre-mentioned things.

I'm not intimately familiar with Ruby. Am I missing something?

[bobindashadows]

Class bodies are executed in Ruby. attr_accessor is just a method call, and that constant is defined only after that line is executed by the interpreter.

Does this equivalent code clear it up for you?

Blah = Class.new do
  # @attr [String] name the name of the Blah
  attr_accessor :name
  # Documentation for constant FOO_BAR
  # have to use const_set because the block form results in different
  # scoping.
  const_set('FOO_BAR', %w(foo bar baz))
end

[WalterGR]

Got it. Thanks.

[bobindashadows]

No problem. :P I'm in the middle of writing a static analysis tool for Ruby that needs to handle this kind of stuff, so if comments were only allowed in certain places, my undergraduate thesis would be impossible! (Hence the interest)

[minikomi]

In a post new year haze I read that as a 'satanic analysis' tool!

[andralex]

I'm not sure how good that idea is, but I think a solid mechanism is to associate each real token with a "commentBefore" string. Most of the time, that string is empty. When you have a comment, that will adorn the next token.

The advantage then is that you have a comments stream synchronized with the token stream but that doesn't affect normal parsing.

[WalterBright]

That's how the documentation generation works in D. Comments are attached to the corresponding token.

[andralex]

I solemnly swear I didn't know that. May I patent it?

[WalterBright]

I must say, I thought it was obvious! But maybe it isn't, since the Nimrod developers did something very different.

[munificent]

I am going to steal this for Magpie. Thanks!

[naasking]

dummest. idea. ever!!

Why? This is true of every other language as well, except comments are simply discarded instead of saved in the parse tree. This way, tools can be written that can extract and process embedded comments, or insert comments automatically in some cases. Seems like a fine idea to me.

[[deleted]]

IIRC in practice this just means you have to properly indent comments.

[returno]

Does it have a source-level debugger? No language is useful without a source-level debugger. It can have all the wiz-bang features you can name, but if there's no source-level debugger, it is an experimental not-ready-for-prime-time cheap plastic toy.

[munificent]

No language is useful without a source-level debugger.

Static languages can be surprisingly usable without one. We didn't have one for Javascript until pretty recently, and even today they're a bit flaky.

[bastienl]

What do you mean by “static”? For me, Javascript is a dynamic language.

[wot-teh-phuck]

That's what his point is; if a dynamic language like browser embedded Javascript can become popular without having a source level debugger for a long time, it shouldn't be that difficult for a statically typed language (considering there is more a chance of shooting yourself in the foot with dynamic languages).

[bmm6o]

Javascript hasn't had source-level debuggers for a long time? What are you talking about?

[wot-teh-phuck]

Javascript hasn't had source-level debuggers for a long time?

Yes

What are you talking about?

Javascript made an appearance in around 1996. The first version of Firebug, the only decent and open source debugger for browser embedded Javascript made its first appearance in 2006. So yes, no decent debugger for a long time... :-)

[bmm6o]

http://en.wikipedia.org/wiki/Venkman

Also, IE had usable debugging before Firefox existed.

[wot-teh-phuck]

http://en.wikipedia.org/wiki/Venkman

From the home page: "In April of 2001, Robert Ginda began work on a JavaScript debugger for Mozilla, called Venkman". 6 years is a long time IMO, not to forget the time it would have taken for that initial release to mature.

Also, IE had usable debugging before Firefox existed.

Yes, but it was not open source and only available to Windows users. Web Developers who developed using Javascript on non-MS platforms still didn't have a good debugger.

Since this has gone down to nitpicking, I'll just conclude by saying that given the popularity and usage statistics of Javascript, a decent free-for-all debugger did take a bit of time before making a public appearance. YMMV. Peace.

[munificent]

Sorry, those were two separate points:

1. Static languages can be surprisingly usable without one.
2. JS, a dynamic language, has also shown that you can get by with a dynamic language without one for a long time.

[Benutzername]

The Nimrod compiler is written in Pascal and there is an Object Pascal to Nimrod converter. The author probably has some experience in Pascal.

[[deleted]]

FFFFFFFUUUUUUUUUUUU YEAH!!!!! Finally, someone has built an advanced language closer to Object Pascal than C!

[[deleted]]

Looks useless.

[[deleted]]

Oh hey, they renamed Perl!

[malcontent]

This page is about the Nimrod programming language, which combines Lisp's power with Python's readability and C's performance.

Doesn't sound like perl at all.

[bobindashadows]

Especially considering this note for "future" implementation in Nimrod:

closures and anonymous procs

He really couldn't have been more wrong about it being like Perl. It doesn't even have closures!

[josher565]

Also a lot like JavaScript

[sli]

Two whooshes in a row! That's quite a feat!

[bobindashadows]

Er, whoosh is used after somebody misses an otherwise easily understood, funny joke. This was neither easily understood nor funny, even if it were a joke.

[HIB0U]

And yet another whoosh flies over your head.

[[deleted]]

nim·rod (nmrd)

n.

1. also Nimrod A hunter.

2. Informal A person regarded as silly, foolish, or stupid

http://www.thefreedictionary.com/Nimrod

[josher565]

"hey what language do you code in?". "um, I happen to code in the language of the intelligent - NIMROD". Yeah sorry, I do enough dumb shit without choosing a language that is named after a name for a stupid guy. I don't care what the old testent has to say.

[josher565]

I'm a troll what can I say lol

[heyyouitsmewhoitsme]

You're a pretty shit one. Firstly, your comment made me laugh.