почему программирование такое сложное

Программирование — это сложно

Большинство новичков в программировании рано или поздно сталкивается с такой чарующей фразой: «Программирование — это просто, ему может научиться любой». Эта фраза сопровождается угрожающим сообщением о том, что людям, занимающимся гейткипингом, надо прекратить. Этой статьёй я хочу сказать, что это неправда. Программирование — это сложно, оно не для каждого, и хотя сейчас им может заняться каждый, большинству определённо не стоит писать код.

Программирование легкодоступно

Когда глупые люди говорят, что программировать просто, что им может заниматься каждый, они на самом деле имеют ввиду доступность сферы программирования. Если у вас есть простейшее средство доступа к Интернету, то достаточно легко получить доступ к ресурсам для изучения. Ни одна из наук не доступна настолько, как компьютерная наука, и большинство работ по ней выложено в открытый доступ — компьютерная наука процветает в Интернете, и хотя отдельные её ветви закрыты, большинство контента доступно свободно и процветает благодаря этой доступности. Вы можете скачивать компиляторы, редакторы, IDE, даже получить доступ к документации, обсуждать с другими людьми свои проблемы, и так далее. Это огромное сообщество, уровень гостеприимности и открытости которого несравним с любой другой наукой в истории человечества.

И в самом деле, вам не нужно знать много, некоторые программы можно написать буквально через полчаса знакомства с программированием. Программирование доступно настолько, насколько не доступна ни одна другая наука.

Но легкодоступность не означает простоту изучения. Если я могу смешать три ингредиента и сделать омлет, то это не делает меня шеф-поваром. Я могу готовить несколько блюд, но никогда не скажу, что готовка — это просто. Приготовление пищи — это сложная задача, требующая терпения и внимания к деталям, много знаний и опыта.

Программирование — это любопытное сочетание творчества и точных наук; но никто и никогда не говорил, что творчество — это «просто». Некоторые вещи легко осваиваются некоторыми людьми, другие сложны для понимания.

Некоторые аспекты программирования просты

Да, в этом можно не сомневаться: отдельные аспекты просты. Существуют вещи, которые вы можете сделать, в конечном итоге получив, например, скелет приложения для блога. Любой (под опытным руководством) может сделать профессионально выглядящую веб-страницу за первые часы изучения HTML. Можно легко задать вопрос и найти решение на StackOverflow, можно запросто скопипастить решение на свои веб-страницы.

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

Однако для разных людей простыми бывают разные вещи. То, что мне кажется невероятно сложным, другим кажется невероятно простым. То, что кажется простым, становится проблемой для других. Нет консенсуса о том, что для кого легко, но для всех есть простые вещи, зависящие от того, по какому пути обучения они шли. Тем не менее…

Большинство аспектов программирования сложно

Такова правда: если человек начинает делать нечто более сложное, чем простая веб-страница или простая демо-программа, всё становится сложным, и чем больше вещей соединяется воедино, тем более сложной и утомительной становится задача. И именно этого вам не скажет лжец, уверяющий, что «программирование — это просто». Решать программные головоломки сложно, особенно, когда они не задумывались как головоломки.

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

Самозванство и мошенническое позитивное мышление

Как часто вы слышали о синдроме самозванца? Если вы слушаете выступление на тему «программирование — это просто», то, вероятно, слышали о нём, и часто на эти темы говорят одни и те же люди. Синдром самозванца — это когда человек чувствует себя недостаточно компетентным для работы, за которую ему платят, и ощущает, что он не заслужил свой успех; но слышали ли вы о случаях, когда люди на самом деле сталкивались с кажущимся непродуктивным топтанием на месте, при котором им приходится исправлять или совершенствовать результаты собственной работы, или когда они не могут быстро найти ответ на Stack Overflow. Чаще всего я слышу о самозванцах в программировании, когда их терпение лопается, когда они больше не могут соответствовать нереалистичным стандартам, которые они создали для себя, когда они не могут двигаться вперёд со скоростью, к которой привыкли. (У меня есть собственные претензии к синдрому самозванца, но об этом в другой раз.)

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

Я сказал, что сфера программирования плодородна для новичков, и это правда. Но то, что плодородно для злаков, плодородно и для сорняков, и для них особенно. Нам нужно говорить о таких людях, пользующихся преимуществами плодородной почвы. А поскольку в этой сфере множество новичков, то там есть множество людей, пользующихся ими.

