Здравствуйте, ArtemGorikov, Вы писали:

AG>Здравствуйте, eao197, Вы писали:


E>>А boost::spirit потянет-то? На yacc, coco/r, antlr сделать разбор языка программирования с последующей генерацией AST или другого представления программы -- это и то не самое простое занятие. А ведь это специализированные инструменты со своими, годами отшлифованными DSL.

AG>Не знаю . Но раз потянул парсинг XML-я и csv, которым и без него в общем-то хорошо, то тут уж сам бог велел

А ты думаешь, что парсинг XML сложнее парсинга, например, C или Python? С языками программирования сложность не только в лексическом и синтаксическом анализе, но еще и в сложной семантике. Которую частично нужно еще во время парсинга учитывать. Скажем, в зависимости от вида идентификатора определять, является ли выражение вызовом метода или обращением к константе.

E>>Имхо, здесь нет совершенно никаких проблем. Просто в новой версии конфига нужно сохранить старый API и предоставить новый API для расширений.
AG>???!!!! И сколько же таких расширений накопится по мере расширения продукта? А ведь их еще придется потом поддерживать, баги править .

Есть такая штука, совместимость называется. Пользователей продукта не должно волновать, во что выливается ее поддержка у разработчика. Пользователь должен иметь возможность перейти на новую версию продукта с минимальными издержками. И если разработчик хочет снизить свои издержки при сопровождении однажды выпущеного API, то он должен более тчательно проектировать этот API.

А что касается багов, то чем дольше используется код, тем меньше багов в нем остается. Опасность как раз представляют новые расширения, которые еще не прошли проверку временем.

E>>Артем, раз ты такой сторонник XML-ных конфигов, можешь прокоментировать то, что я вот здесь нафантазировал: Re[23]: XML vs рукописный формат для конфигов

Автор: eao197
Дата: 09.09.05

(имеется в виду Ruby скрипт с конфигурацией, в котором возможна условная обработка). И насколько просто будет сделать подобное решение на XML?

AG>XML не для того придумали. IMHO если имеет место быть конфиг с условной обработкой, то это уже вопрос неправильной архитектуры.

А вот подобные заявления меня просто умиляют. Как это здорово -- столкнулся кто-то со сложностями, значит архитектура не правильная. А как же. А вот у меня такого не бывает. Сразу все правильно проектирую. И со временем никаких подводных камней не обнаруживается. И если возникает необходимость сменить формат конфигов (хотя с чего бы это, архитектура же правильная?), то пользователи с пониманием отнесутся к необходимости смены формата конфигов и переобучения. Зато ведь архитектура правильная.

Если серьезно, без сарказма, то удобное сочетания декларативности и некоторой доли императива -- это сложная задача. Которая возникает во многих местах. Например, в MSBuild, пример из Re: MSBuild

Автор: eao197
Дата: 13.07.05

:

<Target
  Name="Build"
  Condition=" '$(InvalidConfigurationWarning)' != 'true' "
  Outputs="$(TargetPath)"
  DependsOnTargets="$(BuildDependsOn)"
  />

Или еще один пример здесь: Re[36]: Формат конфигов

Автор: Павел Кузнецов
Дата: 24.06.05

.
Разве не странно -- с одной стороны декларативный формат и предназначен для описания достаточно статических вещей. Ан нет, все равно императивность добавили.

Т.е. хорошо, когда конфиги используются только в качестве деклараций. Если же пришлось добавить в них логику, то и так невысокая читабельность XML вообще убивает все на корню. Лучше всего в таких условиях себя чувствуют lisp-подобные языки (а еще лучше, имхо, сам lisp) и скриптовые языки. Что c-smile как раз и попытался показать в своем примере, а я в своем.

c-smile wrote:
> Одна из задач где мне нужен именно JavaScript'ing —
> HTMLayout. К сожалению карта в отрасли легла таким
> образом что все ожидают в HTML JS.
>
> Не Python, не Perl, не Scheme, а именно JavaScript.

