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.
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.
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.
Forcing code indentation is a sign you're going to be working with a bunch of "coders" who took a weekend course and not actual software engineers.
If you need a language to force you to do what you should be doing and naturally do because of experience, then you're not very good at your job.
There are far more important things in software engineering than being a white space nazi. Something that "coders" don't understand and it shows in their languages of choice.
What's really pathetic about python is that while being obsessed with white space, it can't handle multi-line strings without escape characters. Derp. Indentation essential for readability. Being able to write SQL queries with proper indentation, not important.
It's not surprising that most things people like about these "hip" languages are things you can do (and actually do) in any other language if you're actually skilled. And doing them in the "hip" languages is no indication of skill level.
Work Safe Porn
Who cares? Do you want to use the language or chat with the community? Such people exist in most communities.
The problem with the toxicity is this:
19:04:02 Araq ldlework: I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea
If solutions are being based on emotion and not what is correct, or best, then the language development is well and truly fucked.
I am Slashdot. Are you Slashdot as well?
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!
> 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.
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.
If you were one to write books and training, you might welcome fresh technologies.
+1 for cynicism, but I'll raise you 2:
The other reasons why people go for this are two-fold.
Bonus excuse: Since it's all new, nobody can tell at a glance that you're doing it wrong. :-)
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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."
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!
Oh god oh god, please don't do that. Not indenting the inner loop here is horrifically unreadable.
If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written. For example, R, Python, Java -- no one wants to recode the packages (machine learning algorithms, MPI, web automatisation) in yet another language.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
AFAIK only one person, the creator of Nim (formerly Nimrod), Araq, is in charge of making all the decisions. He has also implemented most of the language and libraries.
That's an excellent reason not to even consider using it at this point. Unless your idea of a good time is maintaining a dead programming language, you should wait until it already has a community and a fork before you even touch it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
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.
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.
Wow.
Removing the ability to screw things up is NOT a bad thing
Can you please elaborate how use of whitespaces for defining control flow is "removing the ability to screw things up"?
If nothing else, use of the invisible characters for something as important as control flow is actively helping "the ability to screw things up".
But does that mean I'm going to poo-poo those languages or try to pretend they're inferior?
The problem is, Python is inferior. Because it provides less tools to its developers.
It's not like C lets you change which brackets do what, does it?
But C does have at least some brackets.
It does have clear visual clues and delimiters in its syntax.
All hope abandon ye who enter here.
It limits expressiveness for no reason other than dogma.
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.