Ну я, к примеру, написал небольшой язык программирования на F#, ради интереса. Ещё что-то там было. Естественно, это не могло пойти в продакшен, потому что нафиг никому не надо :)
Тем не менее, мне тут «программисты», которые вполне много чего-то там выпускают и делают для заказчиков, кидают мне код с параллельными массивами. Ну я ж не написал тыщу ПХПстраничек и 200 флеш-игр, так что куда им слушать меня, убогого, вопиющего, что так никто не делает с 60ых?
Я писал про аргументум ад хоминем. Вы не вняли. Извините, я умею спорить только опираясь на логику :)
Я думаю, конструктива тут больше не будет, так что пора завязывать. И спать, наконец. Мир, дружба, чистые функции и машинные инструкции? :)
Я не могу пользоваться скайпом, к сожалению, я сменил звуковуху и теперь мои наушники к ней не подходят(
Вы есть на вконтакте? В крайнем случае можно использовать хабрапочту :)
И да, мне пора уходить, так что я, вероятно, не буду отвечать ближайшие 10 часов.
">«Так как фвп не обязательно функтор и функтор не обязательно фвп»
>Я этого нигде не утверждал.
>>Утверждали, цитирую:
>>>«функтор» имеет много значений. Одно из них — >>«функция высшего порядка»"
Окей, формально моё высказывание:
"∃ значение слова функтор ≡ ФВП"
Вы отрицаете высказывание:
"∀ значение слова функтор ≡ ФВП"
«И вся теория придумана для того, чтоб писать программы проще и еффективнее.»
Да. Вы считаете, что проще написать 5 строчек или 15?
Безусловно функции в конечном счёте преобразуются в последовательность команд. Только я говорю о проектировании и архитектуре, и меня в данном контексте не интересуют машинные команды. Вы вот тоже понятиями «функтор» и «объект» оперируете. Сомневаюсь, что ими оперирует процессор.
Вообще-то знаю. Почему хорошо, что функция чистая — как раз в одном из тех линков, которые вы «знаете».
Можно задать несколько вопросов?
— Какие языки ФП Вы знаете? Как долго Вы занимались ФП?
— Почему Вы постоянно отрицаете то, что знаете? Ибо в тех ссылках, которые я вам кидал, слова противоположные Вашим. Dissociative identity disorder?
— Вы прочитали мой пост полностью или пробежали его по диагонали, думая что Вы уже всё это знаете?
Вообще говоря, если Вам интересно понять в чём различия, я с удовольствием пообщаюсь с Вами в личке. Это действительно очень объёмная тема. Я извиняюсь, что ввёл Вас в заблуждение не указав явно, что я использую отличную от Вашей терминологию.
«Ну это извините вобще ни в какие ворота не лезет.»
Да что Вы?
«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/
Пишет один из крупнейших учёных в теории типов. Сложите эти мысли, переварите их и подумайте.
«Функция в математике — зависимость одной величины от другой.
Функция в программировании — проименованая(или анонимная) последовательность операций, которая может быть вызвана повторно»
Вы не понимаете разницы между понятием функции в ФП и в императивном программировании.
То, что Вы считаете «функцией в программировании» — это «функция в императивном программировании». Функция в ФП- это сущность, принимающая нечто и возвращающая нечто. Отображение между двумя множествами. Именно поэтому мы так трясёмся с immutable data structures. Они гарантируют чистоту функций, отсутствие сайд-эффектов. И если функция чистая — мы получаем именно ту самую сущность, которая однозначно отображает одно множество в другое. Почитайте: en.wikipedia.org/wiki/Side_effect_(computer_science) en.wikipedia.org/wiki/Pure_function
Я говорю в другой парадигме, поймите же. И да, как раз Ваш опыт может играть с Вами злую шутку: ибо понимание всего этого требует серьёзной ломки стереотипов.
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Я этого нигде не утверждал.
Вы знаете английский?
Вы попытайтесь прочитать полностью то, что там написано :) не вырывая словосочетания из контекста.
Я понимаю что это разные вещи. Функция в математике и ФП — это одно и то же. Они по умолчанию являются объектами первого класса (никакой связи с ООП!). Поэтому понятие функтор там чаще всего используется в том же смысле, что и в теории категории.
Вы же говорите про ООП-функторы: т.е. workaround для изображения «функций, как объектов первого класса».
Товарищи, минусующие карму: вы хотя бы высказались, что ли.
А я говорю: «У Вас неправильные представления об уровнях абстракции и Вы, вместо того, чтобы попытаться понять мои аргументы, занимаетесь демагогией».
Об уровне моей компетентности уж поверьте, судить не Вам :) При всём уважении, мы занимаемся разными вещами. И заметьте, я спокойно пытался объяснить Вам свою позицию, а Вы перешли на личности.
Русская википедия — это тот самый авторитетный источник, по сравнению с которым материалы научных конференций и книги малоизвестного)) издательства O'Reilly ничто.
«Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.»
Общепринятое определение приведено в статье:
«Функция высшего порядка – это функция, которая принимает в качестве аргумента или возвращает как результат другую функцию.»
Оно такое. Открываете любой учебник по ФП и читаете.
Я бы рекомендовал Вам немного выйти из поклонения ООП и почитать хорошие книжки по ФП. И перестать считать себя умнее всех :)
Я посмотрел и мне понравилась Ваша игра, про которую Вы писали пост насчёт AppStore. С удовольствием поиграл, спасибо :)
Но это никак не показывает уровень ваших теоретических знаний, особенно в области функционального программирования.
«Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.»
Вы понимаете, что такое higher-order functions и functions as first-class objects? Здесь нет ни того, ни другого.
«ЭТО СТРАТЕГИЯ!»
Это функция высшего порядка найтиИУбить(), которая реализует поведение характерное для паттерна Strategy. Это не Strategy. Вот Strategy: interface СпособУбийства {
void Убить();
}
class УбитьЯдом {
void Убить(){
...;
}
}
class УбитьЧумой {
void Убить(){
...;
}
}
void УбитьВсехЧеловеков(СпособУбийства как){ //передаём объект, а не функцию => не ФВП!
...
как.Убить();
}
«Если вы считаете, что патерн стратегия в функциональных языках отстутствует.»
В чистых функциональных — да. В поддерживающих ООП — Вы можете его реализовать, но зачем?
«Странно, а кто так делает?»
Я так понял, что Вы этим занимаетесь последние несколько постов :)
«Вообще функтор и функция разные вещи и через дробь их писать не хорошо»
Вообще говоря понятие «функтор» имеет много значений. Одно из них — «функция высшего порядка». Не просто функция, а именно функция_высшего_порядка.
)) Я студент 4ого курса и занимаюсь программированием с 12 лет. Если Вы можете привести контраргументы — приведите их, но ссылаться на возраст и «отсутствие практики» — по меньшей мере странно.
Самое интересное, что Вы, похоже, не очень поняли то, что написано в главе «Лирическое отступление: разница между архитектурой, проектированием и реализацией». Возможно, я так плохо объясняю, так что советую почитать это.
Ну и да, странно слышать про «пробелы в базовых понятиях» от человека, который утверждает, судя по всему, что даже ссылки на функции и те, бедняжки, реализуют паттерн Strategy :)
Чем «конкретная реализация алгоритма» отличается от функции?
убейВсехЧеловековЯдернойБомбой() — «функция» и «конкретная реализация алгоритма».
убейВсехЧеловековЧумой() — опять «функция» и «конкретная реализация алгоритма».
Заметьте, Вы подменяете методы реализации
— передача ссылки на функцию другой функции
— перегрузка ()
и понятие ФВП паттерном Strategy, который используется только в ОО проектировании. Это разные абсолютно уровни абстракции. Весь паттерн — это, по сути, workaround в ситуации: «нам нужны функции как объекты первого класса для решения задачи, но у нас нет функций как объектов первого класса». Странно представлять само понятие функтора/функции высшего порядка/оператора как «реализацию» паттерна ОО проектирования, Вам не кажется?
Вообще, похожая дискуссия завязалась у меня с моим преподавателем по проектированию, когда я представил ему презентацию на эту тему (там ещё рассматривался State). Именно это побудило меня сделать такое большое введение. Это стало всё в итоге моей курсовой работой, и когда он прочитал её, со всеми этими обоснованиями, внезапно оказалось, что между нами нет противоречий, а было только непонимание.
Я думаю, я недостаточно чётко сформулировал цель: моя задача — не реализовывать паттерны, моя задача показать, что некоторые паттерны в некоторых ситуациях не нужны. Поэтому во введении акцент делается именно на том, что паттерны — это не альфа и омега, а просто метод выбора классов задач.
Эм. Мне действительно трудно понять, как можно инкапсулировать 1 в 1. Функция в данном случае — это функция, которая сама по себе значение. Её никуда инкапсулировать не нужно. Сама идея инкапсулировать функцию происходит от того, что она не является в неком языке объектом первого класса.
Тем не менее, использовать ссылки на функции, переданные другим функциями — это ой как неприятно (Вы ведь эту технику подразумевали под «функтором в С и С++»?). Насколько я понимаю, этот метод не типобезопасен?
Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором вообще нет объектов? Я опять хочу заметить, что излишнее обобщение в данном случае не приведёт ни к чему хорошему.
Если использовать такую логику, то надо или в каждой статье начинать с правил сложения, или же писать статью про сильное взаимодействие примерно так: «сильное взаимодействие — это сильное взаимодействие».
«Читать 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 :)
Насчёт первого:
1. Я исходил из предположения, что не всем известны сами паттерны достаточно хорошо. Поэтому я кратко их описал
2. Я предполагал, что не всем известно само понятие ФВП — и я предполагаю, что гораздо ценнее знать, почему мы можем не создавать класс для обёртки функции и т.д.
2. Я отметил во введении, что эта мысль (фактически в той же форме, что и у Вас) присутствует в книге «Functional Programming for the Real World» — и написал, что мне хотелось именно показать хоть какой-то пример, а не просто голую формулировку.
Насчёт второго:
Первая часть поста описывает как раз почему паттерны ООП — это решения уровня проектирования, а выбор парадигмы — решение уровня архитектуры. Есть архитектурные паттерны, например MVC, клиент-сервер и т.д. — они да, весьма мало связаны с целевой парадигмой. Но паттерны ОО проектирования — очевидно, абстракция более низкого уровня.
Сама суть паттерна «стратегия» — это инкапсуляция функции в класс. Я не вижу класса в моём решении :) Вообще говоря, я думаю, что не надо придавать паттернам какой-то дополнительный смысл — паттерн «стратегия» решает конкретные задачи в рамках ООП.
Тем не менее, мне тут «программисты», которые вполне много чего-то там выпускают и делают для заказчиков, кидают мне код с параллельными массивами. Ну я ж не написал тыщу ПХПстраничек и 200 флеш-игр, так что куда им слушать меня, убогого, вопиющего, что так никто не делает с 60ых?
Я писал про аргументум ад хоминем. Вы не вняли. Извините, я умею спорить только опираясь на логику :)
Я думаю, конструктива тут больше не будет, так что пора завязывать. И спать, наконец. Мир, дружба, чистые функции и машинные инструкции? :)
Я занимаюсь им и соответствующими разделами математики последние 1,5 года. Я не гуру ни в коем разе, но.
«Ответ то я знаю. Вообще не занимались.»
Poor me.
«приведите слова противоположные моим из этих линков.»
Например, почитайте ссылки, которые я Вам привёл касательно функторов)) Внимательно)
Итак, мне пора спать :) Продолжим этот разговор позже в личке, если желаете.
Вы есть на вконтакте? В крайнем случае можно использовать хабрапочту :)
И да, мне пора уходить, так что я, вероятно, не буду отвечать ближайшие 10 часов.
>Я этого нигде не утверждал.
>>Утверждали, цитирую:
>>>«функтор» имеет много значений. Одно из них — >>«функция высшего порядка»"
Окей, формально моё высказывание:
"∃ значение слова функтор ≡ ФВП"
Вы отрицаете высказывание:
"∀ значение слова функтор ≡ ФВП"
«И вся теория придумана для того, чтоб писать программы проще и еффективнее.»
Да. Вы считаете, что проще написать 5 строчек или 15?
Безусловно функции в конечном счёте преобразуются в последовательность команд. Только я говорю о проектировании и архитектуре, и меня в данном контексте не интересуют машинные команды. Вы вот тоже понятиями «функтор» и «объект» оперируете. Сомневаюсь, что ими оперирует процессор.
Вообще-то знаю. Почему хорошо, что функция чистая — как раз в одном из тех линков, которые вы «знаете».
Можно задать несколько вопросов?
— Какие языки ФП Вы знаете? Как долго Вы занимались ФП?
— Почему Вы постоянно отрицаете то, что знаете? Ибо в тех ссылках, которые я вам кидал, слова противоположные Вашим. Dissociative identity disorder?
— Вы прочитали мой пост полностью или пробежали его по диагонали, думая что Вы уже всё это знаете?
Да что Вы?
«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
Я говорю в другой парадигме, поймите же. И да, как раз Ваш опыт может играть с Вами злую шутку: ибо понимание всего этого требует серьёзной ломки стереотипов.
«Так как фвп не обязательно функтор и функтор не обязательно фвп»
Я этого нигде не утверждал.
Вы знаете английский?
Я понимаю что это разные вещи. Функция в математике и ФП — это одно и то же. Они по умолчанию являются объектами первого класса (никакой связи с ООП!). Поэтому понятие функтор там чаще всего используется в том же смысле, что и в теории категории.
Вы же говорите про ООП-функторы: т.е. workaround для изображения «функций, как объектов первого класса».
Товарищи, минусующие карму: вы хотя бы высказались, что ли.
Об уровне моей компетентности уж поверьте, судить не Вам :) При всём уважении, мы занимаемся разными вещами. И заметьте, я спокойно пытался объяснить Вам свою позицию, а Вы перешли на личности.
«Функтор имеет одно значение.»
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
Всё ещё в этом уверены?
«Функция высшего порядка это функция которая принимает функторы как аргумент или возвращает функтор. Все. Никак иначе.»
Общепринятое определение приведено в статье:
«Функция высшего порядка – это функция, которая принимает в качестве аргумента или возвращает как результат другую функцию.»
Оно такое. Открываете любой учебник по ФП и читаете.
Я бы рекомендовал Вам немного выйти из поклонения ООП и почитать хорошие книжки по ФП. И перестать считать себя умнее всех :)
Но это никак не показывает уровень ваших теоретических знаний, особенно в области функционального программирования.
* class УбитьЧумой: СпособУбийства
«Здесь ЕСТЬ функции. но НЕТ стратегии. ЕСТЬ 2 реализации алгоритма из одного семейства но стратегии НЕТ.»
Вы понимаете, что такое higher-order functions и functions as first-class objects? Здесь нет ни того, ни другого.
«ЭТО СТРАТЕГИЯ!»
Это функция высшего порядка найтиИУбить(), которая реализует поведение характерное для паттерна Strategy. Это не Strategy.
Вот Strategy:
interface СпособУбийства {
void Убить();
}
class УбитьЯдом {
void Убить(){
...;
}
}
class УбитьЧумой {
void Убить(){
...;
}
}
void УбитьВсехЧеловеков(СпособУбийства как){ //передаём объект, а не функцию => не ФВП!
...
как.Убить();
}
«Если вы считаете, что патерн стратегия в функциональных языках отстутствует.»
В чистых функциональных — да. В поддерживающих ООП — Вы можете его реализовать, но зачем?
«Странно, а кто так делает?»
Я так понял, что Вы этим занимаетесь последние несколько постов :)
«Вообще функтор и функция разные вещи и через дробь их писать не хорошо»
Вообще говоря понятие «функтор» имеет много значений. Одно из них — «функция высшего порядка». Не просто функция, а именно функция_высшего_порядка.
Самое интересное, что Вы, похоже, не очень поняли то, что написано в главе «Лирическое отступление: разница между архитектурой, проектированием и реализацией». Возможно, я так плохо объясняю, так что советую почитать это.
Ну и да, странно слышать про «пробелы в базовых понятиях» от человека, который утверждает, судя по всему, что даже ссылки на функции и те, бедняжки, реализуют паттерн Strategy :)
убейВсехЧеловековЯдернойБомбой() — «функция» и «конкретная реализация алгоритма».
убейВсехЧеловековЧумой() — опять «функция» и «конкретная реализация алгоритма».
Заметьте, Вы подменяете методы реализации
— передача ссылки на функцию другой функции
— перегрузка ()
и понятие ФВП паттерном Strategy, который используется только в ОО проектировании. Это разные абсолютно уровни абстракции. Весь паттерн — это, по сути, workaround в ситуации: «нам нужны функции как объекты первого класса для решения задачи, но у нас нет функций как объектов первого класса». Странно представлять само понятие функтора/функции высшего порядка/оператора как «реализацию» паттерна ОО проектирования, Вам не кажется?
Вообще, похожая дискуссия завязалась у меня с моим преподавателем по проектированию, когда я представил ему презентацию на эту тему (там ещё рассматривался State). Именно это побудило меня сделать такое большое введение. Это стало всё в итоге моей курсовой работой, и когда он прочитал её, со всеми этими обоснованиями, внезапно оказалось, что между нами нет противоречий, а было только непонимание.
Я думаю, я недостаточно чётко сформулировал цель: моя задача — не реализовывать паттерны, моя задача показать, что некоторые паттерны в некоторых ситуациях не нужны. Поэтому во введении акцент делается именно на том, что паттерны — это не альфа и омега, а просто метод выбора классов задач.
Тем не менее, использовать ссылки на функции, переданные другим функциями — это ой как неприятно (Вы ведь эту технику подразумевали под «функтором в С и С++»?). Насколько я понимаю, этот метод не типобезопасен?
Как можно реализовать передачу объекта (!), содержащего функцию, в языке, в котором вообще нет объектов? Я опять хочу заметить, что излишнее обобщение в данном случае не приведёт ни к чему хорошему.
«Читать 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 :)
1. Я исходил из предположения, что не всем известны сами паттерны достаточно хорошо. Поэтому я кратко их описал
2. Я предполагал, что не всем известно само понятие ФВП — и я предполагаю, что гораздо ценнее знать, почему мы можем не создавать класс для обёртки функции и т.д.
2. Я отметил во введении, что эта мысль (фактически в той же форме, что и у Вас) присутствует в книге «Functional Programming for the Real World» — и написал, что мне хотелось именно показать хоть какой-то пример, а не просто голую формулировку.
Насчёт второго:
Первая часть поста описывает как раз почему паттерны ООП — это решения уровня проектирования, а выбор парадигмы — решение уровня архитектуры. Есть архитектурные паттерны, например MVC, клиент-сервер и т.д. — они да, весьма мало связаны с целевой парадигмой. Но паттерны ОО проектирования — очевидно, абстракция более низкого уровня.
Сама суть паттерна «стратегия» — это инкапсуляция функции в класс. Я не вижу класса в моём решении :) Вообще говоря, я думаю, что не надо придавать паттернам какой-то дополнительный смысл — паттерн «стратегия» решает конкретные задачи в рамках ООП.