Ожидаю-то LISP: имеем дерево и набор атрибутов у вершин, как-то
подозрительно похоже на описание какого-то языка в упрощённой форме, а
вот видят все точно JS.

Здравствуйте, c-smile, Вы писали:


AG>>Если в процессе вычислений получили дробное число — то придется отбросить дробную часть. А это нехорошо. Какой тут может идти разговор о вычислительной эффективности, если это интерпретатор? Все равно действия в float-ми быстрее интерпретирования.

CS>Не понял высказывание если честно.
Смысл: зачем программисту скрипта заморачиваться на разнице числовых типов? Ради скорости? А она и так очень невысокая у интерпретатора. Намного больше издержки интерпретирования, чем конвертации из double в int.

CS>Как float "влезает" в нечто типа такого:
CS>

CS>switch(String.charCodeAt(idx))
CS>{
CS>  case 'a': ....
CS>  case 'b': ....
CS>}
CS>

CS>ИМХО, только путем нестандартного секса.
wchar(short) => double => int. Где здесь секс?


CS>"Эффективность все же выше, как пример, код на C++,"
CS>Не выше. Эффективность кода одна и та же. Во всяком случае у меня.
У меня разница в эффективности C++ кода, работающего с массивами VARIANT-ов — и MS JScript в том же приложении (я использовал скриптовую машину для гибкости, когда это вычисление проводится только на массиве с 1 элементом) — составила 7 раз. И это было до того, как я улучшил интерфейс доступа к массиву (С++), заменив виртуальный "GetAt" на "GetData" и далее доступ к каждому элементу уже по смещению в массиве. Преобразование типов из VARIANT в нужный тип, на самом деле, происходит достаточно быстро. Несравнимо быстрее, чем интерпретирование.

CS>JIT есть компиляция байткода в машинные команды.
CS>О каких машинных командах идет речь в случае VARIANT данных?
.NET с этой проблемой справляется. Кстати, в Java тоже есть JIT-компилятор.

CS>Что можно сделать в JIT в случае с var a = b + c; если типы b и с неизвестны в момент JITа.
CS>По моему проблема очевидна. Нет?
Написать что-то типа

call @8VariantSum

Или я не прав?



CS>Добавляем (или убираем) поле и ничего в принципе не меняется (не "грохается").

CS>

CS>data: 
CS>{
CS>  one: 1,
CS>  two: "text",
CS>  three: new Date( 2005, 9, 12 ),
CS>  four: ["Masha", "Vova", "Vasya" ]
CS>}
CS>

CS>Или я не понял проблему?
CS>Абсолютно та же flexibility что и в случае с XML.
Тогда согласен, это удобнее и понятнее, чем городить теги XML. Главное, чтобы не грохалось на бинарных данных, как это было в серилизации MFC.


В любом случае, лучше иметь свой залинкованный интерпретатор JavaScript, чем полагаться на MS-ий. Хоть он и есть на всех машинах, в него может поставить хук антивирус и показывать мерзкое сообщение, что в твоей программе исполняется вредоносный скрипт http://www.viksoe.dk/code/basescript.htm . А применить скрипт можно в обработчиках событий html — подобного GUI. Кстати, я использую "подшлифованный напильником" http://www.viksoe.dk/code/windowless1.htm , тока цвета и весь вид сделал системными. Подумываю еще скрипт прикрутить на обработчики событий его контролов. Есть опыт использования MS WebBrowser в роли диаложек — до сих пор проявляются траблы на машинах с последними сервис-паками из-за его параноидальных настроек безопасности.

Здравствуйте, c-smile, Вы писали:

CS>Не Python, не Perl, не Scheme, а именно JavaScript.

Чем тогда существующие движки не угодили? Mozilla/SpiderMonkey, KJS — все opensourse...

Здравствуйте, ArtemGorikov, Вы писали:


AG>>>Если в процессе вычислений получили дробное число — то придется отбросить дробную часть. А это нехорошо. Какой тут может идти разговор о вычислительной эффективности, если это интерпретатор? Все равно действия в float-ми быстрее интерпретирования.

CS>>Не понял высказывание если честно.
AG>Смысл: зачем программисту скрипта заморачиваться на разнице числовых типов? Ради скорости? А она и так очень невысокая у интерпретатора. Намного больше издержки интерпретирования, чем конвертации из double в int.

CS>>Как float "влезает" в нечто типа такого:
CS>>

CS>>switch(String.charCodeAt(idx))
CS>>{
CS>>  case 'a': ....
CS>>  case 'b': ....
CS>>}
CS>>

CS>>ИМХО, только путем нестандартного секса.

AG>wchar(short) => double => int. Где здесь секс?

Секс в том что wchar(short) => int.
через double получается. Это оно и есть — нестандартный секс...


CS>>Что можно сделать в JIT в случае с var a = b + c; если типы b и с неизвестны в момент JITа.
CS>>По моему проблема очевидна. Нет?
AG>Написать что-то типа

AG>

AG>call @8VariantSum
AG>

AG>Или я не прав?

Так оно в байткоде и выглядит, веришь?


AG>В любом случае, лучше иметь свой залинкованный интерпретатор JavaScript, чем полагаться на MS-ий. Хоть он и есть на всех машинах, в него может поставить хук антивирус и показывать мерзкое сообщение, что в твоей программе исполняется вредоносный скрипт http://www.viksoe.dk/code/basescript.htm . А применить скрипт можно в обработчиках событий html — подобного GUI. Кстати, я использую "подшлифованный напильником" http://www.viksoe.dk/code/windowless1.htm , тока цвета и весь вид сделал системными. Подумываю еще скрипт прикрутить на обработчики событий его контролов. Есть опыт использования MS WebBrowser в роли диаложек — до сих пор проявляются траблы на машинах с последними сервис-паками из-за его параноидальных настроек безопасности.

Имхо (и честно) моя http://www.prowiki.org/wiki4d/wiki.cgi?Harmonia
лучше. Viksoe дизайн (архитектура) мне категорически не нравится.

Здравствуйте, c-smile, Вы писали:


CS>Имхо (и честно) моя http://www.prowiki.org/wiki4d/wiki.cgi?Harmonia
CS>лучше. Viksoe дизайн (архитектура) мне категорически не нравится.
Архитектура там нормальная. После переделки из абсолютных координат контролов в относительные (смещение по отношению к родителю), добавления контрола таблицы и windowless-скролбаров (вертикальный и горизонтальный), замены самописных helper-классов типа CString и CRect на ATL-е, все тип-топ. И выглядит стандартно, и работает быстро. Есть печать. Очень легко добавлять свои контролы (так я добавил чарты, попутно отрезав у них hwnd). Конечно, "обработал напильником" — это мягко сказано , но зато все залинковано в одной либе. Если появится необходимость, прикручу еще windowless edit контрол на движке richedit. Подумываю еще прикрутить возможность вешать скриптовые хуки на события от контролов.

Что мне не понравилось в Harmonia:
1. Больной коричневый цвет контролов. В систете есть уже цветовые схемы, и юзер наверняка может поставить себе коричневую, если она ему так нравится. Лично мне — не нравится. Как с луны свалилась что в Luna, что в стандартной схеме. Цветовая схема и стандартный вид — про это говорится специально во всех руководствах по разработке GUI, что мне встречались, тем не менее, Вы опять наступаете на старые грабли.
2. Тулбары живут своей жизнью, налазят на менюбар, нельзя их разместить, как мне удобно — так, как это делается в rebar контроле.
3. В tree контроле слева выделение элементов почему-то на всю строку. Не всем это нравится, лучше, чтобы было как в обычном tree контроле.
4. Градиентная заливка менюшек как-то не в дугу. Вообще лучше поручить выдумывание таких бантиков дизайнеру, или использовать такие же, как, скажем, в MS Office 2003.
5. Табы тоже какие-то нестандартные. Конечно, креативность — это хорошо, но лучше в меру .

Здравствуйте, c-smile, Вы писали:

T_B>>LUA + Luabind = rulez forever

