Slashdot Mirror
New Release Of Nim Borrows From Python, Rust, Go, and Lisp (fossbytes.com)
An anonymous reader writes:
"Nim compiles and runs fast, delivers tiny executables on several platforms, and borrows great ideas from numerous other languages," according to InfoWorld. After six years, they write, Nim is finally "making a case as a mix of the best of many worlds: The compilation speed and cross-platform targeting of Go, the safe-by-default behaviors of Rust, the readability and ease of development of Python, and even the metaprogramming facilities of the Lisp family..."
Fossbytes adds that Nim's syntax "might remind you of Python as it uses indented code blocks and similar syntax at some occasions. Just like Rust and Go, it uses strong types and first class functions... Talking about the benchmarks, it's comparable to C. Nim compiler produces C code by default. With the help of different compiler back-ends, one can also get JavaScript, C++, or Objective-C.
There's an improved output system in the newest release, and both its compiler and library are MIT licensed. Share your thoughts and opinions in the comments. Is anybody excited about writing code in Nim?
Fossbytes adds that Nim's syntax "might remind you of Python as it uses indented code blocks and similar syntax at some occasions. Just like Rust and Go, it uses strong types and first class functions... Talking about the benchmarks, it's comparable to C. Nim compiler produces C code by default. With the help of different compiler back-ends, one can also get JavaScript, C++, or Objective-C.
There's an improved output system in the newest release, and both its compiler and library are MIT licensed. Share your thoughts and opinions in the comments. Is anybody excited about writing code in Nim?
I prefer {} instead of tabs/spaces to define my code blocks. It's the only part of Python I don't like.
Everyone knows programming languages achieved perfection in 1983. It's a scientific fact.
Then I clicked through from the standard Slashdot post to the Infoworld article to see what was really going on.
Nothing good.
(1) The language is (after _10_ years of effort) in release version 0.16 (2) under the heading of "What it takes to get to 1.0" we get: "[...] Nim's biggest disadvantage right now is the relatively small community of users involved in its development -- an understandable drawback given its status as an independent work. Development is led by the language's creator, Andreas Rumpf, but it's not a full-time effort. Compiler bugs still pop up regularly. Even moderately old code examples may no longer be useful due to changes, and it can be hard to find out what those changes are without closely following the project's development. [...]"
Right. I've heard enough. Keep that crap and don't bother posting until you've got version 1.0 done.
I would be interested in a tool, not in yet another half-baked DIY project.
Here's a big one: overloaded operators are terribad.
"The Nim library makes heavy use of overloading - one reason for this is that each operator like + is a just an overloaded proc. The parser lets you use operators in infix notation (a + b) or prefix notation (+ a). An infix operator always receives two arguments, a prefix operator always one. Postfix operators are not possible, because this would be ambiguous: does a @ @ b mean (a) @ (@b) or (a@) @ (b)? It always means (a) @ (@b), because there are no postfix operators in Nim."
One of the worst "features" of C++ is operator overloading. I don't care how concisely I can write a Matrix class with operators that "look like" real math operators applied to the types; if I can't read a program and know what operators might do because they could be overloaded, then the programming language is inherently very difficult to read, at least with confidence. In my opinion it's much better to have to provide functions to perform actions on types, with those functions naturally having names that describe what the action is. When "a + b" *could mean* "a and b are numbers which are being added together" or *could mean* "a and b are complex types and some completely arbitrary operation is being applied", the language has lost readability.
Just say NO to operator overloading!
Ruby is 22 years old, and regularly someone will come out and say this language will take over the world. And despite a loyal user base, it never really took off. It had a bit of success with the ruby-on-rails framework but it didn't last.
Nim is a bit like that, except that it didn't even have the small success Ruby had.
They do. The object system from smalltalk is the basis of the one used in Objective-C, Java, Python, Ruby among others. Tablet oriented Oses like the dynapad are selling about a billion units a year in smartphones and tablets. The MVC design pattern is the standard for GUIs. And finally WYSIWYG is absolutely a standard in wordprocessing which has now many times over more popular than any other document construction system.In what possible sense doesn't smalltalk rule the world?
As for FORTH the influence is more on the hardware side. Most of the more sophisticated chips (or subsystems within chips) in your computer use a microcode compiler based on the ideas of FORTH. pdf is based on forth. HP RPL is based on forth and influenced a whole generation of programers early in teaching them how to construct dynamic systems out of small parts. I'm not sure if I'd say "rules the world" but "embedded itself into the DNA of computer science forever" is likely accurate.
I strongly disagree.
The first mistake is not knowing C++ well. a+b means operator+(a,b). It's a function call with a funny syntax. No more, no less. Now we're on to function calls, nothing in your language stops someone from writing a function called add() which does something silly. Or sensible.
Why is it worse having a+b than add(a, b) when a and b are complex as per your example?
SJW n. One who posts facts.