Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 00:58
Оценка: 32 (5)
Вот в результате работы над некими проектами получлся scripting engine.
Подумалось что может быть полезным кому-то еще.

http://terrainformatica.com/tiscript/

Основная идея engine — простота интегрируемости в чистый C/C++.
API это 10 plain C функций плюс обертка для C++.
Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.

Сам язык близок к JavaScript "as much as possible"

JavaScript фичи которые попали под нож:

1) упрощена вся эта скажем прямо ахинея вокруг prototype, __proto__ и иже с ними.
Классы и наследование стало прозрчнее и очевиднее. См. http://terrainformatica.com/tiscript/Syntax.whtm#classes

2) класс Number разделен на два — Integer и Float.

Все остальное в принципе должно быть близко к JavaScript. Во всяком случае есть такое намерение.
Это то что касается языка.

Что нового:

1) Появились потоки ввода вывода. File and socket Stream. Соответственно в скрипте определены stdin, stdout, stderr. Ну и printf и всякие штуки типа stdout << "Hi, world!";
Хост-приложение само определеяет что есть эти самые stdin, stdout, stderr.

2) Добавлен режим работы PHP — hypertext preprocessor — скрипты включаются в текст с пом. <% script %>. Примеры в SDK.

3) Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.

4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

Ну вот примерно и все пока.

Философический вопрос вынесен в subject.
Re: Задумчиво так...: нужен ли народу scripting?
От: Aquary Россия https://wmspanel.com/
Дата: 12.09.05 06:36
Оценка: +1
Здравствуйте, c-smile, Вы писали:

CS>Философический вопрос вынесен в subject.


А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?
К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

Велосипед — это интересно и познавательно, для саморазвития — опять же — ценно, но когда время ограничено, проще заюзать что-то проверенное.
https://wmspanel.com/nimble — Nimble Streamer media server for live and VOD HLS, RTMP, HTTP streaming
https://wmspanel.com/ — Control and reporting panel for Wowza and Nimble Streamer
http://scm-notes.blogspot.com/ — Блог об управлении конфигурацией
Re: Задумчиво так...: нужен ли народу scripting?
От: ArtemGorikov Австралия жж
Дата: 12.09.05 06:58
Оценка: -1 :)
Здравствуйте, c-smile, Вы писали:

CS>Вот в результате работы над некими проектами получлся scripting engine.

CS>Подумалось что может быть полезным кому-то еще.
Народу нужна скриптовая машина, не зависисящая от M$.

CS>http://terrainformatica.com/tiscript/


CS>Основная идея engine — простота интегрируемости в чистый C/C++.

CS>API это 10 plain C функций плюс обертка для C++.
CS>Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.
Что значит "никаких зависимостей"? А эта dll-ка и есть зависимость. Хорошо бы иметь реализацию на шаблонах, например, на boost::spirit. Тут некоторые уважаемые товарищи предлагали csv-файлы парсить спиритом, ну это IMHO уже перебор, а вот для разбора скрипта — в самый раз. Чтобы можно было легко расширить и настроить его под свои потребности и синтаксис. Есть задачи, где лучше подойдет именно другой, не -жабовский, синтаксис.



CS>... 2) класс Number разделен на два — Integer и Float.

Это почему? Не всем удобно такое деление в скрипте.


CS>3)... Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.

Хотелось бы иметь JIT .


CS>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>Ну вот примерно и все пока.


CS>Философический вопрос вынесен в subject.

= 2be | !2be
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: Quintanar Россия  
Дата: 12.09.05 09:11
Оценка: +1 :))
Здравствуйте, Aquary, Вы писали:

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


CS>>Философический вопрос вынесен в subject.


A>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?

A>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

A>Велосипед — это интересно и познавательно, для саморазвития — опять же — ценно, но когда время ограничено, проще заюзать что-то проверенное.


Во-во. Особенно непонятно зачем использовать куцую Java'у. Я лично взял бы интерпретатор Scheme, благо есть различные по размерам реализации на все случаи жизни. А как язык для скриптов Scheme'а Java'у оставляет далеко за бортом.
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.09.05 10:35
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

CS>>Основная идея engine — простота интегрируемости в чистый C/C++.

CS>>API это 10 plain C функций плюс обертка для C++.
CS>>Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.
AG>Что значит "никаких зависимостей"? А эта dll-ка и есть зависимость. Хорошо бы иметь реализацию на шаблонах, например, на boost::spirit. Тут некоторые уважаемые товарищи предлагали csv-файлы парсить спиритом, ну это IMHO уже перебор, а вот для разбора скрипта — в самый раз. Чтобы можно было легко расширить и настроить его под свои потребности и синтаксис. Есть задачи, где лучше подойдет именно другой, не -жабовский, синтаксис.

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

CS>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

AG>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

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

Артем, раз ты такой сторонник XML-ных конфигов, можешь прокоментировать то, что я вот здесь нафантазировал: Re[23]: XML vs рукописный формат для конфигов
Автор: eao197
Дата: 09.09.05
(имеется в виду Ruby скрипт с конфигурацией, в котором возможна условная обработка). И насколько просто будет сделать подобное решение на XML?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.09.05 11:26
Оценка: -1 :))) :)
Задумчиво так... а ну его на...
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.09.05 11:38
Оценка:
Здравствуйте, Aquary, Вы писали:

CS>>Философический вопрос вынесен в subject.


A>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?

A>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

Присоединяюсь к этому вопросу.

И еще один вопрос: а как же c-smile?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 15:50
Оценка: 2 (2) +1
Здравствуйте, eao197, Вы писали:

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


CS>>>Философический вопрос вынесен в subject.


A>>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?

A>>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

E>Присоединяюсь к этому вопросу.


E>И еще один вопрос: а как же c-smile?


Все в общем-то просто. Нужен именно JavaScript c его моделью (prototyped).
В c-smile настоящие классы.

