Не уверен что сообщение соответствует тематике форума, но более подходящий форум выбрать не смог.
Вкратце, суть проблемы.
Есть некая разновидность HTA (HTML Application). Само приложение написано на Visual C++/ATL/WTL. На главном окошке приложения лежит MSHTML control, весь интерфейс написан на HTML, вся бизнес-логика — на JavaScript. Основное назначение приложения — создание документов (сами документы хранятся в XML) на основе HTML-форм.
В целом, основные требования к приложению сейчас удовлетворены:
1. Небольшой размер дистрибутива (за счёт того что никаких дополнительных библиотек с собой не таскается).
2. Лёгкость модификации — за счёт того что всё логика лежит в JavaScript и приложение отлаживается даже без перезапуска приложения.
3. Скорость написания новых форм для ввода данных — за счёт того что интерфейс делается на HTML (редакторов — море) а логика на JavaScript (простой и уже привычный, но при этом довольно мощный скриптовый язык, удобный отладчик в лице MS VC).
Но вот на горизонте замаячила миграция на Windows CE. Насколько показало небольшое исследование, портирование HTA на WinCE представляется крайне проблематичным (поправьте если не прав). В таком случае, есть идея переехать на более другие технологии. Понравилась идея HTMLayout — легковесный HTML-парсер с возможностью билда под CE. Опять же, рядом с ним идёт TIScript — практически тот же JavaScript c расширениями. Но с ним возникают след. проблемы:
1. Версия TIScript под CE планируется к выпуску, но пока не вышла. Даже если она выйдет в ближайшее время — не очень хочется связываться с самой первой версией продукта, поскольку буду первопроходцем по граблям.
2. Отладчика для TIScript, насколько я понял, сейчас нет и пока даже не планируется. Ко всему прочему очень хотелось бы иметь возможность удалённой отладки, т.е. отлаживать скрипт который запускается на CE-шном девайсе.
В принципе, к HTMLayout можно будет прикрутить любой другой скриптовый язык который прикручивается к C++. Посему, был бы рад если бы кто посоветовал скриптовый движок/язык со следующими характеристиками:
1. Легко прикручивающийся к C++ (если он будет как JScript срощен с COM — вообще было бы замечательно)
2. Кросплатформенный (хотя бы в плане Win32/WinCE, *nix — опционально)
3. Выразительный, но несложный в изучении (JavaScript в этом плане очень приятно порадовал)
4. С хорошо развитыми средствами отладки, желательно с возможностью удалённой отладки
5. Ну и там всякие вкусности типа документации-готовых примеров приложений и т.п. (в принципе, не так и обязательно, поскольку круг задач как правило довольно узок, форматировать винчестер и инвертировать матрицы мне не нужно, джаваскрипта с его стандартной библиотекой хватало за глаза).
Здравствуйте, Left2, Вы писали:
L>1. Легко прикручивающийся к C++ (если он будет как JScript срощен с COM — вообще было бы замечательно) L>2. Кросплатформенный (хотя бы в плане Win32/WinCE, *nix — опционально) L>3. Выразительный, но несложный в изучении (JavaScript в этом плане очень приятно порадовал) L>4. С хорошо развитыми средствами отладки, желательно с возможностью удалённой отладки L>5. Ну и там всякие вкусности типа документации-готовых примеров приложений и т.п. (в принципе, не так и обязательно, поскольку круг задач как правило довольно узок, форматировать винчестер и инвертировать матрицы мне не нужно, джаваскрипта с его стандартной библиотекой хватало за глаза).
L>Вроде бы всё L>Заранее спасибо за ответы.
Python?
1. Прикручивается к С++ — легче некуда, ибо создавался с учетом интеграции с различными платформами, в т чс нативными реализациями. В случае С++ boost::python рулит. Просто и элементарно, по сравнению с JavaScript с его интеграцией через ацкий COM — просто песня.
2. Есть и на Win32, есть порт и на WinCE. К слову, и на многих *nix-ах имеется.
3. Легче некуда. При этом это, в отличие от JavaScript, полноценный ЯП. По языковым возможностям опережает многие "нескриптовые" языки
4. Прекрасные средства, не только для отладки, но и для разработки приложения в целом. Есть плагин для Eclipse => скорее всего поддерживается удаленная отладка (посольку Eclipse предоставляет для этого API).Хотя, последнее надо проверить.
5. Имеется полноценная документация + куча ресурсов в сети.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Left2, Вы писали: L>1. Легко прикручивающийся к C++ (если он будет как JScript срощен с COM — вообще было бы замечательно) L>2. Кросплатформенный (хотя бы в плане Win32/WinCE, *nix — опционально) L>3. Выразительный, но несложный в изучении (JavaScript в этом плане очень приятно порадовал) L>4. С хорошо развитыми средствами отладки, желательно с возможностью удалённой отладки L>5. Ну и там всякие вкусности типа документации-готовых примеров приложений и т.п. (в принципе, не так и обязательно, поскольку круг задач как правило довольно узок, форматировать винчестер и инвертировать матрицы мне не нужно, джаваскрипта с его стандартной библиотекой хватало за глаза).
Я бы посмотрел на Lua. Это язык специально создавался как язык для встраивания и потому отличается следующими свойствами:
1) Очень маленький (~300кб С кода). В урезанном виде для эмебдед системы, мне удавалось довести откомпилированный размер до 15кб.
2) Очень быстрый. Register-based VM (в отличии от стековых, в большинству других скриптовых языков) даёт отличный перфоманс. Из за этого его, например, очень любят в качестве скриптового языка в играх.
3) Простой. В язык намеренно встроено минимум наворотов и фич, но язык очень гибкий и на нём можно делать всё что угодно от ООП до функционального программирования. По сути, это скорее скелет языка, который можно подогнать под свои нужды. Я например, в одном проекте, использовал как язык описания данных, с некими примочками вроде навешивания скриптовых событий и триггеров.
4) Переносимой. Написан на ANSI C и компилируется на всём что шевелится.
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
Ну, Lua здесь уже советовали. Главный его недостаток — с моей точки зрения — своеобразный синтаксис. Сейчас я использую Squirrel. В плане интеграции и внутреннего устройства похож на Lua, тоже написан на C. Синтаксис С-подобный, местами напоминает JavaScript. Есть возможность удаленной отладки.
LP>Python?
LP>1. Прикручивается к С++ — легче некуда, ибо создавался с учетом интеграции с различными платформами, в т чс нативными реализациями. В случае С++ boost::python рулит. Просто и элементарно, по сравнению с JavaScript с его интеграцией через ацкий COM — просто песня. LP>2. Есть и на Win32, есть порт и на WinCE. К слову, и на многих *nix-ах имеется. LP>3. Легче некуда. При этом это, в отличие от JavaScript, полноценный ЯП. По языковым возможностям опережает многие "нескриптовые" языки LP>4. Прекрасные средства, не только для отладки, но и для разработки приложения в целом. Есть плагин для Eclipse => скорее всего поддерживается удаленная отладка (посольку Eclipse предоставляет для этого API).Хотя, последнее надо проверить. LP>5. Имеется полноценная документация + куча ресурсов в сети.
Спасибо. В целом, во многом перекликается с моими мыслями по этому поводу. Единственно насчёт чего несогласен так это насчёт того что JavaScript неполноценный язык программирования Очень даже полноценный, несмотря на минималистический дизайн.
С>Ну, Lua здесь уже советовали. Главный его недостаток — с моей точки зрения — своеобразный синтаксис. Сейчас я использую Squirrel. В плане интеграции и внутреннего устройства похож на Lua, тоже написан на C. Синтаксис С-подобный, местами напоминает JavaScript. Есть возможность удаленной отладки.
Спасибо, пока что заинтересовало больше всего. Был бы рад услышать субьективные впечатления об опыте использования
Здравствуйте, Zigmar, Вы писали:
Z>2) Очень быстрый. Register-based VM (в отличии от стековых, в большинству других скриптовых языков) даёт отличный перфоманс. Из за этого его, например, очень любят в качестве скриптового языка в играх.
Ну в общем-то никто толком не доказал что лучше stack-based VM или register-based VM.
Вот например:
We believe that the high cost of dispatches makes register machines attractive even
at the cost of increased loads.
Рад видеть в этой теме Впрочем, инициатива наказуема TIScript мне тоже прекрасно подходит по всем параметрам (особенно по синтаксису) — кроме одного — отсутствие отладчика
Если не секрет — планируется ли в будущем поддержка отладки, особенно интересует отладка удалённая?
Здравствуйте, Left2, Вы писали:
L>Рад видеть в этой теме Впрочем, инициатива наказуема TIScript мне тоже прекрасно подходит по всем параметрам (особенно по синтаксису) — кроме одного — отсутствие отладчика L>Если не секрет — планируется ли в будущем поддержка отладки, особенно интересует отладка удалённая?
Что подразумевается под "отладчиком"? Возможность поставить breakpoint и от него ходить?
Или что-то другое?
Здравствуйте, Left2, Вы писали:
L>Спасибо, пока что заинтересовало больше всего. Был бы рад услышать субьективные впечатления об опыте использования
Субъективные впечатления — сугубо положительные. Радует возможность управления всеми объектами движка из нативного кода. На баги не натыкался, разве что в его небольшой стандартной библиотеке есть недочеты в функциях работы со строками — они считают нулевой символ концом строки, в то время как в squirrel это совсем необязательно.
Недостатки его исходят из того, что он достаточно молодой и пока не очень-то популярен, поэтому нет редактора кода, более-менее готового отладчика, автоматических биндеров типа SWIG, биндингов существующих библиотек, и т.п., в то время как для Lua все это есть.
L>>Рад видеть в этой теме Впрочем, инициатива наказуема TIScript мне тоже прекрасно подходит по всем параметрам (особенно по синтаксису) — кроме одного — отсутствие отладчика L>>Если не секрет — планируется ли в будущем поддержка отладки, особенно интересует отладка удалённая?
CS>Что подразумевается под "отладчиком"? Возможность поставить breakpoint и от него ходить? CS>Или что-то другое?
breakpoint, watches, немедленное исполнение кода и т.п. Вообщем, чем больше вкусностей, тем лучше
Очень нравится, к примеру, как Visual Studio отлаживает JavaScript/VBScript — единственное чего не хватает так это remote debugging.
Здравствуйте, LaPerouse, Вы писали:
LP>Python?
LP>1. Прикручивается к С++ — легче некуда, ибо создавался с учетом интеграции с различными платформами, в т чс нативными реализациями. В случае С++ boost::python рулит. Просто и элементарно, по сравнению с JavaScript с его интеграцией через ацкий COM — просто песня. LP>2. Есть и на Win32, есть порт и на WinCE. К слову, и на многих *nix-ах имеется. LP>3. Легче некуда. При этом это, в отличие от JavaScript, полноценный ЯП. По языковым возможностям опережает многие "нескриптовые" языки LP>4. Прекрасные средства, не только для отладки, но и для разработки приложения в целом. Есть плагин для Eclipse => скорее всего поддерживается удаленная отладка (посольку Eclipse предоставляет для этого API).Хотя, последнее надо проверить. LP>5. Имеется полноценная документация + куча ресурсов в сети.
И ещё, на оффициальном сайте http://python.org/ большими буквами написано NASA uses Python...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Сорри что подымаю старую тему, но вдруг кому-то будет интересно чем всё закончилось
А закончилось всё тем что язык остался тем же — JScript. Выяснилось что Win Mobile 2003 (а на более старые версии можно смело забить, ибо их доля на рынке очень небольшая) поддерживает ActiveScripting версии 5.6, что соответсвует IE 5.5 и для моих целей его хватает выше крыши. К сожалению, отлаживать скрипты под WinMobile нельзя, но зато можно иметь два билда программы — под PC и под WinMobile, и отлаживаться по максимуму на PC. Скрипты при этом вообще не знают под какой системой работают.
Немного жаль что не удалось малой кровью поддержать Linux-платформы, ибо всё, похоже, идёт к тому что на рынке дешёвых ноутбуков и смартфонов у Linux-а есть хорошие шансы стать доминирующей платформой. Но в крайнем случае попробую переехать на SpiderMonkey, вроде бы при этом даже не прийдётся менять скрипты. А к тому времени, глядишь, и Linux-версия HTMLayout созреет
TIScript мне тоже прекрасно подходит по всем параметрам (особенно по синтаксису) — кроме одного — отсутствие отладчика 
