lua-users home
lua-l archive

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

On 28/06/2011 14.27, Shawn Fox wrote:

On Mon, Jun 27, 2011 at 5:25 PM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br <mailto:lhf@tecgraf.puc-rio.br>> 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 other people.
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 that. 




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
else's code.


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
problem
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
my suggestions,
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 shouldn't complain. 

>... 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
VM myself.

 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
contribution language.
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 scope.
So long for the supposed belief of the authors thinking that Lua has reached perfection. 


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

Best Regards,
-- Lorenzo