http://www.anyware-tech.com/en/m2m_services/learn_more.html
(The software, which is Eclipse-based, is not publicly available)
The overall goal is to streamline the development / deployment / maintenance of machine-to-machine networks, from embedded devices, to wireless networks, back-end servers, and finally front-end web sites or web services.
In particular, the embedded applications are modeled then generated in Lua. The model is mostly dataflow-oriented, although you can integrate other paradigms when suitable. What we appreciate about Lua in such an application:
- it runs smoothly on our target platforms (a couple hundreds KB and a couple dozens MHz)
- due to Lua's "make your own OO" approach, we have a very nice implementation of dataflow-oriented objects: little runtime overhead, great readability, virtually no boilerplate code. The only other languages which offer similar meta-object capabilities are Lisp dialects; however, they are a no-no, if you don't want regular customers to run away screaming at the prospect of writing a line of parenth^H^H^H code :-)
- since Lua is easy to parse, and the generated code closely follows our model, we have full round-tripping: modifying the model updates the code, but modifying the code also updates the model accordingly! This is a very important usability point: tools which generate once then let you maintain the generated code all by yourself are a real pain to use. Moreover, proficient users prefer to work in their editor rather than jumping back and forth to a model edition UI.
- language flexibility makes extensions relatively easy. For instance, it would be easy for us to add state machines to the modeling tools with little modification.
- the generated code being plain Lua, there is full compatibility between model-based code, regular code, and C code (we generate Lua/C interfacing code tailored to our needs, and many general purpose generators exist). Of course model-driven components use "raw" code, but modeled components are also perfectly usable in regular code.
A slight limitation of Lua is its dynamically typed nature, which isn't tooling-friendly. However, our models are statically typed, and passes its typing information as Lua calls such as
MyComponentClass :new_input_event ('somethingHappened', Time.Timestamp)
This is easily used for round-tripping (if your Lua parser handles scopes, variables aliasing etc. reasonably well), as well as for optional runtime checks (check compatibility when connecting ports together, or make sure that the values passed around conform to type declarations). This means we have dynamic typing for private parts, and static typing at the component interface level, which is an excellent compromise in practice.
Finally, our models aren't tied exclusively to Lua; Lua bends to conform to our models, not the other way around. It's important, because we also generate server-side stuff from the same models; when we have to adapt the model to an inflexible language such as C, not only is the resulting code painful to read, but the concessions we have to make on the model have significant server-side impacts.
For technical details: we use Eclipse for hosting and generic IDE features, EMF for modeling, GMF for graphical edition, OpenArchitectureWare for code generation, and Metalua for code analysis and round-tripping