Одна из задач где мне нужен именно JavaScript'ing —
HTMLayout. К сожалению карта в отрасли легла таким
образом что все ожидают в HTML JS.

Не Python, не Perl, не Scheme, а именно JavaScript.
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 16:04
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

CS>>... 2) класс Number разделен на два — Integer и Float.

AG>Это почему? Не всем удобно такое деление в скрипте.

По стандарту все числа в JavaScript c плавающей точкой.

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


CS>>3)... Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.

AG>Хотелось бы иметь JIT .

JIT не возможен в typeless языках. Или если даже возможен
то эффективность его примерно ноль.

CS>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

AG>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

JavaScript, textual persistence:
data: {
  one: 1;
  two: "text";
}

То же но в XML:
<data type="map">
<one type="int">1</one>
<two type="string">text</two>
</data>

Т.е.
1) Как видишь XML немного "шумит".
2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 16:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Задумчиво так... а ну его на...


Вот и я о том.

Не хотел если честно этот лисапед делать.

Но заказчик...
Интересно люди оплачивают скажем год З/П
моей фирмы и хотят иметь scripting (в присыпку).
Вот я и задался вопросом а на кой им это надо?
И серьезные же люди...
Re: Задумчиво так...: нужен ли народу scripting?
От: Tuo_Bellas Россия  
Дата: 12.09.05 16:15
Оценка:
Здравствуйте, c-smile, Вы писали:

LUA + Luabind = rulez forever

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

Tuo_Bellas.
Re[2]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 16:37
Оценка:
Здравствуйте, Tuo_Bellas, Вы писали:

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


T_B>LUA + Luabind = rulez forever


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


T_B>Tuo_Bellas.


Согласен.

Но к сожалению LUA популярна в основном в среде "дети Борланда"...
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: ArtemGorikov Австралия жж
Дата: 12.09.05 17:01
Оценка: -1
Здравствуйте, eao197, Вы писали:


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


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


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

???!!!! И сколько же таких расширений накопится по мере расширения продукта? А ведь их еще придется потом поддерживать, баги править .

E>Артем, раз ты такой сторонник XML-ных конфигов, можешь прокоментировать то, что я вот здесь нафантазировал: Re[23]: XML vs рукописный формат для конфигов
Автор: eao197
Дата: 09.09.05
(имеется в виду Ruby скрипт с конфигурацией, в котором возможна условная обработка). И насколько просто будет сделать подобное решение на XML?


XML не для того придумали. IMHO если имеет место быть конфиг с условной обработкой, то это уже вопрос неправильной архитектуры.
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: ArtemGorikov Австралия жж
Дата: 12.09.05 17:09
Оценка: -1
Здравствуйте, c-smile, Вы писали:


CS>Не всем удобно например в String.charCodeAt(idx) иметь float

CS>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>эффективности этого дела.

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


CS>JIT не возможен в typeless языках. Или если даже возможен

CS>то эффективность его примерно ноль.
Почему невозможен? VARIANT и никаких проблем с приведением типов. Эффективность все же выше, как пример, код на C++, работающий с вариантами, быстрее аналогичного кода интерпретатора.


CS>>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

AG>>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>JavaScript, textual persistence:

CS>
CS>data: {
CS>  one: 1;
CS>  two: "text";
CS>}
CS>

CS>То же но в XML:
CS><data type="map">
CS> <one type="int">1</one>
CS> <two type="string">text</two>
CS></data>

CS>Т.е.

CS>1) Как видишь XML немного "шумит".
CS>2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.

Ну и что, что "шумит". Зато если прибавилось новое поле в структуру, оно проинициализируется по дефолту а не грохнется.
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: Gaperton http://gaperton.livejournal.com
Дата: 12.09.05 17:33
Оценка: 7 (1) +1
Здравствуйте, c-smile, Вы писали:

CS>JIT не возможен в typeless языках. Или если даже возможен

CS>то эффективность его примерно ноль.

С чего бы это вдруг? "Ведь наши ученые доказали, что любая форма жизни, у которой нет щупальцев, не может обладать разумом"?

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

Впрочем, к примерам. Psyco — JIT для Python. Ускоряет численные рассчеты раз в 25. А для Смоллтока джиты появились раньше чем для явы. Один из таких Смоллтоковских движков лег в основу первой версии Sun-овской виртуальной машины HotSpot.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 18:03
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

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



CS>>Не всем удобно например в String.charCodeAt(idx) иметь float

CS>>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>>эффективности этого дела.

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


Не понял высказывание если честно.

Как float "влезает" в нечто типа такого:
switch(String.charCodeAt(idx))
{
  case 'a': ....
  case 'b': ....
}


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

CS>>JIT не возможен в typeless языках. Или если даже возможен

CS>>то эффективность его примерно ноль.
AG>Почему невозможен? VARIANT и никаких проблем с приведением типов. Эффективность все же выше, как пример, код на C++, работающий с вариантами, быстрее аналогичного кода интерпретатора.

"Эффективность все же выше, как пример, код на C++,"

Не выше. Эффективность кода одна и та же. Во всяком случае у меня.

JIT есть компиляция байткода в машинные команды.
О каких машинных командах идет речь в случае VARIANT данных?

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


CS>>>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

AG>>>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>>JavaScript, textual persistence:

CS>>
CS>>data: {
CS>>  one: 1;
CS>>  two: "text";
CS>>}
CS>>

CS>>То же но в XML:
CS>><data type="map">
CS>> <one type="int">1</one>
CS>> <two type="string">text</two>
CS>></data>

CS>>Т.е.

CS>>1) Как видишь XML немного "шумит".
CS>>2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.

AG>Ну и что, что "шумит". Зато если прибавилось новое поле в структуру, оно проинициализируется по дефолту а не грохнется.


А почему оно должно "грохаться" в моем случае?

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

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


Или я не понял проблему?
Абсолютно та же flexibility что и в случае с XML.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 18:17
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


CS>>JIT не возможен в typeless языках. Или если даже возможен

CS>>то эффективность его примерно ноль.

G>С чего бы это вдруг? "Ведь наши ученые доказали, что любая форма жизни, у которой нет щупальцев, не может обладать разумом"?


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


Еще раз повторю вопрос:

Что можно сделать в JIT в случае с var a = b + c; если типы b и с не известны в момент JITа?

Что наверное можно но имхо выигрыш не будет стоить усилий затраченных на a) разработку JIT b)
увеличение объемов требуемых ресурсов.

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


Я не считаю что Psyco это решение (src: http://psyco.sourceforge.net/introduction.html) :
Причины выделены мной:

Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.

Benefits

2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.

Drawbacks

Psyco currently uses a lot of memory. It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.


Назначение scripting языков в "склеивании" эффективных "native" компонент между собой.
В итоге получаемая система выигрывает не скоростью а в разы увеличиваемым качеством
возможных суперпозиций/сочетаний.

Имхо как всегда.
Re[5]: Задумчиво так...: нужен ли народу scripting?
От: Gaperton http://gaperton.livejournal.com
Дата: 12.09.05 18:45
Оценка:
Здравствуйте, c-smile, Вы писали:

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


CS>Еще раз повторю вопрос:


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


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

CS>Что наверное можно но имхо выигрыш не будет стоить усилий затраченных на a) разработку JIT b)

CS>увеличение объемов требуемых ресурсов.

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


CS>Я не считаю что Psyco это решение (src: http://psyco.sourceforge.net/introduction.html) :

CS>Причины выделены мной:

CS>

CS>Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.

Зря выделяете "a kind of". Это самый настоящий джит, как бы авторы не прибеднялись. То, что вы выделяете "several version of the same blocks" — спокойно, господа, это не проблема, а просто одна из техник JIT компиляции параметрически полиморфных функций , которую я выше уже упоминал. Дотнет подобным образом компилирует женерики, и это считается "решением".

Теперь я повыделяю, почему я считаю это решением, ок?

CS>Benefits

CS>2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.

Спидап видели? Вот так. Комментируем далее:

CS>Drawbacks


CS>Psyco currently uses a lot of memory.

Слово currently заметили? Свойство реализации, а не принципиальная проблема. Во-первых, надо память подбирать периодически, что там пока не делается, во вторых главное заджитить версию функции для скалярных типов. В третьих, полиморфного кода в реальности не так много — процентов 25 может быть. Так что реальный оверхэд по памяти из-за хранения многочисленных скомпилированных версий одной функции я бы оценил в 2х, что терпимо.

CS>It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.

Semantic differences — выделяете, а пояснение, что имеются в виду ошибки (i.e. bugs) — нет. Проблема текущей реализации.

CS>Назначение scripting языков в "склеивании" эффективных "native" компонент между собой.

CS>В итоге получаемая система выигрывает не скоростью а в разы увеличиваемым качеством
CS>возможных суперпозиций/сочетаний.
+25. С этим я, собственно, согласен целиком. Я не согласен с тем, что "джыт невозможен для "бестиповых" языков". Как мы видим, возможен. И вопрос, нужно ли это в скриптовых языках — несколько другой.
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 12.09.05 19:02
Оценка: +3 -1
Здравствуйте, Gaperton, Вы писали:

G>+25. С этим я, собственно, согласен целиком. Я не согласен с тем, что "джыт невозможен для "бестиповых" языков". Как мы видим, возможен. И вопрос, нужно ли это в скриптовых языках — несколько другой.


[поскипано].

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

Например TIScript использует компиляцию в bytecode и исполнение оного.
Это относитлельно дешевое (протзводительность) и эффективное решение.
Утверждаю что для 90% случаев использования scripting это оптимальное или суб-оптимальное решение.

Те задачи которые действительно требуют того что дает JIT очень легко и максимально эффективно решаются в native коде. Нормальный script engine должен лишь предоставить простой и прозрачный способ встраивания native code в script. Все. Больше ничего не надо.

Еще раз JIT нужен тем системам которые претендуют на звание "универсальный язык программирования". Java, .NET и пр.
Для скриптовых языков JIT это ... ну даже не знаю как сказать...
пятая нога псу Мухтару наверное.
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.09.05 19:41
Оценка: :))) :)
Здравствуйте, c-smile, Вы писали:

CS>Не хотел если честно этот лисапед делать.


CS>Но заказчик...

CS>Интересно люди оплачивают скажем год З/П
CS>моей фирмы и хотят иметь scripting (в присыпку).

Тогда это уже превращается в святое дело и творческий процесс проедания денег заказчика.

CS>Вот я и задался вопросом а на кой им это надо?

CS>И серьезные же люди...

Ну, не всем же Челси скупать? Есть у людей и другие причуды.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.09.05 20:41
Оценка:
Здравствуйте, 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 как раз и попытался показать в своем примере, а я в своем.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: raskin Россия  
Дата: 13.09.05 05:24
Оценка:
c-smile wrote:
> Одна из задач где мне нужен именно JavaScript'ing —
> HTMLayout. К сожалению карта в отрасли легла таким
> образом что все ожидают в HTML JS.
>
> Не Python, не Perl, не Scheme, а именно JavaScript.

Ожидаю-то LISP: имеем дерево и набор атрибутов у вершин, как-то
подозрительно похоже на описание какого-то языка в упрощённой форме, а
вот видят все точно JS.
Posted via RSDN NNTP Server 2.0 beta
Re[5]: Задумчиво так...: нужен ли народу scripting?
От: ArtemGorikov Австралия жж
Дата: 13.09.05 06:15
Оценка: -1
Здравствуйте, 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 в роли диаложек — до сих пор проявляются траблы на машинах с последними сервис-паками из-за его параноидальных настроек безопасности.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: Колян  
Дата: 13.09.05 06:55
Оценка:
Здравствуйте, c-smile, Вы писали:

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


