We will provide a tool to make all your Nimrod code consistent. In fact this tool already exists: nimrod pretty project converts all of your project to a consistent style. For now this tool achieves a conversion rate of perhaps 95% of your code; in particular importc'ed symbols that rely on the way the Nimrod symbol is spelt are not touched. We can make it 100% but that's quite some effort and I don't think it's justified: We are not version 1 and people in general seem to be quite forgiving and willing to update their code.
The naming scheme will be like this:
Note how the naming scheme really only makes the casing of the first character significant. We exploit this fact for Nimrod's classic mode which is style insensitive like Nimrod is now except that the casing of the first character is case sensitive. This way there are no interoperability issues whatsoever between modules in different modes.
Note that the classic mode only exists for lonesome coders who don't plan to publish their code. I feel bad for enforcing a style onto these people.
If you don't like this plan, please speak up now!
And how will T/P types be called then, e.g.
type
MyStruct = object ...
PMyStruct = ... ?
5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase.
I think it would be better to only allow PascalCase for types. That way we can guarantee that anything which starts with an uppercase letter is a type.
8. Write Tcp instead of TCP as camelCase doesn't work with well with abbreviations.
I'm not too sure about this, I am accustomed to writing the acronym in all caps but I can appreciate that it looks odd with camelCase: TCPServer vs. TcpServer. HTTPServer vs. HttpServer. I guess it's fine. Some people may not be so open-minded however.
The common type gets the name without the prefix: Socket, File, Rope; the uncommon variant gets the T/P prefix. Or maybe a Ref```, ``Ptr, Obj suffix instead.
I quite like this. However I worry that some people may complain that it's not 'consistent', but oh well.
5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase.
Hu? This doesn't make sense. Both functions and variables are in camelCase. I planned to allow PascalCase for some OpenGL constants which otherwise clash with proc names. Oh well. However, PascalCase has the advantage that people can write them as ALL_CAPS then in classic mode.
I try to avoid discussions about style, but since you asked for us to speak up: I don't like it.
I prefer snake_case, so the enforced rule invalidates 100% of my source code. But that's not important, with the tool and some tweaking new versions can be made. I'm already enforced to use camelCase in every other language I know, so I don't care about that either, real life sucks anyway.
I don't like the concentration of effort and discussion on such an irrelevant feature of a language, leaving more important features languish. I learned about Nimrod because I was searching the internet for a specific set of features, and Nimrod had them all. Nowhere in my search was style a bullet point. In fact, most code examples I looked at were camel case, so the case insensitivity wasn't even on my radar when I started using it. I might have read on it, but until you start writing code yourself and experience it it's as irrelevant as a breeze of air.
My conclusion is that this change is sad because it is the perfect example of how much bikeshedding can delay, or even fuck up good projects. I only hope the effort pays off in marketing and you attract all the world's programmers you are targeting with the change.
Good luck.
> 5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase. Hu? This doesn't make sense. Both functions and variables are in camelCase. I planned to allow PascalCase for some OpenGL constants which otherwise clash with proc names. Oh well. However, PascalCase has the advantage that people can write them as ALL_CAPS then in classic mode.
I would really love if PascalCase was exclusive to types. That is how it works in Haskell and I think it's great. Allowing it for constants just for some wrappers doesn't seem worth it when we have the opportunity to adopt such a nice convention.
By value-accepting procs, I meant regular procs taking a type without any ref/ptr modifiers.
The point is that if you want to have a universal proc that will work with local variables, garbage collected or manually managed heap values, you just write its normal form proc foo(x: TBar). Then if you happen to use ref TBar somewhere, the compiler will automatically dereference the pointer when you pass it to this proc.
Seeing this about 4 months after most of the posts, was there any sort of resolution?
There is no right naming convention. Ask 5 people and you will get 10 answers. IMHO pick something reasonable and everyone will use it - even what is there currently seems ok. Many people who've used go seem to adopt go fmt as it ends the endless discussions on coding styles once and for all. Something similar here would be fantastic.
nimrod pretty works reasonably well now and made the compiler itself case consistent. A switch --cs:partial has been implemented and we'll get rid of the T/P prefixes.
Speaking from experience now the "compromise" of partial case sensitivity really isn't. I constantly needed to decide whether to Capitalize or not and thus needed a naming scheme and then I want to enforce that naming scheme for every babel package as consistency works best when it's used consistently...
I don't have a strong opinion on removing T/P prefixes and replacing them with something else; I don't see that there is much of a benefit to it, but its hardly the worst thing in the world.
I really don't like case-sensitivity though, especially after being able to live without it for a while again. Simply omitting having to care about other people's style choices works much more smoothly than trying to declare one as what all users of the language "must" use, and is also nice when you need to use a lot of code made by other studios.
Edit: Looking around the net, it seems like Nimrod's style insensitivity is one of those things that gets mentioned quite a bit. For instance at http://www.btbytes.com/notebooks/nimrod.html a reference is made about "bikeshedding arguments" being made completely moot.
Enforcing a scheme does not always accomplish something. Schemes should really grow out of necessity. I actually like the diversity -- of having opengl calls look distinctly like opengl, nimrod stdlib names looking theirOwnParticularWay, and some other crazy libraries just looking crazy. It is good for everyone. Good code is still good code -- it does not need to be told how to behave. Bad code is still bad after you dress it up with a suit and tie, but then it is actually even worse, because you won't notice the smell before you are close. Even then some people are still only thinking about the suit.
The style expressed by the author of a program is valuable in itself. We shouldn’t assume programmers are so stupid/boring that everything needs to look the same. Lack of diversity also makes us stupid imho. Perfect style without sound design is just neurotic, and a lot of programming is just that. So let's not become fascists, at least.
People will always complain about a new and beautiful language until it becomes ugly and predictable, but with a shiny (supposedly, to them) surface... Araq expressed it perfectly in the first post: consistency is a poor mans approach to correctness. It is sad every time something genuinely nice sinks into the swamp of enforced surface niceness.
Nimrod has flexible macros, that are likely to lead to a lot of clever extensions and domain specific languages. Shouldn't these be given some stylistic freedom as well? We don't even know how those features are going to be used.
There should be tools that let you translate between different styles etc naturally... I imagine a standardized way to describe code styles, and a tool that converts between them...
I think the parser is mostly great as it is - i love the controversial case insensitivity and underscores. They also add the benefit of being stricter, and therefore safer. Case insensitivity is one of the many strengths of nimrod, it just takes a while to realize. After a period of getting used to them, i’ve even started to use and prefer T/P prefixes over PascalCase, which i used initially. They're not too ugly, they're expressive, and they are neither distracting nor invisible.
I think Araq has great taste, and should not change the language too much to attract (the wrong kind of) people. Quality before quantity.. It's a tough decision though, with many valid arguments. I think nimrod will grow either way, as soon as some successful projects are using it, which will happen sooner or later. It's good that it moves slowly imo -- A sudden increase in popularity doesn't necessarily improve the quality of a community, and a solid community is important now that the foundations are made.
Just some thoughts.
jbe: +1
I think Araq has great taste, and should not change the language too much to attract (the wrong kind of) people.
At least those too lazy just to change their habits.
in my contribution above, some separated lines of the example code got merged in a single one
Writing
.. code-block:: nimrod
var
n: intyou'll get:
var
n: intThis was in Syntax Cheatsheet previously...
You can edit your post.
Personally, I am not bound to any notation for the pre-defined types, classes etc. (as long as they are uniformly used/enforced throughout the language/libs).
However, I would really prefer if the case for user-defined stuff would be enforced (like with --cs:partial).