<snip>
Companies will use Python for a reason. Perhaps those reasons will just be historical, maybe the first application was written in Python when it was less corporate but now you have >10,000 lines of Python to maintain. So you employ more Python programmers to maintain and expand your applications. Substitute the any language for Python in the above and the argument remains. If you are starting something new and there is some existing library that would give you a big head start then you might pick a new language. But it will not make much sense to do so just for the hell of it given that you will be have a massive learning curve for the new field and then adding an additional learning curve for a new language
In fact it has nothing to do with the language and more to do with the tools available in the field. Lua's field of expertise is being embeddable and as a scripting language within a less flexible frameworks / languages. This has lead it to become a lean language which can be exploited for that outside it's traditional fields. But unless that is absolutely what you need then using Lua does not make sense
I didn't convert one of our core applications to Lua just for a laugh but because it improved the application many fold (cost / benefit). However there is little benefit to using Lua for our other applications. We have our workflow nailed down just so, we have considerable experience in the tools we use. We cannot throw that away without good reason
So we will continue to employ Ruby programmers just as others will continue to employ Python, Java and even PHP programmers
I think this is a wise way to look at language choice, but Lua's popularity problem is an obstacle even when it should not be. For example...
In my industry (broadcast and pro av equipment), Lua is a perfect fit. In fact, I cannot think of a language that is able to bring scripting down to the depth that Lua can. In Python, libraries linking into frameworks like GStreamer [1] or digital signage applications like Scala MultiMedia [2] can be triggered by the application in an "out-of-the-loop" fashion, but real-time ability to control the buffer state is not possible. While Python is plenty fast and is multi-threaded, its design does not support embedding in time-constrained (real-time-esque) applications and it will block everything if it needs to.
Even so, nobody in my organization had even heard of Lua and as a result, their assumption was that all scripting languages suffer the same limitations and that the best approach was to find the most popular one and to do the best they could to make it work. Making the case for Lua leads to conversations like
* "What do you need scripting to do? I will make Python do it where others have failed."
* "Why would you need scripting to be in the main processing loop? That sounds dangerous... it's probably not fast enough..."
Simply, introducing them to Lua was not enough. They had to understand the very subtle design differences that end up having a critical impact on what is achievable.
Lua has the quality of simplicity, which makes it look *almost* unfinished and it is easily mistaken for unsophisticated. Committing to the effort of appreciating something like Lua, especially when you're already a super-smart programmer who doesn't need to listen to a product manager's opinion on a toy scripting language that doesn't even make it easy for you actually try out (WTF is the standard library?), is asking a lot of people.
This is not only a technical problem that is solved by picking the right libraries and adding some things to LuaRocks, although I think that those activities are almost certainly an essential *part* of the solution.
--
Andrew Starks
