Slashdot Mirror
Nim Programming Language Gaining Traction
An anonymous reader writes: Nim is a young, statically typed programming language that has been getting more attention recently. See these articles for an introduction: What is special about Nim?, What makes Nim practical? and How I Start: Nim. The language offers a syntax inspired by Python and Pascal, great performance and C interfacing, and powerful metaprogramming capabilities. The author of "Unix in Rust" just abandoned Rust in favor of Nim and some early-adopter companies are starting to use it as well.
When that comes out - I'm buying it regardless of whether or not I actually need to learn or use the language.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
A new fad sweeps through the kiddies every 3-5 years. I guess everyone wants to be one the crest of the new wave so they all rush out to learn the newest one, hoping maybe they'll get to write the book or teach a bootcamp, after it gets advertised on Slashdot of course.
I lurk on the Nim IRC channel sometimes. The toxicity there is unbelievable.
Look at these recent IRC logs, for example.
We see insults like:
And there's lots of unnecessary sarcasm:
Then there's lunacy and quasi-psychotic ranting and rambling:
Or because some people can't cope with another variation on C++.
They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.
Or because they don't want to cope with C++ even though they can. Because C++ is like the BDSM of programming languages.
There's no Wikipedia page on this language. Just an external link in the disamb page.
Why did you conveniently list only languages that use braces to delimit code blocks? The common "FIOC" complaints have never been about "muh braces", they're about making code blocks implied by indents rather than explicit. Braces are just one form of explicit block delimiters, but there are others. Ruby, for example, starts blocks implicitly with if, until, while, etc and ends them with "end". Despite not having braces, it's fine, because the blocks are explicit. The start or end of a block does not accidentally occur, where as this can happen all the time in python.
By the way, what is python's way of handling grouped statements like these:
Technically the inner for statement is within the outer for statement, but an annoying additional level of indentation can be avoided because the language doesn't require it. Besides, it looks nicer to the programmer. Even if you contest the need for this as two loops instead of one, just look at C#'s nested using statements, which are often on the same indent for simplicity.
You'll be having interviews with companies you most likely won't want to work for.
I was looking at the last link in TFS and in the comments to that link there was this little gem that should force you to take a large grain of salt before committing to a major Nim effort
Nim High Priority Issues
Now, I am not familiar with how other, similar languages were at the same stage of development, but given things like this I would be putting Nim in the "Not ready for prime time YET" basket (which is also how I feel about Swift at the moment - there seems to be too many things in a state of flux right now)
I am Slashdot. Are you Slashdot as well?
Nim is just yet another statically-typed GC language with an unsafe escape hatch. I can get the same thing (and much better syntax) with Java and JNI or C# and P/Invoke. Yawn.
Rust, on the other hand, is something genuinely new: it provides completely memory safety without a requiring a garbage collector at all. It's sad to seeing people switch from Rust to Nim: they're often too inexperienced to know what they're giving up, and I feel like they're seeking (syntactic) novelty, not a programming environment that's actually useful.
And suddenly C++ became much more interesting...
The second for loop should be indented. I have trouble believing that you really think the non-indented version is more readable, or conveys the algorithmic intent well. If you were applying for a job with my team and you made this argument, I would find it very difficult to hire you.
Alternate interpretation: nicely trolled. I bit.
What we need more of is science!
Implicit blocks are bad, for many reasons which I'm sure you've already heard. The problems don't just affect developers, mind you, but the language as well. They're the sole reason why anonymous functions in Python are so horribly crippled, for example.
The only reason Nim includes this retardation is that it's written by a guy convinced that the ridiculous mistake Guido made was actually a good idea. I get it: you like Python. Here's the thing, you like Python in spite of the ridiculous white space rules, not because of them. You've spent so many years defending that absurd design decision that you've convinced yourself that it's actually good.
Oh, BTW, with a sensibly designed language, just about every editor out there can format code properly with a single keystroke. The only possible argument in favor of Pythons implicit blocks, forcing idiots to indent their code, is essentially meaningless.
Required reading for internet skeptics
> What, you don't normally indent your C, C++, Java, C#, JavaScript or Perl code?
OK, I'll bite. Not the OP, but I'm against *forced* indentation too.
Programs have two target audiences: the compiler (I'll subsume interpreters here) and the human. Of those, the second one is the more important: a program must be written in a way that a human reader has a chance of convincing herself that it is doing the "right thing".
That's why I enjoy having different channels. The indentation is for a human. Syntactic strukture is for both: compiler and human. And while there should be a tight correspondence between the channels (my editor helps in that), I enjoy tweaking the indentation from time to time to make a point towards the human reader.
> You just left-justify every line? Is that why you're so against indentation?
Nice red herring you have there.
The compiler for it is written in Swift. Pass it on!
Thank you. The "why don't you like indentation?" argument is nothing but a ridiculous straw man...the issue is not the use of indentation to reflect structure (which, as you point out, Python actually interferes with in some cases...it gets worse with higher dimensional cases such as voxel maps), it's with the lack of properly delimited blocks. With blocks being implied by indentation, you lose an important visual anchor and cross-check of intent with the compiler, and what do you gain? Potential problems with tab characters, code truncation errors that are undetectable until you attempt to execute the code, huge headaches if you have to use code that has had its indentation broken...there are no positives here, unless the proponents are seriously objecting to the onerous burden of typing a few } characters or "end" keywords.
Indentation significance is a design flaw, and it's disappointing to see it repeated yet again...
Scoping by invisible characters is bad enough but modifying operator precedence by invisible characters? Why do people think that using spaces, the invisible character, as syntactically meaningful characters is a good idea? For readers of English the space is only important to separate meaningful bits and now we have a language that you will need to count spaces to determine operator precedence?!?! Of course it always cooler to use binary progressions so the operator precedence feature uses sequences of 1, 2 4, and 8 spaces. I can only hope that the language is a joke as per it's original name, nimrod.
Maybe it would be useful if they dumped the space dependency, but after reading that I quit taking it seriously.
nim, like python, requires strict indentation. That's not comfortable for some people. I, for one, have nystagmus and find it practically impossible to code in python. I suspect I'd have the same issues with nim.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
You'll be having interviews with companies you most likely won't want to work for.
Hasn't that been true since at least the turn of the century?
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
All hope abandon ye who enter here.
IMO, only lazy, inept, or noob programmers don't indent correctly. So if a language requires them to indent properly, they call it forced indentation because they usually don't indent correctly in other languages.
If I'm wrong, how many different ways can you indent the following code?
for x in range(1,10):
for y in range(1,10):
if someCondition:
result[x][y] = a[x][y] + b[x][y]
Somebody, who wrote a book an a language I've never heard of, has now switched to another new language. Whether he has an agile and flexible mind or simply is not particularly loyal to anything, I'm not impressed...
In Soviet Washington the swamp drains you.
I just recently learned python (learned it from a top python core developer, though, if that counts any).
I like the language. almost all of it. BUT, the lack of curly braces was a huge mistake. indentation is fine. we all agree its needed.
here's where 'whitespace only' indenting messes up. ever see what blogs do when you try to post code? yeah. that. and its a reality, too. you will never be able to guarantee that posted code won't be 'changed' by some web formatter or email formatter!
twice in the last 2 months I've had to extract posted source (from clueless posters) and FIX their code since it did not run OOTB. I had to GUESS where things were supposed to be nested. its not obvious; if it was, you would be able to strip all spaces out and still be able to get the same meaning.
guido just did not think about this issue. its ok, he thought about most things, but I wish he'd man-up and admit that in THIS case, curlies are truly needed. keep the rest of the forced indenting, but ADD an open and close curly so that the meaning is crystal clear, even if mis-posted or mis-indented. plus, you would be able to re-format the source to your local google 2-space standard or the rest-of-world 4-space standard.
oh, and it would not really hurt if you did have static data types. there's huge value in:
int foo (int a, char b, float c);
if you just tell me you are sending a,b,c into a routine, there's a lot that I should know that you're not telling me. it was a shame to lose this. not sure the 'power' you gain is worth the loss of immediate documentation (in the code) by declaring the types of each var and having that var always (for its scope) be that data type.
--
"It is now safe to switch off your computer."
I agree. it needs the curlies (which WORK great in C and takes up at most 3 chars; 1 for the curlie and 1 for a space before and after. 3 extra bytes for intro and maybe 3 for exit. 6 bytes. big deal. you should 'waste' more space with comments and vertical/horizontal whitespace, just for readability, alone.
it should have been optional. require indentation, fine. but also ALLOW those of us who like seeing an 'open and close' semantic who is explicit (not just implied) would have been the right thing to do.
someday, maybe guido will come to his senses. if/when that happens, a lot of us will breathe a sigh of relief. and then, posted code on blogs, emailed code, etc, will still be runnable without GUESSING what the source was before the formatter destroyed it.
--
"It is now safe to switch off your computer."
Python has multi-line strings. I know that fact won't change your mind, but it might help you look less ignorant.
What we need more of is science!
Please stop, this is getting really tiresome. Python has multi-line strings without special escaping:
http://stackoverflow.com/quest...
You just look like an ignorant idiot with an axe to grind with this obsession over a non-existent problem.
Speaking of obsessions, Python programmers don't obsess over forced indentation. It's the people who violently dislike Python who keep harping on it.
What we need more of is science!
Oh god oh god, please don't do that. Not indenting the inner loop here is horrifically unreadable.
OK, you can consider Python as a heavily standardized version of indentation. Python's entire objective is the human reader. It doesn't leave you and 10 other developers from "tweaking the indentation from time to time to make [their own] point toward the human reader". What people don't understand is that one's interpretation of what they write could be different from others. What one finds easier to understand, others find harder.
There have been countless times that I have read really good Java and C code and could start picking out which individual developers developed where. Do you know how much start up time is wasted in learning Dev1, Dev2's... DevXs' version of the C language? And if you touch C++... each dev has "minor versions" as they learn new ways of doing the same thing. And these code reviews are done in highly standardized environments with docs and comments. Still each developer gets their own unique version of a standardized language. And don't get me started on Perl or Ruby. There are no such things, there are just a ton of individual essays that the Perl and Ruby interpreters understand and execute.
With Python, there is still a lot of uniqueness among developers, but you really need to look for it at the higher levels. Like method & class relationships, program execution flows, or logic design. But at the low level of reading & understanding code from a team of developers, it is dead easy. There are slight variations, but not enough to need to learn that style of coding to help in the future. That is the benefit of Python, its a global coding standard that's built into the language itself. Something that development companies spend far too much money [re]implementing every year for their dev teams.
Now, I am not saying this is best or the way it should be done. Its just one standard where none really exist.
Right... and I have seen this same code written in the following versions:
for (int y=0;yheight;++y) for(int x=0;xwidth;++x) code here
for (int y=0;yheight;++y) {
for(int x=0;xwidth;++x) code here
}
for (int y=0;yheight;++y) {
for(int x=0;xwidth;++x) {
code here
}
}
for (int y=0;yheight;++y)
{
for(int x=0;ywidth;++x)
{
code here
}
}
You ask C devs how they would write it, and you will see they spread out across the above. Of course this is an overly simple example.
Python folks will mostly gravitate to reactor451's version. Are there other versions? Yes, especially when you add in iterators and generators, but for even those, developers will gravitate to ONE version of it totally dependent on if they use that feature in their coding.
#Python 3.0+
for y in range(height):
for x in range(width):
code here.
And if this is too far in indentation, then the Pythonic way says that your code is already too complicated and this section of the code should really be delegated away in its own method.
it should have been optional
this could be easily added without breaking compatibility. you could even write a preprocessor, if it bothers you that much. it is indeed a big constraint with little or no benefit, but most python users seem not to mind, or even like it. many languages have made some of such arbitrary decisions that are purely idiosyncratic, usually pointless but defended with zeal. if the language has other values you simply live with it or hack your way around.
I agree. it needs the curlies (which WORK great in C and takes up at most 3 chars; 1 for the curlie and 1 for a space before and after. 3 extra bytes for intro and maybe 3 for exit. 6 bytes. big deal. you should 'waste' more space with comments and vertical/horizontal whitespace, just for readability, alone.
Haha, here you all complain that Java is too fluffy, but if a language reduces the fluff it is also not good?
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Me, I love Python.
Me too. But in spite of the indentation, not because of it. Indentation gets goofed up all the time. For bracketed languages, you just run "auto-indent". For Python, you interrupt your train of thought for ten minutes while you debug the whitespace.
Yet Another Programming Language.
Same shit, different syntax.
And now, some HR idiot is looking for someone with 5 years experience in it.
Someone has some books and training courses to sell to language hipsters.
Haha, here you all complain that Java is too fluffy, but if a language reduces the fluff it is also not good?
Oh this hipster coders.
Syntax is not fluff.
Wrappers for wrapper for adapters for wrappers - commonly found in the huge, so called "enterprise" software, is fluff.
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Language is a tool.
It should give me, the developer, the choice - not take it away from me.
All hope abandon ye who enter here.
Python's block structure isn't about saving characters or about saving typing. It's about "There should be one-- and preferably only one --obvious way to do it."
In C, for example, there are multiple ways to place braces. In fact, there's even a lengthy Wikipedia page on that very subject.
In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].
Python's indentation is utterly Pythonic because it is compact, yet meaningful. It carries blocks to their logical conclusion. I started in Pascal with begin/end, then learned that braces were better in C, then learned that no braces were best in Python. QED.
In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].
Then don't. Use your preferred style at work, and then convert it to your employer's preferred style with "indent" before checking it in.
Exactly. Imagine a brand of beer whose primary selling point was that it came in a bottle so small that you could drink an entire bottle in one gulp. Although that might be a nice novelty, the beers that come in a larger bottle probably are more enjoyable overall.
IRC is just a bad medium for mature discussion to begin with (but forums suck in many other ways, so where does that leave us). The IRC channel for most *any* project is unnecessarily toxic. Just because Araq is on the IRC channel doesn't mean the whole project is polluted by the ramblings of one or two fans/hecklers/wannabe devs.
My view of Nim from the web pages presented in the summary, and the online docs is very different from your IRC-centric view. I've personally been very impressed with the quality of the documentation, tutorials, and papers I've read so far. I don't think I've seen as friendly and readable documentation for any project in a long time. Perhaps quality will drop as Nim becomes more popular and people concentrate on developing. But for a project that has seemingly come out of nowhere, this really impressed me. Not only is Araq apparently a decent programmer, he's also a good writer too.
Thank you to the submitter for submitting this. I had never heard of Nim before today. Adding it to my short list of very interesting new languages to follow.
Of course python does allow block delimiters. Just remember to indent your code right.
The delimiters are #{ and #} (should be put on their own line)
I've used "indent" many times in the past, and although it's better than nothing, it isn't really a solution for this problem. You have to go fix numerous other small style issues. For example, my employer has a very detailed - though quite eclectic - style. So, indentation and other issues that "indent" can deal with are only a small part of the problem. Also, K&R is my preferredstyle (I personally think Whitesmiths is dopey, but YMMV.) I'll concede my artistic integrity for pay at work, but not for free at home.
Regardless, my primary point (and Guido's, in Python) is that braces lead to a variety of defensible styles. We all have our preferences, but there's really no way to determine which is "best".
Also, for the record, I should mention that Python allows indentation to be any consistent level, with hard tabs counting as 8 spaces. Though it's seemingly contary to the aforementioned principle, that one can be filed under "practicality beats purity."
Tim Peters once said explained such contradictions with something like "the key to any successful philosophy is to allow yourself enough wiggle room to do what you really wanted to do in the first place." [wink]
It limits expressiveness for no reason other than dogma.
I like the language. almost all of it. BUT, the lack of curly braces was a huge mistake. indentation is fine. we all agree its needed.
In addition, according to the Language Manual, Nim supports the directive "#! strongSpaces" to allow white space to affect operator precedence. An example from the manual:
#! strongSpaces
if foo+4 * 4 == 8 and b&c | 9 ++
bar:
echo ""
# is parsed as
if ((foo+4)*4 == 8) and (((b&c) | 9) ++ bar): echo ""
So with/without the directive:
It must have been something you assimilated. . . .
In Python, that could easily have been one or more statements that were unintentionally made conditional or removed from the conditional, perhaps while adjusting the indentation of adjacent just-moved code so the interpreter would put it in the right block. Python's indentation significance doesn't improve things one bit. If you want a fix for this problem, make the end delimiter non-optional, which would make it much more difficult to accidentally put a statement in the wrong block.
And of course, the presence of delimiters does nothing to prevent a language from requiring indentation or producing warnings when it finds inconsistencies between indentation and delimiters.
Looks like a readable python variant.
Religion is what happens when nature strikes and groupthink goes wrong.
Your argument that your poor code is likely to operate in a poor manner is not a valid objection to Python's indentation. It merely condemns your abilities as a coder (and perhaps your ability to choose an appropriate editor as well, but I repeat myself.)
Write good code, no problem. Your argument simply boils down to you claiming you're a lousy programmer. As do many similar arguments, such as thinking types are required because you "might" call a function wrong, or use a variable in some stupid way. If you call the function wrong, or misuse a variable, you are failing as a programmer. Do it right. Problem solved.
Back in the day, when we were writing in assembler more often than not, you'd have been laughed out of the building if you complained that the assembler should "know" what it was looking at beyond the most simple atomic architecture-related constructs. The fact is, as a decent programmer, you should know what you're looking at, and what you are doing at all times. If you don't -- the problem is 100%, entirely, beginning-to-end -- yours. You need improvement. You should seek it. Your failings will lead to bugs. Not the language's failings -- yours.
I've fallen off your lawn, and I can't get up.
Except it doesn't complain when you have a mismatch.