T_B>>Не зависит от MS, основа -- эффективный сишный код. Биндинги к пользовательскому C++ коду -- удобные шаблоны.

CS>Согласен.

CS>Но к сожалению LUA популярна в основном в среде "дети Борланда"...

Уточни, пожалуйста, о чем ты и чем это плохо. Я, вообще, такой тенденции не замечал. Среди гемдевелоперов -- да, популярна, и это о чем-то говорит. Но причем здесь "дети Борланда"?

Tuo_Bellas.

Здравствуйте, c-smile, Вы писали:

CS>Не всем удобно например в String.charCodeAt(idx) иметь float
CS>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>эффективности этого дела.

Это проблема реализации движка. Посмотри исходники аналогов, там это решается в runtime. Изначально тип int, если появилось деление, явно заданное дробное и пр., тогда оно становится double. А в скрипте все прозрачно — только Number.
В данном случае функция, реализующая charCodeAt вернет int и пока ты это значение не поделишь на что-нить, оно так int и останется.

Здравствуйте, Колян, Вы писали:

К>Здравствуйте, c-smile, Вы писали:

CS>>Не Python, не Perl, не Scheme, а именно JavaScript.

К>Чем тогда существующие движки не угодили? Mozilla/SpiderMonkey, KJS — все opensourse...

Open Source. Заказчик категорически отказался иметь с ним дело.

Сугубо частное мнение:

1) Mozilla JS мне очень не нравится как сделан. Там по моему
используется прямая интерпретация AST. (Я могу ошибаться здесь)
Такое решение очень прожорливо по памяти.
2) KJS — вообще использует прямую инетрпретацию текста в стиле первых
и наивных имплементаций Basic. Детский сад, младшая группа.
Скорости (да и надежности) от этого решения ожидать не стоит.

Здравствуйте, Tuo_Bellas, Вы писали:

CS>>Но к сожалению LUA популярна в основном в среде "дети Борланда"...

T_B>Уточни, пожалуйста, о чем ты и чем это плохо. Я, вообще, такой тенденции не замечал. Среди гемдевелоперов -- да, популярна, и это о чем-то говорит. Но причем здесь "дети Борланда"?

Совсем не плохо. Ни в коем разе.

И извиняюсь за неточность. дети Дельфи (Паскаля) имелись ввиду.

У LUA странный микс (для меня лично) в нотации — смесь С и Pascal
конструкций.

Здравствуйте, Колян, Вы писали:

К>Здравствуйте, c-smile, Вы писали:

CS>>Не всем удобно например в String.charCodeAt(idx) иметь float
CS>>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>>эффективности этого дела.

К>Это проблема реализации движка. Посмотри исходники аналогов, там это решается в runtime. Изначально тип int, если появилось деление, явно заданное дробное и пр., тогда оно становится double. А в скрипте все прозрачно — только Number.

С точки зрения TIScript так оно и есть.

var i = 128;
var r = 128.1;

typeof i == "number";
typeof r == "number";
typeof (r+i) == "number";

isInt( i ) == true;
isInt( r ) == false;
isFloat( r ) == true;
isFloat( r+i ) == true;

Единственная разница в следующем:
Класса Number как такового нет поэтому совершенно странная конструкция
из JavaScript:
var n = new Number( something );
у меня смысла не имеет.

Есть два класса Integer и Float
у которых комплекты свойств

MAX_VALUE
MIN_VALUE
NEGATIVE_INFINITY (только у Float)
POSITIVE_INFINITY (только у Float)
и методы toString()/valueOf()

возвращают разные значения.


К>В данном случае функция, реализующая charCodeAt вернет int и пока ты это значение не поделишь на что-нить, оно так int и останется.

Здравствуйте, Gaperton, Вы писали:

G>Термин typeless просто на удивление "удачен". Например, он совсем не означает, что типов в языке нет и что компилятор/рантайм их не может определить.

Если язык заточен на динамическую типизацию, то в программе будет море мест где до выполнения реальный тип будет не определен. О скорости тут говорить не приходится. А то что типы можно попытаться вычислить — это здорово. Но только для качественного результата тут нужно чтобы язык на это был заточен. Вот ОКамл заточен. Результат соотвествуютий.

