Learn Lua. I went through the same basic phase as you described, and once I'd gotten my competence with implementing Lua bindings up and running, I never looked back. For me, Lua+C is the most elegant combination of language tools I've used, and as a developer with 30+ years of experience, I've used most of them.

Lua really, really rocks - especially if you look at it as the domain tool it is, and not the prepackaged broad-spectrum scripting language that many people consider it to be ..

Agreed. At my last job I did most of my programming in Lua. We used C++ & Cocos2d-x with LuaC bindings for our game engine and wrote all of the game logic in Lua.

I really like a lot of Lua's features, especially closures and the way metatables work. Although Lua doesn't support true classes, it's possible to implement them nicely through metatables.

What do you use for basic data structures in C? Stuff like hash map, priority queue, sorted set, etc.

Fortunately, it is very easy to implement these structures in Lua, if they haven't already. The basic datatype of Lua - the table - can be treated as a hash map, a sorted set, a priority queue, very, very easily .. in fact if you think these things need to be implemented in C, you're missing a big part of the picture with Lua. The power of Lua as a language is really derived from the "morphological" nature of the basic table datatype .. Lua has all of the structures you're asking about, already.

And anything it doesn't have, which one would truly need to derive from the C/C++ side, is a few simple binding calls away .. but anyway, tables will do all you ask, and more, if you learn to use them properly.

When you're using C as a layer under some other high-level language you get those implemented for you. For instance, if you write Python bindings, you will use Python's data structures from C. If those are too slow for you, you'll want a specialised structure - there are many libraries providing collections for C.

glib is not bad. you can even use vala, which is c-like, but has built in glib and gobject support.

What do you mean by "...as the domain tool it is, and not the prepackaged broad-spectrum scripting language..."?

I haven't used Lua yet, but reading about it led me to believe it was a "broad-spectrum scripting language".

I'd like to understand the distinction you're making more deeply.

There are two ways to look at Lua. There's Lua-the-abstract-language which can certainly be used as a broad-spectrum scripting language. I certainly use it in that capacity.

Then there's Lua-the-implementation(s) (PUC + LuaJIT), both of which are designed from the start to be maximally easy to embed in a host C program, or to delegate work to shared libraries written in C. In my opinion, it is an order of magnitude better at this than Python or Ruby; some of this is a matter of taste but I believe most of the advantages are objective.

Not to put words in the GP's mouth, but I take the "domain tool" comment to mean: "You really should try to use this in close cooperation with C, and not just as a stand-alone language. If you don't you'll miss a significant portion of the value." Note that using it in concert with C need not be done in a single person's head (though this case is also common); Lua+C is an extremely productive way for a systems programmer and an applications programmer to work in harmony while enjoying most of the best of both worlds.

You got my message pretty well 100%, I was just about to type a sentence very close to this one: "You really should try to use this in close cooperation with C, and not just as a stand-alone language. If you don't you'll miss a significant portion of the value."

Yes, you can just run 'lua' at the console and treat it as a local scripting language, with the default bindings available in the distribution Lua-interpreter .. but you can also take the VM itself, make it your own, and put it in your own project for domain-specific applications.

For a great example, take a look at MOAI: http://getmoai.com/

Essentially, MOAI is a collection of C and C++ libraries, tied together into the Lua VM to provide a cross-platform development tool for Android/iOS/Linux/Mac/Windows/&etc. This is accomplished by 'gluing' the Lua VM into the space between a variety of different API's and making those API's available within the Lua environment - in this capacity, it serves very, very well. I could imagine building an entire GUI/OS in a very similar way, and may end up doing just that one day soon ..

Thanks for clarifying. I will be looking into Lua from this standpoint.

Now for a separate question -- do you find MOAI practical for complex mobile apps? Is it one of the most productive ways to build cross-platform mobile apps? If not, why not?

(I came across MOAI a while back and wondered this. Would be good to get an opinion from someone with hands-on experience).

Personally, I'm 100% a raving MOAI fanboix, I can't stop promoting it as a neat way to develop cross-platform apps.

