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?
Seeing as it's been around and alive for nearly 10 years, I'd say your prediction is not going to be true.
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!!!!"
That and the language (lack of) compatibility.
I wrote a project in 2.6 a while ago but a week before production I'm told that the machine would use 2.4
Imagine my surprise when I noticed that some keywords were working differently (something about the exception handling was looking like it was working, but breaking, I don't remember exactly what).
Now, if I want to use some scripting language to quickly so something (by opposition to do something fast) I use perl (cleanly) or bash.
(For the serious stuff I'm more an asm/C/C++/C# guy anyway.)
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
I prefer {} instead of tabs/spaces to define my code blocks. It's the only part of Python I don't like.
Same here. I confess I like the "syntactical sugar" of curly braces. I think it improves readability by an order of magnitude. The whole deal with using whitespace as code block delimiters seems retarded to me.
Just cruising through this digital world at 33 1/3 rpm...
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!
Nim sounds similar in its goals to D, another batch-compiled statically typed language with GC. The main difference is that Nim seems to innovate a lot syntactically. How do the languages compare otherwise?
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'
Looks like another language that does not thoroughly address parallel processing. With the mention of go, I was hoping for something like goroutines (one of the few things I like about the language) - but no. Doesn't look like it.
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.
Sorry, I can't disagree with you more about this.
As a videogame programmer, a significant amount of what I do is working with user-defined types like geometric vectors, matrices, quaternions, etc, all of which have well-defined operations that use mathematical notation, and it makes a big difference when I can write code in a natural and intuitive style. Just because someone could theoretically abuse a feature doesn't mean it's still not a useful feature. You could completely misname a function that adds two values to "multiply_two_values()", but why on earth would you do that? Are functions with arbitrary names a terrible idea then? It makes no more sense to blame operator overloading for similar imagined "shortcomings".
Even the whole "hidden" factor is less an issue than you'd imagine it to be. In most typical use cases I've seen, operators are overloaded on custom classes designed to work like native types. You're typically aware of when you're using these types, and so you're also aware that you're using overloaded operators. Let's also not forget that operator overloading makes things like C++ smart pointers look and work like native raw pointers, or allows us to use an index operator on a collection, or create a custom variant type which you can use just like native types without having to look up arbitrary method names.
More to the point, in two decades of professional C++ programming, do you know how many times this has actually been a problem for me in the real world? Zero. I've never seen an example of someone abusing operators in a ridiculous way like this in code I've actually used or worked on, but I've seen plenty of examples of when it made for much more intuitive and readable code. I see this brought up as an argument all the time, but I think the concern about this is vastly overblown based on my own personal experience.
Irony: Agile development has too much intertia to be abandoned now.
You've obviously not used Python before. It's very easy to comment out a block of code and it doesn't require indenting anything, and it doesn't require an if (0) kludge. Your criticism and claim of being error-prone is not valid in this case. Python has a lot of gotchas and warts, but what you describe isn't one of them.
Ada was huge in aerospace but the last time I was there they were using this abominable ada to java source code translator.
http://michaelsmith.id.au
>There is no reason that indentation levels couldn't be automatically displayed based on the parenthesis data
Yeah, but nobody does that and even Apple and other huge companies have created horrible security bugs because they extended a branch of an "if" statement to two statements without adding the parens around the two statements that one would need then. Huh.
Yes, but automatic indentation in the editor would have automatically highlighted the mistake, and the programmer could have fixed it immediately. Why are computer programmers such luddites? We try to fix other people's problems with technology, but insist that our jobs should be carried out using 1970s technology.
Meanwhile, you can just have the indentation signify blocks which is how every human alive understands it anyhow and which require no special editor support and no weird manual fixes by the person editing it.
Humans may not vary much, but computer screens do. Consider that the whole point of things like HTML is to abstract out formatting in order to allow the same content to be rendered on various devices, including print.
I really think it's time we started getting smarter with our coding environments. Customisable display doesn't just mean indentation levels. Maybe you want to see an argument list in one line: result = functioncall (size=1, number=2, somethingelse=3)
but maybe I want to see it tabulated, with the arguments lined up on individual lines, and both the parameter names and values lined up in two columns. Or maybe just the arguments on different lines, but within setting up columns.
These sorts of differences exist today as "programming style", even in Python (indentation is meaningless in continuation lines in Python). But because the style (rendering) is an integral part of the source code, the programmer is forced to adapt to the chosen style of the team, project or company they work with. This is inefficient and distracts the programmer from the main goal: writing the code.
I'm more efficient when the information is laid out in the way that I find clearest.
But even that may change with time and with what job I'm doing. Maybe I want to be able to "unfold" a single line into a tabulated form for closer examination, or "fold" a tabulated form into a single line to get the "bigger picture" of the code.
But what I shouldn't have to think about is how anyone else is going to see the source code.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Shhhh... don't reveal the Secrets of NIM
Rats, I really wanted to reveal the secrets...
Ruby is a good example of the magpies in action - they hop from flavor of the year language to language to have something new on the resume and to get in while it's still fun and they can still be trendmakers.
Then they flocked off to whatever the new hotness was (I've lost track) and left it as 'That language you use for Rails'.
Python people just want to get their work done and have the code be maintainable, so it endures.
Nim is somewhat interesting, but even that article says that now the hard work starts - you need a library for /everything/.
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.