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

Q>Синтаксис C++ страшен, но опыт вынужденного написания своих замыканий или комбинаторов упрощает понимание реализации «этих концепций». Это позволяет делать правдоподобные априорные заключения о скорости и асимптотической сложности вычислений, о специфике взаимодействия с GC и ресурсами системы, и многих других вещей.

Ты помнишь, вообще, о чём был мой первый пост в этой теме? Прочти его пожалуйста снова. Я там говорил явно не о реализации концепций. Мало того есть серьёзные сомнения, что реализация замыканий и комбинаторов на С++, поможет определить сложность вычислений и потребление ресурсов в языке с GC. А то как устроены замыкания хорошо сказано в SICP причём в описании вычислительной модели.

Мой поинт в том, что чтоб лучше понять ФП(да и любую другую парадигму), нужно использовать языки синтаксис которых меньше всего отвлекает от семантики изучаемых приёмов. А уж привычен этот синтаксис или нет дело десятое. А если тебе нужно оценивать раелизацию, то лучше обратиться к разработчикам компилятора или другим гуру разбирающимся в тонкостях, которые знают как устроено и подскажут узкие места (хотя тут и профайлер может помочь), а не пытаться проводить параллели между 2-мя совершенно разными языками.

ЗЫ Вспомнились языки APL, K, J. Я на них никогда, ничего не писал, и даже не вникал в концепции заложенные в них. Интересно их синтаксис помогает?

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

L>Согласен — нечего здесь сравнивать, абсолютно аналогично

L>

L>map (\foo -> bars ! name foo) foos
L>

Такая запись мне больше нравится чем две предыдущие. Но прочитать её можно, только если знаешь, что там написано. Неподготовленного человека это поставит в тупик секунд на 30.

L>Это далеко не весь ФП :)

Я знаю. Я отдаю себе отчёт в том, что как функциональный язык Хаскель мощнее Шарпа. Но этот синтаксис меня убивает...

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

LP>>>>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
T>>>>>Тебе гибкость иметь или программу писать?
LP>>>>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.
T>>>Кого не устраивает?
LP>>Пока — меня. Потом будет не устраивать пользователей.

T>Ladies and gentleman!

T>Here we have an extremely revealing case of premature optimization!

В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.

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

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

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

IT>И как, интересно, знание разных предметных областей помогает в освоении того же ФП? Как мне в этом поможет, ну скажем, написанный отчёт по заработной плате?

Предполагается, что написав отчет по своей заработной плате, ты ужаснешься ее размерами и срочно пойдешь учить ФП, чтобы увеличить производительность и зарабатывать больше.

E>>>Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?
T>>Не могу никак ограничивать ваше понимание моих слов.
E>Очень отрадно, что вы сторонник "свободы сновидений". Однако, очень бы хотелось узнать именно ваш вывод.

Мой "вывод" такой: настоящий опыт даёт разнообразие предметных областей. Чем больше их перебрано за карьеру, тем лучше. Наиболее выразительный язык даёт возможность справляться с очередной областью быстрее всего. Далее — ваш выбор.

Хотя это не вывод, это тезис. Посылка.

E>>>Гораздо сложнее, на мой взгляд, ответственное отношение к работе, которая не так увлекательна, как создание собственного компилятора.
T>>Написание таких слов — оно ведь создаёт внутри такое тёплое приятное чувство, так?
E>Нет.

А зачем тогда это писать?

Мы, вроде, люди все взрослые, все умеем относиться к работе ответственно, нам об этом напоминать не надо.

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

"Я скажу это потому, что мне нравится так говорить. Мне нравится, когда все знают, что я так думаю."

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

T>>Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?
E>Это не нужно проверять. Так же, как понятие "здравого смысла", который либо присутствует в той или иной степени, или отсутствует напрочь. Так же, как и понятие "вкуса". И это все при том, что программистам требуется в работе как одно, так и второе.

Любой выбор программиста может быть оценён. Это и есть критерий проверки.

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

E>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?

