lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I have developed a visceral aversion to the use of the term "sugar" by the Lua community.

 

Firstly the metaphor is upside down (I did not understand what it was driving at when I first encountered it in PiL). Sugar is one of the basic food groups essential to life, but pretty unpalatable in its raw state. If anything sugar is analogous to the byte codes while the essential constructs would be the fruit, vegetables and honey which make the sugar palatable or the language usable for human beings. The extra frills that make the language pleasurable to use would be analogous to fancy restaurant ingredients like truffles and garlic, but to ease the transition, let us call them "pavlova" from now on!

 

Secondly, the way "sugar" is deployed is  the rhetorical tactic of "political correctness" - rather than debate the merits of a feature or proposal in terms of its practical consequences, just label it with a disparaging term that no "right thinking" person could possibly  favour eliding right over the question of whether the label is actually meaningful. When I first looked at the Lua sources I expected to find something like the C pre-processor or the early implementations of C++: a text processor that pre-digested the pavlova and emitted honest peasant food for the parser to further digest into bytecodes. This does not exist: the pavlova and the peasant food are digested simultaneously in the same stomach. So the distinction is actually a tendentious conceptual one imposed by the critics in a way intended to pre-determine the argument they are trying to make.

 

An argument can be made that, say, "function foo() ... end" is *conceptual* pavlova while "foo = function() ... end" is nearer to the structure of the bytecodes and hence more conceptually honest. But at the level of *syntax* both are equal and which is preferred is a matter of taste. If we follow the argument to its logical conclusion, we should all be programming directly in bytecodes!