Ода предметно-ориентированным языкам

Хороший DSL (Domain Specific Language, предметно-ориентированный язык) бывает на вес золота и помогает элегантно решать довольно сложные проблемы. Часто такие мини-языки применяют там, где требуется много работать с бизнес-логикой и необходимо привлекать эксперта из предметной области, причем этот эксперт может плохо владеть программированием. Здесь подобные языки хорошо себя зарекомендовали, и причины для их применения абсолютно ясны.

Но DSL-и способны помочь и с совершенно иной точки зрения.

Продолжение 👉 ЗДЕСЬ

#digest

Технологии или польза?

Одна из статей Джеймса Хага (James Hague) поднимает важнyю тему в мире программирования. Многие из нас занимаются своей профессией именно потому, что любят технологии. Какой кайф пощупать что-нибудь новенькое, а главное использовать в своей работе (или, на худой конец, в хоббийном проекте)! Оттого на форумах и в профильных сообществах часто звучит вопрос: «Мне нравится язык X, что бы мне такое на нем написать?» Или: «Мне нравится ОС Y, какой бы проект мне сделать на ее основе?»

Хаг подчеркивает, что этот вопрос порочен и ставит инструмент на более важную позицию, чем цель, ради которой этот инструмент создавали. Автор обращает внимание на простой факт: важно не то, что мы используем, а что мы делаем, какую проблему решаем.

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

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

А что вы думаете на этот счет?

#literature

Синтез гитарного звука миниатюрной программой на C

Цифровая обработка сигналов (DSP, Digital Signal Processing) — область знания немного магическая, поскольку достаточно простые алгоритмы порой выдают очень интересные результаты. Как и в этом случае: в небольшом GitHub gist приведен пример банальнейшего кода на C (обернут shell-скриптом), вывод которого проигрывается аудиокартой.

Звучит почти как гитара!

(Если вдруг вы не хотите запускать скрипт, послушайте mp3 примеры, идущие в комплекте.)

#fun

Токсичные персонажи в open source сообществах

Сегодня мы не можем представить свою жизнь без open source. Даже те, кто не участвуют в открытых проектах сами, наверняка используют софт, который полностью или частично создан open source сообществом. Идея, что код или какой-либо цифровой контент может создаваться полностью открыто, сообща, с передачей прав на воспроизведение, копирование, создание производных работ, захватывает ум и заставляет мурашки бежать по спине, не правда ли?

К сожалению, любые сообщества состоят из людей, а люди преследуют разные интересы. И в мире open source сообществ есть свои тролли, персонажи, практикующие буллинг, оскорбления других членов сообщества и авторов открытых проектов. Есть и люди, считающие, что авторы проектов им что-то должны. Они не оставляют запросы в issue tracker, не предлагают своих изменений через pull request, а просто требуют в грубой манере, чтобы автор добавил то или иное изменение. И если человек отказывается — поднимают настоящую шумиху с публичной травлей.

Но бывает и так, что все эти неприятные персонажи собираются в команду, и ставят своей целью захватить чужой проект, а неудобного автора оставить не у дел. Так, например, обошлись с автором Non DAW, Джонатаном Муром Лилзом (Jonathan Moore Liles).

Джонатан своими силами долгие годы разрабатывал комплект программ для профессиональной звукозаписи. Non DAW создавался модульным, быстрым, не жадным к ресурсам. Эту музыкальную студию можно запустить даже на дешевом EeePC или самых старых моделях RaspberryPi, где она будет сносно работать. Даже графический тулкит для своего детища Джонатан сделал сам, переработав FLTK.

Все началось с того, что трое персонажей потребовали от автора доработок в менеджере сессий NSM. Именно потребовали, а когда услышали отказ — начали травить Джонатана в тематических сообществах. Через время появился форк NSM, который сохранил аббревиатуру, но изменил ее расшифровку, при этом «банда» начала продвигать свой форк как «более новую версию, очищенную от рекламы и трекеров».

