ВВ>Но речь-то о проектировании. И если тут по-прежнему то же, что и в ООП... Где "новые горизонты"?
В проектировании так и останется ОО (недавно ругались с Владом, признаю свою неправоту) но это не значит что только
языки поддерживающие майнстримное объектно ориентированное программирование (C++/Java/C#) хороши для разработки
объектно спроектированных программ. Даже если оставить в стороне Smalltalk и языки с прототипным ОО, то даже ML
семейство дает достаточно средств (типы, алгебраические типы, модули, мутабельность) чтобы не менее выразительно
чем мейнстримное ОО реализовывать результат ОО дизайна.
Re[22]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
FR>Кроме того я вообще не вижу никаких преимуществ шарпа при написании подобных приложений, FR>надежности от управляемого кода мы не получим на такой смеси, мощность языка тоже не особо востребована, так FR>как кодирование очень небольшая часть работы (несколько сотен строк кода в неделю вполне нормально). FR>Если бы я писал с нуля подобное выбрал бы (позабыв свою любовь к питону и окамлу) тот же C++, но не C++ Builder, FR>а VC + wxWidfets (или Qt).
Ну так бы и сказал сразу — пишем на билдере, больше ничего не дают. А то "специфику не понимаем". Конспиратор нашелся
Re[45]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
FR>В проектировании так и останется ОО (недавно ругались с Владом, признаю свою неправоту) но это не значит что только FR>языки поддерживающие майнстримное объектно ориентированное программирование (C++/Java/C#) хороши для разработки FR>объектно спроектированных программ. Даже если оставить в стороне Smalltalk и языки с прототипным ОО, то даже ML FR>семейство дает достаточно средств (типы, алгебраические типы, модули, мутабельность) чтобы не менее выразительно FR>чем мейнстримное ОО реализовывать результат ОО дизайна.
Т.е. предлагается в проектировании по-прежнему использовать "классическое" ОО, а потом транслировать все это дело в модель используемого ЯВУ, которая может кардинально отличаться? И на хрена нужны такие радости?
Re[46]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, FR, Вы писали:
FR>>В проектировании так и останется ОО (недавно ругались с Владом, признаю свою неправоту) но это не значит что только FR>>языки поддерживающие майнстримное объектно ориентированное программирование (C++/Java/C#) хороши для разработки FR>>объектно спроектированных программ. Даже если оставить в стороне Smalltalk и языки с прототипным ОО, то даже ML FR>>семейство дает достаточно средств (типы, алгебраические типы, модули, мутабельность) чтобы не менее выразительно FR>>чем мейнстримное ОО реализовывать результат ОО дизайна.
ВВ>Т.е. предлагается в проектировании по-прежнему использовать "классическое" ОО, а потом транслировать все это дело в модель используемого ЯВУ, которая может кардинально отличаться? И на хрена нужны такие радости?
Нет предлагается не отказываться при проектировании для функциональных языков от использования ОО декомпозиции,
ну и выражать ее в терминах адекватных для используемого языка, например для ML семейства в модулях, функторах
и алгебраических типах.
Re[59]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
FR>Нет предлагается не отказываться при проектировании для функциональных языков от использования ОО декомпозиции, FR>ну и выражать ее в терминах адекватных для используемого языка, например для ML семейства в модулях, функторах FR>и алгебраических типах.
ОО декомпозиция, выраженная в терминах ФП? Это ты как-то очень мощно задвинул. Ты как вообще себе это представляешь — выразить ОО модель в терминах ФЯ, который не поддерживает ООП?
Re[60]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ОО декомпозиция, выраженная в терминах ФП? Это ты как-то очень мощно задвинул.
Имелось в ввиду что эта декомпозиция в конечном счете реализуется конкретными языковыми механизмами, например
иерархией классов.
ВВ>Ты как вообще себе это представляешь — выразить ОО модель в терминах ФЯ, который не поддерживает ООП?
Оно вполне адекватно отображается в термины конкретных языков, которые поддерживают не только чистое ФП, но и
многое другое,например те же модули ML вполне обеспечивают реализацию ОО декомпозиции. Притом выразительность
этой реализации будет вполне сравнима с классами из C++/C#/Java.
Re[35]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>>>>>Откуда это убеждение?
LP>>>>А ты с ним не согласен? T>Желаю вам познакомиться с ними поближе и чтоб это знакомство доставило радость.
Спасибо
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[61]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
ВВ>>ОО декомпозиция, выраженная в терминах ФП? Это ты как-то очень мощно задвинул. FR>Имелось в ввиду что эта декомпозиция в конечном счете реализуется конкретными языковыми механизмами, например FR>иерархией классов.
Ну это то, что я и сказала в посте до этого. Имеем модель на одном "языке" — транслируем ее в другой. Разве нет?
ВВ>>Ты как вообще себе это представляешь — выразить ОО модель в терминах ФЯ, который не поддерживает ООП? FR>Оно вполне адекватно отображается в термины конкретных языков, которые поддерживают не только чистое ФП, но и FR>многое другое,например те же модули ML вполне обеспечивают реализацию ОО декомпозиции. Притом выразительность FR>этой реализации будет вполне сравнима с классами из C++/C#/Java.
Ну понятно. Т.е. ФЯ уже не совсем "чистый", а выразительность "вполне сравнима". И видимо степень "сравнимости" зависит от того, насколько конкретный ФЯ в действительности поддерживает ОО парадигму. Вот на Немерле явно будет не хуже, чем на C#.
Причем это еще не касаясь вопроса, а зачем вообще нужен этот геморой. Ради большой любви к ФП? Если у нас есть ОО модель, так давайте и возьмем ОО язык для нее. Алгоритмы можно описывать и на ФЯ, никто же не против.
Re[62]: Быстро превратить интерпретатор в компилятор
ВВ>Ну это то, что я и сказала в посте до этого. Имеем модель на одном "языке" — транслируем ее в другой. Разве нет?
Нет. "Язык" на котором ведется проектирование и ОО декомпозиция не совпадает с конкретным языком (например C++) на
котором происходит реализация того что напроектировали, ты же неявно предположил что в случае майнстримных языков
такое совпадение имеет место. В реальности всегда приходится транслировать.
Кроме того реальное проектирование (исключая может быть самое высокоуровневое) всегда происходит с учетом языка
реализации, поэтому ОО декомпозиция для ML и C++ не совпадут, хотя в общих чертах будут похожи.
ВВ>Ну понятно. Т.е. ФЯ уже не совсем "чистый", а выразительность "вполне сравнима". И видимо степень "сравнимости" зависит от того, насколько конкретный ФЯ в действительности поддерживает ОО парадигму. Вот на Немерле явно будет не хуже, чем на C#.
ML тоже будет не хуже, хотя ОО парадигму в стиле C# не подерживает.
ВВ>Причем это еще не касаясь вопроса, а зачем вообще нужен этот геморой. Ради большой любви к ФП? Если у нас есть ОО модель, так давайте и возьмем ОО язык для нее. Алгоритмы можно описывать и на ФЯ, никто же не против.
Так никто никого не заставляет не нравится не бери. А геморрой только у тебя в голове
Re[60]: Быстро превратить интерпретатор в компилятор
ВВ>Это ответ на какой-то другой вопрос, причем достаточно очевидный. Я же не спрашиваю тебя, почему в ФЯ в ООП стиле писать неудобно? Интересует другой момент — почему неудобно использовать концепции ОО и не тащить при этом весь груз ООП-ных классов с наследованиями.
ВВ>Мы же с тобой определились, что в Си все нужные плюшки есть. ВВ>В ФЯ (подставь любое название) тоже есть. ВВ>Какие же преимущества при использовании этих плюшек есть в ФЯ?
Понял теперь. Преимущества у конкретных языков в *поддержке* (то есть не надо эмулировать) конкретных плюшек. Кстати, я вспомнил слово, которое точно передаёт смысл поддержки: "first-class". В шарпе first-class объекты, в си first-class указатели, а во многих функциональных языках first-class алгебраические типы.
Ну возьмём, например, параметрический полиморфизм. В ФЯ можно написать обобщённую функцию map (map f [] = [], map f (x:xs) = f x : map f xs). А в си нельзя описать такую функцию, придётся писать отдельные варианты для разных типов, которые будут различаться на пару символов.
ВВ>>>Выделение абстракций высокого уровня, описание системы на языке этих абстракций. Вот у нас есть задача — приложение должно работать с файлами под юниксом и вин. Надо создать виртуальную файловую систему. Сначала продумать дизайн. Мы знаем, что есть файлы, директории, атрибуты у тех и других, операции, состояния и проч. T>>Согласен. Но это абстракции и они точно так же не "принадлежат ОО", как и полиморфизм. Эндемичным для ОО в проектировании, наверное, было бы разбиение системы на "объекты"? (но если так, то мы придём к очень интересному) ВВ>Никто не говорит, что абстракции "принадлежат ООП". Абстракции принадлежат тому, кто их придумал.
Имеется в виду вообще "абстракция" (как один из компонентов ОО), а не конкретная абстракция файл/нечто что можно прочитать/etc.
ВВ>И что значит "разбиение системы на объекты"? Как ты себе это представляешь?
Не знаю, я пытаюсь придумать что из того, что вы назвали вообще имеет отношение к ОО. Декомпозиция, очевидно, была раньше.
ВВ>Я уже привел все нужные "термины", именно в таких ООП приложение и разрабатывается, они напрямую мапятся на сущности в ООП.
Отличная формулировка. "мапятся на сущности в ООП". А ещё напрямую мапятся на сложные типы и функции без ООП.
ВВ>Речь же не о том, что любую задачу можно решить в процедурном стиле. ВВ>Вот я ввел ряд абстракций — файл, директория и пр., обладающих определенным поведением, имеющих состояние и пр. Все это, как ты правильно, "не принадлежит" ООП, это, собственно, предметная область. В ООП у меня прямой путь от этих абстракций к коду. А в ФП?
В Haskell/ML/OCaml тоже прямой путь к коду. Опишем тип File, опишем (для классической деревянной фс) тип дерева из File, опишем функции для работы с этими типами и т.д.
Re[59]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
FR>Нет предлагается не отказываться при проектировании для функциональных языков от использования ОО декомпозиции, FR>ну и выражать ее в терминах адекватных для используемого языка, например для ML семейства в модулях, функторах FR>и алгебраических типах.
А может лучше выбрать язык с адекватной терминологией? Ну, в смысле, поддерживающий ООП непосредственно. Таких ФЯ не мало ведь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[63]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
FR>ML тоже будет не хуже, хотя ОО парадигму в стиле C# не подерживает.
С удовольствием посмотрел бы на примеры. А то как-то совсем не верится. Уверен, что такой ООП будет очень похож на ООП на С.
И хотелось бы видеть именно реализацию на ML, а не OCamle, где какой ни какой ООП поддерживается.
ВВ>>Причем это еще не касаясь вопроса, а зачем вообще нужен этот геморой. Ради большой любви к ФП? Если у нас есть ОО модель, так давайте и возьмем ОО язык для нее. Алгоритмы можно описывать и на ФЯ, никто же не против.
FR>Так никто никого не заставляет не нравится не бери. А геморрой только у тебя в голове
Не. Геморрой он в заднице у тех, то реализует на чистых ФЯ проекты спроектированные в ОО-стиле.
ЗЫ
А почему бы просто не выбрать язык который одновременно хорошо поддерживает и ФП и ООП? Не уж то решение на нем будет хуже чем эмуляция?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[64]: Быстро превратить интерпретатор в компилятор
FR>>ML тоже будет не хуже, хотя ОО парадигму в стиле C# не подерживает.
VD>С удовольствием посмотрел бы на примеры. А то как-то совсем не верится. Уверен, что такой ООП будет очень похож на ООП на С.
Он будет похож на си если эмулировать мейнстримный ООП, если нет он будет похож на обычное использование модулей и типов.
ОО будет при этом только в дизайне, реализация же адекватными средствами языка.
VD>И хотелось бы видеть именно реализацию на ML, а не OCamle, где какой ни какой ООП поддерживается.
VD>Не. Геморрой он в заднице у тех, то реализует на чистых ФЯ проекты спроектированные в ОО-стиле.
Ну ни ML ни тем более OCaml не чистые функциональные языки.
Да и тот же ML вполне объектно ориентированный язык, конечно его ОО не совпадает с майнстримным,
но необходимый минимум (который больше чем минимум из си ) он поддерживает.
VD>ЗЫ
VD>А почему бы просто не выбрать язык который одновременно хорошо поддерживает и ФП и ООП? Не уж то решение на нем будет хуже чем эмуляция?
Так я выбрал OCaml, в нем есть полноценное ООП, смотрел примеры достаточно больших программ из них только одна MLDonkey использует
объекты.
Re[64]: Быстро превратить интерпретатор в компилятор
