5 ms·
> 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
by elcritch 5y ago
> 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.
- rualca 5y ago> 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.
- IshKebab 5y ago> 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!
- stavros 5y agoI'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.
- aEverr 5y agothere 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*
- stavros 5y agoSure, but there's a standard formatter, they become a small minority.
- aEverr 5y agoand with style insensitivity they become a non-issue?
- stavros 5y agoThe compiler might not be sensitive to style, but *I* am.
- atom_arranger 5y agoI 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.
- stavros 5y agoI 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.