[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: new releases [was Re: Official public code repository]
- From: Stefan Sandberg <keffo.sandberg@...>
- Date: Thu, 27 Dec 2007 20:31:43 +0100
Lua is as stable and predictable as can be demanded of any language
runtime, imo. I have pretty much complete faith in it.
here's a nice quote(bare with me a bit, ladies):
"On June 4, 1996 an unmanned Ariane 5 rocket launched by the European
Space Agency exploded just forty seconds after lift-off. The rocket was
on its first voyage, after a decade of development costing $7 billion.
The destroyed rocket and its cargo were valued at $500 million. A board
of inquiry investigated the causes of the explosion and in two weeks
issued a report. It turned out that the cause of the failure was a
software error in the inertial reference system. Specifically a 64 bit
floating point number relating to the horizontal velocity of the rocket
with respect to the platform was converted to a 16 bit signed integer.
The number was larger than 32,768, the largest integer storeable in a 16
bit signed integer, and thus the conversion failed."
Now, if you take that into account, and consider the fact that Nasa used
Lua to monitor the gas-release valves on the launchpad, there really is
no real argument to the stability and solidness of the implementation.
This is an application of lua that far outweighs lightroom & wow
combined, due to the importance and cost of it, and the effort in which
(I've been led to believe) Nasa puts into it's software.
(clearly ESA should have used lua as well)
Not to mention that lua started out (and is still used I assume) for/by
Petrobras, which is one of the largest companies in the world. (maybe
not, I have no idea, but darn it fits nice with my argument!)
The point is, you're -not- dependent on any upgrades to your final
product unless it solves a very severe bug, which are very rare in
luaville, and when that happens the solution to the problem is thought
through by the lua team to -not-
disrupt backwards functionality... If your product functions and does
what it's supposed to, you upgrade to fix bugs or performance, or open
up for new development of some sort, but you don't just upgrade because
you want to look cool, that's just foolish.
I have no idea where I'm going with this, I guess I'm just confused by
the logic of where this thread is headed. (a ball of virtual yarn,
Michael Newberry wrote:
Just my 2 cents worth... I support all the statements Stephen has
made. Our Mira product is used for processing images in scientific
applications. For a decade we've been using Lua as a scripting
language, and we also have probably several hundred thousand lines (of
a million+ total) that are accessed by Lua, and nothing has broken as
new Lua releases have come along. I am not sure I could make such a
statement about other development tools we use. Lua is *solid*. And
also, the Lua book by Roberto is simply the most lucid language
reference I have ever read---period. There's a lot to be admired about
----- Original Message ----- From: "Stephen Kellett"
To: "Lua list" <email@example.com>
Sent: Thursday, December 27, 2007 10:58 AM
Subject: Re: new releases [was Re: Official public code repository]
Tim Kelly wrote:
Apparently my explaining how things work in North America is
Not at all.
You said forced upgrades and features customers don't want. That is
what has been getting the reaction. Product upgrades containing bug
fixes and features customers want are good things, but just releasing
an upgrade to gouge your customers, thats shoddy practice.
The company I work for releases updates for all our software products
on a regular basis. But those updates are bug fixes and improvements
to the feature set, not just something to squeeze more cash out of
I do think it bizarre that people writing Lua scripts are expected
to be able to maintain their own version of Lua.
Expected to? No. Its an option you can choose to do if you are
worried that Lua will someday disappear. Thats an option VB users
don't have. How do those VB users maintain their runtime? It seems
that despite Lua winning this comparison you still favour the outcome
that leaves you in the position of the VB users.
>I tried to explain why the absence of a structure roadmap can be seen
as a negative to
>companies considering bids. I even volunteered to write one, but no
one seconded me.
How can you write the roadmap (if one were to be written) given that
you are not in control of the choices? I'm assuming Roberto and a few
others have the most leverage over issues like that.
There is nothing to stop you writing a document that describes the
pros and cons of Lua, the choices companies like Adobe and the World
of Warcraft people (I don't know their name, I don't play the game)
make and so on. Adobe have the resources, two existing languages and
the finance to write their own language. They didn't, they chose an
existing language. Thats a very powerful argument.
I bought my first version of Photoshop when it ran on Windows 3.1.
That was 1994. 13 years ago. Photoshop is still the market leader.
I'm betting that Adobe expect Lightroom to be a viable product in
another 10 years, still with Lua inside it.
>Instead, I feel rather attacked for asking for assurances of long term
You've been given them. But not in the form of a roadmap or a
multi-million dollar company standing behind the product.
We've ported several hundred thousand lines of C++ to work with Lua.
There have been changes to Lua during this time. Zero changes damaged
the work we have done over these years. Some changes in Lua 5.1 (to
the memory allocation API) made one of our software tools much easier
to write and implement. Support from the mailing list on the few
occasions we've been unable to work stuff out on our own has been
The source code is easy to read. Lua has one book published, in two
versions that describes the language. For a language to get its own
book should mean something. Its not vanity publishing, that is for sure.
In a previous post you cited PHP and Perl. We've also ported some of
our tools to PHP and Perl. Doing so was a lot harder than doing the
same task for Lua. Lua was roughly the same difficultly level as
porting to support Python and Ruby.
I asked for assurances because I am tired of choosing technologies
that suddenly decide to go in completely different directions.
But apparently you also conclude that because Lua isn't doing that,
that it is stagnant. You can't have it both ways. Either you are
happy that it Lua is stable, content and slowly changing or you are
happy that Lua is going off in umpteen different flavours (like Linux).
Lua is nearly 15 years old and on version 5.1. That indicates, that
on average it takes just under 3 years per release. Seems like they
consider things and don't just randomly change direction.
I did not wish to invest time and energy in Lua knowing that it was
not a mainstream choice for scripting unless I could feel really
How much more mainstream can you get than Adobe and arguably the most
populous online game in the world, World of Warcraft? You cite you
want mainstream, but when you are shown it for some reason the
dominant market player, worldwide, in two categories (graphics and
online gaming, both multi-billion dollar categories) is not enough.
Lua has software tool support in the form of many open source tools
and 5 commercial tools I can think of. Possibly also an IDE or two.
All the things are in place, that indicate "mainstream", except this
I spent time writing a binary<->decimal<->hexidecimal string
converter in Lua
Given Lua's philosophy, that would go in a library, not the core.
Someone please correct me if I'm wrong.
Perhaps you are mistaking the core for a library that sits around the
core? As others have noted for many things you would not be looking
at Lua, but at a Lua library and as such, you would be reliant on the
maintainer(s) of that library.
FWIW: I have no personal axe to grind with you. You are not being
attacked. Some of the concepts you present are.
Ruby, Java, Assembler, Performance Analysis, Troubleshooting
Object Media Limited
Reg Office: 24 Windmill Walk, Sutton, Ely, Cambs CB6 2NH.
Registered in England and Wales: Company Number: 02979036