Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim Version 1.6.6 Released

nim-lang.org

Post reply on HN
Print view View original

61–70 of 116 posts

Re: Nim Version 1.6.6 Released

#61

Post by nimmer »

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.

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion.

Also you can use nimgrep if have to search across projects written by different people.

Re: Nim Version 1.6.6 Released

#62

Post by arc776 »

rich_sasha wrote: post #4
WithinReason wrote: post #2

There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason

It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.

> the automatic conversion from camel-case to snake-case... very much so.

If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to qualify it or rename it.

This also helps further reduce ambiguity indirectly by forcing sensible naming.

Re: Nim Version 1.6.6 Released

#63

Post by arc776 »

rich_sasha wrote: post #11
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.

If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.

> other people's code can, refer to the same thing by different names

They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to clash they also have to have exactly the same type, otherwise no worries.

You can even rename symbols on import or force qualification for all symbols, but I've never needed to do either in years of heavily using the language.

Re: Nim Version 1.6.6 Released

#64

Post by arc776 »

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.

Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it.

Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.

Re: Nim Version 1.6.6 Released

#65

Post by ezst »

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.

Scala is my go-to for cli tools these days because of that, and even more so since it has a compiler to native (via llvm)

Re: Nim Version 1.6.6 Released

#66

Post by [deleted] »

xigoi wrote: post #49
derbOac wrote: post #34

Earlier quoted context omitted.

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…

In math, most variables are a single letter, so style sensitivity wouldn't really apply.

[deleted]

Re: Nim Version 1.6.6 Released

#67

Post by peheje »

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.

Have you had a look at F#?

It has great GC piggybacking on the huge amount of efforts going into dotnet, each release since dotnet core has just gotten faster and faster, not just GC but many parts of the ecosystem, see e.g. https://devblogs.microsoft.com/dotnet/performance-improvemen...

Pattern matching is first class. See e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

I haven’t programmed with traits, but sounds like interfaces which you can have records implement. https://gist.github.com/robertpi/2964793

Function signatures are usually not needed due to the type inference algorithm, so while it is statically typed, you often don’t need to write out the types of functions.

Re: Nim Version 1.6.6 Released

#68

Post by barnabee »

eklavya wrote: post #46
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.

Absolutely, I think there is a huge opportunity here. A rust+gc lang which has seamless ffi with rust would be a killer in my opinion.

I like Rust but I’d use this for so many things!

Re: Nim Version 1.6.6 Released

#69

Post by memling »

nimmer wrote: post #59
cumshitpiss wrote: post #10

Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus

> If Nim can work with numpy it's a plus Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.

> Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.

Can you clarify this? Is there an equivalent data stack in Nim? Or is it that nim is lighter-weight because, for example, it permits transforming tabular data into language structures natively (i.e., without library support)?

Re: Nim Version 1.6.6 Released

#70

Post by nimmer »

memling wrote: post #69
nimmer wrote: post #59

Earlier quoted context omitted.

> If Nim can work with numpy it's a plus Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.

> Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster. Can you clarify this? Is there an equivalent data stack in Nim? Or is it that nim is lighter-weight because, for example, it permits transforming tabular data into language structures natively (i.e., without library support)?

The latter. For most uses of Pandas you can simply use native arrays. You can use for loops and so on.

For N-dimensional array computation: https://github.com/mratsim/Arraymancer/

Post reply on HN