Qt Script for Applications beta 2

Очевидно - что я чего то не понимаю. Какая цель у еще одного столь же бесполезного для GUI, как и другие, скрипта? Объясните нетолковому, что даст это с точки зрения облегчения программирования?

1) Кто и как гарантирует что он платформ индепендед? 2) Кто и как гарантирует что разные версии будут работать корректно? 3) Как насчет производиельности? 4) Что даст програмирование на 2 уровнях - скриптах и с коде? 5) и так дале..

Объясните мне неумному _зачем_ он?

программист java/linuz

Imho for advanced QT user's.....a'la AppleScript на MacOS

Интеграция скриптов и компилируемого кода - это очень удачное решение. Это позволяет сделать программу очень гибкой. Можно будет создавать макросы. Или в бухгалтерской программе использовать этот язык для небольших модификаций и расширений. Такой симбиоз позволяет объединить в одной системе программирования динамику и гибкость интерпретаторов с мощью и быстродействием скомпидированных программ. Главный элемент новизны в том, чтобы можно было в скрипт параметром передать объект (именно объект, а не число или строку) из программы на С++.

P.S. В винде подобный механизм встроен в саму ОС начиная с OSR2.

тот же аноним.

странно. что же кроется за словами - большая гибкость. Мне кажется - здесь небольная неточность - может быть код это таки исполняемый код, а данные - именно данные. Если ПО спроектировано с акцентом на то, что логика взаимодействия компонентов есть _код_ - гибкости тут и нет (имхо). Если же логика - в данных это, и есть гибкость - так как ее можно настраивать. Т.е. - _скрипт_ есть промежуточное решение - не жесткий и не бесструктурные данные. Не видны преимущество - это уже было - JScript and COM. Не правда ли - _удачное_ решение???

Не вижу я преимуществ и не понимаю в чем они.

Г.н. Коробко правильно отметил идею. COM + VB и у вас все приложения от M$. Компоненты COM на С, С++ и ублюдочный БЕСИК в качестве 'клея' и у вас бесконечно расширяемые и гибкие приложения. Я запустил MS Word с документом о 23 страницы и Notepad из demo/jfc/Notepad c README.txt из того же каталога - в итоге Word скушал 7.5M, а Notepad 14.5M. То есть приложение, сработанное в безопасном и тормозном бесике ( возможно ) весьма посредственными кодерами, использующее аккуратно сделанные компоненты ( в большинстве стандартные ), написанные на 'опасном' C++ дает сто очков вперед приложению сделанному на тойже жабе. (Могу себе представить сколько ресурсов слопает аналог M$ Word на жабе!).

Так что 'программист java/linuz' в сад - паттерны учть!

Капитан Немо.

2 немо - 8) ну что ж сразу в сад.

объясни мне - при чем паттерны? (имхо паттерны - вообще офтопик здесь)

а) нотепад написан без их учета ? б) ворд написан с их учетом? что за сравнения? 8).

кто грамотно то объяснит. в чем преимущества скрипта в ПО по сравнению с данно - ориентированном ПО? Корректно а не междометиями? Есть такие люди?

Ну насчет сада и паттернов - шутка навеянная фразой

>>> логика взаимодействия _код_ - гибкости тут нет >>> в данных есть гибкость

На мой взгляд преимущества этой техологии таковы:

1) компоненты пишутся на низкоуровневом языке, корорый как это принято говорить error-prone, зато генерит оптимальный по ресурсам и быстрый код. (Хотя можно это делать и на 'безопасных' языках Eiffel, Ada ...). Обычно используют С, С++. Обычно компоненты это небольшие универсальные ( в разумных пределах ) классы. (Вообще можно почитать про идеи COM я хоть и не люблю M$, но хорошие идеи и в Африке хороши. ) 2) Компоненты 'склеивают' простым - очень простым ( таким, что любой Идиот с большой буквы сможет без труда освоить за неделю. ) язычком в приложение. 3) Дают этот язычок в руки Идиоту.

