Re: Proposal for a standard way of defining custom operators in Lua

[Leo Romanoff <romixlev@...>]

> Von: Duncan Cross <duncan.cross@gmail.com>
>An: Lua mailing list <lua-l@lists.lua.org> 
>Gesendet: 16:02 Mittwoch, 24.Juli 2013
>Betreff: Re: Proposal for a standard way of defining custom operators in Lua
> 
>
>On Wed, Jul 24, 2013 at 2:45 PM, Fabien <fleutot+lua@gmail.com> wrote:
>> Fancy syntaxes tend to improve your ability to map your own thoughts onto
>> code, but make your code more impenetrable by anybody else.
>
>This is very true. Lua, sometimes controversially, chose to use
>keywords instead of symbols to delimit blocks ('then', 'end' etc.) and
>for boolean operators ('and', 'not' etc.), and has so far resisted a
>short-form/"lambda" syntax for function definitions. Whatever you
>think of this, I think the intention is clear: encourage code that is
>more immediately readable to people who are not already very familiar
>with the language (or perhaps code in general), at the expense of
>information density.
>
>Now, some people think it's worth slacking off a bit on this
>philosophy, but this suggestion is a complete reversal: it encourages
>code where, not only do you have to be familiar with the language to
>make sense of what a chunk of arbitrary Lua code is doing, but you
>have to be familiar with the author's personal set of favourite custom
>operators. (Also, what happens when you get to the situation where you
>want to use two third-party Lua libraries, written by two different
>people, each with their own ideas about what the same operator symbol
>should do...?)


I understand your concerns. 

I also have observed many times this kind of discissions about user-defined operators vs keeping it away from the language because they potentially could lead to a code which is not understood by anyone, since noone knows the semantics of those operators or their implementations in a specific context. I've seen those discussions for C (e.g. Linus explaining why Linux kernel does not use C), for Java, for Scala and many other languages. 

At the same time, we all know that pretty big systems were implemented using languages supportting custom-operators and/or operator overloading (e.g. C++, Scala, etc). And in my humble experience, in many cases the code looks nicer. 

For me, user-defined "operators" vs lack of them sounds like a discussion about style and it usually heavily depends on the personal likings.

I totally agree that when this feature gets out of control and everyone starts implementing his own cryptic operators, then it may lead to a disaster. But I also think that any feature of the language, when it is misused, could result in  a lot of problems. And I'm not sure that operaor overloading specifically is very special in this regard. After all, many people seem to like Moonscript & the like due to a new syntax and operators that it introduces, which may be an indication that current syntax of Lua is a bit too verbose (or too low-level, if you wish) for some people. Also many people programming in Java (which is also intentionally a bit minimalistic when it comes to syntax, because Sun wanted Java to be a "C for JVM") are now trying to escape to more expressive languages running on JVM, e.g. Scala, Groovy, Kotlin and many, many others. Of course, all that happens due to lack of expressiveness or too much verbosity in the original language, and
 not due to user-defined operators only.

-Leo