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

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

Здесь речь уже не о конкретных языках, а о парадигмах. Функциональная, ООП и т.п. И у них, как оказывается, совсем разная ситуация с инструментами.

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

Да, UML используется не только в программирование. Как раз поэтому там так много видов диаграмм, а непосредственно в программирование обычно используется только 3-5 их видов. Так вот, если мы попробуем использовать их при программирование в функциональном стиле, то увидим что ничего хорошего не выходит. Самая популярная диаграммка классов (на ней же часто рисуют и пакеты) не лезет никак. А именно с помощью этой диаграммы обычно получается "уменьшать сложность". Диаграмма объектов тогда естественно тоже не при делах, хотя она и не такая нужная. Диаграммки последовательности (для понимания взаимодействия) и деятельности (для понимания алгоритмов) хороши для императивного кода, так что в контексте чистого функционального языка тоже мимо (разве что для внутримонадного кода в случае Хаскеля и то криво). Что там остаётся то? Разве что диаграмма компонентов нормально ложится, и то она слишком высокоуровневая для эффективного уменьшения сложности.

А вместо всего этого, специалисты по функциональному подходу предлагают нам использовать просто концептуальные схемы (concept map), т.е. при переходе на функциональную парадигму мы получаем откат в инструментах проектирования-моделирования на десятилетия назад.

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

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

_>Здесь речь уже не о конкретных языках, а о парадигмах. Функциональная, ООП и т.п. И у них, как оказывается, совсем разная ситуация с инструментами.

То есть, ты не готов обсуждать языки, а хочешь перепрыгнуть на внешние инструменты ?

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

_>Да, UML используется не только в программирование. Как раз поэтому там так много видов диаграмм, а непосредственно в программирование обычно используется только 3-5 их видов. Так вот, если мы попробуем использовать их при программирование в функциональном стиле, то увидим что ничего хорошего не выходит.

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

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

Да запросто. Надо понимать, что ты за задачу хочешь решать. Если писать код с помощью UML, то это уже двадцать лет как отказались делать.

> А именно с помощью этой диаграммы обычно получается "уменьшать сложность".

Весь UML нужен для "уменьшать сложность", а не одна только диаграмма классов.

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

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

>(разве что для внутримонадного кода в случае Хаскеля и то криво). Что там остаётся то? Разве что диаграмма компонентов нормально ложится, и то она слишком высокоуровневая для эффективного уменьшения сложности.

То есть, ты хотел писать код UMLом, не вышло. Странно, и на С++ та же фигня получается. UML давно перестали использовать так, как ты предлагаешь.

_>А вместо всего этого, специалисты по функциональному подходу предлагают нам использовать просто концептуальные схемы (concept map), т.е. при переходе на функциональную парадигму мы получаем откат в инструментах проектирования-моделирования на десятилетия назад.

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

I>То есть, ты не готов обсуждать языки, а хочешь перепрыгнуть на внешние инструменты ?

Мы тут обсуждаем в основном парадигмы. А в этом контексте интересны и языки (поэтому часто Хаскель всплывает, как редкий пример чистого ФЯ) и инструменты и всё остальное.

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

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

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

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

Он для проектирования (в том числе). А проектированием занимаются уже с учётом предполагаемых к использования парадигм.

I>Да запросто. Надо понимать, что ты за задачу хочешь решать. Если писать код с помощью UML, то это уже двадцать лет как отказались делать.

Причём тут генерация кода? ) Или ты хочешь сказать, что типа генерации Haskell кода по диаграмме классов нет, а вот инструмент для рисования диаграммы классов по готовому Haskell коду существует? )))

I>

