Nim v2: get rid of style insensitivity

[dom96]

Nim v2 is on the horizon which presents a unique backwards compatibility opportunity. The original plan for v2 was to simply change the gc to be orc by default but I think we can be more ambitious.

So I am proposing we get rid of style insensitivity in Nim for version 2 and make Nim fully case sensitive.

Not because style insensitivity leads to bugs or any of the other things that those unfamiliar with Nim hypothesise but because it is one of the main reasons that people do not even try Nim. At the end of the day we want Nim to grow and this seems like a good way to do it. It's a fairly easy change too (in the compiler at least) and should reduce the perception folks have about Nim being error prone because identifiers can be mistaken.

Thoughts welcome. Before responding be sure to familiarise yourself with exactly how style insensitivity works in Nim, including the fact that Nim already ships with a --styleCheck option which allows developers to opt-in their code to be case sensitive. For more info read this comment.

[ghost]

I honestly don't think that we should remove a useful language feature because a few people on HN complain that it makes Nim "error-prone" which it actually doesn't. It's actually the opposite: having case insensitivity means that you can't mix is_ok with isOk. If they have an agressive stance towards Nim from the start, they won't magically start using it if we'd remove case insensitivity.

[Araq]

I don't care much either way. I'm slightly in favor of removing it if we at the same time have the tooling enforce nep1 in the hope it makes Nim simpler to teach and to (re-)implement.

[dom96]

The biggest loss I think for me would be the ability to create wrappers with snake_case and use them with camelCase. But thinking about it we could create a couple macros that generate an alias for the other case variant to keep this use case in place and still get a case sensitive language.

[EyeCon]

I'm very fond of style insensitivity. I agree with @Yardanico that not being able to simultaneously have is_ok and isOK a good thing.

I don't know if the argument for having (maybe) better acceptance and having it somewhat easier for the tooling (because then they can just do a string match) is worth removing a feature.

[RSDuck]

I'm for it, mostly because of problems with C libraries.

One example would be OpenGL having enums such as GL_FLOAT, but also a type called GLFloat. Which in the official OpenGL wrapper is solved by naming one cGL_FLOAT, which is ok, but not nice.

Another example is in a library which has a NvColorFormat_V8_U8 and NvColorFormat_V8U8 constant. At first glance having both of these constants looks stupid, but there is actually a logic behind this (thanks Nvidia) and I think in some cases like this the underscore does carry a meaning.

[deech]

I respectfully disagree that it is a good feature and it has bitten me multiple times, an example where it caused problems in the very area it was trying to help ( FFI wrappers ) was when I had to wrap a C identifier that ended with an underscore, the following fails with Error: invalid token: trailing underscore:

type A_ {.importc: "A_".} = object

The same goes for valid C identifiers like A__blah.

[deech]

Further the insensitivity extends to language keywords, there's no reason for all of proc, pRoc and p_r_OC to be valid.

[ghost]

@deech that's true for most keywords, but what about isnot vs is_not and similar?

[deech]

I'm fine with either but not both.

[dom96]

From planetis (sorry, moving that from the forum thread here to avoid splitting the discussion):

Please leave style insensitivity alone, this is not in any way, an "ambitious" change. Btw did you know you can send an email to user.name@gmail.com with a point anywhere between username and it would still work? My point is, it's not that uncommon.

[foderking]

I agree. remove it!
Also, it would be great if the compiler's errors could be improved and more specific
I have wasted a lot of time on decrypting errors

[bluenote10]

I don't have a strong opinion, but it could help if it wasn't the first thing that comes to mind when people start talking about Nim. A random example:

Nim's style insensitivity is definitely one of the most controversial points of that language, and many people see it as a "billion dollar mistake" (myself included) 🙂

[SolitudeSF]

what about adding pragma to force style sensitivity on some symbols?

[planetis-m]

Meanwhile in raylib#bindings-dev a developer that works on R bindings posted:

FYI - I've made aliases to all functions, so you can use either snake_case or TitleCase. It is auto-generated with some regex magic so no hassle 🙂

To me, problems when wrapping foreign libs are related to them having bad naming conventions and are not in line with Nim's NEP1, anyway.

[levovix0]

1. For me, case insensitivity is the best way to resolve disputes between fans of camelCase and snake_case and to please them both.

