Александр Гранин graninas

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

Современный программист

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

Дополнение

Работа идет, и, как ни крути,
Меня в ремесло посвятят.
На джуна я выйду годам к тридцати,
А в сорок пойду в детский сад.

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

Дисклеймер 1. Ни ссылок, ни имен, ни пруфов не будет. Как известно, в Интернете можно найти подтверждение или опровержение любому тезису, поэтому не вижу большого в том смысла, покуда это не диссертация, а мнение. Моя цель — предоставить другую точку зрения, основанную на личностном опыте веры на личном опыте.

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

Осознав, что я давно не писал на Хабр ничего полезного о ФП и Haskell, и что имеется вполне отличный повод для технической статьи, — решил тряхнуть стариной. Речь в статье пойдет о Software Trasactional Memory (STM), которую мне удалось реализовать на Free-монадах при участии ADTs (Algebraic Data Types) и MVars (конкурентные мутабельные переменные). И, в общем-то, Proof of Concept оказался крайне простым, в сравнении с «настоящим» STM. Давайте это обсудим.

Software Transactional Memory

Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

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

Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?

Введение

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

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

Я придумываю особенную игру в жанре космического симулятора. Согласно одной из ключевых концепций, в игре будет встроенный язык программирования, с помощью которого можно разрабатывать и улучшать алгоритмы взаимодействия игровых элементов. Дизайн такого языка — дело непростое, учитывая его «натуральность», а не «текстовость». То есть, конструкции языка выражены в виде разных графических объектов. Рисуя эскизы его конструкций, я неожиданно для себя отвлекся и вместо языка для игры стал придумывать язык для визуализации Haskell-кода. Получалось так интересно, что я не мог оставить эскизы просто бумажными рисунками. В январе 2012 года я начал писать сервер визуализации, и вот что получилось…

С некоторых пор на Хабре произошли кардинальные изменения, о чем здесь было уже много слов (еще бы!). Я предлагаю лишь одно маленькое, но важное улучшение:

Пожалуйста, продлите срок существования статей в разделе «Новые».

Хотя бы до трех дней. А лучше — до пяти. Сейчас этот срок ограничивается, судя по датам статей, одним-двумя днями. (В комментариях подсказывают, что срок — одни сутки.)

В силу того что востребованность технических блогов и статей и так ниже плинтуса, и технические статьи нужны лишь 2 с половиной заинтересованным, быстро плюсы они набрать не могут. (Мы не говорим о подобном — это вообще вредный контент, где нет ни слова правды). Многие статьи просто не успевают попасть на глаза тем, кому они предназначены, и утекают в небытие, исчезают из поля зрения. И вроде бы остаются еще статьи, у которых голосов < 7, но поскольку они опубликованы позавчера, их уже никто не увидит.

Кроме этого узкоспециальные «технические» ленты (я, например, подписан на программирование и все, что с ним связано) выглядят убого: одна-две страницы, иногда три. Не очень приятно психологически. Такое ощущение, что жизни на техническом Хабре нет.

Сейчас у меня последняя статья в ленте датируется 12-м октября 2011, 05:20. Хотя я помню, что еще вчера было около пяти интересных постов. Где теперь их искать, — не знаю.

Спасибо за внимание.

By Mike Vanier

В предыдущих статьях этой серии мы изучали концептуальный базис монад, но обсуждение наше было слишком абстрактным. Теперь, когда вы, я надеюсь, поняли, что монады такое и для чего они нужны, пришло время для детального рассмотрения специфических монад. Это значит, что мы определим корректные воплощения класса типов Monad для множества различных понятий вычислений, которые мы увидели раньше. Мы используем наши знания, чтобы получить монадическую композицию в каждом конкретном случае через монадическое применение (оператор >>=), и с помощью монадных законов мы выведем определение return.

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

By Mike Vanier

В прошлой статье я рассказал о двух фундаментальных монадических операциях класса типов Monad: оператор связывания (bind, >>=) и функция return. В этой статье я закончу с определением класса типов Monad и расскажу о монадных законах.

By Mike Vanier

Две фундаментальные монадические операции

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

К этому моменту, я надеюсь, у вас сложилось хотя бы смутное ощущение монад, что они такое и для чего используются. Я уже упоминал одну из особенностей функционального программирования — композицию функций, благодаря которой мы создаем новые функции, объединяя старые. Функциональные программисты постоянно говорят о «комбинируемости» {1}, подразумевая, что если что-то в языке программирования не комбинируется, значит, оно немногого стоит. Аналогично, наши новоявленные монадические функции не были столь же полезны, если бы они не компоновались так, как это есть на самом деле. Но мы еще увидим, для их композиции нельзя использовать стандартную функцию «точка» (.) языка Haskell. Мы придем к выводу, что тут нужно что-то большее, и определим две фундаментальные монадические операции (или, для начала, их типы).

