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

What is special about Nim?

hookrace.net

Post reply on HN
Print view View original

71–80 of 88 posts

Re: What is special about Nim?

#71

Post by klibertp »

TylerE wrote: post #66
klibertp wrote: post #63

Earlier quoted context omitted.

To be a bit more specific as to where else these ideas are found: * Run regular code at compile time Lisp, of course. Since very long ago. * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! Lisp, but also Dylan, Elixir, JS with Sweet.js and more. See for example here: https://opendylan.org/articles/macro-system/index.html * Add your own optimizatio…

Simple... the list of languages that provide Lisp-level dynamism AND C level performance is rather short.

Some Lisps, some Smalltalks, modern C++ and D, Haskell, Clean, SML, OCaml, Dylan, Rust, Factor, Felix, some (AOT compiled, commercial) Java implementations... and so on.

Only very tiny fraction of ideas or implementations are really new in programming language design. There is "prior art" for nearly everything, sometimes dating back to sixties. And being both dynamic and fast has been a research topic for decades now. The problem is hard, but we're steadily making progress - as a result we created a lot of (both abandoned and still alive) languages along the way.

Re: What is special about Nim?

#72

Post by TylerE »

klibertp wrote: post #71
TylerE wrote: post #66

Earlier quoted context omitted.

Simple... the list of languages that provide Lisp-level dynamism AND C level performance is rather short.

Some Lisps, some Smalltalks, modern C++ and D, Haskell, Clean, SML, OCaml, Dylan, Rust, Factor, Felix, some (AOT compiled, commercial) Java implementations... and so on. Only very tiny fraction of ideas or implementations are really new in programming language design. There is "prior art" for nearly everything, sometimes dating back to sixties. And being both dynamic and fast has been a research topic for decades now…

Those are generally 2x to 5x slower than C.

Re: What is special about Nim?

#73

Post by BuckRogers »

I've had my eye on Nim(rod) for a long time. I think this language may be the right thing, at the right place at the right time.

I haven't seen a better boat for Python refugees to jump into. It's certainly worth evaluating if moving from a Python2 codebase, rather than porting to 3. It's far enough along that it can start poaching users looking for the best place to jump off from 2.x.

The only thing I'd like to see them somehow do, is add a CPython2.x library compatibility layer. If that could somehow be engineered into Nim before 1.0.. I think I'd declare Python3 to be in serious trouble.

The users WILL come if that's done. Maybe take a look at Nuitka in how to make this possible with the binaries that Nim produces. Or even just include the CPython2 runtime in the compiled binary if a user includes Python(2) code.

Re: What is special about Nim?

#74

Post by kevin_thibedeau »

def- wrote: post #34
rogerbinns wrote: post #21

Earlier quoted context omitted.

As a pythonista one thing that struck me in the code fragments is zeroes and ones appearing everywhere. It looks very easy to have off by one errors. (It is very rare to have off by one errors in Python due to the way counting and ranges work.)

I guess you could use fewer magic numbers if you want, for example instead of: proc createCRCTable(): array[256, CRC32] = for i in 0..255: You can write: proc createCRCTable(): array[256, CRC32] = for i in result.low .. result.high: Or: proc createCRCTable(): array[256, CRC32] = for i, v in result: # index, value Or define your own indices iterator: iterator indices(x) = for i in x.low .. x.high: yield i proc createC…

It does strike me as odd that some Ada-isms are present like 'low and 'high, applicable to types and objects, but the ever useful 'range didn't get included. It is a testament to Nim's flexibility that it can be added, effectively as a one-liner. This really should be in the standard library.

Re: What is special about Nim?

#75

Post by kevin_thibedeau »

danso wrote: post #35

A little OT: Courtesy of the Reddit discussion of the OP, a reference to the discussion on Wikipedia about Nim, or rather, the discussion to delete its Wikipedia entry: https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio... At what point does a language become noteworthy enough for a site that contains full entries for side characters in non-canonical Star Wars novels?

Not to mention detailed articles on Pokemon products, something with decidedly less cultural impact than Star Wars.

Re: What is special about Nim?

#76

Post by kevin_thibedeau »

tenfingers wrote: post #5
mej10 wrote: post #2

This was a helpful writeup. Nim has a lot of really nice features. Are there any problems or things you find lacking?

The idea that thisFunction and this_function are the same might be worse than the problem they're trying to solve. I cannot unfortunately have experience with larg-ish codebases in nim to tell if this would result in an actual problem or not, but the idea that I have to scan between two possible identifiers in the code can be a source of stupid bugs in the same vein as case-insensitive identifiers. On the other hand…