a) Таким образом этот идиот может в очень широких пределах настраивать функциональность приложения под свои нужды.( Макросы в Word, Exel ) b) Модернизируя компоненты мы можем модернизировать приложение, просто копируя новую разделяемую библиотеку ( например ) на место старой. и т.д. и т.п. ....

Это относится не только к COM, CORBA и подобным компонентным технологиям. Возьмите например Python, Ruby, Perl, Lua и другие скриптовые языки так популярные нынче - все они построены на основы этой технологии.

>>>Если же логика - в данных это, и есть гибкость - так как ее можно

Ну это конечно не так... Чтобы убедитья в этом возьмите Word + VBA, Excel + VBA, Emacs + elisp, да наконец любой порядочный SQL server потдерживает хранимые процедуры, триггеры, которые пишутся на том же скриптовом язычке (SPL, PL-SQL, PG-SQL, .... )

Полностью поддерживаю анонимуса. Основной акцент повторю: главное, чтобы из скрипта были доступны объекты приложения. Гибкость получается за счет того, что можем в своём приложении создавать макросы. Невозможно заранее всё предусмотреть. Если мы снабдим свою программу макроязыком, это позволит юзеру нарастить нужную ему функциональность. Или не юзеру, но без перекомпиляции с последующей проверкой и т.д. Скрипт никогда не положит приложение по AV.

Пример 1: формула расчета, например, процента коммиссионных. Запихиваем формулу в текстовое поле БД - и вперёд! Для изменения/добавления новых вариантов нам не надол лезть в исходники.

Пример 2: посмотри MS Office + VBA.

Аргументация, основанная на том, что "можно сделать и без этого" не имеет смысла хотя бы из-за теоремы о функциональной полноте машины Тьюринга.

И ещё, почитайте Горбунова-Посадова.

В продолжение. Бизнес-приложения находятся в состоянии перманентного изменения. Это совершенно естественная ситуация. Если каждое такое изменение будет приводить к модификации и перекомиляции кода, это приведёт к появлению большого числа ошибок.

К сожалению, сегодня крайне мало внимания уделяется вопросам модификации программ.

уррааа!! да здравствуют вирусы, теперь и на линуксе тоже!!!

Интересно.

The language of Qt Script for Applications is Qt Script, an implementation of a subset of ECMAScript 4.0. ECMAScript is also called JavaScript or JScript by some vendors.

What will QSA cost?
The exact price for QSA is not yet available. QSA will be sold on a per developer basis. No run-time fees will be required.

Who will need a QSA developer license?
All Qt developers working on an application that will be script-enabled using QSA, will need a QSA license. (This is because they all, directly or indirectly will make use of the QSA functionality.)

Вопрос: зачем в качестве скриптового языка использовать урезанный JavaScript, да ещё и платить за его использование разработчиком, когда можно взять Tcl, Lua (да и Ruby в принципе тоже) разработанные специально для этих же цели и давно и успешно в этом качестве используемые? Причем более удобные для разработки.
Причем безо всякого лицензирования.

iverg

Вообще штука очень хорошая и давно от QT ожидаемая. Я только за! Почему оно понятно и думаю очевидно. 2iverg. Tcl, Lua и проч. не могут удачно вписаться в работу с C++ и QT. Это будут костыли. Другое дело, что можно было бы сначала предоставить унифицированный интерфейс для скриптовых языков и через него подглючить:) QTScript. Таким образом были бы и овцы целы и волки сыты, то есть можно было бы делать враперы на TCL, Ruby, Python, Lisp и проч. Вот это было бы вообще здорово!

по-моему разширяемость/гибкость очевидна, например как соотносятся emacs и elisp, или jed и slang (кто-то считает emacs недостаточно гибким? :)

в данном-же случае так-как это зашито в тулките, то эту расширяемость могут наследовать все проги на нем написанные, из этого на мой взгляд 2 основных положительных следствия: 1. имеется некий "унифицированный" яэык конфигурации/расширения. 2. он имеется минимальными усилиями со стороны разработчика данной конкретной проги написаной на этом тулките.