By Mike Vanier

В сообществе любителей Haskell прижилась шутка, что каждый Haskell-программист должен в процессе своего обучения написать одно или несколько руководств по монадам. И я — не исключение. Но я знаю, что существует очень много руководств по этой теме, многие из них хороши, — так зачем мне писать Еще Одно? Две причины:

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

Предварительные требования

Так как я буду писать примеры на Haskell, для вас, читатель, было бы полезно знать его, включая такие разделы, как полиморфизм и классы типов. Без этих знаний материал будет сложен для понимания. Уже написаны десятки вводных руководств по Haskell, которые стоит прочитать неподготовленному читателю, и потом вернуться к серии этих статей.

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

Скорее всего, это последняя часть, опубликованная точно в срок. Мой отпуск почти закончился, и теперь писать по статье в неделю будет очень сложно. Спасибо всем, кому было интересно руководство «Haskell Quest Tutorial»!

Living Room
You are in the living room. There is a doorway to the east, a wooden door with strange gothic lettering to the west, which appears to be nailed shut, a trophy case, and a large oriental rug in the center of the room.
Above the trophy case hangs an elvish sword of great antiquity.
A battery-powered brass lantern is on the trophy case.

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 5,
в которой мы из маленькой ошибки выведем значительные следствия, а затем добавим в игру объекты.

Canyon View
You are at the top of Great Canyon on its west wall. From here there is a marvelous view of the canyon and parts of the Frigid River upstream. Across the canyon, the walls of the White Cliffs join the mighty ramparts of the Flathead Mountains to the east. Following the Canyon upstream to the north, Aragain Falls may be seen, complete with rainbow. The mighty Frigid River flows out from a great dark cavern. To the west and south can be seen an immense forest, stretching for miles around. A path leads northwest. It is possible to climb down into the canyon here.

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 4,
в которой мы займёмся рефакторингом, реализуем пару действий, узнаем о pattern matching и рекурсии, а так же сделаем из квеста настоящую программу.

Clearing
You are in a small clearing in a well marked forest path that extends to the east and west.

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 3,
в которой мы станем учиться волшебству с АТД и познаем магические преобразователи Show и Read.

В прошлой части мы изобретали различные варианты describeLocation, а в конце создали три алгебраических типа — Location, Direction, Action. Я обмолвился про волшебство и удивительные возможности АТД, но сказал, что мы рассмотрим их позже. Мы только унаследовали наши типы от класса типов Eq, в котором лежат операции "==" и "/=", а теперь…

Forest
This is a forest, with trees in all directions. To the east, there appears to be sunlight.
You hear in the distance the chirping of song bird.

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 2,
в которой мы будем мучить функцию describeLocation, и даже узнаем, что такое АТД.

Настало время получше подумать над игрой. Что это будет? Классическая приключенческая игра, где можно куда-то идти, находить и использовать предметы, взаимодействовать с неигровыми персонажами? Или это будет rogue-like текстовая игра с магией, злыми существами, с кучей оружия, брони, свитков, мечей и луков? Или, быть может, мы хотим создать квесты а-ля «Космические рейнджеры-2»? Ну, по части игровой механики мы пойдем по стопам Zork, а историю выберем другую — замечательный НФ-квест Lighthouse. Просто потому, что он мне нравится.

West of House
You are standing in an open field west of a white house, with a boarded front door.
There is a small mailbox here.

> open mailbox
Opening the small mailbox reveals a leaflet.

> read leaflet
(Taken)
«WELCOME TO ZORK!

ZORK is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever by mortals. No computer should be without one!»

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 1,
в которой мы познакомимся с не всеми основами языка Haskell и напишем одну полезную для квеста функцию.

Итак, вы стоите в самом начале, перед закрытой дверью и видите почтовый ящик.

Добрый день, любители приключений!

Вы, конечно, играли в текстовую приключенческую игру Zork. Вы еще помните эти недели, когда вы искали вход в подземелье, или думали, как пройти мимо гоблинов с дубинками. Вы помните, как махали мечом, вы даже испробовали различные варианты «hit self» и «kill self». Программа понимала ваши команды, — результат был предсказуем… Весело и удивительно было изучать текстовый мир Zork! И вам, конечно, хотелось создать что-то подобное своими руками. Так может, попробуем? Вместе? В этом руководстве вы будете шаг за шагом создавать свою текстовую игру на замечательном языке Haskell.

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