Чем тогда существующие движки не угодили? Mozilla/SpiderMonkey, KJS — все opensourse...
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 13.09.05 07:03
Оценка:
Здравствуйте, 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 дизайн (архитектура) мне категорически не нравится.
Re[7]: Задумчиво так...: нужен ли народу scripting?
От: ArtemGorikov Австралия жж
Дата: 13.09.05 08:07
Оценка: -1
Здравствуйте, 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. Табы тоже какие-то нестандартные. Конечно, креативность — это хорошо, но лучше в меру .
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: Tuo_Bellas Россия  
Дата: 13.09.05 09:19
Оценка:
Здравствуйте, c-smile, Вы писали:

T_B>>LUA + Luabind = rulez forever


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


CS>Согласен.


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


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

Tuo_Bellas.
Re[3]: Задумчиво так...: нужен ли народу scripting?
От: Колян  
Дата: 13.09.05 12:19
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Не всем удобно например в String.charCodeAt(idx) иметь float

CS>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>эффективности этого дела.

Это проблема реализации движка. Посмотри исходники аналогов, там это решается в runtime. Изначально тип int, если появилось деление, явно заданное дробное и пр., тогда оно становится double. А в скрипте все прозрачно — только Number.
В данном случае функция, реализующая charCodeAt вернет int и пока ты это значение не поделишь на что-нить, оно так int и останется.
Re[5]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 13.09.05 16:24
Оценка:
Здравствуйте, Колян, Вы писали:

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


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


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


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

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

1) Mozilla JS мне очень не нравится как сделан. Там по моему
используется прямая интерпретация AST. (Я могу ошибаться здесь)
Такое решение очень прожорливо по памяти.
2) KJS — вообще использует прямую инетрпретацию текста в стиле первых
и наивных имплементаций Basic. Детский сад, младшая группа.
Скорости (да и надежности) от этого решения ожидать не стоит.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 13.09.05 16:29
Оценка:
Здравствуйте, Tuo_Bellas, Вы писали:

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


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


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

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

У LUA странный микс (для меня лично) в нотации — смесь С и Pascal
конструкций.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 13.09.05 18:57
Оценка:
Здравствуйте, Колян, Вы писали:

К>Здравствуйте, 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 и останется.
Re[4]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.05 23:36
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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

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


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

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


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

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


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

В общем, если в языке нет статической типизации, пусть даже неявной (с выводом типов), то достичь уровня оптимизации доступного из статически типизированных языков/джитов нельзя физически. И не нужно агитировать за советскую власть.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.05 23:36
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Вот тут как-то тестировали рассчет альфы. Кто-то сбацал тест на Питоне и прогнал его с Пико. И каков же был результат? В заднице Питон на таких задачах. А вот джитовые языки и языки с выводом типов не сморя на ЖЦ и другие не оптимальности смотрелись очень даже неплохо.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.05 23:36
Оценка:
Здравствуйте, c-smile, Вы писали:

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

CS>Для скриптовых языков JIT это ... ну даже не знаю как сказать...
CS>пятая нога псу Мухтару наверное.

Хорошо прикрученный джит вряд ли кому помешает. А вот если на высокоуровневом язке можно будет не прибегая к разным С наваять чуть больше кода, то многие задачи будут решаться куда быстрее и проще. А что еще нужно?
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 14.09.05 06:37
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

CS>>Для скриптовых языков JIT это ... ну даже не знаю как сказать...
CS>>пятая нога псу Мухтару наверное.

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


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

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


Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось.
Взять тот же PHP....
Вот кстати феномен тоже. Язык рождался на ходу, соответсвенно всякие несуразицы в синтаксисие.
Но ежики плачут но лезут на кактус... И нафиг никому по большому счету не упали ни классы ни наследование ни JIT.
Язык для народа. И народ на нем пишет. И красиво кстати пишет...
Re[5]: Задумчиво так...: нужен ли народу scripting?
От: Quintanar Россия  
Дата: 14.09.05 09:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Не совсем. Если язык поддерживает возможность проверки типов и программист не ленится их уточнять, где надо, то динамическую типизацию можно частично обойти. В C# типизация тоже не строгая — есть возможность оперировать object'ами, следовательно все, что требуется, это свести в программе количество мест с object'ами к минимуму.
Re[5]: Задумчиво так...: нужен ли народу scripting?
От: Lloyd Россия  
Дата: 14.09.05 13:01
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

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


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


На порядок == в 10 раз быстрее. Ты считаешь, что Psyco не следовало делать таким быстрым?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: Колян  
Дата: 14.09.05 15:16
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>1) Mozilla JS мне очень не нравится как сделан. Там по моему

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

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

CS>2) KJS — вообще использует прямую инетрпретацию текста в стиле первых

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

+1
Re[9]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.05 15:55
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось.

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

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

Лично я скорее выучу Лисп и начну писать не нем, чем прибегну к ПХП. Так что ПХП — это как и ЯваСкрипт... просто так легла карта. Но в отличии от ЯваСкрипт вместо ПХП можно легко проименять полноценные языки, так как клиент видит только результат в виде ХТМЛ. А вот ЯваСкрипт засел в браузерах надолго... стандарт однако.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.05 15:55
Оценка:
Здравствуйте, Quintanar, Вы писали:

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


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


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


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

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


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

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


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

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

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

У C# есть другие места которые приводят к динамическим вычислениям (хотя и не столь значительным). Это, например, делегаты, виртуальные методы, интерфейсы и приведения типов. На сегодня они никак не оптимизируются. Но потенциально большинство таких место таки подаются оптимизации. Так локально испоьзуемый делегат может быть устранен, а не его место может быть подставлен прямой вызов или даже тело вызываемого метода. ФЯ как раз очень харашо демонстрируют насколько это возможно.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.05 15:55
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


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


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


