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?
Nim (*).
We are The Knights Who Say "Ni!".
(*) In Portuguese, "Nim" can be seen as a hybrid of "no" [Não], and "yes" [Sim]. Often used to express "I could, but I won't".
Interesting how personal preference plays into it. But it also sounds like you haven't spent any real time with Python. Because it doesn't take long to get past the whitespace syntax and get on with programming. For most Python programmers, the block syntax is one of the things they like the most. It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs. But in practice, that doesn't seem to be a significant problem. The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.
I find I can write several pages of Python code and often it runs the first time without issue, which was never the case with any of the other languages I worked with, including C++. Invariably I'd forget some closing brace somewhere and a semicolon. Compile errors on first run are almost expected with C-like languages.
Python's real gotchas emerge more from its dynamic nature than its syntax; dynamic typing is a two-edged sword. Test-driven development is pretty much required for large applications.
Nim of course is statically-typed and has some measure of compile-time safety.
I use indents, braces and BEGIN and END so....
BEGIN
{
code here
}
END
I'm working on a new version of Anal called Anal++
Anyways, the language is designed to keep anal retentive developers arguing in nonsense meetings for years to come. "Oh no! Never put the curly braces and the BEGIN/END on the same line!"
"No, it's better to do so but indent 4 spaces and not a tab!"
"I STRONGLY disagree, you should never use tabs but SHOULD put the curly braces on the same line!"
"No no no! Indent AFTER the Begin but before the curly brace!!!!"
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.
Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.
Wrong question. The single most interesting idea I've seen in Nim isn't something you can see in a piece of code: it's how it aids the programmer in optimising code late. It's only the memory management system, but the idea is that you prototype your code with a garbage collector switched on, and once the code is working, and assuming you need the performance gain, you code up your own memory management routines tailored to your code.
It's an idea that seems logical, but is frustratingly uncommon, and is not normally an in-built feature of the language, but rather just a part of the dev workflow (for example: use a generic sort algorithm from a library during prototyping, then analyse the data you're working with in large-scale tests and select or code a more efficient implementation for your situation). The weakness in doing this manually is that it first means tying your codebase to a library, with its various quirks, and then potentially rewriting vast chunks of code to get it to work with a different library (and then there's the risk of cascading changes).
I think Nim's approach is a small step in the right direction, taking us towards logic first, optimisation later.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
There's nothing to discuss since any algorithm can be written in any turing complete language.
There's plenty to discuss, since the ease with which you can express yourself matters greatly in any practical sense. However, the progress we have actually made in this area is not nearly as impressive as one might hope - new languages mostly bring us the same thing, but with slightly different syntax. Real breakthroughs are very, very rare. Remember the 4GL initiative from Japan in the nineties? Still waiting for that killer language... The closest I've seen is the Wolfram language. Maybe that's the way forward: a massive support library and huge, online databases.
As for Turing machines... On a machine with finite memory, all states the machine can be in can be enumerated, and each state always leads deterministically to a single next state. Since the total number of states is finite (very large, but finite), this means that at some point it must either return to a previous state, or halt. If it returns to a previous state, it will then continue to loop forever (since each state deterministically leads to a single next state). Thus, if you have the capacity to track state changes for long enough, you will be able to determine if a program will halt or not.
And yet, there's Turing's proof. Why the discrepancy? Well, simple: a Turing machine has an infinite tape, and can therefore produce not a finite, but an infinite number of states. Any computer we have in the real world does not have infinite memory, and is therefore not a Turing machine. To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement. You might claim that "any algorithm can be expressed in any Turing complete language", but since we don't have any, that's really a moot point, and we would perhaps be wiser to focus on other aspects of the language rather than a theoretically impossible, and perhaps even undesirable feature.
Your move, AC ;-)
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.
Shhhh... don't reveal the Secrets of NIM
Rats, I really wanted to reveal the secrets...
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.