IDE как зло

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

Этот пост скорее дамп мыслей чем законченная идея. Однако мысли эти посещают меня довольно давно и мне кажется неплохой идей их зафиксировать. Мыслей этих примерно 4:

• Общая польза от IDE крайне переоценена 
• Вред от них практически никогда осознанно не рассматривается 
• Во многих [коммерческих] проектах есть крайне не здоровая зависимость от них 
• Производящие их компании и сообщества уже много лет ничего реально не улучшали 

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

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

Рефакторинг? Да то же самое, весь мой рефакторинг в питоне укладывается в grep и Ctrl+R. Просто нет дублирования информации о модулях и сама питонья культура не приветствует создание пакетов "просто так".

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

Реальная польза от IDE - перетаскивание неудачных решений в дизайне языков и библиотек из области "фатальный бред" в область "можно терпеть". Не более. Бывает ли такое решение проблем необходимо? Конечно бывает. Но надо ли им пользоваться по умолчанию?

Печальна также и ситуация с оценкой проблем создаваемых IDE. Их наблюдается немало, но вспоминать про них - табу. Про то как джавовские null'ы несут зло и хаос написаны многие сотни страниц текстов, про то что IDEA последние 6 лет стабильно фризит на более-менее больших проектах почти никто не вспоминает.Или вернёмся опять к рефакторингу. Несмотря на то что идея изменения структуры кода без изменения его семантики в общем то здравая, тут тоже важна мера. Один из негативных эффектов наличия IDE в наборе инструментов - это откровенный спам рефакторингами. Не нравится имя? Две кнопки, вбить новое и готово! Захотелось перепилить структуру пакетов? Берём мышку, драг, дроп, кровь-кишки-мозги по стенам.

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

Самая очевидная проблема - IDE скрывают реальное положение вещей в коде. Бессистемное именование, иерархии классов в 8 уровней, пинг-понг из вызовов перегрузок и super - всё это успешно маскируется навороченным Hierachy view. Проблема в том что инструменты могут что-то сделать с механической частью проблемы - найти все перегрузки, вызовы, ветвления. Но они бессильны с интеллектуальной частью - программисту всё так же надо разбираться в таких путаных структурах.

В коммерческой разработке на Java и C# сейчас наблюдается крайне болезненный культ IDE. Примерно треть половина что я видел не собиралась иначе чем экспортом из конкретной среды, примерно треть могла нормально разрабатываться в одной единственной среде из-за code style или кодогенерации или того что единственное описание зависимости между модулями - проект в проприетарном формате созданный 5 лет назад.

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

Проблема в том что разработчики Git плагинов для IDEшек с которыми я работал либо просто не в курсе этой особенности, либо менеджеры соответствующей квалификации пояснили им что разноцветный дифф важнее для хомяков чем какая-то там расширяемость. Как следствие нельзя настраивать и даже использовать уже настроенные алиасы и нельзя удобно призывать на выполнение внешние скрипты. Зато есть кнопки Update и Commit&Push... Ну можете представить как выглядит история когда проект резко переезжает с SVN, никто не пользуется гуглом а среда представляет такой easy по самое не могу функционал.

Ну и наконец о развитии - для сред разработки оно остановилось где-то в 90. IDEA 12 отличается от от JBuilder 2003 практически только разнообразными окошками навигаторов, а он в свою очередь от Turbo Pasсal 6 в основном наличием индекса символов и файлов. И все вместе они на фоне Squeak, скажем так, не выглядят достижениями трёх пятилеток.

Не хватает реальной интеграции компонентов. Например, как дебагер задействует редактор? Красная полоска в месте останова и попап со значением переменной. И то если программер позаботился о правильном toString, а если нет - пожалуйста прокликивайте дерево объектов. Это в две тысячи четырнадцатом году предел юзабилити и визуализации типа? Я LabView году так в 04-05 поюзабельнее дебагер рисовал.