Сри, неврено прочел. 25 — это просто нереальная цифра. Хороший интерпретатор приблизительно в 10-15 раз медленее компилятора. Получается, что Пико делает код в 2-2.5 раза быстрее чем оптимальный ассемблерынй код.

Думаю, реальная цифра бдет 2-10 раз.
Рельные же (не подтасованные) эксперементы показывают, что Пико до типизированных джитов как до луны.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.09.05 16:09
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 14.09.05 16:18
Оценка:
Здравствуйте, VladD2, Вы писали:

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


CS>>Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось.

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

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


"хостится этот самый народ" ... я тоже

Не знаю как по поводу тових причин...
Я например выбрал именно PHP (не зная его совершенно) потому как
a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель
с) добра на нем написано....

Вот пример: потребовался мне blog engine и я
за один вечер приделал вот это:
http://blocknote.net/blog/index.php
из вот этого
http://sourceforge.net/projects/sphpblog/

стили, раскладку и подгон под то чтобы можно было
писать статьи в BlockNote.

Forum на terrainformatica.com — с нуля — два дня.
Весь сайт — еще четыре.

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


Полноценность...
Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%
Re[11]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.05 22:41
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Не знаю как по поводу тових причин...

CS>Я например выбрал именно PHP (не зная его совершенно) потому как
CS>a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель
CS>с) добра на нем написано....

Ты не понимашь нотации C# или Явы?
На этих языках написано мало добра?

CS>Вот пример: потребовался мне blog engine и я

CS>за один вечер приделал вот это:
CS>http://blocknote.net/blog/index.php
CS>из вот этого
CS>http://sourceforge.net/projects/sphpblog/

Так же ты нашел бы тоже самое и на C# с Явой.

CS>Forum на terrainformatica.com — с нуля — два дня.

CS>Весь сайт — еще четыре.

Посмотрите на этот мир и посмотрите на эти шатны (с) анекдот.

CS>Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%


А я бурусь утверждат, что если задача сложнее гостевухи на личной страничке, то Ява и Шарп с их фреймворками куда более удобне и полноеценное решение. Ну, а лабать сайты можно и на VBScript. Тоже себе полноценное решение.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.05 22:41
Оценка:
Здравствуйте, eao197, Вы писали:

E>Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.


Согласен и даже скажу больше. Многие сильные стороны других перечисленных языков тоже заточены на интерпретируемость и безтиповость. Однако это всего лишь упрощает задачу. Но все тоже самое можно реализовать и в компилируемых, строготипизированных средах. Просто тут нужны уже более мощьные которы и технологии.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 14.09.05 23:58
Оценка:
Здравствуйте, VladD2, Вы писали:

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


CS>>Не знаю как по поводу тових причин...

CS>>Я например выбрал именно PHP (не зная его совершенно) потому как
CS>>a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель
CS>>с) добра на нем написано....

VD>Ты не понимашь нотации C# или Явы?

VD>На этих языках написано мало добра?

Много. Но что-то мне кажется что на PHP больше всякого под inet сделано.
Во всяком случае у PHP своя ниша и большая — малогабаритные системы.
Те же Wiki, Blog'и и прочие PHPBB. Все вместе взятое по количесву инсталляций с C# и не подходи.
Рискну заметить что если Апач то это PHP в 90% случаев.

http://news.netcraft.com/archives/2005/09/overallc.gif


CS>>Вот пример: потребовался мне blog engine и я

CS>>за один вечер приделал вот это:
CS>>http://blocknote.net/blog/index.php
CS>>из вот этого
CS>>http://sourceforge.net/projects/sphpblog/

VD>Так же ты нашел бы тоже самое и на C# с Явой.


1) Ты знаешь — не нашел. Если покажешь пальцем буду признателен.
2) Зачем мне на мой Апач JSP ставить? А тем более C# (ASP.NET)?


CS>>Forum на terrainformatica.com — с нуля — два дня.

CS>>Весь сайт — еще четыре.

VD>Посмотрите на этот мир и посмотрите на эти шатны (с) анекдот.


Угу. "Дешево и сердито"

CS>>Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%


VD>А я бурусь утверждат, что если задача сложнее гостевухи на личной страничке, то Ява и Шарп с их фреймворками куда более удобне и полноеценное решение. Ну, а лабать сайты можно и на VBScript. Тоже себе полноценное решение.


На VBScript? Говорят можно, но не видел вживую изнутри чего-то настоящего..

Если мы говорим про web services или web applications то там да, имеет место и смысл быть Яве или Шарпу.
Но сайты для народа — с выше перечисленными компонентами — этим стрелять по воробьям не надо.
Re[9]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.05 05:40
Оценка: 2 (2)
Здравствуйте, VladD2, Вы писали:

E>>Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.


VD>Согласен и даже скажу больше. Многие сильные стороны других перечисленных языков тоже заточены на интерпретируемость и безтиповость. Однако это всего лишь упрощает задачу. Но все тоже самое можно реализовать и в компилируемых, строготипизированных средах. Просто тут нужны уже более мощьные которы и технологии.


Вот по поводу выделенного у меня есть определенные сомнения. В Ruby существует специальный термин "Duck Typing":

In Ruby, the class is never (OK, almost never) the type. Instead, the type of an object is
defined more by what that object can do. In Ruby, we call this duck typing. If an object
walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it
were a duck.

(Programming Ruby, 2nd edition).

Этот термин определяет одну из важнейших концепций Ruby (возможно в Python и Smalltalk тоже самое): для того, чтобы объект мог принимать участие в какой-то операции всего лишь требуется, чтобы объект предоставлял методы, используемые в данной операции (похоже на шаблоны в C++). Приведу несколько примеров для иллюстрации (из той же книги Programming Ruby).

Предположим, что нам нужно иметь структуру, которая хранит информацию о клиенте и позволяет записывать эту информацию в указанный файл:
class Customer
    def initialize(first_name, last_name)
        @first_name = first_name
        @last_name = last_name
    end
    def append_name_to_file(file)
        file << @first_name << " " << @last_name
    end
