3 ms·

I get frustrated with people who think they can and should rewrite the scripting language. I actually have my OWN game engine (based on LuaJIT, thank you ;) T

I get frustrated with people who think they can and should rewrite the scripting language. I actually have my OWN game engine (based on LuaJIT, thank you ;) This comment would be better if it wasn't snubbing everyone who dared try to shake up the status quo of programming languages. People two hundred years from now won't be using LuaJIT. Therefore why wait two hundred years to invent the future? We could have it within our lifetime, if we remain supportive.

jnbiche 13y ago
If this comment were made about any other scripting language than LuaJIT, I'd be in agreement. But LuaJIT is the future of scripting. It's truly a stunning achievement.
- aktau 13y ago
  LuaJIT is superior to anything else I've been able to find, it blows me away. Though there can always be something better! That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are: - add/subtract - mul/divide - shuffle Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.
  - lobster_johnson 13y ago
    I and a colleague have been looking a little bit at using Nimrod [1] as a game language. Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use. What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right. [1] http://nimrod-lang.org http://nimrod-lang.org
    - aktau 13y ago
      Very interesting. I'm currently still a bit enamored with Go as it allows me to be very productive and makes deployment, cross-compiling and concurrency such an absolute dream. The performance tradeoffs have been rather good to me I find, it's very speedy for the tasks I try to use it for (almost all of them web-based). But if Nimrod is better... well I can't be sad about that!
  - jnbiche 13y ago
    The foundation for SIMD vector operations has already been laid by Mike Pall, and his plan is to implement a pretty full API for supporting architectures. See: http://lua-users.org/lists/lua-l/2012-02/msg00207.html http://lua-users.org/lists/lua-l/2012-02/msg00207.html I think he's looking for a sponsorship to accelerate this feature[1], so if you know of someone who might be in a position to sponsor the feature, it's a very worthy project! 1. http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Type-Support-for-the-FFI http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Ty...
SomeCallMeTim 13y ago
I'm happy to see people do innovative things with programming languages. But there are a lot of people doing that right now. I didn't get a vibe from this one that it could do anything interesting that you can't already do in either LuaJIT or Julia. Other innovative languages I've been tracking include Go, D, Nimrod and Dart. The world is improved by innovations; it's not improved by script language proliferation, or "me too!" projects. Lua in particular is a very well documented language, and is the de facto standard in video game development. I think the bar has to be pretty high to justify creating a new language. Yes it would be more fun than figuring out how to get 3d matrices to work and be fast in LuaJIT, if you don't already know how the FFI works. But there's a LOT of value in using LuaJIT, and unless you're bringing something else of value to the table, no, I don't think it's worthwhile backing Yet Another Language. I know of at least a half dozen other engine-specific scripting languages, and I would wager NONE of them are as robust as Lua, as well known as Lua, as well defined as Lua, or even as well designed as Lua. The value of having a shared language does outweigh every new programmer's desire to write their own language.

jnbiche 13y ago

If this comment were made about any other scripting language than LuaJIT, I'd be in agreement. But LuaJIT is the future of scripting. It's truly a stunning achievement.

aktau 13y ago
LuaJIT is superior to anything else I've been able to find, it blows me away. Though there can always be something better! That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are: - add/subtract - mul/divide - shuffle Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.
- lobster_johnson 13y ago
  I and a colleague have been looking a little bit at using Nimrod [1] as a game language. Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use. What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right. [1] http://nimrod-lang.org http://nimrod-lang.org
  - aktau 13y ago
    Very interesting. I'm currently still a bit enamored with Go as it allows me to be very productive and makes deployment, cross-compiling and concurrency such an absolute dream. The performance tradeoffs have been rather good to me I find, it's very speedy for the tasks I try to use it for (almost all of them web-based). But if Nimrod is better... well I can't be sad about that!
- jnbiche 13y ago
  The foundation for SIMD vector operations has already been laid by Mike Pall, and his plan is to implement a pretty full API for supporting architectures. See: http://lua-users.org/lists/lua-l/2012-02/msg00207.html http://lua-users.org/lists/lua-l/2012-02/msg00207.html I think he's looking for a sponsorship to accelerate this feature[1], so if you know of someone who might be in a position to sponsor the feature, it's a very worthy project! 1. http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Type-Support-for-the-FFI http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Ty...

SomeCallMeTim 13y ago

I'm happy to see people do innovative things with programming languages. But there are a lot of people doing that right now. I didn't get a vibe from this one that it could do anything interesting that you can't already do in either LuaJIT or Julia. Other innovative languages I've been tracking include Go, D, Nimrod and Dart. The world is improved by innovations; it's not improved by script language proliferation, or "me too!" projects. Lua in particular is a very well documented language, and is the de facto standard in video game development. I think the bar has to be pretty high to justify creating a new language. Yes it would be more fun than figuring out how to get 3d matrices to work and be fast in LuaJIT, if you don't already know how the FFI works. But there's a LOT of value in using LuaJIT, and unless you're bringing something else of value to the table, no, I don't think it's worthwhile backing Yet Another Language. I know of at least a half dozen other engine-specific scripting languages, and I would wager NONE of them are as robust as Lua, as well known as Lua, as well defined as Lua, or even as well designed as Lua. The value of having a shared language does outweigh every new programmer's desire to write their own language.