Почти как Rust, только проще, или Пишем свой компилятор

Новые языки программирования появляются постоянно. Только популярных современных проектов масса: Go, Rust, Nim, Zig, Crystal, Swift, Kotlin, Pony. Кроме того, есть проекты и поменьше. Ну а любительские — так вообще появляются каждую неделю!

Конечно, не во всех новых языках программирования присутствует какая-то техническая или научная новизна, некоторые пытаются быть просто удобным инструментом, заботятся о том, чтобы программисту были доступны привычные концепции, но в более удачной упаковке (Go, Kotlin, Swift).

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

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

P.S. Ставьте палец вверх, если вам интересна эта тема! Наберем 10 лайков — посоветуем вам еще больше проектов, туториалов и книг :)

#digest

Вчера заспорили между собой о том, кто как пришел в сеньоры. Точнее, сами пути споров не вызывали – спорили главным образом о том, какой из них проще. Выделились два основных способа: линейно расти на одном проекте, или же сменить работу с повышением.

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

А как стали сеньором вы? Ждали? Уходили? Или может, как-то совсем по-иному? А если вы еще не сеньор, какой способ вам кажется проще?

👇

Пример качественной документации

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

Для нас, авторов этого канала, образцом качественной документации по проекту стала книга Genode Foundations. В действительности это постоянно обновляемая документация по внутренностям Genode Operating System Framework — конструктора операционных систем, построенного для работы над целой плеядой различных микроядер.

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

Что еще желать?!

А можете ли вы привести пример документации, которая вам нравится?

#literature

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

Хороший 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