Re: Degenerative discussions

[Stefan Sandberg <keffo.sandberg@...>]

Haha, I don't understand almost anything of this, it really doesn't make 
much sense. (or I'm reading it backwards, I woke up just 2 minutes ago)


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

So according to you, someone trying to saw a plank of wood in half using his teeth is "elitist and exclusionary"?


- "Decision-making in business rarely involves technical considerations.  Successful completion of the job shows the technical merit of the chosen pieces; getting the chance to do the job has nothing   to do with the technical merits of the possible pieces and everything to do with presenting the possible pieces, including the pieces behind the pieces. "

Do you hire people based on technical merit, or something else, like smell? 
Do you plan ahead like it was a poolparty, and it doesn't really matter very much if there's actual "technical merit" involved or not?
It's just a good sell, and nothing more?

Please, what company do you work for?


Tim Kelly wrote:
> Eric Tetz wrote:
> "Choosing to use Lua
> in your product today does *not* make you dependent on Lua's future
> direction."
>
> This is out of touch with bidding processes.  Most, if not all, independent contractors have toolkits that make their lives easier.  Those toolkits are based on underlying products.  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.  That does make you dependent on Lua's future if you choose Lua today.
>
> (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?  As long as Lua keeps meeting this deadline, for even minor, minor adjustments, there's no question about the future.  As has been pointed out, the MBAs aren't going to know the differences behind the code.)
>
> "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. *shrug*"
>
> This is either elitist and exclusionary, because you are implying by your attitude that Lua is not for everyone, or you offer offense to Lua as unable to handle situations where PHP and Perl might be considered.  I never questioned Lua's ability to handle the jobs I need it to do.  Decision-making in business rarely involves technical considerations.  Successful completion of the job shows the technical merit of the chosen pieces; getting the chance to do the job has nothing to do with the technical merits of the possible pieces and everything to do with presenting the possible pieces, including the pieces behind the pieces.  A good manager/President/CEO won't take a bid from a company pitching a product without examining the solvency of that company.  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) or they can choose to show emph
>  atically they are very solvent in non-monetary terms (thereby encouraging support from users in the form of donations and book purchases, like the two books on Lua I own).
>
> tim
> --
>
> "Anything war can do, peace can do better."  --  Desmond Tutu
>
>
>