Case-insensitivity is not that much of an issue in static languages. It eliminates the burden of having to remember the Studly-Camel-Lumpy-style-du-jour. Accidental name clashes will be caught at compile time. Nim's hybrid approach is more adventurous but I can only see it being a problem with reusing symbols from other case-sensitive languages.

Re: What is special about Nim?

#77

Post by TylerE »

sillysaurus3 wrote: post #67
TylerE wrote: post #66

Earlier quoted context omitted.

Simple... the list of languages that provide Lisp-level dynamism AND C level performance is rather short.

Have you ever actually used Lisp, or are you going off of speculation? I have. It can deliver just short of C level performance. This is like someone going onto a forum and saying "Java is slow!" while ignoring the fact that trading institutions use Java as their primary language for stock market trading. And they wouldn't do that if Java was slow. I'm trying to be as patient as possible, but this is really getting o…

Yes, I have. Lisp code with all the tweaks to even think about approaching C in speed is ugly, ugly code.

Re: What is special about Nim?

#78

Post by sillysaurus3 »

TylerE wrote: post #77
sillysaurus3 wrote: post #67

Earlier quoted context omitted.

Have you ever actually used Lisp, or are you going off of speculation? I have. It can deliver just short of C level performance. This is like someone going onto a forum and saying "Java is slow!" while ignoring the fact that trading institutions use Java as their primary language for stock market trading. And they wouldn't do that if Java was slow. I'm trying to be as patient as possible, but this is really getting o…

Yes, I have. Lisp code with all the tweaks to even think about approaching C in speed is ugly, ugly code.

GOAL code was many things, but "ugly" is a stretch. Jak and Dexter did more than any game of its time, and the only reason they were able to do that is because of the flexibility of the codebase.

Its performance wasn't merely on par with C, but actually surpassed C in many cases. For example, they were able to stream content from disc dynamically while the game was running, and no other engine had that capability. That sounds unrelated to "performance" since it's a design decision, but in fact "performance" is everything which the end user cares about, such as load times. And the only reason the game engine performed well was Lisp. Many of Jak and Dexter's competitors didn't survive, performance problems being one of the reasons. (Game publishers used to cancel projects if development milestones aren't being met, such as a convincing tech demo. So if a tech demo was unconvincing, e.g. due to extreme performance problems, publishers basically killed the company. Maybe that's even still true as of 2015, but it was definitely true in 2001.)

EDIT to your reply: You're right, I edited my comment and added a second paragraph. Also, I apologize for my earlier tone. It was uncalled for and needlessly argumentative. Sorry.

Re: What is special about Nim?

#79

Post by TylerE »

sillysaurus3 wrote: post #78
TylerE wrote: post #77

Earlier quoted context omitted.

Yes, I have. Lisp code with all the tweaks to even think about approaching C in speed is ugly, ugly code.

GOAL code was many things, but "ugly" is a stretch. Jak and Dexter did more than any game of its time, and the only reason they were able to do that is because of the flexibility of the codebase. Its performance wasn't merely on par with C, but actually surpassed C in many cases. For example, they were able to stream content from disc dynamically while the game was running, and no other engine had that capability. Th…

You keep making this argmuent without really any justification besides "it just is". Everything I've read about Jax and Dexter says that it's pretty much amazing it was actually released because ND spent so much time on the esoteric, non-standard, bus-factor-one compiler-cum-game engine that they had very little time to actually make the game.

Re: What is special about Nim?

#80

Post by hugs »

def- wrote: post #55
barbudorojo wrote: post #51

What I don't like about Nim is that there is not a repl. In Lisp and Clojure you don't need to compile things. Could someone give a brief comparison between Clojure and Nim? Let's suppose that we implement Clojure in Nim is this a crazy idea?, What about implementing Shen in Nim?. Many people complain because sbcl is not easy to use with C++ libraries, could an implementation in Nim amilliorate those problems?. Many…

Well, there is a REPL, but it's not that great: $ nim i >>> for i in 0..10: ... echo "Hello World"[0..i] ... H He Hel Hell Hello Hello Hello W Hello Wo Hello Wor Hello Worl Hello World To use up/down keys, build the Nim compiler with "./koch boot -d:release -d:useGnuReadline" or run "rlwrap nim i" instead. Edit: It's even buggier than I remembered, best avoid it and use "nim -r c file" instead.

What bugs or things-that-are-not-great have you run into with Nim's REPL?
Post reply on HN