Hacker News Reader

Comment by PMunch | Hacker News Reader

You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.

View on HN

I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know.

I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot".

Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.

Yeah I can see how it might seem scary. It takes you out of your comfort zone and it's easy to start thinking uncomfortable things have to be scary. I've been using Nim for a couple of years now, and I've never run into a safety issue with it.

I'm all up for new, exciting, slightly scary but promising concepts in programming. Rust's borrow checker. Python extremely-dynamic syntax. Nim's "Python syntax, native code, GC" premise.

Exploring different ways to write the same name does not excite me.

Reading through the GitHub issue, it seems like the one place it makes sense in my eyes is that you can refer to stuff in external libraries with your convention even if the library uses a different one. I'm not sure if there's something I'm not thinking of, but to me it'd make sense if the library boundary was the only place it let you do it.

This is the opposite of a footgun. Imagine if DNS was case sensitive and GMAIL.COM belonged to a domain squatter.

Nim prevents that. It's that simple.

This is an interesting take, I do see the value. If I was trying to prevent this type of aliasing, I'd have the compiler throw an error if there were two aliased variables names (xyz and XYZ for example), rather than merging them automatically.

That's what --styleCheck:error is for.

No. Nim always throws an error if you try to define multiple variables/procs that are conflicting.

--styleCheck:error strictly enforces camel case.

Since Nim is statically typed you can't simply create a new variable with the same name as an existing one without errors. You can shadow variables in a deeper scope, but then only the latest version is available. Defining a function xyz and then trying to define another function xyZ is indeed an error.

Are you confusing syntax with semantics? Your hesitance seems to come from intuition and it's not uncommon for intuition to make mistakes like that.

Having a single syntax with multiple semantic meanings would indeed be a foot gun.

I can't think of a way how different syntax translating to a single semantic meaning could cause any concern. It's not like the wrong thing can happen, it just might look differently depending on codebase.

Reply on news.ycombinator.com