Nim: Scripting Ease in a Compiled Language • Hacker News Board

Re: Nim: Scripting Ease in a Compiled Language

#61

Post by ac29 » Wed, Oct 30, 2019, 4:26 AM UTC

bobbylarrybobby wrote: post #40

ac29 wrote: post #24

Earlier quoted context omitted.

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.

Right, and that's the point, aside from the fact those 2 are actually different in nim. I see what you are doing there, but that would have been very confusing when I started programming.

Question is, should the language enforce you giving your variables a better name, or should convention? I think there are reasonable arguments for both.

Re: Nim: Scripting Ease in a Compiled Language

#62

Post by SamReidHughes » Wed, Oct 30, 2019, 4:29 AM UTC

Jefro118 wrote: post #14

Shameless plug - I interviewed Andreas, the creator of Nim, about his philosophy and design choices here: https://sourcesort.com/interview/andreas-rumpf-on-creating-a... Might be an interesting read for people who are thinking about using Nim and wondering how it compares to the C family, Python, Go, etc.

If you like reading stuff like this, you might love the book, The Design and Evolution of C++, by Stroustroup.

Re: Nim: Scripting Ease in a Compiled Language

#63

Post by swalladge » Wed, Oct 30, 2019, 4:39 AM UTC

nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

This. I like many of the things that Nim is doing, but I refuse to take it seriously if it's going to make basic things like tag search and grepping difficult.

inb4 a Nim linter is written to force a consistent naming style throughout a codebase.

Re: Nim: Scripting Ease in a Compiled Language

#64

Post by longemen3000 » Wed, Oct 30, 2019, 5:00 AM UTC

staticassertion wrote: post #29

How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be. Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.

there is this great discussion about the Nim Language on Julia Discourse: https://discourse.julialang.org/t/version-1-0-released-of-ni...

Re: Nim: Scripting Ease in a Compiled Language

#65

Post by 0xfffafaCrash » Wed, Oct 30, 2019, 5:00 AM UTC

nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

Disallowing these case/underscore variants from referring to differing values could be quite ok -- even a plus-- if (but only if) an additional rule is added to disallow any variations of the declaration-time casing for a variable within the same scope to prevent the need for bespoke grepping tools and discourage arbitrary variations. If that restriction was added one could argue that this improves code readability (& "listenability") by have fewer variable names available in the same scope which would sound the same but aren't.

Re: Nim: Scripting Ease in a Compiled Language

#66

Post by lazulicurio » Wed, Oct 30, 2019, 5:20 AM UTC

nine_k wrote: post #54

lazulicurio wrote: post #23

Earlier quoted context omitted.

VB.net is case-insensitive, and probably more popular than you think[1]. I think that case insensitivity actually does make sense when working with symbolic identifiers. I've seen justifications for "Foo" and "foo" being distinct symbols; personally, I find that playing with casing like that reduces my ability to read code quickly. Case insensitivity does have its downsides, but usually it's not as noticeable in VB.n…

With a tool which removes case inconsistency, it's almost like a language which is case-sensitive.

Almost, but not exactly. For example, you still can't have multiple symbols in the same scope that vary only by case. Which, personally, I'm okay with.

Re: Nim: Scripting Ease in a Compiled Language

#67

Post by emmanueloga_ » Wed, Oct 30, 2019, 5:22 AM UTC

nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

Another precedent for case weirdness :-)

https://stackoverflow.com/questions/7375537/why-is-common-li...

Re: Nim: Scripting Ease in a Compiled Language

#68

Post by mehrdadn » Wed, Oct 30, 2019, 5:45 AM UTC

ac29 wrote: post #24

nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

> Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff

They could enforce case consistency instead of case insensitivity if that's the problem they're trying to solve, though.

Although, even then, consider that variables like 'inform' and 'inForm' might not mean the same thing...

Re: Nim: Scripting Ease in a Compiled Language

#69

Post by [deleted] » Wed, Oct 30, 2019, 5:45 AM UTC

ac29 wrote: post #24

nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

[deleted]

Re: Nim: Scripting Ease in a Compiled Language

#70

Post by kazinator » Wed, Oct 30, 2019, 5:53 AM UTC

Seb-C wrote: post #49

Stratoscope wrote: post #35

Earlier quoted context omitted.

It's not just case insensitive, it's underscore insensitive. So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name! Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world. An interesting contrast is Nim's policy on tabs and sp…

Sounds like a nightmare.

Sounds like a pointless misfeature that will only generate mandatory "do not @#$$ do this" entries in future Nim coding style documents, and Nim linting programs that find and flag abuses.

The motivation is good, if the intent is to get rid of ___unwanted___crap___ like this.

But if I, as a language designer, wanted to ban such identifiers, I would just go ahead and ban them, rather than making them equivalent to ones that do not have repeated underscores.

The principle is: don't make unwanted/undesirable forms equivalent to acceptable forms in hopes that people will then just stick to the acceptable forms when they discover that the the unwanted forms don't bring about the difference they were hoping for. People won't. People will go to town with the equivalence to make problems for other people.

People who don't know about the equivalences, or have forgotten, will be tripped up. Someone might think that a variable called __foo in an inner scope is different from an outer (or global) _foo, yet their definition will shadow _foo, with some behavior-altering consequences.