> For compatibility with other computer languages, the following classic Lua operators can be written in a more customary syntax:
Why though? What does changing `and` to `&&` actually achieve? Were people confused?
Changing the syntax seems very surface level. It's not actually fixing any problems, just making Lua no longer look like Lua. It's not going to help anyone write/learn Lua. It will make everything more complicated as there are now two ways to do everything.
This feels like adding braces to Python because you don't like indenting your code.
Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.
In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.
I've always found it odd that and/or in Ruby isn't just considered equal to &&/||, and I have never really used the english operators except for the usual modifiers like if and unless.
What is a practical use case where the lower precedence makes sense?
A comment <https://github.com/LuaJIT/LuaJIT/issues/1475#issuecomment-47...> has already been made on the issue regarding the ternary operator, recommending `if x then y else z` over `x ? y : z`. This is exactly how it's done with if-then-else expressions in Luau <https://luau.org/syntax/#if-then-else-expressions>, another language compatible with Lua, and makes it a ton easier to nest (especially with elseif) and I believe still easier to read than `y if x else z`.
Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.
LuaJIT has held back the lua ecosystem for over a decade. There's no reason to not at least try to move the implementation closer to luau or puc lua, not create yet more incompatible syntax
Looks like LuaJIT is catching up, but calling these "syntax extensions" is confusing. Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) and adopt newer syntax piecemeal?
I welcome the compound assignment operators. Playdate's version of Lua also has that extension.
LuaJIT is an involuntary fork of 5.1. It already had various extensions that conflicted with the 5.2 implementation of the same features, and Mike Pall made it clear on the mailing list he wasn't going to change how LuaJIT worked.
So 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.
A bunch of them are from Luau, the Roblox fork of Lua and the dialect most young programmers know. Adding them to LuaJIT will make it easier to write for both Zoomers and AI agents, who have been exposed to a lot of Luau code.
I know the LuaJIT maintainer(s?) will never add it because it's too radical a departure from Lua but I wish they would include Luau's type annotations. There are typed languages like Teal that will compile to Lua that should work (although I've had a difficult time getting Teal to work with cdefs) and you can kind of fake it by using C structs obviously but having such a feature be native to Lua itself would be nice.
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"
One of the interesting things about Lua is because they don't really maintain compatibility between major versions, there isn't a huge ecosystem, and as a result there's less friction against making your own, slightly incompatible version. When you add on the simplicity of implementing the language, it's created a really diverse set of lua-alikes. Weird (and cool) for a language to have a diverse ecosystem of implementations, but not necessarily libraries.
Tangently related but I’ve been deep in Lua recently working on a rust implementation that supports Lua 5.1-5.5 in one Rust Binary https://github.com/ianm199/omnilua.
My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
Also, one issue I have with this repo is that, since so much of it seems to use Claude, as an actual human I struggle to read and parse any of the information.
In a mix of official and unofficial benchmarks wall clock performance is ~1.4x as fast as C Lua and the memory usage is ~1.7x.
So performance is worse to be clear but within range. There’s some performance improvements I haven’t gone for yet that would get it down to ~1.1 I think.
This is amazing! Can a program call across versions? Like could we take a Lua 5.1 codebase and upgrade only a portion of it at a time to a new Lua version?
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.
I kinda have seen somewhere on internet, that the language design of lua and js(well, ecmascript to be precise) is somehow related. But can't really find the exact reference I have seen.. it was long time ago when I read this.
There's some overlap in the languages they were inspired by (eg Scheme, or the chains Modula -> Lua vs Modula -> Java -> Javascript), but as far as I'm aware, the original designs were made independently.
Now, the object systems do look similar, but that seems to be a case of convergent evolution: Javascript took direct inspiration from Self, whereas Lua's system is based on a more generic fallback mechanism for table access.
Never 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.
This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.
I guess for the JS case it makes sense to be able to shave a few characters for file shrinking purposes, but generally I'm more biased to code clarity and "self-explainability"
I find it most useful in languages that have non-mutable variables and you want to avoid a mutable variable or an extra function when the value comes from a simple condition.
Looks 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.
It might have been better to publicly document and stabilise the LuaJIT bytecode, which would allow people to then come up with whatever syntax they wanted in their own custom frontends.
They shouldn't add the ternary operator, it keeps `?` from being usable on it's own for safe navigation and requires the ugly `?.` operator, like `a?.[b]` or `f?.()` instead of `a?[b]` or `f?()`.
I imagine these changes make the original Lua adepts think their training wheels have come off. The language now looks like any other. That's a good thing to me, and it will help with the adoption of the JIT, but the whole language could have been syntax modernized as a result. But.. when the work is done someone else can fork it into something independent from its Lua roots.
From that perspective the conditional operator seems defensible, where it would be feature creep otherwise, as it is generally unloved elsewhere.
I would love to see all of these come to LuaJIT (and love2d to support the new version too). It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too
> It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too
But which Lua?
Lua as implemented by LuaJIT is a fork of the language at this point. It's not fully compatible with PUC Lua (the reference implementation) and LuaJIT does not support features from the latest Lua version.
He left for a break, returned and there was no second break or anything.
I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.
Please don't, inscrutable bitwise operators are an accident of the past even in systems languages, let alone in a scripting language. I'm not against infix operators for bitwise operations, just please spell them out with keywords rather than giving them sigils.
Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.
It's not about having to remember them, it's that you shouldn't waste these short single symbols on operations that are only rarely used.
This stuff (especially the ternary) are a step backwards. There is just no reason to waste | on a bitwise or that gets used at 1% of the frequency of the standard or. In the future you might have a better use for it (pipeline syntax, sum or union types come to mind in other languages).
I dislike basically everything about these syntax extensions.
I'm going to disagree only because one of the primary use cases for LuaJIT is interop with C and I think there's a case for making the ergonomics match.
What’s the Lua/LuaJIT story these days for bundling up all the scripts of an application into a single file? Is there a way to do the super convenient go-like thing?
There's a bunch of options from a Google search, but embedding it in a thin C program and building that with https://github.com/jart/cosmopolitan would be a pretty go-like experience, I'd think.
I personally use a hand-written C wrapper program (which is not much more than a dozen lines long), and then embed the Lua scripts using objdump. This isn't quite as easy as Go since cross-compiling C programs is often somewhat tricky, but Lua is very portable and has zero dependencies, so it's usually not too hard.
There was a Lua[JIT] fork called Idle that seems to have fallen off the face of the Earth that did exactly that: it would take a small stub program, a runtime library and all the scripts and package them into a single PE/COFF binary that would read itself when run.
Love2D does it as well:
zip -9 -r SuperGame.love .
cat love.exe SuperGame.love > SuperGame.exe
Cool to see this - ergonomic syntax will make it easier to recommend Lua. Hope the PUC team aligns with this.
Also, I love this kind of pragmatism:
> Exponentiation assignment a ^= b has been deliberately omitted to avoid a predictable pitfall: this is how xor assignment is written in most other computer languages. Also, a syntax for exponentiation assignment is rarely asked for.
A ‘defer’ for closing files or deleting temp files at the end of a script will make life more enjoyable.
Yeah, "?." as safe navigation operator even in JS where it already exists is eye-sore. They could use some other single character instead of two characters. Question mark is already doing a lot with ternaries etc.
Instead of obj?.:method?.(…) it would be like obj#:method#(…)
Replace # with your favorite extra character instead of questionmark.
Lua has a lot of useless syntax. For instance, the "then". I have been using ruby and python for many years. Lua is living in the old age here.
That's just one example of so many more. I get that lua occupies a useful niche with its focus on embedded systems, but lua is not really a well-designed language in general. JavaScript has a similar problem.
> For compatibility with other computer languages, the following classic Lua operators can be written in a more customary syntax:
Why though? What does changing `and` to `&&` actually achieve? Were people confused?
Changing the syntax seems very surface level. It's not actually fixing any problems, just making Lua no longer look like Lua. It's not going to help anyone write/learn Lua. It will make everything more complicated as there are now two ways to do everything.
This feels like adding braces to Python because you don't like indenting your code.
> This feels like adding braces to Python because you don't like indenting your code.
Now this I can get behind...
You need Bython https://github.com/mathialo/bython
Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.
In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.
Same in Perl, hence the good old pattern:
1 reply →
I've always found it odd that and/or in Ruby isn't just considered equal to &&/||, and I have never really used the english operators except for the usual modifiers like if and unless.
What is a practical use case where the lower precedence makes sense?
> Why though? What does changing `and` to `&&` actually achieve? Were people confused?
Also consider AI, that has a greater training base of JavaScript than Lua. So making Lua look more like JS, should improve output and reduce mistakes.
No, don't consider AI.
AI has greater training on Python, which uses `and` and `or`, and it has absolutely no issue keeping that straight.
A comment <https://github.com/LuaJIT/LuaJIT/issues/1475#issuecomment-47...> has already been made on the issue regarding the ternary operator, recommending `if x then y else z` over `x ? y : z`. This is exactly how it's done with if-then-else expressions in Luau <https://luau.org/syntax/#if-then-else-expressions>, another language compatible with Lua, and makes it a ton easier to nest (especially with elseif) and I believe still easier to read than `y if x else z`.
Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.
The ternary operator is easy to nest if you put each clause on a separate line. Then it looks just like nested if-then-else.
I love the ternary operator as much as anyone. But dang if it doesn't get hard to read when there is are a few, nested even.
Does that operator compile to faster assembly that if I make the same logic with verbose `if` logic? Is that a language specific outcome?
3 replies →
Unless you mess up its associativity, like PHP until 7.4.
https://wiki.php.net/rfc/ternary_associativity
http://phpsadness.com/sad/30
LuaJIT has held back the lua ecosystem for over a decade. There's no reason to not at least try to move the implementation closer to luau or puc lua, not create yet more incompatible syntax
Lua 5.3 (2015-01-12) added the bitwise operators:
https://www.lua.org/versions.html#5.3
https://www.lua.org/manual/5.3/manual.html#3.4.2
Looks like LuaJIT is catching up, but calling these "syntax extensions" is confusing. Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) and adopt newer syntax piecemeal?
I welcome the compound assignment operators. Playdate's version of Lua also has that extension.
LuaJIT is an involuntary fork of 5.1. It already had various extensions that conflicted with the 5.2 implementation of the same features, and Mike Pall made it clear on the mailing list he wasn't going to change how LuaJIT worked.
So 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.
A bunch of them are from Luau, the Roblox fork of Lua and the dialect most young programmers know. Adding them to LuaJIT will make it easier to write for both Zoomers and AI agents, who have been exposed to a lot of Luau code.
I know the LuaJIT maintainer(s?) will never add it because it's too radical a departure from Lua but I wish they would include Luau's type annotations. There are typed languages like Teal that will compile to Lua that should work (although I've had a difficult time getting Teal to work with cdefs) and you can kind of fake it by using C structs obviously but having such a feature be native to Lua itself would be nice.
>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"
2 replies →
There is more than one way to do it.
One of the interesting things about Lua is because they don't really maintain compatibility between major versions, there isn't a huge ecosystem, and as a result there's less friction against making your own, slightly incompatible version. When you add on the simplicity of implementing the language, it's created a really diverse set of lua-alikes. Weird (and cool) for a language to have a diverse ecosystem of implementations, but not necessarily libraries.
Tangently related but I’ve been deep in Lua recently working on a rust implementation that supports Lua 5.1-5.5 in one Rust Binary https://github.com/ianm199/omnilua.
My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
Also, one issue I have with this repo is that, since so much of it seems to use Claude, as an actual human I struggle to read and parse any of the information.
For example, what’s the performance like?
Performance dashboard is linked here https://ianm199.github.io/omnilua/performance.html.
In a mix of official and unofficial benchmarks wall clock performance is ~1.4x as fast as C Lua and the memory usage is ~1.7x.
So performance is worse to be clear but within range. There’s some performance improvements I haven’t gone for yet that would get it down to ~1.1 I think.
Oh wow, seriously, I always thought Lua should have been like this. The 5.1/5.2/5.3+ split was so painful.
> My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
I think you could stop right before the syntax extension.
This is amazing! Can a program call across versions? Like could we take a Lua 5.1 codebase and upgrade only a portion of it at a time to a new Lua version?
[dead]
I 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.
Worse, I see C (as in ! or &&), and Perl (as in manifestly more than one way to do it).
There are real improvements though, such as ?. and ??= that help with default-nullable everything.
Ternary is very useful, but it I'd rather see it implemented idiomatically:
Structural pattern-matching could be fantastic, but no syntax is suggested.
I kinda have seen somewhere on internet, that the language design of lua and js(well, ecmascript to be precise) is somehow related. But can't really find the exact reference I have seen.. it was long time ago when I read this.
There's some overlap in the languages they were inspired by (eg Scheme, or the chains Modula -> Lua vs Modula -> Java -> Javascript), but as far as I'm aware, the original designs were made independently.
Now, the object systems do look similar, but that seems to be a case of convergent evolution: Javascript took direct inspiration from Self, whereas Lua's system is based on a more generic fallback mechanism for table access.
Lua to me always felt very JavaScripty, just with a different syntax.
Never 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.
That’s why “if” should just be an expression
This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.
4 replies →
Yep. Everything should be.
Lua basically already has ternary operators anyway since "and" and "or" short circuit. I also don't see the need of adding additional syntax for it.
> The classic Lua idiom a and b or c has a pitfall when b is nil or false: then c is returned, even when a is truthy.
> E.g. true and false or 42 returns 42, whereas true ? false : 42 returns the (expected) false.
I guess for the JS case it makes sense to be able to shave a few characters for file shrinking purposes, but generally I'm more biased to code clarity and "self-explainability"
That’s what compression is for.
I find it most useful in languages that have non-mutable variables and you want to avoid a mutable variable or an extra function when the value comes from a simple condition.
For others interested in alternative syntax to the Lua VM/API sometime ago I've created LJS https://github.com/mingodad/ljs and also https://github.com/mingodad/ljsjit, I've also included an utility lua2ljs program based on the Lemon parser and re2c that convert Lua scripts to LJS with line by line synchronization https://github.com/mingodad/ljs/tree/master/lua2ljs, to test it I've also translated a few non trivial projects (https://github.com/mingodad/ZeroBraneStudioLJS , https://github.com/mingodad/raptorjit-ljs, https://github.com/mingodad/snabb-ljs, https://github.com/mingodad/premake-core/tree/ljs, https://github.com/mingodad/CorsixTH-ljs).
I'm proud of it and thankfull to the Lua/Luajit projects.
Looks 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?
Why won't it be compatible? Any code written in Lua 5.1 will run on LuaJIT.
well, it doesn’t say Lua5.1-JIT
It could be opt in.
Are there any rough estimates on popularity of lua implementations? At this point it feels lua means luajit
not even close, because there are a lot of places where you can't run LuaJIT
4 replies →
It might have been better to publicly document and stabilise the LuaJIT bytecode, which would allow people to then come up with whatever syntax they wanted in their own custom frontends.
They shouldn't add the ternary operator, it keeps `?` from being usable on it's own for safe navigation and requires the ugly `?.` operator, like `a?.[b]` or `f?.()` instead of `a?[b]` or `f?()`.
Yep. This is awful:
+= and ..= are things i find i'm constantly missing in lua.
Personally im a fan of introducing ternaranary operator in lua. Everyone uses `x and y or z` as a ternanary which i find way more confusing than ?:
Lua pursues "simplicity, purity, and simplicity." So... too much syntactic sugar is unlikely
Seems like a bad idea to actively diverge from Lua, hostile even, especially without at least a clear change of name.
extensions are detachable/optional, those arent extensions but features
I thought luajit had completely stopped feature updates
> local gauge = direction == "up" ? count + 10 : count - 10
local gauge = count + (direction == "up" ? 10 : -10)
I imagine these changes make the original Lua adepts think their training wheels have come off. The language now looks like any other. That's a good thing to me, and it will help with the adoption of the JIT, but the whole language could have been syntax modernized as a result. But.. when the work is done someone else can fork it into something independent from its Lua roots.
From that perspective the conditional operator seems defensible, where it would be feature creep otherwise, as it is generally unloved elsewhere.
I would love to see all of these come to LuaJIT (and love2d to support the new version too). It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too
> It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too
But which Lua?
Lua as implemented by LuaJIT is a fork of the language at this point. It's not fully compatible with PUC Lua (the reference implementation) and LuaJIT does not support features from the latest Lua version.
LuaJIT of course.
Is LuaJIT still based on Lua5.1? I wonder why they haven't followed the language spec up to Lua5.5.
Because they don't like the changes, to put it mildly.
I’m confused I thought Mike Pall left luajit and Laurence Tratt took over as maintainer?
He left for a break, returned and there was no second break or anything.
I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.
Are there great uses of LuaJIT out there? It was such a big thing before fast JS engines IIRC.
Mike Pall is to LuaJIT as PG is to Hacker News.
Edit: meaning he can come back anytime.
Please don't, inscrutable bitwise operators are an accident of the past even in systems languages, let alone in a scripting language. I'm not against infix operators for bitwise operations, just please spell them out with keywords rather than giving them sigils.
Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.
What kind of person understands and needs bitwise operators but can't easily remember & | ~ and the arrows for shift? It's very little information.
The part I'd call a hassle is the different kinds of right shift but you have that same hassle if you use keywords.
I like using the and/or keywords for logical operations. Now let's make bitwise look significantly different from that.
It's not about having to remember them, it's that you shouldn't waste these short single symbols on operations that are only rarely used.
This stuff (especially the ternary) are a step backwards. There is just no reason to waste | on a bitwise or that gets used at 1% of the frequency of the standard or. In the future you might have a better use for it (pipeline syntax, sum or union types come to mind in other languages).
I dislike basically everything about these syntax extensions.
You can have them in C/C++ at least [1]
[1] https://en.cppreference.com/cpp/language/operator_alternativ...
I'm going to disagree only because one of the primary use cases for LuaJIT is interop with C and I think there's a case for making the ergonomics match.
Doesn't Zig also have bitwise operators?
The btiwise operators library doesn’t go away
What’s the Lua/LuaJIT story these days for bundling up all the scripts of an application into a single file? Is there a way to do the super convenient go-like thing?
There's a bunch of options from a Google search, but embedding it in a thin C program and building that with https://github.com/jart/cosmopolitan would be a pretty go-like experience, I'd think.
I personally use a hand-written C wrapper program (which is not much more than a dozen lines long), and then embed the Lua scripts using objdump. This isn't quite as easy as Go since cross-compiling C programs is often somewhat tricky, but Lua is very portable and has zero dependencies, so it's usually not too hard.
There was a Lua[JIT] fork called Idle that seems to have fallen off the face of the Earth that did exactly that: it would take a small stub program, a runtime library and all the scripts and package them into a single PE/COFF binary that would read itself when run.
Love2D does it as well: zip -9 -r SuperGame.love . cat love.exe SuperGame.love > SuperGame.exe
This doesn't work with ELF files, though.
Cool to see this - ergonomic syntax will make it easier to recommend Lua. Hope the PUC team aligns with this.
Also, I love this kind of pragmatism:
> Exponentiation assignment a ^= b has been deliberately omitted to avoid a predictable pitfall: this is how xor assignment is written in most other computer languages. Also, a syntax for exponentiation assignment is rarely asked for.
A ‘defer’ for closing files or deleting temp files at the end of a script will make life more enjoyable.
In aggregate this looks like a godsend, but there are some examples (like foo?.:method) that looks atrocious.
Yeah, "?." as safe navigation operator even in JS where it already exists is eye-sore. They could use some other single character instead of two characters. Question mark is already doing a lot with ternaries etc.
Instead of obj?.:method?.(…) it would be like obj#:method#(…)
Replace # with your favorite extra character instead of questionmark.
Is there any reason why they're not considering a single '?' like rust? Is it a parsing issue?
So you'd have: obj?:method(…)
What are some pragmatic embedded scripting languages of choice these days if one has to consider:
1) Ease of learning, ideally minimal deviant behaviour (eg i consider lua tables to be a new concept in itself)
2) Reasonably fast. Not as much as lua jit but even half would be good enough
3) Mature
4) Has Rust bindings
Lua. Lua tables are easy and awesome. My hobby language unites Lua tables with functions too.
[dead]
Lua has a lot of useless syntax. For instance, the "then". I have been using ruby and python for many years. Lua is living in the old age here.
That's just one example of so many more. I get that lua occupies a useful niche with its focus on embedded systems, but lua is not really a well-designed language in general. JavaScript has a similar problem.
For readability, `then` allows splitting with newlines very long conditional expressions, without having to wrap the condition in parentheses:
after `if` and `elseif` the parser simply goes on until it finds `then`.
Python spells "then" as ":"
In Ruby you can choose between "then" and a newline.
This is very pot calling the kettle black.
English too
[dead]