Nim Version 1.6.6 Released

Post by def- » Thu, May 05, 2022, 2:19 PM UTC

Symmetry wrote: post #40

nimmer wrote: post #31

Earlier quoted context omitted.

This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.

If you define them both yes, but you're still free to use them both. var my_var = 1 myVar += 1 echo(my_var) Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.

  nim --styleCheck:error c x

  x.nim(1, 5) Error: 'my_var' should be: 'myVar'

Post by TheEzEzz » Thu, May 05, 2022, 2:29 PM UTC

nimmer wrote: post #37

rich_sasha wrote: post #21

Earlier quoted context omitted.

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.

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.

Post by rkallos » Thu, May 05, 2022, 2:31 PM UTC

rosetremiere wrote: post #38

A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.

Post by travv0 » Thu, May 05, 2022, 2:33 PM UTC

rich_sasha wrote: post #29

PMunch wrote: post #24

Earlier quoted context omitted.

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.

Post by xigoi » Thu, May 05, 2022, 2:39 PM UTC

derbOac wrote: post #34

nimmer wrote: post #6

Earlier quoted context omitted.

Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.

I love Nim and wish it would take off and become as common as python. Case sensitivity isn't affecting that for me. But it still really irks me. There are times when you might want to use the same variables in different cases (math), and the assumption that you wouldn't seems like nannying to me. Also, fundamentally, it's a very english-centric view and encourages that by default. I'd prefer case assumptions weren't…