Hi there,
First of all, before someone starts a flame with me, I want to say that I'm not against the free style case/underscore, I'm using Nimrod and I find it an awesome language.
The problem is that IMHO this insensible style + prefixes scare a lot of people and impede Nimrod to grow.
In my small world every coder I talked to said: _I'll never use a language without sensible case without giving it a chance.
We should all agree that around 98% of code base are written in a language that is case sensitive. I think a similar percentage is for servers.
I'm not interested in knowing what is best or worth, everyone has his own preference and I respect it but we should look at the reality and try to wish the best to Nimrod.
Dave
The problem is that IMHO this insensible style + prefixes scare a lot of people and impede Nimrod to grow.
I guess not. Though slowly, more and more people are coming here showing their interest. As you may have seen, Nimrod has no problem calling code written in other languages. Programmer's preference in writing code in his own style without interfering with other programmers' need to use his/her code through modules is more important IMHO. The code might be written in one style, but the user could call it with another one that he/she prefers. I would smash people posting modules in C with a hell lot of macros because the convention is TO_WRITE_MACRO_THIS_WAY and it hurts my fingers to type.
We should all agree that around 98% of code base are written in a language that is case sensitive
It's not a reason to follow them and not all programmers (including me) like case sensitiveness, changing that would mean changing the very basic concept of the language and it would break backward compatibility A LOT.
but we should look at the reality and try to wish the best to Nimrod
The reality is that Nimrod is case insensitive and that's one of the best thing Nimrod has. Some other popular languages are case insensitive, so it's not a problem that makes Nimrod difficult to grow (anyway, does Nimrod have difficulty in growing? I don't think so).
The start of the discussion is here: https://github.com/Araq/Nimrod/issues/521
There is a lot to say about this topic. So I'm starting with an excellent blog post about it:
"The problems of camel case come from using capital letters for word separation. This interferes with the other uses of case in natural language. The problems are amplified by the brilliant idea to assign even more semantical payload to case: functionsLookLikeThis, but ClassesLookLikeThis, etc. Let's look at some examples.
English has words like TCP, DNA and WTF. Should a TCP socket class be called TCPSocket or TCPsocket? What about a TCPIPSocket? What if we need a tcpOpen method - should we call it TCPOpen, like a class, to preserve the natural case of an acronym, or should it be TCPopen, so that the lowercase "o" conveys the fact that it's a function?"
The problem is that IMHO this insensible style + prefixes scare a lot of people and impede Nimrod to grow.
I agree. These are 2 different things however: The prefixes come from the desire to distinguish between value and reference types. The style insensitivity has little to do with it except that things like var parser: Parser produce way more clashes thanks to it.
anyway, does Nimrod have difficulty in growing? I don't think so
I disagree. I think we have problems in growing and the excentric style insensitivity certainly doesn't help. Somehow it's very hard to convince programmers that a consistent style can and SHOULD be automated. People prefer to be slaves to some petty coding conventions instead.
changing that would mean changing the very basic concept of the language and it would break backward compatibility A LOT.
I wouldn't say it's a "very basic concept" of the language.
When I designed Nimrod, I chose between 2 options:
I chose (a) especially since an enforced naming convention has lots of problems. Abbreviations for instance really are problematic for case sensitivity. Would I pick (a) again? Hell no. I still think that (a) is technically superior and consider Time time = time(TIME) borderline programming . But (b) is what most people want today. You know, the guys who think there is a high negative correlation between "clean code" and "bugs". (I don't think there is.)
The style insensitivity has little to do with it except that things like var parser: Parser produce way more clashes thanks to it.
I should agree it is a common pattern but not so much, I want to show you a bit more what insensitive case means:
TCallingConvention* = enum
ccDefault, # proc has no explicit calling convention
ccStdCall, # procedure is stdcall
ccCDecl, # cdecl
ccSafeCall, # safecall
ccSysCall, # system call
ccInline, # proc should be inlined
ccNoInline, # proc should not be inlined
ccFastCall, # fastcall (pass parameters in registers)
ccClosure, # proc has a closure
ccNoConvention # needed for generating proper C procs sometimesFirst a case sensitive programmer is scared about prefixes and thus we should agree about one thing: instead to write: cdefault, ccstdcall, ccsyscal why we had to capitalize them? I guess readability.
An argument can be, why I'm creating a Type with the symbol CallingConventions and I should pick T prefixes? I said to the compiler: please create me a type enum and call it with the symbol CallingConventions. Why should I "re-say" T(ype)CallingConventions ?
Isn't more cheap, idiomatic and clear?
Why a Type->Enum->FastCall should conflict with a procedure called fast_call ?
I mean I can have tcp.fast_call(..args..) and some where else tcp.kind == FastCall ...
I don't see why it should be worse than tcp.kind = ccFastCall. If I've a good memory cc is CallingConventions, sorry TCallingConventions ...
We, sensitive case aware we have generally one rule. I'm calling a type/object? 99% starts with capital. I'm calling a method/procedure? 99% should be lower. That's it. I don't need to care and browse what the coder XX decided to use as their prefix rule. (yep I know that languages as go use Capital for public functions but again is 1 rule)
This translate to everyday usage means one thing, in order to avoid confusion you'll need to add prefixes everywhere also where not necessary.
IMHO, in that why nimrod look quite old instead to show it's awesomeness and freshness.
I'm myself a BAD example, I found the language 1 year ago, looked fast at the code and ended up with: okay another crap from a guy that is nostalgic about 70'
I was wrong I know but only now ...
Consider also that the habit of put prefixes is also translated in the laziness of the developer that lost totally the expressiveness.
So is common to see: TX, nkN, TNx and so on... and I'm: WTF is that...? This yep can happen in others languages too, BUT in nimrod seems much more frequent.
Why a thing can be simply... simple?
# http module
type
Request* = object
url: string
kind: Kind # type is not allowed
params: seq[string]
Kind = enum
Get, Post, Put, Delete, Patch
proc perform (r: Request) =
# do some ...
proc send_request (request_url: url, request_type: Kind, args: varargs[string, `$`]): Request =
var r = Request(url: request_url, kind: request_type, params: args)
r.perform()
return r
proc get* (url) = sendRequest(url, Get)
proc post* (url) = sendRequest(url, Post)
proc put* (url) = sendRequest(url, Put)
# ... etc
IMHO this kind of code is quite common but again why I spent time to define Get, Post and Put and assign them a Kind Enum if the compiler doesn't care about my name?
Honestly I feel more _monkey and adding kGet, kPost, kPut, kDelete, kPatch than use a proper capitalized version. Looks like "repeat yourself".
Alternatively the compiler should DENY at all any call to Get, Post, Put (enum) alone and use instead a full expressive-prefixed way: Kind.Get, Kind.Post etc... that is more clear (to me) than find in my code k,x,y,z every where.
Also in order to avoid prefixes we should consider a module system that act like Python or Scala or Node and many others.
Avoid implicit enum symbol and use like the mentioned example kind.Get
Everything enclosed by a namespace instead of a customized prefix. So 1 pattern defined by the compiler.
Finally we should (sadly) consider what is the common feel about an insensitive language: that is windows crap. It reminds me visual basic. Yes is like index that start from 1 in Lua.
Before start in a flame I'm not saying that I think the same but that is quite common to hear, at least it happened to me.
We, sensitive case aware we have generally one rule. I'm calling a type/object? 99% starts with capital. I'm calling a method/procedure? 99% should be lower. That's it
You're coming from one specific coding style, which not everybody uses, why enforce it? I don't like camelCase at all, even worse for underscore_separated_identifier, because my background is Pascal which uses PascalCase, for anything except prefixes in enum values.
kind: Kind # type is not allowed
This example really shows the abuse of case sensitivity IMO, which is one of the reason I hate it. You refer to the same word (in normal people sense) with different meaning. In my college, either as student or lecturer assistant I always find people writing exactly like above, and it's confusing. Don't know how many (sometimes difficult to search) compile errors just because of it.
Alternatively the compiler should DENY at all any call to Get, Post, Put (enum) alone and use instead a full expressive-prefixed way: Kind.Get, Kind.Post etc... that is more clear (to me) than find in my code k,x,y,z every where.
Now this one is fine and I already use it for languages with such a support.
Finally we should (sadly) consider what is the common feel about an insensitive language: that is windows crap. It reminds me visual basic. Yes is like index that start from 1 in Lua.
Normal people searches something ignoring its case, only programmers with case sensitive language background do know exactly what case the filename or something they search for (I use Linux, but I turn case insensitive search on by default). VB I don't care, it's a crap. Index is a concept, and it's been explained in Lua's wiki why 1 is chosen. Pointer + Offset is another concept, simply don't think with another when dealing with one.
You're coming from one specific coding style, which not everybody uses, why enforce it? I don't like camelCase at all, even worse for underscore_separated_identifier, because my background is Pascal which uses PascalCase, for anything except prefixes in enum values.
I learn to adapt my coding style to different languages, main stream languages are all of them case sensitive, I'm reporting my thoughts and my difficulties. Honestly I don't care snake or camel, the important IMHO have a concise standard readable code.
Thus I force myself to use the "standard style" for my target language.
This example really shows the abuse of case sensitivity IMO, which is one of the reason I hate it. You refer to the same word (in normal people sense) with different meaning.
First this is how more than 90% of languages works, that doesn't means that is good indeed, but means that outside there are 90% of coders that learned that "thing". For me i.e. has more sense than put x,k,l,m,n etc... prefixes.
Index is a concept, and it's been explained in Lua's wiki why 1 is chosen. Pointer + Offset is another concept, simply don't think with another when dealing with one.
Yea I know that and makes sense, especially for the target audience (when was built) but again me and many others find that pretty annoying that's why if you'll read open source project in lua people prefer to not using it at all (other than the fact there are different idiomatic ways to do that).
For statically-typed languages, an AST-aware IDE takes care of extra typing.
Most serious devs will probably be using: vstudio, VIM, emacs, textmate, xcode
Couldn't get Aporia to compile and the issue was closed without resolution, so I'm very hesitant to invest in nimrod any further.
Couldn't get Aporia to compile and the issue was closed without resolution, so I'm very hesitant to invest in nimrod any further.
I don't know why it was closed or who closed this issue, perhaps because it was a duplicate? Issue #342 is still open and known. As you noticed it's also very puzzling. ;-)
It's hard to fix for me as I don't own a Mac anymore.
Rather than forcing a language to follow the mainstream rule, I suggest following what the language author has chosen. That would make you adaptable to any language regardless their coding style convention.
Well if a guy can handle Clojure (a Lisp!), Ruby, JavaScript, C etc. but struggles with Nimrod's way of doing things, this really worries me.
Finally we should (sadly) consider what is the common feel about an insensitive language: that is windows crap.
Case sensitivity however is this Unix crap and the de-facto default of all lowercase filenames in Unix is another symptom of the case sensitivity disease.
Couldn't get Aporia to compile and the issue was closed without resolution, so I'm very hesitant to invest in nimrod any further.
I assume you are referring to the issue you submitted on the Aporia repo? The reason I closed it was because I assumed it was due to you using a non-git-head version of the compiler. You could have reopened it at any time. I didn't reopen it myself because the actual issue is with the Nimrod compiler not Aporia.