Думая, как мы думаем

предыдущая серия Steve Yegge ссылается на книгу «Гёдель, Эшер, Бах» Дугласа Хофштадтера, и я тут с ним солидарен: хороший программист не может считаться таковым, если он не читал эту книгу! Хофштадтер всю свою жизнь потратил,[…]

Читать дальше …

Универсальный паттерн проектирования

Есть такой довольно забавный блогер Steve Yegge, работавший в Google и Amazon. Авторству его принадлежит, в частности, эпический пост «Исполнение королевский постановлений в царстве существительных», посвященный троллингу Java. Но и квалификация Стива не вызывает сомнений,[…]

Читать дальше …

Технократический парадокс

Есть такая забавная притча: Боб и Алиса в далёкой первобытной древности добывают в поте лица огонь, вращая деревянные палочки. Внезапно около них открывается портал, из него выходит Странник и говорит: — Я пришёл к вам[…]

Читать дальше …

TDD «снизу вверх» (2)

первая часть Проектирование сверху-вниз, от абстракций-типов, имеет и ещё один огромный, с точки зрения мэйнстрима, недостаток — слабая поддержка рефакторинга. Такие простейшие и популярные приёмы, как изменение порядка аргументов функции (который можно полноценно отнести к[…]

Читать дальше …

TDD «снизу вверх»

Подход Type Driven Development подразумевает первоначальное проектирование системы типов, которая на уровне ошибок компиляции контролирует целостность и непротиворечивость всего проекта. Практически повсеместно такой приём, в частности, принят в функциональном программировании. Однако всегда ли такой схема[…]

Читать дальше …

Почему не Haskell (2)

первая часть Итак, почему же Haskell, несмотря на свою математическую мощь, так и не стал мэйнстримом? Потому что его «состыкуемость» ломается на п.4 (когда мы выходим за пределы haskell-программы). Потому что крупные и сложные программные[…]

Читать дальше …

Почему не Haskell

История программирования — это по сути история борьбы со сложностью. Сложность развиваемой программы довольно быстро выходит за биологические возможности человеческого интеллекта, и мы перестаём понимать её и теряем контроль над кодом. Если бы Linux разрабатывалась[…]

Читать дальше …

TDD & TDD

Type Driven Development — это такая моднейшая концепция, в которой проектирование системы ведётся в зависимых типах. Соответственно, в идеале, дабы обеспечить общую целостность проекта, по-хорошему нужно поддерживать консистентность системы типов, для чего применяются пруф-чекеры наподобие[…]

Читать дальше …

Операционные системы совершенно не нужны

Следуя заветам Алана Кея «учиться у Великих прошлого», насладимся мнением одного из величайших гуру современности — Чарльза Мура, создателя уникального конкатенативного языка Forth и проектировщика 144-ядерных чипов со сверхмалым потреблением энергии: …Мы не пишем программы[…]

Читать дальше …

Выход из мета-тупика

Подведём промежуточные итоги последних месяцев. С одной стороны, ясны технологии и языки/парадигмы программирования, которые позволяют быстро создавать DSL и встраивать их в прикладные проекты, и для этого никаких специфических/дополнительных знаний программисту в принципе не требуется.[…]

Читать дальше …

Зависимости пакетов как NP-полная задача

Формально проблема зависимости пакетов (Dependency hell) описывается так: 1. Пакет может иметь ноль или более пакетов или специфических версий пакетов как зависимости. 2. Для успешной установки пакета должны быть успешно установлены все его зависимости. 3.[…]

Читать дальше …

Ремонт программирования

Программирование — это не только увлекательное решение головоломок, но и существенная часть современной культуры. Программирование (в более общем случае, развитые навыки рационального мышления) — это во многом то, что делает нас человеками. И с одной[…]

Читать дальше …

Терминальный cd-киллер

Программирование — процесс текстоориентированный, и хорошие программисты обычно любят тексты во всех их видах (и читать, и писать). По этой причине хардкорные олдскульщики всегда критиковали подход RAD/IDE как «рисование мышкой», которое может и подходит для[…]

Читать дальше …

Годовой цикл самосовершенствования программиста

Рекомендации от Matt Might, профессора математики университета Юты и стратегического консультанта Исполнительного аппарата президента США. Профессор рекомендует в течение одного месяца в году, последовательно практиковать следующие самосовершенствования, своеобразные личные вызовы: 1. Заняться чем-то аналоговым —[…]

Читать дальше …

Тысячекратная компактность кода 2017

Я заинтересовался темой метапрограммирования лет 10 назад, когда написал в PC Week/RE несколько статей с заголовком, вынесенным в сабж. Через несколько лет эта тема была продолжена на Хабре, и вот сейчас воплотилась в данный ресурс.[…]

Читать дальше …

Конкатенативное цитирование

предыдущая серия Однако у Лиспа имеется огромный (относительно конечно) недостаток: это аппликативный язык, и одна лишь его многоскобочность стала притчей во языцех. Нас же интересует гомоиконичность применительно к конкатенативным языкам — и в первую очередь[…]

Читать дальше …

Гомоиконичность против статической типизации

предыдущая серия У динамических языков программирования имеется одно важное свойство, из-за которого они получили массовое распространение в областях, где по хорошему надо бы применять языки со статической типизацией. Это свойство — простота реализации как самого[…]

Читать дальше …

Абсолютная функциональная чистота

предыдущая серия Продолжим рассуждения об конкатенативных языках. Своеобразным микрохоливаром стал тред Role of combinators in concatenative/tacit programming languages на StackOverflow, где весьма заслуженные участники высказывались даже в духе, что никакого полноценного определения конкатенативного языка не[…]

Читать дальше …

Сказка о конкатенативной силе

В мэйнстриме принято делить все языки, более-менее активно эксплуатируемые в реальных проектах, на императивные и функциональные. Такое деление, безусловно, очень условное, но позволяет в первом приближении получить понимание, что примерно из себя представляет некий язык.[…]

Читать дальше …

Есть только типы

предыдущая серия Монады, как известно — это и аппликативные функторы (функции, упакованные в контексты/контейнеры), а все аппликативные функторы — это конечно и просто функторы (условно говоря, функции, к которым можно применять fmap). Начнём с конца.[…]

Читать дальше …