Game company adoption and Lua was RE: Ironic comment RE: cooperative multitasking

[Pyrogon Public <public@...>]

> The fact that enough game companies don't find languages like 
> Lua useful says that there is something Lua is missing that 
> it shouldn't be.  All that I can really think of tho is a) 
> *real* multi-tasking, and b) a more newbie-friendly syntax.

Actually, in my experience from talking to lots of game developers, the
two biggest knocks on Lua are lack of documentation and lack of
awareness.

My conversations tend to go like this:

Them: "So what scripting language are you using?  Python?  Java?  Ruby?"
Me: "I'm looking at Lua"
Them: "Lua?  Never heard of it"
Me: "It's a small, simple language that's easy to embed."
Them: "Hmmm, I'll check it out"

Two weeks later:

Them: "I think it's cool, but there's almost no documentation for it,
and what documentation I have found is partial or out of date or based
on a mix of Lau 3.2, 4.0, 4.1 and 5.0 work"

> So, speaking of that, does anyone have other examples of 
> where a simple syntax isn't a good as a common syntax?

While it's a valid point of "people like what they already know" (cf. my
old comments about "Why the hell does Lua use -- for comments intsead of
//?!", constantly being held back because of old syntax rules only makes
matters worse in the long run.

For example, a common gripe with C/C++ syntax is that function
signatures are of the form:

[return type] [name] [arguments]

e.g.

bool isAlive( Entity &e );

This makes complete sense to someone that is used to C/C++, but if you
look at it objectively, it's actually not the way you'd really want to
write it for readability.  The first item in a list should not be the
return type, because people scan source code for identifiers.  A more
logical representation would be:

isAlive( Entity &e ) bool;

Same with variables.  Do you search by type or by identifer?

int someInt;
foo aFoo;
bar aBar;

doesn't make as much sense as:

someInt : int;
aFoo : foo;
aBar : bar;

Yet the former syntax is "clearer" to many of today's programmers.

Brian