Okay, its not a way to get a native app developed - other frameworks are better for that, although I'm hesitant to recommend any.

MOAI itself is geared towards games, and gaming-style user interfaces. This means, of course, that you can develop all the standard paradigms for UI that exist in the mobile world, with the benefit (or disadvantage, depending on how you look at it) that it will look and feel the same on all platforms.

I was given the task this year to develop a utility app with MOAI (Rauchfrei Durchstarten - a German-language app to assist smokers with quitting their habit, available in Google Play as well as iOS appstores) and while I wouldn't consider it the prettiest looking app in the world, it was definitely a rewarding experience. The project fell into the "learn on someone elses' dime" angle a little, though, so there was a bit of a controversy over the use of MOAI for this project by the company that requested it. However, the job got done. I'd get it done a lot faster, slicker, and with better results now, if I had to do it again (also, I would definitely not work with the original designer, who didn't understand much of what MOAI can do and enforced a rather bland set of rules on me in their work).

But .. one of the great things about MOAI right now is that there are a lot of 3rd-party frameworks popping up specifically for MOAI, which at face value might seem a little unusual since MOAI itself is supposed to be all you need as a framework - but products such as Hanappe, moaigui, and Rapanui are all frameworks for MOAI which give it advanced features with ease - such as scrolling listviews, buttons, dialogs, menus, etc. All of this on top of a very powerful games system which provides a lot of high-end features (Grids, Tiledmap support, pathfinding, etc.)

If you take the stance that MOAI is a lower-level framework which provides performance and portability in an extremely tight package, then add any of the above frameworks (please use Google to find them, they're easy: "hanappe moai" will get you there..) you may see that MOAI can be built upon with extreme power returns.

On the other hand, if you absolutely have to have a native UI, and the idea of implementing your own characteristic UI elements seems abhorrent, then you might get tripped up a bit. I (almost) did, with the Rauchfrei app, anyway .. in that case I used moaigui to provide form and basic UI elements. From a broader standpoint, it probably would've been better to build the app in HTML5 with Titanium or something .. but again, I wouldn't have learned much MOAI that way. ;)

(EDIT: the package bundle for Rauchfrei includes sources .. you might like to inspect them as an existing example if you know how to get the .apk unzipped.. see https://play.google.com/store/apps/details?id=at.allaboutapp...)

As for whether MOAI is practical for complex mobile apps, I would say it really depends on your competence level, in general. I would say that MOAI is not something that beginning/slightly-less-than-fully-confident programmers should pick up and try to use, if they are under the gun.

But if you actually like the idea of inventing new paradigms and delivering them in a cross-platform package, then MOAI can kick some really serious ass. Since most of the mobile GUI these days is derived from gaming-style interfaces, it could be that a MOAI-based app will revolutionize the mobile market soon enough. Its certainly a great gaming toolkit, and in that sense, would make for some nice new paradigms to be invented ..

You've really sold me on this. Just letting you know. This is something that I would have liked to see or bite on for a while now. Didn't know something like this existed already. I haven't heard exactly good things on developing with Marmalade or PhoneGap from friends or HN. This sounds like a much better alternative to both.

It doesn't have the "batteries included" philosophy of languages like Python, where there's already a ready-to-use library for everything. If you want to do anything non-trivial with Lua, you'll probably have to touch some C code.

Others have contributed good answers to this question in your sub-thread, so I will just clear this up for you:

domain tool - a tool which can be applied to, and adjusted according to the needs of the domain of your application. You can embed the Lua VM in your 'broader application' and use it as an internalized scripting language. If, for example, you've got a C/C++ program which sorts apples, you can export those apples, with bindings, into the Lua VM and reference them from the Lua language as apples, just the same ..

board-spectrum scripting language - python, perl, lua. Each of these can be (usually) found in /usr/bin somewhere, as a single executable that can be used to run the language scripts. Lua has a part in this role too - I frequently write system-admin scripts using #!/usr/bin/lua, but in this particular case I don't have any 'customizations' - I get only whats built-in to the Lua executable as shipped by my distribution.

But, beyond this, I could take the Lua VM and build my own domain tool with it. See the difference now?