#author("2025-02-20T05:48:39+00:00","default:yoya","yoya")
[[Windower/Lua]]
#author("2025-02-20T06:11:28+00:00","default:yoya","yoya")
* Windower [#windower]
- [[Windower/Lua]]
- Here are some of my major dislikes with the language:
-- https://forums.windower.net/index.php@sharelink=download%3BaHR0cDovL2ZvcnVtcy53aW5kb3dlci5uZXQvaW5kZXgucGhwPy90b3BpYy82OTctbHVhLWd1aWRlLWZvci1wcm9ncmFtbWVycy8,%3BTHVhIEd1aWRlIGZvciBwcm9ncmFtbWVycw,,.html#entry4230
- 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.
>
文法が間違っています。インデックスリテラルが許可されておらず、単項プラスが数値の有効な演算子であるとは見なされず、式ステートメントが許可されておらず、Lua キーワードを短縮構文のテーブルキーとして使用することも許可されていません。
- 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.
>
冗長な構文。これらの「then」、「do」、「end」トークンはすべて、入力に多くの手間がかかるため、他の言語よりも単語とコードを区別する必要があるため、コードの可読性が低下すると思います。私は中括弧、または空白のスコープによる Python の区切り文字の不在を好みます。どちらも書きやすく、読みやすいです。
- 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.
>
1 インデックス。これにより、一部の関数が使いにくくなるだけでなく、目的の結果を得るために 1 を加算/減算する必要があるため、関数の実行速度がわずかに遅くなることもよくあります。プログラミング分野で 0 インデックスの方が理にかなっている理由については、多くの記事があります。また、その違いを考慮する必要があるため、C 側関数との相互運用性が難しくなります。
- 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.
>
デフォルトのグローバル変数。これは設計上の選択が悪いというよりはむしろ迷惑ですが、それでも目立ちますし、実際に過去にデバッグが困難な奇妙なバグを引き起こしました。これは、私たちが書いたライブラリの 1 つ (Lua は独自のものを出荷していないため) がローカル キーワードを 1 つ忘れ、アドオンで使用されるものと同じ名前のグローバル変数を作成したためです。これは本当に奇妙な選択だと思います。通常、ほとんどの変数はローカルにしたいものですが、グローバル変数はかなり特殊なケースです。
- 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 :)
>
デフォルトのライブラリはありません (文字列、テーブル、システム関数がいくつかあるだけです)。これは Lua をコンパクトにするため、実際に利点であると考える人もいます。これらの人々は、それが単に自分でライブラリを書かなければならず、そのせいでとにかく肥大化してしまうこと、つまり自分でより多くの作業を行う必要があり、代わりに遅くて質の悪いコードになるだけであることを理解していないのは明らかです。:)
- 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.
>
本当の「値なし」値はありません。Lua の「nil」は、単純ですが理想的なソリューションからは程遠く、技術的には「値なし」と区別できませんが、ほとんどの場合、そのように扱われます。これは、テーブル反復処理などで多くの問題を引き起こします。テーブルに nil 値が含まれている場合は、反復処理を実行できないためです。反復処理は、nil 値に遭遇すると中止します。nil 値は、テーブルが完全に反復処理されたと認識されるため、テーブルに nil 値が含まれている場合は実行できません。これは、テーブル キーが最初から存在しなかったのと同じであるためです (Lua はそれらを同じと見なすため)。これは、ライブラリを設計するときにかなり悩まされ、いくつかの場所ではかなり醜いハックで回避する必要がありました。
- 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.
>
すべての演算子がオーバーロード可能というわけではありません。たとえば、ブール変換をオーバーロードできれば、上記の問題に対処するのははるかに簡単になりますが、それは不可能です。その他のブール演算子 (and、or、not) もオーバーロードできません。
- 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.
>
Lua の演算子は、一般的に混乱しています。1 に対するすべてのインプレース代入演算子 (++ から /= まで) などの一般的な演算子が不足しており、ビット演算子や三項条件演算子はありません。また、不等号に、よく使われる != ではなく ~= を使用する理由も、いまだに私には謎です。また、# 演算子は、ほとんど役に立たず、一定時間で実行されることが保証されていません。
- 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.
>
テーブル プロパティの概念はありません。これにより、ここで説明するには少々複雑すぎるメタテーブル設計の多くの問題を回避できます。基本的に、データ構造にプロパティを与えたいときは、そのテーブルにキーを挿入するだけです。したがって、たとえば、そのテーブルに「sort」メソッドがあり、同時にキー「sort」を持つ値を含めることはできません。「メソッド」は、特定のキーを使用して関数を呼び出すための単なる構文上の糖衣であるためです。したがって、テーブルでメソッドを効果的に定義することはできません。
