eaxcast-s01e02/

Темы второго выпуска: отвечаем на комментарии к пилотному выпуску, что не так с нынешними интернетами, зачем программисту на Java учить Erlang или Haskell и что может предложить Idris вместо трансформаторов монад. Первый, пилотный, выпуск можно послушать здесь .

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/2/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/2/file/podfm_eaxcast__eaxcast_102.mp3

Шоу нотес:

Голоса выпуска: Александр @afiskon Алексеев, Валерий @sum3rman Мелешкин

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

Александр: Здравствуйте, дорогие слушатели! Это второй выпуск первого сезона EaxCast. Да-да, вы не ослышались. EaxCast стало в два раза больше, потому что хорошего подкаста должно быть много. Этот выпуск веду я, Александр afiskon Алексеев, и со мной в подкастике Валерий sum3rman Мелешкин. Здравствуй, Валер.

Валерий: Привет!

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

В: Я думаю, на данный момент — человек 650.

А: Твоя аппроксимация очень верна. На самом деле, вот на данный момент — 616 человек по статистике Rpod. Я не знаю, это могут быть скачивания, а не уникальные люди, но вот он показывает 616. И к моменту, когда мы это выложим, видимо, будет больше.

Что нас удивило, народ вообще не жаловался ни на звук, на его качество, ни на то, как мы с Валерой говорим. На этот счет мы больше всего беспокоились. А жаловались на счет разных мелочей. Ну, например, подкаста еще нет в iTunes, но к моменту, когда выйдет вот этот второй выпуск, возможно, он там уже будет. Там возникли небольшие технические сложности. У некоторых пользователей, кто сидит под Ubuntu, не загрузился Flash плеер Rpod’овский. Поэтому пришлось под этим плеером разместить маленькую такую надпись: «Дорогие пользователи Ubuntu, попробуйте нажать F5». Пока не очень понятно, что с этим делать. Может быть, мы прикрутим другой плеер, не оригинальный Rpod’овский. Но пока вот, это работает только таким образом.

Вообще, в контексте этой проблемы я не могу не отметить, что в моем понимании с вебом сейчас происходит что-то не очень правильное. Что я имею в виду? Изначально что такое было веб — это HTML-странички и, может быть, картинки. Правильно ведь?

В: Ну да.

А: Потом кто-то посмотрел на это и сказал, что черный текст на белом фоне — это не интересно, давайте прикрутим CSS.

В: Ну, мне кажется, исторически было наоборот. Извини, что перебиваю.

А: Сначала CSS, потом HTML?!

В: Нет. По-моему, сначала был JavaScript, а потом CSS.

А: Серьезно?

В: Исторически JavaScript притащил Netscape для того, чтобы всякие куски авторизации и аутентификации производить на клиенте. Но тут же нашлись ребята, которые хотели, чтобы мартышка прыгала с бананом, и JavaScript стали использовать для того, чтобы свистеть и пердеть на страницах.

А: (смеется) В общем, мысль заключается в том, что… Я недавно совсем, кстати, где-то видел пост, может быть, найду на него ссылку, что в оригинальном JavaScript типичная программа, как считалось, должна занимать одну строчку. Десять строк JavaScript’а — это большая программа. А вот, как сейчас, тысячи или даже миллионы строк кода, это вообще что-то невообразимое, на что JavaScript никогда не был рассчитан. А потом мы удивляемся, почему мы заходим на какой-то сайтик, и он очень-очень долго грузится, медленно-медленно рендерится. Особенно это заметно, если вы не обновляете компьютер раз в два года, а вот у вас старенькая машинка. Тогда вот прямо невооруженным взглядом заметно, как веб становится все медленнее и мееедленнее и мееееедленнее…

Все это почему происходит? Потому что есть какая-нибудь компания, ну, скажем, Facebook. И им не хочется, чтобы пользователи, весь миллион, ломились к ним Ajax’ом, и загружали апдейты типа «у вас одно новое сообщение». И поэтому они думают: «А вот как бы нам все это оптимизировать? А давайте, придумаем вебсокеты и попробуем протолкнуть это как стандарт!» И вот поэтому веб усложняется, становится таким громоздким, медленным и страшным.

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

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