2. Creating a wrapper over any library from another language is always a problem and it's strange to take into account such trifles as variable name conflicts. If you want to encode the information in the variable name, maybe you should use strings?

[PhilippMDoerner]

As a user, I am mostly neutral and fine with either. If held at gunpoint, I'm leaning towards slightly in favour of removing it. Since I have no idea how this would impact core devs, I am generally in favour whatever is the least amount of effort/makes their life easier since I kinda depend on them for my language of choice to run as smoothly and stable as possible.

What makes me lean slightly in favour of removing insensitivity are the aforementioned C-interop mentions (which I haven't encountered since I also do not use C libs) and that I tend to favour things being explicit rather than implicit. is_ok and isOk implicitly being the same is slightly worrying to me, but does not really affect my code style: I'm using full camcelcase either way (where my project allows me to anyway).

[dado023]

I will post my conditional opinion here.
For me as a beginner programer, style insensitivity is one of good features, which makes it forgiving if i change my style.

However, if style insensitivity is complicating further nim development and interoperability, then it should be removed, if not, then it should stay....simple as that.

[simonkrauter]

Would it be maybe enough to make the feature opt-in?

[exelotl]

I think style insensitivity should stay!

In the last 3-4 years of using Nim I would estimate that I've maybe lost 1 hour to style insensitivity.

• One time when I was making a C wrapper (luckily the conflicting definitions were "legacy" anyways so I could just remove them when I realised what was happening)

• Another time I defined a parameterless template scorebar with technically the same name as a module score_bar.nim, which caused Nim to give confusing messages such as "Error: type mismatch: got <void, Scorebar>". But the root problem is a poor interaction between templates and modules. Style insensitivity just made it possible to trigger it in a way that I didn't expect.

It's harder to quantify the amount of time I've saved thanks to style insensitivity. But I think it helps in a lot of little ways that all add up:

• Scratchpad:

  Consistent style is important, but there are occasions where you legitimately don't care. Debugging macros is a great example: If I want to quickly see what an AST looks like I can write dumptree or echo treerepr foo. My tired fingers appreciate it. I'm going to delete the code 5 seconds later anyway.

• Smoothing over grammatical discrepancies:

  Sometimes I have to use code where the author named their setup function setUp or their tileset tileSet or something else with arguably poor capitalisation. It's nice to not have those choices forced upon you if you disagree with them. This happens with compiler options too, for example --linedir and --stacktrace seem better to me even though they're not the official way.

• Exploration and getting into the zone:

  Related to above - some days I don't know what capitalisation to use myself (should it be scorebar or scoreBar)? Style insensitivity makes it possible to try out both before ideally settling with one, and means I don't have to let my painful indecisiveness stop me from writing code.

  Sometimes I struggle with major productivity issues, so I really do appreciate a language that lets me off the hook in this one case that doesn't make a difference to the correctness of the code itself. In this sense I view style insensitivity as a "well-being" feature, and something that fits right in with Nim's characteristic of letting you get to the heart of the problem domain without distraction.

[ZoomRmc]

... it is one of the main reasons that people do not even try Nim

Citation needed.

Style insensitivity or syntactically significant whitespace are the easiest things to complain about: you don't need to write a single line to start bashing them. However, if such minor quirks prevent you from using a tool which has a potential to solve your problems due to it's technical merits, well, it just means you either don't have enough of a problem or the tools you're already comfortable with is all you need.

At the end of the day we want Nim to grow ...

The main issue of growth is the weak ecosystem. For this Nim needs more developers interested in implementing solid building blocks upon those solid building blocks, provided by the language and the standard library. So, squishing all the bugs, more tests, more docs, finishing already started work, merging or declining all the PRs, unifying and polishing STD's API. That is what's essential to achieve fast and healthy growth, in my opinion.

[AngelEzquerra]

Personally I think it’s not worth the controversy it creates. I think removing it would remove one of the obvious (yet weak) arguments against nim.

Perhaps there is a way to replace the case insensitivity feature with something else that lets us maintain its benefits? All the criticism that I’ve seen of this feature focus on the fact that it cannot be disabled and that it might cause errors due to using two different names for the same symbol. We could add a way to explicitly import a module in a “case insensitive” way, but make it so that all usages of a symbol in the module that imports it must use the same symbol name. I think this fixes the two problems I mentioned earlier (i.e. it’s opt in and there can be no symbol clashes).

An advantage to adding this alternative to the existing case insensitivity is that it would make it easier for people that use case insensitivity to migrate to nim v2.x (which IMHO should be a very important consideration when introducing backwards compatibility breaking changes such as this one).

[FedericoCeratto]

Can I propose a third option? Keep style insensitivity but have the compiler print clear warnings by default when the same element appears with different styles within the same file. The warnings could link to a text explaining how insensitivity is a readability and safety feature, not a bug.

It should have file granularity to support wrappers and the use of 3rd party libraries with different styles. It could be extended to a whole directory or whole project with command line flags.

Edit: I'm aware of the --styleCheck flags and external linters but my point is about doing checks by default, on file granularity and provide a good explanation on the safety and readability benefits. Additionally, --styleCheck enforces camelCase which is not what people necessarily want.

[levovix0]

what about adding pragma to force style sensitivity on some symbols?

How many people will actually use it? It seems to me that if such checks should be introduced, then in the other tool, not in the compiler.

[ghost]

Can I propose a third option? Keep style insensitivity but have the compiler print clear warnings when the same element appears with different styles within the same file. The warnings could link to a text explaining how insensitivity is a readability and safety feature, not a bug.

(The warning could be disabled with a pragma in library wrappers and so on)

This is already a thing (just a hint instead of a warning, and global to the whole project) - --styleCheck:hint. There is also --styleCheck:error for those who really want to use the original style for the variable throughout their project and all of the libraries.

[ghost]

let isOk = true
echo is_ok

$ nim check --styleCheck:hint test.nim
Hint: used config file 'C:\Nim\config\nim.cfg' [Conf]
Hint: used config file 'C:\Nim\config\config.nims' [Conf]
.........................................................
D:\Projects\NimExperiments\test.nim(3, 6) Hint: 'is_ok' should be: 'isOk' [let declared in D:\Projects\NimExperiments\test.nim(1, 5)] [Name]
Hint: 
26789 lines; 0.160s; 25.586MiB peakmem; proj: D:\Projects\NimExperiments\test.nim; out: unknownOutput

[HugoGranstrom]

Style insensitivity is one of my favourite features of Nim. It is always a pain using other languages and libraries because you are at the mercy of the library developer's code style.
One example I'm losing my mind over right now is MPI:
MPI_Irec, MPI_Waitall, MPI_Sendrecv_replace.

Having the option to use libraries in my own way is worth gold to me. And regarding those people complaining at Nim using soley that argument, I don't give a dime about what people who clearly haven't put the effort to actually trying the language out thinks. There is nothing stopping a particular user from having the same code convention in their code, so why take it away from those of us who are enjoying it?

[beef331]

Whoops i misread

[xigoi]

Idea: remove style insensitivity, but disallow underscores in identifiers. That way there's no snake_case and it introduces the possibility to use underscores for something else. However, there will still be a problem with things like fooId versus fooID.

(I don't support this myself, but I'd probably prefer it over style insensitivity just being removed.)

[beef331]

I'm for it, mostly because of problems with C libraries.

One example would be OpenGL having enums such as GL_FLOAT, but also a type called GLFloat. Which in the official OpenGL wrapper is solved by naming one cGL_FLOAT, which is ok, but not nice.

Another example is in a library which has a NvColorFormat_V8_U8 and NvColorFormat_V8U8 constant. At first glance having both of these constants looks stupid, but there is actually a logic behind this (thanks Nvidia) and I think in some cases like this the underscore does carry a meaning.

Personally this is exactly why I'd want to keep it, machine made Opengl wrappers are full of what i consider stupidly written constants this isnt COBOL we dont needs to scream constants. In my framework I heavily use it to get the Opengl constants to what i prefer which is sane PascalCase instead of SCREAMINGCASE. An _ being important pretty much demonstrates just bad code practices which should not be carried through to a language with a better type system and better language features than the source language imo. We can use templates + typedescs to get around the stupidity that is that API, we do not need to pretend _ is actually important.

[saemideluxe]

@PMunch Thanks for the insights. Okay, so I think the approach with collision detection and using postfix might work for me. It is still not my ideal vision of preserving the exact identifier name, but the most pragmatic approach I think.

[chitatof]

Now, this thread exists for a reason, or many reasons. But I feel the actual reasons this thread exists has been lost in the discussion. My advice is to focus on the actual problems.

Case insensitivity is not a problem by itself. It's a convenient feature. But as pointed in this thread, ambiguous identifiers are a problem when interfacing with C.

I agree that style insensitivity is not a real problem, not in Nim. But it seems to me that he real reason this thread exists has nothing to do with making C wrappers, sure there are minor inconveniences in that area, but that is all they are, minor inconveniences, which in my opinion are well outweighed by the benefits (that is, being able to use third party libraries with your preferred style), sure some people still have qualms about it, even in this thread, but how many people have stopped using the language because they had minor troubles writing C wrappers?

The real problem with style insensitivity is that it is stopping a lot potential users from even trying out Nim, because apparently, style insensitivity is a crazy man's idea! Of course, as a Nim user, you know that isn't anywhere close to the truth, both practically and philosophically, but the fact of the matter is, a lot of people already made up their mind about it, and they will stay stubbornly adamant forevermore.

So we are stuck with a dilemma, should you just give it up? or should you stay persistent? and at what point does that persistence become the same adamant stubbornness that is causing the problem in the first place? Frankly, I don't even know where I stand on this topic. I like style insensitivity, but I also like Nim as whole, which means I want it to thrive and become a popular language. I will say though, I'm not entirely convinced that style insensitivity is such a big barrier for people to try the language, I mean, it isn't really advertised as one of its "big features", personally I didn't even know about it until I was already using Nim for personal projects, at that point it did made me raise an eyebrow but I figured if it hadn't caused problems until then, then I probably didn't have to worry about it. The only reason some people find out about style insensitivity before even trying out Nim is the odd user on Hacker News or Reddit mentioning it in the comments, typically in a negative light, but even the people who WILL see that comment aren't guaranteed to turn down the language. So really, how much of a problem is it? And more importantly, are there other issues that merit more attention?

[v3ss0n]

The real problem with style insensitivity is that it is stopping a lot potential users from even trying out Nim, because apparently, style insensitivity is a crazy man's idea! Of course, as a Nim user, you know that isn't anywhere close to the truth, both practically and philosophically, but the fact of the matter is, a lot of people already made up their mind about it, and they will stay stubbornly adamant forevermore.

This is what i had highlighted since I had started trying nim . Since Nim become 1.0 i was introducing nim to my colleagues , and friends from big tech ( Intel , Google) . The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base. They are mostly Golang and Python Devs , that comes from Java background . So when they bring up topic on How should one be controlling code quality when underling language is totally style insensitive in the core , i can't say much because what they say is true. I had trained many interns and when there is no restriction in place they write code in whatever way they want and , since nim enable it , it would become one hell of a spaghetti .

I had raised that once in forums , or chat , but Nim community reaction was like "We don't care about what software industry or big tech people says. " . True , i don't like big-tech too , but that doesn't mean there aren't good , influential software devs in big tech there and they influenced a lot of developers.

The merits Style Insensitivity bring is nothing if you compare to a lot of people who won't adopt nim because of style sensitivity .

[PMunch]

The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base. They are mostly Golang and Python Devs , that comes from Java background . So when they bring up topic on How should one be controlling code quality when underling language is totally style insensitive in the core , i can't say much because what they say is true.

This is something which could easily be solved by tooling though. I believe Nimpretty has settings for this. But the bigger point, which is much harder to make people realise without having tried it, is that style differences doesn't matter. I can agree with the desire to keep a tidy code base with certain guidelines for writing code that is easier to read to a bigger set of your team. But identifier styles does so incredibly little to that end. The overall structure of the program is much more important. And how do you ensure someone programs in a good coding style? You code review. And you know what else you can enforce with a style guide and code reviews? Arbitrary identifier rules. I mean most companies wouldn't allow code with only single letter identifiers, but does their language enforce this? The whole argument is a bit similar to the whole "without god people would just go around murdering anyone", the existence or non-existence of a god is not what is keeping me from murdering people..

[al6x]

Enforcing code style usually a job of the linter. Linter could be a standalone tool or be built-in or extension to the compiler.
JS, for example, allows pretty much anything, yet, there's no problem in big tech with JS code style, just add the linter step in your build process, and enforce rules you want.

[v3ss0n]

The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base. They are mostly Golang and Python Devs , that comes from Java background . So when they bring up topic on How should one be controlling code quality when underling language is totally style insensitive in the core , i can't say much because what they say is true.

This is something which could easily be solved by tooling though. I believe Nimpretty has settings for this. But the bigger point, which is much harder to make people realise without having tried it, is that style differences doesn't matter. I can agree with the desire to keep a tidy code base with certain guidelines for writing code that is easier to read to a bigger set of your team. But identifier styles does so incredibly little to that end. The overall structure of the program is much more important. And how do you ensure someone programs in a good coding style? You code review. And you know what else you can enforce with a style guide and code reviews? Arbitrary identifier rules. I mean most companies wouldn't allow code with only single letter identifiers, but does their language enforce this? The whole argument is a bit similar to the whole "without god people would just go around murdering anyone", the existence or non-existence of a god is not what is keeping me from murdering people..

I agree with all you said but its just hard to change their religions.

[xigoi]

So when they bring up topic on How should one be controlling code quality when underling language is totally style insensitive in the core , i can't say much because what they say is true. I had trained many interns and when there is no restriction in place they write code in whatever way they want and , since nim enable it , it would become one hell of a spaghetti .

Point out that with style insensitiivity, you can avoid having a mess of different styles, whereas with style sensitivity, it's pretty much impossible unless you never use any libraries.

[ZoomRmc]

The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base.

--styleCheck:usages --styleCheck:error → problem solved.
This thread goes totally in circles at this point.

[beef331]

If it was any more cyclical Araq would change the topic subtitle to "remove OSI".

[theAkito]

This thread goes totally in circles at this point.

Indeed. The following was made already utterly clear.

Style Sensitivity

• Same stuff, as in other languages. No choice. You are forced to obey.
• You can still make single letter variable names, compose your modules horribly, import a million tiny third party libraries (Hello, JavaScript disasters!) etc., but that is apparently not reducing the readability & maintainability of the code as much as style insensitivity. Riiight...
• It's a one-point discussion, to the point of becoming a religion. Style insensitivity is such a tiny aspect in the entire complex of what makes readable & maintainable code, it's ridiculous how much they focus on it, just to be angry about it. (I mainly talk about the ragers on those Hacker News type of websites.)

Style Insensitivity

• Freedom, as it makes sense in the Nim eco-system. The whole point of the huge meta-programming abilities in Nim is how flexible the language & its syntax is. Style Insensitivity is a natural part of it. It's a core ability & feature of Nim.
• You can still use compiler flags to enforce style sensitivity, which makes the points about supposedly unmaintainable source code moot.
• You can even use extra tooling to further enforce style sensitivity, which is an utter K.O. argument against all the fuzz about a tiny minority desiring a restriction for a language they aren't even using. 😄

Therefore, I am convinced it is unnecessary to further debate whether to listen to a raging minority of people who do not even use the language to begin with plus a minority in the Nim community. Not sure how big it is. I suppose it's small.

That said, one more point regarding making Nim more sharable to third parties.

If the Nim core would obey to all those requests to mainstreamify Nim, major parts of what makes the language so unique, powerful & distinguishable from existing & more established languages would fall apart.
Which means, Nim would lose significance, as there would be no need to switch to Nim, if it's the same crap you have in other languages, too.

People don't switch from car No1 to car No2, if it's the same crap, but with different labels.
People switch from A to B, if B is objectively different & subjectively better.

[DestyNova]

It's a one-point discussion, to the point of becoming a religion.

Therefore, I am convinced it is unnecessary to further debate whether to listen to a raging minority of people who do not even use the language to begin with plus a minority in the Nim community.

You've had the opportunity to share your opinion, but disparaging and dismissing opposing opinions as "religious" is really unfair and not constructive.

[v3ss0n]

The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base.

--styleCheck:usages --styleCheck:error → problem solved. This thread goes totally in circles at this point.

thats a good way . it should just be default then.

[saemideluxe]

The first thing they point out that Nim being style insensitive , it would be very hard for them to keep a consistent code base.

--styleCheck:usages --styleCheck:error → problem solved. This thread goes totally in circles at this point.

This is pretty much what I was looking for. For some reason I missed this or failed to make the connection when reading through the compiler commandline flags. Thanks a lot 👍

[Skaruts]

Snake_case coder here. I have to say that for me this was never a reason not to try Nim. On the contrary: being a snake_case coder, this actually appealed to me at the beginning.

However, my experience with it in the long run has been that... well... it's not really useful. And is somewhat limiting, especially due to underscore-insensitivity.

I mean, in practice... I only ever bothered keeping code consistent with my style about a dozen times. I quickly stopped bothering, because having snake_case and camelCase mixed up doesn't really bother me as much as it does having to keep worrying about keeping code consistent. I find camelCase harder to read, but most of my code is still snake_case, so it doesn't bother me too much.

What bothers me the most about camelCase is typing code in camelCase. And since that's what most libs are using, and therefore it's what code completion suggests, then... that's what I'm gonna be using. I just press Enter and move on. And it still ends up being less annoying than having to bother keeping code consistent all the time.

So at the end of the day, this has never really solved anything for me. It's... just there.

I don't have much of a problem with case-insensitivity, tbh. The thing that really bothers me the most is not being able to make good use of underscores. It's among my main peeves about Nim.

So I would be in favor of at least having an option to make underscores significant. Especially __these__ underscores.

---

Also, I'd like to just address the belief that not being able to have is_ok and isOK at the same time is a good thing.

It's neither good nor bad. That belief is actually an illusion. If a person is in the habit of doing that, then that person can still have is_ok and Is_ok and isAOK and is_okk. Nim isn't solving anything, it's only making that person take a second longer to come up with the same thing differently, if that's what they really want.

Anyone can still do x and xx, or foo and foo1. This feature makes absolutely no difference for this kind of stuff.

[actondev]

Not sure if this was asked before, but does this insensitivity have an impact in the compilation speed? I'm assuming somewhere in the compiler code some name.replace("_", ""). I'd say good riddance to these lines.

As for the is_ok vs isOk argument. I kind of like zig's style guide:

    If x is a type then x should be TitleCase, unless it is a struct with 0 fields and is never meant to be instantiated, in which case it is considered to be a "namespace" and uses snake_case.
    If x is callable, and x's return type is type, then x should be TitleCase.
    If x is otherwise callable, then x should be camelCase.
    Otherwise, x should be snake_case.

Which , if one were to stick to it, solves the problem of how do you name a predicate function vs local bool predicate result. The function is isValid and you store the result in is_valid, done

[Araq]

Well v2 has seen several release candidates now and no release candidate changes the style insensitivity rules. Closing.

[Araq]

Which , if one were to stick to it, solves the problem of how do you name a predicate function vs local bool predicate result.

That doesn't solve the problem though as these names are identical in my head since I remember words by their sound, not by their spellings. This is also true for every human being I ever interacted with btw.

[theAkito]

Actually, the brain remembers visual images most efficiently. I'm happy to be the first one you encountered, that remembers a part of words by how they look, which includes spelling.

With complicated words, I sometimes even change the spelling in my head to auto-correct issues with the image containing spelling.

Especially, when you learn lots of different natural languages, it's important to see the word, how it's supposed to look. Even more so extremely important with non-Latin character based languages...

That said, I am not arguing for the Zig style guide. I do not find it useful, because it solves a supposed "problem" by making things more complicated.

[Araq]

Actually, the brain remembers visual images most efficiently. I'm happy to be the first one you encountered, that remembers a part of words by how they look, which includes spelling.

Better never change the programming font then.

[v3ss0n]

Well v2 has seen several release candidates now and no release candidate changes the style insensitivity rules. Closing.

A small change , that would Nim adoption by many fold was rejected ...
I respect your decision but we had highlighted because we want serious nim adoption in production as with 2.0 . We expected it be more than just a toy language or black hat community uses it for building viruses and spyware .

This would make it a main reason why many won't accept nim as a serious language - especially by production experts . I wish you reconsider it in later releases ..

Thank you very much for hard work you guys had put into Nim.

[theAkito]

If tech people would only do, what is currently accepted as the Meta of how to do things, we'd still be stuck with Algol 68 or at most C & PHP. We would have no Typescript, Kotlin, Nim, Rust, etc....

When you develop a language, you develop it for what's supposed to work in 10 to 20 years. So, if you ask supposed "production experts" who are stuck in the past or at least cannot see, where the ship is sailing, then their opinion is just as useful as some random Nim user's comment in this thread, like for example mine. 😁

Actually, being stuck in the past is a huge problem in the software industry. There are too many close-minded people who are in it for many decades & yet they are so smart to justify their doings with I have always done it like this. That's just a pretty human (i.e. dumb) excuse for doing something. It's a logical fallacy.
These "industry experts" don't help. They make things worse.
(Obviously, not every expert is like this. I'm just saying, that there is a strong minority halting general progress in the tech industry, as depicted.)

[DestyNova]

Actually, the brain remembers visual images most efficiently. I'm happy to be the first one you encountered, that remembers a part of words by how they look, which includes spelling.

The brain doesn't remember visual images more efficiently, but rather spatial and conceptual relationships. The idea of a photographic memory is certainly a myth, and even iconic memory (the ultra-short-term visual memory buffer) is very limited.

Leaving aside the "memorability" issue though, my problem with is_ok and isOk etc is using grep and other tools. I don't care what "best practices" industry wafflers think, but it does bother me if I'm restricted in using text processing tools effectively. "Use an IDE" is probably the most common answer to that sort of problem, but that's honestly a bit silly. One of my favourite things about Nim is that it's clean and self-contained enough that I can use it with vim without needing a bloated IDE.

[Zectbumo]

This would make it a main reason why many won't accept nim as a serious language - especially by production experts .

I remember something similar was said in the early years about Python and their lack of code block braces...

One of the things that drew me in to Nim was the battle of camelcase and underscore was over. One of the wishes Python3000 had was to standardize everything to snakecase and they ended up with a mishmash in their standard library that is inconsistent even in the same module. It just can't be helped and I feel Nim solves this nicely. Hopefully we get a solution to solving case sensitive problems with stropping.

@DestyNova

...my problem with is_ok and isOk etc is using grep and other tools.

Perhaps a tool you are missing is one that takes in a nim identifier and spits out the matching regex.
grep -RE "$(nimid isOk)" my/src/

[DestyNova]

...my problem with is_ok and isOk etc is using grep and other tools.

Perhaps a tool you are missing is one that takes in a nim identifier and spits out the matching regex. grep -RE "$(nimid isOk)" my/src/

That's a really nice and elegant idea!

[geofire]

Therefore, I suggest a compromise:

Add a pragma that simply turns style insensitivity off or on.

There you go. No need to remove it, since everyone who already uses Nim really likes that feature. With a pragma, people who come from other languages can simply turn it on and get their familiar strict style back. I can instruct beginners to start with SI off, and then turn it on later when they're more comfortable with the language. Existing code continues to work no problem with new code being able to use it or not. And, in the situation of C libraries with conflicting naming it could help resolve those errors by simply tagging their source as style strict.

I agree with this approach. Let the 'end'-developer choose, and treat style insensitivity as an advanced language feature. One of Nim's benefits is that it's an ergonomic compiled language, and can be moulded to fit the needs of the developer. I have my preferences about coding style and these definitely differ from other developers. What SI does is help prevent 'religious debates' about which style is better over another. Nim, through such a declaration, lets me choose so that I can code based on how my brain works. The same can be said when others pick up my code, but can't work with my code style.

I'd suggest adding a change to the compiler for Nim 2.1 to warn a developer about not declaring a style sensitivity preference. From Nim 3.0 change the 'lack of style declaration' to an error. This will give developers time to get used to the idea of forward declaring their style preference before enforcing it language-wide.

Whilst I find Nim's style insensitivity feature awkward, because I'm not used to it coming from languages that enforce style sensitivity, I can definitely see how it is useful and can/will make my life easier, allowing me to use other libraries and not be forced to use their code style of choice, because I have my own code style that works for me.

With more advanced tooling in an IDE, linters, intellisense, and code formatters could use these pragma declarations to automatically format code based on the end-developers preference, if required, or transparently 'translate' between different styles of variable or declaration.

[xigoi]

@Zectbumo Using grep will only be a problem if you use an inconsistent style within a single codebase, which… just don’t.

[xigoi]

@geofire

Nim, through such a declaration, lets me choose so that I can code based on how my brain works.

Why would you need a declaration for that? You can already use whichever style you want thanks to style insensitivity. By declaring your code as style sensitive, you would be forcing your choice on others who use your modules.

I'd suggest adding a change to the compiler for Nim 2.1 to warn a developer about not declaring a style sensitivity preference. From Nim 3.0 change the 'lack of style declaration' to an error.

Please no, I don’t want my Nim codebases littered with style declarations.