Style Insensitive?

[DAddYE]

Nimrod is a style-insensitive language. This means that it is not case-sensitive and even underscores are ignored: type is a reserved word, and so is TYPE or T_Y_P_E. The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions. A Nimrod-aware editor or IDE can show the identifiers as preferred. Another advantage is that it frees the programmer from remembering the exact spelling of an identifier.

Please rethink about that or at least give us an option to disable both: case insensitive and also underscore ignored, this at least for me is struggling since every language I know is case sensitive and since I started to play with this beautiful project I did always case / underscore mistakes...

Example:

type
   SWITCH = enum
      on, off

proc switch(from: SWITCH, to: SWITCH):
   do_some

[ghost]

I'm fine with this now that I know about the naming conventions (TFoo for types, and PFoo for references etc). Also, you can't do this for example "_end: int" since underscores aren't significant, but that's not really a problem either since you can always do "end: int".

I think most people will want to stick with the style that is used in the standard distribution though, but it's still a small price to pay for this kind of flexibility IMO.

[ghost]

I meant "end: int"

[dinedal]

A big issue I see with style insensitivity is that it is very easy for a single developer to choose a style for a code base, which is their own preference. But the any other developer that works with that code base must choose and self enforce with no help from the language the exact same style, or the code base will contain mixed styles.

A huge advantage to consistent, readable styles is that there is much less mental overhead in reading code written by other developers. Go-lang has even gone so far as to have the compiler enforce exactly one style. Regardless with if you agree with the style choices, which I do not, one must agree that now there is 0 overheard in learning many coding styles for the language, in fact, once you learn the one Go-lang style, there is no other style to learn, and you will never be confused about a particular Go-lang code base's conventions ever again.

I believe that there is a strong argument to be made that for any group of developers working together, a consistent style is a huge benefit. There is no confusion on what a token refers to, there is no metal parse of foo == f_o_o == fo_o. There is less of a chance of mistaken reference between included code bases and your own code bases.

People will always use the style they prefer, even if there is a guiding light of a standard library to show them the correct style, especially if the language allows them to do so.

[Araq]

Indeed people will always use the style they prefer and thanks to style insensitivity I don't have to care. My editor can show all the identifiers as I desire (well once editors support it).

Also a consistent style for code bases is VASTLY overrated, in fact I almost never had the luxury of it and yet it was never a problem. The real problems are crazy dynamic semantics: Excessive dynamic binding thanks to interfaces (see how Go fights this problem ... it exacerbates it!), unclear types thanks to dynamic typing, complex control flow, etc etc. Whether the "{" consistently starts on a new line or not is irrelevant.

[DAddYE]

@Araq as promised I'm trying before I'll submit you a more complete "context" to use a bit more this new style.

I admit in some circumstances I like it but ...

I agree with @dinedal, one thing as a newbie I'm suffering a lot, is readability and naming conflict issues (especially with enums). Trust me, readability for a newcomer is important and on nimrod seems quite difficult to master.

I need to read at least two times what is TTime or what is a PIO (In Italy is a human name, and here a pointer to an IO type).

Another (IMHO) error we do is to think that all of us use an IDE, that's not true and if you look at recent statistics vim, emacs, tm, sublime, notepad+ are becoming the de facto editor. Personally I know a pretty big amount of coders, only few of them use an IDE and usually when they are dealing with Java or Object-c. I don't want to argue if is best an IDE or not, I want only point that I think are more the users without an IDE.

Debugging issue: not all IDEs now support Nimord and certainly I can't use my vim c*tags, so I can't jump where a var,proc,type is declared.

