Jump to content
C4 Forums | Control4

Why is Lua used for Control4 driver programming


Recommended Posts

Lua seems like a relatively obscure programming language, at least in 2017 (it doesn't make a list of the 20 most popular programming languages). It was developed in Brazil about 25 years ago.  Is there any particular reason that C4 would have chose this as the language to use for drivers?  Is there anything that makes it well suited for the purpose?  

Any reason why something like Java, Python or variations of C would not have been used instead - or is that just hindsight on what have become very popular languages?

Link to comment
Share on other sites


Good question - here's my thoughts. Control4 used to use C++ compiled drivers. However in 1.6 with the driverworks SDK they included LUA extensions. There's some interesting conversation here, but probably the short order of why it was picked 10 years ago is that it's lightweight, fast, and has a "relatively light" learning curve.

https://web.archive.org/web/20130820131611/http://stackoverflow.com/questions/38338/why-is-lua-considered-a-game-language

Remember back in 2008 when 1.6 was released, the HC300 had specs similar to a 400MHZ processor and 256MB ram. The EA5 today has multicore arm processor and 2GB ram - so yes hardware improved but you still want efficiency because we are now doing much more - 1080p on-screen, Android based UI, tons of 3rd party integrations (compared to 2008, this was before the 4 store even and the 6 year flash navigator experiment), etc. Someone else who spends a lot of time in it like Alan Chow or Ryan (who helped develop Driverworks for Control4) can probably offer more accurate insight.

Link to comment
Share on other sites

2 minutes ago, control4user007 said:

I know both but prefer python.  More libs I can use to do cool things.

This is very true - you can often find what you need already written in Python.  For example, I have some LED lights that use a phone app called Magic Home.  Someone has written Python called called flux_led to easily control these lights.  If C4 used Python it would be very easy to turn these into a driver.  It probably isn't hard to just convert the code to lua, assuming that they have the TCP socket reading and writing available, but with Python it would be trivial.

Link to comment
Share on other sites

7 minutes ago, zaphod said:

This is very true - you can often find what you need already written in Python.  For example, I have some LED lights that use a phone app called Magic Home.  Someone has written Python called called flux_led to easily control these lights.  If C4 used Python it would be very easy to turn these into a driver.  It probably isn't hard to just convert the code to lua, assuming that they have the TCP socket reading and writing available, but with Python it would be trivial.

either way you have to convert the library to use C4 APIs...

Link to comment
Share on other sites

Lua as a language is not as popular as a 'standalone' language as many others, but it's *much more popular* for the kind of things Control4 uses it for.  Lua was never designed to be a standalone language, it was specifically designed to be embedded into other applications, to give applications an interpreter.

Lua is:

  • Small (important because you may have hundreds of DriverWorks drivers in a project)
  • Fast (Embedded controllers are resource constrained, even big ones)
  • Easy to embed and extend
  • Simple to learn and hold in your head
  • Efficient and Flexible data structures (Lua Tables).  They can work as a stack, a queue, a table, a list, etc.
  • Functional-programming available...  Functions are first-class in Lua, and tail-call recursion 'just works'.

The 3 languages I looked at when deciding on DriverWorks were JavaScript, Python, and Lua.

JavaScript's big disadvantages are that it's fairly large, (used to be) very difficult to embed, and somewhat tied to a DOM.  Some of that has changed a bit, but it's still not ideal.

Python was not designed to be embedded, it's much better at embedding *other* things inside of it.  Just like a Python.  It's big advantage is that it is fully 'batteries included', but because of that, it's also very large.

C/C++ derivatives were a non-starter because we wanted to get *away* from having version-specific compilation for drivers.

I made the right choice then, and I stand by the choice, and if I were choosing again today, I'd still choose Lua.

The same reasons makes Lua the *most commonly* embedded interpreter in the gaming industry.

RyanE

P.S.  The only drawback to Lua that I could find is that they use the 'end' keyword... :)

Link to comment
Share on other sites

Also, nowadays there is 'Micro Python', available on microcontrollers.

Sadly, Python devs struggle with it, because making it fit on microcontrollers, you basically slim it down by removing 'the batteries', so you don't have the voluminous libraries that make Python Python...

You end up with Python syntax and a small standard library, but in the end, it's a lot like Lua, but with significant whitespace.

And it's runtime is 2X the size of the Lua runtime.

RyanE

Link to comment
Share on other sites

  • 10 months later...

I came across this today and thought of this forum:

https://medium.com/@caspervonb/a-brief-totally-accurate-history-of-programming-languages-cd93ec806124

 

Quote

1993

Roberto Ierusalimschy and friends decide they need a scripting language local to Brazil, during localization an error was made that made indices start counting from 1 instead of 0, they named it Lua.

 

Link to comment
Share on other sites

Thanks for the history lesson, although I understood very little. I’m not a “true programmer” but I putz when I can. C4forums.com should consider a “History” subsection because I just love reading about my favorite company’s historical decision making. 

I especially enjoy zaphod’s questions and comments. He’s never afraid to answer, or chime in on, the questions some users find too contentious.

Cheers from Lauderdale

Link to comment
Share on other sites

I read that paper 2-3 years *before* I got to basically decide which language Control4 used in DriverWorks.

It made enough of an impression so that I remembered it as an option when the time came.

Once the decision came, it was such a good fit that making the first version of DriverWorks for OS 1.6 happened in a matter of a month or two, for a 1-pizza-sized team.

RyanE

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.