Как познакомить вашу команду с функциональным стилем кодирования?

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

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

Я уже дал пару презентаций о функциональных и кодовых парадигмах. К сожалению, мы не используем надлежащий функциональный язык программирования, такой как Haskell (в основном это унаследованный код на C, C ++, Java), поэтому мы должны делать с ним все, что есть.

Лука Болоньезе сделал эту фантастическую презентацию, где он представляет функциональное программирование (чтобы представить F #) на примере кофе, который действительно хорош и очень помог мне представить функциональное программирование друзьям и коллегам.

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

Ваши коллеги пишут код вне работы?

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

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

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

Помните, что есть функциональные языки, которые будут работать в вашем стеке (scala / closure оба работают на JVM). Это не «чисто функционально», как у Haskell, но это хорошее начало в долгом путешествии.

Если у вас есть контроль над наймом, нанимайте людей, которые имеют некоторый функциональный опыт (или, по крайней мере, заинтересованы в функциональном программировании).

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

Это все о продаже его разработчикам ... менеджмент - это совершенно другой зверь.

Переход от императивного к чисто функциональному программированию - это большое изменение с крутой кривой обучения. Я бы предложил попробовать менее быстрый переход, и в этом случае у вас есть много вариантов. Например, Python поддерживает списочные выражения и генераторные выражения , Ruby поддерживает функции высшего порядка через блоки кода и т. Д. Поскольку вы упомянули Java, если у всех вас есть фон Java и вы хотите полностью функциональную поддержку программирования, вы можете попробовать Scala .

Нанять (или нанять босса) функционального программиста

В конце концов, это не повредит вашей команде.

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

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

Если разница в сложности так велика, как вы говорите, то это должно говорить само за себя.

+1 к faif за упоминание Scala: это началось как комментарий к этому ответу, но стало слишком большим ...

Я хотел узнать кое-что о функциональном программировании (из C / C ++, немного Python и ржавой Java); Я попытался погрузиться в глубокий конец с Ocaml, а затем Haskell и Just Not Get It. Затем я попробовал Scala и обнаружил, что он позволяет мне использовать функциональные вещи в удобной среде OOP / Java-ey, где я легко могу вернуться к привычному императивному стилю, когда функциональный подход ускользает от меня. Некоторые могут жаловаться на «мультипарадигмальную», «гибридную» природу языка, означающую, что вам никогда не придется напрягаться, чтобы перейти на «чистый функционал», но я бы сказал, что это означает, что вы можете прагматично относиться к вещам и знать, что быть в состоянии сделать реальные вещи легко так или иначе, когда вам нужно.

Несколько лет спустя (и более 200 решений Project Euler Scala в Scala позже) встреча с функционалом определенно повлияла на мой Python (гораздо больше использования карт, фильтров, сокращений, лямбда-выражений, itertools, составления списков и передачи функций вокруг, чем я ». я когда-либо размышлял прежде) и в меньшей степени C ++: возможно, немного больше попыток использовать функциональные атрибуты STL, но главное влияние в том, что мне гораздо удобнее использовать конструкции TBB / карты-редукции, и мне действительно нравится, как использование неизменяемости может укротить сложность в многопоточном коде.

Итак, лично я бы на вашем месте привел пример внедрения Scala в некоторые разработки Java-мира, желательно, продемонстрировав некоторые примеры, которые чрезвычайно упростят что-то, и получат преимущества, на которые вы претендуете. Что будет дальше, так это весь бизнес «отстаивания» новых идей и продвижения изменений ... что может показаться гораздо более серьезной проблемой.

Я хотел бы рекомендовать постепенный подход с использованием Scala. И я бы рекомендовал начать с книги создателя Scala «Программирование в Scala, 2-е издание» . Эта книга является ФАНТАСТИЧЕСКИМ, когда медленно знакомит с (FP) функциональным программированием с использованием Scala. И, показывая движение к FP, это не отвергает OO. На самом деле, он использует это. Я делаю свой второй проход через это сейчас.

По сути, Scala позволяет делать Java / OO "без точек с запятой". И тогда можно попробовать немного FP, не прибегая к целой свинье. Например, при обучении владению FP я обычно сосредотачиваюсь на ссылочной прозрачности на уровне методов класса, но пусть мои методы имеют как можно больше var-s, изменчивости и императивности, что необходимо для первого прохода в реализация. Затем я сосредотачиваюсь на медленной переработке каждого метода, чтобы переместить его в сторону чистого FP. И я также использую сайт-партнер для StackOverflow, CodeReview, чтобы получить помощь в моем переходе мышления / мышления. Вот пример недавнего поста, который я сделал, делая эту самую вещь.

Во всяком случае, удачи в вашем путешествии FP. :)