Windower/Lua

Bad grammar. It doesn't allow indexing literals, it does not consider unary plus to be a valid operator for numbers, it doesn't allow expression statements, it doesn't allow Lua keywords to be used as table keys in the shorthand syntax etc. Verbose syntax. All those "then", "do" and "end" tokens require a lot of typing and imo it makes the code less readable, because you have to distinguish between delimiting words and code a lot more than you have in other languages. I much prefer braces myself, or even Python's absence of delimiters due to white-space scoping. Both are both easier to write and easier to read. 1-indexing. Not only does this make some functions uncomfortable to use, it often makes them slightly slower as well, because they have to add/subtract 1 to get the desired result. There are many articles on why 0-indexing makes more sense in the programming field. Also it makes interoperability with C-side functions harder as they need to account for that difference. Default global variables. More an annoyance than a bad design choice, but it's still noticeable and has actually caused some strange bugs for us in the past that were hard to debug, because one of the libraries we wrote (since Lua doesn't ship its own) forgot one local keyword and created a global variable with the same name as one used by an addon. I find this a really strange choice, as you'll normally want most variables to be local, global variables are a rather special case. No default libraries (only a handful of string, table and system functions). Some actually consider that an advantage, because it makes Lua compact. Those people obviously don't realize that it only means that you have to write those libraries yourself and bloat it because of that regardless, only that you have to put more work into it yourself and get slower and worse code in return :) No real "no value" value. Lua's "nil" is a simple but far from ideal solution which is technically not distinct from "no value", although it claims to be and treats it like that for most cases. This causes many problems for things like table iteration, because you can't do that if the table contains nil values, as iterators will abort if they encounter one of those, because a nil value indicates a missing value to it, as such it thinks the table is fully iterated. This also means you can't have keys in tables that contain no value, because that is the same as if that table key didn't exist in the first place (since Lua considers them the same). This has been bugging me quite a bit when designing our libraries and I had to work around it with quite ugly hacks in some places. Not all operators are overload-able. The above issue would be much simpler to deal with if we could overload boolean conversion, for example, but that's a no go. Other boolean operators (and, or, not) are also not overload-able. Operators are generally a mess in Lua. Lack of a lot of common operators, like all the in-place assignment operators for one (from ++ to /=), no bitwise operators and no ternary conditional operator. And why they chose to use ~= for inequality instead of the ubiquitous != is still a mystery to me. Also, the # operator is borderline useless and not guaranteed to be constant time. No concept of table properties. This would avoid many issues of metatable design which are a bit too complex to go into here. Basically as soon as you want to give a data structure a property you're just inserting a key into that table. So that table can't, for example, have a "sort" method and at the same time contain a value with the key "sort", because "methods" are just syntactic sugar for calling a function with that specific key. So you can't effectively define methods on tables.