И кстати о рисовании. В 2014 опять же году, когда всё прогрессивное человечество хреначит колбэки на жаваскрипте встраивает DSL в любой инструмент сложнее cat, для расширения любой IDE мне надо создать модуль(!) плагина, скомпилировать(!) его, положить в нужную папочку а то и прокликать пару форм и перезапустить(!) софтину. Future of programming, чо. Самый доступный способ расширения что предлагается - разлапистая форма настройки брекпоинта с condition и log message (в студии то небось до сих пор и того нет?).

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

Потому что так не делали в 1995 году? Я не вижу других причин.

Land of Lisp

Дочитал сабж. Как можно догадаться книга посвящена языку LISP и выстроена очень своеобразным образом. Основная идея: обучить языку через написание игр. Этот, на первый взгляд направленный на детей, подход в моём случае имел изрядный успех.

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

Скажу честно не все примеры я аккуратно реализовывал и запускал, но примерно 60% задач из книги я выполнил. Что-то расширил, где-то поменял структуру кода - подход с созданием игр в книге даёт читателю очень высокий уровень вовлечённости и это прекрасно.

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

Код примеров на мой вкус немного грязноват. Много где можно радикально улучшить читабельность простыми изменениями вроде добавления структур вместо списков и магических ca*r'ов, заменой анонимных функций на именованные. Стиль который она оставляет после себя как мне кажется нельзя назвать изящным, но это мнение нуба явно тяготеющего к диалектам Scheme-семейства а не Common для которого написана книга.

И да, просто копировать примеры в таком виде было не очень интересно и решение нашлось само собой - я недавно начал ковырять Racket а книжка то написана под Common LISP! Вот и совместил приятное с полезным, транслировал примеры на современный Racket. И я теперь практически лисп-переводчик с опытом работы :) Кстати благодаря этой книжке я сделал и небольшой (и кажется первый сколько-нибудь полезный) вклад в опенсурс: изрядно подвыправил Racket плагин для Sublime.

В общем несмотря на то что книжка вроде не блестящая при должном настрое и желании что-то поделать руками она приночит массу удовольствия. Рекомендую!

Линкопост #2

Пачка ссылок за последние... 4 месяца. Для начала связанное с Racket.

The Racket Way - доклад на strange loop, рассказ о дизайне или даже скорее философии Racket. Несколько наглядных примеров потребности в мета-языках. Достаточно подробно показана возможность плавной эволюции по пути приложение, библиотека, internal DSL, подмножество языка и новый язык со специальным синтаксисом в конце. Полезно посмотреть и как введение в Racket и чтобы понять что можно делать с мета-языками. Мне такая схема показалось существенно более жизнеспособной чем применение MPS или создание external DSL с 0.

Fear of Macros - что-то вроде мини-книги или большого цикла статей о макросах в Racket. Вопрос раскрывается гораздо удачнее чем в основной документации. Автор начинает с простого но низкоуровнего примера и оттуда движется к высокоуровневым pattern-based macros. Оставляет целостное понимание что такое syntax object, expansion и т.д. Интересно будет тем что интересуется мета-программированием или изучает схему.

Frog - аналог Octopress на Racket, вроде попроще в инсталляции. Выглядит симпатично, использует модный Bootstrap. В качестве языка разметки в том числе можно использовать Scribble или Markdown. Код более менее читаемый, в общем неплохой проект для поиграться с языком и посмотреть как на нём пишут реальный софт.

Немного холиваров и вбросов.

We're Doing It All Wrong - доклад от бывшего участника разработки компилятора Scala. Подробно, хотя и крайне эмоционально рассматривает различные проблемы в самом языке и текущей реализации компилятора. Немного сумбурно - неявно мешаются в кучу проблемы дизайна языка,  библиотеки, кода компилятора а в конце вообще выдвигается идея некоего идеального языка не совсем очевидно связанная с озвученными проблемами. Но в любом случае стоит уделить внимание если вы планируете куда-то внедрять скалу.

The Unreasonable Effectiveness of C - наверно одна из самых интересных статей из прочитанных мной за последнее время. Анализируется почему старый, низкоуровневый язык C был и остаётся популярным и весьма успешным. Строго рекомендовано к прочтению фанбоям хаскелей, скал, джаваскриптов, коков и всего остального что конвертирует силу мысли в быстрые и безбажные программы.

