Borland объявил о намерении продать свой IDE бизнес

> Ничего не смешал.

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

> http://www.cs.uu.nl/~daan/parsec.html

Ага, да видел я его, но не подумал, что ты о нём. :) Значится парсеры как таковые, конечно есть, только их помнить надо. Это не мой профиль. С задачами парсинга текста я уже давно не сталкивался. Сейчас xml больше, а языки сам, увы не разрабатываю. Раньше - видел и отдельные и в составе интерпритаторов.

P.S. Кстати, parsec на хаскеле написан. :) Тоже не самый популярный язык... ;-)

> Но эта связка хорошо интегрируется. Вот в чем дело.

Ну это... На вкус и цвет - товарищей нет. Кону охота - интегрирует, Delphi IDE сто лет как расширяемая...

> У тебя объекты, которые ты поручаешь обрабатывать процедуре!

У пионера каша в голове.

Это может быть и не процедура, а метод. Суть от этого не меняется.

Разница только в одном: во время компиляции чётко известно, какого типа ключи и значения в хэше будут, и код генерится с учётом этого знания. Никаких левых значений там не будет гарантированно. А в OP во время компиляции никаких гарантий нет, и код должен во время исполнения проверять каждый (!) ключ и каждое (!) значение, используя не то чтобы очень шустрое RTTI.

> С задачами парсинга текста я уже давно не сталкивался.

Это вот и есть первейший признак пионеристости.

> используя не то чтобы очень шустрое RTTI

Да тут дело не только в шустрости - ряд программ, корректиных в OP, в Haskell, ML, C++ не будут правильно типизированными (well typed).

> Ага, да видел я его, но не подумал, что ты о нём. :) Значится парсеры как таковые, конечно есть, только их помнить надо. Это не мой профиль. С задачами парсинга текста я уже давно не сталкивался. Сейчас xml больше, а языки сам, увы не разрабатываю. Раньше - видел и отдельные и в составе интерпритаторов.

Угу, вот только такую _библиотеку_ на OP не написать, препроцессор нужен. Или DSL, как например, yacc для C.

Да вот boost::spirit тоже не OP не реализовать.

> P.S. Кстати, parsec на хаскеле написан. :) Тоже не самый популярный язык... ;-)

Я о популярности не говорил. Я просто приводил примеры из C++ как довольно известного языка.

> Да тут дело не только в шустрости - ряд программ, корректиных в OP

Т.е. опять, ссылаемся на то, что OP плох, или не годится, потому что любимый способ написания программ там не применим или применим с ограничениями? ;-)

> Угу, вот только такую _библиотеку_ на OP не написать, препроцессор нужен.

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

Впрочем, специально для тех, кто не мыслит языка без препроцессора, в FPC начали его добавлять. Так что я не удивлюсь, если через годик туда начнут портировать STL... Я к этому отношуть достаточно нейтрально. Мне-то что, я-то C++ знаю. Пусть не в совершенстве (нет постоянной практики), но STL понимаю.

А одновременно, приходится признать, что многие, всю жизнь просидевшие в C/C++ просто не представляют, что препроцессор далеко не обязательная часть языка. Можно даже сказать, навеска. Потому и раздаются возгласы - а вот это есть? Нет? У... Всё, тогда такие-то вещи там НИ КАК не сделать... Гы, лол! ;-)

> Я о популярности не говорил. Я просто приводил примеры из C++ как довольно известного языка.

Дык! Наверное я чего-то глобально непонимаю, но моё имхо приходит в ужас от "пример из C++", написанный на Haskel! ;-)))

> Т.е. опять, ссылаемся на то, что OP плох, или не годится, потому что любимый способ написания программ там не применим или применим с ограничениями? ;-)

Тчоно также можно доказывать, что brainfuck - хороший язык. Или whitespace. Конечно же, ОП - алгоритмически полный язык и на нем можно реализовать произвольный алгоритм.

> Мдя... Собственно, на этом можно и закончить. Пожалуйста, если тебе так хочеться - _верь_, что нельзя.

В ОП уже появились параметрическая система типов, классы типов, замыкания и частиное применение функций? Если этого нет, то аналог parsec не написать (boost::spirit использует шаблоны и перегрузку операторов).

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

Библиотека комбинаторов в ОП не может быть реализована из-за отстутсвия в нем замыкания функций. А для имитации нужны шаблоны как в С++ (см. boost).

> А одновременно, приходится признать, что многие, всю жизнь просидевшие в C/C++ просто не представляют, что препроцессор далеко не обязательная часть языка. Можно даже сказать, навеска. Потому и раздаются возгласы - а вот это есть? Нет? У... Всё, тогда такие-то вещи там НИ КАК не сделать... Гы, лол! ;-)

Да правда что ли? Я приводил примеры в которых препроцессор не используется. А то, что в ОП аналогичесные библиотеки нельзя реализовать без препроцесора - это недостаток ОП. В _нормальных_ языках препроцессор не нужен. В _современном_ С++ можно свести использование препроцессора к #include и стажам влючения. В Haskell он используется только для условной компиляции.

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

> Впрочем, специально для тех, кто не мыслит языка без препроцессора, в FPC начали его добавлять. Так что я не удивлюсь, если через годик туда начнут портировать STL... Я к этому отношуть достаточно нейтрально. Мне-то что, я-то C++ знаю. Пусть не в совершенстве (нет постоянной практики), но STL понимаю.

Что-то мне подсказывает, что вы не представляете как STL реализована. И тем более не представляете как реализованана boost.

> Да правда что ли? Я приводил примеры в которых препроцессор не используется.

Сдаётся мне что тот пионер относит и темплейты к "препроцессору". На то он и пионер.

> Тчоно также можно доказывать, что brainfuck - хороший язык.

Вряд ли. Я видел пишущих на нём. Практически все поголовно используют препроцессор-транслятор. :)

> Если этого нет, то аналог parsec не написать (boost::spirit использует шаблоны и перегрузку операторов).

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

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

Будем устраивать экзамен online? ;-)

> И твердят, что на ОП можно все написать - да, можно, но нужно ли?

Да не нужно. Я сам могу назвать кучу задач, для которых OP не стоит использовать. Так ведь твердят, что для него вообще нет подходящих задач! :)

Кстати, вышеупомянутый Haskel тоже не "всёядный", я читал, что у него gc встроенный. А это не годятся для некоторых задач.

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

Это о ком? Не надо путать нежелание и симпатии. Кстати, легко повернуть наоборот. :)

P.S. Интересный разговор получился, хотя и на повышенный тонах. Haskel, в качестве следующего детально изучаемого языка я уже рассматривал. А тут ещё дополнительная агитация. :) Только есть одно но - не назовёщь его сколько нибудь используемым языком. На sf сейчас зарегистрировано 47 проектов... :-( На Forth и Lua - больше! А уж на фоне C и C++...