 |
lua-l archive |
|
|
||
|
On 9/22/2010 7:42 AM, Ryota Hirose wrote:
Hello, Lua Hackers,
2010/9/21 KHMan wrote:
I'll leave out (a), since it is so subjective. For (b) and
(c), what kind of savings did you see for your embedded
system? Was it significant, given the available capacity? For
us on the list, can you provide us with ballpark
specifications of the embedded processor? (The last bit is
getting OT, but it is interesting to find out if someone is
using a previously unreported-on-the-list embedded processor
for Lua...)
[snip]
The code efficiency is not my reason to write a patch. It is a
general feature of a ternary operator. In the wiki page, there
are many tricky solutions about a ternary operator, using table or
function, but all of them are commented as 'not efficiency'. I
think, "If you interested in efficiency, why do you write a patch?".
Thanks for replying. Of course, we must respect confidentiality. Most MCUs that can run what I assume is 32-bit integer-based Lua are likely to have quite a lot of program memory, or the syntax is not likely to be used a thousand times in the code -- so I often suspect that it is a win for pure bean counting (if any at all) and not a win for sensible engineering.
I am neutral about merits of syntax -- there are too many to choose from and I generally only use what's available. I was only rather surprised when the discussion turned to counting bytecode. So the part of the discussion about bytecode size was an unnecessary exercise, as you agree in the above. Perhaps the point was there to make up the numbers -- it's better if used only as a Power Point bullet to soothe managers. Looks like it is mainly because the programmers who call the shots want it.
For the official Lua, I think a ternary operator is not necessary. I’m not well versed about Lua's ideology, but I accept that Lua doesn't have an incremental operator (++), so I accept about a ternary operator, too. (But OLD PROGRAMMERS don't accept it...).
Yes, the antics of senior engineers (as in your case of embedded development) are also often idiosyncratic and dictatorial and we have to grin and bear it -- I guess they have earned the right to be like that. Unfortunately such practice is sometimes a lot of cultural traditions rather than technical merit, so it is a given that this kind of discussion will devolve into a long and winding snake of a thread that seems impossible to kill.
I am aware of and agree with your position about your patch; I disagreed on the bytecode size discussion.
I think I have made this thread gone on long enough, I apologize for that, I will end here.
Thanks, -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia