Keith Devens .com

ick. multiple syntaxes for the same thing are not 'sugar' they are syntactic sours. Talk about asking for widely divergent coding styles and high WTF factor in language design.

Python is generally clean. Allowing operator overloading was a real mistake in my opinion. Same with C++: very high WTF factor.

I disagree strongly. As for the WTF factor, people will still generally use the syntaxes they're comfortable with for a certain concept. People generally won't use foo('bar') over foo['bar'] when they want array access, but I think you should be able to. This is actually how BASIC does array access IIRC, since accessing an element of an array is essentially a function of the key to the value.

And really, stuff like this already exists in languages like Javascript... foo['bar'] is the same as foo.bar. And in languages like Perl, Ruby, and Eiffel, you can already call no-argument functions or methods without parentheses, which gives them the appearance of being properties. Rather than this leading to incomprehensible code, people use whatever's most natural in the situation and I think it works out pretty well.

Also, I'm surprised you're against operator overloading. To me, a clean and extensible syntax is key to a comfortable language. Python's operator overloading has allowed Python to have some of the most natural XML APIs, for instance. The alternative is to have long-winded method names like you have in Java, and it makes it impossible to develop structures that behave similarly to built-ins. I think allowing operator overloading leads to a much lower cognitive load as well, since you're able to use built-in syntax for familiar operations, rather than having to make up and remember your own method names for things.

(Languages like Haskell even let you define your own operators -- potentially ones that don't exist in the base language -- and I think that's wonderful. It's obviously something to be used carefully, but if it lets you more comfortably represent your problem domain I'm all for it.)

I've written about this before in the context of Perl.

I'm in two minds over operator overloading. On the one hand, it leads to incredibly expressive and natural feeling APIs. On the other hand, it has the distinct disadvantage that looking at a piece of syntax no longer gives you a fair idea of what it does. Take the following code for example:

obj.name = 'Simon'

You would expect this to assign the string 'Simon' to the name property of an object. BUT... if the object happens to be an overloaded XML wrapper (like XMLTramp) you'll actually be altering the structure of an in-memory DOM style object. Even more confusing, if it's an SQLObject instance the line will have caused an UPDATE statement to be executed against a database table.

In short scripts where you are the only maintainer this is unlikely to cause a problem. In big applications where multiple people are maintaining the code this could get very confusing - especially if you are using SQLObjects and XMLTramps in the same code snippet.

Operator overloading is very neat, but it can have a serious impact on code understandability if used carelessly.

My Response (since that blog wouldnt let me post it):<br />
Operator overloading (or even better definition ala LISP) is wonderful. The problem expressed above about operator overloading is not a problem with the concept but of the implementation. Any sufficiently powerful language construct can be horribly abused. If you don’t want to use anything that is 'dangerous', then you are left with the option of only using Java/C# so that I can always tell exactly what everything does. Unfortunately I don't find these languages terribly expressive. I would much rather work in a more powerful (dangerous) environment that allows me to express myself in as many ways as possible.

The nice thing about the javascript syntax of obj['item'] is that I can retrieve lists of every item on an object and then loop through all of them looking for all methods or what have you. This is much easier/cleaner than eval('obj.item'). The dot operator is nice when coding directly because its one character instead of four.

After working in C# for a very long time, my biggest complaint with the environment is that it is too safe. It's so safe that I cannot express what I want the program to do without coding around any particular problem and casting 6 or 7 times.