Последнее, что хотелось бы отметить — очень многие граждане, послушав подкаст, пришли к неправильному заключению, что это подкаст только об Erlang. Это абсолютно не так. То есть, мы совсем не против когда-нибудь поговорить о Linux, FreeBSD или, там не знаю, ассемблере. Как обычно, имеет место вырывание слов из контекста, их коверканье, додумывание и интерпретация, как будто мы это сказали. Типа что мы с Валерой думаем, что мейнстрим должен умереть. Ничего подобного. Вообще ни разу. Я прав?

В: Ну да. То есть, речь шла о том, что нам не интересно в этом подкасте постоянно говорить о том, о чем говорят все. Это не значит, что мы к этому плохо относимся. И вообще, это никак наше отношение к этому не обозначает.

А: Мейнстрим мы на самом деле любим. Ну вот я очень люблю PHP. У меня бложик работает на WordPress . Да, и я этого не стыжусь. У меня там есть другие PHP-скрипты, которые не торчат наружу. Я люблю и уважаю сишечку. Я даже не особо ненавижу Винду, прямо скажем. То есть, нет такого, что вот мейнстрим должен умереть. Нет, конечно. Ничего подобного.

В: Как минимум, еще была идея говорить про распределенные системы. Как минимум, еще была идея говорить про всякие свежепоявляющиеся технологии, свежепоявляющиеся языки типа Julia , типа того же Elixir’а . Так что, у нас будет список тем довольно обширный, я надеюсь.

А: Многие слушатели в комментариях у нас спросили: «А зачем нам этот ваш Erlang, или, я там не знаю, Haskell? Вообще, эта ваша функциональщина? Или, например, NoSQL ?» Были люди, которые просто писали: «Erlang — говно и никому не нужен». Такие комментарии, я извиняюсь, но я был вынужден удалять, потому что мне не о чем говорить с такими людьми, ну, по крайней мере, если они так формулируют свое мнение. А некоторые люди интересовались совершенно искренне и искренне недоумевали, и для них мы решили осветить эту тему. Валер, тебе слово.

В: Функциональное программирование, как и любой другой инструмент, или любая другая технология, это всего лишь инструмент. Просто некоторые инструменты лучше подходят для некоторых задач. Бизнесу, например, пофиг, на чем оно сделано, если бизнес — не какой-нибудь Luxoft, которому важна заменяемость работников, прям такая, специальная. Поэтому, если вы пишите распределенную систему, разумно взять Erlang. Или вот, например, Facebook пишет генератор запросов для своей графовой базы данных, который при этом должен их оптимизировать, при этом некоторые проверки корректности должен выполнять еще до выполнения запроса и так далее. Они наняли для этого Simon’а Marlow , который раньше работал в Microsoft Research, работал над GHC. То есть, даже не просто самым популярным, а самым развитым компилятором Haskell. Вот, и в Facebook используют Haskell там, где они считают, что это наиболее подходящий инструмент для того, чтобы эту задачу решать.

Другое дело, что, мне так кажется, многие приходят к предметным областям, в которых ФП хорошо работает, через изучение языков. Да, это, возможно, имеет место быть. Как у меня, например, это случилось. Я в детстве очень любил пытаться писать игры. В какой-то момент мне начало нравится пытаться писать игровые движки. В какой-то момент через это я начал интересоваться всякой многопоточностью. Интересуясь многопоточностью, мне стало интересно, как вообще концептуально с этим справляются. Я нашел Erlang. Потом уже, немного потыкав Erlang, я наткнулся на Riak . Наткнувшись на Riak, я наткнулся на Amazon Dynamo Paper [PDF] ( перевод на русский язык ). И уже через это я увлекся распределенными системами. Хотя про функциональщину я знал немного раньше, чем я до Riak’а добрался.

