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

Nim: Scripting Ease in a Compiled Language

junglecoder.com

Post reply on HN
Print view View original

41–50 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#41

Post by m45t3r »

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…

> As an aside, is there some reason that using the same identifier with different cases is desirable?

It is mostly for conventions, however different cases are generally used to represent different things. For example, in Python:

- ALL_CAPS: global variables

- PascalCase: for classes, and now that Python has typing annotations, types

- snake_case: everything else, from variables to function/method names

(This is not a rule, Python allows anything anywhere, so it is just a convention).

So for example, in Nim you couldn't have PERSON (global variable) and Person (class), however you could still have Person (class definition) and person (class instance). Of course, applying the code style from a language to another language is silly, however it is just to illustrate the value of case sensitive identifiers (if you think that my example is more or less valuable than having the flexibility of using a external library the way you want this is your choice).

BTW, nowadays I am studying Golang and I found it annoying that you capitalization is meaningful in Go, so person() is a private function however Person() is public. It is generally not bad, however sometimes I want to create a global private constant and can't simple call it MY_CONSTANT since this would make it public.

Re: Nim: Scripting Ease in a Compiled Language

#42

Post by CodeMage »

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.

Another perfectly fine example:

  auto * logger = Logger::getLogger("main");

Re: Nim: Scripting Ease in a Compiled Language

#43

Post by SamReidHughes »

blueprint wrote: post #39
SamReidHughes wrote: post #31

Earlier quoted context omitted.

In many languages, you might use one for a type name, the other for a variable. You could ban using the same identifier with different cases, instead of treating them the same.

On the other hand, what if it's a code UI limitation? Suppose the UI for writing Nim had support for linking, editing, viewing all such alternately spelled but equivalent symbols?

There are tools that aren't nim-specific, like ack/grep/sed/git, and code review tools, which suffer as a result.

Re: Nim: Scripting Ease in a Compiled Language

#44

Post by kungtotte »

Stratoscope wrote: post #35
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...

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…

Nim is actually case sensitive on the first character only, so your list of identifiers are not all equivalent. Just thought I'd point that out for correctness sake.

Re: Nim: Scripting Ease in a Compiled Language

#45

Post by jolmg »

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…

> 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 to touch that codebase. I do wonder on average how many different variations of casing is used for each variable and keyword.

Re: Nim: Scripting Ease in a Compiled Language

#46

Post by Stratoscope »

kungtotte wrote: post #44
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…

Nim is actually case sensitive on the first character only, so your list of identifiers are not all equivalent. Just thought I'd point that out for correctness sake.

Oh, thank you for the correction, and sorry for the misinformation!

In any case (pun intended?) it's the underscore insensitivity that makes it difficult to use standard search tools.

Re: Nim: Scripting Ease in a Compiled Language

#47

Post by pastage »

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.

The options in python to speed up your code are vast without really having to do much, on a fundamental level. My outdated experience with Nimrod told me that it was a tad too opinionated E.g. Everything is a string in dbs is mentioned in the article.

It was an interesting language, for me it felt like a stepping stone to something better. But the docs were really bad,

Re: Nim: Scripting Ease in a Compiled Language

#49

Post by Seb-C »

Stratoscope wrote: post #35
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...

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.

Re: Nim: Scripting Ease in a Compiled Language

#50

Post by refaqtor »

dglass wrote: post #3

Is there anyone using Nim either in side projects or in production that can comment on how they like it? I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.

I'm using Nim in production since .18 with zero issues. I spent many years in Qt/C++ and was reasonably quick, but not as quick as I was with D. But then, in an evening, from a cold start, using nothing more than the two Nim Tutorial pages that I happened to have cached in my browser (I was away from a network connection) I was able to redesign and reimplement the bulk of my application in Nim that had taken me one week in D and two in C++. Qt/C++ was great to go from desktop to server to android/iphone. Qt is a bit of a burden on embedded, and D didn't cross-compile easily as Nim. I like banging out standalone executables starting from a two line "script" and evolving up to a complex server. I like Python, but find datatype or whitespace issues that crop up only in runtime intolerable. Compiled Nim won't allow that in the first place - and is very helpful with error messages. I'm also infuriated by getting a "cross-platform" Python script that won't run on my machine because I haven't configured and installed all the dependencies that were on the original developer's machine! Anyway, I'd say pick a small app and have a go. After that, you won't want to waste the mental capacity to use anything else. For knocking out commandline apps, I recommend "cligen" for quick and clean options, or "docopt" for friendlier cli options.
Post reply on HN