Через список рассылки «Linux Audio Announce» Джонатан пытался указать на некорректное поведение этих товарищей, но не прошел премодерации, потому что один из них, David Runge, оказался среди модераторов! Более того, будущие анонсы по релизам реального NSM также не были допущены до публикации, а Джонатан получил вечный бан в сообществе.

У Джонатана оставался сайт оригинального проекта, где он опубликовал свои мысли о происходящем. На этот раз ему и хостингу, где располагался сайт, пригрозили судом, потому как опубликованные материалы порочат чьи-то честь и достоинство. Джонатан убрал материал с сайта, но оставил ссылку на archive.org с сохраненной копией.

И так бывает… А приходилось ли вам сталкиваться с подобным в open source сообществах? Поделитесь!

#digest

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

Разрабы из Касперского без купюр рассказали, как это уcтроено у них для «плюсовой» разработки. Кажется, они первые, кто так открыто раскрывает весь процесс... Но если вы видели такое где-то еще, то скорее делитесь в комментариях!

#digest

Руководства по устройству IT-компаний

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

Далеко не все компании формально описывают каждый аспект своего существования. Где-то внутренняя культура передается устно, какие-то компании используют справочники для новичков, где изложены основные моменты, помогающие быстрее включиться в работу. Только единицы формулируют все принципы своего функционирования в виде законченного документа. И куда меньше компаний готовы публично предоставить такой документ для свободного изучения…

Так что переходите по ссылкам со страницы Дэвида Гаскеза (David Gasquez) и сравнивайте с организацией, где работаете сегодня!

#digest

Механизмы безопасности Unix

Мир Unix-подобных ОС сильно фрагментирован. С одной стороны, известно немало *nix-систем: это и дистрибутивы на основе ядра Linux, и macOS, и различные варианты BSD, и потомки Solaris. Каждая из этих систем реализует целую плеяду собственных механизмов безопасности, расширяющих традиционные, известные издревле, механизмы контроля доступа Unix. С другой стороны, даже в рамках одной системы механизмы безопасности не рождались единовременно, как результат целостной продуманной архитектуры безопасности, а эволюционировали, адаптировались, заполняли лакуны недостающими фрагментами.

Разобраться со всем этим многообразием очень непросто — чего стоит просто найти все необходимые для ознакомления материалы!

К счастью есть просто невероятная статья Патрика Луиса (Patrick Louis), описывающая все, что необходимо знать о механизмах безопасности в Unix-системах.

#literature

Интерпретатор Lua на Rust

Lua и Rust — хорошие языки программирования. Lua прост, ортогонален, для него существует очень быстрый интерпретатор и молниеносный just in time компилятор. За что мы его очень любим. Rust — не просто модный язык, он действительно решает проблемы, которые не решают его конкуренты: благодаря системе типов этого языка удается исключить целый пласт ошибок, связанных с управлением памятью.

Два хороших языка — в два раза больше удовольствия. Окунитесь в разработку интерпретатора для Lua на Rust с бесплатной электронной книгой.

Книга еще не окончена, в ней не хватает некоторых глав, например, про реализацию метатаблиц. Тем не менее, она уже покрывает достаточно большую часть языка. Ну и если заметите грамматические неточности в тексте, не злитесь на автора — он переводил свой труд с китайского, используя Google Translate!

#literature

Хорошее введение в Calculus of Constructions

Наверняка многие из вас слышали про языки с зависимыми типами. Кто-то смотрел примеры кода на Agda и Idris2, а кто-то, возможно, даже отложил себе в закладки замечательные книги серии Software Foundations, описывающие тонкости применения Coq (и все никак не может начать их осваивать, да :)).

Авторам канала всегда нравилось разбираться в деталях технологий: территория неизвестного и непонятного манит и требует решительных действий! Как можно пользоваться инструментом, если не понимаешь, как он устроен внутри, хотя бы приблизительно?!

Пытаясь разобраться в особенностях calculus of constructions, мы наткнулись на великолепный документ, описывающий эту теорию типов с самых азов. В тексте даются все необходимые пререквизиты и вводятся базовые обозначения, которые понадобятся для погружения в мир CoC. Этим «Typed Lambda Calculus / Calculus of Constructions» значительно отличается от других подобных работ, требующих от читателя немалого багажа и погруженности в предмет.

Если вы заняты в сфере, где safety — важный quality-атрибут, самое время обратить внимание на мир языков с зависимыми типами. С каждым годом эти инструменты будут все популярнее.

#digest

TigerStyle!

Не знаем, как у вас, но у нас на работе несколько раз рождались серьезные споры о том, какой стиль кодирования следует предпочесть для той или иной кодовой базы. Кто-то спорит до хрипоты, на какой строке оставлять фигурную скобку в коде на C/C++, кто-то обсуждает, использовать ли do-нотацию в Haskell и запиливать ли катаморфизмы, или обойтись простым и прямолинейным кодом свертки.

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

В недавнем выступлении на конференции Systems Distributed CEO компании TigerBeetle, Джоран Грииф (Joran Greef), рассказал про их собственный подход к разработке, названный TigerStyle. Посмотреть выступление можно по ссылке. В текстовом виде TigerStyle описан на GitHub.

Это не совсем Style Guide в привычном нам виде: многие разделы рассматривают довольно серьезные, порой даже философские вопросы, далекие от исключительно проблемы оформления кода.

Делитесь в комментариях вашими любимыми стилями кодирования, а также Style & Design гайдами.

P.S. Удивительно, что весь бизнес TigerBeetle строится вокруг продукта, написанного на языке Zig, который, хоть и на слуху, но довольно редко применяется в крупных проектах. Подходы, принятые в компании, подкупают некоторым пуризмом, например отказом от внешних зависимостей, которые сложно контролировать, особенно в современном мире, где популярны supply chain атаки. Впрочем, это уже совсем другая история :)

#digest

Стековые и «национальные» языки программирования: а что насчет корейского?

Райан Брейнард (Ryan Brainard) описал интересную параллель между языками с обратной польской нотацией и современным корейским языком: они строятся по схожим принципам, ведь предложения имеют структуру субъект-объект-действие.

Райан кратко рассказывает об устройстве стековых языков и далее объясняет, как ту же механику можно применять для корейского.

Наверняка многие задумывались, почему так мало распространены «национальные» языки программирования, ключевые слова в которых записываются понятными носителю словами. Что до авторов канала, то нас подобные языки отпугивали в первую очередь из-за синтаксиса: если в C, Python или Ada заменить ключевые слова на кириллические аналоги, мало что поменяется — код останется более формальной записью сильно упрощенного английского. Однако Брейнард показывает: код на «корейском» языке программирования может оказаться легко читаемым, поскольку будет почти полностью соответствовать реальным предложениям на этом языке!

Вот такое необычное наблюдение. Самсунг, где ваша смекалочка?

#digest

Невербалика и публичные выступления

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

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

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

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

Уилл Стивен (Will Stephen) провел свое выступление, не рассказав ничего полезного. Его доклад — пародия на значимые выступления известных личностей. Но это не просто стендап: через юмор Уилл доносит до зрителя принципы невербального общения со зрителем, которые помогут докладчику притягивать аудиторию.

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

А еще попробуйте выключить звук и посмотреть несколько отрывков. Кажется, что докладчик рассказывает о чем-то очень серьезном и важном, а также полностью разбирается в материале! :)

#digest

Rust to Assembly

Rust продолжает набирать популярность, в него начинают верить крупные компании, все больше проектов пишут на этом языке.

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

Rust to Assembly — серия статей про то, как разные фичи языка компилируются в машинный код. Авторы разбирают разные примеры ассемблерных листингов, полученных после компиляции той или иной конструкции языка, и описывают все нюансы ее низкоуровневой реализации.

Интересная тема, чтобы поковыряться в низах ближайшие пару-тройку вечеров :)

#literature

Реальная безопасность в Linux

Помните время, когда считалось, что Linux — очень безопасная ОС, не то что Windows? Когда казалось, что под Linux нет злонамеренного ПО – например, вирусов – и вообще это оплот безопасности?

К сожалению, это миф, когнитивное искажение, порожденное популярностью Windows. «Винда» просто была популярнее, и потому на нее были обращены взоры всех хакеров мира. Да и в сравнении с закрытой ОС, Linux выглядел более защищенным, ведь на его код смотрели тысячи глаз.

Впрочем, современные ОС далеко шагнули вперед в плане безопасности. В системы добавляли и развивали механизмы, необходимые для изоляции приложений друг от друга и от остальной системы. К примеру, команда, ответственная за безопасность в Google, продумала действительно крутые архитектурные решения для Android, Chromium и ChromeOS, используя в основе ядро Linux. А до этого известная эксперт по информационной безопасности Йоанна Рутковска (Joanna Rutkowska) запустила проект QubesOS. Идея этих архитектурных решений — изоляция приложений в песочницах, для которых можно гибко задавать разрешения на использование системных сервисов и общение с другими такими же приложениями.

Интересно, что в самом ядре и базовых системных сервисах вокруг него уже есть все необходимое, чтобы выстроить достаточно безопасное пользовательское окружение. Тем не менее, популярные дистрибутивы Linux редко используют доступные механизмы контейнеризации, чтобы ограничивать приложения друг от друга и от использования определенных системных вызовов. Все же модель угроз современных GNU/Linux систем недалеко ушла от legacy мира Unix.

Один из членов группы PrivSec опубликовал статью, где разобрал основные проблемы современных дистрибутивов на базе ядра Linux, а также предложил, как каждый из нас может сделать свою систему гораздо безопаснее. Конечно, придется поколдовать!

#digest

Простое введение в завтипы

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

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

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

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

#literature

nanochess и bootOS

Иногда люди создают программы исключительно ради искусства.

К примеру, проект nanochess не имеет никакой практической пользы, кроме удовольствия от низкоуровневого программирования. Ну и конечно, обучения. В рамках этого проекта был разработан десяток простых игр, написанных на ассемблере для Intel 8088. Каждая из них умещается в один сектор дискеты, 512 байт. А еще автор проекта, Оскар Толедо (Oscar Toledo), опубликовал несколько книг с комментариями к исходному коду игр, объяснив, как они работают.

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

#digest

Монадные трансформеры Haskell

В нашем недавнем посте мы вспоминали Haskell с присущими ему концепциями, заимствованными из теории категорий. Вспоминали и монадные трансформеры.

Статей, объясняющих, что же это такое и как этим пользоваться, много. Но найти хорошую и понятную непросто :) Возможно вам понравится одна из свежих, что мы нашли где-то на hacker news.

#literature

Использование model finding при разработке компилятора

Chapel — язык программирования, созданный для упрощения параллельных вычислений.
Компилятор этого языка, Dyno, использует нетривиальную логику для разрешения имен: например для того, чтобы понять, что требуется вызывать — метод с именем foo или одноименную функцию.

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

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

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

#digest

Введение в формальную верификацию программ

Много слышали про использование формальных методов, но не успели погрузиться в эту область? Не знаете с чего начать? Попробуйте ознакомиться с пособием Александра Сергеевича Камкина «Введение в формальные методы верификации программ». Как нам кажется, эта небольшая книга дает достаточно полное введение в столь непростую и интересную область.

С каждым годом спрос на формальные методы в разработке высоконадежного ПО будет расти. И это не только про самолеты и атомные станции: формальные методы широко применяются, например, для верификации смарт-контрактов в blockchain платформах. Дерзайте!

#literature

Избавление от зависимости

Давненько не было у нас внутренних кеков :)

#fun