Nim: Scripting Ease in a Compiled Language

Post by beagle3 » Wed, Oct 30, 2019, 11:01 PM UTC

gjm11 wrote: post #102

mehrdadn wrote: post #68

Earlier quoted context omitted.

> 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...

Oh, but that's OK. You can just have inform and in_form. Except you can't because Nim also ignores underscores in identifiers. Gotta make sure there is literally no way to disambiguate cases like this! (I _want_ to like Nim but this single decision seems to me so spectacularly bad that it's a non-starter.)

Post by jolmg » Wed, Oct 30, 2019, 11:19 PM UTC

beagle3 wrote: post #151

jolmg wrote: post #45

Earlier quoted context omitted.

> As an aside, is there some reason that using the same identifier with different cases is desirable? It's not like that. The thing is that having case insensitive identifiers incentivices people to be inconsistent with their casing "because it doesn't matter" as one coworker that works in a case insensitive language said to me. "Whoops, I wrote 'vALUE'. Well, it doesn't matter; it works. :)" Thank god I don't have t…

... It's like using curly braces to delimit scope incentivizes people to be inconsistent with indentation because "it doesn't matter". Yes, there are always people who would do stupid stuff. But we have decades of experience with Pascal, SQL, VB, VB.Net, Excel and variety of other languages. Decades. They each have their problems, but in wide practice, case [in]sensitivity is not one of them.

Post by swalladge » Thu, Oct 31, 2019, 2:20 AM UTC

alpaca128 wrote: post #72

swalladge wrote: post #63

Earlier quoted context omitted.

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.

> inb4 a Nim linter is written to force a consistent naming style throughout a codebase. Already done: https://github.com/FedericoCeratto/nimfmt > Detect inconsistent variable/function naming

Post by jolmg » Thu, Oct 31, 2019, 4:09 PM UTC

beagle3 wrote: post #157

jolmg wrote: post #154

Earlier quoted context omitted.

Yet inconsistent indentation is a problem in wide practice. It doesn't take long to find popular open source projects that mix tabs and spaces in their indentation. Of course, many people are going to be consistent with their casing even when using a case insensitive language, but it's nice to know that particular forms of bad style are never going to be an issue because particular rules of good style are enforced by…

Inconsistent indentation is NOT a problem in practice. inconsistent tab/space use is a problem in practice (not a "wide" one in my experience, but not negligible), but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too. I've never heard of someone saying "I don't care about mixing spaces and tabs…

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s*( \t|\t )' $p/^.git | head -1
  done | wc -l

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s* \t' $p/^.git | head -1      
  done | wc -l

  for p in ~/build/{pkg,repo}/*; do
    ag -lr '^ .*\n\t|^\t.*\n |^\s* \t' $p/^.git | head -1 
  done | wc -l                       

Post by kazinator » Thu, Oct 31, 2019, 8:10 PM UTC

beagle3 wrote: post #146

kazinator wrote: post #70

Earlier quoted context omitted.

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 one…

It's possible to argue about this endlessly from a theoretical perspective, but Nim is not a new language, there are substantial code bases (not as substantial as C, Java or Python, of course, but still substantial), and these rules have been worked out through real world cases, and are very effective in practice. From a theoretical perspective, your argument can equally be applied to C's case sensitivity or Pascal's…