Псевдодилемма подсунута довольно ловко. Я оценил.

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

Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.

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

А за счёт чего? За счёт того, что он предусмотрел что-то для вашего использования ("здравый смысл", "чувство локтя"). За счёт того, что его решения стройны и легко расширяются ("вкус").

Причём проверку стройности решения организовать очень легко.

E>>>Сильно сомневаюсь, что ФП здесь имеет какое-то преимущество перед ИП, и что стиль программирование здесь вообще имеет хоть какое-то значение.
T>>Стиль программирования исходной системы, конечно же, имеет значение. В случае ФП нам гарантирован фиксированный объём изменений и фиксированный объём мест, где могут появиться внесённые ошибки. Nes pa?
E>Очень наивная точка зрения, имхо.

(на всякий случай: вы разговариваете с человеком, немало пописавшем в обеих стилях и имеющим базу для сравнения.)

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

T>>>>Кого не устраивает?
LP>>>Пока — меня. Потом будет не устраивать пользователей.
T>>Ladies and gentleman!
T>>Here we have an extremely revealing case of premature optimization!

LP>В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.

Да ты что!

Тебе о производительности ещё никто не сказал, а ты уж вовсю профайлером машешь!

Что это, как не преждевременная оптимизация?

T>>Для программиста знание языков и внутренностей важно, но не менее (а то и более) важно уметь программировать для разных предметных областей. И чем больше их будет, тем лучше.
IT>И как, интересно, знание разных предметных областей помогает в освоении того же ФП? Как мне в этом поможет, ну скажем, написанный отчёт по заработной плате?

Там чуть дальше следующее:

от и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например.

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

Какой язык, какая проблема — меня, как шерифа, это не волнует.

L>>Как думаешь, стоит показывать начинающему в ФП, или примем за факт, что он и то и другое поймёт?
Q>То, что он код на Хаскеле не поймёт — это факт. А вот код типа
Q>

Q>var bars = foos.Select(foo => map[foo.Name]);
Q>

Q>поймёт с большой вероятностью.

Хаскельные "понимания списков" представляют собой кальку с синтаксиса теории множеств.

B={x|x∈B, P(x)}

(почему RSDN не понял ∈?..)

Мой знакомый, увидев пример "понимания списков", взвизгнул от восторга и убежал моделировать какую-то там систему знаний с теоретико-множественным подходом.

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

T>Хаскельные "понимания списков" представляют собой кальку с синтаксиса теории множеств.

T>B={x|x∈B, P(x)}

О, такое мне нравится. Не распознал сразу в коде эти comprehensions.

T>(почему RSDN не понял ∈?..)

HTML entities — зло. Коды, впрочем, тоже. Литералы предпочтительнее, имхо.

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

T>Мой "вывод" такой: настоящий опыт даёт разнообразие предметных областей. Чем больше их перебрано за карьеру, тем лучше. Наиболее выразительный язык даёт возможность справляться с очередной областью быстрее всего. Далее — ваш выбор.

Приходилось ли вам писать программы для бухгалтерии или для складского учета?

T>А зачем тогда это писать?

T>Мы, вроде, люди все взрослые, все умеем относиться к работе ответственно, нам об этом напоминать не надо.

T>Поэтому единственный вариант, когда вот так, без подталкивания со стороны собеседника начинают говорить об ответственности, это вариант с приятным тёплым внутренним чувством.

Очень просто: одним из стимулов для разработчика является его собственная увлеченность в том, чем он занимается. Поэтому если одного и того же человека посадить писать компилятор или GUI формы для системы складского учета, то очень легко можно получить существенно результаты работы (в скорости разработки и качестве продукта) даже при ответственном отношении к делу. И, к сожалению, степень ответственности разработчика так же сильно зависит от того, нравится ли ему его текущее задание или нет.

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

T>>>Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?
E>>Это не нужно проверять. Так же, как понятие "здравого смысла", который либо присутствует в той или иной степени, или отсутствует напрочь. Так же, как и понятие "вкуса". И это все при том, что программистам требуется в работе как одно, так и второе.

