Здравствуйте, DarkGray, Вы писали:
N_>>Чесно говоря, я не понимаю вопроса. N_>>если есть глобальные для программы данные, которые могут меняться обоими модулями, то модули должны их передавать друг другу по очереди.
DG>Есть глобальные данные, которые меняются и читаются несколькими независимыми модулями.
DG>ps DG>Независимые означает, что модули друг о друге не знают
Но знают об этих глобальных переменных? Вот это и не правильно. Надо обернуть эти глобальные переменны в модуль, которые будет за них "отвечать" и вызывать остальные модули. Кстати, при этом ему тоже не обязательно ничего знать о других модулях, кроме необходимого.
DG>Для больших программ — это подобно смерти, т.к. получается что каждый модуль должен знать обо всех остальных модулях. DG>Получается, что обязательно должен быть человек, которые будет держать в голове все зависимости между всеми модулями.
DG>т.е. фактически не получается модульного программирования
Это уже вопрос проектирования, а не языка. Мне кажется, что задача которую вы ставите сама по себе неправильна. Нельзя делать глобальную переменную, которую меняют все кому не поподя. Кривая программа на императивном языке будет сложна для функционального из-за своей кривости, а не потому что функциональные языки плохие.
Nick_ -> "Re[10]: Где у ФЯ матчасть?" :
N> Я уже писал. N> новая_машина = одеть(починить(снять(машина)))
Машина, которую уже чинили != новая Опять же, каждый экземпляр машины
обладает уникальными идентификационными номерами.
Yury Kopyl aka hrg | http://id.totem.ru |
"Если ты плюнешь на коллектив — коллектив утрется,
но если коллектив плюнет на тебя — ты утонешь" (С)Баралгин
INT>>>В чисто функциональном стиле это тоже делается. Даже более изящно. Как всегда, через монады.
DG>>Чем монады отличаются от объектов?
Q>Поскольку они не имееют ничего общего, ответить на этот вопрос будет сложно.
ИМХО, это ложное утверждение
Объект: характеризуется своим состоянием и операциями над ним.
Монада тоже имеет состояние и тоже имеет некий набор операций над собой.
G>>Я надеюсь, принцип понятен — это можно обобщить до произвольных событий и реализовать подписку.
DG>А где работа с данными? т.е. где видно, что каждый из клиентов получает обновленные данные с сервера?
Ну, это...
Функция OnTick принимает два параметра, один из которых — сервер, а второй — клиент. Оба в актуальном состоянии.
Здравствуйте, DarkGray, Вы писали:
INT>>>>В чисто функциональном стиле это тоже делается. Даже более изящно. Как всегда, через монады.
DG>>>Чем монады отличаются от объектов?
Q>>Поскольку они не имееют ничего общего, ответить на этот вопрос будет сложно.
DG>ИМХО, это ложное утверждение
DG>Объект: характеризуется своим состоянием и операциями над ним.
DG>Монада тоже имеет состояние и тоже имеет некий набор операций над собой.
DG>Так в чем различие?
Мнэ... Видишь ли, не существует единого способа работающего для всех объяснить, что такое монада.
Я серьезно. Это очень жесткая штука. Прикол в том, что даже если объяснить из чего она состоит, все равно ничего понятно не будет. Отсутствие краткого эффективного объяснения понятии монады — одна из главных проблем обучения языку Haskell. Я по крайней мере такового не видел.
Здравствуйте, hrg, Вы писали:
hrg>Nick_ -> "Re[10]: Где у ФЯ матчасть?" :
N>> Я уже писал. N>> новая_машина = одеть(починить(снять(машина)))
hrg>Машина, которую уже чинили != новая Опять же, каждый экземпляр машины hrg>обладает уникальными идентификационными номерами.
Все так. Семантика такая — нет деструктивных изменений.
Здравствуйте, Gaperton, Вы писали:
G>Мнэ... Видишь ли, не существует единого способа работающего для всех объяснить, что такое монада. G>Я серьезно. Это очень жесткая штука. Прикол в том, что даже если объяснить из чего она состоит, все равно ничего понятно не будет. Отсутствие краткого эффективного объяснения понятии монады — одна из главных проблем обучения языку Haskell. Я по крайней мере такового не видел.
Google-time!
Результаты 1 - 10 из примерно 2 360 для What the hell are monads?. (0,19 секунд)
Здравствуйте, DarkGray, Вы писали:
DG>ИМХО, это ложное утверждение DG>Объект: характеризуется своим состоянием и операциями над ним. DG>Монада тоже имеет состояние и тоже имеет некий набор операций над собой. DG>Так в чем различие?
Монада — это "довесок" к твоим собственным вычислениям. Во всяком случае из тех простых примеров, что я видел, можно понимать ее именно так. С ее помощью можно добавить разные дополнительные фичи типа исключений, сбора информации, состояний и т.п. практически не меняя основной так сказать алгоритм.
DG>>Объект: характеризуется своим состоянием и операциями над ним. DG>>Монада тоже имеет состояние и тоже имеет некий набор операций над собой. DG>>Так в чем различие?
Q>Монада — это "довесок" к твоим собственным вычислениям. Во всяком случае из тех простых примеров, что я видел, можно понимать ее именно так. С ее помощью можно добавить разные дополнительные фичи типа исключений, сбора информации, состояний и т.п. практически не меняя основной так сказать алгоритм.
В любом случае, остается один вопрос: если они такие хорошие, зачем они такие сложные?
Почему их нельзя представить в более простом и понятном виде для программиста?
Здравствуйте, DarkGray, Вы писали:
DG>В любом случае, остается один вопрос: если они такие хорошие, зачем они такие сложные? DG>Почему их нельзя представить в более простом и понятном виде для программиста?
Если их использовать, не задаваясь вопросом, как они работают, то они не сложные. А сложность понимания их сущности обусловленна тем, что они практически буквально выдраны из теории категории, где есть прямой их аналог. А теория категорий одна из самых абстрактных теорий в математике, что, правда говоря, не означает, что она очень сложная. Просто в нее надо долго врубаться, чтобы понять как и что там устроено, привыкнуть к ней.
Почему вдруг теория категорий? Дело в том, что она претендует на роль основания всей математики. В ней можно выразить лямбда-исчисление, формальную логику, логику предикатов частично даже и еще бог знает что. Поэтому создатели(ль) монад искали естественный способ внести императивные фичи в ФЯ так, чтобы тот оставался самим собой и можно было бы доказывать всякие теоремы и т.п. Естественно, что они использовали для этого ТК, которая идеологически очень близка ФП.
Это не значит, что чтобы понять монады, надо учить ТК. Просто ввиду некоторой их абстрактности сразу принцип работы с ними понять нелегко. Тут нужно использовать метод просветления — изучать все возможные примеры, пока не дойдет их смысл.
Здравствуйте, Quintanar, Вы писали:
Q> Поэтому создатели(ль) монад искали естественный способ внести императивные фичи в ФЯ так, чтобы тот оставался самим собой и можно было бы доказывать всякие теоремы и т.п. Естественно, что они использовали для этого ТК, которая идеологически очень близка ФП.
Добавлю пять копеек. Возникает вопрос — почему просто не разрешить операции с побочными эффектами? Т. е. просто взять, и не добавить в ФЯ нормальные императивные фичи, без всяких монад?
Такие языки есть. Но проблема в том, что тогда перестанут быть безопасными ленивые вычисления. Монады же позволяют реализовать императивные возможности не привнеся при этом в язык побочных эффектов. Магия.
Монады — не единственный выход. Второй подход — uniqueness typing, примененный в языке Clean, который обладает двумя преимуществами перед монадами:
1) Позволяет без особых усилий генерировать эффективный код, не проигрывающий императивным вариантам. С монадами это нетривиально. Массивы и ввод/вывод в языке Clean сравним по эффективности с императивными языками.
2) Интуитивно понятен, в отличии от монад. Все просто — вы помечаете аргумент функции звездочкой, и компилятор проверяет, что на него него не остается ссылок после вызова. А раз ссылка на него единственна, то можно делать модифицирующие операции.
Здравствуйте, DarkGray, Вы писали:
DG>Пример: DG>Возьми ключ, и сними переднее колесо.
DG>Конструкция, по сути, императивная.
Да ты чё? Щаз к твоему предложению приделают функции высшего порядка и окажется, что ты писал о псих-больнице, так как ключ был от шкафа с таблетками, а переднее колесо — это таблетка лежащие с края.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
DG>>Открюченное колесо — это колесо, которое не прикручено к машине. DG>>Сделай так, чтобы переднее колесо было открюченным колесом.
G>{ Колесо, МашинаБезКолеса } = снятьПереднееКолесо( Машина, Ключ ). G>Так лучше?
Вот так полная задница.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не лучше так:
Дама (Д) — У меня колесо проколато надо починить. Сколько мне это будет стоить?...
Слесарь (С) — Извените я раньше матиматиком работал...
Д — И что?
С — Не могли бы вы сформулировать задачу в функциональном стител?
Д — Подлец! Ты на что на что намикаешь? (бьет слесаря по морде).
Это я к тому что инструкции разные бывает. Дама дйствительно не будет описывать набор действий. Он просто опишет проблему. Но опишет она ее хотя и декларативно, но все же не функциональном стиле. Она просто продекларирует свое желание и исходные данные. А уже слесарь обязан будет правильным образом проинтерпретировать их. Даже домыслить их воспользовавшись своим опытом и контестом. И выбрать оптимальный императивный путь решения задачи.
К чему это я все клоню?
Правильно! R#!
Создаем систему деклараций намерений и описания входных данных/предпосылок.
Подбираем наилучшее решение.
Определяем контекст и на его основании выбираем и применяем решение.
А вы говорите функциональные языки...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Перед тем, как продолжить, мы немного отклонимся в сторону теории категорий. Концепция монады была разработана специалистами в теории категории задолго до ее последующего применения в функциональном программировании. Некоторым может показаться удивительным тот факт, что нечто столь абстрактное как теория категорий оказалось полезным в столь конкретной области как программирование. В конце концов, теория категорий в известной степени настолько абстрактна, что не может не быть несколько неудовлетворительной: вся она это одни определения без теорем, практически все можно свести к категории, если достаточно долго поломать над этим голову, сказать, что что-то есть категория, значит не сказать практически ничего. Тоже самое относится и к большинству категорных концепций: они имеют множество возможных воплощений и сказать, к примеру, что нечто есть монада, значит не сказать практически ничего. Столь сильная общность — это одна из причин, почему начинающему так трудно развить хорошую интуицию в теории категории, но это и неудивительно: в конце концов, теория категорий была создана с целью быть теорией всего, каркасом в который можно было бы вставить другие многочисленные математические структуры. Но почему столь абстрактная теория должна иметь какое-либо применение в программировании?
Ответ прост: как специалисты в CS мы ценим абстракции! Когда мы разрабатываем интерфейс к програмному компоненту, мы хотим, чтобы он скрывал как можно больше деталей реализации. Мы хотим, чтобы у нас была возможность заменить текущую реализацию на другие возможные альтернативы, многие другие реализации той же самой 'концепции'. Если мы разрабатываем общий интерфейс для библиотек, то возможность выбора из множества реализаций становится еще более важной. Именно высокую общность 'концепции' монад мы оцениваем так высоко, именно потому что теория категорий столь абстрактна, ее концепции оказываются столь полезными в программировании.
Здравствуйте, Павел Леонов, Вы писали:
ПЛ>Здравствуйте, Quintanar, Вы писали :
Q>> Кстати, интересная цитата из статьи Hughes'а:
ПЛ>Хоть парочку ссылочек бы на теорию категорий, в инете искал, но там больше около теорные статьи, прямого материала найти не удалось.
а потом существует просто немеренно количество людей, рассылок и журналов по разным приложениям, нужно просто последний линк немного поменять, только вот что это даёт? эта теория нужна разве только нужно разрабатывать свой язык программирования, а их и так уже норъмалъно.
Опять же, каждый экземпляр машины