Это происходит множеством различных способов; некоторые из таких людей даже не осознают, что делают это, они просто инстинктивные деляги, продающие свои навыки по слишком большой цене. Обычно они выглядят так: двухлетний опыт работы в сфере разработки ПО, пишут книги и раздают советы, иногда за приличную цену. Мы встречаем их на конференциях, их рекламируют в статьях или в других медиа, иногда они разыгрывают карту «культурного разнообразия» (diversity), иногда — карту успешного новичка, продвигая себя и пользуясь доверчивостью толп начинающих.

И чтобы создавать ложный имидж в этой сфере, даже не нужно быть абсолютным лжецом. Достаточно играть с чувствами людей. Например, говорить им нечто ошибочное, что люди хотят слышать. Нужно подобрать ключевые слова, которые будут льстить большинству аудитории; «программирование» — это одно из них, потому что программирование — крайне размытое понятие, а получить звание «программист» желают многие, так же, как и звание «сениор», к которому стремятся люди, мечтающие стать сениорами в свои двадцать с небольшим лет. Нужно найти ярлык, лестный вашей аудитории, и применить его к ней. Именно так мы получаем лозунг «программирование — это просто» (это не так), или «HTML — это язык программирования» (это не так), или «программирование — это мастерское пользование поиском в Google/StackOverflow».

Чтобы подчеркнуть своё утверждение, затем вы демонстрируете врага. «Не позволяйте никому говорить, что это неправда» — простой, но эффективный способ внушить аудитории образ мышления «вы против враждебного мира». Неплохо также использовать словечко «гейткиперы», ведь рассуждения о привилегиях и людях, охраняющих их от аудитории, привлекательны. Они не дают вам подняться, они несправедливы, они лгут о трудностях, они заставляют вас заниматься сложной, скучной работой. Такая методика применима не только к программированию, это простая техника манипуляции толпой — если есть враги, то это простой способ сплотить аудиторию против них. Но какой бы ни была эта методика, основная задача манипулятора — размытость содержимого сообщения, чтобы было сложно его опровергнуть.

Давайте обсудим мои примеры. На объяснение лозунга «программирование — это просто» мне уже понадобилось 1385 слов, а статья ещё не закончена. Объяснить «HTML — это язык программирования» в чём-то сложнее из-за нечёткого значения термина «программирование». Строго говоря, HTML не является реальным программированием, это язык представления разметки. Он является неполным описанием того, как выглядит и что содержит веб-страница. HTML — обязательный для любого связанного с вебом проекта инструмент, но он не используется изолированно, программирование происходит не на нём. Но если кто-то говорит вам, что HTML — это язык программирования, то обычно защищает своё заявление тем, что гейткиперы ограничивают значение слова «программирование». При этом говорящие это редко заинтересованы в изучении истинного значения собственных слов. Как я говорил, «программист» — это звание, и подобно другим почётным званиям, оно заставляет людей, особенно некомпетентных, защищать его.

Иллюзия «я могу сделать то же, что и ты»

С заявлением «программирование — это мастерское пользование поиском в Google/StackOverflow» всё сложнее. Потому что это и правда, и ложь одновременно. Мастерское владение поиском в вебе — очень важный навык современного разработчика. Я учился в мире, где этого ещё не было, где не существовало Google, где человеку нужно было изучать документацию и иногда читать сотни страниц, чтобы понять, как всё работает. И это если документация была; в противном случае приходилось только пробовать, терпеть неудачу и пробовать снова. Однако сегодня пробовать не нужно, существуют готовые тулкиты, библиотеки или языки программирования (и даже их коммерческие версии), чётко заточенные на поиск ответа. Документация теперь предназначается не для чтения пользователями, а для индексации поисковыми движками и для того, чтобы люди работали с ней при помощи поисковых движков. Однако больше всего современные инструменты полагаются на сайт ответов Stack Overflow.

На самом деле, зависимость людей от Stack Overflow — это, вероятно, самое пугающее, что произошло с сообществом программистов за последние 10 лет. Stack Overflow — это мощный костыль, мешающий вам двигаться самостоятельно, потому что слишком легко искать ответы на нём. А когда люди перестают мыслить самостоятельно, то начинают писать неразумные вещи.