А: У меня было немножко по-другому. Я писал на Perl’е. Ну, так исторически сложилось, что я в свое время искал подработку, будучи студентом. Сишником почему-то никто студентов брать не хочет, потому что сразу понятно, что у них переполнится буфер, утечет память, разыменются указатели в никуда, и так далее. Поэтому одно время я пописывал на PHP, потом на Perl’е. И вот, сижу я такой грусный и унылый перловик, и размышляю о том, что наверное где-то есть язык с более широкой областью применимости, чем у Perl. Perl, он, конечно, прикольный, но на нем нельзя написать, например, оконный менеджер. На нем не особо попишешь игрушки и так далее. У него есть определенные проблемы с… ммм… На самом деле, много с чем.

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

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

Так зачем же вообще учить какие-то там Erlang’и, Haskell’и, когда все кругом пишут на PHP и Java? Вообще, что такого можно написать на этом вашем дурацком Haskell, чего нельзя написать на Си? Такая постановка вопроса абсолютно неверна. То есть, если исходить из «зачем что-то изучать, если все пишут на PHP», ну, давайте все дружно сидеть под Windows, писать на PHP, питаться в McDonalds, потому что вот все так делают. И любую новую технологию, которая появляется, давайте сразу отбрасывать, потому что вот все же пишут уже на PHP, зачем что-то новое изучать.

В: Ведь это не потому что PHP плохой, или Windows плохой, или там макдак плохой. Просто все делают так, как им удобнее и им нравится. Странный вопрос. Мы же не спрашиваем: «Почему ты носишь красные рубашки? Вот все же носят синие, а ты носишь красные!» Вот не возникает такая постановка вопроса в бытовой жизни.

А: И понятно, что если ты придешь к своему руководителю, начальнику или тимлиду, и ты работаешь в серьезной крупной компании, и ты скажешь: «А давайте дружно сядем и перепишем все на Erlang!», то, конечно, тебя пошлют… эээ… глубоко и туда, где не светит солнце. Так зачем же тогда всякие Эрланги, Хаскели и, не знаю, Лиспы, и прочее в этом роде?

В моем понимании, дела обстоят так. При изучении этих языков ты открываешь для себя новые подходы в программировании. Например, Erlang. В нем прекрасно сделана многопоточность. Это действительно для меня было настоящим открытием. Я читал этого Чезарини и Томпсона и у меня вот прямо просветление наступило. Ага, у нас же акторы и у них нет общего состояния, и значит можно все акторы разнести по разным машинам и у нас система вот сразу масштабируется. Это же так круто! Потом я рассказал это своему знакомому джависту, объяснил, и он тоже сказал: «Вау, это же так прекрасно! Почему мы трахаемся, простите, с этими мьютексами и тредами ?» То есть, это совершенно новый мир, это совершенно другой подход, который, если ты всю жизнь пишешь на Python, ты никогда не осмыслишь.

В: Тут еще есть такой интересный момент. Если ты умеешь писать на Эрланге, ты сможешь писать на Эрланге на C++. А если ты не умеешь писать на Эрланге, ты не сможешь писать на Эрланге, как на Эрланге. Я видел код на Эрланге, написанный питонистами, которые не хотели учить Эрланг. Это был такой Питон на Эрланге. И я видел код людей, которые умеют писать на Эрланге, написанный на С++. Это был такой Эрланг на C++. Очевидно, что если ты пишешь какую-то сильно многопоточную или даже распределенную программу на C++, то лучше, конечно, протащить Эралнг в C++, чем, например, попытаться писать на Питоне на Эрланге. Это как в шутке про то, что программист на Фортране на любом языке будет писать как на Фортране.

А: Действительно, можно изучить язык, тот же Erlang или Lisp, и не писать на нем, а писать на Java, но используя там подходы, которые ты узнал, изучая тот другой язык. В этом нетрудно убедиться, открыв ту же Практику Функционального Программирования . Там найдете массу примеров, где на Java пишут, как на функциональном языке, и получается очень красиво. Тогда что дает Haskell? Можно же Erlang выучить, и сразу про многопоточность все узнаешь.

