lua-users home
lua-l archive

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

Glenn Maynard wrote:
On Tue, Nov 14, 2006 at 12:21:27PM +1100, Mike Kreuzer wrote:
Sure, there are bindings & wrappers, but so far the ones I've looked at
(& I haven't investigated yours) either act with the same carte blanche
with regard to changing their APIs, or they don't update at all.

Not updating seems to be a popular choice, but what possible goal
could be achieved by fragmenting the user base between different
versions of the language?

(A goal--as I see it, at least--is to avoid bloat.  You describe a side-
effect.  The above is like saying  "what possible goal could be achieved
by stubbing your toe?" to someone who wasn't wearing shoes and, as a
side-effect, stubbed his toe.)

OK, I'll up the ante with Santa.  Now I'd now like backwards
compatibility for Christmas as well.  From version 5.1, any 5.1 script
should run in any future version of Lua.  If the language is mature, and
I think it is, then it's time to say so.

The Oxford English Dictionary has a very simple rule for deleting a word
once it's in the dictionary:  They don't.  I think we should adopt the
same approach with language features.  It might concentrate minds a bit
when new features are being considered.

This is the "feature bloat" approach: once a feature is added, it's
stuck in the code, even when it serves no purpose but backwards
compatibility, and even when that compatibility causes code bloat,
design bloat--you have to design around the need for those features,
forever--and maintenance bloat--you have to test these features and
keep them working.

I don't want a Lua where luaL_checkudata has to always return NULL for
backwards compatibility, even though the rest of the check* functions
throw errors.  I want a Lua that's consistent today, even if it means
more work to upgrade.  I don't want these deprecated functions and
features to stick around in the code and headers and documentation
forever; I want them to go away.

I don't want Lua's evolution stunted by backwards compatibility.

Stuck.  Bloat.  Stunted.  ROTFL, tell me what you really think. :-)

Avoiding bloat is a useful goal, sure, I just think providing backwards
compatibility is a more important one, and providing API stability is
more important again, and growing the user base & making Lua useful for
larger projects is more important again.  All of those goals are
compatible, except for the first one.

Still, there're obvious roles for a very small language, just as there's
a role for a language that remains the plaything of hobbyists and
academics.  If that's what Lua's going to limit itself to, that's fine.
 IMHO, the growth of useful code written in the language is only really
going to take off when changes in the language and the API slow down
enough to let that happen.

Stunted. Still laughing about that one.

Mike Kreuzer