VGn>>Но имхо функция совершенно не канает, как макро-сущность в нематематических задачах.

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

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

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

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

D>>Угу. Между коммуникабельностью и знакомстовом с Excell.

VD>А ты думаешь, что это не важно? По-твоему, важно только кнопки нажимать уметь?

VD>Кому ты нужен в большом проекте если не умешь в Ёкселе табличку слабать с отчеом и не в силах договриться с товарищами и начальством о том, что и как ты будешь делать?

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

это если путать декларативное равенство с присвоением

D>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.

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

D>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.

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

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

D>>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.

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

Вроде сначала речь шла о "задачах бизнес-уровня".
И потом — универсальный DSL для финансового моделирования в гигантской бизнес-структуре это не "большой проект"?

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


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

Теорема Ферма

VGn>>Ты представляешь себе задачу, которую можно решать сотнями высоколобых математиков?
D>Теорема Ферма

И чем в данном отдельно взятом случае сотни математиков эффективнее одного?

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

D>Вроде сначала речь шла о "задачах бизнес-уровня".
D>И потом — универсальный DSL для финансового моделирования в гигантской бизнес-структуре это не "большой проект"?

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

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


VGn>В общем-то, конечно, да, если плясать от IDEF. Но чем больше система, тем менее понятной становится её функциональная модель и сложнее выделять уровни абстракции.
VGn>В этом отношении ООП намного проще и удобнее.

да IDEF(точнее, видимо, имелся в виду IDEF0?) тут ни при чем совершенно. оно даже скорее со своими диаграмками с ящичками и стрелочками работает в духе ОО Проектирования. Точнее, непонятно как.
Проблема с ОО подходом (к проектированию) в том, что никто не знает что это такое и как должно работать. Сколько человек соберется это обсуждать, столько и мнений будет. Потому что не формализировано ничего, никто не знает что такое объект, не говоря уже о проектировании. Отсюда всякая неразбериха с паттернами типами этих объектов — объект-сообщение, объект-прокси, объект-фабрика. На ровном месте. В ФП правда происходит похожая фигня с монадами в последнее время, но те хотя бы строго формальны и слишком далеко не уйдешь.

Я вот вижу ООП так, что ему есть место и есть применения для ряда случаев, как у сущности сопутствующей данным — внешние устройства там представлять, генераторы там всякие. Но уж точно не фабрики и команды.

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

VGn>Хотя знавал я одного айтишника в возрасте, который ооп/а так и не понял и держался зубами за IDEF. Правда всё это служило оправданием макаронному структурному подходу.

Я вот понимал ООП раз 8. Каждый раз по-настоящему. Как-то даже наследование понимал и любил. Неловко признаться.

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


VD>Например, я сталкнулся с нешуточным сопротивлением просто потому, что язык не поддерживается мега-корпорацией вроде МС или Сана. И этих людей можно понять.
VD>Так же я сто раз нарывался на высассанные из пальца утверждения.
VD>С ФП все усложняется практически полным отсуствие учебных материалов приемлемого качества. То что есть нассчитано или на людей с серьезным мат. образованием, или вообще никуда не годятся. Вещей класса "The C programming language" я не видел во все.

Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных. Для ML/Caml полно книжек на любую тему. И все от вполне себе попсовых издательств типа O'Reilly и Addison-Wesley. Для лиспа есть те же Грэм и Сейбел. Это не считая приличного количества самиздата и и всякой вики-блогосферы.
Но дело не в этом. Все же спрос рождает предложение, а не наоборот. Если человек захочет что-то выучить, он это выучит и без кучи книжек. А если не хочет, то хоть обложи его литературой.

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



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


Ну по-моему вопрос императивен или нет ввод-вывод сродни вопросу: вращается ли солнце вокруг земли или наоборот. Правильного ответа не существует — все зависит от системы отсчета и начала координат.
Что же до фанатизма — я бы не называл то, что имеет под собой аргументы фанатизмом. Все же ссылочная прозрачность несет в себе немало выгод. Я даже в последнее время за собой заметил, что для всех задач, где мне реально требуется делать что-то императивное, я делаю на Си, потому что в той же Java от этих всех присваиваний смысл без указателей, их арифметики и goto какой-то не очень большой. 99% этих присваиваний — локальные переменные и подергивание полей в конструкторах и сеттерах. Чудовищно бессмысленная работа, которая выводится за видимость нормальным компилятором. А оставшийся 1% случаев вполне оборачивается во что-нибудь безопасное. Оборачивают же они сейчас работу с буферами в памяти и тому подобное.

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

D>>>>Это не он?

VGn>>>Типа того.

VGn>Немного ошибся (с первого раза не очень внимательно посмотрел).
VGn>Я имел в виду системы по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.

А может оно и не надо? Может ФП (грамотно применяемый) позволяет сократить всю эту кучу народа раз в нцать?

VGn>>Я имел в виду системы по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.

M>А может оно и не надо? Может ФП (грамотно применяемый) позволяет сократить всю эту кучу народа раз в нцать?

Не сократит.
Замена дешёвых кодеров на Разработчиков сократит раза в 2 от силы.
Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.
А значит + ещё 1000 кодеров.
Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
В моём нынешнем проекте из 15 сборок ФП напрашивается толко в 5.
И то — ещё только потому, что на него завязано меньше бизнес-логики и больше системных задач.

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

G>>Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.

Q>С недоверием — это, типа, на сайт даже не зашли? Вообще, странно, пару-тройку лет назад здесь была дискуссия по поводу К, ты же тогда же выступил в его пользу.

Почему — зашли. Только было это очень давно — в районе 2001 года, кажется. До дискуссий о К.

Здравствуйте, VGn, Вы писали:
VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().

palm mute,

VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
PM>Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().

Обожаю калькулятор!

VGn>Не сократит.
VGn>Замена дешёвых кодеров на Разработчиков сократит раза в 2 от силы.
VGn>Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.
VGn>А значит + ещё 1000 кодеров.

Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?

VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.

А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"

Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.

VGn>В моём нынешнем проекте из 15 сборок ФП напрашивается толко в 5.
VGn>И то — ещё только потому, что на него завязано меньше бизнес-логики и больше системных задач.

Ну а в моем нынешнем проекте вообще нет ФП Потому что Coldfusion И о чем это говорит? Ни о чем

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

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


VD>>Например, я сталкнулся с нешуточным сопротивлением просто потому, что язык не поддерживается мега-корпорацией вроде МС или Сана. И этих людей можно понять.
VD>>Так же я сто раз нарывался на высассанные из пальца утверждения.
VD>>С ФП все усложняется практически полным отсуствие учебных материалов приемлемого качества. То что есть нассчитано или на людей с серьезным мат. образованием, или вообще никуда не годятся. Вещей класса "The C programming language" я не видел во все.

Г>Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных.

Странно, но в осле найти их не удалось.

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

Г>>Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных.

L>Странно, но в осле найти их не удалось.

И еще более странно то, что у меня там только что нашлись:
Haskell: The Craft of Functional Programming (2nd Edition) — Simon Thompson
The Haskell Road to Logic, Math and Programming — Kees Doets & Jan van Eijck. В хорошем состоянии
Programming in Haskell (draft, CUP, 2005)(200s) Hutton A.
Портсигар отечественный — два

THSoE нету, да. У меня она, увы, только в бумажном виде.