LuaJIT 3.0 proposed syntax extensions
github.com
LuaJIT 3.0 proposed syntax extensions
1–10 of 170 posts
Re: LuaJIT 3.0 proposed syntax extensions
#2So is LuaJIT resuming active development after a decade or so of only maintenance? Great!
A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
Re: LuaJIT 3.0 proposed syntax extensions
#3I see JavaScript.
Some of these really look like QoL improvements. I'm not convinced ternary statements are an ergonomic improvement in particular. The examples given don't make a compelling case, 'visually tidy' is not the same as readable.
Re: LuaJIT 3.0 proposed syntax extensions
#4So is LuaJIT resuming active development after a decade or so of only maintenance? Great! A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
>TIMTOWTDI
What on earth is this supposed to mean?
Re: LuaJIT 3.0 proposed syntax extensions
#5So is LuaJIT resuming active development after a decade or so of only maintenance? Great! A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
>TIMTOWTDI What on earth is this supposed to mean?
There is more than one way to do it.
Re: LuaJIT 3.0 proposed syntax extensions
#6Looks like LuaJIT is really going to fork away from Lua this time. After these changes, it won't be a compatible Lua 5.1 implementation anymore, it will be a new language.
So shouldn't it have a new name?
Re: LuaJIT 3.0 proposed syntax extensions
#7Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.
Re: LuaJIT 3.0 proposed syntax extensions
#8So is LuaJIT resuming active development after a decade or so of only maintenance? Great! A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
>TIMTOWTDI What on earth is this supposed to mean?
There Is More Than One Way To Do It.
That takes me back a bit. It's a perl-ism. I used to think it was a great design feature but I've come to strongly prefer "There should be one way to do it, and it should be obvious"
Re: LuaJIT 3.0 proposed syntax extensions
#9I thought luajit had completely stopped feature updates
Re: LuaJIT 3.0 proposed syntax extensions
#10Earlier quoted context omitted.
>TIMTOWTDI What on earth is this supposed to mean?
There Is More Than One Way To Do It. That takes me back a bit. It's a perl-ism. I used to think it was a great design feature but I've come to strongly prefer "There should be one way to do it, and it should be obvious"
Interesting, thank you.