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

141–150 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#141

Post by refaqtor »

galangalalgol wrote: post #100
refaqtor wrote: post #52

Earlier quoted context omitted.

ditto! docker and kubernetes are solutions to problems that shouldn't be there in the first place!

What problems does it solve? It seems like a convoluted way for distributing shared libraries and support applications with the primary application. Couldn't i just put them all ina folder wih a script to se paths?

I've quit using Python, unless forced, because I've gotten too many folders of files that "work on my(the original developer's) machine," but fail on mine because I didn't find or follow a README that said "just" install all the same dependencies and versions.

Re: Nim: Scripting Ease in a Compiled Language

#142

Post by beagle3 »

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…

Tabs are fine and spaces are fine, but mixing tabs and spaces for indentation is a recipe for disaster, because different environments and tools have a different tab width setting -- as a result, "printing a file and OCRing it" (which people do, e.g. when typing code shown somewhere else) can result in legal but semantically very different programs looking the same. That's why you shouldn't use tabs on code that is ever edited/viewed by more than one person[0], and why you should always use python with -tt mode.

Nim takes a practical approach by banning tabs altogether; The "#?" hack you suggest just shows another great Nim feature - source code filters are standardized; You don't need a preprocessor/lex/yacc/re2c/swig with its own driver/makefile; it's all well documented and tracked within your Nim environment.

[0] especially in languages in which indentation changes program semantics, but even in e.g. C - where mismatch between indentation and curly brackets can let a bug like "goto fail;" hide in plain sight.

Re: Nim: Scripting Ease in a Compiled Language

#143

Post by refaqtor »

jyapayne wrote: post #132
refaqtor wrote: post #50

Earlier quoted context omitted.

I'm using Nim in production since .18 with zero issues. I spent many years in Qt/C++ and was reasonably quick, but not as quick as I was with D. But then, in an evening, from a cold start, using nothing more than the two Nim Tutorial pages that I happened to have cached in my browser (I was away from a network connection) I was able to redesign and reimplement the bulk of my application in Nim that had taken me one w…

I'm curious, what do you use as an alternative to Qt for Nim?

