News for hackers. Stuff that matters.
Re:Why I Use Nim instead of Python for Data Processing by elcritch on Saturday September 25, 2021 @03:29AM (#28651246)
> Yeah should really be "Why I don't use Python for Data Processing".

Not entirely. Nim‘s benefit here is that it’s superficially similar enough to Python that’s it’s easy for people from that world to pickup and start using Nim.

> Also I don't know how anyone could design a language in the 21st century and make basic mistakes like this: > If that's any indication of the sanity of the rest of Nim then I'd say steer well clear!

It may seem like a design mistake at first glance but it’s surprisingly useful. It’s intent is to allow a given codebase to maintain a consistent style (eg camel vs snake) even when making use of upstream libraries that use different styles. Not including the first letter avoids most of the annoyance of wantonly mixing all cap constants or lower case and linters avoid teams mismatching internal styles. Though mostly I forgot it’s there as most idiomatic Nim code sticks with camel case. I’d say not to knock it until you’ve tried it.

The rest of Nim’s design avoids many issues I consider actual blunders in a modern language such as Python’s treatment of if/else as statements rather than as expressions, and then adding things like the walrus operator etc to compensate.

Re:Why I Use Nim instead of Python for Data Processing by rualca on Saturday September 25, 2021 @05:02AM (#28651653)
> It may seem like a design mistake at first glance but it’s surprisingly useful. > It’s intent is to allow a given codebase to maintain a consistent style (eg camel vs snake) even when making use of upstream libraries that use different styles.

That doesn't sound right at all. It sounds like a design choice aimed at achieving the exact opposite: inconsistency without any positive tradeoff in return.

> Not including the first letter avoids most of the annoyance of wantonly mixing all cap constants or lower case and linters avoid teams mismatching internal styles.

That does not sound right at all. At most, it sounds like the compiler does not throw errors when stumbling on what would otherwise be syntax errors, but you still have all the mismatches in internal styles and linters complaining about code and teams wasting time with internal piss matches, and more importantly a way to foster completely futile nitpicking discussions within a language community.

Re:Why I Use Nim instead of Python for Data Processing by IshKebab on Saturday September 25, 2021 @05:46AM (#28651828)
> It’s intent is to allow a given codebase to maintain a consistent style (eg camel vs snake) even when making use of upstream libraries that use different styles.

This doesn't make sense. For an entirely new language you can just have the entire ecosystem use the same style, e.g. like Rust does. Or even Python!

Re:Why I Use Nim instead of Python for Data Processing by hexo on Saturday September 25, 2021 @07:51AM (#28652387)
It actually makes a lot of sense. I personally don't want to touch .Net langs because of their PascalCase and camelCase coding style which I find very unfortunate arbitrary decision. And well, didn't really want to get into Nim because of camelCase but since I've learned about this feature I'm reconsidering again.
Re:Why I Use Nim instead of Python for Data Processing by maleldil on Saturday September 25, 2021 @10:45AM (#28653578)
Do you really dislike camelCase that much to avoid an _entire_ ecosystem because of it?

I prefer snake_case too, but avoiding a language because of a minor convention like that seems weird.

Re:Why I Use Nim instead of Python for Data Processing by hexo on Saturday September 25, 2021 @01:17PM (#28654690)
Only language where I can stand it is Haskell. camelCase is relatively ok, but PascalCase for non-types (i.e. function names) is a big no-no :)
Re:Why I Use Nim instead of Python for Data Processing by gilrain on Saturday September 25, 2021 @11:06AM (#28653721)
When there are so many excellent languages to choose among, a trivial distinction can almost be a relief.
Re:Why I Use Nim instead of Python for Data Processing by stavros on Saturday September 25, 2021 @06:18AM (#28651951)
I'd agree, if you want a consistent style, ship a formatter with your package manager, like Rust does with `cargo fmt`. If it's there by default, it'll quickly be a standard.
Re:Why I Use Nim instead of Python for Data Processing by aEverr on Saturday September 25, 2021 @08:41AM (#28652708)
there are many packages and maintainers of such who just dont give a damn about the formatter or the style, some people just *want what they want*
Re:Why I Use Nim instead of Python for Data Processing by stavros on Saturday September 25, 2021 @08:45AM (#28652719)
Sure, but there's a standard formatter, they become a small minority.
Re:Why I Use Nim instead of Python for Data Processing by aEverr on Saturday September 25, 2021 @08:53AM (#28652780)
and with style insensitivity they become a non-issue?
Re:Why I Use Nim instead of Python for Data Processing by stavros on Saturday September 25, 2021 @09:01AM (#28652830)
The compiler might not be sensitive to style, but *I* am.
Re:Why I Use Nim instead of Python for Data Processing by atom_arranger on Saturday September 25, 2021 @10:42AM (#28653551)
I guess the best thing would be having a formatter that can switch the style for you locally. I don’t think Nim has this currently, would be neat if they did.
Re:Why I Use Nim instead of Python for Data Processing by stavros on Saturday September 25, 2021 @09:05PM (#28657501)
I don't think most people care about a specific style, as long as it's consistent. That's why I love Black, we all disagree with it equally, but each for different reasons.