Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
Интересная статья. Стимулирует читать книги в сноске.
Спасибо.
Кстати говоря, тем, кто впервые сталкивается с функциональным программированием, я бы порекомендовал начинать с этой книги. Даже если Haskell — не тот язык, в котором вы заинтересованы, — ибо в этой книге есть отличные упражнения, сайт с ответами и комментариями пользователей (и вообще вся книга доступна он-лайн по вышеприведённой ссылке) и она учит именно мыслить в стиле ФП.
Кстати говоря, тем, кто впервые сталкивается с функциональным программированием, я бы порекомендовал начинать с этой книги. Даже если Haskell — не тот язык, в котором вы заинтересованы, — ибо в этой книге есть отличные упражнения, сайт с ответами и комментариями пользователей (и вообще вся книга доступна он-лайн по вышеприведённой ссылке) и она учит именно мыслить в стиле ФП.
Да, функциональные языки программирования поворачивают мозги в другую строну.
До некоторой части паттерны это реализация тех вещей, для которых «классический» (тот который был в языках типа явы\с++ в период их зарождения) ООП не очень подходит.
Например паттерн композит — реализация миксинов/трайтов не средствами языка, а «вручную».
Например паттерн композит — реализация миксинов/трайтов не средствами языка, а «вручную».
По моему вы что-то путаете, паттерн composite ни разу не реализация паттерна mixin. Это очень даже разные вещи, преследующие разные цели.
Ах, да сорри, с декоратором перепутал.
У декоратора и примеси разные цели. Разница между ними примерно такая-же как при обычном и множественном наследовании (но только примерно, так как все четыре подхода — суть разные вещи, служащие для достижения разных целей).
Резюме:
При использовании паттернов команда и стратегия в ООП языках создаются классы которые содержат только одну функцию. Соответственно в языках с функциональными возможностями можна функцию в класс не оборачивать.
Зачем такую простую мысль было так усложнять?
И еще ИМХО: паттерны это архитектурные решения и они не привязаны к конкретной парадигме.
Если в функциональном языке программирования вы реализовали алгоритм той же сортировки, который принимает функцию для сравнения обьекта — это тоже паттерн «стратегия», только реализованый через функторы а не через классы.
При использовании паттернов команда и стратегия в ООП языках создаются классы которые содержат только одну функцию. Соответственно в языках с функциональными возможностями можна функцию в класс не оборачивать.
Зачем такую простую мысль было так усложнять?
И еще ИМХО: паттерны это архитектурные решения и они не привязаны к конкретной парадигме.
Если в функциональном языке программирования вы реализовали алгоритм той же сортировки, который принимает функцию для сравнения обьекта — это тоже паттерн «стратегия», только реализованый через функторы а не через классы.
Насчёт первого:
1. Я исходил из предположения, что не всем известны сами паттерны достаточно хорошо. Поэтому я кратко их описал
2. Я предполагал, что не всем известно само понятие ФВП — и я предполагаю, что гораздо ценнее знать, почему мы можем не создавать класс для обёртки функции и т.д.
2. Я отметил во введении, что эта мысль (фактически в той же форме, что и у Вас) присутствует в книге «Functional Programming for the Real World» — и написал, что мне хотелось именно показать хоть какой-то пример, а не просто голую формулировку.
Насчёт второго:
Первая часть поста описывает как раз почему паттерны ООП — это решения уровня проектирования, а выбор парадигмы — решение уровня архитектуры. Есть архитектурные паттерны, например MVC, клиент-сервер и т.д. — они да, весьма мало связаны с целевой парадигмой. Но паттерны ОО проектирования — очевидно, абстракция более низкого уровня.
Сама суть паттерна «стратегия» — это инкапсуляция функции в класс. Я не вижу класса в моём решении :) Вообще говоря, я думаю, что не надо придавать паттернам какой-то дополнительный смысл — паттерн «стратегия» решает конкретные задачи в рамках ООП.
1. Я исходил из предположения, что не всем известны сами паттерны достаточно хорошо. Поэтому я кратко их описал
2. Я предполагал, что не всем известно само понятие ФВП — и я предполагаю, что гораздо ценнее знать, почему мы можем не создавать класс для обёртки функции и т.д.
2. Я отметил во введении, что эта мысль (фактически в той же форме, что и у Вас) присутствует в книге «Functional Programming for the Real World» — и написал, что мне хотелось именно показать хоть какой-то пример, а не просто голую формулировку.
Насчёт второго:
Первая часть поста описывает как раз почему паттерны ООП — это решения уровня проектирования, а выбор парадигмы — решение уровня архитектуры. Есть архитектурные паттерны, например MVC, клиент-сервер и т.д. — они да, весьма мало связаны с целевой парадигмой. Но паттерны ОО проектирования — очевидно, абстракция более низкого уровня.
Сама суть паттерна «стратегия» — это инкапсуляция функции в класс. Я не вижу класса в моём решении :) Вообще говоря, я думаю, что не надо придавать паттернам какой-то дополнительный смысл — паттерн «стратегия» решает конкретные задачи в рамках ООП.
Насчет первого:
Для понимания статьи надо как минимум знать UML, читать C# и F#. Думаю таким людям про паттерны чтото известно и что такое функтор тоже.
Насчет второго:
Сама суть паттерна «стратегия» — разделение алгоритма и специфических для разных обьектов реализаций.
И никак не инкапсуляция функции в класс.
И если вы заглянете в википедию даже найдете там пример реализации. «Пример с использованием динамических (first-class) функций»
Для понимания статьи надо как минимум знать UML, читать C# и F#. Думаю таким людям про паттерны чтото известно и что такое функтор тоже.
Насчет второго:
Сама суть паттерна «стратегия» — разделение алгоритма и специфических для разных обьектов реализаций.
И никак не инкапсуляция функции в класс.
И если вы заглянете в википедию даже найдете там пример реализации. «Пример с использованием динамических (first-class) функций»
ru.wikipedia.org/wiki/Стратегия_(шаблон_проектирования)#.D0.97.D0.B0.D0.B4.D0.B0.D1.87.D0.B0
Если использовать такую логику, то надо или в каждой статье начинать с правил сложения, или же писать статью про сильное взаимодействие примерно так: «сильное взаимодействие — это сильное взаимодействие».
«Читать F#» особо не требуется — я, как мне кажется, даю кое-какие комментарии насчёт того, что значит приведённый код. Так получилось, что в ФП нет аналога UML — поэтому я даю достаточно подробные комментарии и в самом коде.
Сорри, крыша немного едет, я имел в виду Command, конечно, когда говорил про инкапсуляцию функции в класс.
Но, тем не менее, насчёт стратегии:
«Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.» (GoF)
Всё же суть — «объявить семейство алгоритмов, инкапсулировать их и сделать взаимозаменимыми».
Я думаю, что то, о чёс вы говорите («разделение алгоритма и специфических для разных обьектов реализаций») — это ближе к понятию ad-hoc polymorphism.
Я хочу ещё раз заметить: я не занимаюсь реализацией этих паттернов с помощью x. Моя цель — показать, что паттерны, зачастую, не нужны, ибо имитируют нечто, что отсутствовало в большинстве распространённых языков в явном виде на момент создания паттернов. И опять же, я привёл ссылку на книгу Judith Bishop, где она использует механизм делегатов. Есть весьма тонкая грань (но она всё же есть) между реализацией паттерна X с помощью Y для достижения цели Z и между использованием Y для достижения цели Z :)
«Читать F#» особо не требуется — я, как мне кажется, даю кое-какие комментарии насчёт того, что значит приведённый код. Так получилось, что в ФП нет аналога UML — поэтому я даю достаточно подробные комментарии и в самом коде.
Сорри, крыша немного едет, я имел в виду Command, конечно, когда говорил про инкапсуляцию функции в класс.
Но, тем не менее, насчёт стратегии:
«Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.» (GoF)
Всё же суть — «объявить семейство алгоритмов, инкапсулировать их и сделать взаимозаменимыми».
Я думаю, что то, о чёс вы говорите («разделение алгоритма и специфических для разных обьектов реализаций») — это ближе к понятию ad-hoc polymorphism.
Я хочу ещё раз заметить: я не занимаюсь реализацией этих паттернов с помощью x. Моя цель — показать, что паттерны, зачастую, не нужны, ибо имитируют нечто, что отсутствовало в большинстве распространённых языков в явном виде на момент создания паттернов. И опять же, я привёл ссылку на книгу Judith Bishop, где она использует механизм делегатов. Есть весьма тонкая грань (но она всё же есть) между реализацией паттерна X с помощью Y для достижения цели Z и между использованием Y для достижения цели Z :)
Приблизительно то что в GoF я и имел ввиду. Просто непонятно выразился.
В том то и дело что «инкапсулировать реализацию алгоритма» — а куда инкапсулировать в класс или функтор — дело десятое. Например в C нету ООП, но паттерн стратегия реализуется.
«что отсутствовало в большинстве распространённых языков в явном виде» — вообще то функторы в явном виде существуют в С и в С++.
Из всех языков, с которыми я работал их нету только в Java.
В том то и дело что «инкапсулировать реализацию алгоритма» — а куда инкапсулировать в класс или функтор — дело десятое. Например в C нету ООП, но паттерн стратегия реализуется.
«что отсутствовало в большинстве распространённых языков в явном виде» — вообще то функторы в явном виде существуют в С и в С++.
Из всех языков, с которыми я работал их нету только в Java.
Эм. Мне действительно трудно понять, как можно инкапсулировать 1 в 1. Функция в данном случае — это функция, которая сама по себе значение. Её никуда инкапсулировать не нужно. Сама идея инкапсулировать функцию происходит от того, что она не является в неком языке объектом первого класса.
Тем не менее, использовать ссылки на функции, переданные другим функциями — это ой как неприятно (Вы ведь эту технику подразумевали под «функтором в С и С++»?). Насколько я понимаю, этот метод не типобезопасен?
Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором вообще нет объектов? Я опять хочу заметить, что излишнее обобщение в данном случае не приведёт ни к чему хорошему.
Тем не менее, использовать ссылки на функции, переданные другим функциями — это ой как неприятно (Вы ведь эту технику подразумевали под «функтором в С и С++»?). Насколько я понимаю, этот метод не типобезопасен?
Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором вообще нет объектов? Я опять хочу заметить, что излишнее обобщение в данном случае не приведёт ни к чему хорошему.
стратегия не есть «инкапсулирование функции», а есть «инкапсулирование конкретной реализации алгоритма».
В С — ссылка на функцию. в С++ — перегрузка оператора ().
В С — нетипобезопасен, в С++ типобезопасен. Хотя к чему это?
>Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором >вообще нет объектов?
Подозреваю что никак.
Но можна передать указатель на функцию являющийся конкретной реализацией алгоритма принадлежащего определенному семейству. И это уже стратегия.
В С — ссылка на функцию. в С++ — перегрузка оператора ().
В С — нетипобезопасен, в С++ типобезопасен. Хотя к чему это?
>Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором >вообще нет объектов?
Подозреваю что никак.
Но можна передать указатель на функцию являющийся конкретной реализацией алгоритма принадлежащего определенному семейству. И это уже стратегия.
Чем «конкретная реализация алгоритма» отличается от функции?
убейВсехЧеловековЯдернойБомбой() — «функция» и «конкретная реализация алгоритма».
убейВсехЧеловековЧумой() — опять «функция» и «конкретная реализация алгоритма».
Заметьте, Вы подменяете методы реализации
— передача ссылки на функцию другой функции
— перегрузка ()
и понятие ФВП паттерном Strategy, который используется только в ОО проектировании. Это разные абсолютно уровни абстракции. Весь паттерн — это, по сути, workaround в ситуации: «нам нужны функции как объекты первого класса для решения задачи, но у нас нет функций как объектов первого класса». Странно представлять само понятие функтора/функции высшего порядка/оператора как «реализацию» паттерна ОО проектирования, Вам не кажется?
Вообще, похожая дискуссия завязалась у меня с моим преподавателем по проектированию, когда я представил ему презентацию на эту тему (там ещё рассматривался State). Именно это побудило меня сделать такое большое введение. Это стало всё в итоге моей курсовой работой, и когда он прочитал её, со всеми этими обоснованиями, внезапно оказалось, что между нами нет противоречий, а было только непонимание.
Я думаю, я недостаточно чётко сформулировал цель: моя задача — не реализовывать паттерны, моя задача показать, что некоторые паттерны в некоторых ситуациях не нужны. Поэтому во введении акцент делается именно на том, что паттерны — это не альфа и омега, а просто метод выбора классов задач.
убейВсехЧеловековЯдернойБомбой() — «функция» и «конкретная реализация алгоритма».
убейВсехЧеловековЧумой() — опять «функция» и «конкретная реализация алгоритма».
Заметьте, Вы подменяете методы реализации
— передача ссылки на функцию другой функции
— перегрузка ()
и понятие ФВП паттерном Strategy, который используется только в ОО проектировании. Это разные абсолютно уровни абстракции. Весь паттерн — это, по сути, workaround в ситуации: «нам нужны функции как объекты первого класса для решения задачи, но у нас нет функций как объектов первого класса». Странно представлять само понятие функтора/функции высшего порядка/оператора как «реализацию» паттерна ОО проектирования, Вам не кажется?
Вообще, похожая дискуссия завязалась у меня с моим преподавателем по проектированию, когда я представил ему презентацию на эту тему (там ещё рассматривался State). Именно это побудило меня сделать такое большое введение. Это стало всё в итоге моей курсовой работой, и когда он прочитал её, со всеми этими обоснованиями, внезапно оказалось, что между нами нет противоречий, а было только непонимание.
Я думаю, я недостаточно чётко сформулировал цель: моя задача — не реализовывать паттерны, моя задача показать, что некоторые паттерны в некоторых ситуациях не нужны. Поэтому во введении акцент делается именно на том, что паттерны — это не альфа и омега, а просто метод выбора классов задач.
у вас пробелы в базовых понятиях. подозреваю это изза отсутствия практики. слова курсовая и преподаватель многое обясняют
)) Я студент 4ого курса и занимаюсь программированием с 12 лет. Если Вы можете привести контраргументы — приведите их, но ссылаться на возраст и «отсутствие практики» — по меньшей мере странно.
Самое интересное, что Вы, похоже, не очень поняли то, что написано в главе «Лирическое отступление: разница между архитектурой, проектированием и реализацией». Возможно, я так плохо объясняю, так что советую почитать это.
Ну и да, странно слышать про «пробелы в базовых понятиях» от человека, который утверждает, судя по всему, что даже ссылки на функции и те, бедняжки, реализуют паттерн Strategy :)
Самое интересное, что Вы, похоже, не очень поняли то, что написано в главе «Лирическое отступление: разница между архитектурой, проектированием и реализацией». Возможно, я так плохо объясняю, так что советую почитать это.
Ну и да, странно слышать про «пробелы в базовых понятиях» от человека, который утверждает, судя по всему, что даже ссылки на функции и те, бедняжки, реализуют паттерн Strategy :)
ссылаюсь на возраст и отсутствие практики, так как обьяснил довольно просто, а вы не поняли.
>странно слышать про «пробелы в базовых понятиях» от человека
Мне не надо доказывать мой уровень. Я просто пишу хорошие проекты и они хорошо работают. Можете посмотреть в профиле.
>странно слышать про «пробелы в базовых понятиях» от человека
Мне не надо доказывать мой уровень. Я просто пишу хорошие проекты и они хорошо работают. Можете посмотреть в профиле.
Вы баловались турбо паскалем и считаете это «занимаюсь программированием»?
Ну… мне было лет 8, батя притянул домой правец и мама мне показывала чето в бейсике даже — сама была программист на PL1. Лет 20 прошло с тех пор…
Но я почемуто считаю, что я занимаюсь программированием всегото 5 лет. Ровно столько сколько решаю реальные задачи, за которые мне платят деньги, за которые я живу.
Ну… мне было лет 8, батя притянул домой правец и мама мне показывала чето в бейсике даже — сама была программист на PL1. Лет 20 прошло с тех пор…
Но я почемуто считаю, что я занимаюсь программированием всегото 5 лет. Ровно столько сколько решаю реальные задачи, за которые мне платят деньги, за которые я живу.
Вы опытнее меня, да. Ну и что? Вам не кажется, что вы совершаете логическую ошибку?
еще раз повторю. я не говорю «я опытнее потому я прав». Я говорю «я пробую обяснить, вы не понимаете простых вещей, потому больше обяснять не буду так как вижу, что обьяснить не получится. но воспользуюсь случаем и укажу на вашу некомпетентность»
А я говорю: «У Вас неправильные представления об уровнях абстракции и Вы, вместо того, чтобы попытаться понять мои аргументы, занимаетесь демагогией».
Об уровне моей компетентности уж поверьте, судить не Вам :) При всём уважении, мы занимаемся разными вещами. И заметьте, я спокойно пытался объяснить Вам свою позицию, а Вы перешли на личности.
Об уровне моей компетентности уж поверьте, судить не Вам :) При всём уважении, мы занимаемся разными вещами. И заметьте, я спокойно пытался объяснить Вам свою позицию, а Вы перешли на личности.
ок. чтоб не быть голословным разжую максимально просто.
есть задача — найти человеков и убить.
реализация 1:
найтиИУбить1
{
человеки=найтивсехчеловеков()
убиваем_каждого_по_очереди_чумой(человеки)
}реализация 1:
найтиИУбить2
{
человеки=найтивсехчеловеков()
убиваем_каждого_по_очереди_ядом(человеки)
}
Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.
теперь стратегия:
найтиИУбить(как)
{
человеки=найтивсехчеловеков()
как(человеки)
}
ЭТО СТРАТЕГИЯ!
использование:
найтиИУбить(убиваем_каждого_по_очереди_ядом)
Да, это ФВП и это стратегия. Но не каждая ФВП — стратегия.
Если вы считаете, что патерн стратегия в функциональных языках отстутствует — вперед редактировать вики. Так как там есть пример реализации на функциональном языке.
>Странно представлять само понятие функтора/функции высшего порядка/оператора >как «реализацию» паттерна ОО проектирования, Вам не кажется?
Странно, а кто так делает?
>функтора/функции
Вообще функтор и функция разные вещи и через дробь их писать не хорошо
есть задача — найти человеков и убить.
реализация 1:
найтиИУбить1
{
человеки=найтивсехчеловеков()
убиваем_каждого_по_очереди_чумой(человеки)
}реализация 1:
найтиИУбить2
{
человеки=найтивсехчеловеков()
убиваем_каждого_по_очереди_ядом(человеки)
}
Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.
теперь стратегия:
найтиИУбить(как)
{
человеки=найтивсехчеловеков()
как(человеки)
}
ЭТО СТРАТЕГИЯ!
использование:
найтиИУбить(убиваем_каждого_по_очереди_ядом)
Да, это ФВП и это стратегия. Но не каждая ФВП — стратегия.
Если вы считаете, что патерн стратегия в функциональных языках отстутствует — вперед редактировать вики. Так как там есть пример реализации на функциональном языке.
>Странно представлять само понятие функтора/функции высшего порядка/оператора >как «реализацию» паттерна ОО проектирования, Вам не кажется?
Странно, а кто так делает?
>функтора/функции
Вообще функтор и функция разные вещи и через дробь их писать не хорошо
О боже.
«Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.»
Вы понимаете, что такое higher-order functions и functions as first-class objects? Здесь нет ни того, ни другого.
«ЭТО СТРАТЕГИЯ!»
Это функция высшего порядка найтиИУбить(), которая реализует поведение характерное для паттерна Strategy. Это не Strategy.
Вот Strategy:
«Если вы считаете, что патерн стратегия в функциональных языках отстутствует.»
В чистых функциональных — да. В поддерживающих ООП — Вы можете его реализовать, но зачем?
«Странно, а кто так делает?»
Я так понял, что Вы этим занимаетесь последние несколько постов :)
«Вообще функтор и функция разные вещи и через дробь их писать не хорошо»
Вообще говоря понятие «функтор» имеет много значений. Одно из них — «функция высшего порядка». Не просто функция, а именно функция_высшего_порядка.
«Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.»
Вы понимаете, что такое higher-order functions и functions as first-class objects? Здесь нет ни того, ни другого.
«ЭТО СТРАТЕГИЯ!»
Это функция высшего порядка найтиИУбить(), которая реализует поведение характерное для паттерна Strategy. Это не Strategy.
Вот Strategy:
interface СпособУбийства {
void Убить();
}
class УбитьЯдом {
void Убить(){
...;
}
}
class УбитьЧумой {
void Убить(){
...;
}
}
void УбитьВсехЧеловеков(СпособУбийства как){ //передаём объект, а не функцию => не ФВП!
...
как.Убить();
}
«Если вы считаете, что патерн стратегия в функциональных языках отстутствует.»
В чистых функциональных — да. В поддерживающих ООП — Вы можете его реализовать, но зачем?
«Странно, а кто так делает?»
Я так понял, что Вы этим занимаетесь последние несколько постов :)
«Вообще функтор и функция разные вещи и через дробь их писать не хорошо»
Вообще говоря понятие «функтор» имеет много значений. Одно из них — «функция высшего порядка». Не просто функция, а именно функция_высшего_порядка.
* class УбитьЯдом: СпособУбийства
* class УбитьЧумой: СпособУбийства
* class УбитьЧумой: СпособУбийства
про очевидные вещи больше спорить не буду.
В русской википедии реализация стратегии на функторах. Без классов для реализации алгоритмов. Вперед редактировать википедию — ссылку я приводил выше.
Теперь про пробелы в ваших знаниях.
Функтор имеет одно значение. Это «функция как обьект». Все. Нет других значений.
>Одно из них — «функция высшего порядка». Не просто функция, а именно >функция_высшего_порядка.
Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.
Учите матчасть, потом редактируйте википедию, и дважды думайте перед тем как спорить о том в чем не разбираетесь.
В русской википедии реализация стратегии на функторах. Без классов для реализации алгоритмов. Вперед редактировать википедию — ссылку я приводил выше.
Теперь про пробелы в ваших знаниях.
Функтор имеет одно значение. Это «функция как обьект». Все. Нет других значений.
>Одно из них — «функция высшего порядка». Не просто функция, а именно >функция_высшего_порядка.
Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.
Учите матчасть, потом редактируйте википедию, и дважды думайте перед тем как спорить о том в чем не разбираетесь.
Русская википедия — это тот самый авторитетный источник, по сравнению с которым материалы научных конференций и книги малоизвестного)) издательства O'Reilly ничто.
«Функтор имеет одно значение.»
1. en.wikipedia.org/wiki/Function_object
2. en.wikipedia.org/wiki/Functor
3. en.wikipedia.org/wiki/Map_(higher-order_function)#Generalization
4. en.wikipedia.org/wiki/Function_word
5. caml.inria.fr/pub/docs/manual-ocaml/manual004.html#toc15
Всё ещё в этом уверены?
«Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.»
Общепринятое определение приведено в статье:
«Функция высшего порядка – это функция, которая принимает в качестве аргумента или возвращает как результат другую функцию.»
Оно такое. Открываете любой учебник по ФП и читаете.
Я бы рекомендовал Вам немного выйти из поклонения ООП и почитать хорошие книжки по ФП. И перестать считать себя умнее всех :)
«Функтор имеет одно значение.»
1. en.wikipedia.org/wiki/Function_object
2. en.wikipedia.org/wiki/Functor
3. en.wikipedia.org/wiki/Map_(higher-order_function)#Generalization
4. en.wikipedia.org/wiki/Function_word
5. caml.inria.fr/pub/docs/manual-ocaml/manual004.html#toc15
Всё ещё в этом уверены?
«Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.»
Общепринятое определение приведено в статье:
«Функция высшего порядка – это функция, которая принимает в качестве аргумента или возвращает как результат другую функцию.»
Оно такое. Открываете любой учебник по ФП и читаете.
Я бы рекомендовал Вам немного выйти из поклонения ООП и почитать хорошие книжки по ФП. И перестать считать себя умнее всех :)
Ну это простите вообще смешно.
ссылка 1. A function object, also called a functor,
ссылка 2. For functors as a synonym of «function objects»
ссылка 3., higher-order functions, functional forms, or functionals are functions which do at least one of the following:
take one or more functions as an input
output a function
итд.
Везде сказано именно то, что я сказал выше. Практически слово в слово.
Конкретно сказано Functor == Function object.
>«Функция высшего порядка это функция которая принимает функторы >как аргумент или возвращает функтор. Все. Никак иначе.»
> «Функция высшего порядка – это функция, которая принимает в >качестве аргумента или возвращает как результат другую функцию.»
Вы че, на самом деле не понимаете, что это написано одно и тоже?? На полном серьезе?
ссылка 1. A function object, also called a functor,
ссылка 2. For functors as a synonym of «function objects»
ссылка 3., higher-order functions, functional forms, or functionals are functions which do at least one of the following:
take one or more functions as an input
output a function
итд.
Везде сказано именно то, что я сказал выше. Практически слово в слово.
Конкретно сказано Functor == Function object.
>«Функция высшего порядка это функция которая принимает функторы >как аргумент или возвращает функтор. Все. Никак иначе.»
> «Функция высшего порядка – это функция, которая принимает в >качестве аргумента или возвращает как результат другую функцию.»
Вы че, на самом деле не понимаете, что это написано одно и тоже?? На полном серьезе?
Вы попытайтесь прочитать полностью то, что там написано :) не вырывая словосочетания из контекста.
Я понимаю что это разные вещи. Функция в математике и ФП — это одно и то же. Они по умолчанию являются объектами первого класса (никакой связи с ООП!). Поэтому понятие функтор там чаще всего используется в том же смысле, что и в теории категории.
Вы же говорите про ООП-функторы: т.е. workaround для изображения «функций, как объектов первого класса».
Товарищи, минусующие карму: вы хотя бы высказались, что ли.
Я понимаю что это разные вещи. Функция в математике и ФП — это одно и то же. Они по умолчанию являются объектами первого класса (никакой связи с ООП!). Поэтому понятие функтор там чаще всего используется в том же смысле, что и в теории категории.
Вы же говорите про ООП-функторы: т.е. workaround для изображения «функций, как объектов первого класса».
Товарищи, минусующие карму: вы хотя бы высказались, что ли.
еще раз повторюсь — там сказано именно то что сказал я
и нигде не сказано, такого как
> «функтор» имеет много значений
и
>Одно из них — «функция высшего порядка»
Так как фвп не обязательно функтор и функтор не обязательно фвп
>Функция в математике и ФП — это одно и то же.
Ну это извините вобще ни в какие ворота не лезет.
Функция в математике — зависимость одной величины от другой.
Функция в программировании — проименованая(или анонимная) последовательность операций, которая может быть вызвана повторно
и нигде не сказано, такого как
> «функтор» имеет много значений
и
>Одно из них — «функция высшего порядка»
Так как фвп не обязательно функтор и функтор не обязательно фвп
>Функция в математике и ФП — это одно и то же.
Ну это извините вобще ни в какие ворота не лезет.
Функция в математике — зависимость одной величины от другой.
Функция в программировании — проименованая(или анонимная) последовательность операций, которая может быть вызвана повторно
«Ну это извините вобще ни в какие ворота не лезет.»
Да что Вы?
«In particular, in a functional language variables are variables: the mathematical concept of variables, which is given meaning by substitution, is precisely the programming concept of variable. It’s not analogous, it’s the same.»
existentialtype.wordpress.com/2011/04/17/some-advice-on-teaching-fp/
«The differential is an operator acting on functions that produces a linear approximation to the function at each point in its domain (if the function in fact has such).»
existentialtype.wordpress.com/2011/04/02/functions-are-values/
Пишет один из крупнейших учёных в теории типов. Сложите эти мысли, переварите их и подумайте.
«Функция в математике — зависимость одной величины от другой.
Функция в программировании — проименованая(или анонимная) последовательность операций, которая может быть вызвана повторно»
Вы не понимаете разницы между понятием функции в ФП и в императивном программировании.
То, что Вы считаете «функцией в программировании» — это «функция в императивном программировании». Функция в ФП- это сущность, принимающая нечто и возвращающая нечто. Отображение между двумя множествами. Именно поэтому мы так трясёмся с immutable data structures. Они гарантируют чистоту функций, отсутствие сайд-эффектов. И если функция чистая — мы получаем именно ту самую сущность, которая однозначно отображает одно множество в другое. Почитайте:
en.wikipedia.org/wiki/Side_effect_(computer_science)
en.wikipedia.org/wiki/Pure_function
Я говорю в другой парадигме, поймите же. И да, как раз Ваш опыт может играть с Вами злую шутку: ибо понимание всего этого требует серьёзной ломки стереотипов.
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Я этого нигде не утверждал.
Вы знаете английский?
Да что Вы?
«In particular, in a functional language variables are variables: the mathematical concept of variables, which is given meaning by substitution, is precisely the programming concept of variable. It’s not analogous, it’s the same.»
existentialtype.wordpress.com/2011/04/17/some-advice-on-teaching-fp/
«The differential is an operator acting on functions that produces a linear approximation to the function at each point in its domain (if the function in fact has such).»
existentialtype.wordpress.com/2011/04/02/functions-are-values/
Пишет один из крупнейших учёных в теории типов. Сложите эти мысли, переварите их и подумайте.
«Функция в математике — зависимость одной величины от другой.
Функция в программировании — проименованая(или анонимная) последовательность операций, которая может быть вызвана повторно»
Вы не понимаете разницы между понятием функции в ФП и в императивном программировании.
То, что Вы считаете «функцией в программировании» — это «функция в императивном программировании». Функция в ФП- это сущность, принимающая нечто и возвращающая нечто. Отображение между двумя множествами. Именно поэтому мы так трясёмся с immutable data structures. Они гарантируют чистоту функций, отсутствие сайд-эффектов. И если функция чистая — мы получаем именно ту самую сущность, которая однозначно отображает одно множество в другое. Почитайте:
en.wikipedia.org/wiki/Side_effect_(computer_science)
en.wikipedia.org/wiki/Pure_function
Я говорю в другой парадигме, поймите же. И да, как раз Ваш опыт может играть с Вами злую шутку: ибо понимание всего этого требует серьёзной ломки стереотипов.
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Я этого нигде не утверждал.
Вы знаете английский?
Вообще говоря, если Вам интересно понять в чём различия, я с удовольствием пообщаюсь с Вами в личке. Это действительно очень объёмная тема. Я извиняюсь, что ввёл Вас в заблуждение не указав явно, что я использую отличную от Вашей терминологию.
разницу между словами function и variable вы видимо не признаете.
>Я этого нигде не утверждал.
Утверждали, цитирую:
>«функтор» имеет много значений. Одно из них — «функция высшего порядка»
Это все класно. Сущность… нечто… Только от проблемка одна. Программирование это чисто прикладная дисциплина. И вся теория придумана для того, чтоб писать программы проще и еффективнее. А так как центральный процессор не оперирует понятиями «сущность» и «нечто» то функции и получаються последовательностями комманд.
И в C# и в F#.
И перестаньте мне кидать линки на то, что я итак знаю.
А вы, хоть знаете, откуда пошел весь сыр бор про ФП??? Какую проблему ФП должно бы решить? В чем фишка того, что функция чистая??
Английский я знаю.
>Я этого нигде не утверждал.
Утверждали, цитирую:
>«функтор» имеет много значений. Одно из них — «функция высшего порядка»
Это все класно. Сущность… нечто… Только от проблемка одна. Программирование это чисто прикладная дисциплина. И вся теория придумана для того, чтоб писать программы проще и еффективнее. А так как центральный процессор не оперирует понятиями «сущность» и «нечто» то функции и получаються последовательностями комманд.
И в C# и в F#.
И перестаньте мне кидать линки на то, что я итак знаю.
А вы, хоть знаете, откуда пошел весь сыр бор про ФП??? Какую проблему ФП должно бы решить? В чем фишка того, что функция чистая??
Английский я знаю.
">«Так как фвп не обязательно функтор и функтор не обязательно фвп»
>Я этого нигде не утверждал.
>>Утверждали, цитирую:
>>>«функтор» имеет много значений. Одно из них — >>«функция высшего порядка»"
Окей, формально моё высказывание:
"∃ значение слова функтор ≡ ФВП"
Вы отрицаете высказывание:
"∀ значение слова функтор ≡ ФВП"
«И вся теория придумана для того, чтоб писать программы проще и еффективнее.»
Да. Вы считаете, что проще написать 5 строчек или 15?
Безусловно функции в конечном счёте преобразуются в последовательность команд. Только я говорю о проектировании и архитектуре, и меня в данном контексте не интересуют машинные команды. Вы вот тоже понятиями «функтор» и «объект» оперируете. Сомневаюсь, что ими оперирует процессор.
Вообще-то знаю. Почему хорошо, что функция чистая — как раз в одном из тех линков, которые вы «знаете».
Можно задать несколько вопросов?
— Какие языки ФП Вы знаете? Как долго Вы занимались ФП?
— Почему Вы постоянно отрицаете то, что знаете? Ибо в тех ссылках, которые я вам кидал, слова противоположные Вашим. Dissociative identity disorder?
— Вы прочитали мой пост полностью или пробежали его по диагонали, думая что Вы уже всё это знаете?
>Я этого нигде не утверждал.
>>Утверждали, цитирую:
>>>«функтор» имеет много значений. Одно из них — >>«функция высшего порядка»"
Окей, формально моё высказывание:
"∃ значение слова функтор ≡ ФВП"
Вы отрицаете высказывание:
"∀ значение слова функтор ≡ ФВП"
«И вся теория придумана для того, чтоб писать программы проще и еффективнее.»
Да. Вы считаете, что проще написать 5 строчек или 15?
Безусловно функции в конечном счёте преобразуются в последовательность команд. Только я говорю о проектировании и архитектуре, и меня в данном контексте не интересуют машинные команды. Вы вот тоже понятиями «функтор» и «объект» оперируете. Сомневаюсь, что ими оперирует процессор.
Вообще-то знаю. Почему хорошо, что функция чистая — как раз в одном из тех линков, которые вы «знаете».
Можно задать несколько вопросов?
— Какие языки ФП Вы знаете? Как долго Вы занимались ФП?
— Почему Вы постоянно отрицаете то, что знаете? Ибо в тех ссылках, которые я вам кидал, слова противоположные Вашим. Dissociative identity disorder?
— Вы прочитали мой пост полностью или пробежали его по диагонали, думая что Вы уже всё это знаете?
>— Какие языки ФП Вы знаете? Как долго Вы >занимались ФП?
Ни одного. Не занимался ФП вообще.
Встречный вопрос
-Как долго вы занимались программирование вообще.
Ответ то я знаю. Вообще не занимались.
>слова противоположные Вашим.
приведите слова противоположные моим из этих линков.
Ни одного. Не занимался ФП вообще.
Встречный вопрос
-Как долго вы занимались программирование вообще.
Ответ то я знаю. Вообще не занимались.
>слова противоположные Вашим.
приведите слова противоположные моим из этих линков.
«Ни одного. Не занимался ФП вообще.»
Я занимаюсь им и соответствующими разделами математики последние 1,5 года. Я не гуру ни в коем разе, но.
«Ответ то я знаю. Вообще не занимались.»
Poor me.
«приведите слова противоположные моим из этих линков.»
Например, почитайте ссылки, которые я Вам привёл касательно функторов)) Внимательно)
Итак, мне пора спать :) Продолжим этот разговор позже в личке, если желаете.
Я занимаюсь им и соответствующими разделами математики последние 1,5 года. Я не гуру ни в коем разе, но.
«Ответ то я знаю. Вообще не занимались.»
Poor me.
«приведите слова противоположные моим из этих линков.»
Например, почитайте ссылки, которые я Вам привёл касательно функторов)) Внимательно)
Итак, мне пора спать :) Продолжим этот разговор позже в личке, если желаете.
Но всетаки хочется услышать — какие прикладные проблеммы решает ФП и чистые функции? Ваш вариант.
Подсказка — это НЕ упрощение паттерна стратегия на 3 строчки кода.
Подсказка — это НЕ упрощение паттерна стратегия на 3 строчки кода.
Облегчение параллелизации ПО, например. Очень непрактичная вещь, правда ведь?)
И да, забавно, что Вы так глубоко разобрались в ФП, даже к нему не прикасаясь. Вот бы мне так :)
Забавно что вы разобрались в программировании вообще к нему не прикасаясь.
У нас просто критерии разные. Я не написал ни одной программмы на ФЯП которая пошла в продакшен. Потому я считаю, что я НЕ занимаюсь ФП вообще.
Вы чтото читали про ФП и (ВАУ) написали курсовую и считаете что «занимаетесь» им 1.5 года.
вот и вся разница.
У нас просто критерии разные. Я не написал ни одной программмы на ФЯП которая пошла в продакшен. Потому я считаю, что я НЕ занимаюсь ФП вообще.
Вы чтото читали про ФП и (ВАУ) написали курсовую и считаете что «занимаетесь» им 1.5 года.
вот и вся разница.
Ну я, к примеру, написал небольшой язык программирования на F#, ради интереса. Ещё что-то там было. Естественно, это не могло пойти в продакшен, потому что нафиг никому не надо :)
Тем не менее, мне тут «программисты», которые вполне много чего-то там выпускают и делают для заказчиков, кидают мне код с параллельными массивами. Ну я ж не написал тыщу ПХПстраничек и 200 флеш-игр, так что куда им слушать меня, убогого, вопиющего, что так никто не делает с 60ых?
Я писал про аргументум ад хоминем. Вы не вняли. Извините, я умею спорить только опираясь на логику :)
Я думаю, конструктива тут больше не будет, так что пора завязывать. И спать, наконец. Мир, дружба, чистые функции и машинные инструкции? :)
Тем не менее, мне тут «программисты», которые вполне много чего-то там выпускают и делают для заказчиков, кидают мне код с параллельными массивами. Ну я ж не написал тыщу ПХПстраничек и 200 флеш-игр, так что куда им слушать меня, убогого, вопиющего, что так никто не делает с 60ых?
Я писал про аргументум ад хоминем. Вы не вняли. Извините, я умею спорить только опираясь на логику :)
Я думаю, конструктива тут больше не будет, так что пора завязывать. И спать, наконец. Мир, дружба, чистые функции и машинные инструкции? :)
логика:
1.все парадигмы программирования для упрощения решения прикладных задач.
2. вы не решили ни одной прикладной задачи.
следствие:
придумайте сами. мне кажется все итак ясно
1.все парадигмы программирования для упрощения решения прикладных задач.
2. вы не решили ни одной прикладной задачи.
следствие:
придумайте сами. мне кажется все итак ясно
Т.е. книгу, скажем, указанной J. Bishop мне выкинуть? Ну вот не решила, бедняжка, ни одной практической задачи. И вообще _все_ книги и статьи мне выкинуть, кроме «я вот тут решил создать игрушку, вот вам топик с её кодом: ...»?
Вообще, теория не имеет право на существование, да?)
Вообще, теория не имеет право на существование, да?)
да кто ж говорит что книгу выкинуть. Я говорю что вы книгу не поняли.
Что и доказали в коментариях выше. Когда я формулировал определение по своему, но абсолютно правильно, а вы «опровергали» меня определением из книги, которое отличается немногим более чем порядком слов.
Что и доказали в коментариях выше. Когда я формулировал определение по своему, но абсолютно правильно, а вы «опровергали» меня определением из книги, которое отличается немногим более чем порядком слов.
понятиями функтор и обьек оперирует ЯП. А понятиями «сущность и „нечто“ не оперирует никто.
>не интересуют машинные команды
меня тоже. разговор был про команды — операторы и конструкции языка программирования.
>»∃ значение слова функтор ≡ ФВП"
> Вы отрицаете высказывание:
> "∀ значение слова функтор ≡ ФВП"
Понимаю. Тяжело признавать свою неправоту. От только вы сказали такой бред вроде
«одно из значений слова существо — паук тарантул».
да. паук тоже существо. никто ж не спорит.
>не интересуют машинные команды
меня тоже. разговор был про команды — операторы и конструкции языка программирования.
>»∃ значение слова функтор ≡ ФВП"
> Вы отрицаете высказывание:
> "∀ значение слова функтор ≡ ФВП"
Понимаю. Тяжело признавать свою неправоту. От только вы сказали такой бред вроде
«одно из значений слова существо — паук тарантул».
да. паук тоже существо. никто ж не спорит.
«А понятиями «сущность и „нечто“ не оперирует никто.»
Наука есть такая. Философия. И да, ещё одна. Математика. А ещё есть ER-диаграммы. И анализ предметной области. Печаль им.
«От только вы сказали такой бред вроде»
Я указал Вам на то, что Вы допускаете ещё одну логическую ошибку, самую частую, кстати. Вы путаете кванторы. Ах да. Кванторы не решили практической задачи, нафиг кванторы.
Кстати, а какую практическую задачу решили Вы, всеми этими комментариями? :)
Наука есть такая. Философия. И да, ещё одна. Математика. А ещё есть ER-диаграммы. И анализ предметной области. Печаль им.
«От только вы сказали такой бред вроде»
Я указал Вам на то, что Вы допускаете ещё одну логическую ошибку, самую частую, кстати. Вы путаете кванторы. Ах да. Кванторы не решили практической задачи, нафиг кванторы.
Кстати, а какую практическую задачу решили Вы, всеми этими комментариями? :)
Может действительно, займитесь философией. Там код писать не надо. И работать ничего не должно. Ладно. На этом разрешите откланятся. Жизнь расставит все на свои места. Вас же жизнь поставит на место на первом же собеседовании на должность джуниор девелопера.
признайтесь честно, вам обоим просто не спалось))
А кванторы попутали вы, так как утверждение
∃ функтор ≡ ФВП
однозначно верно, но утверждение
∃ значение слова функтор ≡ ФВП
однозначно ложно.
Или вы просто не понимаете слова «значение».
Опять на простом примере
«Термин язык программирования имеет много значений — одно из них ассемблер».
∃ функтор ≡ ФВП
однозначно верно, но утверждение
∃ значение слова функтор ≡ ФВП
однозначно ложно.
Или вы просто не понимаете слова «значение».
Опять на простом примере
«Термин язык программирования имеет много значений — одно из них ассемблер».
2mokus,
А я люблю его писать, видите, какое трагическое противоречие. И когда у тех самых «практиков» возникают проблемы, они бегут ко мне. Ангст.
«Вас же жизнь поставит на место на первом же собеседовании на должность джуниор девелопера.» — посмотрим :) Когда-нибудь я Вам сообщу о результатах :)
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Перечитайте 15 раз, пожалуйста.
Её богу, если я Вам сейчас начну пересказывать курс мат. логики в комментариях, это будет странно :)
2Meroving,
^_____^
А я люблю его писать, видите, какое трагическое противоречие. И когда у тех самых «практиков» возникают проблемы, они бегут ко мне. Ангст.
«Вас же жизнь поставит на место на первом же собеседовании на должность джуниор девелопера.» — посмотрим :) Когда-нибудь я Вам сообщу о результатах :)
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Перечитайте 15 раз, пожалуйста.
Её богу, если я Вам сейчас начну пересказывать курс мат. логики в комментариях, это будет странно :)
2Meroving,
^_____^
Функтор — это придуманный способ обмана, но для ФП функтор — марихуана
Если вы будете везде, где достаточно передать функцию, строить классическую схему построение патернов, то вы утонете в коде раньше чем решите задачу. GAF-ы пишут именно об этом, когда говорят, что люди отказываются от использования патернов.
Есть замечательная книга Джошуа Кериевски «Рефакторинг к паттернам», основная ее мысль — стройте такую структуру типов, которая действительно необходима. Паттерн — это картинка, которая поможет в трудную минуту, а не инструкция по сборке самолета.
Взгляните на передачу функции в качестве аргументов под углом достаточности и вы поймете, что mokus прав
Есть замечательная книга Джошуа Кериевски «Рефакторинг к паттернам», основная ее мысль — стройте такую структуру типов, которая действительно необходима. Паттерн — это картинка, которая поможет в трудную минуту, а не инструкция по сборке самолета.
Взгляните на передачу функции в качестве аргументов под углом достаточности и вы поймете, что mokus прав
Вы спорите о словах: называть паттерном реализацию без класса или не называть. По-моему тут важнее возможность построения изоморфизма: если возможно построить изоморфизм с описанием паттерна — то это тот же паттерн, иначе — нет.
В этом случае легко понять, что предложенные подходы на основе функций являются одними из возможных реализаций паттернов.
В этом случае легко понять, что предложенные подходы на основе функций являются одними из возможных реализаций паттернов.
Чем «конкретная реализация алгоритма» отличается от функции?
Функция — это абстракция над алгоритмом. Функция инкапсулирует его. Если там где вызывается функция ввести её тело без «обвязки» (но с соответствующими изменениями, чтобы, например, избежать конфликтов имён), то результат работы алгоритма не изменится (и даже будет получен быстрее — не будут тратиться ресурсы на вызов функции, хотя если в программе функция вызывается в разных местах и в каждом заменить вызов на тело, то размер кода увеличится, а поддержка его превратится в ад).
моя задача — не реализовывать паттерны, моя задача показать, что некоторые паттерны в некоторых ситуациях не нужны.
Вы реализуете паттерн путем выделения алгоритма в функцию :)
Не смотря на некоторые заблуждения всё равно спасибо за статью, появились мысли для чего можно использовать элементы ФП в PHP.
Дело в том, что мы по разному определяем исходные понятия :) Я подразумеваю под функцией нечто оторванное от физической реализации в принципе. Когда Вам говорят о функции синуса, вы же не представляете это как ряд шагов, которые реализуют, например, подсчёт суммы соответствующего разложения в ряд? Точно так же паттерны говорят о том, как организовать объекты так, чтобы достичь некоторых свойств системы. Т.е. в случае функции в ФП мы абстрагируемся от её реализации, а в случае паттернов в ООП — мы абстрагируемся от, скажем, конкретной реализации объектов в языке или системы наследования (ну в js, например), но всё же от самого понятия объекта мы абстрагироваться не можем.
Поэтому я всё же, если говорить строго, показываю, что один из приёмов ФП можно использовать для того, чтобы достичь тех свойств системы, которые обычно достигаются путём использования паттерна.
Паттерн — это метод достижения определённой цели, ФВП — тоже метод достижения определённой цели, цели иногда отличаются, иногда совпадают, но это просто параллельные миры на одном уровне абстракции :)
Вот как можно кратко сформулировать всё то, о чём мы спорили с mokus :)
Поэтому я всё же, если говорить строго, показываю, что один из приёмов ФП можно использовать для того, чтобы достичь тех свойств системы, которые обычно достигаются путём использования паттерна.
Паттерн — это метод достижения определённой цели, ФВП — тоже метод достижения определённой цели, цели иногда отличаются, иногда совпадают, но это просто параллельные миры на одном уровне абстракции :)
Вот как можно кратко сформулировать всё то, о чём мы спорили с mokus :)
* И да, пожалуйста :)
Точно так же паттерны говорят о том, как организовать объекты так, чтобы достичь некоторых свойств системы.
Не согласен. Паттерны в моём понимании — это выражение задачи и типичного способа её решения. Например, задача стратегии это выбор алгоритма динамически. Типичный способ решение — отделение логики выбора от логики собственно алгоритма. Будет логика выбора реализована через наследование или через ФВП — это уже летали реализации. Но это мое понимание, на академическую строгость не претендую.
Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором вообще нет объектов?
Вообще говоря, объект — это сущность, имеющая состояние и поведение, атрибуты и методы. Реализовать его можно хоть на ассемблере в виде, например структуры данных с общим базовым адресом и доступом к данным и адресам функций по смещению к базовому адресу. Различные obj = new SomeClass; obj.attr = 1; obj.method() — это лишь синтаксический сахар, ведь программа хоть на Си, хоть на Хаскеле в итоге сводится даже не к ассемблеру, а к машинному коду.
«ведь программа хоть на Си, хоть на Хаскеле в итоге сводится даже не к ассемблеру, а к машинному коду.» — безусловно. Но мы на уровень выше этого :)
Я приведу контрпример: фраза хоть на китайском, хоть на русском в итоге сводится к одному и тому же смыслу, который понимает и китаец, и русский. Тем не менее, хотя языки позволяют выражать одно и то же, в китайской грамматике есть такие вещи, как, например, счётные слова, которые не имеют аналога в русском. А в русском есть падежи, которых, очевидно, нет в китайском. У нас та же ситуация :) Мы говорим про правильные грамматические конструкции для выражения смысла: и т.к. языки разные, грамматические конструкции меняются :)
Я приведу контрпример: фраза хоть на китайском, хоть на русском в итоге сводится к одному и тому же смыслу, который понимает и китаец, и русский. Тем не менее, хотя языки позволяют выражать одно и то же, в китайской грамматике есть такие вещи, как, например, счётные слова, которые не имеют аналога в русском. А в русском есть падежи, которых, очевидно, нет в китайском. У нас та же ситуация :) Мы говорим про правильные грамматические конструкции для выражения смысла: и т.к. языки разные, грамматические конструкции меняются :)
> паттерны это архитектурные решения и они не привязаны к конкретной парадигме.
Вы ошибаетесь. Паттерны привязаны не только к парадигме, они даже от языка зависят (в рамках одной парадигмы). Некоторые паттерны языка C++, например, бессмысленны в SmallTalk.
Вы ошибаетесь. Паттерны привязаны не только к парадигме, они даже от языка зависят (в рамках одной парадигмы). Некоторые паттерны языка C++, например, бессмысленны в SmallTalk.
>Паттерны Command и Strategy — это ограниченная реализация функций высшего порядка
категорически не согласен с такой формулировкой.
Мой вариант: В функциональных языках паттерны Command и Strategy реализуются с помощью ФВП.
категорически не согласен с такой формулировкой.
Мой вариант: В функциональных языках паттерны Command и Strategy реализуются с помощью ФВП.
Ну, это нечто вроде спора, что первично: курица или яйцо. Я действительно не думаю, что никому из GoF не были известны ФВП — а учитывая, что Lisp появился несколько раньше, чем ООП… Хотя, в любом случае, как кто-то говорил, паттерны возникают сами — и Command, и Strategy переоткрывались и теми, кто понятия не имел про ФВП. В общем, я считаю, что и Ваша, и моя формулировка правильны и, фактически, эквиваленты.
См. выше.
Здесь лучше подходит не «курица и яйцо», а «кто первый встал — того и тапки» или «в чужой монастырь со своим уставом не ходят».
Уж скоро 20 лет как GoF вышел, а люди все никак не успокоятся.
Почему никак нельзя принять факт что для каждой парадигмы есть свое направления движения и свой _правильный_ подход по интерпретации и реализации какой либо сущности.
Почему нельзя отойти от умных книжек и википедий и решить что функция это просто некая сущность переносящая логику. И без разницы как оно это делает и чем в каком либо языке по факту является.
Есть много уровней абстракций и точек обзора. И программа написанная на C\C++\C#\F#\Prolog может идентично отображаться в любой реализации, но не коррелировать со своим описание на UML\SDL и других блокнотиках. Детали имплементации понимаешь.
Может еще на уровне логики, поведения или битиков в памяти однозначно реализовывать какой либо патерн, но на жестком и не праведном уровне кода быть чем-то иным?
Почему никак нельзя принять факт что для каждой парадигмы есть свое направления движения и свой _правильный_ подход по интерпретации и реализации какой либо сущности.
Почему нельзя отойти от умных книжек и википедий и решить что функция это просто некая сущность переносящая логику. И без разницы как оно это делает и чем в каком либо языке по факту является.
Есть много уровней абстракций и точек обзора. И программа написанная на C\C++\C#\F#\Prolog может идентично отображаться в любой реализации, но не коррелировать со своим описание на UML\SDL и других блокнотиках. Детали имплементации понимаешь.
Может еще на уровне логики, поведения или битиков в памяти однозначно реализовывать какой либо патерн, но на жестком и не праведном уровне кода быть чем-то иным?
«Гипотеза заключалась в том, что паттерны — это устоявшиеся решения определённых проблем, а раз возникают проблемы и их устоявшиеся решения, видимо есть некие слабости и недостатки, которые приходиться преодолевать. Для рассмотренных паттернов это действительно так.»
Занятные у вас гипотезы; главное, очень актуальные.
Скажите, а вас не смущает, что ваша «гипотеза» озвучивается как данность на любом вменяемом архитектурном семинаре (я вот ее встречал у Казмана, что в книге, что на семинарах)?
Занятные у вас гипотезы; главное, очень актуальные.
Скажите, а вас не смущает, что ваша «гипотеза» озвучивается как данность на любом вменяемом архитектурном семинаре (я вот ее встречал у Казмана, что в книге, что на семинарах)?
И второе.
Анализируя паттерн «стратегия», вы сразу берете его реализацию для объектно-ориентированных языков. И потом успешно ее разносите, показывая «какой неудачный паттерн, он придуман потому что ООЯ ущербны». Но.
Паттерн «стратегия» — это всего лишь прием, позволяющий поменять поведение алгоритма, передав в него другой алгоритм. И мне наплевать, реализован он в рамках ООП, ФП, ООП-с-делегатами или еще как-то. Мне важно только то, что с точки зрения поведения это «стратегия».
В частности, в том же (насквозь ОО) c# стратегии уже давно можно реализовывать с помощью Func{Of T,T1,T2...}. Мне плевать, что внутри платформа сделает из этого класс — мне важно только то, что для меня оно ведет себя как функция. Именно в этом красота паттерна — он абстрагирует меня от конкретики.
(С другой стороны, стратегия может быть настолько сложна, что реализовать ее в одной функции — сложно. И тут тем более выгодно работать с объектом, потому что он позволяет как угодно декомпоновать нужное мне поведение.)
Анализируя паттерн «стратегия», вы сразу берете его реализацию для объектно-ориентированных языков. И потом успешно ее разносите, показывая «какой неудачный паттерн, он придуман потому что ООЯ ущербны». Но.
Паттерн «стратегия» — это всего лишь прием, позволяющий поменять поведение алгоритма, передав в него другой алгоритм. И мне наплевать, реализован он в рамках ООП, ФП, ООП-с-делегатами или еще как-то. Мне важно только то, что с точки зрения поведения это «стратегия».
В частности, в том же (насквозь ОО) c# стратегии уже давно можно реализовывать с помощью Func{Of T,T1,T2...}. Мне плевать, что внутри платформа сделает из этого класс — мне важно только то, что для меня оно ведет себя как функция. Именно в этом красота паттерна — он абстрагирует меня от конкретики.
(С другой стороны, стратегия может быть настолько сложна, что реализовать ее в одной функции — сложно. И тут тем более выгодно работать с объектом, потому что он позволяет как угодно декомпоновать нужное мне поведение.)
:-) Фактически, уважаемые спорщики говорят об одном и том же разными словами и терминами, имея свое субъективное мнение об их назначении.
Легко убедиться, что они хорошо владеют терминологией, пусть с небольшими погрешностями в понимании.
Проблема состоит в стыковке: если одинаковые понятия имеют разные формулировки, бывает довольно сложно понять, что это одно и то же.
Легко убедиться, что они хорошо владеют терминологией, пусть с небольшими погрешностями в понимании.
Проблема состоит в стыковке: если одинаковые понятия имеют разные формулировки, бывает довольно сложно понять, что это одно и то же.
Собственно для того, чтобы избежать этого, я и привёл исследование, рассказывающее, почему же я так смело утверждаю, что к чему относится и кто кого реализует :) Но, похоже, никто не удосужился…
Короче говоря, мне надоело спорить на эту тему. Если Вы так хотите воспринимать это как реализацию паттерна — пожалуйста :) Кому-то моя статья сэкономит пару строк кода, а кого-то познакомит с весьма важными понятиями. Это уже очень много.
Короче говоря, мне надоело спорить на эту тему. Если Вы так хотите воспринимать это как реализацию паттерна — пожалуйста :) Кому-то моя статья сэкономит пару строк кода, а кого-то познакомит с весьма важными понятиями. Это уже очень много.
Вы повторили то, что я пытался доказать автору целую ночь :)
От себя добавлю, что например в AS3 в отличие от C# функция даже при компиляции не будет запакована в класс.
От себя добавлю, что например в AS3 в отличие от C# функция даже при компиляции не будет запакована в класс.
Норвиг в 1996 году рассматривал паттерны в Lisp и Dylan. Собственно, результат аналогичный (многие паттерны становятся тривиальными или существенно упрощаются), но на более богатом материале.
У меня вопрос такой: можно ли данную парадигму ФВП как-нибудь представить в UML? Возможно ли представить, скажем, процедурно написанный код на обычном Си в UML, где есть только функции, классы не применялись? Если да, то как, подскажите, может есть пример для этого?
Для конкретной задачи практически всегда можно создать некую структуру из классов, которая будет отражать тот или иной аспект применения функций высших порядков — и изобразить её на UML-диаграмме. Но сам концепт представить сложно в таком виде, разве что нарисовать компилятор для функционального языка :) UML, всё же, язык объектного моделирования :)
Были попытки разработать графический язык для функционального программирования, например, тут, но, на мой взгляд, неудачные и не имеющие смысла. Тут ситуация аналогичная блок-схемам — с появлением структурного программирования они потеряли смысл, ибо сами языки были нагляднее, чем представление алгоритма в блок-схеме.
И ещё, процедурное программирование и функциональное — две большие разницы. Функциональное представляет функции как значения, за счёт этого Вы можете представить списки функций, композицию функций и прочие подобные вещи. И вообще говоря, Вы представляете решение задачи как последовательное применение функций, по сути — Вы описываете, что хотите получить.
В процедурном программировании Вы как раз представляете решение задачи как последовательность шагов, вся идея заключается в изменении состояний памяти, значений переменных и прочее.
UML же отражает сущности из другой области — он представляет классы, интерфейсы, отношения между ними — в чистом функциональном или в обычном процедурном (хотя ООП является потомком процедурного программирования) программировании этого всего нет. ООП изображает программу как передачу сообщений между объектами — это просто другая точка зрения, взгляд с другого угла на проблему.
Поэтому использовать UML и для процедурного, и для функционального программирования бессмысленно :)
Были попытки разработать графический язык для функционального программирования, например, тут, но, на мой взгляд, неудачные и не имеющие смысла. Тут ситуация аналогичная блок-схемам — с появлением структурного программирования они потеряли смысл, ибо сами языки были нагляднее, чем представление алгоритма в блок-схеме.
И ещё, процедурное программирование и функциональное — две большие разницы. Функциональное представляет функции как значения, за счёт этого Вы можете представить списки функций, композицию функций и прочие подобные вещи. И вообще говоря, Вы представляете решение задачи как последовательное применение функций, по сути — Вы описываете, что хотите получить.
В процедурном программировании Вы как раз представляете решение задачи как последовательность шагов, вся идея заключается в изменении состояний памяти, значений переменных и прочее.
UML же отражает сущности из другой области — он представляет классы, интерфейсы, отношения между ними — в чистом функциональном или в обычном процедурном (хотя ООП является потомком процедурного программирования) программировании этого всего нет. ООП изображает программу как передачу сообщений между объектами — это просто другая точка зрения, взгляд с другого угла на проблему.
Поэтому использовать UML и для процедурного, и для функционального программирования бессмысленно :)
Спасибо за ответ! Погуглил, есть такой ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность) (ссылку не могу дать, карму мою сегодня поглотили ))), может он подойдет? =)
А по написанному, с Вами согласен, Я просто использовал у себя диаграммы процессов, dfd- и erd — диаграммы, а тут пришло время писать отчет — подумал заморочиться…
А по написанному, с Вами согласен, Я просто использовал у себя диаграммы процессов, dfd- и erd — диаграммы, а тут пришло время писать отчет — подумал заморочиться…
ДРАКОН — те же блок-схемы, вид сбоку. Я про него слышал краем уха, но он предназначен, насколько я понял, для такого традиционного структурного программирования. И он сам вроде бы язык, только визуальный :)
У меня был опыт работы с Max/MSP — тоже визуальный язык, но объектный и для работы с аудио и MIDI. С тех пор если есть выбор, писать или рисовать, я предпочитаю писать :)
DFD и ERD — это совсем другая история, они да, нужные и полезные :)
У меня был опыт работы с Max/MSP — тоже визуальный язык, но объектный и для работы с аудио и MIDI. С тех пор если есть выбор, писать или рисовать, я предпочитаю писать :)
DFD и ERD — это совсем другая история, они да, нужные и полезные :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны Command и Strategy с точки зрения функционального программирования