G>Впрочем, к примерам. Psyco — JIT для Python.

И? Тесты сделанные не его разработчиком показывают, что джит из дотнета или Явы рвет Psyco аки Тузик грелку.

G>Ускоряет численные рассчеты раз в 25.

Ага, а нада на порядок. К тому же численные рассчеты далеко не самая значительная часть программ. Банальные вызовы методов и работа с коллекциями занимают куда больше места. А тут уже с оптимизациями по туже.

G> А для Смоллтока джиты появились раньше чем для явы. Один из таких Смоллтоковских движков лег в основу первой версии Sun-овской виртуальной машины HotSpot.

И толку с них? Вот Сановская машина показывает на сегодня нехилые результаты, а Джиты Смолтока до него недотягивают.

В общем, если в языке нет статической типизации, пусть даже неявной (с выводом типов), то достичь уровня оптимизации доступного из статически типизированных языков/джитов нельзя физически. И не нужно агитировать за советскую власть.

Здравствуйте, Gaperton, Вы писали:

G>Джиттить имеет смысл цыклы — от этого основной выигрышь. В телах циклов типы var a = b + c обычно выводятся без проблем — типы и значения переменных за пределами циклов уже известны. Плюс, для функций применяется техника сходная с тем, как джиттятся generics в .НЕТ (JIT генерит разный машинный код для аргумента различного типа). Учитывая то, что нам наиболее важно определить числовые типы (от этого основной прирост скорости), все не так страшно.

Вот тут как-то тестировали рассчет альфы. Кто-то сбацал тест на Питоне и прогнал его с Пико. И каков же был результат? В заднице Питон на таких задачах. А вот джитовые языки и языки с выводом типов не сморя на ЖЦ и другие не оптимальности смотрелись очень даже неплохо.

Здравствуйте, c-smile, Вы писали:

CS>Еще раз JIT нужен тем системам которые претендуют на звание "универсальный язык программирования". Java, .NET и пр.
CS>Для скриптовых языков JIT это ... ну даже не знаю как сказать...
CS>пятая нога псу Мухтару наверное.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>Еще раз JIT нужен тем системам которые претендуют на звание "универсальный язык программирования". Java, .NET и пр.
CS>>Для скриптовых языков JIT это ... ну даже не знаю как сказать...
CS>>пятая нога псу Мухтару наверное.

VD>Хорошо прикрученный джит вряд ли кому помешает.

Ай опьять за рибу гроши...

VD>А вот если на высокоуровневом язке можно будет не прибегая к разным С наваять чуть больше кода, то многие задачи будут решаться куда быстрее и проще. А что еще нужно?

Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось.
Взять тот же PHP....
Вот кстати феномен тоже. Язык рождался на ходу, соответсвенно всякие несуразицы в синтаксисие.
Но ежики плачут но лезут на кактус... И нафиг никому по большому счету не упали ни классы ни наследование ни JIT.
Язык для народа. И народ на нем пишет. И красиво кстати пишет...

Здравствуйте, VladD2, Вы писали:

VD>Если язык заточен на динамическую типизацию, то в программе будет море мест где до выполнения реальный тип будет не определен. О скорости тут говорить не приходится. А то что типы можно попытаться вычислить — это здорово. Но только для качественного результата тут нужно чтобы язык на это был заточен. Вот ОКамл заточен. Результат соотвествуютий.

Не совсем. Если язык поддерживает возможность проверки типов и программист не ленится их уточнять, где надо, то динамическую типизацию можно частично обойти. В C# типизация тоже не строгая — есть возможность оперировать object'ами, следовательно все, что требуется, это свести в программе количество мест с object'ами к минимуму.

Здравствуйте, VladD2, Вы писали:

G>>Ускоряет численные рассчеты раз в 25.

VD>Ага, а нада на порядок.

На порядок == в 10 раз быстрее. Ты считаешь, что Psyco не следовало делать таким быстрым?

Здравствуйте, c-smile, Вы писали:

