lobster_johnson 1 day ago
link |
Nimrod looks a lot like someone took Borland's ObjectPascal? and removed the begin/end block semantics in favour of whitespace indentation.
For example, they use the "var: type" syntax; the syntax for declaring classes is nearly identical; "case [value] of" is right out of Pascal, as is the "0..2" range syntax. They refer to "procedures" as opposed to functions. They even use naming conventions from ObjectPascal?: "T" as a prefix for types (eg., TChannel), "P" for the Nimrod equivalent to pointers (eg., PChannel is a "ref TChannel"), "F" for class members.
I would not be surprised if the author was an old Turbo Pascal/Delphi hand.
reply
--
mynegation 1 day ago
link |
This is the closest to my ideal language I've ever seen. Elegant and expressive syntax of Python, statically typed with automatic type inference, compiled to native code, garbage collected, macros, AST manipulation, very comprehensive "batteries included" standard library. Definitely worth a closer look!
reply
--
xaa 1 day ago
link |
This 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.
reply
WalterBright? 1 day ago
link |
Since I've written a C compiler, I know how to read C source files. The problem with automated conversion is you can do 90% of the job without any trouble, but there's that darned last 10% that doesn't map to D without some human decision making.
For example, there are the preprocessor macros. Most are straightforward, but it seems most C .h files succumb to the temptation at some point to do something wacky with them.
--
" If you don't like Scala, thanks for sharing, but I don't see how it affects me, I will still continue using it as my go to language until I find something better (there are contenders, Kotlin, Ceylon, Dart, TypeScript?, and my favorite now - Nimrod, but there is still a big gap for me to fully switch) "
--- http://nimrod-lang.org/talk01/slides.html#%287%29
What is Nimrod?
A statically typed
var input: TaintedString?
systems programming language
var a = cast[int](gch.stackBottom)
with a clean syntax
iterator from1to2(): int = yield 1; yield 2
and strong meta programming capabilities.
template `!=`(x, y: expr): expr = not (x == y)
Implementation aspects
Nimrod compiles to C; C++ and Objective-C are also supported it compiles to JavaScript it provides a realtime GC which supports max pause times of 1-2 miliseconds which means it is perfectly useful even for demanding games the Nimrod compiler and all of the standard library (including the GC) are written in Nimrod whole program dead code elimination: stdlib carefully crafted to make use of it; for instance parsers do not use (runtime) regular expression -> re engine not part of the executable the GC is also optimized away if you do not use it
our infrastructure (IDE, build farm, build tools, package manager) is also completely written in Nimrod
echo "hello ", "world", 99
is rewritten to:
echo([$"hello ", $"world", $99])
echo is declared as: proc echo(a: varargs[string, `$`]); $ (Nimrod's toString operator) is applied to every argument local type converter: only in this context everything is converted to a string via $ in contrast to C#/Java's solution this requires no dynamic binding
it is extensible:
proc `$`(x: MyObject?): string = x.s var obj = MyObject?(s: "xyz") echo obj # works
nimrod-lang.org/talk01/slides.html#(24)
Nimrod's focus is meta programming; macros are used
1. to avoid code duplication / boilerplate:
01 template htmlTag(tag: expr) {.immediate.} = 02 proc tag(): string = "<" & astToStr(tag) & ">" 03 04 htmlTag(br) 05 htmlTag(html) 06 07 echo br()
2. for control flow abstraction:
01 template once(body: stmt) = 02 var x {.global.} = false 03 if not x: 04 x = true 05 body 06 07 proc p() = 08 once: 09 echo "first call of p" 10 echo "some call of p" 11 12 p() 13 once: 14 echo "new instantiation" 15 p()
3. for lazy evaluation:
01 template log(msg: string) = 02 if debug: 03 echo msg 04 05 log("x: " & $x & ", y: " & $y)
4. to implement DSLs:
01 html mainPage: 02 head: 03 title "now look at this" 04 body: 05 ul: 06 li "Nimrod is quite capable" 07 08 echo mainPage()
Produces:
<html> <head><title>now look at this</title></head> <body>
Implementation:
01 template html(name: expr, matter: stmt) {.immediate.} = 02 proc name(): string = 03 result = "<html>" 04 matter 05 result.add("</html>") 06 07 template nestedTag(tag: expr) {.immediate.} = 08 template tag(matter: stmt) {.immediate.} = 09 result.add("<" & astToStr(tag) & ">") 10 matter 11 result.add("</" & astToStr(tag) & ">") 12 13 template simpleTag(tag: expr) {.immediate.} = 14 template tag(matter: expr) {.immediate.} = 15 result.add("<$1>$2</$1>" % [astToStr(tag), matter]) 16 17 nestedTag body 18 nestedTag head 19 nestedTag ul 20 simpleTag title 21 simpleTag li
:
template html(name: expr, matter: stmt) {.immediate.} = proc name(): string = result = "<html>" matter result.add("</html>")
template head(matter: stmt) {.immediate.} = result.add("<" & astToStr(head) & ">") matter result.add("</" & astToStr(head) & ">")
...
template title(matter: expr) {.immediate.} = result.add("<$1>$2</$1>" % [astToStr(title), matter])
template li(matter: expr) {.immediate.} = result.add("<$1>$2</$1>" % [astToStr(li), matter])
01 html mainPage: 02 head: 03 title "now look at this" 04 body: 05 ul: 06 li "Nimrod is quite capable" 07 08 echo mainPage()
Is translated into:
proc mainPage(): string = result = "<html>" result.add("<head>") result.add("<$1>$2</$1>" % ["title", "now look at this"]) result.add("</head>") result.add("<body>") result.add("
Compile time function evaluation optimizes 'mainPage()' into:
"<html><head><title>now look at this</title></head><body>..."
---
https://news.ycombinator.com/item?id=6820474
---
rdtsc 4 days ago
link |
I am sold. I really like it!
reply
progman 4 days ago
link |
Some very interesting features of Nimrod which I would like to emphasize:
I am working with Nimrod right now, and it is really one of the most productive languages that I ever encountered. It seems to mix the best features of other popular languages. Nimrod actually is where Python should be. I wonder if it is suitable for small embedded systems also.
By the way, one important difference to Perl regular expressions is that re"..." always parses the whole expression where Perl parses partially. Fortunately Perl's behavior can easily be simulated with a template.
reply
TylerE? 4 days ago
link |
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)
hcarvalhoalves 4 days ago
link |
> 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.
reply
TylerE? 4 days ago
link |
As someone who has spent much of the last decade or so writing Python, I mostly disagree. The pain points I've had with python (speed, mainly) are well catered to by Nimrod. I agree that it's not "pythonic" in some ways, but the feeling is very similar. The wtfs/line ratio is very low.
reply
andrewflnr 4 days ago
link |
What do you mean by "Nimrod is where Python should be"? The two languages are aimed at very different use cases.
reply
progman 4 days ago
link |
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.
reply
ericb 4 days ago
link |
This looks really neat!
Looks like a cross-platform language thats an even more acceptable lisp than ruby (hello macros!), with multiple build-language targets including C/javascript/C++ and a fast garbage collector? Like Go, but even cooler?
reply
ericb 3 days ago
link |
My enthusiasm is greatly lessened. The IDE doesn't compile on Mac OS X. Even worse, the developers don't care, and keep closing the issue.
https://github.com/nimrod-code/Aporia/issues/37#ref-issue-17...
As a rule, I avoid any project where the developers have too much of the it-doesn't-work-and-I-don't-care attitude, mainly because you can't build on top of a foundation that isn't maintained fastidiously--you'll waste all your time fixing the foundation and won't get productive work done. Culture matters.
reply
mortyseinfeld 2 days ago
link |
Don't worry. You'd be better off using a normal text editor anyway. GTK+ is flaky on non Linux/BSD systems.
They should note what some of the OpenDylan? folks are doing and write a plugin for Intellij.
reply
---
twotwotwo 3 days ago
link |
It has a lot of cool stuff, and I'm intrigued by its approach to threading. (Per-thread heaps and message passing, with an unsafe shared heap if you need it.)
How does dynamic typing work in Nimrod, if it has it? What's the equivalent of being able to call Write() on any io.Writer in Go, for example? [Edit: just found the explanation at http://nimrod-lang.org/tut2.html#dynamic-dispatch but have not yet read and digested.]
I'd love to see some open-source projects that've been written in it--the Nimrod tools and stdlib are obviously a good start. I think one of the things that really helped Go was having lots of n00b-friendly content (the tour, a short "spec", Effective Go doc, blog posts, talks); you could call it "marketing", but it really helped me, at least.
reply
---