T>Любой выбор программиста может быть оценён. Это и есть критерий проверки.

Можете продемострировать, как оценить, например, выбор имен переменных/методов? В Ruby, например, есть метод to_a для преобразования значения в массив. В других языках аналогичный метод было бы принятно называть toArray или ToArray. Как оценить, какое из них является лучшим?

E>>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?

T>Псевдодилемма подсунута довольно ловко. Я оценил.

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

T>Я разделяю достаточно общепринятый взгляд, что "лучшая" вещь обычно означает экономию времени.

T>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.

Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.

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

В последнее время я думаю, что хороший программист -- это предсказуемый программист. Если говорит, что сделает к такому-то сроку, то делает (или укладывается в стабильную дельту времени). И если говорит, что протестировал свой код -- значит действительно протестировал. Заметен ли он в остальное время, удивляет ли чем-то -- это уже бытовые мелочи.

T>(на всякий случай: вы разговариваете с человеком, немало пописавшем в обеих стилях и имеющим базу для сравнения.)

T>Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.

Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?

Или еще одна ситуация. Прикладная система состоит из нескольких частей. Первая часть генерирует большие текстовые файлы (например, в csv-формате). Вторая часть импортирует их в РСУБД. Обе части написаны на разных языках и работают на разном железе. Некоторые из столбцов в РСУБД имеют ограничения на размер. В первую часть вносятся изменения, при которых значения в текстовых файлах могут оказаться на один-два символа длинее, чем соотвествующие столбцы в РСУБД. Чем здесь поможет ФП?

T>>Мой "вывод" такой: настоящий опыт даёт разнообразие предметных областей. Чем больше их перебрано за карьеру, тем лучше. Наиболее выразительный язык даёт возможность справляться с очередной областью быстрее всего. Далее — ваш выбор.
E>Приходилось ли вам писать программы для бухгалтерии или для складского учета?

Да. Два раза, полгода и год я на это потратил. dBaseIV и тикль.

T>>А зачем тогда это писать?
T>>Мы, вроде, люди все взрослые, все умеем относиться к работе ответственно, нам об этом напоминать не надо.
T>>Поэтому единственный вариант, когда вот так, без подталкивания со стороны собеседника начинают говорить об ответственности, это вариант с приятным тёплым внутренним чувством.
E>Очень просто: одним из стимулов для разработчика является его собственная увлеченность в том, чем он занимается. Поэтому если одного и того же человека посадить писать компилятор или GUI формы для системы складского учета, то очень легко можно получить существенно результаты работы (в скорости разработки и качестве продукта) даже при ответственном отношении к делу. И, к сожалению, степень ответственности разработчика так же сильно зависит от того, нравится ли ему его текущее задание или нет.
E>Поэтому не нужно приводить в пример такие задачи, как разработка компиляторов. Многие из здесь присутствующих, наверное, хотело бы заниматься разработкой компляторов. Только это все равно невозможно, т.к. нафиг никому не нужно такое количество разработчиков компиляторов.

О!.. Я понял. Переформулируем.

Один может два месяца возиться с реализацией замыканий на C++, тогда как выгодней сделать за те же два месяца всю программу складского учёта. И получить полезные знания, как то — динамическое программирование при планировании загрузки стеллажей. Может, что-то ещё. Но уж точно — отточить своё мышление в ФП стиле, вместо MPD стиля "ФП на C++".

И удачно завершив проект, приступить, наконец, к разработке компилятора!

E>>>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?
T>>Псевдодилемма подсунута довольно ловко. Я оценил.
E>Боюсь, вы нашли в моих словах не то, что я хотел сказать. Просто читая ваши сообщения у меня складывается впечатление, что вы приверженец детерминизма. Это проявляется даже в вашем интересе к зависимым типам.

Я приверженец "поменьше работать". Детерминизм вы за меня придумали.