Если вы, как новичок, смотрите, что делают опытные разработчики, то это выглядит простым. Кажется, то, что делают они, может сделать каждый. Это выглядит совершенно посредственно. Существует миф о суперпрограммистах, делающих всё по-своему. Голливуд представляет их как людей, вводящих код со скоростью света, потому что единственный способ продемонстрировать высокий навык персонажа в своём деле — показать, что он справляется с работой быстрее, чем кто-либо другой (Голливуд показал бы человека, лучше всего отсчитывающего десять секунд, как того, кто справляется за пять). Смысл в том, что это выглядит просто, но на самом деле это не так. Потому что опыту новичка не хватает кругозора, сосредоточенности на действительно важном. Новичку научиться считать до десяти мешает только незнание синтаксиса цикла, для опытного разработчика синтаксис — это то, что замедляет его реализацию выполнения операций с коллекцией отфильтрованных данных.

Утверждение «программирование — это просто» не даёт людям развиваться

Этот пост возник благодаря представленному ниже твиту (и этой статье на румынском, но я остановлюсь на англоязычном твите.

— Когда я говорю кому-то, что я программист, то меня сразу начинают считать суперумной. Ребята, можем ли мы как-то вместе попробовать объяснить людям, что кодить не так сложно. В первую очередь, это в буквальном смысле гугление и устранение сделанных нами ошибок. Писать код может каждый.

— Я понимаю задачу этого поста и знаю, что он был написан не из злого умысла, однако учиться кодить сложно и это утверждение «писать код может каждый»/«кодинг — это не так уж сложно» заставляло меня чувствовать себя тупой, когда я была новичком.

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

Автор первого твита сказала что-то в духе «люди считают меня умной, потому что я программист» и «главное в гуглении и исправлении своих ошибок». Но на самом деле программирование не об этом, и такой преувеличенный, ограниченный взгляд говорит мне, что её опыт в разработке ПО достаточно мал. И знаете, что пугает? Она работает над сайтом под названием «thecodinginterview.com», то есть является популярным источником советов для начинающих. И я даже не хочу начинать тему того, насколько аморально это мошенничество с «coding interview».

Позитивное мышление безотказно, потому что позитивность никогда не подвергают проверкам; и она полностью пропадает, когда ситуация действительно становится серьёзной. Все ошибки — ваша вина, потому что «кодить может каждый» и «кодинг не так сложен». Когда ты вынужден столкнуться со своими ошибками, ты остаёшься в одиночестве, потому что никакая чушь о позитивном мышлении не может их устранить.

Установка «программирование — это сложно» не должна быть пугающей

Кое-кто утверждает, что если врать новичкам о том, насколько на самом деле сложно программирование, то это их отпугнёт. Не уверен, что людей когда-нибудь останавливал тот факт, что выбранное ими занятие сложно. В конце концов, бОльшая часть нашей поп-культуры посвящена героям, выполняющим сложные задачи. Мне кажется, что именно эта культура изнежила мозги людей, считающих, что если результат не будет мгновенным, то он не стоит усилий. Но когда я начинал программировать, никто не говорил мне, что программировать легко. Я ожидал, что оно будет сложным.

Я знаю, что у многих есть одержимость «достигаторством», они хотят овладеть программированием, стать сениором в 22 года. Я удержался от преследования столь глупой затеи. Я знал, что программирование сложно и что достижение моей цели может быть невозможным. В каком-то смысле, так и есть: я изучал программирование, чтобы уметь писать собственные игры, и спустя более полувека я так и не создал ни одной. Но это дало мне чёткое понимание масштаба моего дела.

Я говорю это не для того, чтобы демотивировать начинающих. Статья всего лишь должна подготовить их к тому, что ждёт их впереди. Так что если вы хотите сказать что-то новичку, то скажите следующее: «В программировании есть простые и сложные вещи. Если ты будешь достаточно терпелив, то со временем сложные вещи станут интересными, а простые станут сложнее».

Но не говорите ему, что программирование — это просто. Это не так.

На правах рекламы

Заказать у нас сервер очень просто! Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!

Источник

Почему так трудно стать программистом?

Вот уже около полугода, в качестве добровольного «лаборанта» участвую в работе клуба начинающих программистов. Хочу поделиться своими итогами этих наблюдений и собственными мыслями насчет того, почему далеко не все желающие способны освоить эту профессию. Как-то читал о том, что заниматься IT-технологиями в состоянии не более 9% людей в любом обществе. Когда создавался наш клуб, у меня появилась реальная возможность опровергнуть или подтвердить этот тезис и понять, почему же «айтишников» так мало.

Среда для исследования

Наш клуб могут посещать все желающие. Основная масса узнает о нем из рекламы курсов для начинающих пользователей ПК. Многие приходят именно оттуда. Это очень разные люди и все они, конечно, слышали о высоких зарплатах в IT-отрасли и полны энтузиазма освоить столь выгодную в финансовом плане профессию. Но действительность быстро охлаждает пыл большинства из них.

Изучить программирование непросто

Программирование включает набор сложнейших дисциплин, для освоения которых необходим обширный объем специфических знаний. Для «айтишника» в этом нет ничего нового но для неофитов это удивительно и неприятно.
Оказывается, что несмотря на энтузиазм и огромное желание зарабатывать в будущем хорошие деньги, для того, чтобы присвоить одну переменную другой, освоить пару операторов и выполнить с ними какие-то действия, многим требуется вовсе не пара часов, а несколько месяцев. Причем, они уходят только на понимание этих самых, на первый взгляд, довольно примитивных действий.
Почему это происходит? Думаю потому, что людям не имевшим прежде дела с логикой, математикой и программированием совсем непросто перестроить собственное мышление. Обычно ведь человек получает опыт, изучая окружающую его внешнюю среду и отталкиваясь от уже имеющихся знаний. Но в этом опыте нет места условиям, циклам, двоичному счислению и многому другому, что требуется для программирования. В быту и обычной жизни всё это никак не используется. Именно поэтому часть «начинающих программистов», сталкиваясь с совершенно непонятными вещами, бросают учёбу уже в первые дни или даже часы.

Необходимо научиться пользоваться инструментами ЯП, вспомнить все свои скудные знания по математике (а многие её, в принципе, не используют, разве что, только для подсчета купюр), расширить их до необходимого уровня. Да и это только на «старте». Дальше придется осваивать технологии, построенные на основе избранного языка программирования. Я уже молчу о том, что нужен ещё и английский язык, хотя бы на техническом уровне. Именно поэтому шансы у соискателя, не имеющего особых способностей, не увлекавшегося в школе информатикой и не сталкивавшегося в вузе с программированием, совсем невелики.

Конечно, есть талантливые люди, которым новые знания даются довольно быстро. Но, как показали мои наблюдения, это — редчайший случай. На моих глазах через клуб прошло множество потенциальных «специалистов». Никто из них до финиша так и не добрался. До подавляющего большинства новоявленных студентов, после месяца-двух интенсивной учебы доходило, что программирование — совершенно не их предмет. А наиболее способные поняли это гораздо быстрее.
Из примерно двух сотен людей прошедших через клуб, до сих пор переквалифицироватьcя в программисты удалось лишь двум талантливым и упорным технарям, которых прижала жизнь. Это всего 1 процент, а не 9, как гласило прочитанное когда-то мной исследование.

Клуб продолжает работать, он оказался великолепным местом для знакомства и общения с людьми, которые хотели бы узнать что-то новое без слишком уж большого напряжения. Приходил, например, немолодой ученый, уже на пенсии, решивший взяться за освоение языков программирования. Были мамы с детьми, супружеские пары — молодые и не очень, лаборанты и преподаватели вузов, действующие офицеры спецслужб, инженеры заводов и даже спортсмены. Кого только не было! Но большинству, повторюсь, программирование давалось трудно или не давалось, вообще. Впрочем, никто и не утруждал себя чрезмерно. Домашнее задание, например, игнорировалось в принципе. Через некоторое время большинство людей занятия бросали.

Почему так получается?

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

Источник

Почему функциональное программирование такое сложное

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

Самым непонятным и зубодробительным оказалось, наверное, Теория Категорий. Я освоился в ней только с третьего подхода. В первые два раза я честно все прочитал, кажется понял, но т.к. никакой связки с реальной жизнью она не имела, то спустя неделю она благополучно полностью выветривалась.

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.

Кому эта статья

Эта статья для программистов, давно желавших понять Функциональное Программирование, пытавшихся что-то почитать на эту тему и упершихся в стену «да что, это блин за хрень такая, и зачем все так усложнять!?». Поэтому в этой статье я попытаюсь ответить на вопрос «зачем они это придумали», не сильно ударяясь в технические дебри. Я сегодня побуду таким «Робертом Киосаки от функционального программирования», который не столько учит вас финансовой функциональной грамотности, сколько мотивирует ее в себе развивать.

Дисклеймер

Я не претендую на звание эксперта в функциональном программировании или Теории Категорий. Далее в статье я излагаю довольно упрощенный и частный взгляд на довольно нетривиальные вещи. Прошу отнестись с пониманием к неточностям и ошибкам, ведь даже «истина, высказанная словами – есть ложь». Тем не менее я буду рад уточнениям и исправлениям, отправленным в личку.

Зачем нам Функциональное Программирование?

Изучение ФП делает разработчика профессиональнее. Я даже не буду приводить ссылки на пруфы, потому что в 2020 это уже просто незыблемая истина.

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

Тем не менее уровень входа в ФЯП крайне высок. Иногда настолько высок, что вполне состоявшиеся разработчики с многолетним и успешным опытом не могут освоить его принципы, даже честно пытаясь. Иногда непонимание концепций ФП приводит к анекдотичному причислению некоторых ЯП к числу функциональных лишь на том основании, что в них есть функция map(). Разработчики могут искренне заблуждаться, считая, что они уже освоили ФП.

Что я понял по результатам моих попыток.

Есть общая беда всех курсов из разряда «Введение в …» (даже со смешными картинками) – они дают пачку базовых определений, постепенно повышая сложность. «Почему это беда?», спросите вы. Отвечу аналогией: когда вы учите двухлетнего ребенка отличать круглое от квадратного, вы не даете ему геометрической аксиоматики, «что такое прямая», «что такое окружность» и т.п. плавно подводя к определению «шар» и «куб». Вы просто даете ему кубики и шарики и доску с дырками, в которую их надо вставить. Только значительно позже, уже в средних классах, он узнает их формальные определения. Конечно, программист с опытом – не двухлетний ребенок. Но встроенная в каждого человека нейросеть эволюционировала как инструмент обобщения разрозненных примеров в общий абстрактный принцип, а совсем не как инструмент, получающий готовые абстрактные принципы. Обучение на примерах всегда идет быстрее нежели сухое перечисление определений.

Анекдот:

– Как «бесконечность», повернутая на пи-пополам».

Аналогично, при чтении очередного определения «монады» через функтор, у меня в голове возникала только одна мысль: вроде все понятно, но непонятно НАХРЕНА. Ощущения примерно соответствуют этой картинке:

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

Сначала немного бла-бла

Так уж исторически сложилось, что основная терминология ФП пришла из мира математики. Причем ОЧЕНЬ абстрактной математики. Теория Категорий, разработанная в 1940-х годах – это настолько абстрактная теория, что она полностью оторвана не только от реального мира, но и от многих разделов «обычной» математики. По своей абстрактности она близка к формальной логике «на стероидах».

Хорошая новость состоит в том, что для того, чтобы понять ФП совсем не обязательно начинать (или вообще знать) Теорию Категорий. Я советую сначала разобраться в практике ФП, а потом уже копать в сторону «корней» теоретической основы.

Плохая новость состоит в том, что с этой оторванной от реальности терминологией придется смириться и привыкнуть. Поэтому я буду все время смешивать абстрактные термины с общечеловеческими, чтобы вы к ним привыкали.

Абстрактность

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

Следуя подходу Теории Категорий «обобщай пока есть что обобщать», в ФП обобщают все что можно. Если что-то можно обобщить или абстрагировать – оно будет обобщено и абстрагировано. В итоге все приходит к условной абсолютно абстрактной «монаде», которая как «Многоликий Будда» не может быть описана одним предложением (хотя ниже я попытаюсь).

Следование этому пути приводит к полному исключению не только дублирования кода, но и дублирования алгоритмов и даже примитивов языка.

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

Декларативность

Сложности с пониманием ФП у «обычного разработчика» во многом обусловлены также необходимостью смены парадигмы императивного программирования на декларативное.

Дело в том, что исторически прямо со времен зарождения программирования все обучение новых программистов ведется на алгоритмах последовательного выполнения инструкций для получения некоего результата – императивном программировании. Императивно устроены большинство и старых, и даже новых ЯП. В противоположность Императивному было разработано Декларативное Программирование, к которому относится в том числе ФП. Не вводя абстрактных определений, просто приведу сравнительную таблицу двух подходов на житейских примерах:

Видно, что наши «программы» отличаются «точкой зрения на проблему». Императивный подход – постепенно конструируем результат от простого к сложному. Первая написанная функция императивного программиста будет « Чистить(Овощ) = … ». Декларативный – наоборот: начинаем с самого конца, постепенно декомпозируя задачу на более мелкие. Первая написанная функция будет называться « ГотовыйБорщ = … ».

Но есть еще более существенная разница. Дело в том, что императивная версия программы по поиску клада выполнится корректно только для конкретной начальной точки (хоть метр в сторону – и все было напрасно). А если в процессе варки борща, окажется что нет свеклы, то мало того, что борщ не сварится, так еще и зря пропадут уже порезанные продукты. А при попытке перезапуска процесса варки морковь окажется порезанной дважды. Поэтому основная проблема императивного подхода – большая чувствительность к начальному состоянию и прочим глобальным переменным в процессе исполнения. Что приходится компенсировать бесконечными if-ами, assert-ами, и обмазывать толстым слоем контрактов и тестов.

Может показаться, что я «натягиваю сову на глобус», выставляя декларативное программирование святым граалем. Но истина в том, что за все приходится платить. Основной недостаток Декларативного подхода – это необходимость прописывания всех (вот прям вообще всех, Наташ!) ограничений на все данные на всех этапах обработки – еще до запуска, что повышает сложность на этапе программирования, но отплачивает сполна в процессе работы. Этот полу-магический эффект, «если скомпилировалось, значит работает», замечают практически все, кто изучает ФП. Плюс функциональный код легко распараллеливается.

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

Чистая функциональная программа – это не поток исполнения (control flow), а поток данных (data flow), сопровождаемый монадическими Эффектами (о них чуть позже). Программа на чистом ФЯП – это такая многослойная матрешка, которая не делает ничего, пока не начнешь ее раскрывать слой за слоем. В процессе чего из нее иногда будут «вываливаться» Эффекты, сигнализирующие, что что-то там фактически программой было сделано.

Кроме того, декларативный подход «сверху-вниз» позволяет создавать библиотеки невероятной мощности: библиотека выкапывания всего и везде, библиотека варки любых блюд и т.п., которые дают сразу наборы функций из «верхней части» алгоритма (типа «варить до готовности»). Остаётся только дописать «нижнюю» половину – в каком порядке складывать в кастрюлю. Библиотека, работающая с монадами, работает с ЛЮБЫМИ монадами (которые удовлетворяют специальным «законам», общим для всех монад). Это обобщенное программирование, возведенное в Абсолют.

Отмечу также, что приведенные выше примеры – это «сферические кони». На практике даже в императивных ЯП программа пишется, начиная с функции main. И часто дальнейшее проектирование тоже происходит «по-декомпозиционному», т.е. сверху вниз. А опытный программист может написать все в декларативном стиле даже на «голых сях». С другой стороны, и в ФЯП программа, будучи декларативной по своей природе будет все равно чаще всего написана, как цепочка последовательных преобразований данных от начального состояния к конечному. Поэтому все же стоит вспомнить избитый принцип «императивный код определяет, что надо сделать, а декларативный код – что надо получить».

Декларативный язык всегда требует исполнительного механизма (иногда довольно сложного), способного из описания «что надо» понять, «как» это получить. А декларативная программа должна содержать достаточно подробное описание, чтобы исполнительный механизм мог понять, как это сделать. Из этого следует второй большой недостаток ФП: не всегда удается получить производительный код, напрямую используя выразительные декларативные конструкции. В таких случаях приходится вспоминать, что там под капотом, и давать компилятору подсказки по оптимизации либо просто отказываться от красивостей в пользу менее красивого, но более производительного кода.

Примерами декларативных систем и их исполнительных механизмов являются:

Прошу к столу

Теперь наконец попробуем разобраться в терминах Теории Категорий на понятных условному сишнику/джависту примерах.

Морфизм – это любая функция, преобразующая один тип в другой. Вот IntToStr – это вполне себе морфизм. Итого: видим «морфизм» — читаем «функция конвертации». «Эндоморфизм» — это морфизм внутри категории, т.е. преобразование типа в самого себя. Функция «синус» вполне себе Эндоморфизм из Категории Double в нее же, хотя и крайне примитивный. Более сложный пример морфизма: преобразователь пары строк (username, password) в объект сессии.

«Ее Величество» Монада – это простой и банальный контейнер. Ее основная цель – обрабатывать данные в контейнере, не вынимая их наружу. Для этого к ней прицепили парочку функций ( map ). Например, если у нас есть монада-список (массив) чисел, то преобразование их в строки можно сделать прямо в массиве, сразу получив на выходе готовый массив строк, не заморачиваясь с циклами, созданием новых массивов и т.п.

Функтор – обработчик данных в контейнере.

Лямбда выражения и Замыкания. Лямбда исчисление имеет к ФП такое отношение, как Теория Категорий, т.е. никакое. Просто люди, привнесшие эту концепцию в ФП, были прожжёнными математиками, и дали ей такое название. Для того чтобы понять суть «лямбд» и «замыканий» не нужна высшая математика. Лямбда-выражение – это просто анонимная функция. Когда у тебя есть язык, весь состоящий из функций, и когда функции можно передавать в качестве значений другим функциям, то не очень хочется для каждой такой функции придумывать имя. Особенно если эта функция состоит из одной строки и тройки-другой слов.

Эффект – это один из столпов ФП, наравне с монадой (и настолько же абстрактен, как она). Эффект – это императивная часть программы. Любой программе, написанной на чистом и няшном ФП, приходится взаимодействовать с внешним миром. Любое взаимодействие заставляется выйти из теплого мирка контейнеров-монад в грязный реальный императивный мир и что-то вывести на экран, что-то принять по сети, прочитать текущее время и т.п. Кроме того любое извлечение данных из контейнера – это Эффект (т.к. с извлечением может быть запущена отложенная реальная обработка данных). Чтобы вывести распарсенное число на экран, нам придется-таки узнать, а было ли оно вообще распарсено (извлечь содержимое Option / Maybe ). Не удивительно, что функциональщики стараются держать Эффекты под контролем. Весь прикол функционального мира состоит в том, что Эффекты до самого последнего момента тоже остаются монадными (т.е. упакованными в свой контейнер эффектов). Если где-то в коде ФЯП написано, что надо что-то вывести в консоль, то оно (текст) будет упаковано в монаду и доставлено вверх по кол-стеку прямо в функцию main. Функция main возвращает именно такую супер-монаду IO (а не void как в «сях»), которая собрала в себя всю логику программы, и все эффекты ввода-вывода в консоль. Только внутренний boot-код, сгенерированный компилятором, запустит исполнение Эффекта (извлечение контейнера IO ) – откроет ящик Пандоры, из которого выскочат все реальные строки, вычисленные тут же «на лету» цепочками различных преобразований.

Что дальше

Я надеюсь, что мое объяснение было полезным и дало вам привязку мира ФП к реальным задачам. Поэтому если вы еще не начали, то попробуйте начать писать функциональный код. Вот прямо сразу, на том языке, на котором вы пишете все время. Как я упоминал выше, это можно делать почти в любом ЯП. Для этого надо всего лишь стараться максимально следовать следующим принципам:

Заключение

Аппетит приходит во время еды. Постепенно развивая в себе функциональное чутье, со временем вы постепенно начнете «видеть» монады. Ваш код станет выразительнее, компактнее, надежнее. Но есть один недостаток: взглянув через год на свой код вам станет нестерпимо стыдно и захочется переписать его заново вдвое короче. По крайней мере так было у меня.

Апдейт по мотивам комментариев

Еще раз напомню, что данная статья не является академической. Данные тут определения — это вольные трактовки на конкретных житейских примерах, они способны вызывать батхёрт у тех, кто уже углубился в абстракции и топит за «чистоту». За строгостью формулировок я настоятельно рекомендую обратиться к авторитетным источникам.

Источник