[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Possible enhancements for Lua 5.2
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Tue, 28 Jun 2011 19:20:42 +0200
On 28/06/2011 14.27, Shawn Fox wrote:
On Mon, Jun 27, 2011 at 5:25 PM, Luiz Henrique de Figueiredo
<email@example.com <mailto:firstname.lastname@example.org>> wrote:
> but that isn't a reason to not add them to the language itself.
A language does not grow in a healthy way by adding things for which you
cannot find a reason to omit.
I'm not surprised to hear this argument from you as I've seen you post
similar garbage before. Frankly your reply is offensive and not at all
constructive, rather that making such a childish statement, in the
future please give a valid argument as to why a suggestion is not a good
idea and you'll get a civil response from me.
Sorry, but to me that was a very civil answer to your request. Now you
ask a valid argument to reject your request, but it was you in the first
place that gave no valid reason to accept it in the first place: there
are LOTS of things any of us would like to see added to the language,
but the degree of usefulness is highly relative.
You said: "that isn't a reason to not add them to the language itself",
but that is not a reason to add them either.
If you value the small footprint of Lua, as most of us do, you should
think that your favourite feature could be not the favourite feature of
For example, If I were asked "choose a new feature for Lua as you wish",
I wouldn't choose what you proposed, since I have different needs. I
would largely prefer some support for custom operators and some more
support for DSLs.
The criteria for which a language change proposal have been discussed to
death on this list. If you have lurked enough time and searched the
mailing list archive enough times you should now.
This doesn't mean that many of us sometimes don't try to convince Lua
authors to add/modify something, but you should give a valid reason why
that feature could be useful *IN GENERAL*, not just for your use case,
or for limited use cases.
"why not" or "language XYZ has it" are rarely a good reason, especially
if stated in a perentory tone as you did. If you *really* want _Lua
team_ to do some work for you, you should give them enough reasons to do
There are many very good reasons to add an API or some other standard
way to cap memory usage. The obvious one being that anyone who needs to
cap memory can do it by just calling the already existing API instead of
reinventing the wheel or searching the internet and then copying someone
As I said, there are TONS of thing cannot do out of the box.
While it may be obvious to you that creating a custom
allocator is a potential solution, that is not at all obvious to someone
who is new to Lua even if they are a highly proficient C/C++
programmer. In my opinion, the need to cap memory is such a common
You assume your model fits to anyone. It seems you work in an
environment where users my abuse the memory managed by Lua. Try to
think, for example, as an embedded system engineer: would you like to
waste some kb of precious memory for a memory capping feature you'll
never ever use?
that it ought to be supported already without having to use a
custom allocator or modify the Lua source code itself. Certainly you
can argue that I am an idiot and my opinion is wrong, but please provide
evidence and reasoning behind your statement or do not reply at all if
you cannot do so.
As Steve D. said, you see evil where there is none. He simply gave an
almost standard reply to a "why not" argumentation.
Please, try to remember that, although we all speak English on this
list, you still are talking with people all over the world, so you
cannot assume intonation from written word alone. I wouldn't want to
bother the list with non-verbal communication theory stuff, but please
try to stick to the written words without trying to infer anything more.
You should know a person very well to infer things easily understandable
when talking face to face (such as subtle irony).
That's why emoticons were born, they are not only silly smiling faces
used by kiddies.
I've seen this solution proposed before, I do read a high percentage of
the posts on this list... but this does not fulfill the requirement that
was stated very clearly if you had only bothered to read what I had
said. It also requires access to the debug library which may not be
available in many environments. If you are going to so casually dismiss
he hasn't dismissed your suggestions, he has dismissed the way you
motivated them ("why not")
at least propose a valid solution to the problem.
I assume he is not paid for solving your problems or give alternatives
to your proposals. If he does, you should be grateful, otherwise you
>... isn't Lua supposed to be simple and easy to use?
This seems sarcasm. As I said, please, tone down.
Please tell me why you believe Lua has reached the perfect level of
capabilities and does not need to evolve any further,
I never heard something like that coming from Lua team. You put words in
the mouth of others.
> and use arguments
other than telling me how to do something by writing a lot of additional
code. By that argument we don't need Lua at all
I don't agree at all. Even if Lua stayed as it is for a long time, it
could be used for many useful purposes. The proof of that is the
evolution of Lua and the extremely low bug ratio of the codebase.
>since I can do anything
with C or even assembly language already, and certainly we do not need
Lua 5.2 since there is nothing in Lua 5.2 that I can't already do with
Lua 5.1 either directly, with C functions, or by modifying the Lua 5.1
From what I understand, one of the primary design goal behind Lua is to
keep the language small and easy to use, thus things such as UTF8
support, regular expressions, etc have not been added to the language.
Certainly I can accept this argument, although I do not agree with it
completely as it is also possible to have build options which allow
these features to be removed in constrained environments. You could
also argue that you do not have the time/resources to add such features,
and I can certainly understand that as well. If that is the case then
perhaps it is time for PUC-Rio to start accepting code contributions
from others instead of maintaining Lua as a open source / closed
It's not up to you to decide what Lua team must do with THEIR project.
If someone wants, he/she can already do almost whatever he/she wants
with Lua code. It is MIT licensed, so you could fork it and start your
dialect with all your favourite features.
I am 100% sure that there are many people who
read this list who would be very happy to contribute code that becomes
part of the standard Lua language and there are certainly several people
at least who have been around long enough that they would be able to
continue to provide support for their contributions.
As I said, fork your dialect and try to manage all the volunteers'
efforts into a working classic open source/open development project.
Nothing wrong with that. What's wrong is that you try to pressure people
to do what you want (or at least, that's what I get from your message).
The point of all of this being that when proposals are offered that are
small in scope and make the language easier to use the person who
proposed such a feature deserves a response which is cordial and
correct, not a response which is neither.
The reply _was_ correct. As for cordiality, it is a bonus, not a right.
You shouldn't assume Lua team have infinite time to reply extensively to
every message that proposes a change in the language.
In my experience *they are exremely cordial* and also sometimes find
time to answer questions from newbies if the community doesn't get to
the point. Try to achieve that from a Sun (now Oracle) SDK developer
(ha!) or from a Windows XP developer (ha!ha!) (and you PAY for Windows
XP), unless you have a mega$$$ support contract!
Many times such requests are handled collectively by "senior" list
members, which have the patience to explain to newbies why this or that
feature would probably not be accepted.
Lua team usually read all those posts, even if they don't answer to all
of them, and sometimes they change their mind according to what emerges
from the discussion. It has happened even in the recent discussion on
"goto and labels": they changed their mind on label syntax and on labels
So long for the supposed belief of the authors thinking that Lua has
For all those reading this
far or those having skipped to the end, I apologize for my ranting and
do not mean to pollute this list with such nonsense, but for some reason
I could not let this one go without a response.
so did I