T>>Я разделяю достаточно общепринятый взгляд, что "лучшая" вещь обычно означает экономию времени.
T>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.
E>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.

Ваш логический вывод "в моей логике" мне недоступен, надо отметить.

T>>(на всякий случай: вы разговариваете с человеком, немало пописавшем в обеих стилях и имеющим базу для сравнения.)
T>>Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.
E>Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?

Напомню, что я первый высказал просьбу.

Тем не менее — fudgets. Точнее, их stream processors.

Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.

Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.

Вот ваш вариант:

    +-+ +-+
----|B|-|M|----> куда-то на
    | | +-+  +-> мультиплексор
    | |      |
    | |------+
    +-+

Вот вариант с чисто функциональной прокладкой:

    +-+ +-+ +-+
----|B|-|M|-| |---> куда-то на...
    | | +-+ | |
    | |     | |
    | +-----+ |
    |         |
    +---------+

То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.

E>Или еще одна ситуация. Прикладная система состоит из нескольких частей. Первая часть генерирует большие текстовые файлы (например, в csv-формате). Вторая часть импортирует их в РСУБД. Обе части написаны на разных языках и работают на разном железе. Некоторые из столбцов в РСУБД имеют ограничения на размер. В первую часть вносятся изменения, при которых значения в текстовых файлах могут оказаться на один-два символа длинее, чем соотвествующие столбцы в РСУБД. Чем здесь поможет ФП?

Оба-на! Вторая просьба.

Я оценил перевод стрелок, да.

Поэтому напомню про то, что простая вежливость (да даже просто предсказуемость — здесь, ожидаемое умение отвечать за свои слова) должна была толкнуть вас на ответ мне первому. Напомню, что вы сочли моё мнение о том, что если система написана в стиле ФП, то её изменения более предсказуемы, наивным. Я же попросил вас показать, откуда может возникнуть непредсказуемость изменений.

С напоминаниями всё, надеюсь, они не пропадут втуне. Перейду к вашему примеру. И скажу ровно одно слово: КОДОГЕНЕРАЦИЯ. По единой спецификации.

Подойдёт?

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

T>>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.
E>>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.

T>Ваш логический вывод "в моей логике" мне недоступен, надо отметить.

Если интерфейс настолько прост, что позволяет быстро приступить к работе, то это вовсе не означает что он будет настолько же хорошо экономить время в дальнейшем. Доказательством чего служат редакторы ViM и Emacs (а так же LaTeX) -- где нужно потратить изрядное время на первые шаги (т.е. длительное время без полезной работы вообще), зато потом это компенсируется более эффективной работой.

T>>>Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.
E>>Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?

T>Напомню, что я первый высказал просьбу.

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

T>С напоминаниями всё, надеюсь, они не пропадут втуне. Перейду к вашему примеру. И скажу ровно одно слово: КОДОГЕНЕРАЦИЯ. По единой спецификации.

T>Подойдёт?

Нет. Наличие единой спецификации -- это организационный вопрос. К языкам программирования и используемым парадигмам он не имеет отношения. Собственно, как и кодогенерация, которая прекрасно может быть сделана как на ИЯ, так и на ФЯ.

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

T>Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.

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

T>Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.

Вообще-то это не побочный эффект -- это ее цель.

T>Вот вариант с чисто функциональной прокладкой:
T>

T>    +-+ +-+ +-+
T>----|B|-|M|-| |---> куда-то на...
T>    | | +-+ | |
T>    | |     | |
T>    | +-----+ |
T>    |         |
T>    +---------+
T>

T>То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.

Этот вариант требует от B "протягивания" через себя большого количества сообщений, которые обрабатывает M, но о которых не имеет понятие B. Что создает лишнюю зависимость. Фактически, B должен поддерживать весь "внешний интерфейс" компонента M.

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

  --- D ---
 /          \
M ---- B --- S
 \          /
  -- T - Y -

Где D обрабатывает свой поток сообщений, B свой, T и Y -- свой. А компоненты M и S даже не подозревают, об их существовании.