end

Для проверки работоспособности класса Customer создаем Unit-тест:
require 'test/unit'
require 'addcust'

class TestAddCustomer < Test::Unit::TestCase
    def test_add
        c = Customer.new("Ima", "Customer")
        
        f = File.open("tmpfile", "w") do |f|
            c.append_name_to_file(f)
        end
        
        f = File.open("tmpfile") do |f|
            assert_equal("Ima Customer", f.gets)
        end
    ensure
        File.delete("tmpfile") if File.exist?("tmpfile")
    end
end

Test-case с именем test_add создает объект типа Customer и записывает его в файл tmpfile. Затем открывает этот же файл для чтения и проверяет, что информация была правильно в него записана. И на последок, чтобы не оставлять после себя мусора, tmpfile удаляется.
Благодоря duck typing этот test-case можно упростить, поскольку для Customer#append_name_to_file нужен объект, который поддерживает оператор <<. В Ruby это не только файл, но и String:
require 'test/unit'
require 'addcust'

class TestAddCustomer < Test::Unit::TestCase
    def test_add
        c = Customer.new("Ima", "Customer")
        f = ""
        c.append_name_to_file(f)
        assert_equal("Ima Customer", f)
    end
end

А так же и Array:
require 'test/unit'
require 'addcust'

class TestAddCustomer < Test::Unit::TestCase
    def test_add
        c = Customer.new("Ima", "Customer")
        f = []
        c.append_name_to_file(f)
        assert_equal(["Ima", " ", "Customer"], f)
    end
end


Т.е. благодоря duck typing объект Customer может работать с гораздо большим количеством классов, чем это предполагалось ранее. Что, вообще-то говоря, дает большую гибкость использования объектов Customer. В статически типизируемых языках метод append_name_to_file должен был бы получать в качестве пераметра какой-то интерфейс. Скажем std::ostream в C++. Но в том же C++ ни std::string, ни std::vector (list, deque) не являются наследниками std::ostream. Подозреваю, что в C# и Java с потоками ввода-вывода и классами String, ArrayList и пр. такая же ситуация. И чтобы достичь в статически типизированном языке такого же эффекта, нужно будет для String/Vector писать какую-то обертку, реализующую нужный интерфейс. В С++ это можно было бы сделать на шаблонах:
class Customer
    {
        std::string    first_name_;
        std::string    last_name_;
    public :
        ...
        template< class Receiver >
        void append_name_to_file( Receiver & f )
            {
                f << first_name_ << " " << last_name_;
            }
    };

// Обертка для предоставления возможности сохранения содержимого Customer в строку.
class String_As_Receiver
    {
        std::string &    receiver_;
    public :
        String_As_Receiver( std::string & receiver ) : receiver_( receiver ) {}
        
        String_As_Receiver &
        operator<<( const std::string & what )
            {
                receiver_.append( what );
                return *this;
            }
    };
    
// Обертка для предоставления возможности сохранения содержимого Customer в вектор (список, дек).
template< class Container >
class    Container_As_Receiver
    {
        Container &    receiver_;
    public :
        Container_As_Receiver( Container & receiver ) : receiver_( receiver ) {}
        
        Container_As_Receiver &
        operator<<( const std::string & what )
            {
                receiver_.push_back( what );
                return *this;
            }
    };
    
// А теперь использование всего этого безобразия.
Customer c( "Ima", "Customer" );

{
    std::ofstream f( "tmpfile" );
    c.append_name_to_file( f );
}

{
    std::string s;
    String_As_Receiver r( s );
    c.append_name_to_file( r );
}

{
    std::vector v;
    Container_As_Receiver r( v );
    c.append_name_to_file( r );
}


Т.е. получаем практически такой же эффект, но гораздо большими усилиями.

Конечно, кто-то задастся вопросом, а зачем вообще такая гибкость нужна? Лично мне кажется, что эта гибкость необходима для сопровождения кода, когда для внесения значительных изменений потребуется сделать всего несколько модификаций. И, что интересно, в Programming Ruby приводится похожий пример из реального Web-приложения. В этом приложении была возможность даунлоада содержимого некоторой базы в CSV формате. И при нагрузочном тестировании буквально перед запуском оказалось, что операция CSV выполняется недопустимо долго. Оказалось, что проблема была в коде:
def csv_from_row(op, row)
    res = ""
    until row.empty?
        entry = row.shift.to_s
        if /[,"]/ =~ entry
            entry = entry.gsub(/"/, '""')
            res << '"' << entry << '"'
        else
            res << entry
        end
        res << "," unless row.empty?
    end
    op << res << CRLF
end

result = ""
query.each_row {|row| csv_from_row(result, row)}
http.write result

На больших объемах входных данных этот код сильно тормозил. Оказалось, что дело в garbage collector-е. По мере роста результирующей строки result переодически запускался GC который прибивал множество небольших временных строк res, которые образовывались на каждой итерации цикла.
Для того, чтобы преодолеть эту проблему был просто заменен тип переменной result -- вместо String, который сохранял свое значение в непрерывном блоке памяти, применили Array, который хранил свое содержимое как множество мелких объектов:
def csv_from_row(op, row)
    # Код не изменился.
end

result = []
query.each_row {|row| csv_from_row(result, row)}
http.write result.join


Конечно же, можно говорить, что у разработчиков и руки кривые, и что они сразу не увидели, что здесь может быть замедление работы, и еще что-нибудь Только, имхо, здесь был полностью задействован принцип о преждевременной оптимизации. Сначала получили работающий корректный код. А потом, изменив всего две строки, сделали его быстрым.

Вот такая вот у duck typing гибкость. Правда расплачиваться за нее приходится скоростью исполнения (и большим количеством unit-test-ов, что вряд ли плохо). Но я сомневаюсь, что в статически-типизированных языках можно достичь чего-нибудь подобного. Да и если можно, то на это время потребуется. А в Ruby (вероятно и в Python, Smalltalk, etc) это есть уже сейчас.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 15.09.05 06:03
Оценка: 4 (4) :))) :))) :))) :))
Здравствуйте, eao197, Вы писали:

