Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

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

V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

А вопрос в форуме "о работе" потому, что большинство в другие редко заглядывает?

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

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

V>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

VM>А вопрос в форуме "о работе" потому, что большинство в другие редко заглядывает?

Нет. Просто иконка была открыта на этом форуме.
Иконки либо команды ВНЕ како-го-либо форума не нашел.
Исправлюсь.

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

V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор.

а чем интерпертатор отличается от компилятор?
+ интерпертатор куда?

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

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

AD>а чем интерпертатор отличается от компилятор?
AD>+ интерпертатор куда?

а какая разница? главное же чтобы быстро...

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

S>Здравствуйте, Alex Dav, Вы писали:

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

AD>>а чем интерпертатор отличается от компилятор?
AD>>+ интерпертатор куда?

S>а какая разница? главное же чтобы быстро...

Да. Главное — чтобы БЫСТРО В общем нахождение ЗДЕСЬ, в разделе РАБОТА,
обусловлено примерно тем же, чем знаменит некий анекдот.
Президенты MS и GM раговаривают: второй ехидно замечает первому:
— Если бы мы должны были прежде чем заглушить движок нажать клавишу ПУСК

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

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

V>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор.

AD>а чем интерпертатор отличается от компилятор?
AD>+ интерпертатор куда?

Коды берутся и НА ЛЕТУ превращаются в ОБЪЕКТНЫЕ
Медленно очень. ОООЧЕНЬ.
Система сбора и обработки информации.

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

V>Коды берутся и НА ЛЕТУ превращаются в ОБЪЕКТНЫЕ
V>Медленно очень. ОООЧЕНЬ.
V>Система сбора и обработки информации.

То есть JIT используется?
Если нет то может будет проще его прикрутить к интерпретатору?

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

V>Коды берутся и НА ЛЕТУ превращаются в ОБЪЕКТНЫЕ
V>Медленно очень. ОООЧЕНЬ.
V>Система сбора и обработки информации.

вы меня извините — может я плохо учился в институте — зато сам делал интерпретатор и немного учил англ. — интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой. Как я понимаю вы хотите что бы этим конечным языком был машиный кода, а еще точнее вам нужен исполняемый файл — вот от сюда и надо бежать — берем что у вас получается на конце — асемблерный код? берете компилятор ассемблера (tasm к примеру) и через ком. строку компилите. Тоже делаете для других языков.

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

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

V>>Коды берутся и НА ЛЕТУ превращаются в ОБЪЕКТНЫЕ
V>>Медленно очень. ОООЧЕНЬ.
V>>Система сбора и обработки информации.

AD>вы меня извините — может я плохо учился в институте — зато сам делал интерпретатор и немного учил англ. — интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой. Как я понимаю вы хотите что бы этим конечным языком был машиный кода, а еще точнее вам нужен исполняемый файл — вот от сюда и надо бежать — берем что у вас получается на конце — асемблерный код? берете компилятор ассемблера (tasm к примеру) и через ком. строку компилите. Тоже делаете для других языков.

Поясняю. Мне нужен код не в виде объектного кода в файле, а в буфере.
Дело в том, что бесконечный повтор пуш-попов бессмыслен абсолютно — если объем кода исполнения немаленький.
Если я запишу в память исполняемый код и затем просто передам управление первой команде из списка —
у меня будет просто ДИКАЯ экономия. В общем-то, в данном случае есть уже кой-какой опыт.
Но речь о создании кода для ДРАЙВЕРА, а здесь малость не то.
Там не было ПРОИЗВОЛЬНЫХ выражений справа ранее.
Насчет того, что интерпретатор и компайлер — одно и то же — Вы не правы

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

V>Поясняю. Мне нужен код не в виде объектного кода в файле, а в буфере.
V>Дело в том, что бесконечный повтор пуш-попов бессмыслен абсолютно — если объем кода исполнения немаленький.
V>Если я запишу в память исполняемый код и затем просто передам управление первой команде из списка -
V>у меня будет просто ДИКАЯ экономия. В общем-то, в данном случае есть уже кой-какой опыт.
V>Но речь о создании кода для ДРАЙВЕРА, а здесь малость не то.
V>Там не было ПРОИЗВОЛЬНЫХ выражений справа ранее.
честно говоря ничего не понял Наверное я сильно отстал в этом деле

V>Насчет того, что интерпретатор и компайлер — одно и то же — Вы не правы
ваше право так думать
здесь

но вы я так понимаю имеете ввиду это
здесь

ну а на мой взгляд это просто попытка разделить подчасти одного и того же используя разные слова при переводе на русский (ИМХО)

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

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

V>>Поясняю. Мне нужен код не в виде объектного кода в файле, а в буфере.
V>>Дело в том, что бесконечный повтор пуш-попов бессмыслен абсолютно — если объем кода исполнения немаленький.
V>>Если я запишу в память исполняемый код и затем просто передам управление первой команде из списка -
V>>у меня будет просто ДИКАЯ экономия. В общем-то, в данном случае есть уже кой-какой опыт.
V>>Но речь о создании кода для ДРАЙВЕРА, а здесь малость не то.
V>>Там не было ПРОИЗВОЛЬНЫХ выражений справа ранее.
AD>честно говоря ничего не понял Наверное я сильно отстал в этом деле

V>>Насчет того, что интерпретатор и компайлер — одно и то же — Вы не правы
AD>ваше право так думать
AD>здесь

AD>но вы я так понимаю имеете ввиду это
AD>здесь

AD>ну а на мой взгляд это просто попытка разделить подчасти одного и того же используя разные слова при переводе на русский (ИМХО)

Да аб чем базар-та?
Мне просто нужно к завтрему сделать бы код, который будет раз в 50 быстрее исполняться,
чем если без конца перекидывать токены туда-сюда

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

AD>вы меня извините — может я плохо учился в институте — зато сам делал интерпретатор и немного учил англ. — интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой.
Интерпретатор исполняет код, он не одно и тоже с компилятором.

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

T>Здравствуйте, Alex Dav, Вы писали:

AD>>вы меня извините — может я плохо учился в институте — зато сам делал интерпретатор и немного учил англ. — интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой.
T>Интерпретатор исполняет код, он не одно и тоже с компилятором.

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

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

T>Здравствуйте, Alex Dav, Вы писали:

AD>>вы меня извините — может я плохо учился в институте — зато сам делал интерпретатор и немного учил англ. — интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой.
T>Интерпретатор исполняет код, он не одно и тоже с компилятором.

код исполняет виртуальная машина Java, .net framework, OS, а интерпретатор — то что я сказал. Но как я понял автору нужен интерпретатор (компилятор) с пошаговым исполением.

V>Интерпретатор — строку за строкой читает и в реальном времени выдает окончательный результат.
V>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код путем передачи управления на начало.

Тебе нужно написать транслятор, т.е. некий конвертер, который будет создавать исполняемый .exe-файл на основе твоего макроязыка. Но за день ты это не напишешь, даже и не думай. Мануалы интеловские читать, формат PE-файлов учить и так далее. Здесь тебе не помогут с этим, если только сможешь сформулировать конкретные вопросы и с ними целенаправленно идти уже в профильные форумы.

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

x64>Тебе нужно написать транслятор, т.е. некий конвертер, который будет создавать исполняемый .exe-файл на основе твоего макроязыка. Но за день ты это не напишешь, даже и не думай. Мануалы интеловские читать, формат PE-файлов учить и так далее.

Ну, если его устроит любая современная VM, то может и не надо. А можно и без, при помощи хотя бы моновсгого АОТ компайлера.

V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

А какой язык интерпретируете?

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

x64>Тебе нужно написать транслятор, т.е. некий конвертер, который будет создавать исполняемый .exe-файл на основе твоего макроязыка. Но за день ты это не напишешь, даже и не думай. Мануалы интеловские читать, формат PE-файлов учить и так далее.

Не обязательно так глубоко лезть. Достаточно транслировать в какой-либо другой компилируемый язык, например в C. А уже потом компилировать C используя сторонний компилятор.

L>Не обязательно так глубоко лезть. Достаточно транслировать в какой-либо другой компилируемый язык, например в C. А уже потом компилировать C используя сторонний компилятор.

Как вариант. Тот же C# можно взять

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

L>>Не обязательно так глубоко лезть. Достаточно транслировать в какой-либо другой компилируемый язык, например в C. А уже потом компилировать C используя сторонний компилятор.

x64>Как вариант. Тот же C# можно взять

Ну это смотря какая платформа у программы. Если .Net, то можно и шарп взять.

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

V>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

T>А какой язык интерпретируете?

Свой. Си-подобный. В принципе, проблема уже снЯта.

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

x64>Как вариант. Тот же C# можно взять

C# не надо, IL удобнее.

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

V>>Интерпретатор — строку за строкой читает и в реальном времени выдает окончательный результат.
V>>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код путем передачи управления на начало.

x64>Тебе нужно написать транслятор, т.е. некий конвертер, который будет создавать исполняемый .exe-файл на основе твоего макроязыка. Но за день ты это не напишешь, даже и не думай. Мануалы интеловские читать, формат PE-файлов учить и так далее. Здесь тебе не помогут с этим, если только сможешь сформулировать конкретные вопросы и с ними целенаправленно идти уже в профильные форумы.

Чудак ты Мне ниечего не нужно... Транслятор, что ты говоришь, я ужЕ давным-давно написал.
Ему уже лет с 20. Сейчас САМ высказался, что смогу увеличить скорострельность раз в 50.
Эту самолетная индустрия.

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

L>>Не обязательно так глубоко лезть. Достаточно транслировать в какой-либо другой компилируемый язык, например в C. А уже потом компилировать C используя сторонний компилятор.

x64>Как вариант. Тот же C# можно взять

Слушай. А чьл ты имеешь в виду под ПРОФИЛЬНЫМИ форумами?
Я-то по глупости думал, что именно ЭТО и есть профильный форум.
Конференции что-ли? Англоязычные?
Сори — я весьма занят

V>Мне ниечего не нужно...

Когда человеку ничего не нужно, ему остаётся только умереть.

V>>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

T>>А какой язык интерпретируете?

V>Свой. Си-подобный. В принципе, проблема уже снЯта.

Си-подобный по синтаксису или по семантике и уровню? Есть какая-то документация? Изучаю языки, интересно.

V>Сори — я весьма занят

Сорри, я тоже.

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

V>>>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

T>>>А какой язык интерпретируете?

V>>Свой. Си-подобный. В принципе, проблема уже снЯта.

T>Си-подобный по синтаксису или по семантике и уровню? Есть какая-то документация? Изучаю языки, интересно.

Документация, само собой, есть. Но ЗАЧЕМ ОНО вам? Языки сочиняются элементарно.
Тока подумай насчет того, что должен он выполнять. Например, здесь есть встроенные спец-функции,
это MARK(номер панели) = выдающая номер точки маркера, или SPNT(номер точки) = выдает вольтаж в заданной точке,
SELO(номер зоны) — номер точки начала заданной зоны.

В 1984 году к нам в институт прибыла машина PDP 11/23. Англичанин, продавший нам машину, приложил бесплатно 5-дюймовый диск с неким новым компайлером. Это был язык С. ЦЕ — как выражался тогда мой начальник отдела
Так вот, я восстановил этот компайлер и переписал его на Си. Кроме того, сразу же сделан был кросс-ассемблер на 8 языков микропроцессоров. Сори — слишком много воды с тех пор утекло Где они все — текстА???

T>>Си-подобный по синтаксису или по семантике и уровню? Есть какая-то документация? Изучаю языки, интересно.

V>Документация, само собой, есть. Но ЗАЧЕМ ОНО вам? Языки сочиняются элементарно.
V>Тока подумай насчет того, что должен он выполнять. Например, здесь есть встроенные спец-функции,
V>это MARK(номер панели) = выдающая номер точки маркера, или SPNT(номер точки) = выдает вольтаж в заданной точке,
V>SELO(номер зоны) — номер точки начала заданной зоны.

Ясно, по уровню си-подобный. Такие не интересно.

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

V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор.

Есть такой подход "partial evaluation". Но для него нужно использовать язык поддерживающий метапрограммирование.
Например:
http://nemerle.org/Partial_evaluation

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

AD>вы меня извините — может я плохо учился в институте

100%!

AD>интерпретатор и компилятор — это одно и тоже — смысл перевода кода из одного языка в другой.

Полнейшая чушь!
Пруфлинк

Разница между компилятором и интерпретатором в том, что компилятор никогда не выполняет программу, а интерпретатор никогда ее не компилирует .

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

V>>Насчет того, что интерпретатор и компайлер — одно и то же — Вы не правы
AD>ваше право так думать
AD>здесь

И что ты там нашел? Можно цитату?

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

AVK>C# не надо, IL удобнее.

Удобнее?

Быстрее, гибче — возможно. Но не удобнее — это 100%.

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

VD>Удобнее?

VD>Быстрее, гибче — возможно. Но не удобнее — это 100%.

Я писал компилятор — мне показалось удобнее. Хотя бы потому что стековая запись намного более удобна, нежели линейная у исходников на шарпе. В большинстве случаев там прям по мере обхода дерева генерятся инструкции в линейный список.

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

VD>Разница между компилятором и интерпретатором в том, что компилятор никогда не выполняет программу, а интерпретатор никогда ее не компилирует .

Тогда срочно нужно новое слово для Питона, Руби 1.9, Луа и кучи других. Ибо они сперва компилируют (в байткод), а потом выполняют.

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

V>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код
Э-э... С каких это пор компиляторы выполняют скомпилированный код?

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

DM>Тогда срочно нужно новое слово для Питона, Руби 1.9, Луа и кучи других. Ибо они сперва компилируют (в байткод), а потом выполняют.

Не не нужно. Это интерпретатор чистой воды. То что интерпретируется не исходный код, а промежуточное представление ничего не меняет.

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

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

VD>Здравствуйте, D. Mon, Вы писали:

DM>>Тогда срочно нужно новое слово для Питона, Руби 1.9, Луа и кучи других. Ибо они сперва компилируют (в байткод), а потом выполняют.

VD>Не не нужно. Это интерпретатор чистой воды. То что интерпретируется не исходный код, а промежуточное представление ничего не меняет.

