И что же комфортного в такой ситуации? Со мной иногда приключается тупняк и апатия, но чувствую я себя при этом достаточно паршиво, ничего общего с моим пониманием комфорта.
Что еще хуже, проскакивала фраза «по результату в бизнесе». То есть можно ставить программисту дурацкие задачи, а потом свалить вину на него же. Радует, что не все так считают.
Ага, менеджеров не любят… Частенько материл нашего за то, что вместо программирования занимаюсь написанием ТЗ и генерю отчеты из Жиры. Но сейчас вдруг пришла в голову мысль, может быть он хороший раз умудрился заставить меня делать работу, которой никто заниматься не хочет и которая один фиг должна быть сделана
Мне кажется, тут речь немного о другом. Идея «хочешь что-то переделать — изложи концепцию письменно» мне нравится. Я сейчас сам в позиции новичка, который врубается в проект, и конечно руки чешутся переписать все «правильно», а учитывая, что до этого я полтора года оттимлидил на сложном проекте и привык к тому, что мои технические решения принимаются, держать себя в руках сложновато.
Функциональный подход дает возможность представить программу как стрелочку между состоянием мира на момент получения входных данных и состоянием на момент получения результата. Если стрелочка слишком сложная, то она разбивается на композицию более простых стрелочек. Это просто более высокий уровень абстракции.
Бывают же константы, бывают процедуры, бывают контейнеры (объекты, структуры и т.п.)
Константы — это функции возвращающие одинаковый результат при любых входных данных
Процедуры — монады
Контейнеры — функторы
Никто не мешает писать в императивном или ООП стиле на функциональном языке, все эти концепции на месте, только называются и выглядят непривычно.
Вы действительно не поняли задачу, ну предположим, что синтаксис вам не понятен, но комментарии на русском прочесть же можно?
$ cat q.hs
solve x = go where go = fmap ($ go) x
main = print $ solve [const 42 -- константа 42
, succ . (!! 0) -- нулевая ячейча + 1
, sum . take 2] -- сумма первых двух ячеек
$ runhaskell q.hs
[42,43,85]
Быстрая сортировка ведь есть в стандартной библиотеке C++?
Ну а что вы хотели? Чтобы я привел пример задачи, которую никто еще раньше не решал?
Что касается программы с ячейками — во-первых, я не очень понял задачу.
Реализовать табличный процессор, на входе имеем список констант и функций от этих констант, на выходе тот же самый список, в котором все функции вычислены.
Могу еще пример привести, некогда один хабраюзер решал задачу генерации JSON на C++ http://habrahabr.ru/post/230079/ и даже написал статью на эту тему. Я в комментариях привел пример того, как ту же самую задачу решить на haskell http://habrahabr.ru/post/230079/#comment_7786101. Сравните объем и понятность кода из комментария и код из статьи.
Но ни разу почему-то не пришлось решать задачи, которые я посчитал бы удобным решать на чисто функциональных языках
Может быть дело не в задачах, а в вашем субъективном мнении на счет удобства тех или иных языков? На самом деле, в этом нет ничего плохого, я тоже предпочитаю использовать те инструменты, которые знаю лучше всего, и это к сожалению не haskell. Только это еще не повод отказывать себе в изучении чего-то нового.
Правда, я ни разу пока не встречал задачи, которую было бы сильно сложнее написать императивным/объектным стилем.
Ну обычно тут приводят в пример быструю сортировку (не очень корректный пример, т.к. она не in-place, но оценить выразительность дает):
qsort [] = []
qsort (x:xs) = qsort [a | a <- xs, a <= x] ++ [x] ++ qsort [a | a <- xs, a > x]
Императивный код с циклами и индексами выглядит намного ужаснее.
Еще мне нравится такой пример, вполне себе практический, представим себе электронную таблице типа экселевской, пусть это будет список с ячейками в которых лежат значения и функции зависящие от этих значений, попробуем написать код вычисляющий значения для всех ячеек:
solve x = go where go = fmap ($ go) x
main = print $ solve [const 42 -- константа 42
, succ . (!! 0) -- нулевая ячейча + 1
, sum . take 2] -- сумма первых двух ячеек
Это валидная программа на haskell, а теперь попробуйте написать то же самое в императивном стиле.
Что касается GUI, тут я соглашусь, задачи программирования GUI очень хорошо мапятся на ООП.
А на том же C++ можно по всякому — и так, и эдак, и с подвывертом.
К ответу на этот вопрос можно подойти с разных сторон.
Во-первых, у ФП есть очевидное преимущество в области параллельных вычислений (отсутствие защищаемого состояния и безразличие к порядку вычисления), а т.к. сейчас даже в телефонах по 4 ядра, это становится все более и более актуальным.
Что касается понятности, эффективности и выразительности, то делать выводы о ФП по достаточно извращенному примеру, использующему только лямбда исчисление — не правильно. Естественно есть более выразительные функциональные языки предоставляющие синтаксис для простых и красивых абстракций. В реальной жизни программист для вычисления факториал напишет например такой код на haskell:
fact n = product [1..n]
Или без использования стандартной библиотеки:
fact 0 = 1
fact n = n * fact (n - 1)
Ничего страшного и непонятного в таком коде нет, какие-то подходы могут быть непривычны, но это далеко не rocket science. Подтверждением этому факту служит то, что многие подходы ФП (map, reduce, лябмды, замыкания и т.д.) благополучно переползли в императивные языки и не вызывают проблем у среднестатистического программиста.
Теперь о том, зачем понимать лямбды, комбинаторы и прочее. Я думаю, что мало кто возьмется спорить с тем, что программисту на любом императивном языке полезно понимать семантику указателей, немножко знать Си и иметь хотя бы поверхностное понимание того как работает регистровая машина.
Понимание лябмда-исчисления настолько же полезно для функциональщика, т.к. является низкоуровневым представлением функциональных программ.
И еще, я просто получаю удовольствие от красивых математических концепции. Мне нравится видеть, как простые вещи (семантика л-исчисления чрезвычайно проста) комбинируясь дают неограниченно сложные структуры. Так что эстетическое восприятие программирования играет для меня не последнюю роль.
Это можно объяснить на таком примере:
Конечно можно всегда писать module.exports =…, но лучше понимать в чем дело.
Можно подумать, будто таких зданий не строят, пообщайтесь с инженерами-конструкторами :)
f0rk.tt@gmail.com
MD5: 976ad9df64fa84984466c9e4153b1e3b
Есть такая проблема. У меня, если честно, закончилось желание что либо вам объяснять. Не поняли, ну и ладно, видимо не сильно хотелось.
Функциональный подход дает возможность представить программу как стрелочку между состоянием мира на момент получения входных данных и состоянием на момент получения результата. Если стрелочка слишком сложная, то она разбивается на композицию более простых стрелочек. Это просто более высокий уровень абстракции.
Константы — это функции возвращающие одинаковый результат при любых входных данных
Процедуры — монады
Контейнеры — функторы
Никто не мешает писать в императивном или ООП стиле на функциональном языке, все эти концепции на месте, только называются и выглядят непривычно.
Не понимаю, каким образом он тут уместен?
$ cat q.hs solve x = go where go = fmap ($ go) x main = print $ solve [const 42 -- константа 42 , succ . (!! 0) -- нулевая ячейча + 1 , sum . take 2] -- сумма первых двух ячеек $ runhaskell q.hs [42,43,85]Получится элегантно решить в императивном стиле?
Ну а что вы хотели? Чтобы я привел пример задачи, которую никто еще раньше не решал?
Реализовать табличный процессор, на входе имеем список констант и функций от этих констант, на выходе тот же самый список, в котором все функции вычислены.
Могу еще пример привести, некогда один хабраюзер решал задачу генерации JSON на C++ http://habrahabr.ru/post/230079/ и даже написал статью на эту тему. Я в комментариях привел пример того, как ту же самую задачу решить на haskell http://habrahabr.ru/post/230079/#comment_7786101. Сравните объем и понятность кода из комментария и код из статьи.
Может быть дело не в задачах, а в вашем субъективном мнении на счет удобства тех или иных языков? На самом деле, в этом нет ничего плохого, я тоже предпочитаю использовать те инструменты, которые знаю лучше всего, и это к сожалению не haskell. Только это еще не повод отказывать себе в изучении чего-то нового.
Ну обычно тут приводят в пример быструю сортировку (не очень корректный пример, т.к. она не in-place, но оценить выразительность дает):
Императивный код с циклами и индексами выглядит намного ужаснее.
Еще мне нравится такой пример, вполне себе практический, представим себе электронную таблице типа экселевской, пусть это будет список с ячейками в которых лежат значения и функции зависящие от этих значений, попробуем написать код вычисляющий значения для всех ячеек:
Это валидная программа на haskell, а теперь попробуйте написать то же самое в императивном стиле.
Что касается GUI, тут я соглашусь, задачи программирования GUI очень хорошо мапятся на ООП.
Можно. Ценой кошмарных синтаксических конструкций.
Во-первых, у ФП есть очевидное преимущество в области параллельных вычислений (отсутствие защищаемого состояния и безразличие к порядку вычисления), а т.к. сейчас даже в телефонах по 4 ядра, это становится все более и более актуальным.
Что касается понятности, эффективности и выразительности, то делать выводы о ФП по достаточно извращенному примеру, использующему только лямбда исчисление — не правильно. Естественно есть более выразительные функциональные языки предоставляющие синтаксис для простых и красивых абстракций. В реальной жизни программист для вычисления факториал напишет например такой код на haskell:
Или без использования стандартной библиотеки:
Ничего страшного и непонятного в таком коде нет, какие-то подходы могут быть непривычны, но это далеко не rocket science. Подтверждением этому факту служит то, что многие подходы ФП (map, reduce, лябмды, замыкания и т.д.) благополучно переползли в императивные языки и не вызывают проблем у среднестатистического программиста.
Теперь о том, зачем понимать лямбды, комбинаторы и прочее. Я думаю, что мало кто возьмется спорить с тем, что программисту на любом императивном языке полезно понимать семантику указателей, немножко знать Си и иметь хотя бы поверхностное понимание того как работает регистровая машина.
Понимание лябмда-исчисления настолько же полезно для функциональщика, т.к. является низкоуровневым представлением функциональных программ.
И еще, я просто получаю удовольствие от красивых математических концепции. Мне нравится видеть, как простые вещи (семантика л-исчисления чрезвычайно проста) комбинируясь дают неограниченно сложные структуры. Так что эстетическое восприятие программирования играет для меня не последнюю роль.