So, I saw cases where a proc is using snake_case but somewhere else is used in camelCase and some where else CamelCase. My trick usually with langs not well supported by my editor is simple: $ ag procedureName. As said the procedure was declared in snake_case so I'm unable to find it thus I try camelCase then I need to flag my vim ag/ack to don't care about sensitive case and so on, aka a waste of time :(.

More than the time spent to figure where the thing is declared I need however to learn the code style of another person to guess where is this thing. So I can't see this statement working: "Indeed people will always use the style they prefer and thanks to style insensitivity I don't have to care."

Honestly only (IMHO) bad programmers follow a very own custom style. I usually never seen something pretty odd in the freedom of ruby-land or python-land or javascript-land or clojure-land... indeed from a good coder.

As @dinedal told us the thumb of rule of a nimrod fmt source.nim is interesting enough. It works so well in go-land that all the source code around looks like written by one person and is pretty easy to read it.

Finally I don't want to fight on what is the correct way, I think you have good reasons and (maybe) we too, we should try to consider only (and I'm not saying that that's correct) that the majority of recents languages (with large adoption) are sensible case. Unix systems are sensible case, my native langauge (Italian) is sensible case, English (my bad second one) is sensible case and so on. I know Japanese and Cinese survive without it but ...

Last word, maybe you don't care but IMHO for a large Nimrod adoption this is an important point to consider as the majority of us prefer another convention (not style).

[gradha]

Wow, I'm surprised this thread is still alive here and has not been moved yet to the nimrod forums.

Anyway, @DAddYE, the reason you can't jump around in vim is because you haven't installed https://github.com/zah/nimrod.vim/, which works with any case style, since it queries the compiler itself for locations. Once you have it you can jump straight into library code and review its implementation. No need for clunky ctags.

Also, a nimrod fmt is possible to do, go ahead man and implement it! I'm sure people will love it.

[Araq]

Another (IMHO) error we do is to think that all of us use an IDE, that's not true and if you look at recent statistics vim, emacs, tm, sublime, notepad+ are becoming the de facto editor.

Irrelevant. Vim etc. essentially are IDEs albeit more language agnostic than - say - Eclipse. Even if you disagree and call them editors that doesn't mean that they don't have or can't have IDE-like features.

But even if the feature is missing, the average Nimrod code is much more readable than the average C# code IME at least. It's also much more readable than Clojure and Go code. And even better: You cannot only read the code but reason about it. I'm sick and tired arguing about minor syntactic issues when all that matters are the semantics anyway.

Honestly only (IMHO) bad programmers follow a very own custom style.

If syntax is all that concerns you, you're a bad programmer.

What the majority of languages uses is also no argument. The majority is dynamically typed or uses braces for control flow.

[DAddYE]

But even if the feature is missing, the average Nimrod code is much more readable than the average C# code IME at least.

Maybe because you come from Pascal and you wrote yourself Nimrod trust me I'll find much more easier to read clojure and any other language mentioned by you.

If syntax is all that concerns you, you're a bad programmer.

Thanks, to saying me that I'm bad programmer. Because yes the syntax concern me because I'm not a one man show I usually work in a team and good coding style roles can increase a lot the chance to get a job done in less time.

What the majority of languages uses is also no argument. The majority is dynamically typed or uses braces for control flow.

Also, that's not true at all and also at least you should divide by high level languages, medium and low. That's said you should be surprised why not many insensible case languages had success other than: VisualBasic ?

[Araq]

Thanks, to saying me that I'm bad programmer.

Come on, it was a tit for tat response.

That's said you should be surprised why not many insensible case languages had success other than: VisualBasic ?

There is nothing to be suprised about. I know perfectly well the reasons why languages succeed or fail. The MAJOR reason is whether it's the platform's native language or not. Make Golang the native language of Andriod and watch it raise in popularity by a factor of 100 if not more. Just see how Objective C usage took off thanks to Apple's comeback.

Also your ignorance of Delphi is annoying. It's still 17th in Tiobe, would rank higher than Ruby if Tiobe wouldnn't pointlessly distinguish Pascal and Delphi. OK, Tiobe doesn't mean much.

The idea that case (in)sensitivity has any measurable impact of the success of a language is absurd.

[Araq]

EDIT: Nope wouldn't rank higher than Ruby.

[Araq]

BTW Nimrod code is objectively more readable (if you conflate readability with reasonability) since it avoids problematic semantics like reflection or dynamic typing.

[DAddYE]

JIC: https://github.com/languages/Delphi vs https://github.com/languages

I'm not here to discuss what is better or not, what is right or not. I don't know why this issue is following that way. Also I'm not here to discuss language designs like reflections, dynamic typing or so.

I find the readability messy why?

# module a
type
  TThis = object
  TContext = enum
     THIS, THAT

proc hello_there(this: TThis) =
  echo "who is this? ", this

# module b
import a

var this: TThis
this.helloThere()

• The need of prefixes / suffixes (not common in recent languages)
• Prefixes suffixes as a replacement to a simple Capitalize or CamelCase are less readable IMHO: TIO, TTime, Poi.
• NO UNIFORMITY == hard to be read from a new nim coder
• Very error prone, in my bad example this is TThis or a TContext, is this javascript ?

As a statement for no standard guidelines for a newbie I mean read code where sometime one call tIO, TIO, tio, Tio in the same library or proc foo_bar but then you write another proc with proc Foo().

Btw since every one here seems (seeing reactions) to take this as a personal offense and tend to make (under the hood) offenses I'll close.

[Araq]

I'd like to continue this discussion if you don't mind and promise to not make any offenses.

• You don't need the prefixes. You only need them because you deliberately want to name everything the same: types and functions, enum values and variables and parameter names. The T vs P is about value vs reference types.
• The stdlib is uniform afaict, if not we should make it uniform. The conventions are documented.

How is:

void foo(Foo* _foo) { _foo = 0; }

good readable code? I honestly can't see that. Why are constants all UPPERCASE? That puts emphasizes on the non-changing parts! It should be the other way round, the mutable state should SCREAM. It's uppercase because of historical reasons, because of C's preprocessor. C# doesn't use it.

[dinedal]

There's no need for either side to devolve in ad hominem attacks please. Both of you are established developers with extensive open source contributions, and each side has presented thus far has strong arguments.

@Araq, I believe you misconstrued @DAddYE's statements as such, but please know that as his co-worker, he and I chat daily and on more then one occasion he has stated his respect for your abilities and works. @DAddYE himself is the author of Padrino, and has written many other open source projects as well. However, english is still his second language and therefore I urge you to ask him to please clarify before jumping to any conclusions if for any reason you might presume he is attacking your character.

[DAddYE]

Thanks @dinedal, absolutely no problem by me!

Touch those things I know is like re-discuss about a religion.

void foo(Foo* _foo) { _foo = 0; }

@Araq you're comparing an awesome, but old language.

I will compare it with scala

val foo = (foo: Foo) => foo + 1

Why are constants all UPPERCASE? That puts emphasizes on the non-changing parts! It's uppercase because of historical reasons, because of C's preprocessor. C# doesn't use it.

I think because in this way you wont have naming conflicts, I have usually very few constants, so emphasize something that is immutable isn't that bad, at least I prefer have 3/4 UPPERCASE words instead of the opposite, or add a prefix to avoid naming resolution problems.

@gradha pointed me on a better config for vim, honestly I use snippets but not autocompletions, so just because I'm quite prone to try new things I recompiled my vim with python support and tried to setup a autocompletion environment... without success. TL;DR; yep I need to turn off autocompletions case sensitive (a global var) which have problems with all languages I had to use and it can complete things from nimrod codebase.

[gradha]

Ah, note how I did avoid mentioning autocompletion, I use vim's string based autocompletion. The nimrod vim plugin is wonderful for jumping around foreign code: you place the cursor somewhere, call JumpToDef and after a second or two there you are, without ctags. But I don't use it for autocompletion.

Since it's all about opinion let me weigh in, brace for TL;DR. Personally I like snake case and despise camel case. The fact that I can use snake case with camel case designed APIs is really nice, but... I don't practically use it, and my snake case calling external code tends to use whatever external case was used. More than simple letters (using lower case or whatever) what I dislike about styles are global inconsistencies. I'm ok with using camelCase as long as there are no snake cases mixed in, or word particles which don't use upper case, or suddenly somebody copied stuff from some other API and you have two styles mixed in.

And yet this is only the tip of the iceberg, for me style is also how things are named (verbs, nouns, adjectives), or how they are composed (verb + noun or verb + useless particle + noun), or how things are visually outlined in the code, or how comments are written and where they are placed. Style is more than just letter casing but the whole bag of conventions you used to turn code into something you want to look at. So despite having my strong opinions about case, I contribute always using the style of the original source code. To the point were the code I write usually tries to look as if it was written by the author (though I usually fail because for some reason other authors rarely use comments in their code, anybody has ideas about that?, so my new comments stand out in the wilderness like a tasty deer).

But there is a second important point: communication. As it has been mentioned, rarely you work alone in your environment. What it means is that you end up talking to other people and discussing code, and often you end up saying aloud lines of code so as to argument something, teach a technique, or simply put into context what you are discussing. In this context, case sensitivity sucks big time. Having to say "Oh yeah, the proc is all lower case switch, open brace, from, colon, all upper case switch, etc" is madness. Same with having to say "lower case foo" vs "upper case foo".

If you find talking to other developers having to mention upper/lower case your API is bad beyond belief, because it IS causing confusion: it is preventing your developers from communicating. It is when people don't realise this that I think they either work alone or never IRL, always talking through email/chat where case is part of the communication channel.

So looking at the wishes of people willing to have a case sensitive language I think to myself: "oh, god, these people want trouble, as if they had never worked in a team". Yet that's the argument that I see flying over here. I believe it's incorrectly used, most people design APIs with their butts, and unfortunately few people have strong opinions to improve over them, so they just go "meh, I'll copy this convention because its easier than figuring myself what's good". The worst offenders being those who come from another language and try to copy their previous style into the new one simply because they don't know better and you know, learning new stuff gets you out of the comfort zone.

More specifically, I haven't read about any good case sensitive argument so far. All the examples using case sensitivity would make me in real life stand up, go to your seat/cubicle and slap you in the face. Really, if you want to bring good arguments you need to compare whole APIs designed with one vs another style, and then illustrate how a piece of code using that API is better/easier to understand/work with than with another.

[gradha]

BTW @DAddYE, I'm looking now at some clojure tutorials since you mentioned you prefer its readability over other langs, and most code uses lower case and dashes rather than camelcase. So I think you are confusing the other elements of clojure style with upper/lower case. The only places I see upper case is with code interoperating against Java APIs (see http://java.ociweb.com/mark/clojure/article.html). I don't know why you advocate case sensitivity yet consider clojure one of the most readable languages, where upper case seems absent in the general style.

I think this points out more that case style is mostly irrelevant for readability, once you put it into the whole context of the language were there are so many more important things to pay attention to.

[DAddYE]

BTW @DAddYE, I'm looking now at some clojure tutorials since you mentioned you prefer its readability over other langs, and most code uses lower case and dashes rather than camelcase.

Where I've said that there are in clojure camel case or underscore?

There is a misunderstanding, I'll try to summarize with a noob formula:

                               readability == uniformity

How much uniform Nimrod is? Not that much. tNode or TNode. What about C calls ?

I like clojure just because it is uniform everything (except interop) is just hello-world 1 rule to rule them all.

I totally don't care if you write in snake_case, camelCase, dash-case but should be only 1 rule

That said I think the argument of this context, case sensitivity sucks big time can be only done by two super anarchic coders.

I've no idea about a large adopted javascript library in underscore (not coffee script), ruby methods written in camelcase, there are some of them (IIRC) in c and c++ just because there are some old advocates but really in modern languages at least all I used doesn't suffer of this giant pain as u described.

Honestly we have style guides but are more focused on spaces indentations a some minor things:

https://github.com/styleguide

That's my first time in my life that I'm discussing something like that, isn't that strange?

I've some minor questions for you @gradha.

1. Why you use upper/lower case letters in your language? Why you write email with that? Really isn't necessary, if there is a confusion between a human name and a city why u don't simply prefix it with c or h ?
2. Why do you need to prefix things?
3. If your coworker will decide to not use prefixes at all would be worse than a constant UPPERCASE?
4. If something like 90% of world codebase today is still case sensitive doesn't sound a bit strange, I mean Nimrod isn't the first language case insensitive, we adopted Ruby and Node.js why we can embrace a such good thing?
5. With an hand on your heart, do you think ruby, node, python will be ever ever largely adopted if they were insensible?

[DAddYE]

Just to clarify:

we can embrace a such good thing

I mean the insensible case

[zah]

I'm curious why the original example in this thread didn't work?

type
   SWITCH = enum
      on, off

proc switch(from: SWITCH, to: SWITCH):
   do_some

Didn't we implement overloading of type names with proc names at some point (either with separate namespaces or with nkSymChoice)?

Otherwise, obviously this thread is going nowhere. Araq's point is that comprehensibility of the code is what is important and comprehensibility comes from good semantics, not from the mechanical rendering of the program text. People will always prefer different styles and Nimrod tries to position itself for a quite distant future, where you'll be able to tell your IDE (editor) how you prefer to see the code and the preferred style will be applied everywhere. Only before saving the file to disk and committing it to version contol, the IDE needs to normalize the code to some common style adopted by the project as a whole.

[DAddYE]

Ok: nkSymChoice is already to odd to me but .. If I'll decide to write in nksymchoice how chances as the IDE/editor to format it in a comprensible way? Same of an sensible language. Honesty I feel quite mechanical in putting prefixes to render quite illegible my types and my pointers and my enums.

[zah]

Sorry DAddYE, with nkSymChoice I'm referring to some internal implementation details.

The general idea is that the prefixes are not strictly necessary, because Nimrod can disambiguate type names from proc names in many contexts. We have discussed this in the past and Araq agreed to allow such "overloading" and even submitted a quick and dirty implementation of it if I recall correctly.

My suspicion is that indeed, most people really complain about the need for prefixes, but can't quite put this into words and blame the style insensitivity instead.

[DAddYE]

My suspicion is that indeed, most people really complain about the need for prefixes, but can't quite put this into words and blame the style insensitivity instead.

I agree, it is 90% of the problem.

Second is the readability of a library where in the same file there are different styles.

LAST, but SUPER important is unless your editor is so awesome it can't highlight correctly if you put your code to upper case. That's means that now I'm forced to:

isMainModule, sizeof

Instead of my preferred choice:

when IS_MAIN_MODULE:
      echo size_of(my_pointer)

That said I'm still forced to adopt your convention and style otherwise no highlight :( (unless I have so much time rewrite a vim syntax that should be able or aware about that)

[DAddYE]

another example:

type
  CODES = enum
    GET, POST, DELETE, PUT, PATCH

  STATUS = enum
    OK, FAIL

proc patch(url): STATUS =
  var ok = fetch(url)
  ok

assert patch != OK

Here proc patch got redefined but OK is ... okay.

[DAddYE]

@Araq what about this deal:

types are case sensitive; every thing else not.

Or better:

procs names only are case free everything else not.

If you accept this I promise I'll update with my fingers all the nimrod sorce code.

[gradha]

Where I've said that there are in clojure camel case or underscore?

Nowhere. Where did I suggest you said that? Since I failed to be understood I'll ellaborate:

1. Guy comes and says "Hey, Nimrod is cool but please disable both case insensitive and underscore ignored", later reasoning is because it hurts readability.
2. Clojure is mentioned as good example of readability.
3. Looking at clojure I see just lower case for everything, meaning that the general convention doesn't use case to differentiate items.
4. Here I suggest: if clojure is ok with you not writing Foo, foo and FOO because most people will only use lower case, why is it an issue in Nimrod? AFAICS you can use clojure's lower case style replacing dashes with underscores. So... do it?

Later in your answer you start pointing more to what I was saying, it's consistency that is the problem and not the case insensitiveness. Cool, basically we are talking circles around the same thing. The current standard library features different modules by different people and no hard convention, precisely because you can use any. So this may be problematic for somebody new to the language. We all agree that it would be nice if all the current code used the same style but are short of hands

But look on the bright side! Unlike other languages which are case sensitive and would break backwards compatibility, in Nimrod you can propose a formal convention/style for nimrod's standard library by making a pull request updating doc/apis.txt and if it is accepted start contributing. Here I would say that case insensitivity makes it possible to change, so by all means change the current look, but don't remove the feature.

What about C calls?

When a C symbol is exposed to Nimrod you can use it in any case, so there's no problem with them.

That said I think the argument of this context, case sensitivity sucks big time can be only done by two super anarchic coders.

Get off my lawn!

That's my first time in my life that I'm discussing something like that, isn't that strange?

It's normal because you have only been exposed to case sensitive languages before. Unless you are a fortune teller and discuss things that haven't happened yet in your life.

1 Why you use upper/lower case letters in your language? [...]

I use the rules of the language, because otherwise I'm not writing the correct language. I don't see your point, in German you capitalise each noun, in Spanish you don't, in English you write "I" upper case, always. So what? Nimrod is not a language you use to talk to humans, why does it have to have the same rules? BTW, in Nimrod I only use case for T (type) and P (ref), and only because I inherited from Nimrod's current style, but indeed I may remove all traces of upper case from my code.

2 Why you need to prefix things?

To improve readability. Recently you gave the example of network code and defined a STATUS enum. Most of the network code I write first gets the content then parses it, so you end up having a network status enum and a parsing enum plus maybe other statuses given that much code is a finite state machine. The word status alone is too generic for me so I will always prefix it with some context.

3 If your coworker will decide to not use prefixes at all would be worse than a constant UPPERCASE?

Your hypothetical questions are too much for me, sorry, you don't even mention programming language, I see no point in answering such questions which lead to nowhere.

4 If something like 90% of world codebase today is still case sensitive doesn't sound a bit strange, I mean Nimrod isn't the first language case insensitive, we adopted Ruby and Node.js why we can embrace a such good thing?

First try to explain what we means, I have not adopted such languages, and I don't embrace them as good either. If you look at the history of most languages, they don't exist in a vacuum, they are derivatives of other languages. Let's look at Python (ugh, can't figure out valid syntax link for a wikipedia URL with parenthesis, sorry), it is a derivative of the ABC programming language. That basically means Python is ABC + whatever changes the author thought were improvements. The author didn't start from scratch, think thoroughly about all possible cases and say "Aha! This is what I want for my language". All other languages I've seen are like that too, somebody likes part of a language, but thinks it can be improved, and goes and makes it. Which is what Nimrod is doing here, trying to improve away from case sensitivity.