В: Ну, кстати, не все. Чтобы узнать все про многопоточность, нужно попытаться понять, как Erlang, сволочь, работает. Это уже интересно, попытаться в его кишках покопаться, попытаться хотя бы что-то похожее изобразить на крестах. Тогда действительно наступает просветление и сатори .

А: Чем интересен Haskell? В первую очередь, своей строгой статической типизацией. Это уже общепризнанный факт, что в Haskell неповторимая, прекрасная система типизации, которую не удалось пока никому повторить, может быть, кроме Idris’а .

В: Ну тут, понимаешь, как. Есть семейство ML’ей, вообще все. Оно все обладает тем приятным свойством, что типизация статическая и не нужно, как белка истеричка, все подписывать типами самому. Оно все довольно умное. С другой стороны, в Хаскеле есть довольно удобные тайпклассы. Зато вот, например, в Standard ML есть модули. Сам по себе Хаскель уже приближается к тому месту, когда в нем будут зависимые типы. Но там пока вот вроде бы как не оно. То есть, может быть, в каких-то расширениях оно и есть, но еще не совсем. А Idris и Agda — там уже да, там уже зависимые типы и вперед, можно доказывать теоремы.

А: Тайпклассы в Хаскеле были для меня настоящим открытием, таким просветлением. Вот у тебя есть тип, у тебя есть класс типов, грубо говоря, интерфейс. И тебе ну нужно жестко привязывать все это, у тебя может быть совершенно отдельная сущность, которая связывает типы с неким интерфейсом. Это то, чего я не понял, прочитав книжки по C++ и Java, а я в свое время почитывал много таких книжек .

В: Я когда впервые увидел классы типов, я понял, что это то, чего мне всю жизнь не хватало в языках со статической типизацией. Когда ты берешь в руки какой-нибудь Ruby, там это есть более-менее само по себе, потому что там так называемая утиная типизация. Она довольно строгая в том смысле, что если объект чего-то не умеет, то runtime exception, все, до свидания. Он не будет, как JavaScript, пытаться приводить одно к другому. И при этом довольно удобно, что можно сказать, что вот это объект имеет какой-то метод, значит мы будем с ним так обращаться. А тайпклассы — это то, чего всегда хотелось в статическом языке, сказать, что вот этот объект умеет вот этот интерфейс через вот так-то. И все, сразу добро и гармония.

А: Открыв для себя тайпклассы, я теперь не понимаю, как без них вообще можно жить. Самое интересное, что связать класс типов и тип может совершенно другой программист. То есть, один программист пишет интерфейс, то есть, класс типов, второй программист объявляет тип, а потом через двадцать лет какой-нибудь третий программист смотрит на это дело и говорит: «А, так их же можно связать!» И совершенно отдельную библиотеку с этим объявлением создает. То есть, это то, чего совершенно нет в других языках.

Еще про строгую статическую типизацию нажно сказать, что она не такая, как, ну не знаю, в C++. Что тебе нужно постоянно, действительно, объявлять типы, и она такая сложная, неудобная, и вообще, нужна для того, чтобы тебе это правильно скомпилить в машинный код. В Хаскель строгая статическая типизация — она друг программиста. Она защищает тебя от того, чтобы ты случайно не сложил доллары и евро, или метры и литры, или январь с количеством учеников.

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

А: Да, то есть, еще Хаскель контролирует побочные эффекты. Обратите внимание, не запрещает, а именно помогает контролировать. И ты знаешь, что если вот тут у тебя есть некоторая функция, она гарантированно не сходит по сети или не перезапустит компьютер. Это в частности позволяет грамотно реализовать транзакционную память, чего тоже есть ну разве что в Clojure , и то, там, видимо, не контролируются побочные эффекты.

