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

101–110 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#101

Post by narimiran »

enriquto wrote: post #90
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…

> As an aside, is there some reason that using the same identifier with different cases is desirable? I do it all the time, in numerical code. If you have two pairs of points, for example, it is very natural to name them "a,A,b,B"

> for example, it is very natural to name them "a,A,b,B"

And just to clarify once again, since I'm not sure who will read which reply: those are NOT the same identifiers in Nim!

    let
      a = 11
      b = 22
      A = 99
      B = 88

    echo a == A # false
    echo b == B # false
Run the code in the Nim Playground if you don't believe: https://play.nim-lang.org/#ix=20kr

Re: Nim: Scripting Ease in a Compiled Language

#102

Post by gjm11 »

mehrdadn wrote: post #68
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…

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

Re: Nim: Scripting Ease in a Compiled Language

#103

Post by galangalalgol »

thanatropism wrote: post #37
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.

Re: speed, I'm seeing the Rust ecosystem get better and better; I'm also learning the language on the weekends with small projects. But also: many many moons ago I had Matlab code that was really slow (and I wanted to run 10^LARGENUM simulations for Monte Carlo purposes) and decided to learn Fortran. It was surprisingly easy to learn, and it did cut my running time from afternoons to minutes. But in the process I fou…

Matlab usually flags cases like that in the editor suggesting you reserve space outside a loop.

My experience with numpy was that it was 11x slower than visual basic access in excel. I was deali g with a lot of small matricies instead of a big one and I think that contributed.

I want to try julia in production. About to try out rust in production.

Re: Nim: Scripting Ease in a Compiled Language

#104

Post by PMunch »

Stratoscope wrote: post #46
kungtotte wrote: post #44

Earlier quoted context omitted.

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.

Again just for correctness your last identifier isn't legal in Nim. You aren't allowed to start an identifier with an underscore, and you can't have two underscores together.

Re: Nim: Scripting Ease in a Compiled Language

#105

Post by mehrdadn »

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

Sounds like you're agreeing with me?

Re: Nim: Scripting Ease in a Compiled Language

#106

Post by enriquto »

narimiran wrote: post #101
enriquto wrote: post #90

Earlier quoted context omitted.

> As an aside, is there some reason that using the same identifier with different cases is desirable? I do it all the time, in numerical code. If you have two pairs of points, for example, it is very natural to name them "a,A,b,B"

> for example, it is very natural to name them "a,A,b,B" And just to clarify once again, since I'm not sure who will read which reply: those are NOT the same identifiers in Nim! let a = 11 b = 22 A = 99 B = 88 echo a == A # false echo b == B # false Run the code in the Nim Playground if you don't believe: https://play.nim-lang.org/#ix=20kr

great!

then I don't really understand nim's case insensitivity rules

Re: Nim: Scripting Ease in a Compiled Language

#107

Post by PMunch »

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…

I thought this feature was a bit odd once I first started using Nim. But by now I'm a huge fan, and I'll explain why. But first I'll just say that yes, it is slightly harder to search for identifiers. But libraries will stick to either snake_case or camelCase for their identifiers, so as long as you know which one it is it's not that big of a deal. The benefit of this style insensitivity though is really nice. I programmed in Python and C for many years before trying out Nim. And in both languages I've run into libraries that does the opposite of what the style guide recommends. Some people just prefer one style over another and will do their libraries in their preferred style. The problem is that this meant that my code ended up as a hodge-podge of the different styles. This was definitely more prevalent with Python code, but I've run into it with C as well, especially with micro-controller programming. With style-insensitivity however this is a complete none issue. You can write your code in whatever style you prefer, and not care about what dubious stylistic choices the library maintainer sticks to. To me this far outweighs the small inconvenience that it brings (especially if you take into account editor tools).

I feel most people who read about style insensitivity imagines all Nim code being written as a crazy mix of styles, while in reality Nim code is often more consistent in style.

And the tabs vs. spaces issue is simply to alleviate the issues with "how many spaces are a tab" which is impossible to guess when compiling code. The replace filter you mention above essentially just explicitly specifies how many spaces you intend a tab to be. That being said I would've liked it better if it forced tabs, that way you'd have one tab for one indentation level, and everyone could choose their own preference of indentation.

Re: Nim: Scripting Ease in a Compiled Language

#108

Post by treeform »

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

Main reason for this feature is that Nim is big as a glue language. Many C/C++ libraries don't have consistent naming conventions between them. I don't want my code to look like a patch work of `__APICALL__(system_call.inspectSomething())` I just want it to look like Nim code: `apiCall(systemCall.inspectSomething())`. This is just a consistent standard on how to turn names in one style into another style backed into a language.

Re: Nim: Scripting Ease in a Compiled Language

#109

Post by gameswithgo »

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 used it a about three years back for a few sideprojects. i ran into two or three bugs, but i saw those get fixed in the months after my work. im hopefull that biw at 1.0 things are pretty stable. it was mostly a joy to use. meta programming did generate hard to diagnose errors at the time.

Re: Nim: Scripting Ease in a Compiled Language

#110

Post by PMunch »

jimws wrote: post #53
jxy wrote: post #48

You know the language has potential when the top comments on HN are all about syntax. To generate more talking points, somebody ought to write an inverse of dumpLisp: https://nim-lang.org/docs/macros.html#dumpLisp.m%2Cuntyped

I am confused if you this is an honest opinion or if you are saying with a touch of sarcasm. If it is the latter, a winking smiley or " " or "/s" would have been nice to avoid triggering Poe's Law. In my honest opinion, discussion on syntax is a distraction. One of the reasons I like Lisp/Clojure is that there is very little syntax. I can just focus on my problem and writing good code.

I think he meant that if the worst thing people can say about a language is that it has slightly quirky syntax it must've done a lot of things right.
Post reply on HN