I hesitate to raise this as I'm new to the language but since there is a push to get to 1.0 I think I need to raise this sooner rather than later, at the risk of having egg on my face.
Nim is line-break and indentation sensitive by design so why do we see so many lines of code ending in the separator symbol ':'? Isn't this the kind of syntactic noise that Nim is supposed to eliminate?
Would it be possible to replace the mandatory ':' separator with an optional ':' or IND(>)? {inclusive-or required for backward compatibility}
for example-
could become-
Note that fuction of statement terminator is supplied by a change of indentation, so why can't the separator be likewise?
Edit: Colons don't show up well in the forum's font.
That is a very old discussion known from Python... From the beginning of Python 20 years ago some people have wondered about the colon syntax. Of course it is not necessary syntactically, because syntax is defined by indentation of next line. But code like your above without colons looks strange for many people -- something is missing...
Making Colon optional? Then we have variants with and without. I don't think a good idea. We should try to accept some design decisions. Same for elif, I was not happy with it from the beginning, was used elsif from Ruby. But both is OK I think. Maybe we can tune aporia editor to automatically insert colons, or even hide its visibility. (I hope I will get aporia working with GTK3 soon, at least on Linux...)
Araq: They have been copied over from Python because Guido found after usability studies that they improve readability (as far as I know).
That is essentially correct. The studies were performed for Python's predecessor language ABC, and the results were carried over to Python.
Ah, Guido says..
I found an interesting discussion of this here- http://python-history.blogspot.co.uk/2009/02/early-language-design-and-development.html I'm strongly with Riobard.
Apparently in the early ABC usability testing (early 80's ?) the meaning of indentation was unclear to beginners being taught the first steps of programming without the superfluous colon. Should we also adopt capitalised key-words from ABC?
I suspect if the superfluous ':' were made optional its use would quickly die out.
I'll now stop beating the dead horse.
beating a carcass
I find that the colon syntax makes me wanna inline the whole shabang comming on the next line. AS a JS optimization nerd I kind of like short inline stuff but it sure doesnt read clearer. What is the type of code you want in Nim?
Also my eyes get stuck on the colons when I really shouldnt be, the code reads clear without it.
Reanimation completed. :)
This reminds me of http://www.snopes.com/weddings/newlywed/secret.asp
ABC was a teaching language, intended for people who had never programmed or seen code before. For people who had no prior experience or concept of structured code or nested scope, the colons were useful for getting across the concept. Thus, the reasons for adding the colon, and the usage study, do not apply to Nim. For an elegant, concise language like this, it seems a shame that unnecessary syntactic noise is included for an erroneous reason.
"colons are optional here and here, but not here"
But is it better for colons to be required in some places but not allowed in others? There are no colons after type, var, let, and so on, nor after case <expr>.
I don't expect this to be changed, certainly not now with so many other things to consider moving to 1.0, but I hope that the language designers will remain open to revising their views.
Anyone following nim or you Araq for any length of time will know better than to think that anything in this language was done with any hint of mindlessness. But still colons to me (or semi colons) could be used like in natural languages, as sentance clairifyers. But when not needed they could be allowed to be ommited.
Like so:
Which would be analog to using full stop to separate sentences. But if you want to not do that you could punctuate a sentence with commas or semi-colons, in order to bind related sentences-like structures together. Which in Nim would be with the colon.
if foo: bar+3 else: z
which indeed also makes sence for short easy to read logik.
Analog to the sentences (although i am by no means a language specialist or native english speaker): "The red one was small. Scale was of the essence." "The red one was small; scale was of the essence." "The red one was small scale was of the essence."
EDIT: Not saying that poetic form should not be allowed.
else: z
Brand new user of nim (I love it so far!), so my 2 cents here will justifiably carry no weight. That being said...
I would prefer no colons. I love python but it has a few warts IMO, like the colons. Some examples of significant whitespace languages without colons that are very readable: HAML, Slim, Jade, SASS (not scss), CoffeeScript. Probably more, but these are ones I use and enjoy on a fairly regular basis.
I have no particular opinion in regards to nim and the use of colons. In other words, both syntactic choices are perfectly fine.
My major gripe with nim - and by the way, calling the package manager nimble now is actually a better and more fitting name than babel, as the language; it was a clever thing, whoever had that idea was a clever person - is the documentation or tutorial. I have been mentioning this a while ago, and I think others have mentioned this as well, and hopefully one day the documentation will be really oustanding; ruby still has rather awful documentation, it just so happens to be very flexible and very elegant for my own use case.
Personally I do not like the colon in general - this refers to python mostly.
I never understood why in python I had to indent AND use a colon at the same time.
By the way, when you guys mention the usability guide making : more readable in Python, then you also need to remember that guido once said that if he were to change one aspect of python, it would be the mandatory indent. And the mandatory indent is also an integral part in python when things like this are used:
Because you would not see people want to do this:
def foo(): print("bar")
Without indent, because it would not be valid syntax for python anymore. So the : and the indent go hand in hand here - do you find the second example more readable then the first? I think indent is more important than the : and I also don't mind to make use of indent as syntactic element, as I can omit e. g. "end" or other terminators, like "}". But in python the discussion is somewhat moot because you must use the colon AND the indent anyway, all the time! So you don't have a choice, you must use both combined. You could eliminate the : but the indent would still be the same enforcement. Is there any programming language that uses a : but not mandatory indent?
Also in the discussion there are two main differences - one is about personal choice and preference, and the other is the requirement by the parser.
So the personal preference are just statements about YOUR OWN personal preference. You will ALWAYS find people who prefer this or that way, as people prefer chocolate icecream or vanilla icream (and some people like both). You can not reason when it is about personal preference.
So the part where Araq states that "too much syntantical freedom makes people upset rather than happy" is not an argument. Restrictions make people unhappy too.
"they will invent style guides to essentially remove this freedom again"
I happily ignore all style guides in ruby because the ruby parser allows me a lot of freedom. So why should I artificially cater to any random style guide out there, regardless of how many others would adhere to it? My style guide is freedom, the freedom given to me to use all means that the ruby parser allows me. :-) (I of course restrict this to elements that are elegant, ideally succinct and terse, concise, and logical to me.)
Ruby does not use : and it has never been an issue. There is no mandatory indent, but 99,999999% of the programmers will indent due to readability.
The only issue that has been discussed in ruby would be to make indent an option, so that you could omit the "end" statements. This would be useful on a per file basis, so you could e. g. put a single class into such a file and omit all end statements there - this would eliminate a few more lines. I don't know if that is possible but it has not been implemented and probably won't be implemented either.
"There's just no world where even all the punctuation in Nim taken as a whole could be considered "on the border of hinderance" let alone just the colons."
Again that is your personal preference and opinion here. I consider the exactly opposite way to be true, and hence your statement completely incorrect. How can we argue over style? :)
"That you're using such language inspires me to think that you're really arguing for an "extreme" or "fundamentalist" anti-punctuation position."
Ok but you also adopt a fundamentalist position because in the current form you mandate that everyone must use : - so you do the very same thing yourself here. An optional way would always be the more flexible approach, but unfortunately there are several reasons why you may not want to opt out for options but instead restrict something:
Araq also wrote this here:
After 'case X', 'type', 'let', 'var' and so on, no expression/statement follows but after 'else:', 'if expr:' etc. an expression/statement does follow. Furthermore 'if foo bar+3 else z' is ambiguous without the colon.
And if that is correct than that would be a technical reason against it, because then you would lose the possibility of a one-liner approach. I don't know enough about nim (practically) to know if that is correct, but in this case that would be where the mandatory colon : allows for a syntax that is otherwise not possible.
It has been annoying me in python that I could not easily copy/paste in the interactive python unless the indent was right - in ruby that always worked. It is not a huge deal but a minor nuisance.
By the way, it is also perfectly valid to specifically make a design choice to enforce colon. matz enforces lots of personal preference in regards to ruby too, and when people get too eager to wish to change core aspects of the language matz disagrees with, he tells them to create their own programming language. So if matz can do so, and I assume guido would be able to do so as well, Araq sure enough can do so as well. I find that perfectly acceptable - the only part I will disagree with is by attempting to decide for others where their own personal preferences live. ;-)
but most kids are using only lower case without any punctuation...
They do so, easing their writing, until they notice others don't like read that, and then they learn punctuation and capitals...
@Idlework that is a pretty lame argument translated into "This discussion that I have invested in, I now declare silly; so lets all take my point of view." Ofcourse most will read just fine with out without colons, but we are not talking about possible vs impossible here are we.
Colons may not be a functional property of the language but it sure affects how we perceive it. Why do some perfer CS instead of JS, Python instead of Java. I doubt functionality is the big driver. And since Nim seems to be a language striving for low cognical overhead I actually find this discussion rather relevant.
Me coding mostly in JS, C# or C(++) are used to putting tons of decoration on every line of code. But I sure feel more free and creative when I get to meddle in languages that are less weighted down and more consequent.
Hi all,
I don't mind the colon when it helps readability. What I find "confusing" here is that a colon is not necessarily mandatory everywhere. For example, you can write things like this:
without needing a colon after type or var.
Other than that, I'm really impressed by the language !
The rules for colons are largely fairly consistent - they basically appear to start a new block of statements. For example, an if-block will contain a set of statements. On the other hand, a var-block will contain a set of assignments - it can't contain a set of arbitrary statements. The colons are used for the former, but not the latter. I like this, because it distinguishes cleanly between indented sections that can contain any code, and indented sections that can only contain specific types of statement.
The only exception to this is procs, where arbitrary statements can exist, but the block-marker is actually =, which is probably a touch confusing, but then colons are also explicitly used to determine types. I guess Nim could convert to the C/Java/etc style of putting the types before the variables, in which case I guess colons are no longer needed there, but then that seems quite an extensive change to make at this point.
I think Araq's use of colons is fairly well-determined. The difference between true blocks with colons and "fake blocks" without could be considered confusing to beginners, but I would suggest that, if one is teaching Nim, having the clear distinction actually makes understanding the more fundamental rule (not all blocks are equal) easier.