PS. если не понял основной фичи qscript просьба сильно не пинать, т.к. не особо изучал, пользовался slang (www.s-lang.org ... или .com?) и писал "по-аналогии" :)

>>Так что 'программист java/linuz' в сад - паттерны учть!

это кнечно хорошая идея, но есть вопросы к столь катигоричным заявлениям.

1) Что ты делаешь с ресурсами которые так пытаешся сберечь??? или прешся от того что загрузка проца 0.0% и 98% свободной памяти?
2) SWING действительно слегонца тормозной, но! Его таки потихоньку улучшают, и второе - это не единственая вариант GUI. SWT не доводилось видеть случаем??
3) Java совершено прекрасно умеет дергать под виндой OLE объекты. И по удобству даст форы всем скриптам вместе взятым, так как умеет делать кроме этого, еще кучу чего полезного. Есть куча либ, которые уже реализованы на java и возможность иметь все в одном флаконе + кучу разных и велеколепных IDE.
4) Теперь просто вопрос, так сказать для повышения собственой образованости. Просвятите плиз, скриптописатели, какой из скритовых языков умеет сериализовать объекты???

не, я не пытаюсь ничего доказывать, я просто не люблю когда делаються такие выводы на основе "я запустил JNotepad, он скушал 14М посему java фуфло".

А насчет QT. Да правильно делают. Главное чтобы силенок хватило довести все это до уровня промышленой платформы.

2ifconfig: список языков которые умеют сериализовать объекты по большей части совпадает со списком языков с приличными объектами. для меня это -- scheme (guile, gauche, etc..) и ruby (блин, недавно откопал для себя -- такая приятная штука!). впрочем, и perl в каком-то роде это умеет, и прочие понемногу..

а написать десяток строчек на такой гибкой фигне как схема или ruby и не возиться с перекомпиляцией всего и вся -- это как был рулез, так им и останется вовеки.

to ifconfig

В python тоже есть сериализация. Проще не видел:

# запись в файл (поток)
picle.dump(object,file)

# чтение из файла (потока)
object=picle.load(file)

Есть еще модуль shelve для хранения сериализованных объектов в файлах DBM.

>>перекомпиляцией всего и вся

"всего" мягко говоря не нужно, а "вся" дак не руками же компилить...
А за ответы по сереиализации спасибо.. сам хочу как нибудб на пистон посмотреть.. все времени не хвататет..
Насчет "руби". Очень смутные представления, найдеться ли кто нибудь кто не отсылая там по ссылкам ответит коротко и внятно на простые вопросы.
1) на чем работает
2) механизм общения с субд
3) механизм "склейки" и "синхрогизации" приложений живущих на разных хостах..

>>пистон

сорри, ПИТОН (phyton) кнечно...

по ruby:

1. на всем что движется. очень активно переманивает к себе людей с perl и видимо python. raa (ruby application archive) быстро растет.

2. по типу perl. т.е. -- один интерфейс к разным фиговинам. для pg давеча видел модуль для писания процедур.

3. dRB? (distributed ruby). впрочем, в этом предмете я не разбираюсь.

главная ссылка -- ruby-lang.org

есть весьма толковое руководство.

and last, but not least:

tarball ruby (1.6.8) весит около метра. включает интерфейс к tk (среди прочего).

tarball ruby-sumo (выборка из raa) весит около двух метров. включает интерфейс к датабазам и eruby (для использования ruby на манер php) и drb (среди прочего).

ну и метр -- doc-bundle.

Г-ну ifconfig

[>> ... с ресурсами ... пытаешся сберечь ... или прешся ...<<] Это Вы претесь приятель. Эк как Вас перекосило! Сразу видно фана от жабы! Да я собственно не против жабы - я против халтуры и маразма. ( Реализация JVM и частично самого языка - халтура, а некоторые заявления Гослинга вообще маразм - наверно старческий ).

