lua-users home
lua-l archive

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


This looks like a story I've heard:

This guy used to work with Pascal, then he started to work on a C project.
The first thing he did?
Create a header like this:

C2PAS.h

#define BEGIN {
#define END    }

#define If         if
#define Else    else

#define Int    int

and so on...

So, the function

int somefunc()
{

... some code

}

would look like

Int somefunc()
Begin

... some code

End


He was trying to modify the syntax of C to be more similar to Pascal.

This is wrong, IMHO!

If you are working on a new language, you must write your code on that language!

Lua it's a great language, but you must think in Lua when writing your code, not try to do some "cosmetic surgery" to make Lua seen like C++.

And if they claim that "we made a series of incredible performance enhancements to the execution speed and memory management of the interpreter", it would be a great contribution to the comunity if they shared at least some os these "incredible performance enhancements ".

Lua became this great language due not only to the bright development team, but in part on the community contribution.



Just my 2 cents...


----- Mensagem original ----
De: Glenn Maynard <glenn@zewt.org>
Para: lua@bazar2.conectiva.com.br
Enviadas: Quinta-feira, 15 de Março de 2007 1:42:21
Assunto: Re: Bookworm Adventures Postmortem


On Wed, Mar 14, 2007 at 08:59:43PM -0300, Luiz Henrique de Figueiredo wrote:
> "We heavily modified the Lua interpreter to support many advanced
> features. The first thing we did was to change the syntax to be almost
> identical to C/C++ since the BASIC-like coding style was irksome, and to
> add in sorely missed operators such as +=, *=, ++, etc. "
> 
> If they wanted Javascript they knew where to find it, right? :-(

I've considered adding those operators a couple times, since
"IndexVariable = IndexVariable + 1" is just tiring.  I'm not quick
to suggest adding operators, but these ones really are complete
no-brainers.  (I havn't yet added them to my tree, due to the cost
of maintaining more forked code and the learning curve imposed by
adding bits to Lua that aren't the Lua that everyone else knows.)

Cosmetically changing the syntax to be more C-like is just gratuitous,
though.

> "Furthermore, we made a series of incredible performance enhancements to
> the execution speed and memory management of the interpreter. We greatly
> decreased table access times and improved the performance of the garbage
> collector."
> 
> Now, it would be interesting to know details about this.

It's always frustrating to me when people say "we took this open source
code and made it better", without any mention of contributing it back.

(Not a suggestion of copyleft or anything like that--my frustration is
how it seems to never even cross their mind.  Copyleft bends arms, but
doesn't create motivation.)

Sure would be nice to see that Lua debugger under the MIT license, too.
It's easy enough to have simple Lua debugging facilities *inside* a game
engine, but it's not so obvious how to do it in a real debugger, stepping
through code inside an embedded Lua state.

> "Lua was a constant source of extreme anger and frustration."
> 
> :-(
> 
> "The Lua debugger was highly experimental and didn't become stable until
> several months before launch."
> 
> So, why blame it on Lua??

"Lua was a constant target of misdirected anger and frustration."

-- 
Glenn Maynard

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/