Честно про современные веб-технологии - запихнул в этот раздел, но вообще считаю все написанное в посте чистейшей правдой. Не могу не добавить что надвигающийся HTTP 2.0 обещает сделать реализацию и поддержку веб-сервера уделом пары-тройки корпораций.

Хорошие статьи по практике программирования.

Computational Geometry in Python: From Theory to Implementation - понятный и краткий обзор вычислительной геометрии с точки зрения программиста. Хорошо проиллюстрирован кодом на питоне. Очень приятный способ размять мозги в новой области.

How to design and code a complete program - очень хорошая серия статей о дизайне в функциональном стиле. Построена вокруг одного примера - CRUD приложения для веба. Просто и наглядно излагаются некоторые неочевидные концепции. Код на хаскеле.

Ну и немного философии. Why education is so difficult and contentious - большой обзор происхождения и актуальных проблем современного образования. Интересна тем что внятно формулирует цели образования и показывает что они не очень то совпадают с интересами современного индивида, да и во многом общества.

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

"(Не)совершенная случайность"

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

Книга посвящена теории вероятности и содержит её рассмотрение сразу с нескольких ракурсов и автор не старается как-то их разделять по ходу изложения. Теория рассказывается от простого к сложному с привлечением разных ракурсов по мере необходимости. В принципе в кинге уверенно распознаются три аспекта.

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

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

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

Также хочется отметить перевод - действительно хороший и грамотный. Я не заметил ни одной шероховатости в терминологии и описании сложных ошибок использования тервера. Единственный момент который вызвал моё непонимание это название книги. На английском она называется "Drunkard's Walk" то есть "Походка пьяного" как я понимаю.

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

Clojure vs. Racket - мои наблюдения

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

В финал вышли два - Clojure и Racket. Common Lisp я отбросил так как в нём многовато на мой вкус специальных форм, макросов и прочих интересных вещей, мне он показался достаточно непоследовательным. Для двух финалистов есть известное и по сути очень хорошее сравнение. Его вывод достаточно однозначен - на практике программировать на Clojure гораздо удобнее, а для учебных целей у диалектов паритет. Однако пост от 2010 года и часть данных там устарели. Ниже я перечислю все устаревшие моменты в том посте ну и приведу пару фактов которые склонили мой выбор в пользу ракеты.

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

Вторая проблема: не консистентная работа со словарями. Она исправлена во-первых ведением протокола для словарей, поддерживаемого из коробки хеш-таблицами и списками пар. Во-вторых богатым семейством функций in-dict* по преобразованию словарей в последовательности.

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

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

Почему я в итоге выбрал Racket? Буквально две причины. Во-первых в Clojure слишком много на мой вкус синтаксических конструкций. Да да, ЛИСП с избытком конструкций, куда мир катится? Куча каких-то скобочек, шапочек, двоеточий и стрелочек... Всякие навороты вроде ключевых слов очень активно используются стандартной библиотекой. Вторая - JVM. Сейчас я уж слишком привязан к ней, надо как-то расширять кругозор.

Чем хорош текст

Недавно отсмотрел серию презентаций небезызвестного Брета Виктора. Кстати всем их рекомендую. Последнюю из них, "The Future Of Programming", я бы назвал вторым лучшим техническим докладом что я видел (Угадайте какой первый?).

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

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

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

Кусок текста можно послать коллеге в скайпе или вставить в научную статью с минимальными затратами. Текст ничего не потеряет, хитрая визуализация динамически скрывающая часть свойств и связей объектов может оказаться не пригодной для простой пересылки если на другом конце нет ПО которое её переваривает. В конце концов текст можно перенести на бумагу и (если он разумного размера) взять с собой на необитаемый остров.

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

У этого достоинства есть пара очень важных подпунктов. Первый - это валидация. Для текстов есть развитая теория грамматик и не менее развитая практика написания парсеров. Есть ли они для графов/картинок?

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

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

Упрощение кода с case classes - пример

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

Как мне кажется проблемы с читабельностью имеют две основные причины.

