I wonder what other wonderful languages I've never heard of. Really, please share!
MetaML, a language with as many levels of macros as you'd like: http://www.cs.rice.edu/~taha/publications/journal/tcs00.pdf
(implementation as MetaOcaml)
Nimrod: C + Macros + GC
11–20 of 116 posts
Re: Nimrod: C + Macros + GC
#12Just when i started reading tutorials about Rust this comes up... Looks nice, but does it also have concurrency built in (Rust tasks, Erlangs processes, message passing, etc.)?
From the second paragraph on the linked page: > Beneath a nice infix/indentation based syntax with a powerful (AST based, hygienic) macro system lies a semantic model that supports a soft realtime GC on thread local heaps. Asynchronous message passing is used between threads, so no "stop the world" mechanism is necessary.
Yes, so not. I've found the actor module, but it's based on threads so no "lightweigth" and not as powerful as the networked, lightweight erlang processes. I'd really love to see that in a new language, especially since Rust and Nimrod are the first ones in a while i really like from the syntax point of view..
Re: Nimrod: C + Macros + GC
#13I know exactly what I'm going to be doing next week!
Re: Nimrod: C + Macros + GC
#14I've been tempted by this one several times. I may have to play around with it and SDL2. One thing that gets me, though, is the var keyword in a statically typed language. Why say "var thing: string" instead of "string thing"? I think that consistent, explicit declaration of types is much cleaner and easier to read than this recurring mixture of type inference and annotation.
In this language, I don't think it makes sense. (Then again, I think little of this language makes sense. Neat hack, but still in the "if I want GC I'll use the JVM" bucket that a lot of these fall into.)
In something like Scala, you can end up with some fairly hairy eyesores of variable declarations and the type is often not that important when you and everyone else have the ability to hover over a variable name and see the computed type immediately. Wouldn't work for a vim-driven language, but works well in an IDE.
Re: Nimrod: C + Macros + GC
#15This looks good. However according to the web framework benchmark its performance looks pretty underwhelming, below that of Python and Ruby:
http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
Has anyone used this in production?
Re: Nimrod: C + Macros + GC
#16Can someone explain why is this so much better than c++?
Re: Nimrod: C + Macros + GC
#17I've been tempted by this one several times. I may have to play around with it and SDL2. One thing that gets me, though, is the var keyword in a statically typed language. Why say "var thing: string" instead of "string thing"? I think that consistent, explicit declaration of types is much cleaner and easier to read than this recurring mixture of type inference and annotation.
One point in favor of inference is that it gives you less to read, and what the compiler can infer, the reader usually can, too. On the other side, you could say you shouldn't have to infer while you read and having types in front of you reduces cognitive load.
I bet the folks building these languages with inference probably and wouldn't mind having fewer annotations (and being more consistent, in a sense) if they could. It's just that to get rid of some of these annotations you have to make deep changes to the language, like OCaml's polymorphic functions, and that may be inconsistent with their design goals or just hard.
Obviously folks won't agree on whether inference is a great thing or not. Whatever one's used to usually seems easier to read. I've worked more in dynamically typed langauges than statically, and (so) languages with inference feel more like home.
Re: Nimrod: C + Macros + GC
#18What would be really killer is if it could have bindings to Java. Then one could take advantage of the JVM being present everywhere w/o having to do a separate compilation for every platform.
Re: Nimrod: C + Macros + GC
#19This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++.
But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts.
As another commenter below noted, the var and proc thing is also redundant and annoying. However, the ability to compile to C (and, as a result, to easily cross-compile) is really nice.
Re: Nimrod: C + Macros + GC
#20Can someone explain why is this so much better than c++?
Nobody can explain to a dedicated C++ programmer why a new language is better than C++. I have tried for more than a decade many times and all I have ever gotten across has apparently been a "wah wah wah" noise like the adults in Peanuts.
Because C++ is multi-paradigm, all paradigms are possible within it (although they may not be syntactically easy or have reasonable error messages, etc etc). Therefore, either C++ is the obviously the best language (to its partisans) or it is a hellish agglomeration of mutually contradictory confusing crap that takes years to begin to understand (to its detractors). Unfortunately, those two camps each find their position obvious, and seem to be unable to communicate with one another.
std::cout << "This does what??!" << endl;