Что такое? ) Концептуальные схемы — это инструмент из которого вырос и UML и множество других инструментов. Но это всё зарождалось в 70-ые годы прошлого века. Рекомендовать его для программирования во втором десятилетие 21-го века можно только от полной безысходности (отсутствия каких либо продвинутых специализированных инструментов). А именно это и делают кругом любители функциональщины. И в обсуждаемой здесь статье с хабра (http://habrahabr.ru/post/211871/) автор этим занимается и в других местах тоже самое http://stackoverflow.com/questions/2457903/can-uml-be-used-to-model-a-functional-program...

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

_>Мы тут обсуждаем в основном парадигмы. А в этом контексте интересны и языки (поэтому часто Хаскель всплывает, как редкий пример чистого ФЯ) и инструменты и всё остальное.

Для инструментов создай отдельный топик

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

А мне вот больше С++ кажется ущербным

_>А вот с твоей позицией "чем ближе код к функциональному стилю, тем он выше уровнем" я точно не могу согласиться. Это именно разные стили, а не разные уровни.

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

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

Ты ничего не продемонстрировал Архитектура это не рисование квадратов в UML, как то так. Сильно вряд ли хаскель будет работать с БД как то отлично от того, как это делают другие средтсва.

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

_>Он для проектирования (в том числе). А проектированием занимаются уже с учётом предполагаемых к использования парадигм.

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

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

I>>Да запросто. Надо понимать, что ты за задачу хочешь решать. Если писать код с помощью UML, то это уже двадцать лет как отказались делать.

_>Причём тут генерация кода? ) Или ты хочешь сказать, что типа генерации Haskell кода по диаграмме классов нет, а вот инструмент для рисования диаграммы классов по готовому Haskell коду существует? )))

Ты хочешь программировать с помощью UML на хаскеле

I>>

_>Что такое? ) Концептуальные схемы — это инструмент из которого вырос и UML и множество других инструментов. Но это всё зарождалось в 70-ые годы прошлого века. Рекомендовать его для программирования во втором десятилетие 21-го века можно только от полной безысходности (отсутствия каких либо продвинутых специализированных инструментов). А именно это и делают кругом любители функциональщины. И в обсуждаемой здесь статье с хабра (http://habrahabr.ru/post/211871/) автор этим занимается и в других местах тоже самое http://stackoverflow.com/questions/2457903/can-uml-be-used-to-model-a-functional-program...

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

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

I>Я говорю про близость к математике, а тебе мерещится чтото другое.

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

I>Ты ничего не продемонстрировал Архитектура это не рисование квадратов в UML, как то так. Сильно вряд ли хаскель будет работать с БД как то отлично от того, как это делают другие средтсва.

UML вполне себе помогает в проектирование архитектуры.

А причём тут БД? ) Кстати, я конечно не в курсе деталей, но подозреваю, что в случае Хаскеля там будет сплошной монадный ужас.

I>Ты хочешь программировать с помощью UML на хаскеле

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

Для случая ООП языков я таких инструментов знаю не мало.

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

I>>Я говорю про близость к математике, а тебе мерещится чтото другое.

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

_>А причём тут БД? ) Кстати, я конечно не в курсе деталей, но подозреваю, что в случае Хаскеля там будет сплошной монадный ужас.

conn <- connectSqlite3 "test.db"

result <- quickQuery' conn "SELECT id, desc from test where id <= ? ORDER BY id, desc" [toSql maxId]

Ужос !


I>>Ты хочешь программировать с помощью UML на хаскеле

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

Это одни и те же инструменты. Если не задаваться целью программировать на UML, то получается примерно одно и то же.

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

I>>Я говорю про близость к математике, а тебе мерещится чтото другое.

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

В общем ты никак не можешь сформулировать, что же такое уровень языка. О том, что в разных парадигмах есть языки разных уровней, напоминать не надо. Нужно взять да посмотреть, чем отличается императивный питон от императивного ассемблера или от императивного С++. Внезапно — питон ближе к математике чем два других.

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

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

I>Ужос !

О, как я и думал монадный ужас.

I>Это одни и те же инструменты. Если не задаваться целью программировать на UML, то получается примерно одно и то же.

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

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

I>В общем ты никак не можешь сформулировать, что же такое уровень языка. О том, что в разных парадигмах есть языки разных уровней, напоминать не надо.

ОК, хоть в чём-то договорились. )

I>Нужно взять да посмотреть, чем отличается императивный питон от императивного ассемблера или от императивного С++.

Ууу там много чего.

I>Внезапно — питон ближе к математике чем два других.

Каким это местом?

I>С функциональщиной примерно так же — там нат никакой железячной специфики. За счет этого она будет уровнем повыше С++. Вот если в будущем изобретут язык "как С++" но с полноценной реализацией всех функциональных возможностей, тогда можно будет пересмотреть сказаное

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

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

