Решил немного отвлечься от технического образования и заняться научно-популярной литературой. Был приятно удивлён простотой и доступностью книги вышедшей в оригинале на русском да ещё и написанной человеком работающим в Москве. Работа всё ещё не попадает в разряд лёгкого чтива, требует определённой концентрации и запоминания терминологии, но тем не менее доступна без специальной подготовки и даже приятна для людей со склонностью к разбиранию сложных штук.
Книга посвящена современному состоянию эволюционной биологии, в особенности тому что известно о ранних этапах развития жизни. Попутно делается краткий экскурс в современное состояние генетики и молекулярной биологии, которые изрядно продвинулись со времён написания учебников по которым я учился. Много врезок кратко описывающих результаты отдельных исследований конца 2010х годов и их место среди остального материала. Как и положенно научной книге большинство упомянутых фактов сопровождаются ссылками на соответствующие работы.
Медленно и неспешно, начиная с самых простых организмов автор рассматривает как устроен и мог возникнуть соответствующий тип. Начало, конечно, получается довольно насыщенным гипотетическими формами жизни, но это, по мере приближения во времени к современности а по уровню организации к современным многоклеточным и их сообществам, проходит. Приводится множество фактов палеонтологии и недавних открытий реликтовых видов, про которые неспециалисты вряд ли слышали. Огромный массив информации представляется как логически связанная цепочка фактов.
Неожиданно подробно для книги с такой направленностью разбираются химические механизмы регуляции в живых организмах, современное состояние молекулярной биологии. Все даётся в описательном виде, без технических деталей, что может быть небольши минусом для людей не страдающих страхом перед химией. Где уместно полностью рассматриваются цепочки обратной связи от гена до влияния на внешнюю среду и обратно, приводится несколько "интуитивных" доказательств что даже самые простые обратные связи могут эволюционировать в сторону усложнения и адаптации. Вообще одна из позитивных идей вынесенных мной из книги - математические модели и формальные доказательства становятся всё более важной частью биологии.
В общем книга оставляет в голове достаточно яркую и развёрнутую картину современной биологии и её взгляда на историю жизни. Бонусом читатель знакомится с существенно более детальным описанием микроскопического устройства клетки и её механизмов регуляции чем остаётся от школьного курса биологии. В целом дочитывал книгу в состоянии легкого восторга и немедленно приобрёл ещё одни труд автора, ждите ещё обзоров.
среда, 4 февраля 2015 г.
среда, 12 ноября 2014 г.
Линкопост #3
Понял что умных своих мыслей не было уже пару месяцев и не предвидится. Давайте хоть чужими поделюсь чтобы блог не умер.
Для начала про хаскель и теорию:
Crash Course on Notation in Programming Language Theory - название говорит само за себя. Позволяет не пропускать разделы с формальной семантикой в современных статьях по теории ЯП. В принципе материал достаточно уникальный, я например больше нигде не видел описания этой нотации.
Также наткнулся на две статьи с нормальным описанием подхода к IO в Haskell. First-Class “Statements” и I/O Is Pure. Они наглядно показывают как устроен ввод-вывод в ленивых языках. Что такое тип IO и каков смысл основных операций с ним в терминах "read data" и "apply to result" а не выдуманнных эффектов и действий. Как небольшой побочный результат дают возможность понять что монады, функторы и прочие интересности которыми забиты все тьюториалы и ответы на SO никакого отношения к сути IO не имеют.
Нашлось за полгода и много интересного и про развитие языков программирования.
Всплыла демо-сессия посвящённая дебаггеру в Elm, Bret Victor style reactive debugging. Сейчас этот проект уже влит в основную ветку разработки и доступен как reactor.
Chris Granger написал пару стоящих прочтения статей о том что он дальше собирается делать с IDE. Первая, Toward a better programming, неплохо рассмотрено почему софт пишется медленно и заброшена пара идей что с этим можно сделать. Также было сделано объявление о старте EVE, по делу там достаточно мало, но всё-таки читать интересно. Фактически признано что Light Table превратился в "ещё один редактор" с парой секси фич. Чтож светлая ему память, у EVE есть все шансы таки сдвинуть идею "среды разработки" с мёртвой точки.
Интересная декларация создания двухуровневого языка программирования. Я так понял чистое прожектёрство, по проекту год не было новостей, но идея выглядит неплохо Big Programming, Small Programming.
Небольшой флешбэк, The Mother of All Demos. Презентация руководителя ARC о результатах работы лаборатории 1968 года. Показывается ряд интерактивных систем и озвучиваются идеи их развития. Пользуясь случаем хочу передать пламенный привет всем свидетелям Джобса придумавшего ПК.
Отдельно стоит найденная мной серия лекция Хэмминга (того самого) Learning to Learn. Название говорит само за себя, Хэмминг рассказывает о том как он учился сам и советует как учиться студентам. Особого внимания достойна завершающая лекция You and Your Research.
Для начала про хаскель и теорию:
Crash Course on Notation in Programming Language Theory - название говорит само за себя. Позволяет не пропускать разделы с формальной семантикой в современных статьях по теории ЯП. В принципе материал достаточно уникальный, я например больше нигде не видел описания этой нотации.
Нашлось за полгода и много интересного и про развитие языков программирования.
Всплыла демо-сессия посвящённая дебаггеру в Elm, Bret Victor style reactive debugging. Сейчас этот проект уже влит в основную ветку разработки и доступен как reactor.
Chris Granger написал пару стоящих прочтения статей о том что он дальше собирается делать с IDE. Первая, Toward a better programming, неплохо рассмотрено почему софт пишется медленно и заброшена пара идей что с этим можно сделать. Также было сделано объявление о старте EVE, по делу там достаточно мало, но всё-таки читать интересно. Фактически признано что Light Table превратился в "ещё один редактор" с парой секси фич. Чтож светлая ему память, у EVE есть все шансы таки сдвинуть идею "среды разработки" с мёртвой точки.
Интересная декларация создания двухуровневого языка программирования. Я так понял чистое прожектёрство, по проекту год не было новостей, но идея выглядит неплохо Big Programming, Small Programming.
Небольшой флешбэк, The Mother of All Demos. Презентация руководителя ARC о результатах работы лаборатории 1968 года. Показывается ряд интерактивных систем и озвучиваются идеи их развития. Пользуясь случаем хочу передать пламенный привет всем свидетелям Джобса придумавшего ПК.
Отдельно стоит найденная мной серия лекция Хэмминга (того самого) Learning to Learn. Название говорит само за себя, Хэмминг рассказывает о том как он учился сам и советует как учиться студентам. Особого внимания достойна завершающая лекция You and Your Research.
Ну и немного по управлению, статья в духе капитана, но так нереально трудно усваиваемая людьми работающими в менеджменте Банальность: главный ингредиент в разработке ПО -- это люди.
понедельник, 11 августа 2014 г.
Опыт с Bullet Journal
Какое-то время назад я увидел сам и немного порекламировал окружающим аналоговую систему ведения списка дел: Bullet Journal. Суть кратко: автор предлагает типографскую нотацию легко воспроизводимую от руки для управления списками дел на бумаге без помощи компьютера.
Сама идея весьма удобна. Во-первых аналоговая запись существенно расширяет диапазон артефактов которые можно хранить, в программировании часто нет слов зато есть небольшая схемка. Во-вторых записи можно обрабатывать и дополнять оффлайн, в вагоне поезда, в палатке за городом, когда лежишь на диване и боишься случайно засветиться в скайпе.
Однако некоторые детали этой системы меня не устроили и в процессе использования прижился ряд поправок. Последняя версия не подвергалась изменениям уже месяца 3, так что я решил ей поделиться.
Крупнейшее изменение которое я внёс состоит в разделении журнала на две книги. Одну для "текучки" и одну для "вечного". Первую я веду в блокноте чуть меньше А5, туда идут собственно кратковременные задачи и малозначимые заметки по разным топикам. Вторую я веду в обычной школьной тетради. Туда идут долговременные планы, эскизы по разным проектам, важные мысли. Обе книги оформлены как оригинальный журнал: содержат нумерацию страниц и оглавление.
Второе важное отличие: удаление контента. Меня существенно раздражает наличие в поле зрения ненужных вещей, в частности топиков которые уже точно не актуальны. И если оригинальный журнал был append-only, то мои книги подразумевают удаление. В книге с текучкой я просто вычёркиваю элементы оглавления и вырываю соответствующие страницы когда топик становится полностью закрыт или не актуален. Из книги с вечным я только вычёркиваю названия топиков как в оглавлении так и на странице.
Небольшим изменением подвергся набор иконок. Значок "звезда" долго рисовать и редко получается если пишешь на коленях. Иконка priority была заменена на восклицательный знак, соответственно для inspiration я использю простую молнию. Теперь все значки рисуются в пару касаний и узнаваемы даже когда добавлены в вагоне метро.
Я полностью не отказался от цифрового хранения тудушек. Для трекинга живого и эволюционирующего проекта оно подходит лучше. Ну и хранить ссылки на бумаге немного не удобно. Для таких задач я использую Trello. Топики иногда перемещаются между журналом и облаком. Для сохранения разума были выработаны два правила. Первое: никакой топик не живёт одновременно в двух системах. Второе: никогда не осуществлять перенос сразу, я всегда ставлю специальную пометку в названии и осуществляю перенос только когда на неё натыкаюсь.
Система в общем оказалась весьма полезной и после небольшого тюнинга достаточно удобной. Иногда приходится выделять полчаса на обзор текущего состояния журнала и чистку перенос части содержимого, но случается это примерно раз в два месяца. При том что я регулярно оказываюсь поездах, автобусах и т.п. без особого желания читать но с желанием о чём-то подумать бумажный журнал оказывается весьма кстати. Основная проблема не забыть книги дома, но надёжного способа борьбы с ней пока не придумано.
Сама идея весьма удобна. Во-первых аналоговая запись существенно расширяет диапазон артефактов которые можно хранить, в программировании часто нет слов зато есть небольшая схемка. Во-вторых записи можно обрабатывать и дополнять оффлайн, в вагоне поезда, в палатке за городом, когда лежишь на диване и боишься случайно засветиться в скайпе.
Однако некоторые детали этой системы меня не устроили и в процессе использования прижился ряд поправок. Последняя версия не подвергалась изменениям уже месяца 3, так что я решил ей поделиться.
Крупнейшее изменение которое я внёс состоит в разделении журнала на две книги. Одну для "текучки" и одну для "вечного". Первую я веду в блокноте чуть меньше А5, туда идут собственно кратковременные задачи и малозначимые заметки по разным топикам. Вторую я веду в обычной школьной тетради. Туда идут долговременные планы, эскизы по разным проектам, важные мысли. Обе книги оформлены как оригинальный журнал: содержат нумерацию страниц и оглавление.
Второе важное отличие: удаление контента. Меня существенно раздражает наличие в поле зрения ненужных вещей, в частности топиков которые уже точно не актуальны. И если оригинальный журнал был append-only, то мои книги подразумевают удаление. В книге с текучкой я просто вычёркиваю элементы оглавления и вырываю соответствующие страницы когда топик становится полностью закрыт или не актуален. Из книги с вечным я только вычёркиваю названия топиков как в оглавлении так и на странице.
Небольшим изменением подвергся набор иконок. Значок "звезда" долго рисовать и редко получается если пишешь на коленях. Иконка priority была заменена на восклицательный знак, соответственно для inspiration я использю простую молнию. Теперь все значки рисуются в пару касаний и узнаваемы даже когда добавлены в вагоне метро.
Я полностью не отказался от цифрового хранения тудушек. Для трекинга живого и эволюционирующего проекта оно подходит лучше. Ну и хранить ссылки на бумаге немного не удобно. Для таких задач я использую Trello. Топики иногда перемещаются между журналом и облаком. Для сохранения разума были выработаны два правила. Первое: никакой топик не живёт одновременно в двух системах. Второе: никогда не осуществлять перенос сразу, я всегда ставлю специальную пометку в названии и осуществляю перенос только когда на неё натыкаюсь.
Система в общем оказалась весьма полезной и после небольшого тюнинга достаточно удобной. Иногда приходится выделять полчаса на обзор текущего состояния журнала и чистку перенос части содержимого, но случается это примерно раз в два месяца. При том что я регулярно оказываюсь поездах, автобусах и т.п. без особого желания читать но с желанием о чём-то подумать бумажный журнал оказывается весьма кстати. Основная проблема не забыть книги дома, но надёжного способа борьбы с ней пока не придумано.
понедельник, 4 августа 2014 г.
"Mathematics for Computer Graphics" и "Computational Geometry: Algorithms and Applications"
Последние полгода очень сильно ленился в плане чтения и справился всего с двумя книжками.
Первая "Mathematics for Computer Graphics" - краткое ревью математики полезной для программирования графики. Книга в принципе неплоха как напоминание и как компактная коллекция полезных математических инструментов. В качестве книги для начального изучения чего либо она к сожалению не очень хороша по нескольким причинам.
Во-первых книге катастрофически не достаёт иллюстративного материала, что фатально сказывается на скорости начального восприятия. Ко многим выкладкам и доказательствам приходится рисовать картинки самостоятельно, что исключает чтение книги в транспорте или на отдыхе.
Вторая проблема: разная глубина изложения в разных разделах. Какие-то направления представлены подборкой основных формул и их интерпретацией. Где-то есть пара примеров их применения, где-то вдруг приводятся доказательства. При сквозном чтении очень тяжело зацепиться за какой-то ритм и следовать ему.
В общем книга приемлема для полки в качестве справочника и не может использоваться для начального ознакомления с мат. аппаратом.
Вторая, "Computational Geometry: Algorithms and Applications". Книга как раз противоположна предыдущей - она очень удачна в качестве учебника. Начинает с простого, продолжает непростым, заканчивает комбинацией ранее изложенного. Очень приятной деталью является отличное покрытие иллюстрациями. Все логические построения и алгоритмы сопровождаются удачными рисунками - мне практически не приходилось брать карандаш и бумагу в руки.
Рассматривается около полутора десятков проблем вычислительной геометрии. Каждая атакуется плавно. Нет хороших решений из коробки, всегда показывается эволюция алгоритма от простых идей и игнорирования предельных случаев до доказуемо корректного решения. Авторы часто приводят не лучший алгоритм предпочитая детально описать более простой и понятный.
Чтение не требует знаний выходящих за первый семестр курса алгоритмов. Используются самые базовые вещи: деревья, кучи, списки. Анализ алгоритмов предполагает только знакомство с нотацией асимптот и умение решать "recurrences".
Все главы сопровождаются небольшим ревью вопроса. Там даётся история изучения проблемы и наиболее сильные современные результаты. Часто есть обзор смежных областей, приложений и т.п. Список ссылок огромный.
Книга даёт приятный уровень нагрузки на мозг, каждая задача требует 10-15 сконцентрированных размышлений сверх времени на прочтение. Можно рекомендовать и как учебник если вдруг пришлось столкнуться с геометрическими проблемами так и для развивающего чтения. В целом книга мне исключительно понравилась.
Первая "Mathematics for Computer Graphics" - краткое ревью математики полезной для программирования графики. Книга в принципе неплоха как напоминание и как компактная коллекция полезных математических инструментов. В качестве книги для начального изучения чего либо она к сожалению не очень хороша по нескольким причинам.
Во-первых книге катастрофически не достаёт иллюстративного материала, что фатально сказывается на скорости начального восприятия. Ко многим выкладкам и доказательствам приходится рисовать картинки самостоятельно, что исключает чтение книги в транспорте или на отдыхе.
Вторая проблема: разная глубина изложения в разных разделах. Какие-то направления представлены подборкой основных формул и их интерпретацией. Где-то есть пара примеров их применения, где-то вдруг приводятся доказательства. При сквозном чтении очень тяжело зацепиться за какой-то ритм и следовать ему.
В общем книга приемлема для полки в качестве справочника и не может использоваться для начального ознакомления с мат. аппаратом.
Вторая, "Computational Geometry: Algorithms and Applications". Книга как раз противоположна предыдущей - она очень удачна в качестве учебника. Начинает с простого, продолжает непростым, заканчивает комбинацией ранее изложенного. Очень приятной деталью является отличное покрытие иллюстрациями. Все логические построения и алгоритмы сопровождаются удачными рисунками - мне практически не приходилось брать карандаш и бумагу в руки.
Рассматривается около полутора десятков проблем вычислительной геометрии. Каждая атакуется плавно. Нет хороших решений из коробки, всегда показывается эволюция алгоритма от простых идей и игнорирования предельных случаев до доказуемо корректного решения. Авторы часто приводят не лучший алгоритм предпочитая детально описать более простой и понятный.
Чтение не требует знаний выходящих за первый семестр курса алгоритмов. Используются самые базовые вещи: деревья, кучи, списки. Анализ алгоритмов предполагает только знакомство с нотацией асимптот и умение решать "recurrences".
Все главы сопровождаются небольшим ревью вопроса. Там даётся история изучения проблемы и наиболее сильные современные результаты. Часто есть обзор смежных областей, приложений и т.п. Список ссылок огромный.
Книга даёт приятный уровень нагрузки на мозг, каждая задача требует 10-15 сконцентрированных размышлений сверх времени на прочтение. Можно рекомендовать и как учебник если вдруг пришлось столкнуться с геометрическими проблемами так и для развивающего чтения. В целом книга мне исключительно понравилась.
четверг, 19 июня 2014 г.
Что не так с Хаскелем
Недавно тут вспомнилась забавная статья "Почему язык Haskell так непопулярен" от одного из вождей соответствующего сообщества. Понял что со времён её публикации мой ответ на заголовок изменился с абстрактного "нихрена не понял" на список из нескольких достаточно конкретных проблем. Их я и попробую тут расписать.
Во-первых нет учебников и справочников по алгоритмам/структурам данных. Большая часть алгоритмов описана в расчёте на дешёвое присваивание и строгие вычисления. Найти описание и анализ нетривиального алгоритма для хаскельных реалий практически не возможно. У того же Окасаки, как я понимаю, половина книги - разработка аппарата для того чтобы только научиться иметь с этим дело.
К предыдущей плотно примыкает проблема номер два. Ленивые вычисления - это фактически полная передача компилятору баланса между потреблением памяти и процессора. Иногда он сдвигает его в совершенно неожиданное место и программа вдруг начинает требовать феерические объёмы ресурсов. Что с этим делать непонятно, гайды которые мне удавалось находить написаны для разрабов этого самого компилятора. В них в принципе нет введений, даже нет ссылок, предполагается что огромная масса знаний о реализации вычислительной модели уже в голове. Что делать человеку который прочитал LYHGG, написал первый алгоритм и получил время выполнение или потребление памяти в районе лунной орбиты непонятно.
Лирическое отступление. Пару лет назад я проходил на курсере курс по алгоритмам. Начать попробовал на хаскеле. Первым заданием было посчитать inversions, то есть нарушения порядка в массиве. Решение я написал сравнительно быстро, мин 40. Проблемы начались при запуске - программа пожирала всю доступную память. Несколько ритуальных плясок в обходе списка позволили программе вмещаться в пару гигабайт памяти и 20 минут. И да, выдавать корректный ответ для пары тысяч чисел в первой версии, спустя полтора часа...
Обзор тематических ресурсов подходы к решению проблемы найти не позволил. Консультация с коллегой-фаном хаскеля, который кстати тоже получил что-то не вменяемое в первой версии программы, и перестановка чего-то там в паре выражений (перед глазами встал призрак 2003 студии где перестановка инклудов иногда чинила access violation) позволили сократить время до нескольких минут. Для интереса сделал тоже на питоне за 10 мин, 20 или 30 секунд выполнения и символическое потребление памяти. Искать с помощью Хаскеля минимальный разрез графа из нескольких тысяч узлов я уже не рискнул.
Ну и главное: нет примеров полномасштабных приложений. Какая нибудь обработка исключений от трёх функций с помощью стрелок находится легко. Исходник простого веб-сервера, без расширений языка, без 90% закопанного в библиотеки найти сложно. Хотелось бы увидеть простой аналог рисовалки или текстового редактора. Что угодно что демонстрирует в рамках 3-4 экранов дизайн полноценного приложения которое читает, пишет, показывает что-то пользователю, реагирует на ошибки и нарушения форматов. Таких примеров нет, невозможно оценить какой массив знаний необходим для создания полноценного приложения. Теркат? Трансформеры? Дисер Окасаки? Свободная навигация по исходникам компилятора? Я за три года так и не понял.
Ещё для меня серьёзной проблемой является типографический кретинизм большинства авторов. Он проявляется в нескольких аспектах. Во-первых для функции нормально не иметь человеческого имени. Пишем <*>, в уме проговариваем "треугольна жопа", как описать код коллеге не понятно. Во-вторых статьи абсолютно всех уровней, от ICFP до очередного тьюториала по монадам в блоге программиста Васи наполнены типографскими аналогами собственно операторов языка, то есть вместо -> везде →. Какая-нибудь тау с нижним и верхним индексом - тоже святое дело. Вообще обучение на примере кода который не запускается - норма для данного сообщества. В том же LYHGG процентов 30 не работало ещё три года назад когда я его читал.
Ну и сообщество. Я там выше давал ссылочку на любителя корректных программ, подпишитесь - понаблюдайте недельку. Подумайте что делать если к такому существу придётся обращаться за поддержкой или оно окажется у вас в команде. Справедливости ради надо заметить что те кто собственно что-то делает, разработчики самого компилятора и популярных билиотек более вменяемы и не лишены кругозора.
Чуть не забыл, данная заметка не претендует на полный охват предмета. Haskell имеет некоторое (конечное) количество положительных черт, но я тут про них умолчал. Жаждущие серебряных пуль могут найти их в интернете во множестве.
UPD: Буду сюда докидывать пруфы
Во-первых нет учебников и справочников по алгоритмам/структурам данных. Большая часть алгоритмов описана в расчёте на дешёвое присваивание и строгие вычисления. Найти описание и анализ нетривиального алгоритма для хаскельных реалий практически не возможно. У того же Окасаки, как я понимаю, половина книги - разработка аппарата для того чтобы только научиться иметь с этим дело.
К предыдущей плотно примыкает проблема номер два. Ленивые вычисления - это фактически полная передача компилятору баланса между потреблением памяти и процессора. Иногда он сдвигает его в совершенно неожиданное место и программа вдруг начинает требовать феерические объёмы ресурсов. Что с этим делать непонятно, гайды которые мне удавалось находить написаны для разрабов этого самого компилятора. В них в принципе нет введений, даже нет ссылок, предполагается что огромная масса знаний о реализации вычислительной модели уже в голове. Что делать человеку который прочитал LYHGG, написал первый алгоритм и получил время выполнение или потребление памяти в районе лунной орбиты непонятно.
Лирическое отступление. Пару лет назад я проходил на курсере курс по алгоритмам. Начать попробовал на хаскеле. Первым заданием было посчитать inversions, то есть нарушения порядка в массиве. Решение я написал сравнительно быстро, мин 40. Проблемы начались при запуске - программа пожирала всю доступную память. Несколько ритуальных плясок в обходе списка позволили программе вмещаться в пару гигабайт памяти и 20 минут. И да, выдавать корректный ответ для пары тысяч чисел в первой версии, спустя полтора часа...
Обзор тематических ресурсов подходы к решению проблемы найти не позволил. Консультация с коллегой-фаном хаскеля, который кстати тоже получил что-то не вменяемое в первой версии программы, и перестановка чего-то там в паре выражений (перед глазами встал призрак 2003 студии где перестановка инклудов иногда чинила access violation) позволили сократить время до нескольких минут. Для интереса сделал тоже на питоне за 10 мин, 20 или 30 секунд выполнения и символическое потребление памяти. Искать с помощью Хаскеля минимальный разрез графа из нескольких тысяч узлов я уже не рискнул.
Ну и главное: нет примеров полномасштабных приложений. Какая нибудь обработка исключений от трёх функций с помощью стрелок находится легко. Исходник простого веб-сервера, без расширений языка, без 90% закопанного в библиотеки найти сложно. Хотелось бы увидеть простой аналог рисовалки или текстового редактора. Что угодно что демонстрирует в рамках 3-4 экранов дизайн полноценного приложения которое читает, пишет, показывает что-то пользователю, реагирует на ошибки и нарушения форматов. Таких примеров нет, невозможно оценить какой массив знаний необходим для создания полноценного приложения. Теркат? Трансформеры? Дисер Окасаки? Свободная навигация по исходникам компилятора? Я за три года так и не понял.
Ещё для меня серьёзной проблемой является типографический кретинизм большинства авторов. Он проявляется в нескольких аспектах. Во-первых для функции нормально не иметь человеческого имени. Пишем <*>, в уме проговариваем "треугольна жопа", как описать код коллеге не понятно. Во-вторых статьи абсолютно всех уровней, от ICFP до очередного тьюториала по монадам в блоге программиста Васи наполнены типографскими аналогами собственно операторов языка, то есть вместо -> везде →. Какая-нибудь тау с нижним и верхним индексом - тоже святое дело. Вообще обучение на примере кода который не запускается - норма для данного сообщества. В том же LYHGG процентов 30 не работало ещё три года назад когда я его читал.
Ну и сообщество. Я там выше давал ссылочку на любителя корректных программ, подпишитесь - понаблюдайте недельку. Подумайте что делать если к такому существу придётся обращаться за поддержкой или оно окажется у вас в команде. Справедливости ради надо заметить что те кто собственно что-то делает, разработчики самого компилятора и популярных билиотек более вменяемы и не лишены кругозора.
Чуть не забыл, данная заметка не претендует на полный охват предмета. Haskell имеет некоторое (конечное) количество положительных черт, но я тут про них умолчал. Жаждущие серебряных пуль могут найти их в интернете во множестве.
UPD: Буду сюда докидывать пруфы
- Need help - my haskell code is over 50 times slower than equivalent perl implementation
- The reasons I don’t write all my code in Haskell
- Where is Haskell going in industry?
- What's the performance bottleneck in this prime sieve function?
- Beginner - Parse Error on Input '='
- How do you avoid the Cabal Hell™? (третий пункт прекрасен, изящный функциональный дизайн типа)
- Complete roadmap from total novice to Haskell mastery?
- How do you structure a program to support logging?
- Why is foldl bad?
понедельник, 26 мая 2014 г.
Нетипичные IDE
Не так давно я написал довольно обстоятельный пост про проблемы современных IDE. В частности подробно отписался почему они могут нанести существенный ущерб проекту без должной осторожности и почему заметной пользы они не приносят. Что характерно пост получился самым популярным за историю блога и много народу не поленилось даже отстоять любимый инструмент в твиттере.
Пришло время перейти к конструктиву и немного посмотреть как их можно делать среды которые что-то меняют в процессе разработки. Есть изрядное количество инструментов которые пытаются продвинуться за пределы 95го года и существенно изменить способ взаимодействия программиста и разрабатываемой им программы.
Вот например Squeake, первый релиз 96 год. (Небось думали я с потолка год в прошлом посте взял? Правильно думали на самом деле, да и большинство обсуждаемых далее фич были в Smalltalk-80). Я наверно повторяю очень известную вещь, но всё таки: основной чертой Smalltalk является существование live image. В нём нет статического кода и времени исполнения, всё что делает программист порождает объекты в одном образе, этот образ несёт в себе и код и живые объекты на одинаковых правах. Образ содержит и ядро языка, и разрабатываемое приложение, и среду разработки одновременно, при поставке пользователю ненужные классы удаляются.
Подход этот конечно спорный, но он имеет несколько явно положительных результатов. Например при разработке графики можно весьма просто с ней управляться. Например имея нарисованную как-то картинку можно немного её покрутить, примерить к другой картинке, продублировать. Как-то так или так (вторая ссылка покороче, но требует скачивания видяшки). А после соответствующего благоустройства среда позволяет что-то программировать даже детям. Ну и вообще она полна простых приятностей, вот например Object inspector.
"Чего же тут такого интересного?" - многие спросят. Вроде и ничего, но вот 2014 год на дворе а все популярные среды разработки по-прежнему считают что цвет нормально показывать как десятизначное число.
Второй интересной наработкой Smalltalk является method finder. Первая его фича - поиск по ключевым словам более менее освоена современными IDE. А вот вторая, поиск по примеру и сейчас, спустя примерно 30 лет после создания насколько я знаю ни кем не повторена. Если кратко она позволяет ввести пример результата метода при заданных аргументах и получить список методов которые этому примеру удовлетворяют. Например на запрос ' trim my spaces '. 'trim my spaces' он ответит #withBlanksTrimmed.
Ладно, хватит истории, вот пара проектов которые прямо сейчас в разработке. Первый, собравший 300k$ на кикстартере, Light table. Это IDE которая должна решить несколько известных проблем и серьёзно пересмотреть постановку других. На данный момент она нацелена на поддержку Clojure, JavaScript и Python. Среди наиболее интересных фичей:
с блэкджеком и монадами.
Проект Lamdu параллельно развивает язык и среду разработки для него. Язык построен на основе Haskell с изменениями направленными на большую явность конструкций и адаптацию для визуального представления структуры программ. В частности он вводит обязательные имена параметров для функций и явно отображает типы в лямбда-выражениях.
Среда построена вокруг структурированного представления и редактирования кода с выделением различных элементов шрифтом и цветом. Редактор позволяет вводить код только в предназначенные для этого слоты, контролирует после ввода тип, предполагаются умные автодополнения. Ошибки типизации получаются хорошо локализованы (не могу не заметить что оригинальный хаскель тут от C++ ушёл совсем не далеко, точность ошибки компенсируется неопределённостью её местоположения).
Редактор автоматически применяет визуальную свёртку сложных языковых конструкций (вроде лямбд и аннотаций параметров как на картинке). Среди целей проекта предоставление билиотекам возможности настраивать отображение для своих структур данных и функций.
Также предполагается поддержка "regression debugging", то есть автоматический контроль хода выполнения теста и поиск изменения которое сломало тест. Примерно можно сказать что IDE будет запоминать все промежуточные результаты вычисления функций и сравнивать их для каждой версии. Хотя в контексте ленивости языка всё явно будет хитрее.
Помимо попыток привнести глобальные улучшения в IDE есть несколько инструментов реализующие какие-то конкретные компоненты гораздо лучше, чем принято в мэйнстриме.
Вот например Projucer, инструмент визуальный разработки для Juce. Ничего сверхъестественного, просто быстрая связь кода и картинки, но всё-таки поживее многочисленных SWING-дизайнеров, а пишется одним человеком.
Ещё один проект, коммерческий, Chronon. Включает в себя "Time Traveling Debugger". Это забавный инструмент который работает с полной записью исполнения программы. Записи получаются с помощью чёрной магии и второго компонента Chronon'а - "Recording Server". Нам же тут интересен дебаггер.
Его центральной фичей является возможность идти не только вперёд но и назад. Найдя ошибку можно вместо того чтобы расставлять бряки в подозрительных местах и перезапускать программу просто пойти назад и посмотреть "откуда пошло". Есть множество приятностей, вроде подсветки активных путей исполнения, истории состояний для переменных и вызовов методов. Много различных фильтров для поиска нужных значений в истории. Для примера можно посмотреть вот это видео.
Последний пример с совсем неожиданного направления, из мира железячных корпораций и кровавого геймдева. PhysX debugger - инструмент для физического движка от nVidia. Он создан для отладки поведения физической модели в сложных сценах. И демонстрирует очень высокий уровень использования различных визуализаций. Если вам интересно визуальное программирование я рекомендую потратить 15 мин и посмотреть обзорный ролик целиком: PVD tutorial video.
В этом инструменте есть множество примеров визуализации разных аспектов динамических сцен и процесса их вычисления, вот интересный кусочек для ленивых (смотреть минуты три). Есть функции бэктрекинга, когда есть бажный объект, есть момент времени когда с ним что-то не так и надо найти откуда проблема появилась. Предусмотрены инструменты для командной работы, можно аннотировать дебаг-сессию оставляя каменты к объектам в определённые моменты времени. Сессия экспортируется и может быть передана коллеге для дальнейшего разбора проблемы. Действительно развитый инструмент для решения весьма нетривиальных задач.
Напоследок уже в который раз не могу не дать ссылку на сайт Bret Victor'а, которого авторы большинства описанных выше проектов называют в числе основных источников идей: worrydream.com. Если Вы ещё не изучили все его материалы стоит немедленно начать.
Пришло время перейти к конструктиву и немного посмотреть как их можно делать среды которые что-то меняют в процессе разработки. Есть изрядное количество инструментов которые пытаются продвинуться за пределы 95го года и существенно изменить способ взаимодействия программиста и разрабатываемой им программы.
Вот например Squeake, первый релиз 96 год. (Небось думали я с потолка год в прошлом посте взял? Правильно думали на самом деле, да и большинство обсуждаемых далее фич были в Smalltalk-80). Я наверно повторяю очень известную вещь, но всё таки: основной чертой Smalltalk является существование live image. В нём нет статического кода и времени исполнения, всё что делает программист порождает объекты в одном образе, этот образ несёт в себе и код и живые объекты на одинаковых правах. Образ содержит и ядро языка, и разрабатываемое приложение, и среду разработки одновременно, при поставке пользователю ненужные классы удаляются.
Подход этот конечно спорный, но он имеет несколько явно положительных результатов. Например при разработке графики можно весьма просто с ней управляться. Например имея нарисованную как-то картинку можно немного её покрутить, примерить к другой картинке, продублировать. Как-то так или так (вторая ссылка покороче, но требует скачивания видяшки). А после соответствующего благоустройства среда позволяет что-то программировать даже детям. Ну и вообще она полна простых приятностей, вот например Object inspector.
"Чего же тут такого интересного?" - многие спросят. Вроде и ничего, но вот 2014 год на дворе а все популярные среды разработки по-прежнему считают что цвет нормально показывать как десятизначное число.
Второй интересной наработкой Smalltalk является method finder. Первая его фича - поиск по ключевым словам более менее освоена современными IDE. А вот вторая, поиск по примеру и сейчас, спустя примерно 30 лет после создания насколько я знаю ни кем не повторена. Если кратко она позволяет ввести пример результата метода при заданных аргументах и получить список методов которые этому примеру удовлетворяют. Например на запрос ' trim my spaces '. 'trim my spaces' он ответит #withBlanksTrimmed.
Ладно, хватит истории, вот пара проектов которые прямо сейчас в разработке. Первый, собравший 300k$ на кикстартере, Light table. Это IDE которая должна решить несколько известных проблем и серьёзно пересмотреть постановку других. На данный момент она нацелена на поддержку Clojure, JavaScript и Python. Среди наиболее интересных фичей:
- Абстрагирование от файлов проекта, редактор показывает и даёт редактировать функции динамически компонуя их по мере просмотра и редактирования исходников.
- Автоматический показ документации и/или исходников связанных функций.
- Интерактивная отладка, как через горячую подмену кода так и через 'watches' которые позволяют записывать и отображать состояние программы в отдельных точках.
Проект Lamdu параллельно развивает язык и среду разработки для него. Язык построен на основе Haskell с изменениями направленными на большую явность конструкций и адаптацию для визуального представления структуры программ. В частности он вводит обязательные имена параметров для функций и явно отображает типы в лямбда-выражениях.
Среда построена вокруг структурированного представления и редактирования кода с выделением различных элементов шрифтом и цветом. Редактор позволяет вводить код только в предназначенные для этого слоты, контролирует после ввода тип, предполагаются умные автодополнения. Ошибки типизации получаются хорошо локализованы (не могу не заметить что оригинальный хаскель тут от C++ ушёл совсем не далеко, точность ошибки компенсируется неопределённостью её местоположения).
Редактор автоматически применяет визуальную свёртку сложных языковых конструкций (вроде лямбд и аннотаций параметров как на картинке). Среди целей проекта предоставление билиотекам возможности настраивать отображение для своих структур данных и функций.
Также предполагается поддержка "regression debugging", то есть автоматический контроль хода выполнения теста и поиск изменения которое сломало тест. Примерно можно сказать что IDE будет запоминать все промежуточные результаты вычисления функций и сравнивать их для каждой версии. Хотя в контексте ленивости языка всё явно будет хитрее.
Помимо попыток привнести глобальные улучшения в IDE есть несколько инструментов реализующие какие-то конкретные компоненты гораздо лучше, чем принято в мэйнстриме.
Вот например Projucer, инструмент визуальный разработки для Juce. Ничего сверхъестественного, просто быстрая связь кода и картинки, но всё-таки поживее многочисленных SWING-дизайнеров, а пишется одним человеком.
Ещё один проект, коммерческий, Chronon. Включает в себя "Time Traveling Debugger". Это забавный инструмент который работает с полной записью исполнения программы. Записи получаются с помощью чёрной магии и второго компонента Chronon'а - "Recording Server". Нам же тут интересен дебаггер.
Его центральной фичей является возможность идти не только вперёд но и назад. Найдя ошибку можно вместо того чтобы расставлять бряки в подозрительных местах и перезапускать программу просто пойти назад и посмотреть "откуда пошло". Есть множество приятностей, вроде подсветки активных путей исполнения, истории состояний для переменных и вызовов методов. Много различных фильтров для поиска нужных значений в истории. Для примера можно посмотреть вот это видео.
Последний пример с совсем неожиданного направления, из мира железячных корпораций и кровавого геймдева. PhysX debugger - инструмент для физического движка от nVidia. Он создан для отладки поведения физической модели в сложных сценах. И демонстрирует очень высокий уровень использования различных визуализаций. Если вам интересно визуальное программирование я рекомендую потратить 15 мин и посмотреть обзорный ролик целиком: PVD tutorial video.
В этом инструменте есть множество примеров визуализации разных аспектов динамических сцен и процесса их вычисления, вот интересный кусочек для ленивых (смотреть минуты три). Есть функции бэктрекинга, когда есть бажный объект, есть момент времени когда с ним что-то не так и надо найти откуда проблема появилась. Предусмотрены инструменты для командной работы, можно аннотировать дебаг-сессию оставляя каменты к объектам в определённые моменты времени. Сессия экспортируется и может быть передана коллеге для дальнейшего разбора проблемы. Действительно развитый инструмент для решения весьма нетривиальных задач.
Напоследок уже в который раз не могу не дать ссылку на сайт Bret Victor'а, которого авторы большинства описанных выше проектов называют в числе основных источников идей: worrydream.com. Если Вы ещё не изучили все его материалы стоит немедленно начать.
вторник, 8 апреля 2014 г.
Альтернативная среда для Racket
Это последний отчёт о моих опытах с Racket и посвящён он сугубо техническому вопросу, а именно среде разработки. По умолчанию новоиспечённому Racket-разработчику предлагается минимальная среда разработки. Она умеет открывать файлы с исходниками, подсвечивать синтаксис, загружать их в простой (ну очень простой) REPL и запускать под отладкой.
В принципе это не так и мало, но хотелось большего. А именно:
Однако не сразу всё идеально заработало. Файлы с константами было невозможно перезагружать ,rr - Racket выдавал ошибку переопределения имён. Небольшое исследование вопроса показало что это связано с включенными по умолчанию оптимизациями и легко может быть исправлено одной командой, алиас принял вид "xracket="racket -il xrepl --eval '(compile-enforce-module-constants #f)'"".
Остальные 3 функции поставляет Sublime оставалось только подружить его немного с ЛИСПом, благо я не первый кто этим озадачился. Установка пары плагинов налаживает между крепкую дружбу между Racket и Sublime. Для упрощения жизни я использовал Package Control.
Первый и самый насущный - конечно отступы :) lispindent - отлично справляется с этой задачей и даже не пугается квадратных скобок.
Второй - подсветка синтаксиса. В принципе она уже была, однако некоторые конструкции понимала не корректно. В частности совершенно убивали подсветку литералы #something а также функции и структуры не появлялись в списке символов. За пару дней поправил всё это и даже заслал патч в основную ветку проекта.
Ну и последняя доводка из области эстетства - красивая подсветка скобок и быстрый переход между ними. Делается плагином Bracket Highlighter. Очень удобно показывает границы блока слева, рядом с номерами строк а также позволяет включить "усиленную подсветку" - дополнительно подсветить весь текст принадлежащий выделенному блоку. Плюшки вроде удалить блок или перейти во внешний также присутствуют.
Для того чтобы всё это дружило потребовалось буквально пара настроек.
Во-первых надо включить lispindent для соответствующего языка следующей настройкой в lispindent.sublime-settings (если используется Package Control то его можно открыть через меню Preferences->Package settings).
В принципе это всё. Я первый раз что-то глубоко копал в настройку Sublime и результат мне очень понравился. Всё, вплоть до написания своего плагина, решается достаточно легко и работает вполне безглючно.
В принципе это не так и мало, но хотелось большего. А именно:
- Полноценного REPL который бы помнил историю команд и умел подгружать изменения без полного перезапуска.
- Быстрой навигации по именам функций и структур.
- Богатого функционалом текстового редактора, в частности мультивыделения и быстрого поиска.
- Поддержки проектов, по крайней мере коллекций файлов по которым можно искать.
Однако не сразу всё идеально заработало. Файлы с константами было невозможно перезагружать ,rr - Racket выдавал ошибку переопределения имён. Небольшое исследование вопроса показало что это связано с включенными по умолчанию оптимизациями и легко может быть исправлено одной командой, алиас принял вид "xracket="racket -il xrepl --eval '(compile-enforce-module-constants #f)'"".
Остальные 3 функции поставляет Sublime оставалось только подружить его немного с ЛИСПом, благо я не первый кто этим озадачился. Установка пары плагинов налаживает между крепкую дружбу между Racket и Sublime. Для упрощения жизни я использовал Package Control.
Первый и самый насущный - конечно отступы :) lispindent - отлично справляется с этой задачей и даже не пугается квадратных скобок.
Второй - подсветка синтаксиса. В принципе она уже была, однако некоторые конструкции понимала не корректно. В частности совершенно убивали подсветку литералы #something а также функции и структуры не появлялись в списке символов. За пару дней поправил всё это и даже заслал патч в основную ветку проекта.
Ну и последняя доводка из области эстетства - красивая подсветка скобок и быстрый переход между ними. Делается плагином Bracket Highlighter. Очень удобно показывает границы блока слева, рядом с номерами строк а также позволяет включить "усиленную подсветку" - дополнительно подсветить весь текст принадлежащий выделенному блоку. Плюшки вроде удалить блок или перейти во внешний также присутствуют.
Для того чтобы всё это дружило потребовалось буквально пара настроек.
Во-первых надо включить lispindent для соответствующего языка следующей настройкой в lispindent.sublime-settings (если используется Package Control то его можно открыть через меню Preferences->Package settings).
{
"languages": {
"racket": {
"syntax": "Racket.tmLanguage"
}
}
}
В настройках Bracket Highlighter, которые bh_core.sublime-settings (также легко открываются через меню Preferences->Package settings) надо только найти и настроить под себя параметр high_visibility_style, мне понравился underline. Также удобно повесить переключение этого режима на хоткей, для этого в Default.sublime-keymap надо дописать{
"keys": ["ctrl+\\"],
"command": "bh_toggle_high_visibility"
}
Ну и проверить что файлы .rkt открываются как Racket по умолчанию.В принципе это всё. Я первый раз что-то глубоко копал в настройку Sublime и результат мне очень понравился. Всё, вплоть до написания своего плагина, решается достаточно легко и работает вполне безглючно.
Подписаться на:
Сообщения (Atom)