3 ms·

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 p

by PMunch 4y ago

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.

rich_sasha 4y ago
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.
- PMunch 4y ago
  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.
  - rich_sasha 4y ago
    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.
    - travv0 4y ago
      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.
- nimmer 4y ago
  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.
  - TheEzEzz 4y ago
    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.
    - xigoi 4y ago
      That's what --styleCheck:error is for.
      - nimmer 4y ago
        No. Nim always throws an error if you try to define multiple variables/procs that are conflicting. --styleCheck:error strictly enforces camel case.
    - PMunch 4y ago
      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.
- dinHeld 4y ago
  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.

by PMunch 4y ago

rich_sasha 4y ago

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.

PMunch 4y ago
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.
- rich_sasha 4y ago
  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.
  - travv0 4y ago
    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.
nimmer 4y ago
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.
- TheEzEzz 4y ago
  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.
  - xigoi 4y ago
    That's what --styleCheck:error is for.
    - nimmer 4y ago
      No. Nim always throws an error if you try to define multiple variables/procs that are conflicting. --styleCheck:error strictly enforces camel case.
  - PMunch 4y ago
    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.
dinHeld 4y ago
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.