Well, if you're talking GUI stuff, nothing in Nim compares to Qt. But, I did routinely use Qt for console, server, and headless embedded stuff. The Qt environment compensated for lots of C++ shortcomings up to recently. I think I've seen a Nim linkage to QML (Qt's newer Javascript UI markup language). But, I've never been all that keen on it. Depends what you need in a GUI. QML worked well for me on android/ios apps. I guess I'm just old school when it comes to desktop apps, and I can bang out a Qt gui app in a hurry for the desktop. A few times, in D, I'd written all of the logic for the application in D as a console app with a command handler that worked on stdin that would generate the same Qt data model on stdout that a Qt GUI app would use to populate its model-bound tables and whatnot. Worked surprisingly well. But, to end this treatise on the state of nim gui stuff... I've had some fun with nimx, but keep trying the more native stuff. give 'em a try.

Re: Nim: Scripting Ease in a Compiled Language

#144

Post by beagle3 »

PMunch wrote: post #107
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…

I thought this feature was a bit odd once I first started using Nim. But by now I'm a huge fan, and I'll explain why. But first I'll just say that yes, it is slightly harder to search for identifiers. But libraries will stick to either snake_case or camelCase for their identifiers, so as long as you know which one it is it's not that big of a deal. The benefit of this style insensitivity though is really nice. I prog…

> I would've liked it better if it forced tabs, that way you'd have one tab for one indentation level, and everyone could choose their own preference of indentation.

The problem with this is that in many code bases, you occasionally need spaces to align code/data in different lines to make them more readable and easily inspectable, e.g. within a long parenthesized expression spanning multiple lines. In that case, indentation tabs require nontrivial gymnastics, whereas spaces are consistent.

The files should always contain spaces - because behaving as if spaces are tabs is round-trippable even when every user uses a different setting. An editor could en-tab on load, de-tab on save, and everyone is happy (though I'm not aware of any editor that does this). If the file only has tabs, the converse "de-tab on load and en-tab on save" does not give you the same alignment flexibility.

Re: Nim: Scripting Ease in a Compiled Language

#145

Post by gtrs »

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...

Nim is written in Nim and no one has run into this style insensitivity confusion despite many people contributing. If your project is smaller or fewer people and you still think this is a big issue, good luck. And if it is larger, this is the least of your concerns.

Think in reverse, is it a useful language feature to have MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_ be different? When did you need this flexibility recently? Are we really so limited at naming things appropriately?

It's fine to make a big deal about something in theory but if it really was such a dumb idea it would have died over the decade Nim has been around. It was debated again prior to 1.0 and persisted, several good reasons are also mentioned in this thread. And it isn't even an original idea as brought up by several others.

If this is the reason someone doesn't try Nim then it's only unfortunate for them. Add this to the tabs vs. spaces, curlies vs. whitespace indentation or other so called concerns which make no difference in the grand scheme of things.

Re: Nim: Scripting Ease in a Compiled Language

#146

Post by beagle3 »

kazinator wrote: post #70
Seb-C wrote: post #49

Earlier quoted context omitted.

Sounds like a nightmare.

Sounds like a pointless misfeature that will only generate mandatory "do not @#$$ do this" entries in future Nim coding style documents, and Nim linting programs that find and flag abuses. The motivation is good, if the intent is to get rid of ___unwanted___crap___ like this. But if I, as a language designer, wanted to ban such identifiers, I would just go ahead and ban them, rather than making them equivalent to one…

It's possible to argue about this endlessly from a theoretical perspective, but Nim is not a new language, there are substantial code bases (not as substantial as C, Java or Python, of course, but still substantial), and these rules have been worked out through real world cases, and are very effective in practice.

From a theoretical perspective, your argument can equally be applied to C's case sensitivity or Pascal's case insensitivity when someone "doesn't know" or "forgets" about the equivalece - isn't it absurd that FOO and foo are different (C) / equivalent (Pascal) when you are coming from the other one? Similarly, Lisp-1 vs. Lisp-2 . In practice, it's just one more convention -- among several others.

The motivation is not to get rid of __unwanted___crap___ (nim bans multiple sequential underscores and leading underscores, so they are rid of), but rather: Nim arguably has the best built-in FFI of any modern language with nontrivial use, and this FFI has been a factor in the language design. Nim's rules allow you to keep a mostly uniform coding style in _your_ parts, yet integrate it naturally into projects using snake_case, CamelCase, javaCase and ALLCAPSCASE and SHOUTING_MATCH_CASE, or all of the above in the same project.

Nim started out case-insensitive (which is less popular, but definitely common choice made e.g. by Pascal, Excel and others). IIRC, the "first letter's case does matter" is a relatively recent addition (as in, 2 years out of the project's 9) to simplify FFI to conventions like OpenGL, which have the same identifier in both lower or upper case.

In theory, everything could go wrong. In practice, Nim gets it exceptionally right.

Re: Nim: Scripting Ease in a Compiled Language

#147

Post by beagle3 »

wycy wrote: post #92
jdc wrote: post #84

Earlier quoted context omitted.

It's a misfeature, but let's not to be melodramatic.. just use a formatter.

It's a pretty bad misfeature though, since it's a feature you might accidentally use without realizing it if you don't use a linter.

I disagree with this claim.

You shouldn't modify code in a programming language you don't have sufficient familiarity with - at least not code that you depend on.

C has shortcut boolean ops, so "if (have_peace_treaty || launch_missiles() == LM_SUCCESS) cross_border()" would not launch missiles if you have a peace treaty.

C++ has shortcut boolean ops as well... unless you have overloaded "operator&&". So the same line in C++, depending on the types involved, might not short-circuit and start a war even if you have a peace treaty.

In Pascal and Python 3, evaluating 1/(1/2) gives 2. In python 2 and C, you get an integer overflow (with differing semantics). But 1.0/(1.0/2) gives 2 in all cases, even though 1==1.0 is true in all languages mentioned.

And "if (0.3*3 == 0.9) all_is_well(); else apocalypse_go_to_bunker()" might also surprise you if you are not aware of how FP math is implemented (in APL/K/J, all_is_well(), but not in any other language I'm familiar with).

The only example I can think of that could bite you is when shadowing an outer scope -- which is just as much a problem in C, Python etc. Some compilers warn about it, some don't, I don't know if Nim does.

In practice, Nim choices put it in an amazingly sweet spot.

Re: Nim: Scripting Ease in a Compiled Language

#148

Post by beagle3 »

pjbk wrote: post #131
nimmer wrote: post #114

Earlier quoted context omitted.

It's shocking how people whine about case insensitivity without bothering to try using Nim for a while. Case insensitivity is a feature and it's meant to allow easy interfacing with C. And it also encourages clean code. With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability. I…

Some of us work in regulated industries where coding standards are not strong suggestions but unconditional requirements. Unambiguous names and identifiers precludes the use of Nim as a tool in any of those fields just by an improper design decision. Sounds very bad and completely avoidable to me. There is a reason old languages were many times case insensitive but not anymore.

Do they preclude using e.g. NTFS (case preserving but insensitive) in your project for that reason? NTFS vs. ext4 has exactly the same kind of issues (and it has in fact caused security issues in cross-platform software.

Regardless, this does not preclude the use of Nim any more than a regulation saying "do not use preprocessor macros" preclude C because you might accidentally use #define. It just means you have to verify that you adhere to those regulations. Here's one tool[0] you can use to make sure your unconditional requirements are satisfied.

Nim would probably be precluded anyway based on age and popularity, and rightly so for tightly regulated industries -- but given some time, assuming it does grow in popularity, there is no inherent reason Nim would be precluded from any project that allows e.g. C++, Java, JavaScript or Go.

[0] https://github.com/FedericoCeratto/nimfmt

Re: Nim: Scripting Ease in a Compiled Language

#149

Post by gtrs »

andybak wrote: post #85
lone_haxx0r wrote: post #27

Nim's syntax is everything I hate in a language. It's not bad, objectively speaking, but its design opinions are the polar opposite of mine.

I'm half and half. I adore syntactic whitespace and it makes me sad that it hasn't become more prevalent. However the flexible identifier rules bother me no end. But as soon as my editor of choice handles it transparently then I guess I might come round.

> flexible identifier rule

When / how has this actually impacted you?

Re: Nim: Scripting Ease in a Compiled Language

#150

Post by beagle3 »

fluffything wrote: post #128
nimmer wrote: post #114

Earlier quoted context omitted.

It's shocking how people whine about case insensitivity without bothering to try using Nim for a while. Case insensitivity is a feature and it's meant to allow easy interfacing with C. And it also encourages clean code. With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability. I…

> In Nim the compiler tells you that you are redefining the same variable in 3 different places and you can go and give them more meaningful names. If this is the goal, there are many alternative ways to solve this problem, making the language case insensitive is a pretty big hammer.

See gtrs' comment above[0]. Why do you assume case sensitivity is "the right thing"?

[0] https://news.ycombinator.com/item?id=21403387

Post reply on HN