Why did people even consider using this shitty unreadable method of separating words inside compound identifiers? Why the fuck is it recommended style for Javascript, Haskell and other half-decent languages? Why does Python use it in some of its identifiers (but not in all, because it is inconsistent shit)?
Why won't underscores do (or even real spaces for some languages)? Makes code much more readable.
Name:
Anonymous2012-08-13 10:51
don't know either.
probably mob effect: the built-in standard classes use that, so every other class is mimicking that, and it all goes shit from that
>>2
It is good practice to use the style which the standard library uses in your programs (if it follows any sort of consistent style, i. e. not PHP or Perl, as their libs all use a multitude of styles; Python has inconsistent standard library as well, but it is greatly alleviated by the popular PEP-8).
However, why would any language designer conscientiously choose the worst possible style for his new (or even not yet written) standard library?
>>4
Shit because lispers for decades fail to move on to having better syntax which allows fucking infix epressions. Ignoring the infix minus possibility, - is still no better than _ as a separator.
By the way C (and, by extension, C++, D, Jewa, C#, Javashit and all other shit languages with syntax derived by C, except Perl) could use real spaces inside identifiers, because using two alphanumeric identifiers next to each other is illegal syntax anyway.
E. g. there is no valid C construction where you can write foo bar. It should have some sort of operator or syntactic token between them.
In Perl it is impossible because you can omit parens during function calls (like in Haskell after which Perl was modelled).
Compare this:
Q.Interface.prototype.defaultValue = Q.makePropertyAccessor('__defaultValue__');
Q.Interface.prototype.restoreDefaultValue = function () {
this.value(this.defaultValue());
};
and
Q: Interface: prototype: default value = Q: make property accessor('__ default value __');
Q: Interface: prototype: restore default value = function () {
this: value(this: default value());
};
This was the code that I was looking at at the moment of writing, and it's not so bad. But consider how many identifiers like addContainerToCollection are out there in other places.
I also replaced the dot with semicolon because dot looks silly in the upgraded syntax. It is not used anywhere else because JS does not have goto labels and does not support Python-like array slices, and the goto-like labels for case can be replaced with something more sensible.
Even jabba looks much nicer and actually somewhat readable:
namespace Abstract Factory
{
public interface I. Button
{
void Paint();
}
public interface I. GUI Factory
{
I. Button Create Button();
}
public class OS X Button : I. Button // Executes fourth if OS:OSX
{
public void Paint()
{
System: Console: Write Line("I'm an OSXButton");
}
}
...
Since we liberated . from being a property/method separator token we can use it inside compound symbols to denote abbreviations. Yes, it looks a bit more verbose, but this kind of benign verbosity offsets the grotesque ugliness of jabba's own intrinsic verbosity. I find it a successful example of fighting fire with fire.
Name:
Anonymous2012-08-16 14:27
>>12
The dot character is used very often and it is one of the easiest syntax characters to type in dvorak, so replacing it with the colon is retarded as the colon is awkward to type on both dvorak and qwerty.
>>3
Good practice to whom? IMHO, using the same capital letter style like in the standard lib(s) is just a game of luck not to collide with any lib-defined symbols. E.g. in C I wouldn't recommend to anybody to write function names / global vars all lower case because that eliminates possible clashes since C stdlib symbols are lower case.
>>10
E. g. there is no valid C construction where you can write foo bar. It should have some sort of operator or syntactic token between them. typedef int foo;
foo bar;
if intpos; char in string(c, pos, "0123456789ABCDEF"[@0]) orel char in string(c, pos, "abcdef"[@10]) then pos else
-1 fi
Algol 68 uses spaces in identifiers. charinstring are three bold symbols (a type, a keyword, and a type), but char in string is a single identifier (a standard library procedure).
Name:
Anonymous2012-08-16 23:25
>>23
Nice. Sometimes I wonder why do we have over 9000 different shitty languages if LISP and Algol 68 already offer us everything we will ever need.
>>24
I agree. I should file a complaint to my university and asking why we learned python, c++, ruby and java the first year instead of Algol 68. I like Algol 68. Any good modern compilers?
>>19
C has been around so long that you can often guess a programmer's (or program's) heritage based on what convention is used. AT&T devotees and Linux kernel hackers prefer all lower case, separated by underscores. The MIT/X11 guys, GL programmers, and C++ refugees mostly prefer camel case. Camel case with all uppercase typedefs (especially for pointers) is a sure sign of a Windows programmer...