News for hackers. Stuff that matters.
Re:Nim Version 1.6.6 Released by rich_sasha on Thursday May 05, 2022 @09:04AM (#31272787)
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.

Re:Nim Version 1.6.6 Released by nimmer on Thursday May 05, 2022 @09:31AM (#31273074)
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.

Re:Nim Version 1.6.6 Released by TheEzEzz on Thursday May 05, 2022 @10:29AM (#31273798)
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.
Re:Nim Version 1.6.6 Released by PMunch on Friday May 06, 2022 @03:47AM (#31282494)
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.
Re:Nim Version 1.6.6 Released by xigoi on Thursday May 05, 2022 @10:37AM (#31273912)
That's what --styleCheck:error is for.
Re:Nim Version 1.6.6 Released by nimmer on Thursday May 05, 2022 @12:58PM (#31275816)
No. Nim always throws an error if you try to define multiple variables/procs that are conflicting.

--styleCheck:error strictly enforces camel case.

Re:Nim Version 1.6.6 Released by dinHeld on Thursday May 05, 2022 @11:27AM (#31274578)
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.

Re:Nim Version 1.6.6 Released by PMunch on Thursday May 05, 2022 @09:08AM (#31272819)
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.
Re:Nim Version 1.6.6 Released by rich_sasha on Thursday May 05, 2022 @09:16AM (#31272897)
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.

Re:Nim Version 1.6.6 Released by travv0 on Thursday May 05, 2022 @10:33AM (#31273867)
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.