I>>Ужос !

_>О, как я и думал монадный ужас.

Не заметил, просто другой синтаксис, не такой как в С++

I>>Это одни и те же инструменты. Если не задаваться целью программировать на UML, то получается примерно одно и то же.

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

Эти инструменты не создавались для языков. Они создавались для моделирования и проектирования. Что и объясняет, почему туда перекочевали вещи, которые используются в областях далёких от разработки.

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

I>>Внезапно — питон ближе к математике чем два других.

_>Каким это местом?

Тем самым. ООП и обобщенное программирование в ём гораздо сильнее плюсового, а как ООП относится к математике, тебе показал Синклер.

I>>С функциональщиной примерно так же — там нат никакой железячной специфики. За счет этого она будет уровнем повыше С++. Вот если в будущем изобретут язык "как С++" но с полноценной реализацией всех функциональных возможностей, тогда можно будет пересмотреть сказаное

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

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

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

I>Не заметил, просто другой синтаксис, не такой как в С++

Просто тут не видно всей монады. )))

I>Эти инструменты не создавались для языков. Они создавались для моделирования и проектирования. Что и
объясняет, почему туда перекочевали вещи, которые используются в областях далёких от разработки.

Ещё раз: "проектировать и моделировать" надо с учётом особенностей используемого для программирования языка. Так вот если мы возьмём чистый функциональный язык, то увидим, что наш инструмент для "проектирования и моделирования" резко теряет свои возможности.

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

I>Тем самым. ООП и обобщенное программирование в ём гораздо сильнее плюсового, а как ООП относится к математике, тебе показал Синклер.

С чего бы это в Питоне сильнее ООП и обобщённое программирование (а где оно там вообще в Питоне)?

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

I>>Не заметил, просто другой синтаксис, не такой как в С++

_>Просто тут не видно всей монады. )))

Ну как обычно — вот здесь всё хорошо, а вот в той части, что не показана — ужос-ужос !

I>>Эти инструменты не создавались для языков. Они создавались для моделирования и проектирования. Что и
_>объясняет, почему туда перекочевали вещи, которые используются в областях далёких от разработки.

_>Ещё раз: "проектировать и моделировать" надо с учётом особенностей используемого для программирования языка. Так вот если мы возьмём чистый функциональный язык, то
увидим, что наш инструмент для "проектирования и моделирования" резко теряет свои возможности.

Ну да, протокол single-side авторизации внезапно начнет зависеть от того, на каком языке он реализован. Вот чудо !

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

I>>Тем самым. ООП и обобщенное программирование в ём гораздо сильнее плюсового, а как ООП относится к математике, тебе показал Синклер.

_>С чего бы это в Питоне сильнее ООП и обобщённое программирование (а где оно там вообще в Питоне)?

С того, что там динамический полиморфизм, мультиметоды и много чего еще.

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

I>С того, что там динамический полиморфизм, мультиметоды и много чего еще.

Динамический полиморфизм есть наверное в любом ООП языке)))

Мультиметодов в самом Питоне нет. Но их можно реализовать в виде библиотеки. Так же как и в C++.

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

I>>С того, что там динамический полиморфизм, мультиметоды и много чего еще.

_>Динамический полиморфизм есть наверное в любом ООП языке)))

Ога. Только возможности отличаются на порядки.

_>Мультиметодов в самом Питоне нет. Но их можно реализовать в виде библиотеки. Так же как и в C++.

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

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

I>Ога. Только возможности отличаются на порядки.

Например?

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

I>>Ога. Только возможности отличаются на порядки.

_>Например?

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

То есть, всё как завещал изобретатель ООП сэр Алан Кей (у которого ООП в с++ вызвало глубокое недоумение).

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

I>Например попробуй реализовать такое — вызвать несуществующий метод у объекта. Разумеется, безо всяких исключений и тд и тд.

I>То есть, всё как завещал изобретатель ООП сэр Алан Кей (у которого ООП в с++ вызвало глубокое недоумение).

И?

В C++ будет ошибка времени компиляции, а в Питоне будет ошибка времени исполнения. В чём разница? )