VD>На будущее. Интерпретация — это исполнение программы другой программой, а не процессором (железякой).
VD>Вот компиляцией можно назвать и преобразование текста в байткод. Но если говорят о интерпретирующих и компилирующих ЯП или средах, то под компилятором обычно понимают нечто транслирующее код в нэйти-код процессора.

1) Сори, я не успел к сегодня: очень много работы. Основная книга — Руководство по Сопроцессору.
2) Насчет московского Гуггля — я не шутил о зарплатах. Им-то начхать ГДЕ платить. Было бы за что
3) Насчет московского не-Гуггля — кудата пропала инфа!
А я хотел и продолжить мысль. Ну пусть сейчас мы получаем копейки.
Но у нас в руках Советского качества ФОНДЫ. А это не есть уши от мертвого осла,
сами понимаете. Когда в помещении остались ты да я да мы с тобой — веселья маловато.
Но все же в НАШИХ руках Зарплата в 200 тыс. РУР в месяц — не за горами.
А сейчас что? Ну пусть 20 штук в месяц. На жизнь — вроде хватает.

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

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

V>>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код
AD>Э-э... С каких это пор компиляторы выполняют скомпилированный код?

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

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

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

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

V>>>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код
AD>>Э-э... С каких это пор компиляторы выполняют скомпилированный код?

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

Насчет Основной темы ветки: ну конечно же мне стыдно (:
Еще бы не стыдно — стока многа дней и ночей!

Но перемелется — мука будет
Я думаю, что ОТВЫК ОЧЕНЬ, мотаясь по московским обменникам.

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

DM>>Тогда срочно нужно новое слово для Питона, Руби 1.9, Луа и кучи других. Ибо они сперва компилируют (в байткод), а потом выполняют.

VD>Не не нужно. Это интерпретатор чистой воды. То что интерпретируется не исходный код, а промежуточное представление ничего не меняет.

Там внутри довольно четкое разделение на компиляцию в байткод и исполнение его ВМ. Есть даже разделение — байткод можно сохранить в файл, а потом многократно исполнять.

VD>На будущее. Интерпретация — это исполнение программы другой программой, а не процессором (железякой).

Тогда Java — интерпретатор.

VD>Вот компиляцией можно назвать и преобразование текста в байткод.

Питон, Руби и Луа это делают.

VD>Но если говорят о интерпретирующих и компилирующих ЯП или средах, то под компилятором обычно понимают нечто транслирующее код в нэйти-код процессора.

Тогда Nemerle — не компилятор.

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

VD>Разница между компилятором и интерпретатором в том, что компилятор никогда не выполняет программу, а интерпретатор никогда ее не компилирует .

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

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

V>Вообще-то, в подавляющем большинстве случаев интерпретаторы компилируют программу в некое представление для своей виртуальной исполнительной машины.

Это без разницы. Главное, что они не формируют нечто что может исполняться без интерпретации. Интерпетатор байткода все равно интерпретатор.

Ну, и компиляторы в байткод тоже бывают. Только они не интерпретируют ничего и потому не являются интерпретаторами.

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

DM>Там внутри довольно четкое разделение на компиляцию в байткод и исполнение его ВМ. Есть даже разделение — байткод можно сохранить в файл, а потом многократно исполнять.

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

VD>>На будущее. Интерпретация — это исполнение программы другой программой, а не процессором (железякой).

DM>Тогда Java — интерпретатор.

Ява имеет разные реализации. Есть чисто интерпретирующие VM, а есть VM поддерживающие JIT-компиляцию (т.е. компиляцию кода перед первом его исполнением). Более того JIT-ер от Sun-а может какие-то куски кода интерпретировать (если он посчитает, что они не критичны для производительности или они не выполняются более одного раза), а какие-то компилирует.
Дотнет, как не странно, тоже обладает разными VM. Основная, используемая на ПК, обладает JIT-компилятором который прекомпилирует весь код. Более того большая часть системных сборок прекомпилируется еще при инсталляции дотнета.

VD>>Вот компиляцией можно назвать и преобразование текста в байткод.

DM>Питон, Руби и Луа это делают.

Это делают 90% интерпретаторов.

VD>>Но если говорят о интерпретирующих и компилирующих ЯП или средах, то под компилятором обычно понимают нечто транслирующее код в нэйти-код процессора.

DM>Тогда Nemerle — не компилятор.

Правильно, так как Nemerle — это язык. Но вот его компилятор генерирует байткод, которые перед исполнением компилируется в машинный код с помощью JIT-компилятора дотнета (или прекомпилятора — ngen.exe). Так что в итоге Nemerle — это компилируемый язык. Именно по этому код написанный на нем по скорости мало отличается от кода написанного на С.

VD>Правильно, так как Nemerle — это язык. Но вот его компилятор генерирует байткод, которые перед исполнением компилируется в машинный код с помощью JIT-компилятора дотнета (или прекомпилятора — ngen.exe). Так что в итоге Nemerle — это компилируемый язык. Именно по этому код написанный на нем по скорости мало отличается от кода написанного на С.

Вот, за что я люблю лёгкие наркотики: куча свежих идей.

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

T>Вот, за что я люблю лёгкие наркотики: куча свежих идей.

Рад за тебя. Но какой интерес слушать о твоих приходах на этом форуме?

T>>Вот, за что я люблю лёгкие наркотики: куча свежих идей.

VD>Рад за тебя. Но какой интерес слушать о твоих приходах на этом форуме?

Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

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

T>Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

ОК. Один раз простил. В следующий раз пойдешь в баню на недельку.

T>>Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

VD>ОК. Один раз простил. В следующий раз пойдешь в баню на недельку.

Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

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

T>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

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

Пойми, никто не хочет разговаривать с каким-то обдолбанным малолеткой.

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

T>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

Вот так действительно пристойно. Остается только определить значение понятия "существенно" и объяснить на чем основан этот скепсис.

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

T>>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

VD>Вот так действительно пристойно. Остается только определить значение понятия "существенно" и объяснить на чем основан этот скепсис.
VD>Вот десятикратное отставание, которое обычно демонстрируют рантаймы скриптовых языков — это (на мой взгляд) существенное отставание. Отрыв в несколько процентов или даже в два раза в некоторых случаях — не существенное.

Действительно, понятие субъективное. А отрывы будут сильно зависеть от решаемой задачи. У вас внизу значок nemerle developer, может быть вам известны примеры кода, где он отстаёт от Си на несколько процентов — было бы очень интересно взглянуть. Честно, я не проводил бенчмарков, но учитывая причины скепсиса (ниже), мне кажется, что "в два раза" это самая-самая оптимистичная оценка.

Относительно требований продукта к производительности — согласен! и в десятки раз несущественно, поэтому скриптовые языки и пользуются такой бешеной популярностью. Безотносительно требований конкретных продуктов, просто так две цифры в бенчмарке: 200% это очень существенно. Я понимаю, что разница разумно обусловлена и полностью оправдана. Но это не делает её меньше.

Скепсис основан на боксинге и ветвлениях в runtime проверке типов. Ну, это если x + y (где x,y: uint32) компилируется в одну машинную инструкцию (без учёта того, что результат куда-то надо положить). А если нет, то ещё дополнительные расходы, ещё повод для скепсиса.

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

DM>>Тогда Java — интерпретатор.

VD>Ява имеет разные реализации. Есть чисто интерпретирующие VM, а есть VM поддерживающие JIT-компиляцию (т.е. компиляцию кода перед первом его исполнением). Более того JIT-ер от Sun-а может какие-то куски кода интерпретировать (если он посчитает, что они не критичны для производительности или они не выполняются более одного раза), а какие-то компилирует.

"Это не имеет ровным счетом никакого значения. Это детали реализации интерпретатора."
У Луа есть LuaJIT, если что.

В общем, мысль твоя ясна, просто формулировки не самые хорошие.

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


DM>"Это не имеет ровным счетом никакого значения. Это детали реализации интерпретатора."
DM>У Луа есть LuaJIT, если что.

DM>В общем, мысль твоя ясна, просто формулировки не самые хорошие.

Как прикол если код на питоне содержит такую пару строчек:

import psyco

psyco.full()

то он волшебным образом из интерпретатора превращается в компилятор

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


V>>Вообще-то, в подавляющем большинстве случаев интерпретаторы компилируют программу в некое представление для своей виртуальной исполнительной машины.

VD>Это без разницы. Главное, что они не формируют нечто что может исполняться без интерпретации.

Вполне может, например на форт- или джава-процессорах. Да, сами подобные процессоры тоже являются интерпретаторами, впрочем, как и наиболее популярная на сегодня архитектура x86 — классика интепретирования, изначально работающая на микрокоде. Сейчас место микрокода занял автомат, выполняющий аналогичный ф-ии, но суть не поменялась — это интерпретатор чистой воды, который сначала переводит исходный код во внутреннее исполнение, и только потом подает его исполняющей (но уже не виртуальной) машине.


VD>Интерпетатор байткода все равно интерпретатор.

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

Да тут обсуждать-то нечего. Очевидно, что большинство современных интерпретаторов представляют из себя на самом деле пару: компилятор+интерпретатор некоей VM (напр. Лисп и Пролог). Хотя, изначальное твое утверждение предположительно верное, если интерпретаторы рассматривать именно как пару, но резко неверное (и здесь это заметил не только я) ввиду того, интерпретаторы рассматриваются как некий неделимый "черный ящик", где описанная пара — всего лишь подробность реализации.

ИМХО, четкую границу тут не проведешь. С одной стороны, хочется хочется уточнить твое первоначальное утверждение и сказать, что интерпретаторы код выполняют, а компиляторы — нет, но и это тоже неверно для некоторых языков, где код выполняется во время компиляции.

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

V>ИМХО, четкую границу тут не проведешь. С одной стороны, хочется хочется уточнить твое первоначальное утверждение и сказать, что интерпретаторы код выполняют, а компиляторы — нет, но и это тоже неверно для некоторых языков, где код выполняется во время компиляции.

Провести грань тут не могут только псевдо-философы.
На практике грань очевидна. Именно по этому автор темы хочет заменить иетерпретацию на динамическую компиляцию и выполнение скомпилированного кода.

Все не просто, а очень просто.
Если код исполняется процессором, без участия интерпретирующей программы,то это не интерпретация.
Всякие Лисп-машины — это апаратная ревлизаци.
То как там они реализованы дело десятое.

Важно тут только то, что интерпретация программы всегда во много раз медленнее непосредственного исполненя на той же машине.

И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

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

VD>Важно тут только то, что интерпретация программы всегда во много раз медленнее непосредственного исполненя на той же машине.

Форт со своим шитым кодом точно интерпретатор, но интерпретатор настолько простой (часто выливается в пару ассемблерных инструкций)
что на скорости по скорости практически сравним с компиляторами в нативный код.

VD>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

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

T>Относительно требований продукта к производительности — согласен! и в десятки раз несущественно, поэтому скриптовые языки и пользуются такой бешеной популярностью.

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

T> Безотносительно требований конкретных продуктов, просто так две цифры в бенчмарке: 200% это очень существенно.

В два раза — это на 100%, а не на 200. Причем разницу в два раза еще нужно постараться получить. Это или закой-то числодробильный код который резко выигрывает от ручных оптимизаций, или еще что-то, что в гражданском коде встретишь не часто.

T>Я понимаю, что разница разумно обусловлена и полностью оправдана. Но это не делает её меньше.

Двухкратную разницу порой вообще нельзя увидеть не вооруженным взглядом. А там где это критично всегда можно схимичить. Мне вот только еще не разу этим заниматься не пришлось.

Зато код написанный на типобезопасном ФЯ намного проще распараллелить. А это уже может поднять скорость в 4 и более раз (в зависимости от железа и задачи). Так что не все так просто.

T>Скепсис основан на боксинге и ветвлениях в runtime проверке типов. Ну, это если x + y (где x,y: uint32) компилируется в одну машинную инструкцию (без учёта того, что результат куда-то надо положить). А если нет, то ещё дополнительные расходы, ещё повод для скепсиса.

Скепсис основан на твоем не знании и отсутствии опыта.

Откровенно говоря у меня совсем нет желания агитировать за советскую власть. Я говорю о том с чем сам работаю. Я где-то 15 проработал с С/С++ и скоро будет 10 лет как с дотнетом.
Конечно при применеии дотнета есть тонкие вопросы и по неопытности можно получать весьма не эффективный код, но практика показывает, что если писать с умом, то скорость получается более чем приемлемая. Тот же боксинг в моем коде встречается крайне редко и только там где это совершенно не важно с точки зрения производительности (например, при консольном выводе, где скорость вывода на консоль в десятки раз ниже боксинга).

Вот сейчас я занимаюсь переделыванием Word-ового шаблона для верстки статей для RSDN. Раньше он был создан на базе automation-API ворда и нэтив COM-библиотек. Кода на VB6 было не очень много, так как основная работа "поручалась" компонентам написанным на С/С++ — MS XML, Regex-ы и API ворда (все нэйтив и написанное на С/С++). Тормозил старый шаблон просто чудовищно, не смотря на использования в основном нэйти-кода! Даже небольшие статьи обрабатывались десятками секунд. А большие минутами (и это на весьма современном железе).
Новый шаблон работает посредственно с фалом в формате Word XML 2003. Он парсит его с помощью менеджед-библиотеки System.Xml.Linq и обрабатывает (в основном в функциональном стиле). Далее он генерирует ХМЛ в формате RSDN ML и с помощью прекомпилированного в управляемый код XSLT генерирует HTML со статьей (для предварительного просмотра). Так вот даже на документы весьма большого размера обрабатываются в мгновение ОК.

Это рассказ конечно не доказывает, что нэйтив-код медленнее управляемого. Но хорошо демонстрирует, что скорость у управляемых решений очень высокая и в купе с гибкостью которую дает Nemerle и дотнетные библиотеки — это позволяет решать мгогие задачи намного эффективнее чем если бы для этого использовать нэйтив-код. Более того иной раз объем работы настолько велик, что решение задачи на С/С++ становится просто мало реальным, а на дотнете очень даже реальным. Не даром Майрософт переписывает свой компилятор C# на C# с С++ и переписывает все больше частей VS на C#.

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

FR>Форт со своим шитым кодом точно интерпретатор, но интерпретатор настолько простой (часто выливается в пару ассемблерных инструкций)
FR>что на скорости по скорости практически сравним с компиляторами в нативный код.

Позволю себе усомниться. Чудес все же не бывает.

VD>>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

FR>Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

Ну, когда есть модуль который компилирует код перед выполнением, то это несомненно компилятор.

То что для питона такой есть — это полнешая чушь. Я так понимаю ты имеешь в виду PyPy. Назвать его "модулем" можно с огромной натяжкой. Это отдельный компилятор. И он несомненно ускоряет код Питона (пусть даже и не всегда). Вот только беда в том, что Питон клинически плохо компилируется в виду своей динамической семантики. Так что эффект от его прекомпиляции не очень значительный. Причем чем более продвинутые возможности используются в программе, тем меньше толку будет от ее компиляции.

Другое дело Nemerle с его выводом типов. Для него сделать эффективный компилятор намного проще. Накладные расходы на GC конечно тоже будет, но они ни в какое сравнение не идут с тем какие накладные расходы получаются в Питоне.

ЗЫ

Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.

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

VD>Вот сейчас я занимаюсь переделыванием Word-ового шаблона для верстки статей для RSDN. Раньше он был создан на базе automation-API ворда и нэтив COM-библиотек. Кода на VB6 было не очень много, так как основная работа "поручалась" компонентам написанным на С/С++ — MS XML, Regex-ы и API ворда (все нэйтив и написанное на С/С++). Тормозил старый шаблон просто чудовищно, не смотря на использования в основном нэйти-кода! Даже небольшие статьи обрабатывались десятками секунд. А большие минутами (и это на весьма современном железе).
VD>Новый шаблон работает посредственно с фалом в формате Word XML 2003. Он парсит его с помощью менеджед-библиотеки System.Xml.Linq и обрабатывает (в основном в функциональном стиле). Далее он генерирует ХМЛ в формате RSDN ML и с помощью прекомпилированного в управляемый код XSLT генерирует HTML со статьей (для предварительного просмотра). Так вот даже на документы весьма большого размера обрабатываются в мгновение ОК.

VD>Это рассказ конечно не доказывает, что нэйтив-код медленнее управляемого. Но хорошо демонстрирует, что скорость у управляемых решений очень высокая

Круто сраниваешь.
Это все равно, что бросить ферари в болото (в котором она завязнет), а запор поставить на хорошую асфальтированное покрытие. И из сравнения результатов делать вывод, что скоростные характеристики у запора "очень высокие".

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

L>Круто сраниваешь.
L>Это все равно, что бросить ферари в болото (в котором она завязнет), а запор поставить на хорошую асфальтированное покрытие. И из сравнения результатов делать вывод, что скоростные характеристики у запора "очень высокие".

Я сравниваю то что есть в реальной жизни. Дорог нет. Есть только направления. И ферари ваш (которой в прочем на поверку не ферари а банальные хадули) вязнет в трясине, а запоржец (который в прочем скорее джип VIP-уроня) позволяет передвигаться по этой пересеченке с очень высокой скоростью.

В общем, есть задача, есть и лучшее для нее решение. И нэйтив-код тут мне ничем не помогает, а наоборот, ого-го как мешает.

Мы же здесь говорили о скорости. Так вот я просто указал, что скорость получается не просто приемлемая, а невероятно высокая. И это при том, что весь используемый в проекте код — это управляемый код. Причем не малая часть этого кода написана на Nemerle. Я уверен, что будь он целиком написан на Питоне или Руби, и особенно без применения С-шнхы либ, то тормозил бы серьезно. А будь он написан на голом С в супер-оптимальном хакерском стиле, то никто бы и в микроскоп разницы в скорости не заметил.

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

VD>Мы же здесь говорили о скорости. Так вот я просто указал, что скорость получается не просто приемлемая, а невероятно высокая. И это при том, что весь используемый в проекте код — это управляемый код.

Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation. Используй ты его в managed-коде, тормоза никуда не пропали бы.

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

VD>Позволю себе усомниться. Чудес все же не бывает.

Там никаких чудес и нет, по сути "интерпретатор" это косвенный ассемблерный jmp. Базовые слова написаны на встроенном ассемблере
в результате получается очень быстро. Вернее получалось лет пятнадцать назад, современные процессоры (хотя самые современные уже нет)
не очень любят такую схему, ну и плюс оверхед от стека вместо регистров. Но все-равно вполне сопоставимо с си.


FR>>Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

VD>Ну, когда есть модуль который компилирует код перед выполнением, то это несомненно компилятор.

VD>То что для питона такой есть — это полнешая чушь. Я так понимаю ты имеешь в виду PyPy. Назвать его "модулем" можно с огромной натяжкой. Это отдельный компилятор. И он несомненно ускоряет код Питона (пусть даже и не всегда). Вот только беда в том, что Питон клинически плохо компилируется в виду своей динамической семантики. Так что эффект от его прекомпиляции не очень значительный. Причем чем более продвинутые возможности используются в программе, тем меньше толку будет от ее компиляции.

Я имею ввиду ни PyPy (это отдельная реализация питона) а Psyco http://psyco.sourceforge.net/ JIT компилятор выполненный в виде модуля к обычному CPython.
Плохо или хорошо компилируется это неважно, главное принципиальных различий от java или NET никаких.

VD>Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.

Меня тоже, просто демонстрирую что все не так просто и четко разделить эти понятия сейчас мало реально.

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

L>Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation.

А с чего ты взля что "использовался out-of-rocess automation"?

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

L>Используй ты его в managed-коде, тормоза никуда не пропали бы.

В мэнеджед-коде я могу вместо неповоротливого ворда навязывающего свои алгоритмы использовать те алгоритмы и библиотеки которые хочу.

Кстати, запускаются они так же из макросов ворда как in-process-сервер. Вся разница только в том, что вместо нэйтив компонет испоьзуется управляемые библоитеки.

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

L>>Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation.

VD>А с чего ты взля что "использовался out-of-rocess automation"?

В посте, на который я отвечал, не упоминались макросы, но было про VB6 и automation. Я решил, что работа с вордовым документом велась из VB. Я тебя неправильно понял. Возражение снимается с повестки.

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

FR>Там никаких чудес и нет, по сути "интерпретатор" это косвенный ассемблерный jmp. Базовые слова написаны на встроенном ассемблере
FR>в результате получается очень быстро. Вернее получалось лет пятнадцать назад, современные процессоры (хотя самые современные уже нет)

Это сотрясение воздуха. Для волнение нетривиальная работы нужно 90% команд процессора. И их "косвенное" выполнение и есть интерпретация. Кроме косвенности есть еще сужение системы типов, использование проверок и т.п. Все в месте и замедляет код. Если бы это было не так, то на можно было бы увидеть тесты демонстрирующие отсутствие разницы в скорости. А по факту пока что форт нигде где требуется производительность не применяется. Насколько мне известно в основном его применяют там где требуется очень компактная и переносимая ВМ. О Питоне даже говорить не приходится. Тормозом был, тормозом и остнется.

FR>не очень любят такую схему, ну и плюс оверхед от стека вместо регистров. Но все-равно вполне сопоставимо с си.

Пруфлинк, плиз.

FR>Я имею ввиду ни PyPy (это отдельная реализация питона) а Psyco http://psyco.sourceforge.net/ JIT компилятор выполненный в виде модуля к обычному CPython.
FR>Плохо или хорошо компилируется это неважно, главное принципиальных различий от java или NET никаких.

А кто-то говорит о принципиальной разнице? Если есть джит который компилирует 100% кода, то это, несомненно, компилятор. Ну, а то что от него нет никакого толко обесловлено тем, что он вынужден вставлять куски интерпретатора в генерируемый код (в виду динамической природы языка), ну, и другой оверхэд (вроде использования числе неограниченной точности) тоже никто не отменял.

VD>>Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.

FR>Меня тоже, просто демонстрирую что все не так просто и четко разделить эти понятия сейчас мало реально.

Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

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

VD>Это сотрясение воздуха. Для волнение нетривиальная работы нужно 90% команд процессора. И их "косвенное" выполнение и есть интерпретация. Кроме косвенности есть еще сужение системы типов, использование проверок и т.п. Все в месте и замедляет код. Если бы это было не так, то на можно было бы увидеть тесты демонстрирующие отсутствие разницы в скорости. А по факту пока что форт нигде где требуется производительность не применяется. Насколько мне известно в основном его применяют там где требуется очень компактная и переносимая ВМ. О Питоне даже говорить не приходится. Тормозом был, тормозом и остнется.

Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

FR>>не очень любят такую схему, ну и плюс оверхед от стека вместо регистров. Но все-равно вполне сопоставимо с си.

VD>Пруфлинк, плиз.

Я уже тебе объяснял что форт для меня только теплые воспоминания, когда я на нем программировал интернет отсутствовал.

VD>А кто-то говорит о принципиальной разнице? Если есть джит который компилирует 100% кода, то это, несомненно, компилятор. Ну, а то что от него нет никакого толко обесловлено тем, что он вынужден вставлять куски интерпретатора в генерируемый код (в виду динамической природы языка), ну, и другой оверхэд (вроде использования числе неограниченной точности) тоже никто не отменял.

Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

VD>Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

VD>Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

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

L>В посте, на который я отвечал, не упоминались макросы, но было про VB6 и automation.

А какой смысл писать внешний код на отдельном VB6 когда он встроен в сам Ворд? Естественно под VB6 понимались макросы.

L>Я решил, что работа с вордовым документом велась из VB. Я тебя неправильно понял. Возражение снимается с повестки.

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

Конечно дело не в том, что C не умеет код генерировать. Просто для наших нужд АПИ ворда просто плохо подходит. У него нет возможности взять и прочесть внутреннюю структуру документа. Приходится читать или посимвольно, что в ворде работает ну очень медленно, или пользоваться высокоурожайными операциям вроде поиска и замены. Они работают быстрее, но их нужно выполнять намного больше чем если бы можно было прочесть структуру документа. В итоге я выбрал лобовое решение. Отказаться от использования ворда вовсе. В макросах теперь просто производится запись содержимого файла во временный MXL-файл (в формате Word XML), а потом вся работа ведется путем чтения этого файла и ручной его обработки.

Решение работает не просто быстрее, а несоизмеримо быстрее. Визуально на моем ноуте статьи обрабатываются молниеносно. Нажимаешь кнопку трансформации, и сразу же видишь как в роузере открывается HTML-предпросмотр. А вдеь при этом происходит:
1. Создание нового (невидимого) документа ворда.
2. Копирование содержимого старого документа в новый файл.
3. Принятие всех ревижонов.
4. Запись файла в формате ХМЛ (все эти пункцты — это 8 строк макросов, т.е. VB).
5. (отсюда работает управляемый код) Чтение файла через XLinq.
6. Преобразование XLinq в немерловый вариант Tag (его описание можно увидеть здесь). Кстати, он полностью неизменяемый, т.е. функциональный.
7. Несколько трансформаций (если интересно, ищи функцию Transform в файле RsdnMl.n) полученного дерева (из рекурсивного варианта Tag). Трансформации дерева даже не оптимизируются, так что каждый раз гнерируются новые копии дерева.
8. Производится парсинг таблицы метатрибутов (этого вообще не было в первой версии шаблона). Код парсинга можно увидеть в файле MetadataPersing.n. Код так же не оптимизировался и лепился, что называется в лоб. В нем кроме всего применяются функции высшего порядка которые вместе с разметкой лежат в шэш-таблицах. Можно сказать, небольшой интерпретатор DSL-я.
9. С помощью XLinq Формируется и записывается на диск XML-файл в формате RSDN ML. Мелочи вроде формирования заголовков статьи я просто пропускаю...
10. Файл сформированный на шаге 9 загружается в XslCompiledTransform который использует сборку полученную путем прекомпиляции XSL-файла в днтент-сборку с помощью утилиты xsltc.exe. Эта утилита генерирует управляему сборку содержащую тип XSL-транслятор.
11. Полученный текст помещается в шаблон HTML-файла и записывается на диск.
12. Файл отображается в броузере ассоциированном с расширением HTML с помощью Diagnostics.Process.Start(outFilePath).
13. Список ошибок возвращается в макрос. Причем я еще думаю, что видимо выброшу код макроса занимающийся отображением ошибок и замению его на ВинФормсовый, так как работа с формами в ворде примитивнейшая. Уже пришлось использовать ВыньАПИ.

И все это выполняется быстрее чем успеваешь выдохнуть.

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

FR>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

Пруфлинк в студию.

FR>Я уже тебе объяснял что форт для меня только теплые воспоминания, когда я на нем программировал интернет отсутствовал.

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

FR>Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

Это еще почему? Оно очевидно и очевидно, что даже от плохой компиляции есть выигрыш в скорости.

VD>>Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

FR>Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

Запамятовал твои задачи. Не напомнишь?
И еще... ты все же ответь, почему не Питон то?

VD>>Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

FR>Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

Ну, ты всегда выбираешь весьма странные, на мой взгляд, решения. К этому я уже привык. Но все же я не пойму почему все же не Питон? Да и почему не OCaml? F# хотя бы по соображениям платформы можно отбросить. Но OCaml то чем не угодил?

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

FR>>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

VD>Пруфлинк в студию.

Некогда гуглить, тут фортеры точно водятся думаю подкинут.

FR>>Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

VD>Это еще почему? Оно очевидно и очевидно, что даже от плохой компиляции есть выигрыш в скорости.

Потому-что толку от него все-равно никакого.

FR>>Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

VD>Запамятовал твои задачи. Не напомнишь?

Утилиты системные.

VD>И еще... ты все же ответь, почему не Питон то?

Потому что windows написан на Си и для глубокого с ним взаимодействия хорош именно Си/C++.

FR>>Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

VD>Ну, ты всегда выбираешь весьма странные, на мой взгляд, решения. К этому я уже привык. Но все же я не пойму почему все же не Питон? Да и почему не OCaml? F# хотя бы по соображениям платформы можно отбросить. Но OCaml то чем не угодил?

Выше, тяжеловато на OCaml и хук поставить и перехват API функций делать и писать используя только Native API.

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


V>>ИМХО, четкую границу тут не проведешь. С одной стороны, хочется хочется уточнить твое первоначальное утверждение и сказать, что интерпретаторы код выполняют, а компиляторы — нет, но и это тоже неверно для некоторых языков, где код выполняется во время компиляции.

VD>Провести грань тут не могут только псевдо-философы.
VD>На практике грань очевидна.

Угу, для многих языков грань очевидна, ты это имел ввиду под своей "практикой"?

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

Итого: практически все интерпретаторы выполняют фазу компиляции, а так же есть компиляторы, выполняющие интерпретирование пользовательского кода.

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


VD>Важно тут только то, что интерпретация программы всегда во много раз медленнее непосредственного исполненя на той же машине.

Очередное заблуждение, насчет "во много раз", ибо от языка зависит и принципов его работы.


VD>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

Опять мимо.

Давай так, твоя формулировка сообщением выше была некорректна, и разводить тут дальше бессмысленно, а то примерами закидают.
ИМХО, отличие интерпретатора от компилятора на сегодня лишь в том, что интерпретатору можно на вход подать исходный код, и он его тут же выполняет, а компилятор лишь преобразует его для выполнения "на потом". Вот это лишь существенно и позволит не запутаться, а не то, преобразует ли интерпретатор исходник в байт-код или нативный перед непосредственным исполнением. Так же как не важно в какой код преобразует компилятор — в нативный или байт-код.

Почему я не дал такое определение сразу? Из-за лени, ибо даже в этом определении стоит оговориться. Например, есть программа на том же Форте (угу, это он, родной, всю картинку портит и умы смущает), так вот, если последней строкой программы будет какое-нить " Filename.exe" SAVEPROG, то это вроде как компиляция, а если в этой же строке будет имя стартового слова — то уже интерпретация... Небольшое различие, прямо скажем.

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

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

FR>>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

VD>Пруфлинк в студию.

Я тоже подписываюсь, и мне для моих тестов никто был не нужен, да и интернета тогда у нас еще не было.
Принцип быстрой работы Форта в том, что для его слов не требуется пролог-эпилог, какой требуется для ф-ий высокоуровневых языков, и который прилично тормозил программы в свое время. (Это сейчас многое инлайнится). Далее, перед вызовом каждой процедуры ЯВУ нужно запихать все операнды в стек, в отличие от Форта, программы на котором писались таким образом, чтобы состояние стека на выходе одного слова было требуемым состоянием для входа следующего. У меня разница до 2-х раз в пользу Форта доходила.

Да, на современных процах с переименованием регистров и out of order выполнением это отличие практически не влияет на быстродействие, но это из-за заточки процов на те самые классические ЯВУ. Если заточить под Форт, то это будет гладкое data-flow практически не требующее доп. оптимизации на уровне проца, т.е. эти же ресурсы транзисторов кристалла могли бы быть применены куда как более полезно, например под дополнительные АЛУ и дополнительные аппаратные треды.


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

Мы же о языках беседуем. Так вот, Форт — такой же равноправный язык.

[доказательства того, с чем я не спорил (потому что я с вами вообще не спорил) и опровержения того, чего я не утверждал (например, "на 200%") пропущены]

VD>Откровенно говоря у меня совсем нет желания агитировать за советскую власть.

[два абзаца неагитации пропущены]

VD>Это рассказ конечно не доказывает, что нэйтив-код медленнее управляемого. Но хорошо демонстрирует, что скорость у управляемых решений очень высокая [...]

Этот рассказ ничего не доказывает только потому, что нет нужды что-то доказывать. А вы именно этим, почему-то, очень усердно занимаетесь.

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

В начале было слово. И на него есть ссылка.

Именно по этому код написанный на нем [Nemerle] по скорости мало отличается от кода написанного на С.

Потом вы уточнили, что "мало отличается" — это

Отрыв в несколько процентов или даже в два раза

.

Это не вопрос агитации или доказательства кто/что уместнее в каком-то проекте/для каких-то задач. Тут либо есть бенчмарки, где Nemerle/C#/etc на несколько процентов, или, хотя бы в два раза отличается от аналогичного кода на Си, либо этих примеров нет и тогда ваш изначальный тезис (о том, что код на Nemerle по скорости мало отличается) остаётся недоказанным.

Речь идёт исключительно об одной вещи — отличается ли скорость X от Y на D процентов или нет.

P.S.: ещё раз, на всякий случай. Я правда, искренне понимаю, что .NET достаточно быстрый. Но речь не о "заметной на глаз разнице", а о конкретных числах.

Здравствуйте, Temoto, Вы писали:
T>Я уже писал, что понимаю, ради чего типобезопасные рантаймы хавают проц
Хм... а я вот не понимаю. Если под типобезопасностью понимать мощную статическую типизацию, то на то она и статическая, чтобы в рантайме ничего не хавать.

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

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

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

FR>Утилиты системные.

А конкретнее? Не уж то современные ОС нуждаются в утилитах от сторонних производителей?

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


FR>>Утилиты системные.

VD>А конкретнее? Не уж то современные ОС нуждаются в утилитах от сторонних производителей?

OC не нуждаются, пользователям почему-то нужно.
Конкретнее дефрагментаторы, утилиты работы с реестром, твикеры, разные тонкие настройки и т. п.

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

T>В начале было слово. И на него есть ссылка.

Именно по этому код написанный на нем [Nemerle] по скорости мало отличается от кода написанного на С.

T>Потом вы уточнили, что "мало отличается" — это

Отрыв в несколько процентов или даже в два раза

.

Где-то и превосходит. Особенно старые или фиговые компиляторы вроде борлондовских.

T>Это не вопрос агитации или доказательства кто/что уместнее в каком-то проекте/для каких-то задач. Тут либо есть бенчмарки, где Nemerle/C#/etc на несколько процентов, или, хотя бы в два раза отличается от аналогичного кода на Си, либо этих примеров нет и тогда ваш изначальный тезис (о том, что код на Nemerle по скорости мало отличается) остаётся недоказанным.

Бенчмарки есть. Зайти в раздел статьей и найди статьи под названием "Кто сегодня самый шустрый". Только бэнчмарки есть бэнчмарки. Они вообще мало что показывают, так как на любой выигрышный бэнчмарк всегда можно сделать бэнчмарк с обратным результатом (потому как есть масса нюансов по разному реализованных).

T>Речь идёт исключительно об одной вещи — отличается ли скорость X от Y на D процентов или нет.

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

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

T>P.S.: ещё раз, на всякий случай. Я правда, искренне понимаю, что .NET достаточно быстрый. Но речь не о "заметной на глаз разнице", а о конкретных числах.

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

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

FR>OC не нуждаются, пользователям почему-то нужно.
FR>Конкретнее дефрагментаторы, утилиты работы с реестром, твикеры, разные тонкие настройки и т. п.

А, ясно. Я это называю посой (не обижайся, плиз).
В прципе конечно тоже рынок. Только такой сойт без проблем может писать и на том же дотнете, если ОС — это Виндовс. Ну, код который должен в режиме ядра работать, конечно нужно на С писать. А все остальное — это бессмысленная трата времени.

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



VD>А, ясно. Я это называю посой (не обижайся, плиз).

Тут нечего обижаться, так и есть, по сути большая часть фигня, но есть и полезные вещи.

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

Извини Влад, но ты в этом не разбираешься

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

FR>Извини Влад, но ты в этом не разбираешься

А в чем там разбираться то? Что есть какие-то проблемы с чтением реестра из управляемого кода?

Здравствуйте, Temoto, Вы писали:
T>То есть, чтобы, например, прочитать число из файла, нужно провести проверки в рантайме.
Это-то ясно. Но при типонебезопасном рантайме все равно нужно эти проверки делать.

T>>То есть, чтобы, например, прочитать число из файла, нужно провести проверки в рантайме.
MC>Это-то ясно. Но при типонебезопасном рантайме все равно нужно эти проверки делать.

В целом, верно. Но не все. Например, вы прочитали число N из файла и инициализируете массив числами от 1 до N:

is = array(N)
for (i = 0; i < N; i++)
  is[i] = i

Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер.

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

Да я как-то не учел, что в типонебезопасном варианте программист может держать в голове (а не в коде) какие-то инварианты, которые безопасный рантайм будет проверять (а оптимизатор может и не выкинуть).

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

T>В целом, верно. Но не все. Например, вы прочитали число N из файла и инициализируете массив числами от 1 до N:

T>

T>is = array(N)
T>for (i = 0; i < N; i++)
T>  is[i] = i
T>

T>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит.

Ага есть. Называется jit. Если он видит паттерн

for (i = 0; i < ary.Length; i++)

то он выкидывает проверку. Естественно анализ идет на уровне IL-а...

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

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

T>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер.
Делают. Причем это не просто оптимизация, а система типов построена так что можно доказать что не будет выхода за придела массива.
http://scholar.google.com/scholar?cluster=6505909062216609091&amp;hl=en&amp;as_sdt=2000

T>>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер.
WH>Делают. Причем это не просто оптимизация, а система типов построена так что можно доказать что не будет выхода за придела массива.
WH>http://scholar.google.com/scholar?cluster=6505909062216609091&amp;hl=en&amp;as_sdt=2000

Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.

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

VD>Ага есть. Называется jit. Если он видит паттерн

ngen уж тогда он называется. Вряд ли все JiT компиляторы делают такую оптимизацию, только потому что их запускают непосредственно перед выполнением программ, правда?

VD>

for (i = 0; i < ary.Length; i++)

VD>то он выкидывает проверку. Естественно анализ идет на уровне IL-а...

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

Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx

Автор: Mr.Cat
Дата: 26.01.10

И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.

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

T>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
Это вопрос времени.

T>С другой стороны, вон, товарищ Vlad2 сообщает, что .NET компилятор уже сегодня оптимизирует конкретно этот случай без зависимых типов.
Без них можно оптимизировать только очень не большое колличество частных случаев.
Это уже хрен оптимизируешь ибо у нас нет информации о том что векторы одного размера.

assert length <| {n:nat} 'a array(n) -> int(n)
and sub <| {n:nat} {i:nat | i < n} 'a array(n) * int(i) -> 'a

fun dotprod(v1, v2) =
    let
        fun loop(i, n, sum) =
            if i=n then sum
            else loop(i+1, n, sum + sub(v1, i) * sub(v2, i))
        where loop <| {n:nat} {i:nat | i <= n} int(i) * int(n) * int -> int
    in
        loop(0, length v1, 0)
    end
where dotprod <| {p:nat} {q:nat | p <= q } int array(p) * int array(q) -> int

В любом случае подобные оптимизации оказывают влияние на весьма не большое колличество кода.

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

VD>>Ага есть. Называется jit. Если он видит паттерн

T>ngen уж тогда он называется. Вряд ли все JiT компиляторы делают такую оптимизацию, только потому что их запускают непосредственно перед выполнением программ, правда?

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

VD>>

for (i = 0; i < ary.Length; i++)

VD>>то он выкидывает проверку. Естественно анализ идет на уровне IL-а...

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

T>Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx

Автор: Mr.Cat
Дата: 26.01.10

И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.

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

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

T>С другой стороны, вон, товарищ Vlad2 сообщает, что .NET компилятор уже сегодня оптимизирует конкретно этот случай без зависимых типов.

VladD2, если приглядеться.

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

T>>Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx

Автор: Mr.Cat
Дата: 26.01.10

И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.

VD>Несомненно есть случае когда типобезопасность выливается в дополнительные проверки рантайме. Только вот в хорошем С-коде эти проверки тоже будут.

Рад, что мы пришли к общему знаменателю.

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

Да я тоже за то, чтоб не считать спички. Но когда есть возможность компилятором (то есть бесплатно, без участия человека и в каждой программе на десятки лет вперед) сэкономить пол-процента, глупо не воспользоваться.

А сколько эти пол-процента в количественном выражении будут — действительно, иногда ничтожно мало (я охотно верю, что тесты есть и что они верны, это даже без тестов можно простой логикой показать). С другой стороны, есть специфические области, типа шедулеров процессов в ядре или движков 3D графики, где цикл будет выполняться мильёны раз, тогда и один if и один cache miss окажутся существенны.

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

V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

Сделать компилятор C-- и воспользоваться любым существующим транслятором C--. Как это делают многие современные компиляторы.
http://en.wikipedia.org/wiki/C--

Удачи!

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

T>Да я тоже за то, чтоб не считать спички. Но когда есть возможность компилятором (то есть бесплатно, без участия человека и в каждой программе на десятки лет вперед) сэкономить пол-процента, глупо не воспользоваться.

К сожалению, в случае с С/С++ экономия никогда не бывает бесплатной. Она практически всегда получается в следствии выбора между надежностью и производительностью.

Есть и еще один аспект. "Быстрый код" на С не только "хакерский", но еще и очень низкоуровневый. Приходится работать с очень низкоуровневыми абстракциями. Это часто приводит к тому, что хотя на низком уровне выжимаются микросекунды и биты, но на макро-уровне делаются серьезные алгоритмические просчеты, которые легко приводят к тому, что казалось бы высокооптимизированная программа безбожно тормозит.

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

V>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".

T>Сделать компилятор C-- и воспользоваться любым существующим транслятором C--. Как это делают многие современные компиляторы.
T>http://en.wikipedia.org/wiki/C--

T>Удачи!

К сожалению, авторы забросили проект из-за закрытия финансирования. Собирались выложить его в публичный репозиторий на гитхабе, чтобы кто-то развивал, но пока нет.

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

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

T>>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
WH>Это вопрос времени.

А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.

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

LP>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.

Деление на функциональные и не функциональные есть только в головах у людей. Системам типов по фигу какой там язык.

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

VD>>В прципе конечно тоже рынок. Только такой сойт без проблем может писать и на том же дотнете, если ОС — это Виндовс. Ну, код который должен в режиме ядра работать, конечно нужно на С писать. А все остальное — это бессмысленная трата времени.
FR>Извини Влад, но ты в этом не разбираешься

Так расскажи, в чем специфика. Мне вот тоже интересно стало
Подозреваю, что может быть много интеропа, в таком случае писать код исключительно на том же C# достаточно геморойно. Но на C++\CLI или даже на C++\CLI + C# вполне. Уж по крайней мере ГУЙ писать, который у таких утилиток как правило весьма "нарядный".

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

LP>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
Могут.
Более того если ты посмотришь саму статью то найдешь там деструктивные присваивания контролируемые этой системой типов...

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

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

LP>>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
WH>Могут.
WH>Более того если ты посмотришь саму статью то найдешь там деструктивные присваивания контролируемые этой системой типов...

О, это хорошо. И когда ждать счастья? В смысле когда появится что-то вроде явы, простое и надежное для промышленного применения?

LP>>>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
WH>>Могут.
WH>>Более того если ты посмотришь саму статью то найдешь там деструктивные присваивания контролируемые этой системой типов...

LP>О, это хорошо. И когда ждать счастья? В смысле когда появится что-то вроде явы, простое и надежное для промышленного применения?

То есть вам принципиально важно писать на нефункциональном языке?

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

LP>>>>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
WH>>>Могут.
WH>>>Более того если ты посмотришь саму статью то найдешь там деструктивные присваивания контролируемые этой системой типов...

LP>>О, это хорошо. И когда ждать счастья? В смысле когда появится что-то вроде явы, простое и надежное для промышленного применения?

T>То есть вам принципиально важно писать на нефункциональном языке?

Мне принципиально важно, чтобы в языке был ООП, который необходим для проектирования крупных систем. Если в языке будет удобный синтаксис для замыканий, а библиотека будет содержать необходимый минимум иммутабельных структур данных, тем лучше. Это все, что мне требуется от ФП.

LP>>>О, это хорошо. И когда ждать счастья? В смысле когда появится что-то вроде явы, простое и надежное для промышленного применения?

T>>То есть вам принципиально важно писать на нефункциональном языке?

LP>Мне принципиально важно, чтобы в языке был ООП, который необходим для проектирования крупных систем. Если в языке будет удобный синтаксис для замыканий, а библиотека будет содержать необходимый минимум иммутабельных структур данных, тем лучше. Это все, что мне требуется от ФП.

ООП, который необходим для проектирования крупных систем

Откуда это убеждение?

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

LP>>>>О, это хорошо. И когда ждать счастья? В смысле когда появится что-то вроде явы, простое и надежное для промышленного применения?

T>>>То есть вам принципиально важно писать на нефункциональном языке?

LP>>Мне принципиально важно, чтобы в языке был ООП, который необходим для проектирования крупных систем. Если в языке будет удобный синтаксис для замыканий, а библиотека будет содержать необходимый минимум иммутабельных структур данных, тем лучше. Это все, что мне требуется от ФП.

T>

ООП, который необходим для проектирования крупных систем

T>Откуда это убеждение?

А ты с ним не согласен?
Программирование в своем развитии прошло долгий путь, оставив позади те парадигмы, которые некоторые предлагают сегодня в качестве альтернативы ООП. Фанаты функциональных языков почему-то не принимают во внимание, что в аспектах, касающихся проектирования ПО, ФП ничем не отличается от процедурной парадигмы (эти две парадигмы отличаются в способах описания вычислительного процесса, но это к проектированию не имеет никакого отношения).
Отсутствие возможности иметь изменяемое состояние ведет к потере модульности (а какое без нее нафик проектирование?). Смотри пример в разделе 4.7.2 CTM. Я приведу только заключение (выделенное жирным — мои комментарии):

Which approach is simpler: the first (функциональный) or the second (ООП)? The first has a simpler model but a more complex program. The second has a more complex model but a simpler program. In our view, the declarative approach is not natural. Because it is modular, the stateful approach is clearly the simplest overall.

Без изменяемого состояния модульность в самом деле труднодостижима. ООП же позволяет максимально эффективно использовать это самое состояние, вводя концепцию объектов, в которые состояние заворачивается.

LP>в аспектах, касающихся проектирования ПО, ФП ничем не отличается от процедурной парадигмы

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

LP>>>Мне принципиально важно, чтобы в языке был ООП, который необходим для проектирования крупных систем. Если в языке будет удобный синтаксис для замыканий, а библиотека будет содержать необходимый минимум иммутабельных структур данных, тем лучше. Это все, что мне требуется от ФП.

T>>

ООП, который необходим для проектирования крупных систем

T>>Откуда это убеждение?

LP>А ты с ним не согласен?

Да. И я очень точно могу обосновать. Смысл ООПа не в объектах и состоянии (это легко делается на любых языках). Смысл в том, что оно предлагает некоторые абстракции, методики построения программ. Эти, заезженные до дыр, инкапсуляцию и полиморфизм и лалала. Так вот, функциональные языки не забирают эти абстракции. И инкапсуляция везде есть, и все остальные. ООПа нет, а все фичи ООПа есть, понимаете?

LP>Программирование в своем развитии прошло долгий путь, оставив позади те парадигмы, которые некоторые предлагают сегодня в качестве альтернативы ООП.

Давайте не будем словоблудить про долгий путь. Это исключительно субъективная позиция. Любой человек из микрософта скажет, что ОС прошли долгий путь и винда победно оставила на обочине всех. И как он может быть неправ, если у него кругом одна винда? Конечно он прав. А другой человек через дорогу винду видит два раза в неделю, у него "своя правда". Оба правы. Лично мне более интересен разговор об объективных, которые для всех одинаковы.

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

Это игра слов. Как я уже писал выше, ООП даёт инструменты проектирования. И в ФЯП (очень важно, речь уже идёт о языках) они тоже есть, только не связаны друг с другом, это единственная причина, по которой нельзя сказать, что в ФЯП есть (включён) ООП. Что понимать под словом "функциональное программирование" — каждый для себя решает сам. И можно без потери смысла сказать, что ФП=процедуры, только правила вычисления другие. Почему так можно сказать? Потому что вы строго не описали что именно подразумевается по ФП. Но объективно в реально существующих языках, которые все называют ФЯП, есть те же самые инструменты проектирования, что и в реально существующих ООП языках. А вот это уже факт, который можно проверить, тут неоднозначности быть не может.

LP>Отсутствие возможности иметь изменяемое состояние ведет к потере модульности (а какое без нее нафик проектирование?). Смотри пример в разделе 4.7.2 CTM. Я приведу только заключение (выделенное жирным — мои комментарии):

LP>

LP>Which approach is simpler: the first (функциональный) or the second (ООП)? The first has a simpler model but a more complex program. The second has a more complex model but a simpler program. In our view, the declarative approach is not natural. Because it is modular, the stateful approach is clearly the simplest overall.

LP>Без изменяемого состояния модульность в самом деле труднодостижима. ООП же позволяет максимально эффективно использовать это самое состояние, вводя концепцию объектов, в которые состояние заворачивается.

При *проектировании* я не оперирую понятием "состояние", до тех пор, пока в бизнес-логике не нужно будет это самое состояние надёжно сохранить (на диск, например). У любой программы есть что-то на входе и что-то на выходе. Если повезёт, то две программы можно совместить друг с другом. Я понимаю, что это совсем не тот масштаб, о котором вы говорите, но bash строка `grep foo | sort | diff last-week` является примером программы, спроектированной без упоминания состояния.

Кроме того, это просто-таки толстый тролль, что ФП не позволяет иметь изменяемое состояние (ну или не тролль, а вы просто не писали программ на ФЯ). В Scheme есть set!, в хаскеле State. И когда так нужно или удобнее, люди их применяют. Вы путаете ФП (как реально существующие, работающие программы) и вычисление арифметических выражений. В последнем, да, всё просто и убого, ничего нет; а ФП гораздо шире.

Вообще, я бы зарезюмировал, что ФП следует представлять, прежде всего, как попытку управлять состоянием. В императивной программе состояние неуправляемое, вам неизвестно что чему может быть равно. Точно так же в программе на ассемблере у вас может быть какой угодно мусор в такой-то области памяти. Типы вводят контроль над этим мусором. Аналогично функциональное программирование вводит контроль над состоянием. Из этого вытекает логичный вывод, что ФП таки позволяет, не мешает, делать всё то же самое, что и раньше. Говнокодить мешает (так же, как и типы). А задачи решать — нет.

P.S.: и вот я долго отвечал на это, перечитывал ваши слова, и меня не покидает ощущение, что вы не писали на ФЯП.

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

T>

ООП, который необходим для проектирования крупных систем

T>Откуда это убеждение?

Из практики. ФП — это модернизированное на уровне кода функций процедурное программирование. ООП же был разработан для декомпозиции на уровне всего проекта. На сегодня все большие проекты пользуются идеологией ООП (даже если проекты ведутся на С).

T>>

ООП, который необходим для проектирования крупных систем

T>>Откуда это убеждение?

VD>Из практики. ФП — это модернизированное на уровне кода функций процедурное программирование. ООП же был разработан для декомпозиции на уровне всего проекта. На сегодня все большие проекты пользуются идеологией ООП (даже если проекты ведутся на С).

Это всё та же игра слов. ООП состоит из отдельных концепций, все из которых есть в популярных ФП языках (ну, пожалуй, кроме наследования *реализации*). И если рассматривать ООП как сумму его частей, то в конкретных существующих функциональных языках тоже есть ООП. А если рассматривать ООП как одну монолитную концепцию, то она не может быть необходима. Так же, как нет необходимости конкретно в поездах; есть необходимость в средствах передвижения, поезда это предоставляют, но не только они, есть ещё самолёты. Боже, такая убогая аналогия, простите, конечно... надеюсь, меня поймут.

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

T>Это всё та же игра слов. ООП состоит из отдельных концепций, все из которых есть в популярных ФП языках (ну, пожалуй, кроме наследования *реализации*).

Эко тебя религиозной пропагандоый накрыло.

T> И если рассматривать ООП как сумму его частей, то в конкретных существующих функциональных языках тоже есть ООП.

Если заняться бесмысленным софизмом, то можно договориться до того, что и ООП, и ФП есть в С, так как в С можно все это с горем попалам эмулировать. Но вот для того чтобы парадигму было можно эффективно использовать нужно иметь поддержку в языке и методики (читай учебники) их применения. Думаю, что даже самому последнему софисту не прийдет в голову говорить о том, что в "чистых" ФЯ есть необходимые ингредиенты.

T>А если рассматривать ООП как одну монолитную концепцию, то она не может быть необходима.

Конечно, кнечно. Все ко пишет современный софт они дебили. А вот проповедники ФП они то знают как писать объемный софт, но им просто не дают применить сви знания на практике. Так?
Если не так, то почему же, хотя ФП существует уже 50 лет, на нем так и на стали делать объемные проекты, а вот на ООП деают почти все.

T> Так же, как нет необходимости конкретно в поездах; есть необходимость в средствах передвижения, поезда это предоставляют, но не только они, есть ещё самолёты. Боже, такая убогая аналогия, простите, конечно... надеюсь, меня поймут.

Ну, в общем, считашь, что кроме ФП тебе ничего не нужно? Замечательно! Все рады за тебя. Но почему ты считаель, что твои мысли должны разделять все окружающие. Я вот согласен с товарищем. Мне нужен язык поддерживающий все парадигмы, а ту что наилучшим образом подходит для решения задачи я выберу сам. Более того я хотел бы чтобы между подходами можно было переходить удобным рефракторном. Типа, начал писать проект в функциональном стиле на замыканиях. Понял, что проект разросся. Отрефактори проект введя классы и преобразовав в них некоторые из замыканий. Продолжил развитие проекта.

T>> Так же, как нет необходимости конкретно в поездах; есть необходимость в средствах передвижения, поезда это предоставляют, но не только они, есть ещё самолёты. Боже, такая убогая аналогия, простите, конечно... надеюсь, меня поймут.

VD>Ну, в общем, считашь, что кроме ФП тебе ничего не нужно? Замечательно! Все рады за тебя. Но почему ты считаель, что твои мысли должны разделять все окружающие. Я вот согласен с товарищем. Мне нужен язык поддерживающий все парадигмы, а ту что наилучшим образом подходит для решения задачи я выберу сам. Более того я хотел бы чтобы между подходами можно было переходить удобным рефракторном. Типа, начал писать проект в функциональном стиле на замыканиях. Понял, что проект разросся. Отрефактори проект введя классы и преобразовав в них некоторые из замыканий. Продолжил развитие проекта.

Понимаю, что это выглядит иначе, но я ничего не проповедую. Это можно проверить: я не предлагал использовать какие-то конкретные языки. И я не говорил, что мне нужно или не нужно. Не надо тролить.

Мне нужен язык поддерживающий все парадигмы, а ту что наилучшим образом подходит для решения задачи я выберу сам

Точно! И если немножко раскрыть "все парадигмы" (мне нужен язык, позволяющий разбивать большую программу на модули, создавать абстракции и т.п.) то получится ровно то, что говорил я. Людям нужен не ООП ради ООПа, а те плюшки, которые он предоставляет. То же самое и с ФП. Глупо хотеть, чтобы язык был "функциональным" (что бы это размытое слово ни значило). Но вот в конкретных существующих языках (которые попутно называются функциональными) как раз все плюшки есть.

Типа, начал писать проект в функциональном стиле на замыканиях. Понял, что проект разросся. Отрефактори проект введя классы и преобразовав в них некоторые из замыканий. Продолжил развитие проекта.

Такие языки есть сегодня и вы их знаете. Можно сказать, что они функциональные. Можно сказать, что они поддерживают отдельные части ООП.

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

T>Понимаю, что это выглядит иначе, но я ничего не проповедую. Это можно проверить: я не предлагал использовать какие-то конкретные языки. И я не говорил, что мне нужно или не нужно. Не надо тролить.

Ты, вот именно, что троллишь заставляя окружающих объяснять окружающих очевидные для них вещи.

T>

Мне нужен язык поддерживающий все парадигмы, а ту что наилучшим образом подходит для решения задачи я выберу сам

T>Точно! И если немножко раскрыть "все парадигмы" (мне нужен язык, позволяющий разбивать большую программу на модули, создавать абстракции и т.п.) то получится ровно то, что говорил я.

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

T>Людям нужен не ООП ради ООПа, а те плюшки, которые он предоставляет.

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

T>То же самое и с ФП. Глупо хотеть, чтобы язык был "функциональным"

На мой взгляд, глупо такое заявлять, а хотеть очень даже естественно.

T> (что бы это размытое слово ни значило).

Есть какие-то проблемы в понимании этого термина? Язык поддерживающий ФП (имеющий средства облегчающие использование этой парадигмы) является функциональным. Язык поддерживающий только ФП называется чисто функциональным. Язык поддерживающий и другие парадигмы называется мультипарадигмным или гибридным. По-моему, все очевидно.

T>Но вот в конкретных существующих языках (которые попутно называются функциональными) как раз все плюшки есть.

Ну, почему же тоже самое не применимо к ООЯ?

T>

Типа, начал писать проект в функциональном стиле на замыканиях. Понял, что проект разросся. Отрефактори проект введя классы и преобразовав в них некоторые из замыканий. Продолжил развитие проекта.

T>Такие языки есть сегодня и вы их знаете.

А кто-то с этим спорит?
Человек зала вопрос по поводу языков с зависимой системой типов (или как ее грамотно назвать?). Вот язык в ЗТ поддерживающих ООП я пока что не знаю.

T>Можно сказать, что они функциональные. Можно сказать, что они поддерживают отдельные части ООП.

Не. Никаких отдельных частей не бывает. Быает наличие поддержки и ее отсутствие. Ну, еще может быть не приемлемая (недостаточная) поддержка, но ее смело можно назвать отсутствием поддержки.

T>>Но вот в конкретных существующих языках (которые попутно называются функциональными) как раз все плюшки есть.

VD>Ну, почему же тоже самое не применимо к ООЯ?

К некоторым применимо. Тут уже надо конкретные языки рассматривать. Вот, например, в C#, Ocaml, Scala много плюшек из разных "парадигм". (Дурацкое слово, мы только из-за него говорим об одном но не понимаем друг друга.)
Обратный пример: C++, Java. Нет лямбд, вывода типов, развитие этих языков *остановилось на плюшках из ООП*.

T>>Можно сказать, что они функциональные. Можно сказать, что они поддерживают отдельные части ООП.

VD>Не. Никаких отдельных частей не бывает. Быает наличие поддержки и ее отсутствие. Ну, еще может быть не приемлемая (недостаточная) поддержка, но ее смело можно назвать отсутствием поддержки.

Ладно, частей не бывает. Но задачи, которые решает ООП вы выделить можете? Типа "прячет реализацию за интерфейсом", "предоставляет однотипный интерфейс для разных реализаций". Вот эти задачи я и называю частями.

Как вы считаете, пример с поездами достаточно подобен тому, что мы обсуждаем? Вы (и тот товарищ) говорите, что вам ехать далеко (большой проект), следовательно нужен конкретно поезд (ООП). Я говорю, что поезд это не единственный способ, нужно средство передвижения.

Я очень хорошо понимаю что такое привычка, можно хотеть ООП по привычке, потому что он знаком. Но на уровне обсуждения (просто поболтать) это ведь не должно мешать принимать существование других способов решения тех же проблем. А здесь почему-то разговор резкий и отторгающий. Как будто подтекст такой "нет, отстань, нам хорошо с ООПом". Так ведь я и не посягаю, просто говорю что те же самые задачи решаются ещё и другими способами.

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

T>К некоторым применимо. Тут уже надо конкретные языки рассматривать. Вот, например, в C#, Ocaml, Scala много плюшек из разных "парадигм". (Дурацкое слово, мы только из-за него говорим об одном но не понимаем друг друга.)
T>Обратный пример: C++, Java. Нет лямбд, вывода типов, развитие этих языков *остановилось на плюшках из ООП*.

Замечательно. Меня такое объяснение полностью утраивает.
Неясно почему такая дискриминация применяется только к ООЯ. С ФЯ та же ситуация. Хаскель и Агда остановились на функциональном/процедурном программировании. Средств поддержки ООП в языках нет.

T>Ладно, частей не бывает. Но задачи, которые решает ООП вы выделить можете? Типа "прячет реализацию за интерфейсом", "предоставляет однотипный интерфейс для разных реализаций". Вот эти задачи я и называю частями.

Мне пересказать все что я знаю об ООП? Или нужно изложить теорию ООП?

Еще раз. Есть парадигмы и средства их поддержки в языках. Скажем ООП поддерживается и в C#, и в OCaml, и в C++, и в Python, и в Smalltalk, и даже в Lisp (хотя там она мягко говоря нестандартна). Но, конечно, поддерживается по разному. А вот в С, Хаскеле и Агде он не поддерживается.

T>Как вы считаете, пример с поездами достаточно подобен тому, что мы обсуждаем? Вы (и тот товарищ) говорите, что вам ехать далеко (большой проект), следовательно нужен конкретно поезд (ООП). Я говорю, что поезд это не единственный способ, нужно средство передвижения.

Не, поездов нам не надо. Мы говорим о ЯП. Аналогии тут не уместны.

T>Я очень хорошо понимаю что такое привычка, можно хотеть ООП по привычке, потому что он знаком.

Вот только не надо. Я за всех не отвечаю, но за себя точно скажу, что в программировании ничего по привычке не использую.

T>Но на уровне обсуждения (просто поболтать) это ведь не должно мешать принимать существование других способов решения тех же проблем. А здесь почему-то разговор резкий и отторгающий. Как будто подтекст такой "нет, отстань, нам хорошо с ООПом". Так ведь я и не посягаю, просто говорю что те же самые задачи решаются ещё и другими способами.

Есть повернутые на чем-то. Есть повернутые на ФП. Есть повернутые на ООП. Есть даже повернутые на динамике или статике. Ну, а есть люди которые прекрасно понимают, что те или иные парадигмы или технологии и умеют использовать их там где это удобно. И не надо убеждать последних в том, что одна из технологий самодостаточна, а они просто не умеют ее готовить.

Лично для меня ООП и МП (метапрограммирование) — это парадигмы позволяющие вырваться из мира декомпозиции на уровне функций/процедур. Понято что любую задачу при желании и наличии необъятного времени можно решить путем декомпозиции на функции. Но это крайне не удобно. О многих задачах лучше мыслить в терминах объектов и их классов, а о некоторых в терминах языков предметной области. И если ваш язык не умеет это делать, но вы его считаете крутым, то это ваши проблемы. Мне нужен более гибкий инструмент. Просто наличие ЗТ мне не нужно. Мне нужно чтобы это была одна из дополнительных возможностей. И чтобы она не вставляла мне палки в колеса.

T>>Ладно, частей не бывает. Но задачи, которые решает ООП вы выделить можете? Типа "прячет реализацию за интерфейсом", "предоставляет однотипный интерфейс для разных реализаций". Вот эти задачи я и называю частями.
VD>Мне пересказать все что я знаю об ООП? Или нужно изложить теорию ООП?

Я задал конкретный вопрос про задачи. Можно в двух словах ответить какую задачу решает разбиение одной километровой программы на процедуры, правда? С ООПом это будет больше слов, но список решаемых задач не включает в себя толстую теорию. И не нужно ничего пересказывать. Я просто делаю ссылку, что вот, мол, вот их я называю частями ООП.

T>>Но на уровне обсуждения (просто поболтать) это ведь не должно мешать принимать существование других способов решения тех же проблем. А здесь почему-то разговор резкий и отторгающий. Как будто подтекст такой "нет, отстань, нам хорошо с ООПом". Так ведь я и не посягаю, просто говорю что те же самые задачи решаются ещё и другими способами.
VD>Есть повернутые на чем-то. Есть повернутые на ФП. Есть повернутые на ООП. Есть даже повернутые на динамике или статике. Ну, а есть люди которые прекрасно понимают, что те или иные парадигмы или технологии и умеют использовать их там где это удобно. И не надо убеждать последних в том, что одна из технологий самодостаточна, а они просто не умеют ее готовить.

Я не говорю, что какая-то технология самодостаточна. Я говорил о том, что несмотря на отсутствие классов и объектов в функциональных языках решаются те же самые задачи (полиморфизм и бла бла), что и в ООЯ. Вот товарищ сказал, что ООП необходим для больших проектов, а я говорю что не именно ООП необходим, а средства решения определённых задач; и эти средства есть во всех ООЯ, потому что эти задачи решает ООП, и эти средства есть в *некоторых* функциональных языках. То есть для привычки ООП хотеть — понятно, а для решения проблем — нет.

VD>Лично для меня ООП и МП (метапрограммирование) — это парадигмы позволяющие вырваться из мира декомпозиции на уровне функций/процедур.

Вот, супер. Уже речь идёт о задачах.

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

Конечно неудобно, согласен. Но никто не говорит, что в функциональных языках вместо объектов надо писать километровые функции, это было бы глупо. Создатели функциональных языков не дураки, никто не заставляет людей возвращаться в паскаль. Функциональные языки предоставляют другие средства. Например, в хаскеле и агде есть то, что в ООП называется интерфейсами и хитрый способ привязки реализаций интерфейсов к типам данных.

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

Полностью здесь согласен. Только любая фича будет вставлять палки в колёса. В этом смысл всех фич в языках. Вот раньше не было типов, ассемблерщики прямо с памятью работали как хотели. А в си уже нельзя так вольно. А в Java вообще систему типов не обойдёшь. Написал какой-то дурачок в своей библиотеке, что здесь нужен не IEnumerable, а именно объект класса List и всё, свой Tuple никуда не сунешь. С одной стороны, защита от повреждений данных в памяти, а с другой стороны палка в колёса. И со всеми фичами точно такая ситуация. И с процедурами, и с модулями, и с зависимыми типами так же будет.

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

T>>>Ладно, частей не бывает. Но задачи, которые решает ООП вы выделить можете? Типа "прячет реализацию за интерфейсом", "предоставляет однотипный интерфейс для разных реализаций". Вот эти задачи я и называю частями.
VD>>Мне пересказать все что я знаю об ООП? Или нужно изложить теорию ООП?
T>Я задал конкретный вопрос про задачи. Можно в двух словах ответить какую задачу решает разбиение одной километровой программы на процедуры, правда? С ООПом это будет больше слов, но список решаемых задач не включает в себя толстую теорию. И не нужно ничего пересказывать. Я просто делаю ссылку, что вот, мол, вот их я называю частями ООП.

А зачем "эмулировать" ООП на языках, где нет полноценной поддержки ООП?

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

Я вот могу занять, к примеру, такую позицию. Могу утверждать, что все нужные "плюшки" ООП я могу с успехом реализовать на plain C, используя указатели на ф-ции и проч. Чем подобное утверждение отличается от того, что говоришь ты? И ведь на С, заметь, писалось огромное количество "больших систем".

По-моему как раз необходимость такой "эмуляции", реализации ОО-паттернов не самыми привычными средствами для этих паттернов, и происходит из-за того, что ООП, наверное, таки нужен для проектирования систем. И возникает вопрос. А не проще ли сразу взять полноценный ООП, а не заниматься черт знает чем?

ВВ>Я вот могу занять, к примеру, такую позицию. Могу утверждать, что все нужные "плюшки" ООП я могу с успехом реализовать на plain C, используя указатели на ф-ции и проч. Чем подобное утверждение отличается от того, что говоришь ты? И ведь на С, заметь, писалось огромное количество "больших систем".

Да, верно, и здесь как раз будет разница. Все языки тьюринг полны, на всех можно сделать всё. Когда мы говорим, что язык поддерживает модули, то имеется в виду очень конкретная вещь. Склейка нескольких отдельных файлов cat module-*.s > whole.s это эмуляция, нельзя сказать, что в ассемблере есть модули. (а я говорил именно о поддержке, о плюшках встроенных в язык, не эмуляции)

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

ВВ>По-моему как раз необходимость такой "эмуляции", реализации ОО-паттернов не самыми привычными средствами для этих паттернов, и происходит из-за того, что ООП, наверное, таки нужен для проектирования систем. И возникает вопрос. А не проще ли сразу взять полноценный ООП, а не заниматься черт знает чем?

Со всем согласен до слов "ОО-паттерны" дело в том, что ООП (это моё ИМХО, если хотите) это композиция нескольких средств/паттернов/абстракций/подходов/плюшек, и все они по отдельности существовали раньше. Полиморфизм был до ООП и в других языках есть отдельно от ООП. То же самое с инкапсуляцией и остальными плюшками, якобы из ООП. ООП предлагает одну стройную модель, которая соединяет эти плюшки. В ООЯ они реализованы через классы/интерфейсы/объекты. В других языках эти плюшки реализованы иначе. То есть это не эмуляция ОО плюшек, это нормальная, невторосортная реализация плюшек, которые попутно есть и в ООЯ.

Тут вся соль, в том что мы привыкли видеть наследование, полиморфизм и пр. в ООП. И поэтому по привычке мы хотим ООП, чтобы иметь всё, что (теперь уже можно сказать традиционно) делалось плюшки. А скрытие реализации кстати, хоть и не весть какое, но было ещё в Си (typedef size_t, FILE, etc). ООП тоже предлагает скрытие реализации, нельзя же сказать, что typedef это эмуляция куска ООП.

P.S.: но я очень рад, что мы наконец-то поняли друг друга.

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

T>Да, верно, и здесь как раз будет разница. Все языки тьюринг полны, на всех можно сделать всё. Когда мы говорим, что язык поддерживает модули, то имеется в виду очень конкретная вещь. Склейка нескольких отдельных файлов cat module-*.s > whole.s это эмуляция, нельзя сказать, что в ассемблере есть модули. (а я говорил именно о поддержке, о плюшках встроенных в язык, не эмуляции)

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

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

Пока можно сказать, что есть набор определенных — "паттернов", "плюшек", называй как хочешь, — которые необходимы при разработке "больших систем". ООП объединяет эти "плюшки", предлагая некую монолитную концепцию. При желании эти "плюшки" можно найти и в других языках (а можно и не найти).

А что такое эти "плюшки" по сути? Ведь к ФП парадигме они никакого отношения не имеют, что доказывает хотя бы тот факт, что в "чистых ФП языках" их нет. Вот если бы ты пытался доказать, что в любом ФП языке... Но стоп, этот поезд уже уехал

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

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

Ты же, говоря о "привычке к ООП" и новых "средствах передвижения" никаких новых на самом деле инструментов не предлагаешь. Вот и получается, что людей убеждают вместо привычного молотка использовать особый, изогнутый под ФП. Причем совершенно неясно, зачем нужна эта "изогнутость", кроме как, чтобы засунуть в язык "плюшку", которая туда на самом деле не слишком-то хорошо вписывается (когда ее отрывают от других родственных плюшек).

А зачем гнуть молоток, если можно слить в ФП весь ООП? (подумал автор Немерле).

T>P.S.: но я очень рад, что мы наконец-то поняли друг друга.

Боюсь, с Владом вы до сих пор друг друга не поняли

И, кстати, непонятно почему. Немерле полноценно поддерживает и ФП, и ООП парадигму. Даже в императивном стиле писать можно. Спор идет о том минимальном количестве плюшек, которое будет достаточно для "больших систем"? Или о том, "нужны ли классы"?

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

LP>>>>Мне принципиально важно, чтобы в языке был ООП, который необходим для проектирования крупных систем. Если в языке будет удобный синтаксис для замыканий, а библиотека будет содержать необходимый минимум иммутабельных структур данных, тем лучше. Это все, что мне требуется от ФП.

T>>>

ООП, который необходим для проектирования крупных систем

T>>>Откуда это убеждение?

LP>>А ты с ним не согласен?

T>Да. И я очень точно могу обосновать. Смысл ООПа не в объектах и состоянии (это легко делается на любых языках). Смысл в том, что оно предлагает некоторые абстракции, методики построения программ. Эти, заезженные до дыр, инкапсуляцию и полиморфизм и лалала. Так вот, функциональные языки не забирают эти абстракции. И инкапсуляция везде есть, и все остальные. ООПа нет, а все фичи ООПа есть, понимаете?

Полиморфизм это свойство системы типов, не связанное неразрывано с ООП, согласен. Но вот инкапсуляция, способствует ли ей функциональный подход? Если разделе CTM, на который я ссылался в предыдущем сообщении, показан пример, как функциональная декомпозиция приводит к неустойчивому интерфейсу. Если нет состояния, приходится данные протаскивать через параметры если ты понимаешь о чем я, в результате чего от состава этих данных зависит интерфейс. То есть реализация выплывает из объекта наружу, в параметры функции. Нарушение инкапсуляции, расстрел на месте.

LP>>Программирование в своем развитии прошло долгий путь, оставив позади те парадигмы, которые некоторые предлагают сегодня в качестве альтернативы ООП.
T>Давайте не будем словоблудить про долгий путь. Это исключительно субъективная позиция.

Это не словоблудие, это диалектика. Если ФП за пятьдесят лет не нашел широкого промышленного применения в качестве отдельной парадигмы (как ООП), значит оно не самодостаточно.

T>Любой человек из микрософта скажет, что ОС прошли долгий путь и винда победно оставила на обочине всех. И как он может быть неправ, если у него кругом одна винда? Конечно он прав. А другой человек через дорогу винду видит два раза в неделю, у него "своя правда". Оба правы. Лично мне более интересен разговор об объективных, которые для всех одинаковы.

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

T>Потому что вы строго не описали что именно подразумевается по ФП. Но объективно в реально существующих языках, которые все называют ФЯП, есть те же самые инструменты проектирования, что и в реально существующих ООП языках. А вот это уже факт, который можно проверить, тут неоднозначности быть не может.

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

LP>>Без изменяемого состояния модульность в самом деле труднодостижима. ООП же позволяет максимально эффективно использовать это самое состояние, вводя концепцию объектов, в которые состояние заворачивается.
T>При *проектировании* я не оперирую понятием "состояние", до тех пор, пока в бизнес-логике не нужно будет это самое состояние надёжно сохранить (на диск, например). У любой программы есть что-то на входе и что-то на выходе.

Ты только и делаешь, что пишешь утилиты командной строки? В практическом программировании от состояния никуда не деться, оно буквально нас окружает. Но я (и Ван Рой в своем примере) имели ввиду не состояние, обусловленное предметной областью как таковой, а о том, как намеренное введение состояния способствует повышению модульности. Даже консольную программу можно сделать модульнее, сделав связку отдельных кусков через состояние. Ибо при этом увеличивается инкапсуляция отдельных модулей.

T>P.S.: и вот я долго отвечал на это, перечитывал ваши слова, и меня не покидает ощущение, что вы не писали на ФЯП.

Не буду говорить, что я дока в функциональных языках, но общее понятия я о них имею. Использую приему ФП в повседневном программировании на java, само собой только тогда, когда это востребовано.

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

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

T>>Да, верно, и здесь как раз будет разница. Все языки тьюринг полны, на всех можно сделать всё. Когда мы говорим, что язык поддерживает модули, то имеется в виду очень конкретная вещь. Склейка нескольких отдельных файлов cat module-*.s > whole.s это эмуляция, нельзя сказать, что в ассемблере есть модули. (а я говорил именно о поддержке, о плюшках встроенных в язык, не эмуляции)

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

ВВ>Является ли полиморфизм на указателях на ф-ции "плюшкой" или же эмуляцией? Можешь ответить утвердительно и обосновать? Я вот не вижу, где в общем случае заканчивается эмуляция и начинается плюшка.

Полиморфизм на указателях на функции? я здесь не совсем понял.
foo (void *data) это не полиморфизм, потому что нет проверки.
foo (int data); foo (string data); foo (Korova data); (overloading) без интерфейсов это полиморфизм для бедных. Вроде как конкретный тип не указан, проверки есть, но на каждый новый тип писать новую реализацию это кошмар. Плохая плюшка.
foo (IStream s) это полиморфизм, потому что конкретный тип не указан, но проверка что аргумент поддерживает необходимые операции будет. Вот это хорошая плюшка (поддержка полиморфизма).

ВВ>А что такое эти "плюшки" по сути? Ведь к ФП парадигме они никакого отношения не имеют, что доказывает хотя бы тот факт, что в "чистых ФП языках" их нет. Вот если бы ты пытался доказать, что в любом ФП языке... Но стоп, этот поезд уже уехал

А процедуры и лямбды не имеют отношения к ОО парадигме. Так что, они в C#, эмуляция или резиновая женщина или молоток гнутый? Нормально вместе живут разные фичи и подходы. Влад, кстати, правильно об этом сказал, что неплохо, когда язык поддерживает максимум разных полезностей.

Честно говоря, я не знаю ни одного языка, в котором была бы *только функциональная парадигма*. И вообще нет однопарадигменных языков, кроме эзотерики. Например, ассемлер. Там есть call/ret (процедуры) и он императивный. Всё! Уже две. Поэтому говорить о чисто функциональных или чисто процедурных или чисто <другой базворд> языках не конструктивно, ничем не вооружает. Если имелись в виду чистые функциональные языки в смысле, что там нет побочных эффектов, то это не имеет отношения к обсуждаемой теме, поэтому я не понимаю что имеется в виду.

ВВ>А значит это какие-то дополнительные "плюшки", искусственно введенные в язык. А раз их нет в чистых ФЯ, значит эти плюшки представляют какую-то более другую парадигму, чем ФЯ. Ну и какую же парадигму они представляют?

Можно придумать слово парадигма полиморфизма. Но это бесполезно. Зачем приводить что-то к парадигмам? Мне больше нравится такой подход: перечислить фичи. Например, в языке L' есть классы, интерфейсы, объекты для решения таких-то задач; процедуры, модули для решения таких-то задач; и т.п. Всё понятно и без слова парадигма.

ВВ>Вопрос не в том, являются ли всякие инкапсуляции и полиморфизмы прерогативой именно ООП. Вопрос в том, что для ООП это ключевые понятия, на которых ООП строится. А вот для ФП это не так. И говоря, что ООП требуется для больших систем, видимо, и имеются в виду, что нужен некий стандартный набор инструментов, который в рамках ООП всегда полон, давно устоялся, проверен временем и т.п. и пр.

ВВ>Ты же, говоря о "привычке к ООП" и новых "средствах передвижения" никаких новых на самом деле инструментов не предлагаешь. Вот и получается, что людей убеждают вместо привычного молотка использовать особый, изогнутый под ФП. Причем совершенно неясно, зачем нужна эта "изогнутость", кроме как, чтобы засунуть в язык "плюшку", которая туда на самом деле не слишком-то хорошо вписывается (когда ее отрывают от других родственных плюшек).

Он, кстати, не то чтобы именно под ФП изогнут. Можно сказать, что в некоторых функциональных языках существует боёк молотка и ручка отдельно. Когда нужно забить гвоздь, оба куска применяются вместе (и это не выглядит уродливо, поверьте, а лучше проверьте), когда нужно померять глубину колодца — боёк используется с верёвкой, без ручки, а когда надо что-то разрубить, на ручку надевают лезвие и получается топор. Весь процесс функционального программирования состоит в том, чтобы найти сочетание (композицию) имеющихся очень примитивных (по отдельности) частей.

ВВ>А зачем гнуть молоток, если можно слить в ФП весь ООП? (подумал автор Немерле).

Ну раз у них получилось, это конструктивное доказательство что такой подход тоже вполне пригоден. А ещё есть другой подход, тоже конструктивно доказана пригодность.

А у ООПа, кстати, есть объективные недостатки по скорости поводу наследования реализации, связанные с затратами на подъём по дереву наследников.
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

Понятно, что по сравнению с си/паскалем любой дурак с удовольствием будет платить эти накладные расходы. Я просто говорю, что есть ещё другие варианты, со своими достоинствами и недостатками; не говорю, что есть серебряная пуля.

ВВ>Немерле полноценно поддерживает и ФП, и ООП парадигму. Даже в императивном стиле писать можно. Спор идет о том минимальном количестве плюшек, которое будет достаточно для "больших систем"? Или о том, "нужны ли классы"?

Изначально я говорил, что для построения больших проектов нужен не конкретно ООП, как монолитная концепция из нескольких плюшек, а что эти плюшки *просто нужны*: по отдельности или в качестве суммы — неважно. В общем, да, можно сказать, о том "нужны ли классы".

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

T>Полиморфизм на указателях на функции? я здесь не совсем понял.

Сравни:

class A
{
  abstract void Foo();

  void Bar()
  {
        Foo();
  }
}

class B
{
    Func _foo;
    
    B(Func foo)
    {
        _foo = foo;
    }
    
    void Bar()
    {
        _foo();
    }
}

T>>>>Откуда это убеждение?

LP>>>А ты с ним не согласен?

T>>Да. И я очень точно могу обосновать. Смысл ООПа не в объектах и состоянии (это легко делается на любых языках). Смысл в том, что оно предлагает некоторые абстракции, методики построения программ. Эти, заезженные до дыр, инкапсуляцию и полиморфизм и лалала. Так вот, функциональные языки не забирают эти абстракции. И инкапсуляция везде есть, и все остальные. ООПа нет, а все фичи ООПа есть, понимаете?

LP>Полиморфизм это свойство системы типов, не связанное неразрывано с ООП, согласен. Но вот инкапсуляция, способствует ли ей функциональный подход? Если разделе CTM, на который я ссылался в предыдущем сообщении, показан пример, как функциональная декомпозиция приводит к неустойчивому интерфейсу. Если нет состояния, приходится данные протаскивать через параметры если ты понимаешь о чем я, в результате чего от состава этих данных зависит интерфейс. То есть реализация выплывает из объекта наружу, в параметры функции. Нарушение инкапсуляции, расстрел на месте.

Вот мне щас не хотелось бы показывать на конкретный язык, но в хаскеле есть инструмент, который в частности используется для "протаскивания" данных не через параметры. Через параметры можно сделать некрасиво, понимаю о чём вы, да. А можно и нормально, если тип абстрактный и состав данных снаружи неизвестен, это подход Си с typedef.

LP>>>Программирование в своем развитии прошло долгий путь, оставив позади те парадигмы, которые некоторые предлагают сегодня в качестве альтернативы ООП.
T>>Давайте не будем словоблудить про долгий путь. Это исключительно субъективная позиция.
LP>Это не словоблудие, это диалектика. Если ФП за пятьдесят лет не нашел широкого промышленного применения в качестве отдельной парадигмы (как ООП), значит оно не самодостаточно.

На одних функциях, если вы об этом, далеко не уедешь, тут глупо спорить. С другой стороны, ООЯ без модулей (в смысле отдельно компилируемые файлы), процедур и прочих парадигм (а они не входят в ООП) был бы тоже ужасен. Поэтому вы сравниваете воображаемый язык с одной ФП парадигмой против языка с ООП и другими. В этом и словоблудие, или диалектика, если вам так угодно.

T>>Любой человек из микрософта скажет, что ОС прошли долгий путь и винда победно оставила на обочине всех. И как он может быть неправ, если у него кругом одна винда? Конечно он прав. А другой человек через дорогу винду видит два раза в неделю, у него "своя правда". Оба правы. Лично мне более интересен разговор об объективных, которые для всех одинаковы.

LP>Правильно, оставила. Спорить с этим тяжело. Есть ведь объективные данные, позволяющие судить о популярности операционных систем. В данном споре ты как раз выступаешь в роли того самого "человека через дорогу".

Я знаю один хостинг с виндой. И сотни с линупсом и freebsd. Вот такие данные. На десктопе всё наоборот. Кто кого оставил? В среднем смотреть бессмысленно, надо смотреть по отраслям. К этому я и призывал изначально.

T>>Потому что вы строго не описали что именно подразумевается по ФП. Но объективно в реально существующих языках, которые все называют ФЯП, есть те же самые инструменты проектирования, что и в реально существующих ООП языках. А вот это уже факт, который можно проверить, тут неоднозначности быть не может.

LP>Тогда язык перестает быть чисто функциональным. Ты пытаешься приписать функциональной парадигме наследующиеся из ООП особенности некоторых нечистых функциональных языков. Да, они предоставляют те же концепции, только ФП-то здесь при чем?

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

LP>>>Без изменяемого состояния модульность в самом деле труднодостижима. ООП же позволяет максимально эффективно использовать это самое состояние, вводя концепцию объектов, в которые состояние заворачивается.
T>>При *проектировании* я не оперирую понятием "состояние", до тех пор, пока в бизнес-логике не нужно будет это самое состояние надёжно сохранить (на диск, например). У любой программы есть что-то на входе и что-то на выходе.

LP>Ты только и делаешь, что пишешь утилиты командной строки? В практическом программировании от состояния никуда не деться, оно буквально нас окружает. Но я (и Ван Рой в своем примере) имели ввиду не состояние, обусловленное предметной областью как таковой, а о том, как намеренное введение состояния способствует повышению модульности. Даже консольную программу можно сделать модульнее, сделав связку отдельных кусков через состояние. Ибо при этом увеличивается инкапсуляция отдельных модулей.

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

Но, по-моему, очевидно, что любую программу можно спроектировать (и реализовать) хорошо и плохо. С лишним состоянием и без. А вы почему-то склоняетесь к крайности (состояние — хорошо, давайте делать его больше).

LP>Не буду говорить, что я дока в функциональных языках, но общее понятия я о них имею. Использую приему ФП в повседневном программировании на java, само собой только тогда, когда это востребовано.

Желаю вам познакомиться с ними поближе и чтоб это знакомство доставило радость.

T>>Полиморфизм на указателях на функции? я здесь не совсем понял.

AVK>Сравни:
[урезано]

В вырожденном случае второй пример сводится к просто bar_not_class(Func foo) { foo(); }. Это пригодится, чтобы foo вызывать с хитрыми параметрами или ещё что, но не понял причём тут полиморфизм.
А первый так и не понял зачем он нужен. Похоже на то, что сигнатуру и реализацию Foo спрятали за другой функцией (Bar), но как это относится к полиморфизму неясно.

Вы не могли бы привести примеры использования этих классов?

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

ВВ>>Является ли полиморфизм на указателях на ф-ции "плюшкой" или же эмуляцией? Можешь ответить утвердительно и обосновать? Я вот не вижу, где в общем случае заканчивается эмуляция и начинается плюшка.
T>Полиморфизм на указателях на функции? я здесь не совсем понял.

Не, не то. Подмена указателя на функцию в заранее описанной структуре это своего рода аналог виртуальной функции. Т.е. у нас есть, скажем, структура anyStream, которая может и представлять и memoryStream, и fileStream и т.д.
Нужно тебе добавить свою реализацию encryptedStream — объявляешь ф-ции, заполняешь anyStream указателями — и вперед. Очень даже полиморфно все.

Можно в принципе те же интерфейсы имитировать через переинтерпретацию памяти, но такой подход мне меньше нравится

Ну так короче. Эмуляция это или плюшка?

ВВ>>А что такое эти "плюшки" по сути? Ведь к ФП парадигме они никакого отношения не имеют, что доказывает хотя бы тот факт, что в "чистых ФП языках" их нет. Вот если бы ты пытался доказать, что в любом ФП языке... Но стоп, этот поезд уже уехал
T>А процедуры и лямбды не имеют отношения к ОО парадигме. Так что, они в C#, эмуляция или резиновая женщина или молоток гнутый? Нормально вместе живут разные фичи и подходы. Влад, кстати, правильно об этом сказал, что неплохо, когда язык поддерживает максимум разных полезностей.

В С#? А чем не гнутый молоток-то. Очень даже. Разница только в том, что никто не пытается утверждать, что ФП языки не нужны, раз в C# есть лямбды. Или что все задачи из ФП можно с той же легкостью решать на C# в ФП стиле (а это просто неправда). Почувствуй тут разницу, как говорится.
As of now С# вообще очень плохой пример, если речь идет о "высоком дизайне". Как тут кто-то пошутил, у МС что бы они не делали, все время получается си плюс плюс. Засунули в язык кучу, извините, "парадигм" в весьма укушенном к тому же виде, теперь от первоначальной концепции вообще ничего не осталось (если она, конечно, была, концепция эта).

T>Честно говоря, я не знаю ни одного языка, в котором была бы *только функциональная парадигма*. И вообще нет однопарадигменных языков, кроме эзотерики. Например, ассемлер. Там есть call/ret (процедуры) и он императивный. Всё! Уже две. Поэтому говорить о чисто функциональных или чисто процедурных или чисто <другой базворд> языках не конструктивно, ничем не вооружает. Если имелись в виду чистые функциональные языки в смысле, что там нет побочных эффектов, то это не имеет отношения к обсуждаемой теме, поэтому я не понимаю что имеется в виду.

Э, давай не уходить в сторону. Ты себе ФП без "процедурной парадигмы" представляешь? Может такое быть? А без ОО парадигмы ФП вполне может быть. Более того, ООП (вернее, те семые "плюшки") ФП скорее даже мешает (но, да, склеить их, конечно, можно, если очень хочется).

ВВ>>А значит это какие-то дополнительные "плюшки", искусственно введенные в язык. А раз их нет в чистых ФЯ, значит эти плюшки представляют какую-то более другую парадигму, чем ФЯ. Ну и какую же парадигму они представляют?
T>Можно придумать слово парадигма полиморфизма. Но это бесполезно. Зачем приводить что-то к парадигмам? Мне больше нравится такой подход: перечислить фичи. Например, в языке L' есть классы, интерфейсы, объекты для решения таких-то задач; процедуры, модули для решения таких-то задач; и т.п. Всё понятно и без слова парадигма.

Да в том-то и проблема, что ничего непонятно.
Я еще раз повторюсь, независимо от того, что на многие из своих основополагающих принципов у ООП нет монополии, ООП единственная парадигма которая предлагает их все, причем в непротиворечивом виде.

Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.

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

T>Он, кстати, не то чтобы именно под ФП изогнут. Можно сказать, что в некоторых функциональных языках существует боёк молотка и ручка отдельно. Когда нужно забить гвоздь, оба куска применяются вместе (и это не выглядит уродливо, поверьте, а лучше проверьте), когда нужно померять глубину колодца — боёк используется с верёвкой, без ручки, а когда надо что-то разрубить, на ручку надевают лезвие и получается топор. Весь процесс функционального программирования состоит в том, чтобы найти сочетание (композицию) имеющихся очень примитивных (по отдельности) частей.

Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла? У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.

ВВ>>А зачем гнуть молоток, если можно слить в ФП весь ООП? (подумал автор Немерле).
T>Ну раз у них получилось, это конструктивное доказательство что такой подход тоже вполне пригоден. А ещё есть другой подход, тоже конструктивно доказана пригодность.
T>А у ООПа, кстати, есть объективные недостатки по скорости поводу наследования реализации, связанные с затратами на подъём по дереву наследников.

Погоди, ты уверен, что в рамках обсуждения ФП, *действительно* хочешь говорить о скорости?

T>Понятно, что по сравнению с си/паскалем любой дурак с удовольствием будет платить эти накладные расходы. Я просто говорю, что есть ещё другие варианты, со своими достоинствами и недостатками; не говорю, что есть серебряная пуля.

Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.

ВВ>Не, не то. Подмена указателя на функцию в заранее описанной структуре это своего рода аналог виртуальной функции. Т.е. у нас есть, скажем, структура anyStream, которая может и представлять и memoryStream, и fileStream и т.д.
ВВ>Нужно тебе добавить свою реализацию encryptedStream — объявляешь ф-ции, заполняешь anyStream указателями — и вперед. Очень даже полиморфно все.
ВВ>Можно в принципе те же интерфейсы имитировать через переинтерпретацию памяти, но такой подход мне меньше нравится
ВВ>Ну так короче. Эмуляция это или плюшка?

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

ВВ>Э, давай не уходить в сторону. Ты себе ФП без "процедурной парадигмы" представляешь? Может такое быть? А без ОО парадигмы ФП вполне может быть. Более того, ООП (вернее, те семые "плюшки") ФП скорее даже мешает (но, да, склеить их, конечно, можно, если очень хочется).

Да, есть лисп, который чисто функции и списки; всё остальное делается средствами самого языка. Во всех остальных языках такой чистоты нет но те же самые плюшки, которые есть в ООП, вряд ли мешают. (сейчас напишу почему)

(упорно кажется, что следущий параграф я уже где-то писал)
Все плюшки во всех языках направлены на увеличение качества программ (например, через уменьшение количества ошибок). Исходя из этого (теоретически) плюшки не могут мешать друг другу. Чем их больше — тем качественнее программы. А вот как они на практике сочетаются в конкретных языках, получается там гнутый молоток или нет, это не парадигмы виноваты, а конкретные люди. Ну это моё мнение, может быть есть какая-то мощная теория, которая логически доказывает как одни плюшки мешают другим, я не видел.

ВВ>Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.

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

ВВ>У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.

Ну да, если убрать слово указатель, то это лямбда исчисление. Всё из функций, даже рыбы и медузы.

ВВ>Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла?

Это очень простой вопрос. Всё это нужно для проверки кода на корректность и для оптимизаций (в т.ч. компиляции в машинный код).

T>>Ну раз у них получилось, это конструктивное доказательство что такой подход тоже вполне пригоден. А ещё есть другой подход, тоже конструктивно доказана пригодность.
T>>А у ООПа, кстати, есть объективные недостатки по скорости поводу наследования реализации, связанные с затратами на подъём по дереву наследников.

ВВ>Погоди, ты уверен, что в рамках обсуждения ФП, *действительно* хочешь говорить о скорости?

Невероятно, но факт, есть функциональные языки, которые в отдельных тестах по скорости отстают от Си всего в 1-2 раза. (правда, по памяти отстают намного больше)
Да, в этом плане, за последние лет 10-15 они очень сильно продвинулись.

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
Из 15 языков в таблице, я насчитал 5 функциональных. Там, правда Java три раза учавствует.

T>>Понятно, что по сравнению с си/паскалем любой дурак с удовольствием будет платить эти накладные расходы. Я просто говорю, что есть ещё другие варианты, со своими достоинствами и недостатками; не говорю, что есть серебряная пуля.

ВВ>Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.

Про варианты это надо конкретные языки назвать?

Я уже говорил, что все составляющие ООПа существовали и до первых ООП языков. Поэтому нельзя сказать, что я оттуда что-то взял. И я не говорю, что это выдаётся за brave new world. Единственный мой посыл заключался в том, что хотеть надо средства для решения задач (в общем, не конкретное одно средство — ООП). Я могу напомнить с чего начался весь этот сыр-бор.

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

Си почти всё позволяет, но почти ничего не контроллирует. Мне кажется, что в ежедневной работе любому программисту более интересен язык, который ограждает от ошибок. В этом плане чистые функциональные языки (в смысле без побочных эффектов), такие как Agda, Clean, Haskell ограждают ещё и от ошибок вызванных произвольным изменением состояния.

T>>>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
WH>>Это вопрос времени.

LP>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.

Кстати, может быть, вам будет интересно, я в википедии нашёл ссылку на исследование по поводу GADT (это как бы подмножество зависимых типов) в C# и Java.

http://research.microsoft.com/~akenn/generics/gadtoop.pdf

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

T>Я подумал и получается, что нет, это не полиморфизм, потому что он неконтроллируемый (я ведь могу указатель на любую функцию сунуть в эту структуру).

Объяви да засовывай только то, что нужно:

struct anyStream {
  int (*xReadByte) (int /*offset*/, hren* /*какая-нибудь еще хрень*/);
};

T>(упорно кажется, что следущий параграф я уже где-то писал)
T>Все плюшки во всех языках направлены на увеличение качества программ (например, через уменьшение количества ошибок). Исходя из этого (теоретически) плюшки не могут мешать друг другу. Чем их больше — тем качественнее программы. А вот как они на практике сочетаются в конкретных языках, получается там гнутый молоток или нет, это не парадигмы виноваты, а конкретные люди. Ну это моё мнение, может быть есть какая-то мощная теория, которая логически доказывает как одни плюшки мешают другим, я не видел.
ВВ>>Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.
T>Я говорю не хуже, потому что я пробовал и мне понравилось. А вам?

Ну начнем с того, что "не хуже" по крайней мере недостаточно.

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

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

Но, погодите, ведь это означает, что язык *изначально проектировался* как "гибридный", а не как ФЯ? Т.е. о нем уже некорректно говорить как просто об ФЯ. Это гибридный язык. Поддерживающий ФП и ООП. Вот опять немерле в голову лезет.

А лягут ли хорошо ООП "плюшки" в ФЯ язык (не буду употреблять слово "чистый", раз уж оно тебе не нравится), который все же изначально проектировался как ФЯ?

ВВ>>У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.
T>Ну да, если убрать слово указатель, то это лямбда исчисление. Всё из функций, даже рыбы и медузы.

Вот чем такая позиция отличается от вашей? ИМХО налицо определенное сходство.

ВВ>>Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла?
T>Это очень простой вопрос. Всё это нужно для проверки кода на корректность и для оптимизаций (в т.ч. компиляции в машинный код).

Проверку кода на корректность можно делать и без этого. А по поводу оптимизаций — извините, что из перечисленного используется для *оптимизации*? Вы ничего не путаете? Скорее всего, наоборот. Подлинный сишник, например, скажет, что это все мега-зло и мешает ему писать заоптимизированные до смерти "большие системы". И в чем-то будет прав, кстати. Если речь идет, скажем, о ядре ОС.

T>http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
T>Из 15 языков в таблице, я насчитал 5 функциональных. Там, правда Java три раза учавствует.

Ну насколько там F# от C# отстает
А вообще нуна эту вашу табличку Это тест компиляторов по большей части. Добавьте туда "взрослый" промышленный компилятор C++ вроде VC или Intel CPP, и он порвет всех остальных как тузик грелку.

ВВ>>Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.
T>Про варианты это надо конкретные языки назвать?

Другие варианты построения "больших систем". Без ОО. А так получается, что ОО вроде бы и нет, а вроде он и есть. Я разницы не вижу. В упор.

T>Я уже говорил, что все составляющие ООПа существовали и до первых ООП языков. Поэтому нельзя сказать, что я оттуда что-то взял. И я не говорю, что это выдаётся за brave new world. Единственный мой посыл заключался в том, что хотеть надо средства для решения задач (в общем, не конкретное одно средство — ООП). Я могу напомнить с чего начался весь этот сыр-бор.

Так ООП это ведь не одно средство, а скорее набор средств, аккуратно уложенных в коробочку, согласно некоторой "концепции". Ты (в лучшем случае) предлагаешь те же самые средства в другой коробочке. И зачем оно?

T>- хотелось бы ООП язык с зависимыми типами
T>- а зачем именно ООП?
T>- потому что ООП нужен для проектирования больших систем
T>- несогласен, нужны части, а не конкретное воплощение ... и поехало.

Если речь идет о том, можно ли вообще, т.е. в принципе, писать большие системы на не-ОО языках, то да — можно. На Си же пишут. И даже не в ОО-стиле пишут.

А так, ну да, нужны части. А часто нужны все части. А часто еще нужно, чтобы все эти части хорошо вписывались в дизайн языка. И так далее. И если у вас все это есть — значит язык поддерживает ОО-парадигму. Разве нет?