Подход с параметризацией означал бы, что система приняла бы вид:

M - T - Y - D - B - S

где каждый следующий элемент бы предыдущим. И изменения потока данных между M и S по линии T-Y означала бы необходимость адаптации к этим изменениям еще и D, и B.

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

Ошибся:

E>где каждый следующий элемент бы предыдущим.

следует читать как "следующий элемент был бы связан с предыдущим".

T>>>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.
E>>>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.
T>>Ваш логический вывод "в моей логике" мне недоступен, надо отметить.
E>Если интерфейс настолько прост, что позволяет быстро приступить к работе, то это вовсе не означает что он будет настолько же хорошо экономить время в дальнейшем. Доказательством чего служат редакторы ViM и Emacs (а так же LaTeX) -- где нужно потратить изрядное время на первые шаги (т.е. длительное время без полезной работы вообще), зато потом это компенсируется более эффективной работой.

Вам что, трудно вообразить интерфейс, который 1) позволяет быстро приступить к работе и 2) не мешает работе в дальнейшем?

Есть у меня обоснованное подозрение, что вы оперируете двумя выводами "трудно в учении => легко в бою" и "легко в учении => трудно в бою", необоснованно их считая их эквивалентными (ну, считая, что так бывает наиболее часто).

Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно. Да вот, блин, Vertu с его одной универсальной кнопкой.

Как раз для экономии любого отрезка времени пользователя.

(тут дальше следуют интересные выводы, которые мы опустим)

T>>>>Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.
E>>>Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?
T>>Напомню, что я первый высказал просьбу.
E>Для того, чтобы показывать системы на ФЯ их нужно видеть, а еще лучше иметь в своем распоряжении. Я таковых в своем распоряжении не имею. Но, мой второй пример с импортом данных в РСУБД совершенно безразличен к языку программирования, на котором реализованы компоненты системы.

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

Что это доказывает?

T>>Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.
E>Меня больше интересует вопрос о том, есть ли какие-то средства в каком-то языке, которые бы смогли описать существующий контракт. Как и что перепроектировать -- здесь вариантов туева хуча.

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

По-моему, это слегка по-детски, это раз, и ну совсем никак не связано с исходной темой.

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

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

Вам интересно почувствовать себя умным. То самое "тёплое приятное чувство внутри".

"Гляди-ка, Вань, кому я перепроектировать в функциональном стиле запретил!"

Насчёт языков — см. Sing#. Там можно задавать изменения типов объектов после изменения состояния. Например, объект типа Connection перейдёт в объект типа Cinnection:Connected после вызова метода connect. И только тогда станет доступен метод close().

Не функционально, ну и ладно.

T>>Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.
E>Вообще-то это не побочный эффект -- это ее цель.

Для перехвата сообщений от S к M заплатка B должна стоять на входе M. Покажите место, где про это рассказано в вашем изложении задачи. Да даже в вашей схеме (которую я удалил) она стоит на выходе.

А если она стоит не на выходе, а обрабатывает двунаправленное соединение, то это ровно тот вариант, что ф предложил.

T>>То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.
E>Этот вариант требует от B "протягивания" через себя большого количества сообщений, которые обрабатывает M, но о которых не имеет понятие B. Что создает лишнюю зависимость. Фактически, B должен поддерживать весь "внешний интерфейс" компонента M.

Не вижу проблем.

E>Подход с параметризацией означал бы, что система приняла бы вид:
E>

E>M - T - Y - D - B - S
E>

E>где каждый следующий элемент бы предыдущим. И изменения потока данных между M и S по линии T-Y означала бы необходимость адаптации к этим изменениям еще и D, и B.

Это как вы всё это построите. Комбинаторы потоков у Fudgets весьма развесисты.

Давайте попробуем.

Итак, у нас есть комбинатор U (SP i o — потоковый процессор из i в o):

uGateSP :: (SP (Either i o) (Either i o)) -> SP i o -> SP i o
uGateSP gateFunc componentM = ...

