The useless parentheses syndrome
Over the last few decades of programming I've seen a strange thing become more and more common: the useless parentheses syndrome. It seems that most computer languages these days have lots of classes, functions, methods, whatever, that have parentheses that perform absolutely no purpose at all. I'm sure I'm not the only programmer who finds this annoying and confusing. On learning a new language it is one of the most irritating hurdles. Does this one take parameters? Or are the parentheses there purely for decoration?
Related to that, the dot manner of indicating that some function relates to a particular group of functions is a very nice way of doing things, and can do a great job of clarifying code, but I find it often gets mixed up with parentheses in entirely arbitrary ways like this:
length(blah)
blah.length()
blah.length
Looking at the bare reference guides for languages it is often difficult to tell how something is used, or why that way and not another. Even python, the most sane computer language I've yet found, is prey to some of this silliness.
While I'm on the subject I have to say I've never really seen any purpose to the ridiculous proliferation of names for subroutines -- functions, methods, objects, classes, modules, calls, subroutines, blah, blah, blah... As far as I can see, they are all subroutines that take and/or return data.
It seems computer programmers are busy building many towers of Babel. It will be a blessing when AI advances sufficiently that computers program themselves and put us all out of a job. We might get some sanity in programming then.
Related to that, the dot manner of indicating that some function relates to a particular group of functions is a very nice way of doing things, and can do a great job of clarifying code, but I find it often gets mixed up with parentheses in entirely arbitrary ways like this:
length(blah)
blah.length()
blah.length
Looking at the bare reference guides for languages it is often difficult to tell how something is used, or why that way and not another. Even python, the most sane computer language I've yet found, is prey to some of this silliness.
While I'm on the subject I have to say I've never really seen any purpose to the ridiculous proliferation of names for subroutines -- functions, methods, objects, classes, modules, calls, subroutines, blah, blah, blah... As far as I can see, they are all subroutines that take and/or return data.
It seems computer programmers are busy building many towers of Babel. It will be a blessing when AI advances sufficiently that computers program themselves and put us all out of a job. We might get some sanity in programming then.
no subject
Java is a pain in this respect especially because you have to bloody cast everything back and forth. Objective-C is a little better, but then you have square brackets instead of round ones.
no subject
length(blah)
Obvious that length is a function and its parameter is blah. This borrows from mathematical notation, f(n).
blah.length()
Empty parentheses signify that the function takes no parameters. If you think they're redundant, the next example illustrates how ambiguous and annoying it is to do-away with 'em.
blah.length
Appears to be a data-structure, IMHO, and it would really confuse me to see it being used as a parameterless function.
IIRC, Pascal makes the distinction between a function and routine (one takes no parameters). I believe there's a big difference in the way it affects the guts of the compiler (and the way it runs, WRT Stack space), but it seems unnecessary to differentiate the two concepts, especially when Pascal tries to be clean and easy to use.
I think the rot set-in when Object Oriented programming was held-up to all as the Silver Bullet. It's not. It's one krufty hack after another. LEt me go a step further by saying that wrapping data and functions together was boneheaded, IMHO. Sure, if you're writing really low-level stuff, go for it (heck, I've written self-modifying Assembly...it wasn't pretty but it worked), but it's foolish and confusing in a high-level environment.
no subject
C static functions are written as C functions, so there's no change there.
If we want a public instance var, blah->ivar would work, althought this is nasty practice, and one should use a getter/setter, so [blah ivar] would work. Note this is also the syntax for a method which takes no arguments.
If a method takes an argument, it would be written something like [blah arg1:val1 arg2:val2 ...].
Static "class methods" are written just the same, with the class name replaced with the object variable name.
The number of brackets is decreased; you are only delimiting method calls within brackets and not argument lists. The bonus of using Objective-C is there's no need to cast back and forth, so you don't worry about brackets with casting, which is really necessary in something like Java.