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

Nim: Scripting Ease in a Compiled Language

junglecoder.com

Post reply on HN
Print view View original

71–80 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#71

Post by alpaca128 »

ac29 wrote: post #61
bobbylarrybobby wrote: post #40

Earlier quoted context omitted.

Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.

Right, and that's the point, aside from the fact those 2 are actually different in nim. I see what you are doing there, but that would have been very confusing when I started programming. Question is, should the language enforce you giving your variables a better name, or should convention? I think there are reasonable arguments for both.

But does a language with Python-like syntax really have to try to be so "beginner-friendly" that it enables inconsistent casing?

The language itself can't enforce better variable names, at least not this way - Nim doesn't stop me from using "abcd" or "a0, a1, ... a100" as variable names even though it's usually a very bad idea.

No, I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion.

Re: Nim: Scripting Ease in a Compiled Language

#72

Post by alpaca128 »

swalladge wrote: post #63
nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

This. I like many of the things that Nim is doing, but I refuse to take it seriously if it's going to make basic things like tag search and grepping difficult. inb4 a Nim linter is written to force a consistent naming style throughout a codebase.

> inb4 a Nim linter is written to force a consistent naming style throughout a codebase.

Already done:

https://github.com/FedericoCeratto/nimfmt

> Detect inconsistent variable/function naming

Re: Nim: Scripting Ease in a Compiled Language

#73

Post by eaurouge »

refaqtor wrote: post #58
haberman wrote: post #17

Is Nim stable? I have vague memories that some parts of its runtime had some deep issues that weren't yet resolved, like maybe around concurrency? I see the language is at 1.0 now, does it have a stable, solid, dependable implementation and runtime?

I don't have vague memories. I use it everyday on production code on server and embedded. I find it stable, solid, dependable.

Can I ask how you got started on embedded and on which MCU? I assume you mean bare metal.

Re: Nim: Scripting Ease in a Compiled Language

#74

Post by whateveracct »

jxy wrote: post #48

You know the language has potential when the top comments on HN are all about syntax. To generate more talking points, somebody ought to write an inverse of dumpLisp: https://nim-lang.org/docs/macros.html#dumpLisp.m%2Cuntyped

I don't think it speaks to potential - it's just Wadler's Law ;)

Re: Nim: Scripting Ease in a Compiled Language

#75

Post by freedatoms »

staticassertion wrote: post #29

How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be. Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.

I work as a Data Scientist/Machine Learning Engineer and I think that biggest issue with Nim are lacking libraries. Working as a Data Scientist is very iterative process, you spend most of the time preprocessing data. It's often try and see approach so interactive repl is a must. While I know Nim has some library to be used with Jupyter, I found it too immature. Other reason to favor Python is it's libraries - they are often written in cython which yields comparable (but of course a bit slower) performance to C. And to speed up custom code you can almost always use numba (llvm-based jit compiler that works with CPython).

Re: Nim: Scripting Ease in a Compiled Language

#76

Post by petre »

Stratoscope wrote: post #35
nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

It's not just case insensitive, it's underscore insensitive. So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name! Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world. An interesting contrast is Nim's policy on tabs and sp…

Banned tabs? Good to know. From now on I'll just ignore everything about Nim. I will also applaud the Go team's decision to include a formatter instead of such nightmare restrictions.

Re: Nim: Scripting Ease in a Compiled Language

#77

Post by TylerE »

petre wrote: post #76
Stratoscope wrote: post #35

Earlier quoted context omitted.

It's not just case insensitive, it's underscore insensitive. So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name! Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world. An interesting contrast is Nim's policy on tabs and sp…

Banned tabs? Good to know. From now on I'll just ignore everything about Nim. I will also applaud the Go team's decision to include a formatter instead of such nightmare restrictions.

nim has a formatter

Re: Nim: Scripting Ease in a Compiled Language

#78

Post by narimiran »

bobbylarrybobby wrote: post #40
ac29 wrote: post #24

Earlier quoted context omitted.

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.

> `array = Array()` ...which would break in Nim.

This is NOT true.

The first character is case-sensitive in Nim, so examples like yours are not only possible, but frequently used even in Nim compiler and standard library.

Re: Nim: Scripting Ease in a Compiled Language

#79

Post by narimiran »

CodeMage wrote: post #42
bobbylarrybobby wrote: post #40

Earlier quoted context omitted.

Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.

Another perfectly fine example: auto * logger = Logger::getLogger("main");

...which also works perfectly fine in Nim.

Re: Nim: Scripting Ease in a Compiled Language

#80

Post by narimiran »

SamReidHughes wrote: post #31
ac29 wrote: post #24

Earlier quoted context omitted.

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

In many languages, you might use one for a type name, the other for a variable. You could ban using the same identifier with different cases, instead of treating them the same.

> In many languages, you might use one for a type name, the other for a variable.

And Nim is one of those languages too. This is perfectly valid and frequently used:

    type
      Person = object
        name: string
        age: int

    let person = Person(name: "you", age: 99)

    echo person
You can try it in Nim Playground: https://play.nim-lang.org/#ix=20jS
Post reply on HN