Вот именно, это не библиотека получится, а фреймворк. А со фреймворками как раз обычно так и получается — нельзя использовать одновременно две штуки. :-)
Проверка контракта — да, полезно. Только в нашем случае к ООП не имеет особого отношения. Проверка должна быть не «наследуется от интерфейса», а «реализует указанный протокол».
Мне кажется, что обычно, в режиме когда нет времени на изучение новой технологии, лучше эту технологию отложить на потом, и пользоваться «дедовскими методами». Потом обычно меньше негативных эмоций остаётся. ;-)
1. (Главная и прагматическая) Реюз имеющегося специализированного луашного кода во флеше, чтобы не решать дважды одни и те же проблемы на клиенте (Флеш) и на сервере (Луа). (Довольно медленно, но для этих задач скорость не настолько важна.)
2. Некоторые флешеры (в частности, мой коллега по проекту) считают, что для части задач Actionscript слишком статичен. Луа — более динамический язык, на нём проще писать. Я — не флешер и люблю Луа, так что мне тяжело быть объективным в этом вопросе.
3. Пользовательский скриптинг (конструкторы игр; скриптуемые приложения на Air, в природе уже есть несколько на нашей технологии). Весь мой опыт говорит о том, что Луа более доступен неопытному пользователю чем язык типа Actionscript.
Имеется в виду не число ниток, а число одновременных запросов. С низким числом запросов высоки шансы, что ни один так и не выполнится одновременно с другим.
Во-первых, кривая обучения языку и простота работы с ним, всё-таки, разные вещи. И синтаксис здесь далеко не первый вопрос.
Например, вне зависимости от синтаксиса, первые программы опытного PHP-шника на Луа не будут эффективными (обратное тоже верно) — языки слишком по-разному работают со строками.
У любого языка есть свои особенности. Пока человек не изучил их в достаточной степени, нельзя говорить, что он эффективно использует этот язык.
Во-вторых, мне, лично, разница в синтаксисе серьёзно помогает.
Когда я пишу одновременно на плюсах и на Луа, я регулярно пытаюсь написать в Луа фигурную скобку (или пропустить двоеточие) а в плюсах написать then. Я натыкаюсь на эту ошибку (часто даже до компиляции), и у меня сразу в голове происходит переключение на нужный контекст (которое почему-то не произошло раньше).
Можно попробовать писать в одном стиле, например, на плюсах и на Яве и не думать про переключение между языками. Только вот результат будет весьма посредственным.
Если уж так часто лезут эти ошибки — соответствующий статический валидатор кода на Металуа пишется достаточно тривиально.
Можно обойтись и рантайм-валидацией (я так делаю) — просто всегда проверять ассертом что self — это таблица. 80% опечаток это вылавливает.
1. Это зависит не от наличия или отсутствия ООП, а от программистов.
Копи-пейст (раз уж мы говорим об объёмах кода), например, у нас присутствовал в проекте в обычных (небольших) масштабах. И не из-за особенностей Луа, а из-за обычной программистской лени (либо авральности выполнения конкретной задачи). На плюсах или Яве было бы то же самое.
Другое дело, что, если бы, например, в Луа был ООП, но не было бы, скажем, замыканий и функций — значения первого класса, то было бы не 160 KLOC, а все 500.
(Хочу заметить в скобках, что, ИМХО, всё-таки не эмуляции ООП, а его реализации.)
Если уж вдруг во внешнем интерфейсе луашного модуля так сильно нужен ООП… (Для чего? Высунуть «класс», чтобы можно было от него наследоваться? Зачем?)… И стоит задача сделать это максимально «стандартно» — пожалуйста, есть LOOP — «полуофициальная» реализация объектной модели на Луа.
Я с Луа уже лет пять, написал приличное количество сложного кода — и мне вполне достаточно тех механизмов, что она мне даёт.
Да, кое-что (не так уж много, на самом деле) приходится писать самому, но механизмы для этого в большинстве случаев весьма удобны, и позволяют достаточно быстро получить нужную функциональность в таком виде, как это нужно мне для решения данной конкретной задачи.
Опять же, нет желания писать самому — возьми у коллег. Для Луа сейчас доступно огромное количество открытого кода.
Для некоторых этот подход неприемлем, хочется прийти и сразу заниматься постройкой бизнес-логики под задачу, а не наворачивать фреймворк — ну что ж, это зависит от задачи и от подхода к работе.
Я вполне признаю валидность такого подхода и, действительно, тогда уж лучше взять, например, Питон или Руби или, скажем, Яву и Шарп.
Но для себя, на данный момент, я вижу именно в Луа наилучшее сочетание качества (фичей) и цены (скорости написания кода и скорости работы этого кода) для написания бизнес-логики.
Никто и не обещал, что будет легко. Проблема скрещивания двух разных GC вообще вещь нетривиальная (хотя вот, например, нам, вроде бы, удалось скрестить луашку с AS3 без особых проблем).
В любом случае это не значит, что Луа вообще нельзя пользоваться :-)
Вот, кстати, недавно появился новый биндинг Lua-ObjectiveC (правда для айфона): Wax. Может быть там найдёте что-то полезное.
Утверждение некорректно как с точки зрения Луа как языка, так и с точки зрения конкретной реализации.
Если говорить о Луа как о языке, в Луа нет ни массивов ни хеш-таблиц. Есть один, универсальный тип данных — table (таблица). Его можно использовать как array, dictionary, set, list, queue, record и т.п. (прошу прощения, неуверен в русскоязычной терминологии). Table может быть как чем-то одним из этого списка, так и несколькими вещами сразу (например, в моём коде достаточно часто встречается комбинация array и record). Луашные таблицы — мощнейшее выразительное средство, один из краеугольных камней всего языка.
Если же говорить о конкретной реализации, то каждая луашная таблица одновременно содержит в себе как хеш-таблицу, так и массив. Виртуальная машина прозрачно и по достаточно чётко описанным правилам выбирает, куда класть данные. Если лень копаться в коде, всё написано доступным языком в двух абзацах четвёртого раздела The implementation of Lua 5.0, на который я уже давал ссылку.
Да, индексация с единицы и неоднозначность размера у массивов с дырками действительно по началу сбивают с толку.
Но оно того стоит, и с этим можно жить, и жить счастливо.
Смертельных проблем с JSON-ом я не вижу. Главное не пытаться использовать ipairs/table.concat/unpack/# и т.п. там, где этого не стоит делать. Если есть какой-то конкретный вопрос, готов помочь.
А, вообще, мне попадалось достаточно много готовых луашных библиотек для работы с JSON-ом. Вот, например: http://github.com/harningt/luajson
В моей практике писать скрипты на языке со статической типизацией можно заставить только достаточно ограниченный круг лиц. (Если пользователи — программисты на C#, тогда да, конечно, решение идеальное.)
Проверка контракта — да, полезно. Только в нашем случае к ООП не имеет особого отношения. Проверка должна быть не «наследуется от интерфейса», а «реализует указанный протокол».
Но Руби слишком медленный для моих задач, а для эрланга слишком тяжело найти программистов. Спасает то, что Луа — где-то между ними. :-)
Мне кажется, что обычно, в режиме когда нет времени на изучение новой технологии, лучше эту технологию отложить на потом, и пользоваться «дедовскими методами». Потом обычно меньше негативных эмоций остаётся. ;-)
Всё-таки, мне кажется, утиная типизация должна снимать вопрос с интерфейсами.
1. (Главная и прагматическая) Реюз имеющегося специализированного луашного кода во флеше, чтобы не решать дважды одни и те же проблемы на клиенте (Флеш) и на сервере (Луа). (Довольно медленно, но для этих задач скорость не настолько важна.)
2. Некоторые флешеры (в частности, мой коллега по проекту) считают, что для части задач Actionscript слишком статичен. Луа — более динамический язык, на нём проще писать. Я — не флешер и люблю Луа, так что мне тяжело быть объективным в этом вопросе.
3. Пользовательский скриптинг (конструкторы игр; скриптуемые приложения на Air, в природе уже есть несколько на нашей технологии). Весь мой опыт говорит о том, что Луа более доступен неопытному пользователю чем язык типа Actionscript.
Во-первых, кривая обучения языку и простота работы с ним, всё-таки, разные вещи. И синтаксис здесь далеко не первый вопрос.
Например, вне зависимости от синтаксиса, первые программы опытного PHP-шника на Луа не будут эффективными (обратное тоже верно) — языки слишком по-разному работают со строками.
У любого языка есть свои особенности. Пока человек не изучил их в достаточной степени, нельзя говорить, что он эффективно использует этот язык.
Во-вторых, мне, лично, разница в синтаксисе серьёзно помогает.
Когда я пишу одновременно на плюсах и на Луа, я регулярно пытаюсь написать в Луа фигурную скобку (или пропустить двоеточие) а в плюсах написать then. Я натыкаюсь на эту ошибку (часто даже до компиляции), и у меня сразу в голове происходит переключение на нужный контекст (которое почему-то не произошло раньше).
Можно попробовать писать в одном стиле, например, на плюсах и на Яве и не думать про переключение между языками. Только вот результат будет весьма посредственным.
Если уж так часто лезут эти ошибки — соответствующий статический валидатор кода на Металуа пишется достаточно тривиально.
Можно обойтись и рантайм-валидацией (я так делаю) — просто всегда проверять ассертом что self — это таблица. 80% опечаток это вылавливает.
Вот мой велосипед:
function foo:method(bar) method_arguments( self, "number", bar ) endКопи-пейст (раз уж мы говорим об объёмах кода), например, у нас присутствовал в проекте в обычных (небольших) масштабах. И не из-за особенностей Луа, а из-за обычной программистской лени (либо авральности выполнения конкретной задачи). На плюсах или Яве было бы то же самое.
Другое дело, что, если бы, например, в Луа был ООП, но не было бы, скажем, замыканий и функций — значения первого класса, то было бы не 160 KLOC, а все 500.
Если уж вдруг во внешнем интерфейсе луашного модуля так сильно нужен ООП… (Для чего? Высунуть «класс», чтобы можно было от него наследоваться? Зачем?)… И стоит задача сделать это максимально «стандартно» — пожалуйста, есть LOOP — «полуофициальная» реализация объектной модели на Луа.
Я с Луа уже лет пять, написал приличное количество сложного кода — и мне вполне достаточно тех механизмов, что она мне даёт.
Да, кое-что (не так уж много, на самом деле) приходится писать самому, но механизмы для этого в большинстве случаев весьма удобны, и позволяют достаточно быстро получить нужную функциональность в таком виде, как это нужно мне для решения данной конкретной задачи.
Опять же, нет желания писать самому — возьми у коллег. Для Луа сейчас доступно огромное количество открытого кода.
Для некоторых этот подход неприемлем, хочется прийти и сразу заниматься постройкой бизнес-логики под задачу, а не наворачивать фреймворк — ну что ж, это зависит от задачи и от подхода к работе.
Я вполне признаю валидность такого подхода и, действительно, тогда уж лучше взять, например, Питон или Руби или, скажем, Яву и Шарп.
Но для себя, на данный момент, я вижу именно в Луа наилучшее сочетание качества (фичей) и цены (скорости написания кода и скорости работы этого кода) для написания бизнес-логики.
В любом случае это не значит, что Луа вообще нельзя пользоваться :-)
Вот, кстати, недавно появился новый биндинг Lua-ObjectiveC (правда для айфона): Wax. Может быть там найдёте что-то полезное.
Если говорить о Луа как о языке, в Луа нет ни массивов ни хеш-таблиц. Есть один, универсальный тип данных — table (таблица). Его можно использовать как array, dictionary, set, list, queue, record и т.п. (прошу прощения, неуверен в русскоязычной терминологии). Table может быть как чем-то одним из этого списка, так и несколькими вещами сразу (например, в моём коде достаточно часто встречается комбинация array и record). Луашные таблицы — мощнейшее выразительное средство, один из краеугольных камней всего языка.
Если же говорить о конкретной реализации, то каждая луашная таблица одновременно содержит в себе как хеш-таблицу, так и массив. Виртуальная машина прозрачно и по достаточно чётко описанным правилам выбирает, куда класть данные. Если лень копаться в коде, всё написано доступным языком в двух абзацах четвёртого раздела The implementation of Lua 5.0, на который я уже давал ссылку.
Да, индексация с единицы и неоднозначность размера у массивов с дырками действительно по началу сбивают с толку.
Но оно того стоит, и с этим можно жить, и жить счастливо.
Смертельных проблем с JSON-ом я не вижу. Главное не пытаться использовать ipairs/table.concat/unpack/# и т.п. там, где этого не стоит делать. Если есть какой-то конкретный вопрос, готов помочь.
А, вообще, мне попадалось достаточно много готовых луашных библиотек для работы с JSON-ом. Вот, например: http://github.com/harningt/luajson
В моей практике писать скрипты на языке со статической типизацией можно заставить только достаточно ограниченный круг лиц. (Если пользователи — программисты на C#, тогда да, конечно, решение идеальное.)
Луа предоставляет не решения, но механизмы для их реализации.
Если нужно иметь всё из коробки — что ж, возможно Луа не для Вас. ;-)
2. Читал, но конструктивной критики не увидел. Слово «дурацкий» в конструктив записать не могу, увы.
3. :-) Может быть Вы просто не умеете их готовить?
Я использую вот это: lstack.h
Пример использования, например, здесь.