1. 3 возможных состояния объекта закодированы в 3 аттрибутах. При этом возможны заведомо бессмысленные состояния (doneCnt != res.size() или ex != null && doneCnt == totCnt).
2. Методы fail, add, listen судя по коду предпринимают какие-то действия  в слепую, иногда проверяя лишь часть переменных. Как следствие о корректности кода нельзя судить по отдельным фрагментам - нужно думать о поведении всех методов сразу.

Это в принципе типичные неприятности при дизайне классов в классическом джавовском стиле. Давайте посмотрим как пара простых изменений позволили их устранить.

Суть выражена в переходе от набора из нескольких аттрибутов к одному но с более сложной структурой.
Было:

private var doneCnt = 0
private var ex: Exception = null
private val res = new ArrayList[T](totCnt)

Cтало:

private var res: Either[util.ArrayList[T], Exception] = Left(new util.ArrayList[T](totCnt))

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

Было:

def add(item: T) {
  lock.lock()
  try {
    res.add(item)
    doneCnt = doneCnt + 1
    if (doneCnt == totCnt) {
      done.signalAll()
      for (lsnr <- succLsnrs)
        lsnr(res)
    }
  }
  finally {
    lock.unlock()
  }
}

Cтало:

def add(item: T) {
  lock.lock()
  try {
    res match {
      case Left(list) if list.size < totCnt => {
        list.add(item)
        if (list.size == totCnt) {
          done.signalAll()
          for (lsnr <- succLsnrs)
            lsnr(list)
        }
      }
      case _ => return
    }
  }
  finally {
    lock.unlock()
  }
}

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

1. Right(exception) - сбор результатов провалился.
2. Left(list) && list.size < totCnt - сбор результатов всё ещё в процессе.
3. Left(list) && list.size == totCnt - сбор результатов завершён их все можно получить.

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

Метод fail тоже неплохо прибавил в выразительности - теперь оба add и fail явно переводят объект из одного состояния в другое. Надо признать что новая версия ведёт себя не точно так-же как старая, новый подход сделал более строгое поведение и более лёгким. add больше не принимает результаты сверх заданного числа, а fail - не изменяет состояние завершённого объекта.

Было:

def fail(e: Exception) {
  lock.lock()
  try {
    ex = e
    done.signalAll()
    for (lsnr <- failLsnrs)
      lsnr(ex)
  }
  finally {
    lock.unlock()
  }
}

Cтало:

def fail(e: Exception) {
  lock.lock()
  try {
    res match {
      case Left(list) if list.size < totCnt => {
        res = Right(ex)
        done.signalAll()
        for (lsnr <- failLsnrs)
          lsnr(ex)
      }
      case _ => return
    }
  }
  finally {
    lock.unlock()
  }
}

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

Было:

def get: JavaCollection[T] = {
  lock.lock()
  try {
    while (doneCnt != totCnt) {
      if (ex != null)
        throw ex
      done.await()
    }

    res
  }
  finally {
    lock.unlock()
  }
}

Cтало:

def get: JavaCollection[T] = {
  lock.lock()
  try {
    while (res.left.toOption.exists(_.size < totCnt))
      done.await()

    res match {
      case Left(list) => list
      case Right(ex) => throw ex
    }
  }
  finally {
    lock.unlock()
  }
}

Метод listen в принципе изменился так же как get, так что я не буду приводить его код. Вот окончательная версия.

Я вижу следующие явные улучшения:

1. Вместо 3х скоординированных значений - одно, содержащее результат. Состояний по-прежнему три, но способ их кодирования радикально упростился.
2. Методы add, fail, listen изменили форму. Раньше они более а в основном менее явно предполагали некую историю изменений и обновляли состояние на основе этих предположений. Теперь методы инспектируют текущее состояние, и устанавливают новое на его основе. Практически конечный автомат.
3. Метод get сначала неявно ожидал нужного состояния одной из двух переменных (ex и size), "произошло исключение или количество результатов сравнялось с ожидаемым". Теперь этот метод явно ожидает пока нарушится одно условие, "существует неполный список результатов". Точек принятия решения в методе изначально было две, стала одна.

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