CS>1) Mozilla JS мне очень не нравится как сделан. Там по моему
CS>используется прямая интерпретация AST. (Я могу ошибаться здесь)
CS>Такое решение очень прожорливо по памяти.

Да, код там "тяжелый", но работает хорошо. По памяти все нормально. У меня сервачечное приложение, скрипты эти там пачками выполняются без остановки.

CS>2) KJS — вообще использует прямую инетрпретацию текста в стиле первых
CS>и наивных имплементаций Basic. Детский сад, младшая группа.
CS>Скорости (да и надежности) от этого решения ожидать не стоит.

+1

Здравствуйте, c-smile, Вы писали:

CS>Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось.
CS>Взять тот же PHP....
CS>Вот кстати феномен тоже. Язык рождался на ходу, соответсвенно всякие несуразицы в синтаксисие.
CS>Но ежики плачут но лезут на кактус... И нафиг никому по большому счету не упали ни классы ни наследование ни JIT.
CS>Язык для народа. И народ на нем пишет. И красиво кстати пишет...

Думаю, что популярность ПХП определяется не его качествами как языка, а тем что он входит в набор доступных средств на супер дешевых хостингах (а то и халавнях) где хостится этот самый народ (а точнее низкоквалифицированные орлы у которых нет денег на серьезный хостинг). Ну, а то что некоторые более менее серьезные сайты подсели на ХПХ объясняется тем, что ПХП-массы обеспечивают массу дешевейших рабочих рук которые естественно выбирают то что знают.

Лично я скорее выучу Лисп и начну писать не нем, чем прибегну к ПХП. Так что ПХП — это как и ЯваСкрипт... просто так легла карта. Но в отличии от ЯваСкрипт вместо ПХП можно легко проименять полноценные языки, так как клиент видит только результат в виде ХТМЛ. А вот ЯваСкрипт засел в браузерах надолго... стандарт однако.

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, VladD2, Вы писали:

VD>>Если язык заточен на динамическую типизацию, то в программе будет море мест где до выполнения реальный тип будет не определен. О скорости тут говорить не приходится. А то что типы можно попытаться вычислить — это здорово. Но только для качественного результата тут нужно чтобы язык на это был заточен. Вот ОКамл заточен. Результат соотвествуютий.

Q>Не совсем. Если язык поддерживает возможность проверки типов и программист не ленится их уточнять, где надо, то динамическую типизацию можно частично обойти.

Дык в том то и дело, что для этого язык должен быть заточен под это. Ну, гед скажи мне на милось такая заточка в Питоне, Руби или Лиспе?

Q> В C# типизация тоже не строгая

Ты путашь понятие "строгая" и "полная статическая". Это разные вещи. В безопасном режиме Шарпа типизация строгая, но допускается динамическая типизация.

Q>- есть возможность оперировать object'ами, следовательно все, что требуется, это свести в программе количество мест с object'ами к минимуму.

В C# есть только две операции которые можно произвести над object-ами. Это боксинг и анбоксинг. Так что полноценно оперировать с object неполучится. В следствии этого object используется только как типобезопасная замена void в С++, т.е. как полиморфный базовый тип.

Понятно, что можно было бы обойтись вообще без таких "расширений", но без оных уже нельзя строить компонентные среды. А компонентность — это конек дотнета и Явы. Так что это совсем не тот случай.

Я же говорю о языках которые проектировались как "тайплес". Несомненно для разных Руби, Питовно, Смолтоков и Лиспом можно и ружно делать джиты и т.п. Но сам дизайн языков припятствует полному устранению интерпретируемости.

У C# есть другие места которые приводят к динамическим вычислениям (хотя и не столь значительным). Это, например, делегаты, виртуальные методы, интерфейсы и приведения типов. На сегодня они никак не оптимизируются. Но потенциально большинство таких место таки подаются оптимизации. Так локально испоьзуемый делегат может быть устранен, а не его место может быть подставлен прямой вызов или даже тело вызываемого метода. ФЯ как раз очень харашо демонстрируют насколько это возможно.