Hacker News Reader

Comment by ryukoposting | Hacker News Reader

> That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces)

I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent.

It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code.

I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.

View on HN

Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that.

> It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code.

I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.

To some extent, Nim has a valid excuse because Whitespace is syntax. Forcing spaces should (ostensibly) make parsing more reliable, and users are less likely to have weird problems caused by their editors. Regardless, it's a negligible problem in my eyes.

> I assume you're talking about the partial case insensitivity of Nim?

That's one part of it, yes. I include UFCS in that as well.

Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.

I'll admit that it's much easier in languages that are not whitespace sensitive but imho it's not an unsolvable problem for the ones that are and software from 50 years ago not handling things correctly is not an argument if you ask me. I know it bothers me more than it probably should and likely more than the average person but at the end of the day such things have an influence on people. Everyone has some things they just prefer and imo forcing everyone to use one specific style is always a worse solution than using tools like code formatters and letting people have their way.

> That's one part of it, yes. I include UFCS in that as well.

Oh yeah, UFCS is pretty nice. Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions, I'd very much like to see if I'm calling a function or not. Sure for things like the size of an array it doesn't really matter but the call could be expensive. This is mostly for reading code though, obviously in my own code I'd never drop them.

> Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.

I'd argue that it's still weird because the first letter is still case sensitive and I"m coming from a case sensitive language but being able to use foreign code in your own style is very appealing. I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway, the closest example I can think of would be T and t for temperature and time but you can also just type those words out, more expressive anyway.

> Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions

That isn't true, you need parentheses for procs with no arguments, else it's interpreted as a proc pointer. Try `echo` vs `echo()`.

> I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway

It's used for declaring variables of an object. `type Foo = object` and `var foo: Foo`.

I like Nim's rules for identifiers, it prevents you for mistakenly declaring two different variables/procedures with similar names.

Other examples where, how you would write something doesn't matter, is Windows filesystems and gmail, reserving every possible derivative with a dot like your.name@gmail.com and y.ourname@gmail.com.

So it's not uncommon or weird. Just programming languages are overly restrictive.

> That isn't true, you need parentheses for procs with no arguments, else it's interpreted as a proc pointer. Try `echo` vs `echo()`.

My bad, I meant 0 argument member functions (or rather 0 additional argument functions, apart from the this pointer). So `foo: Foo` and then `i = foo.len()` directly shows me that I'm calling a function, `i = foo.len` looks like I just access a member variable. len is obviously not the best example but I still don't think hiding the fact that a function is being called is a good idea at all.

> It's used for declaring variables of an object. `type Foo = object` and `var foo: Foo`.

Good point, I didn't consider that. So far never came up in my code but I can see that it sometimes can be useful to do something like that.

> So it's not uncommon or weird. Just programming languages are overly restrictive.

Natural languages have been case sensitive long before programming languages existed. Again, I'm not saying it's a bad feature - on the contrary, definitely appealing in some case - it's just not what we're used to and hence a bit "weird".

Reply on news.ycombinator.com