Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 0.13.0 has been released

nim-lang.org

Post reply on HN
Print view View original

21–30 of 80 posts

Re: Nim 0.13.0 has been released

#21

Post by scardine »

lmm wrote: post #19
scardine wrote: post #11

Earlier quoted context omitted.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance.

Personally I believe code is harder to read than to write, so I favor languages that are easier to read.

Re: Nim 0.13.0 has been released

#22

Post by JadeNB »

lmm wrote: post #19
scardine wrote: post #11

Earlier quoted context omitted.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

> Case sensitivity makes life harder for beginners

I think that I disagree. In general (not all the time, but often), things that look different should be different; allowing them to be treated the same is offering beginners a short-time advantage, while preventing them from making, or even understanding, distinctions that they may want to make in the long term. Imagine, for example, a car where both pedals behave the same, and where the actual function is determined by smart traffic-analysis sensors in the car. It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.

> would you really want to have two different variables called VariableName and variable_name in scope?

Yes, sometimes! (Not that particular example, but there have definitely been cases when I have wanted variables with the same letters in their names but different capitalisations.)

Re: Nim 0.13.0 has been released

#23

Post by lmm »

scardine wrote: post #21
lmm wrote: post #19

Earlier quoted context omitted.

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance. Personally I believe code is harder to read than to write, so I favor languages that are easier to read.

If such a convention applied consistently that would be great. But my Python experience is that it isn't, and an inconsistent convention is worse than useless. If such a distinction is to be meaningful then IMO the language itself needs to enforce it.

Re: Nim 0.13.0 has been released

#24

Post by KirinDave »

jksmith wrote: post #14
KirinDave wrote: post #9

Nim's approach to parallelism is, for the general industry, basically groundbreaking and inspiring work. I really wish that this language got more attention. It can fill many of the same holes that Go fills without all the awkward dependency non-management and bad error handling. Similar story for Rust, it's got a lot of similar benefits without an ownership and extent model many people find confusing.

Groundbreaking? How so?

While it's not amazing in academia, seeing static analysis of correctness for concurrent and parallel code is unusual outside of things like Haskell language extensions.

Check out what they're doing. It's quite unusual to see.

Re: Nim 0.13.0 has been released

#25

Post by scardine »

keypusher wrote: post #17
scardine wrote: post #11

Earlier quoted context omitted.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

I brought it up recently in the #nim irc channel, trying to get a good explanation. The creator still seemed to think it was a good idea, and I could not convince him otherwise.

Yeah, I feel your pain. This is a deal breaker for me.

My OS of choice for the last 25 years has a case sensitive filesystem, all the programming languages I learned (well, except PHP) are case sensitive, it is too hard to unlearn.

BTW, PHP has weird case sensitivity rules. Case sensitive (both user defined and PHP defined):

  * variables
  * constants
  * array keys
  * class properties
  * class constants
Case insensitive (both user defined and PHP defined)

  * functions
  * class constructors
  * class methods
  * keywords and constructs (if, else, null, foreach, echo etc.)

Re: Nim 0.13.0 has been released

#26

Post by phaylon »

keypusher wrote: post #17
scardine wrote: post #11

Earlier quoted context omitted.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

I brought it up recently in the #nim irc channel, trying to get a good explanation. The creator still seemed to think it was a good idea, and I could not convince him otherwise.

Is there a way to enforce a particular style across a project? From what I've read the abiliity for projects to be internally consistent, even with third party library usage, seems to be one of the big advantages of this design-wise. So if you had an optional setting somewhere that enforces it, it might help communicate the intention of the feature.

Re: Nim 0.13.0 has been released

#27

Post by lmm »

JadeNB wrote: post #22
lmm wrote: post #19

Earlier quoted context omitted.

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

> Case sensitivity makes life harder for beginners I think that I disagree. In general (not all the time, but often), things that look different should be different; allowing them to be treated the same is offering beginners a short-time advantage, while preventing them from making, or even understanding, distinctions that they may want to make in the long term. Imagine, for example, a car where both pedals behave th…

> In general (not all the time, but often), things that look different should be different

Case-sensitivity is the opposite though: it's making two things that look the same be different. I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.

> It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.

I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.

Re: Nim 0.13.0 has been released

#28

Post by scardine »

lmm wrote: post #23
scardine wrote: post #21

Earlier quoted context omitted.

In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance. Personally I believe code is harder to read than to write, so I favor languages that are easier to read.

If such a convention applied consistently that would be great. But my Python experience is that it isn't, and an inconsistent convention is worse than useless. If such a distinction is to be meaningful then IMO the language itself needs to enforce it.

I agree, it should be mandatory - one of the things I like about Nim is static typing.

Oddly enough, the "we are all consenting adults" attitude works in Python. Most patterns and interfaces are by convention instead of being enforced.

People don't abuse Pythons permissive nature very often, and when they do they are frowned upon by the community. I think such deviations are easier to spot in Python compared to other languages, don't really know why.

Re: Nim 0.13.0 has been released

#29

Post by pklausler »

PeCaN wrote: post #15
klibertp wrote: post #6

Earlier quoted context omitted.

In Lisps, this: (- 1) and this: (-1) Are completely different things (the latter is actually an error). Also in LiveScript ls> (- 2) [Function] ls> (-2) -2 Also in Smalltalk, this: -3. "=> -1" - 3. "=> Error!!!" That's off the top of my head, I'm sure there are many other languages with this characteristic. Why would that be a problem? It's just a single (or a couple) parse rules to remember (but you get other benefi…

Perhaps most notably, Haskell has the same behavior as LiveScript. EDIT: Derp, that's not true. (- 2) == (-2)

To be clear: (- 2) is not a section in Haskell, it's effectively a numeric literal because '-' is Haskell's only prefix operator. Haskell has a 'subtract' function that's defined in its Prelude that is used where a section for (-) would be useful.

It's a minor wart, and probably never going to be fixed.

EDIT: clarified

Re: Nim 0.13.0 has been released

#30

Post by wtetzner »

lmm wrote: post #27
JadeNB wrote: post #22

Earlier quoted context omitted.

> Case sensitivity makes life harder for beginners I think that I disagree. In general (not all the time, but often), things that look different should be different; allowing them to be treated the same is offering beginners a short-time advantage, while preventing them from making, or even understanding, distinctions that they may want to make in the long term. Imagine, for example, a car where both pedals behave th…

> In general (not all the time, but often), things that look different should be different Case-sensitivity is the opposite though: it's making two things that look the same be different. I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO. > It w…

> Case-sensitivity is the opposite though: it's making two things that look the same be different.

No it isn't. fooBar and foo_bar have the same words in them, but they look very different.

Post reply on HN