And talking about Python, do you remember how much bickering and gritting of teeth did it receive for using whitespace as structure, ditching braces? Yet now it seems to be mostly ok, and you start to see more languages like that, Boo, Nimrod and others. So an argument of "90% of world codebase is" only means that the software industry has a really strong inertia and changes slowly, and we aren't writing everything from scratch, so we will always have asm, C, and JS for longer than our lives affecting the global percentage. Maybe in 20 years half of the code will be using case insensitive languages?

5 With an hand on your heart, do you think ruby, node, python will be ever ever largely adopted if they were insensible?

Haha, good one. First, you are presuming they are adopted. In my personal experience I've never seen a job offer for any of those, all I see (now) is C++, C#, Java and ObjC. From time to time I see a python job position, that's it. My meaning of adoption is you get paid to work in that language. So I don't think any of those languages have been adopted, but then, I live in a third world country, so it's not a surprise either.

Anyway, it seems your arguments are just points of view, and at least for me they are totally opposite. However, I know my opinion is just that, so I have no plans on imposing it onto others. That's why I like Nimrod. As you say, in other languages I'm forced to at least make the public exposed API to match the general style, whatever it is, otherwise people (like you?) won't use it because it doesn't conform to their expectations. In Nimrod I'm free to use the one I like and feel most productive in, and my users can use theirs.

Why do you wan't to take away that freedom? As said above, consistency in the standard library can be improved, but that doesn't have anything to do with forcing the language to be case sensitive.

[dom96]

Many people have complained about this over the years, and I am now starting to think that maybe we should simply make Nimrod case sensitive while there are still no big companies that are using it.

It's nice to see that @DAddYE is trying to change this behaviour instead of simply using a different language. However, style insensitivity is a nice feature. I do not see any strong enough disadvantages to warrant a change, except for the fact that people are obviously against style insensitivity and we are not gaining a big enough community as fast as I would like because of that.

I have used Haskell before and I enjoyed the fact that type names are prefixed with an upper case letter. We obviously cannot do that and must rely on prefixes. But are these prefixes really so bad? We get information thanks to them, like whether the type is an object or a ref, or whether the object is an exception. Prefixes are definitely not a thing unique to Nimrod, this is seen in Delphi/Pascal and even C# uses the 'I' prefix for interfaces.

---

I believe that there is a strong argument to be made that for any group of developers working together, a consistent style is a huge benefit. There is no confusion on what a token refers to, there is no metal parse of foo == f_o_o == fo_o. There is less of a chance of mistaken reference between included code bases and your own code bases.

I don't see this specifically being a problem unless someone abuses style insensitivity, why would you write f_o_o when foo is a single word. The point of style insensitivity is that foo_bar should be the same as fooBar. There is not much mental parsing required to see that they are the same identifier.