gateFunc заплатки B принимает на вход либо Left i — элемент на входе uGate, — либо Right o — элемент с выхода компоненты M. Порождает она либо Left i — вход для M, — либо Right o — выход для uGate.

Полдела у нас есть. Есть обобщённая функция, которая позволяет создавать перекрытия.

Теперь надо создать штуку, которая бы мультиплексировала потоки. Чтобы обработка потока для одной части схемы шло по одному пути, для другой — по другому. Это делается с помощью того же Either outLeft outRight, filterSP и joinSP (слияние потоков). Где есть мультиплексор 1->2, есть и мультиплексор 1->N.

Значение SP i o может быть получено путем частичного применения или соединения потоков "за сценой". Выглядит, как SP i o, а на самом деле работает ещё с каким-то потоком.

Вот пример:

something :: SP i a -> (a -> SP i o) -> SP i o
something input func = ... r ...
    where
        -- r :: SP i o
        r = concatMap func input

Всё вместе даст нам ровно ту схему, что вы описали.

Теперь я жду ответа насчёт нелокальности изменений систем, написанных на ФП.

Если в паре сообщений этого ответа не будет, запишу вас в мелкие трепачи и подожду полового созревания.

Надоело мне что-то в одни ворота играть.

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

T>Поскольку любая попытка внести в разговор необходимые для смены точки зрения изменения наталкиваются на "как и что перепроектировать", я заключаю, что вам неинтересна моя точка зрения.

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

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

T>Насчёт языков — см. Sing#. Там можно задавать изменения типов объектов после изменения состояния. Например, объект типа Connection перейдёт в объект типа Cinnection:Connected после вызова метода connect. И только тогда станет доступен метод close().

Это все не из той оперы. Ситуация, выраженная на объектно-ориентированном языке такова:

class Mailslot { public void sendStateNotification(); ... }
interface SIterface { public queryState(); }
class S implement SInterface {
  // Атрибут, который не меняется с течением жизни объекта.
  protected final Mailslot mailslot;

  S( Mailslot m ) { mailslot = m; }
  public virtual queryState() { mailslot.sendStateNotification(); }
};

Здесь заложено поведение, что в методе S.queryState() _всегда_ вызывается метод sendStateNotification и объекта mailslot, который объект S получает в конструкторе и не может изменить в течении всей жизни. Изменение этого поведения (например, не вызов метода sendStateNotification() или вызов его для другого объекта Mailslot) должно приводить к тому, что остальные модули системы, обращаются к S, не должны даже скомпилироваться. Функциональное программирование как-нибудь решает эту проблему?

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

T>Теперь я жду ответа насчёт нелокальности изменений систем, написанных на ФП.

Вы сами уже дали этот ответ:

E>Но, мой второй пример с импортом данных в РСУБД совершенно безразличен к языку программирования, на котором реализованы компоненты системы.

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

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

Я вот не понимаю, если вы настолько уверены в собственной правоте, то зачем подобные выпады в сторону собеседника?

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

T>Вам что, трудно вообразить интерфейс, который 1) позволяет быстро приступить к работе и 2) не мешает работе в дальнейшем?

Да, это редкость.

T>Есть у меня обоснованное подозрение, что вы оперируете двумя выводами "трудно в учении => легко в бою" и "легко в учении => трудно в бою", необоснованно их считая их эквивалентными (ну, считая, что так бывает наиболее часто).

Да, так бывает наиболее часто.

T>Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно.

Под Apple что понимается: MacOS или iPhone? Про iPhone не могу судить, про MacOS неоднократно слышал от опытных людей, что на MacOS сложность решения нестандартных задач (вроде настроек хитрых устройств) очень резко растет вплоть до полной невозможности. В отличии от Windows или Unix-ов.

T>Ну, безразличен. Так он одинаково плохо будет решаться на всём, чём угодно.

T>Что это доказывает?

Что на определенном этапе организационные вопросы гораздо важнее технических. И опытный программист должен в поставленных перед ним задачах разделять технические и организационные составляющие.

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