В: Хаскель контролирует побочные эффекты через, о Боже, эти страшные монады , которых все почему-то так боятся. Не знаю, почему все боятся монад. Вполне себе понятная абстракция. После того, как ты потрогал список, потрогал Maybe, потрогал State, дальше, мне кажется, монада просто сама по себе в голове появляется. Я не знаю, почему всем так сложно это освоить.

А: Я уже отмечал, что Хаскель не нужно учить наскоком. То есть, видишь монаду, не понимаешь, что это — сел и спокойно разобрался. В этом нет ничего сложного, просто не нужно пытаться это так быстро заботать, что типа ага, все понятно, циклы, переменные, все, я знаю новый язык! Правда, он такой же, как предыдущий, но зато я знаю их теперь два.

В: На самом деле, я хотел не совсем про монады сказать. Я хотел сказать про то, что монада — это, к сожалению, не очень composable штука. Есть монадические трансформеры, но это не очень удобно использовать. Вот чем забавны Idris’ы и прочие такие появляющиеся языки с еще более интересными системами типов. Вот в Idris’е есть система эффектов. Это ортогональный механизм, он гораздо удобнее в использовании, чем монадические трансформеры. И кстати, на счет наскока на Хаскель. Я не могу сказать, что знаю Хаскель на том же уровне, на котором его знаешь ты, но я Хаскель учил довольно быстро. Правда, я в начале изучил Схему, в смысле Scheme, потом у меня был Эрланг, и потом Хаскель у меня как-то очень хорошо пошел сам собой.

А: Некоторые программисты, кстати, наоборот, отмечают, что пытаются учить Эрланг, и он что-то не идет, потом они изучают Хаскель, ну так, основы, а потом Эрланг идет очень хорошо, потому что ты уже знаешь все эти fold’ы, map’ы и так далее. То есть, у тебя меньше вещей вызывает удивление.

В: А fold и map у меня вообще были в Scheme как раз.

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

В: Ну или, например, в Go есть легковесные процессы, в которых, насколько я знаю, можно не беспокоясь пойти в файл, но вот в цикле начать крутиться уже нельзя. Потому что можно заблочить поток, и чтобы его не заблочить, нужно в этом цикле периодически размахивать yield’ой . А Эрланг считает инструкции. Если процесс слишком много редукций потратил и какой-то слишком наглый, его просто турнут. А Хаскель, насколько я знаю, обращения к памяти считает.

А: Самое интересное, что начав работать с легковесными процессами ты уже не понимаешь, как без них можно что-то серьезное писать. Например, если у тебя есть сайтик, ты без легковесных процессов не можешь так просто взять и поддерживать десять тысяч одновременных соединений по TCP. То есть, ты можешь, но тебе нужно взять там сишечку, взять libev какой-нибудь, а в Эрланге это просто и элегантно, тебе ни о чем особо думать даже не надо, оно вот само работает.

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

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

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

В: Мне в этом смысле нравится подход типа скальего. Хочешь — используешь обычные коллекции, хочешь — используешь ленивые коллекции.

А: Нужно понимать, что ленивые вычисления — это более общий случай строгих вычислений, и Хаскель позволяет всем этим хозяыйством управлять. То есть, если тебе нужна строгая коллекция, берешь Data.Map.Strict, и у тебя строгий Map. Или, если тебе нужно вот сразу все вычислить, ты делаешь deepseq, и у тебя вычислено строго. То есть, если тебе нужны строгие вычисления, ты их получаешь. Это я еще не говорю о строгих полях в структурах, о расширениях языка, которые позволяют делать строгие вычисления более легко, синтаксический сахар предлагают для этого. Более того, есть плагин для компилятора GHC, который компилирует модуль полностью строго. То есть, даже так. Хотя, обычно этим не пользуются.

