Re[8]: Быстро превратить интерпретатор в компилятор - Философия программирования

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

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

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

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

T>

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

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

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

Which approach is simpler: the ﬁrst (функциональный) or the second (ООП)? The ﬁrst 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 ﬁrst (функциональный) or the second (ООП)? The ﬁrst 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

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

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

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

	От:	LaPerouse
	Дата:	29.01.10 22:20
	Оценка:

	От:	Temoto
	Дата:	29.01.10 22:57
	Оценка:

	От:	LaPerouse
	Дата:	30.01.10 12:21
	Оценка:

	От:	Temoto
	Дата:	30.01.10 14:12
	Оценка:

	От:	LaPerouse
	Дата:	30.01.10 16:50
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	31.01.10 18:25
Оценка:

	От:	Воронков Василий
	Дата:	01.02.10 13:48
	Оценка: