Clojure *

В статье про тестируемость я косвенно упоминал подход "разработка через тестирование" (TDD); сейчас же хочу поделиться переводом статьи от гуру TDD, Роберта Мартина. Он обсуждает с Марком Симаном, нужно ли при динамической типизации больше тестов. Симан утверждает, что статическая типизация исключает многие недопустимые состояния, и поэтому часть тестов становится просто ненужной. Мартин же доказывает, что тесты необходимы для проверки поведения независимо от языка. При использовании методологии TDD типизация не обеспечивает дополнительной надёжности.

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

Недавно мне попался следующий твит от OneHappyFellow:

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

— One Happy Fellow (@onehappyfellow) 5 мая 2025

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

Привет, Хабр!

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

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

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

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

Это перевод небольшой книги о языке Janet за авторством Иана Генри (Ian Henry). В этой небольшой книге подробно раскрываются различные аспекты работы с языком, обьяснение синтаксиса и некоторых приемов программирования.

Внимание, в этой публикации содержатся скобочки! Люди с непереносимостью Лисп-подобных языков, вас предупредили.

$ echo "hector the frantic father on an anchor or a rare fat cat sat on the ranch" > test-huff.txt
$ xxd test-huff.txt
00000000: 6865 6374 6f72 2074 6865 2066 7261 6e74  hector the frant
00000010: 6963 2066 6174 6865 7220 6f6e 2061 6e20  ic father on an
00000020: 616e 6368 6f72 206f 7220 6120 7261 7265  anchor or a rare
00000030: 2066 6174 2063 6174 2073 6174 206f 6e20   fat cat sat on
00000040: 7468 6520 7261 6e63 680a                 the ranch.

a, c, e, f, h, i, n, o, r, s, t; пробел (0x20) и перевод каретки (0x0a).

$ 7z a -mx9 test-huff.txt.gz .\test-huff.txt
$ xxd test-huff.txt.gz
00000000: 1f8b 0808 d76f 6565 0200 7465 7374 2d68  .....oee..test-h
00000010: 7566 662e 7478 7400 158b 410a 0031 0c02  uff.txt...A..1..
00000020: effb 0abf 2621 257b 69c1 e6ff d480 1e64  ....&!%{i......d
00000030: c6ca e823 7425 96b8 fb0f 2c7a 0967 8393  ...#t%....,z.g..
00000040: 2873 8710 9543 11ee 75ad cc51 237d 0fc7  (s...C..u..Q#}..
00000050: 9797 d64a 0000 00                        ...J...

0101 1001 0001 1101 00111 010 000 1101 0101 1001 000
h    e    c    t    o     r   ' '   t    h  e    ' ' 

$ echo "aaaaaaaa" > test.out
$ xxd test.out
00000000: 6161 6161 6161 6161 0a     aaaaaaaa.

$ gzip -1 test.out
$ xxd test.out.gz
00000000: 1f8b 0808 bf35 6a61 0403 7465 7374 2e6f  .....5ja..test.o
00000010: 7574 004b 4c84 002e 00b6 66d7 ad09 0000  ut.KL.....f.....
00000020: 00

Дисклеймер: эту статью я писал в целях обучения, так что мог допустить некоторые ошибки. Мне нравится заниматься низкоуровневым программированием, но моя основная деятельность сосредоточена на веб-разработке для Microsoft Teams.

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

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

Это первая глава перевода небольшой книги о языке Janet за авторством Иана Генри (Ian Henry). В этой книге раскрываются различные аспекты работы с языком, обьяснение синтаксиса и некоторых приемов программирования.

Внимание, в этой публикации содержатся скобочки! Люди с непереносимостью Лисп-подобных языков, вас предупредили.

История одной оптимизации во время мастер-класса Clojure Minecraft

В июне компания JUXT приняла участие в ClojureD, ежегодной замечательной конференции по Clojure в Берлине. В течение дня проводился ряд семинаров, на которых рассказывалось о конкретной идее или инструменте и предлагалось поработать с ними. Наша группа решила посетить семинар "Изменим мир (Minecraft) с помощью кода", который проводили Арне Брассер (Arne Brasseur), Ариэль Алекси (Ariel Alexi) и Фелипе Баррос (Felipe Barros). В этом посте рассказывается о том, как мы использовали полученные на семинаре знания для создания изображений в игре и оптимизировали код с помощью Tufte.

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

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

Роберт К. Мартин (Robert C. Martin) (дядя Боб) назвал пять основных принципов проектирования программного обеспечения SOLID. Такой акроним помогает людям легче запомнить их. Мне очень нравятся подобные мнемоники, потому что всем нам нужна помощь для фиксации в памяти необходимой информации. Чем проще закрепить знания, тем большему мы способны научиться.

Благодаря большому опыту проектирования программного обеспечения, эти принципы были разработаны для того, чтобы помочь создать ПО, которое можно поддерживать в работоспособном состоянии на протяжении длительного времени. Это благо для мира ОО (object-oriented — объектно-ориентированный), что об этих и подобных принципах так много говорят. Они были идентифицированы, переработаны, названы и кодифицированы. И теперь можно открыто говорить о них, при этом люди понимают, что вы имеете в виду. Такого рода вещей, как ни странно, совершенно не хватает в мире функционального программирования.

Краткий экскурс в синтаксис Clojure, который настолько лаконичен, что вы сможете прочитать этот раздел примерно за 15 минут.

”Если вам нравятся Руби, Свифт, Дарт, Эликсир, Эльм, С++, Питон или даже С, используйте их ради бога. Но выучите Кложур, и выучите его хорошо” — Дядя Боб (твит, а также твиты: 1, 2, 3).

Статей о Clojure написано много, цель этой — дать свое видение некоторых преимуществ языка для кросплатформенной разработки на Flutter. Ориентируюсь в первую очередь на dart-разработчиков, но статья может быть интересна всем, кто работает с Clojure и/или Flutter.

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

На текущий момент инструменты еще не отшлифованы, нет репла(!) и автодополнений для dart-интеропа, но пользоваться можно, и некоторые плюшки кложуры уже показали себя (например, nest-макрос, убирающий проблему вложенности).

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

Этот пост служит для того, чтобы освежить в памяти, а некоторых познакомить с базовыми возможностями функционального программирования на языке Python. Материал поста разбит на 5 частей:

Главная задача этого поста – показать один мало применяемый на языке Python архитектурный шаблон под названием «функциональное ядро - императивная оболочка», в котором функциональный код концентрируется внутри, а императивный код выносится наружу в попытке свести на нет недостатки каждого из них. Известно, что функциональные языки слабы при взаимодействии с «реальным миром», в частности с вводом данных пользователем, взаимодействием с графическим интерфейсом или другими операциями ввода-вывода. В рамках такого подхода весь императивный код выталкивается наружу, и внутри остается только функционально-ориентированный.