И мне конечно приходится "жабить", так что о прожерливости этого чуда я знаю не понаслышке. Мы делаем многоуровневые приложения с использованием CORBA и С++, но в последнее время приходилось делать и на жабе (только сервер поэтому конечно без свингов ) - дань моде так сказать. Однако, когда Вы работаете с сервером БД, то очевидно он и есть самое узкое место в системе, и обычно стараются отдать ему побольше ресурсов, а когда у вас сервак на жабе жрет память насосом, то тут есть над чем репу почесать. Конечно можно привести обычный аргумент фанов жабы - память - де дешевеет, железо - де копейки стоит и т.п. - НО попробуйте сказать заказчику, который хочет апгрейда, что мы дескать переписали вот приложение и ему теперь придется докупить еще сервачек специально для "мидла", причем общая призводительность системы увы не увеличится, зато надежность потенциально будет ООООО какая - пошлет он вас ... и уйдет к другим.

Интересно, что даже прототип сервера на Python + OMNIOrb уедает в 2 - 2.5 меньше ресурсов. Хотя работает конечно медленнее, но для задач где одно из звеньев базуха - вполне приемлимо.

Мне кажется, что фаны, пишущие на жабе или никогда не разрабатывали приложений больше 10 000 LOC или пишут для ооооочень богатых клиентов.

[ >>> удобству даст форы всем скриптам вместе взятым <<< ] Ну это конечно нетак. Синтаксис скриптовых языков обычно более емкий и гибкий за счет их безтиповости и динамичности. Внутреннее устройство Python-a, Rubby и Lua очень похоже на устройство Smalltalk (все есть dictionary ). А Smalltalk это классика!

В итоге:

Жаба конечно не плохой язык ( особенно если выкинуть примитивные типы, добавить шаблоны и перегрузку операторов - кроме разумеется присваивания ) очень легкий по сравнению с теми же плюсами и главное почти лишен что называется "проклятие выбора". Однако ООООООчень медленно развивается. Некоторые господа aka Mr. Gosling наверное считают что недостатки не только продолжение достоинств, а сами эти достоинства и есть.

Если и дальше так пойдет, то .net точно похоронит эту технологию, а жаль. Рассыланием жалестных призывов с javalobby, коллекционированием подчас совершенно идиотских "25 reasons why Java is better than .Net", смехотворные судебные иски к M$ - они плохие - они нехотят включать java в XP! Хреновые методы борьбы !!!

Более 75% компов в мире - Windoze, а это значит .NET - чтобы выжить java должна быть в 100 раз лучше не на словах а на деле. Что касается Eclipse - я как-то посмотрел как у них сделаны виджеты - отсутствие протектных интерфейсов и вот вам " SWT convention is to use anonymous inner classes to forward the functionality to non-public methods of the same name. " А освобождение ресурсов мне напоминает освобождение динамической памяти в С - только там легко получить memory leak а тут resource leak и не факт, что перовое хуже второго.

(Python например как и С++ умеет автоматически освобождать ресурсы при выходе за границы контекста )

За сим позвольте откланятся. Искренне Капитан Немо.

ээ.. кажется господин Немо загнул кое-где немножко..

аноним - детонатор 8)

хм. интересно 8) - получается все правы - кто за мс = макросы - рулят, кто за питон - рулит питон. жаву попинали 8).

внесу свое имхо - тут пробегало про готовые компоненты - вопрос - насколько будет приложение готовое как вы говорите гибким - очевидно, что функционал обеспечивают компоненты. а логику саму - писать на жскрипт??? или новые компоненты? тогда зачем скрипт. как то однажды пришлось писать на жскрипте = увольте, больше не хочу - код в несколько кило превращается в нечто не поддающееся ни контролю ни пониманию - отладки нет, типизации нет, набор команд годных разве что для управления штмл 8/. в общем не программирование - а гиморой. если кто-то несогласен - пусть напишет на жскрипте почтового клиента - мы все заценим. вот такое мое имхо.

