1. Современный Луа очень гибкий и поддерживает кучу разных подходов к написанию программ. В том числе и честный ООП. Если очень хочется его получить, welcome. Но, как с любым другим языком, на Луа лучше всего писать программы в его собственной, «луашной» стилистике.
В моей практике мне не хватало честного наследования всего пару раз. Утиная типизация вместе с метатаблицами решают.
2. Если смотреть с точки зрения mainstream-языков, таких как C++, C#, Java… в синтаксисе Луа действительно есть свои «странности». Нужно просто помнить, что Луа — другой язык, и всего лишь к ним привыкнуть.
Большинству «странностей» имеется серьёзное объяснение почему сделано именно так а не иначе. Объяснение с позиций сбалансированности всех аспектов языка, включая удобство пользователя, однозначность синтаксиса и максимальную простоту и скорость работы его реализации.
Это Ваше личное мнение. Такое ощущение, что речь всё ещё про Луа 4.х. :-)
Моё личное мнение — более изящного, «некорявого», а, главное, сбалансированного языка чем Луа 5.1 я не встречал.
Ошибки скриптинга отлавливаются шикарно. Нужно просто уметь их ловить. Могу ответить на конкретные вопросы.
Бридж к ObjectiveC к Луа как к языку не имеет никакого отношения вообще. Чистый Луа предоставляет механизм для биндинга в plain C (и, на правах бедного родственника, в C++).
Всё, что сверх этого — надстройки, которые часто пишутся обычно для удовлетворения частных нужд разработчика.
Да, есть приличные бриджи (либо альтернативные реализации VM) в .Net, в Java, в Perl. Кое-какой бридж в Active script.
Если бридж ObjectiveC тёк, это — проблема бриджа а не языка. Можно написать свой.
Пункты 1 и 2 — вкусовщина ИМХО. У меня лично никогда серьёзных проблем ни с тем ни с другим не было, всё шикарно обходится.
Пункт 3 — неправда. Луашные таблицы и есть массивы (и, одновременно, хеш-таблицы). Даже на низком уровне — то есть без пенальти по скорости. Наличие выделенного типа «массив» никаких бенефитов не даёт.
1. Современный Луа очень гибкий и поддерживает кучу разных подходов к написанию программ. В том числе и честный ООП. Если очень хочется его получить, welcome. Но, как с любым другим языком, на Луа лучше всего писать программы в его собственной, «луашной» стилистике.
В моей практике мне не хватало честного наследования всего пару раз. Утиная типизация вместе с метатаблицами решают.
2. Если смотреть с точки зрения mainstream-языков, таких как C++, C#, Java… в синтаксисе Луа действительно есть свои «странности». Нужно просто помнить, что Луа — другой язык, и всего лишь к ним привыкнуть.
Большинству «странностей» имеется серьёзное объяснение почему сделано именно так а не иначе. Объяснение с позиций сбалансированности всех аспектов языка, включая удобство пользователя, однозначность синтаксиса и максимальную простоту и скорость работы его реализации.
Много чего по теме можно почерпнуть из http://www.lua.org/doc/hopl.pdf и The implementation of Lua 5.0.
Моё личное мнение — более изящного, «некорявого», а, главное, сбалансированного языка чем Луа 5.1 я не встречал.
Ошибки скриптинга отлавливаются шикарно. Нужно просто уметь их ловить. Могу ответить на конкретные вопросы.
Бридж к ObjectiveC к Луа как к языку не имеет никакого отношения вообще. Чистый Луа предоставляет механизм для биндинга в plain C (и, на правах бедного родственника, в C++).
Всё, что сверх этого — надстройки, которые часто пишутся обычно для удовлетворения частных нужд разработчика.
Да, есть приличные бриджи (либо альтернативные реализации VM) в .Net, в Java, в Perl. Кое-какой бридж в Active script.
Если бридж ObjectiveC тёк, это — проблема бриджа а не языка. Можно написать свой.
2 — Определение «левости» синтаксиса в студию. Либо конкретные примеры.
3 — Мы всё ещё про 5.x говорим? Если да, идём учить матчасть (в данном случае раздел 4).
Если пишешь биндинги под себя, используй стандартный Lua C API. Если им проникнуться, лучшего средства нет.
Если нужны биндинги для какой-нибудь монструозной сторонней библиотеки, используй генератор биндингов (например tolua).
Пункт 3 — неправда. Луашные таблицы и есть массивы (и, одновременно, хеш-таблицы). Даже на низком уровне — то есть без пенальти по скорости. Наличие выделенного типа «массив» никаких бенефитов не даёт.