5 ms·

LuaJit is so fast now, why not LuaJit + C where needed?

• malkia 17y ago
  LuaJit is awesome, but he talks purely about using Lisp to describe "C" semantics. Take it as use "Lisp" Alphabet, but still write a "C" language. Not good analogy, but gets you there. What he would achieve - well the same semantics, anything generated by his amplifier would be linkable, runnable the same way as C. What he would achieve by using Lisp - we'll he can just skip the whole C++ templa-bastardization, and just use common lisp macros. He can use it for anything that he would like... Hell I would like to use it tommorow. It won't be easy on the guy that's trying to debug that thing, after such transformations you would need some heavy "#line" preprocessor magic put in the "C" code, but it's doable.
• silentbicycle 17y ago
  That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C or C++, write or generate a simple Lua wrapper for its API, and then the do logic in Lua, moving hotspots to C as necessary. (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers http://c2.com/cgi/wiki?AlternateHardAndSoftLayers, as they say.) As a bonus, the cross-language boundaries are often natural seams for containing complexity. TCL was also designed with this style of programming in mind, and John Ousterhout describes it pretty well (http://www.vanderburg.org/OldPages/Tcl/war/0009.html http://www.vanderburg.org/OldPages/Tcl/war/0009.html). FWIW, LuaJIT is only available for i386 at the moment, though amd64 porting is in progress. Standard Lua is still pretty fast, and it's great for prototyping. It's a good idea to get algorithms and overall design right before spending much time on low-level tuning.