Duck typing это попсовый жаргон.
Сейчас настоящие пацаны говорят 'Unintrusive Retroactive Polymorphism'. Оппонент сразу вянет.

http://www.heron-language.com/interfaces.html
Re[11]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.05 08:45
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Duck typing это попсовый жаргон.




CS>Сейчас настоящие пацаны говорят 'Unintrusive Retroactive Polymorphism'. Оппонент сразу вянет.


CS>http://www.heron-language.com/interfaces.html


Имхо, duck typing от Unintrusive Retroactive Polymorphism все же отличается. Как я понял, если какой-то класс пытаются выдать за интерфейс, то в этом классе должны быть реализованы все методы интерфейса. Т.е., если бы в приведенном по ссылке примере:
types {
    class Dog {
        MakeSound() : String {
            return "woof";
        }
        GetNumLegs() : Int {
            return 4;
        }
        GoFetch() {
            // ...
        }
    }

    class Duck {
        GetNumLegs() : Int {
            return 2;
        }
        MakeSound() : String {
            return "quack";
        }
        FlySouth() {
            // ...
        }
    }

    interface IAnimal {
        MakeSound() : String;
        GetNumOfLegs() : Int;
        // Был бы еще вот такой метод.
        GoAway();
    }
}

То следующий код, как я понимаю, не скомпилировался бы:
functions {
    _main() {
        IAnimal& animal;
        Dog dog;
        Duck duck;
        // Здесь следовало бы ожидать ошибку, т.к. у Dog нет метода GoAway.
        animal = @dog;
        P(animal.MakeSound()); // outputs woof
        // И здесь так же.
        animal = @duck;
        P(animal.MakeSound()); // outputs quack
    }
}

Или я ошибаюсь?

А вот в duck typing все же не требуется от объекта иметь все методы, которые у него могут потребоваться. Например:
class Dog
    def make_sound; "woof" end
    def get_num_legs; 4 end
    def go_fetch; end
end

class Duck
    def make_sound; "quack" end
    def get_num_legs; 2 end
    def fly_south; end
end

class Cat
    def make_sound; "miau" end
    def get_num_legs; 4 end
    def go_away!; puts "Frrrrr!" end
end

def play_with_animal( animal )
    sound = animal.make_sound
    if "woof" != sound && "quack" != sound
        animal.go_away!
    else
        puts "I like animal with sound '#{sound}'"
    end
end

play_with_animal Dog.new
play_with_animal Duck.new
play_with_animal Cat.new

в результате выполнения получаем:
I like animal with sound 'woof'
I like animal with sound 'quack'
Frrrrr!

и никаких ошибок. Аналогичные штуки с C++ шаблонами можно делать.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
От: Lloyd Россия  
Дата: 15.09.05 09:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А яваскрипт-то в качестве скрипта чем плох?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[13]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.09.05 12:34
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Много. Но что-то мне кажется что на PHP больше всякого под inet сделано.


Не думаю.

CS>Во всяком случае у PHP своя ниша и большая — малогабаритные системы.

CS>Те же Wiki, Blog'и и прочие PHPBB. Все вместе взятое по количесву инсталляций с C# и не подходи.

По количеству несомненно. Но по деньгам уже ПХП рядом не валялся.

CS>Рискну заметить что если Апач то это PHP в 90% случаев.


Опять же в случаях домашних страничек.

CS>http://news.netcraft.com/archives/2005/09/overallc.gif


Этому ресурсу я неверю уже давно. Он явно предвзят.

VD>>Так же ты нашел бы тоже самое и на C# с Явой.


CS>1) Ты знаешь — не нашел.


Плохо искал. У нас мужики быстро нашли.

CS>Если покажешь пальцем буду признателен.


Спроси что взяли на GDN для блогов.

CS>2) Зачем мне на мой Апач JSP ставить? А тем более C# (ASP.NET)?


Чтобы не возиться с куцым и убогим ПХП. Ну, и плюс... вдруг у тебя нагрузки большие. Тогда компилируемый и типизированный язык точно даст приемущество.

CS>На VBScript? Говорят можно, но не видел вживую изнутри чего-то настоящего..


90% ASP сайтов.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.09.05 12:34
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>А яваскрипт-то в качестве скрипта чем плох?


Проще попробовать найти хотя бы одно приумущество над любым другим языком. К примеру, чем он лучше Руби?
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.09.05 12:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот такая вот у duck typing гибкость.


Это гибгатьс на грани фола. А скорее за гранью. Нет проблем выражать полиморфизм явно. Делегаты и интерфейсы еще никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Задумчиво так...: нужен ли народу scripting?
От: Lloyd Россия  
Дата: 15.09.05 12:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Проще попробовать найти хотя бы одно приумущество над любым другим языком. К примеру, чем он лучше Руби?


м.б. тем что проще?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[11]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.05 12:54
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Вот такая вот у duck typing гибкость.


VD>Это гибгатьс на грани фола. А скорее за гранью. Нет проблем выражать полиморфизм явно. Делегаты и интерфейсы еще никто не отменял.


Вот что интересно: год назад я бы еще более грубо по этому поводу высказался бы. А сейчас уже привык, почти. Удобно, однако. Сам не ожидал.

19. A language that doesn't affect the way you think about programming, is not worth knowing.

((C) EPIGRAMS IN PROGRAMMING).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.09.05 13:59
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>м.б. тем что проще?


Я бы так не сказал. Тот же руби куда проще.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.05 14:17
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>м.б. тем что проще?


VD>Я бы так не сказал. Тот же руби куда проще.


