Комментарии 24
Спасибо за статью, к сожалению не могу голосовать.
Если, честно заинтересовался, так как приходилось использовать ActionScript. Но есть ряд вопросов, один из которых доступные среды разработки, а второй производительность.
Если, честно заинтересовался, так как приходилось использовать ActionScript. Но есть ряд вопросов, один из которых доступные среды разработки, а второй производительность.
1) Любой продукт из серии JetBrains
2) В зависимости от компилятора\конечногого языка и платформы
2) В зависимости от компилятора\конечногого языка и платформы
«Родная» среда разработки — FlashDevelop. Полная поддержка автодополнения через вызов компилятора, которая на данный момент ещё и работает довольно быстро даже для больших проектов. Из минусов — нет дебаггера. Производительность, как и сказал SerafimArts, зависит от целевой платформы. Практика показала, что код для C++ не очень эффективный (слишком много обвязки и допущений — например, int-ы могут хранить и null — отсюда невозможность использования простого типа данных), а вот код для других платформ очень даже неплох.
а вот код для других платформ очень даже неплох.
За исключением JS. Помнится была демка с «мячиками» прямо в каталоге с примерами и для отрисовки каждого мячика использовался отдельный канвас, а поворот и всякие издевательства осуществлялись средствами CSS.
Но это было около года назад, как сейчас дело обстоит — не в курсе, может быть что-то поменялось.
Вы сейчас говорите про библиотеку OpenFL — да, использование её для HTML5-игр пока не оправдано, вы правы. Я лично склоняюсь к использованию easeljs, например.
Да, верно, скорее всего именно OpenFL.
Увы, любовался хаксом довольно продолжительное время назад и своего рода полюбил, по крайней мере синтаксис — он великолепен, даже для человека (меня), приверженца динамических языков со слабой типизацией. Решил подождать когда компиль станет код покачественнее генерировать и попробовать запилить какую-нибудь игрушку (именно по этому скорее всего OpenFL тогда смотрел).
Увы, любовался хаксом довольно продолжительное время назад и своего рода полюбил, по крайней мере синтаксис — он великолепен, даже для человека (меня), приверженца динамических языков со слабой типизацией. Решил подождать когда компиль станет код покачественнее генерировать и попробовать запилить какую-нибудь игрушку (именно по этому скорее всего OpenFL тогда смотрел).
А сам haxe, как язык, тут совершенно не при чем. Это лишь проблема тех, кто реализовал на нем таким образом эти мячики.
Мячики были представлены в виде объекта спрайта. Есть варианты как сделать это по другому, чтоб openfl при компиляции не делал тучки html тегов?
Лично для сейчас меня фаворитом является VSCode.
Со списком самых популярных можно ознакомиться тут: haxe.org/documentation/introduction/editors-and-ides.html
По поводу генерации С++. Теперь используется как-раз простой тип.
И при попытки присвоение null к int haxe выдаст ошибку.
Со списком самых популярных можно ознакомиться тут: haxe.org/documentation/introduction/editors-and-ides.html
По поводу генерации С++. Теперь используется как-раз простой тип.
И при попытки присвоение null к int haxe выдаст ошибку.
Не смотрели в сторону Typescript? На нем теперь тоже можно писать и клиентский, и серверный код со строгой типизацией, практически идентичный JS.
TypeScript основан на JS, в том время, как Haxe, вроде как, можно транслировать во множество языков.
Да, так и есть, но это довольно сомнительный плюс. Я слабо представляю себе проект, в котором возможность в любой момент сменить целевую платформу важнее, чем обилие и качество готовых библиотек под конкретный язык — а под Haxe их, смею предположить, минимум на порядок меньше чем под PHP или JS.
Какая-то кроссплатформенная разработка, к примеру)
Думаю, что для ряда случаев вы правы, однако могу привести контпример: пару лет назад написали с другом ряд онлайн-игр на haxe с компиляцией в php, а через некоторое время перекомпилировали их в neko. В результате смогли снизить расходы, избавившись от половины серверов.
Недавно смотрел. Использовал файлы *.def.ts для генерации аналогичных обёрток для haxe. Синтаксис haxe мне больше нравится.
компилятор лишь транслируетТак и говорите — транслятор.
Решил не нарушать традицию: в англоязычной документации везде используется «compiler». Кроме того, haxe всё же имеет встроенную поддержку компиляции в байт-код машины nekovm.
интересно, а он не умеет компилироватся в байткод java?)
пока не умеет.
Теперь умеет
haxe.org/manual/target-java-getting-started.html
haxe.org/manual/target-java-getting-started.html
Так ведь изначально он и был только компилятором. Первой целью была именно компиляция в байт-код swf. И только вторым добавился js, в который уже нужно было транслировать. И до сих пор swf — один из самых взрослых таргетов, так что не nekovm единым.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Haxe: конвертируем исходный код