I believe that what makes Python so popular is that you could learn just a very small subset of the language and be very productive with it. Then, as you gain experience, you simply become more expressive and thereby more productive. I am looking for similar feature for a compiled language. I also came from C background and it simplicity, to me, is the biggest attraction. Nim is the nearest to python for a compiled language but I somehow think it is still complex and could be made more simple. For example, the statement var x:int to me is unnecessary. Why not just x:int? I understand that you might also want something like let x = 1 or const x=1 but isn't it that 95% of the time, you want it to be var? So, why not make it var by default then, for the 5% of the time you want it a const or use let, you make an explicit declaration. Also, making it var could also handle all that const or let could handle except that it may be error prone.
Another one is, why even declare X:int? If there is a statement x=1 then, x is an int. I understand that Nim has an implied declaration and behaves this way but then again, why not make it the default? Having said that, I could understand that for objects (like C's struct) you really need to declare the variable type. We should put the burden on the compiler rather than the user and make things simpler. Thank you.
Keywords like 'var' are important, not just to help the compiler but also to help humans. Without a distinct beginning variable names can easily cause bugs when the original variable name changes. Consider the following..
var x = 123 # this works, btw
# ..lots of code...
when condition:
x = 555
# ..lots of code...
doSomethingImportant(x)
.. now let's pretend that some other programmer comes along and decides 'x' isn't clear enough and changes the name to 'delta', but he didn't look through all the "lots of code" parts and missed the x = 555 line. When 'var' is required he gets a compiler error complaining about the (now undeclared) 'x' symbol on that line, but without it the program compiles and may even initially run without any obvious errors but it actually has a silent bug that could crop up in some very nasty and hard-to-trace ways later on.This makes a bit of sense in a language which is primarily for scripting or REPL use. For quick-and-dirty coding. But that's not really Nim's primary target. As filwig wrote, the var keyword is very useful to make the code clear and unambiguous for humans. Remember that code I'd not just for humans to write and machines to read. It's also for other humans to read.
I miss var all the time when writing Ruby or Julia code
npquintos: why not make it var by default then, for the 5% of the time you want it a const or use let, you make an explicit declaration.
I'd say most of the time you dont want to modify its value, and would be safer if you declare a new one containing the new assignment.
Talkig about features, i'd like to see this working http://pastebin.com/ZRGSd2Tp
This seems what I like to get stuck in as well. Every time I start taking up a new language, I say "look at this stupid thing they did, [FavoriteLanguageX] is so much better because it can do Y".
It happened when I came from Java to Python. I didn't like the lack of types, I hated that I never really "knew" what a type was going to be and the ability to pass functions around confused me. Now it's one of my favorite languages because it has those things.
When I started learning Nim, I had a few grumbles, but I understand that it's a new language and my grumbles might get fixed, or my grumbles might turn into what I love about the language. Yes, it's slightly annoying to type "var" before a variable declaration when coming from Python, but that's only 3 extra letters and you can put down a var block if you need multiple declarations. Just give it some time and you'll become accustomed to all of the pragmas, procs and vars that Nim has to offer :)
annoying to type "var" before a variable declaration
Some months ago Dennis showed a template for using := instead of var keyword, in case someone really prefers that:
But isn't it that when I say.
x: int
I am already making a declaration? So, in the first reply where delta replaced x, the error will still be caught. With C, that is perfectly fine (i.e., you don't have to say that x is a variable because the mere fact that you say "int x", you are already saying that it is a variable.) but then, maybe that is why you don't like C. I just don't see the merit of having
var x: int
instead of
x:int
Not to repeat myself but using 'const' and 'let' to me are more like special cases and should be fine to make that distinction for those special cases but in the majority of cases the intention is var. This is actually the second time I looked at Nim. The first time around, among other things, I saw the 'var' and told myself this is too verbose, that Julia got it right. However, the speed, the python-like syntax, and easy integration with C and C++ kept me coming back. Julia got those too but I believe Nim has a lot more potential.
First x: T as a variable declaration doesn't work, because it already means: "invoke procedure/template/macro x with argument T".
Example:
echo: true
Yes, true is not a type, but we can know that only after the code has been parsed and type-checked. And we can write macros and templates thatt take type arguments, too.
Second, trying to infer whether an assignment should also be treated as a declaration has always caused more problems than it has solved, in Python, Ruby, and Lua.
Third, requiring a keyword to start variable declarations makes them stand out visually. Code is read much more often than it is written, and it is far easier to identify variable declarations when there's an explicit syntactic marker for them.
There are two issues with the suggestion.
The first one, as many pointed out, is that avoiding explicit declarations creates a difficulty in scoping. It becomes harder to distinguish whether a variable is meant to shadow an existing one in a larger scope or not.
Other languages that miss explicit declarations either
The former is undesirable, because introducing a new identifier can make existing variables in smaller scopes change their meaning, thereby involuntarily introducing an action at a distance.
The latter one is undesirable because it makes more cumbersome to refer to identifiers in larger scope, thereby discouraging the use of closures, which in fact are not quite common in python. It is also harder to read (at least for me): one has always to keep in mind that x in an inner scope is not the same x in a larger scope, without any declaration to indicate a difference.
In the context of Nim, this would also introduce an asymmetry with other constructs that require a declaration.
But there is also a second objection: it is not the case that var is the most common declaration, by far! I would be more inclined to believe that 95% of the times one uses let than the other way around (it is probably somewhere in the middle).
Taking into account that most objects are never changed after their initialization, and that Nim has the mutable variable result always available for this, I use var quite sparingly. Even then, it is seldom the case that there is no default value, and that I leave it uninitialized, so var x = 1 is much more common (for me) than var x: int. So one would not even have the hint of a variable being uninitialized to decide that it can be made mutable.
But isn't it that when I say. x: int I am already making a declaration?
Ok, you want to omit var there, but what about
var x = funcThatReturnsConstant()
? Allowing the omission of var just in those cases where there is an explicit type is inconsistent, ugly, and harder to comprehend.
With C, that is perfectly fine (i.e., you don't have to say that x is a variable because the mere fact that you say "int x", you are already saying that it is a variable.)
And what about
mumble x;
? By putting the type in front and using that to indicate that it's a declaration, parsing C becomes context-sensitive. And consider type inference; in C++, you could write
auto x = 3;
which is more verbose than Nim's
var x = 3
so you should prefer Nim if that's your only criterion.
maybe that is why you don't like C.
There are many reasons not to like C, but that's not what this is about.
I just don't see the merit
Many people take their failure to understand as a virtue, but it's not.
Not to repeat myself
That's exactly what you're doing. The first time you said it, Arrrrrrrrr noted that let is more often correct than var, and that hasn't changed.
The first time around, among other things, I saw the 'var' and told myself this is too verbose, that Julia got it right.
Julia doesn't require variable declarations at all, so it's not relevant to your specific "feature request".
I like less
And in this case Nim indeed provides less. Nim is statically typed so we need a way to provide a type, hence : type part. Now nim also supports duck typing so we have to be able to ommit type while declaring and right here we get actually less. I am not sure what other consistent syntax could fit in this case.
looks to me like Pascal, which I never liked
That was my first impression too. And i too cant stand pascal/delphi. However we can look at it from the other angle. Python3 type annotations use same syntax (at least in function declarations). TypeScript also uses same syntax. And if we do something shameful like using var/let with every declaration it no longer is pascal-like.
I bet all of us find something not quite to their taste in Nim and thats ok. We are all different. However Nim is so forgiving that it lets us work-around most of things and make it fit to our taste. And that is truly awesome. Things that cant be worked around are well-worth putting up with (although im not sure what little itch of my own i could not work-around).