Простота Ruby мне кажется весьма обманчивой. Чем больше я его изучаю, тем больше думаю, что он не намного проще C++. А может быть и вовсе не проще.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Задумчиво так...: нужен ли народу scripting?
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.09.05 15:20
Оценка:
Здравствуйте, eao197, Вы писали:

E>Простота Ruby мне кажется весьма обманчивой. Чем больше я его изучаю, тем больше думаю, что он не намного проще C++. А может быть и вовсе не проще.


Это терминалогический спор. Я говорю о простоте использования.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.05 15:36
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Простота Ruby мне кажется весьма обманчивой. Чем больше я его изучаю, тем больше думаю, что он не намного проще C++. А может быть и вовсе не проще.


VD>Это терминалогический спор. Я говорю о простоте использования.


Вообще-то я тоже
Ruby совсем не так прост, как кажется. Вот, например: Seeing Metaclasses Clearly.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 15.09.05 16:09
Оценка:
Здравствуйте, eao197, Вы писали:

E>Имхо, duck typing от Unintrusive Retroactive Polymorphism все же отличается.


Ну а самые крутые пацаны говорят так:

Late Binded Unintrusive Retroactive Polymorphism based on Discriminated Union Type System.
Re[13]: Задумчиво так...: нужен ли народу scripting?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.09.05 06:10
Оценка: :)))
Здравствуйте, c-smile, Вы писали:

E>>Имхо, duck typing от Unintrusive Retroactive Polymorphism все же отличается.


CS>Ну а самые крутые пацаны говорят так:


CS>Late Binded Unintrusive Retroactive Polymorphism based on Discriminated Union Type System.


Новый русский приезжает в магазин антикварных музыкальных инструментов:
-- Слышь, мне чисто конкретно для братана подарок нужен! Он типа музыку уважает.
-- Вот, пожалуйста, специально для вас есть уникальная вещь: барабан работы великого итальянского мастера Страдивари.
Новый русский покупает барабан, уезжает, вручает подарок. Над ним смеются:
-- Да тебя развели: Страдивари скрипки пилил!
Новый русский хватает свою братву и уносится на разборки в магазин. Через полчаса возвращается довольный:
-- Не пацаны, все нормально. Страдивари для лохов скрипки пилил. А для реальных пацанов -- барабаны!


duck typing -- это, типа для обычных.
А для реально крутых пацанов вот это самое, LBURPDUTS (расшифровку см. выше)
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Задумчиво так...: нужен ли народу scripting?
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.09.05 08:03
Оценка: 18 (1) :)
Здравствуйте, c-smile, Вы писали:
CS>Late Bound Unintrusive Retroactive Polymorphism based on Discriminated Union Type System.
Угу, в разговоре произносится этак небрежно: LBURP/DUTS.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Задумчиво так...: нужен ли народу scripting?
От: c-smile Канада http://terrainformatica.com
Дата: 16.09.05 16:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

CS>>Late Bound Unintrusive Retroactive Polymorphism based on Discriminated Union Type System.

Ага, спасибо. Затмение нашло.

На самаом деле надо наверное писать так

Unintrusive Retroactive Polymorphism based on Discriminated Union Type System and/with Late Binding

А то Late Bound уже не то получается.

Полуаем URP/DUTSLB или заменяя сокращение lb (фунты) — URP/DUTS-pound


S>Угу, в разговоре произносится этак небрежно: LBURP/DUTS.
Re: Задумчиво так...: нужен ли народу scripting?
От: iLYA Канада http://www.bizon.org/ilya/
Дата: 17.09.05 18:18
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Философический вопрос вынесен в subject.


Немного оффтоп, но интересная ссылка: http://unigine.com/products/unigine_v0.32/compiler_benchmark/
Re[12]: Задумчиво так...: нужен ли народу scripting?
От: FR  
Дата: 22.09.05 13:34
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

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


E>>>Вот такая вот у duck typing гибкость.


VD>>Это гибгатьс на грани фола. А скорее за гранью. Нет проблем выражать полиморфизм явно. Делегаты и интерфейсы еще никто не отменял.


E>Вот что интересно: год назад я бы еще более грубо по этому поводу высказался бы. А сейчас уже привык, почти. Удобно, однако. Сам не ожидал.


У меня такая же ситуация только с питоном
Re: Задумчиво так...: нужен ли народу scripting?
От: Aviator  
Дата: 23.09.05 05:39
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Вот в результате работы над некими проектами получлся scripting engine.

CS>Подумалось что может быть полезным кому-то еще.

CS>http://terrainformatica.com/tiscript/


CS>Основная идея engine — простота интегрируемости в чистый C/C++.

CS>API это 10 plain C функций плюс обертка для C++.
CS>Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.

CS>Сам язык близок к JavaScript "as much as possible"


CS>JavaScript фичи которые попали под нож:


CS>1) упрощена вся эта скажем прямо ахинея вокруг prototype, __proto__ и иже с ними.

CS>Классы и наследование стало прозрчнее и очевиднее. См. http://terrainformatica.com/tiscript/Syntax.whtm#classes

CS>2) класс Number разделен на два — Integer и Float.


CS>Все остальное в принципе должно быть близко к JavaScript. Во всяком случае есть такое намерение.

CS>Это то что касается языка.

CS>Что нового:


CS>1) Появились потоки ввода вывода. File and socket Stream. Соответственно в скрипте определены stdin, stdout, stderr. Ну и printf и всякие штуки типа stdout << "Hi, world!";

CS>Хост-приложение само определеяет что есть эти самые stdin, stdout, stderr.

CS>2) Добавлен режим работы PHP — hypertext preprocessor — скрипты включаются в текст с пом. <% script %>. Примеры в SDK.


CS>3) Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.


CS>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js


CS>Ну вот примерно и все пока.


CS>Философический вопрос вынесен в subject.


Жаль сурсов интерпретатора нет — или я плохо смотрел ?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.