lua-users home
lua-l archive

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


Here at work we use:

C, C++, gsc (game script language), AngelScript (for some tools), .bat/.cmd, some leftover .sh files, Makefiles, perl, python (standalone, Maya, MotionBuilder), lua (now started), MEL (tcl like language for Maya), HLSL, Cg, CUDA (from nvidia-texture-tools), .NET - C# and VB, php, SQL (MySQL, SQLite), JavaScript, even some assembly specific to the platforms (ps3, xbox, pc, wii)

Additionally there are many description languages for various text file formats, and yacc/lexx/bison/antlr/whatever else for parsing them. (so this means also .l .y .lex, etc. meta languages - not really programming, but still relative)

As example for libs - we use quite a lot of libs, even for UI, there is wxWidgets, Windows Forms (.NET), Qt, MFC, custom UI libs, and probably few others. (I've used JUCE in the past).

It's a normal ecosystem, we tend to like one language for certain operation a lot (perl), then we move to another (python), or stay, or move just bits of it. It mainly depends on the person supporting it.

I've seen some techincal artists moving from MEL to Python for Maya.

What I like about Lua, right now is LuaJIT - the ability to dynamically run code without recompiling... FAST! Bonus - the awesome FFI system.

I'm experimenting right now with using Autodesk MotionBuilder with it, because C++ development with it simply sucks (the iteration time is killing me, at least debugging is good), and Python might be a bit too slow for certain operations.

If I have some success, I would think about Maya next.

On 4/19/2011 1:00 PM, Robert Raschke wrote:
Sigh. There is no one true way!

Lua is absolutely brilliant for configuration scripting. (And quite a
bit more, but you can run into difficulties quite quickly then.)

Programming languages are tools (note the plural!). In order to solve a
large problem, you end up needing more than one tool. In all the
industrial projects I have worked in, none of them used one programming
language (compilers I worked on used assembly, C, Imp, Yacc, Lex;
statistics programs used C, C++, Java, homegrown scripting language; IT
mgmt program uses Java, Flash, Javascript, Powerbuilder, SQL, Lua,
Erlang, C, C++), plus build, test and support scripting (make, perl,
python, ant, sh, awk, ...).

It's a toolbox, use as much of it as you need. But if all you know how
to use is a screwdriver (aka Java, these days), you're gonna get into
trouble reasonably quickly.

Further, writing a library for general use is very hard. Regardless of
underlying language. Either you write a library that solves your
problem, and if you make it public, quite a few people moan about lack
of features. Or, at the other extreme, you invent CPAN. Not everyone has
the resource to come up with something like the C++ template library,
which is the only fully functioning, bells and whistles, stable,
dependable and well documented bit of kit, I am aware of. Everything
else (Java, Python, Ruby, Perl, Haskell, SML, C#, Lua, Squeak, Lisp,
Fortran) is good to very good, but generally a bit of a mess all round.

Designing the supporting infrastructure for any programming language is
a non-trivial task. Making the language is the easy part.

Robby

PS I never had the pleasure of working with Algol 60, which supposedly
had a pretty good set of libraries at the time.