---

1. Why you use upper/lower case letters in your language? Why you write email with that? Really isn't necessary, if there is a confusion between a human name and a city why u don't simply prefix it with c or h ?

Human languages vary greatly, some don't even have a latin alphabet. Although even with English it is still very easy to understand text when no capital letters are used. But as someone mentioned, human languages are very different from programming languages.

---

I probably reiterated what was answered already and I apologise for that.

Now onto more recent talk.

@Araq what about this deal: types are case sensitive; every thing else not. Or better: procs names only are case free everything else not. If you accept this I promise I'll update with my fingers all the nimrod sorce code.

That may work, but it would also be highly inconsistent don't you think? I think it's better to be fully case sensitive or to leave it as it is.

[zah]

The point is that such tautological prefixes are just a really retro way to solve the problem with discriminating the various identifiers. Modern editors and IDEs should strive to drop the simple syntax highlighting of the past and replace it with semantic highlighting assisted by features such as nimrod idetools. Such an IDE will be able to assign different color/style/font-weight to any category such as local variables, constants, types, functions, etc.

[dom96]

@zah semantic highlighting is a brilliant idea.

[DAddYE]

That may work, but it would also be highly inconsistent don't you think? I think it's better to be fully case sensitive or to leave it as it is.

I don't know. Lock sensitive case on types is good enough to help me to try to convince my friends/coders to try this language. I'm 51% more for a full sensible case, but I'm not experience enough in insensible case languages to say what is bad or not. I saw your points and I agree with some of them so ...

What I know is that:

• Insensible cases is quite blocking for a bit more large adoption.
• Prefixes scare a lot of coders, in many terms, the language looks vintage and mostly (especially in docs) have a poor readability.

I think those two things together prevent a lot the language adoption, at least in my small example all my friends who I talked about are super skeptical to use a language with these two features/anti-features.

Finally, as @Araq knows more than me many languages tried to put the insensible cases... without success, most recent one (according to @Araq) is rust.

[DAddYE]

I've a last purpose more consistent and that allow a bit of free style.

Nimrod sensible case but with snake_case interop!

so: this proc foo_bar() can be called only with foo_bar (the same name) or with fooBar

in that way you can adopt a free style again we can remove prefixes, yep maybe there wont be consistency across the community, but this is like now so not a big deal.

What do you think?

[Araq]

Discussion moved over to the forum.