В: Не знаю. Вот, с моей точки зрения, наоборот, ленивые вычисления — это то, что хочется включать, когда надо. А во всех остальных случаях пользоваться тем, на что натренирована твоя программистская интуиция. Потому что мы живем в мире, где почти все программисты по умолчанию обучаются на энергичных языках. Даже если людей учат функциональщине в ВУЗе, далеко не всегда они сталкиваются с ленивыми вычислениями, как с основным инструментом. Даже если приподается какая-нибудь Схема, даже если говорят про ленивые потоки, все равно по умолчанию люди привыкают работать с энергичными языками. В этом смысле кажется более прагматичным работать по умолчанию в энергичной среде. Если ты знаешь, что вот эта задача лучше легла бы на ленивые вычисления, взять ленивую коллекцию.

А: Ну, как звучит известная шутка, не нужно пытаться сразу учить ленивые вычисления, познакомься с ними, когда тебе это понадобится. (Смеются) Нужно понимать, заканчивая обсуждание ленивых вычислений, что GHC — умный компилятор. Он в ряде случаев, если компилировать программу с флагом -O2, видит, что где-то значение вычисляется всегда и вычисляет его строго. Это называется анализ строгости. И большую часть времени действительно на Хаскеле можно писать как будто ты пишешь на строгом языке, не особо беспокоясь о ленивости. Обычно такой проблемы и не возникает, что типа я учился в школе на Pascal’е, и не понимаю, как работают ленивые вычисления.

В: Нет, но с другой стороны, если бы вообще не было проблем с ленивостью, то у нас не было бы развесистой такой вот фауны среди всех этих iteratee, conduit’ы , потом были эти машины, пайпы… Вот если бы ленивое IO так замечательно работало, наверное, весь этот зверинец не зародился бы.

А: Не-не-не, подожди. Нужно понимать различие между просто ленивыми вычислениями и ленивым IO. И когда тебе что нужно. Вот, кондуиты и iteratees нужны в случае, когда у тебя приложение работает долго. То есть, если ты пишешь компилятор, тебе вообще не нужны кондуиты. Если ты пишешь HTTP-прокси, то да, конечно, тебе нужны кондуиты, потому что ты хочешь контролировать, какие данные ты считываешь, и закрывать файловые хэндлеры, когда у тебя где-то бросился эксепшен , и так далее и тому подобное. То есть, да, вот так оно здесь устроено.

Что касается iteratees, это уже, насколько я знаю, уже несколько устаревшая фигня, по крайней мере, в мире Haskell. Потому что разработчик Yesod’а, веб-фреймворка на Хаскеле , который, кстати, очень активно паразитирует на его сильных сторонах, вплоть до того, что ты не можешь случайно сослаться на страницу, которой не существует, или написать JavaScript или CSS с синтаксической ошибкой, или HTML с неправильным отступом, вплоть до такого… Так о чем я? По-моему, его зовут Michael Snoyman .

Так вот, он является автором кондуитов, и он их написал по той причине, что пробовал iteratees и в какой-то задаче типа написать HTTP-прокси оно как-то очень плохо работало, и было сложно, и не получалось . И вот, он написал кондуиты, которые как iteratees, только лучше . То есть, iteratees — это уже не очень актуальная вещь.

В: Так потом пришел кто-то еще и написал machines . Сказал: «Смотри, кондуиты это не круто, вот есть machines».

А: Об этом я ничего не могу сказать.

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

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

А: Ну, в конце концов, да. Никто же не заставляет. Это все добровольно. В любом случае, мы уже наговорили очень, очень много минут времени.

Спасибо, что слушали нас. Пожалуйста, подписывайтесь на наш RSS и твитеры. К моменту, когда вы будете слушать этот подкаст, мы почти наверняка уже будем в iTunes. Пишите комментарии и отзывы, о чем вам было бы еще интересно послушать, с чем вы согласны из того, что мы сказали, с чем вы категорически несогласны. Мы, как правило, всем отвечаем, если у нас не создается впечатление, что пишут какие-то злобные троли. Ну и, пожалуйста, без мата.

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

Пожалуй, это все. Спасибо. Пока!

В: Пока!

Дополнение: EaxCast S01E03, говорим о NewSQL базах данных

EnglishRussianUkrainian