Re: Degenerative discussions

["Eric Tetz" <erictetz@...>]

On Dec 28, 2007, Tim Kelly <gtkelly@dialectronics.com> wrote:
> It would be absurd for anyone soliciting an RFP/RFB to consider a
> developer that has toolkit based on a product that hasn't been updated
> in five years.

It would be absurd for anyone to value arbitrary dates over relevance
to the project. For instance, if I was contracting someone to deliver
a system written in C, I'd want them to code for C89, so I'd be
ensured the wide compiler. But C89 is 20 years old! There are newer
version of the standard! Newer is always better! Having a more recent
timestamp trumps all other considerations! It's absurd to think
otherwise! Right?

> What's wrong with setting a schedule where once a year a new release
> version comes out with up-to-date bug fixes and non-dramatic features
> appear?

You've made it clear that you don't care about bug fixes or new
features; you want updates for updates' sake, so you can have a date
that looks good on paper to stupid people. I don't think I'm
exaggerating.

>> If you can't justify the use of Lua in a particular problem domain,
>> then perhaps it really is the wrong tool for the job.
>
> This is either elitist and exclusionary

No, it's pragmatic. You don't use a saw to pound nails.

> you are implying by your attitude that Lua is not for everyone

I'm implying that it's not the solution to every problem. There's a
right tool for every job. If Lua's a good fit for a particular task
(assuming you understand the task and the tool) it should be
relatively easy to justify.

> A good manager/President/CEO won't take a bid from a company pitching a
> product without examining the solvency of that company.

That's a terrible analogy.

If your project depends on a company and the company DISAPPEARS,
you're left empty-handed, you're screwed.

Lua can't "disappear". If your project depends on Lua, you cannot be
left empty handed. It's FREE software, for which you have every last
byte of source code included in your project. Roberto could be eaten
by a dinosaur tomorrow and it would not affect your product's
dependance on Lua whatsoever.

> Free/open source software projects can choose to reject being held to
> any determinancy of solvency (in which case they should stop requesting
> users support them with donations and book purchases)

Man, you really do have balls. :)  FREE projects can do whatever the
hell they want. Lua's authors are free to request whatever help and/or
donations they want. And they don't owe us a damn thing. It's FREE
software. You can take it or leave it.

A lot of people have chosen "take it" -- people who are writing
billion dollar software --  so you might want to entertain the
*possibility* that they see the "solvency" equation differently than
you do.

>> Would you email concrete manufacturers asking for a roadmap of
>> when concrete is likely to change?
>
> Actually, this is often the case.  As building requirements change so must
> the loads concrete can bear.

You're misunderstanding how this question applies to Lua. If you
contract to build a structure with concrete X, the future of concrete
is not relevant to your construction. Once you've chosen concrete X as
a building material, it's going to be PART OF THE BUILDING; any future
enhancments to concrete will not affect your structure. You're not
going to go back later and retrofit your existing structure with a new
type of concrete.

> Kinda like it'd be reasonable to ask how will changes in operating system
> versions will affect postgresql which affects LuaSQL which depends on Lua.

LuaSQL is not dependent on what happens to Lua, the language, over in
PUC-Rio. LuaSQL is dependent on *the version of Lua it's built with*
(i.e. concrete X). Lua can go turn itself into the next Visual Basic
(i.e. a new type of concrete), and this has no impact on LuaSQL.

If a new version of Lua comes out with irresistibly sexy new features,
LuaSQL can *choose* to update the version of Lua they are built with,
but they don't *have* to. Their "solvency" is not dependent on Lua's
update schedule (or lack thereof).

Cheers,
Eric