все равно мне кажется это слишком жестким решением 8/

>>Мне кажется, что фаны, пишущие на жабе или никогда не разрабатывали приложений больше 10 000 LOC

мягко говоря не правда.

>>или пишут для ооооочень богатых клиентов.
вот это отсчасти да, но главное здесь даже не деньги, а скорость разработки.

Насчет железа. Я не господин Никс, и кричать что каждой секретарше по менфрейму от IBM не стану. Но то минимальное (x86) железо, которое вам сейчас удастся купить, вролне может сдужить тем пресловутыми middle для этак клиентов 25-30. А лепить middle & RDBMS на один физический сервер, мягко гововря - не рекомендуеться. И дело тут не только в производительности и ресурсах.

>>А Smalltalk это классика!
ну и где эта классика?? IBM вон его до сих пор подпихивает. Ай нет, в последнее время и та забивает за отсутсвие спроса на классику. А вот java "глолубые" пихают изо всех сил.

Кстати, я далеко не фанат, эпизодически хватаюсь за плюсовые проекты. Но то что ПРОСТЫЕ (с точки зрения програмера) приложения пишуться на java быстрее, это опыт.

Насчет скритов. Я соершенно не против, более того сабж меня радует. Вопрос в том, что я физически не имею возможности переключаться с одних тулзов на другие, только потому, что сущестыкет мнение, что этот скритовый язык лучше подходит для этого... А вон тот - для вот этого. Лучший язык, это тот, кторый ты ХОРОШО знаешь.

Кстати, то что указано насчет inner классов в SWT далеко не самое страшное. Лично мне, очень не нравиться что все контролы должны быть в одном треде. Из этого вытекает куча неудобоств. Но есть куча плюсов. Например идея Layout &Data очень удобная. Кстати, в подобном контекте, идея собсно то "скриптовая"..

Кстати, не совсем понял вашу мысль про "resource leak".. Разверните поподробнее, чего то я не въехал пока, что имееться ввиду..

Насчет медлено развиваеться. Вобщем то да, но с другой стороны интерпрайсес приложения не лучшее место для "гонки". А JRE куча проблем, если гнать быстрее, то ошибок будет еще больше..

Насчет NET. Дык, поживем увидим. Для меня пофигу на чем писать, лижбы не прыгать туды<->сюды..

Одно из возможный применений QSA - конфигурация KDE по аналогии с тем, как bash-скрипты выполняют всю работу по конфигурации и управлению системой.

Скорость разработки самой KDE от этого может значительно увеличиться, так как простенькие задачки легко, быстро, и с минимальным кол-вом ошибок пишутся на скриптах. Надо только грамотно выделить это множество задач. Иначе эффект, конечно же, будет прямо противоположный - существенная потеря производительности.

Писать _всё_ на С/С++, на мой взгляд, равносильно строительству дома одним топором. Разнообразие (умеренное) инструментария лучше его однообразия.

> Вопрос: зачем в качестве скриптового языка использовать урезанный JavaScript,
Qt Script - это JavaScript+Qt, т.е. отнюдь не урезанный.

>да ещё и платить за его использование разработчиком, когда можно взять Tcl, Lua (да и Ruby в принципе тоже) разработанные
Qt Script распространяется на условиях GPL, читай, бесплатно.

>специально для этих же цели и давно и успешно в этом качестве используемые?
Назначение Qt Script - расширять и дополнять существующие Qt-приложения, а не для самостоятельной разработки приложений.

>Причем более удобные для разработки.
Qt Script не использует привязок к Qt, со всеми вытекающими...

>Причем безо всякого лицензирования.
Вас не устраивает GPL и вы хотите зарабатывать деньги на своих скриптах ? Тогда покупайте у троллей коммерческую версию QSA...

На этой неделе выйдет русский перевод небольшой статьи, рассказывающей, что такое QSA, чтобы удовлетворить интерес публики и уменьшить число таких вопросов...

www.wxpython.org - то, чего всем так нехватает...