lua-users home
lua-l archive

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


I tend to think same that lisa (just maybe far from this upset level
yet). 

Decision delay to select a new tool is short in industry. Open source at
least makes evaluation easier and maybe gives a little more weight to
technical motivation to select a tool (besides cost, training issue,
maintenance costs). So not having a visibility on identified key feature
is killing especially when there is still competition (other script,
proprietary). 

Now I understand that asking "why you will need it" helps when it comes
to really chose how to implement it, but it shall not let the feeling
that this is starting to be a undefined length path to convince that
this is really needed. Else you shall rather say, why I don't want it so
far (eventually with some copy paste, but a faq would help!). Up to a
certain level of noise (or user patch) for a particular request, this
shall be very documented.

To solve this particular issue, I've patched lua kernel, this is not big
effort to do it even as an optional feature lua_configurable, to even
not disturb those convinced they don't need it and don't want at all to
pay the code footprint increase. 

I've started from an existing patch, just maintained it:
- selected syntax. it could'nt be fully reused xor was '#' in patch, so
I've used '^|' not sure of the acceptance, neither of the naming of
metamethods I did, so anybody could reuse patch and then select a
proprietary syntax... 0-- made operators overloadable. 
Overhead in lua footprint is around 4ko if I remember right on my linux
(out of 146), when I balance that to the energy needed to say I really
need it... 

This is not fully satisfying me because now I have to maintain it. I
don't mind to, but my employer does because dependency upon me is
increased besides training cost of using new exotic language. I'm also
bound to a limit in bit size. Although I admit I can go to a userdata
type (provided that I can at least overload some operators), I'm not
sure of starting from how many bits, I want to go to userdata.

PS: well maybe another topic. But what are real constraints of people
quoting lua footprint as a key (not only nice) factor to select it (I
guess reading that, it only means rom size space constraints... I only
once saw a mail from some one needing 32Ko as far as I remember). Can
they quantify from which size the footprint breaks it (and if gc or
parser is required)? Maybe this will show the real constraints on
language design, and margin which can be used...

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Tomas
Sent: Thursday, September 21, 2006 1:17 PM
To: Lua list
Subject: Re: boolean operators

 	Hi Lisa

> Why shouldn't we want boolean operators in Lua? Who're you to define
whether 
> we need them? Unless you're up their with Babbage or Turing, you
certainly 
> aren't in any position to dictate, which is why they're one of the
features 
> commonly hacked into Lua. Functions just don't cut it when you need 
> performance.
 	Well, they are the guys who design and implement Lua.  And,
as being theirs, I think it is up to them decide what features should be

there!  I think they're trying to listen to the comunity.

> I'm getting exceedingly sick and tired of the way us users are treated
like 
> children. Just the fact it's so commonly requested ought to be enough
reason 
> for them to be added.
 	I think that if they add each requested feature anyone asks
for, they would be treating us like pampered children.

 	Tomas