L>>Честно, не пойму, чем from foo in foos select map[foo.Name] отличается от...
Q>Слова человеческие.

Ясно.

L>>И не надо глупостей про новичков, синтаксис программистам помогать должен программы писать, а не язык учить.
Q>По прежнему не вижу оснований считать синтаксис Хаскеля «помогающим».

Итак мы программируем с ФП стиле. Как Haskell помогает нам в этом?

1. Очень простое описание ФВП.

foo f x = g (f x)

или даже просто

foo x y = f x y

foo — уже ФВП, потому что по дефолту каррирована.

2. Карринг.

Можно смотреть пример выше, можно вот этот:

insertEverywhere x = map (insert x)

Здесь один карринг позволяет получить естественную запись (сравни с _.Map(_.Insert(x))) — "слова человеческие". Второй — записать определение кратко, не принимая во внимание куда именно мы вставляем x (можно сделать запись полностью point-free: insertEverywhere = map . insert, но я предпочитаю более явную запись), что ведёт нас к wholemeal programming и возможность естественно комбинировать функции, не задумываясь над тем, что мы через них пропускаем.

3. Секции, инфиксная запись

Обычно, когда пишешь на Haskell функцию, то последним параметром делаешь тот, который и будет теми данными, что пропускаются через цепочку функций. Например, при вставке в коллекцию это будет сама коллекция, а не элемент, который мы вставляем в неё. В большинстве случаев поэтому карринга вполне хватает. Однако иногда случается необходимость описать "вставить в что-то", а не "вставить что-то". В этом случае поможет инфиксная запись (`insert` coll). Сюда же секции — это частичное применение операторов, например, (^2) — возвести в квадрат.

Вариант _.Map(_.Insert(x)) более гибкий (см. случай, когда нам нужен третий с конца параметр), но и более многословный. А его гибкость нужна очень редко. В этом случае, в Haskell используют менее удобные лямбды или вложенные функции.

4. Вывод типов или раздельное описание типа и определения.

Тоже сильно помогает, но не знаю, стоит ли это относить к ФП.

5. Ленивость — ура!

Ленивость by default в чистом языке очень сильно помогает писать в ФП стиле. Но это большая (больная) тема.

6. Монады

В Haskell для программирования на монадах, которое используется очень часто, есть специальный синтаксис. Не скажу, что мне это нравится, но писать этот синтаксис помогает. Аналогично есть синтаксис для стрелок.

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

А также паттерн матчинг, ADT/GADT и многое, что я не вспомнил, потому что действительно очень многое подталкивает именно к ФП. Не понимаю, как это можно не видеть?

Теперь ты скажи — а чем же Haskell мешает писать в ФП стиле?

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

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

T>>Поскольку любая попытка внести в разговор необходимые для смены точки зрения изменения наталкиваются на "как и что перепроектировать", я заключаю, что вам неинтересна моя точка зрения.

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

E>Мне не интересно разговаривать про то, что нужно было делать не так с самого начала.

E>Это все не из той оперы. Ситуация, выраженная на объектно-ориентированном языке такова:
E>skipped...
E>Здесь заложено поведение, что в методе S.queryState() _всегда_ вызывается метод sendStateNotification и объекта mailslot, который объект S получает в конструкторе и не может изменить в течении всей жизни. Изменение этого поведения (например, не вызов метода sendStateNotification() или вызов его для другого объекта Mailslot) должно приводить к тому, что остальные модули системы, обращаются к S, не должны даже скомпилироваться. Функциональное программирование как-нибудь решает эту проблему?

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

E>Я вот не понимаю, если вы настолько уверены в собственной правоте, то зачем подобные выпады в сторону собеседника?

Так, стоп.

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

Я правильно понимаю, что если Сергей сейчас не спляшет, и не изменит одну строку (Вами же и указанную (я утрировал)) в императивной системе так, чтобы всё заработало, то Вы типа показали, как "внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений"?