При создании компилятора для собственного языка программирования я сделал его как транспайлер в исходный код на С++, вот только реализация сильно подкачала. Сначала приходится генерировать динамическую библиотеку с помощью вызова gcc, который и сам по себе не очень быстрый, так еще его может и не быть на целевой машине, особенно на другой платформе (например Windows). Конечно, для первых экспериментов и такой реализации было достаточно, но сейчас, когда я начал готовить код компилятора к публикации, стало понятно, что текущий вариант с фоновым запуском gcc никуда не годится.

Из-за этого, я решил не откладывать перевод компилятора на использование LLVM, который планировался когда нибудь в будущем, а решил сделать это уже сейчас. И для этого нужно было научиться запускать компиляцию C++ кода с помощью библиотек Clang, но тут вылезло сразу несколько проблем.

Оказывается, интерфейс Clang меняется от версии к версии и все найденные мной примеры были старыми и не запускались в актуальной версии (Сlang 12), а стабильный C-style интерфейс предназначен для парсинга и анализа исходников и с помощью которого сгенерировать исполняемые файлы не получится*.

Дополнительная проблемой оказалось, что Clang не может анализировать файл из памяти, даже если для этого есть соответствующие классы. Из объяснений выходило, что в экземпляре компилятора проверяется, является ли ввод файлом**.

А теперь публикую результат своих изысканий в виде рабочего примера динамической компиляции С++ кода с последующей его загрузкой и выполнением скомпилированных функций. Исходники адаптированны под актуальную версию Clang 12. Пояснения к коду я перевел и дополнил перед публикацией, а ссылки на исходные материалы приведены в конце статьи.

• *) Кажется в 14 версии планируется реализовать C интерфейс для генерации исполняемых файлов.
• **) На самом деле, Clang может (или теперь может) компилировать файлы из оперативной памяти, поэтому в исходники я добавил и эту возможность.

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

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

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

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

Данная статья — размышление о совместимости декларативной и императивной парадигм программирования и возможности их одновременного использования в рамках одного языка программирования одновременно.

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

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

Моя история примечательна тем, что я первый раз столкнулся с хорошо продуманной атакой с применением приемов социальной инженерии, которая была организована одновременно по нескольким каналам!

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

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

Итератор (от англ. iterator ― перечислитель) — интерфейс, предоставляющий доступ к элементам коллекции (массива или контейнера) и навигацию по ним. В различных системах итераторы могут иметь разные общепринятые названия. В терминах систем управления базами данных итераторы называются курсорами.

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

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

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

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

Особенности языка:

• Низкий порог входа и естественное ограничение уровня сложности в течение длительного времени даже при условии постоянного развития самого языка.
• Возможность писать код программы как в декларативной, так и в императивной парадигме с использованием процедурного, модульного и объектно-ориентированного подхода.

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

Когда-то на Хабре была статья Борьба с пиратством и контрафактом в сети без помощи судов, в которой перечислялись разные способы защиты правообладателей от нарушителей авторских прав в Интернете.

И хотя сам материал содержит вроде бы обоснованные способы борьбы с контрафактом, но по факту, наше текущее законодательство дает возможность владельцам авторских прав использовать данные инструменты со значительными злоупотреблениями. И как в подтверждение этого, совсем недавняя статья Роскомнадзор заблокировал портал и форум 4PDA.

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

Наверное уже многим надоело, что все кому не лень, пишут про очередной кризис в производстве микросхем, повышение отпускных цен на радиодетали и микроэлектронику или невозможность их приобрести вследствие нарушившихся цепочек поставок из-за пандемии COVID-19, майнинговой лихорадки или продолжающейся торговой войны США и Китая.

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

И вот теперь эту напасть я увидел воочию и сполна прочувстовал на себе. И если сказать, что был удивлен и шокирован, то это не сказать вообще ничего. Я просто не поверил своим глазам, когда увидел стоимость копеечного микроконтроллера STM32F105 из новой поставки.

Ровно два года назад, в апреле 2019 года, произошло знаменательное событие для всех сторонников свободного и открытого ПО, которые следят за Российскими новостями. АО «МЦСТ» "опубликовало" ОС Эльбрус для свободного скачивания. И несмотря на некоторые сложности в самом начале из-за возникшего ажиотажа, этот дистрибутив остается в свободном доступе по сей день и даже продолжает периодически обновляться.

На текущий момент доступны для скачивания версии «Эльбрус Линукс» 6.0.0 на базе ядра Linux 5.4 и версии 5.0-rc3 и 4.0.4 на базе ядра Linux 4.9.



Я специально написал слово «опубликован» в кавычках, т.к. на тот момент исходные тексты дистрибутива Эльбрус Линукс в свободном доступе отсутствовали. Два года назад в разговоре с CNews директор по маркетингу МЦСТ Константин Трушкин сообщил, что

… исходные коды на продукты компании пока недоступны ни для самостоятельного скачивания, ни по запросу, но в скором времени компания намерена их открыть.

Разные пакеты ПО выпускались МЦСТ под различными открытыми лицензиями, и под ними же будет происходить распространение исходных кодов.

Раскрывая исходные коды, компания преследует маркетинговые цели, связанные с продвижением продуктов МЦСТ, а также стремится расширить комьюнити разработчиков ПО под ОС «Эльбрус».

Дочь занимается изготовлением украшений из полимерной глины и как-то пришла ко мне с просьбой. Хочу, говорит, снимать рекламные ролики своих изделий на видео, и публиковать их в Инстаграме.

После уточнения всех её хотелок и нескольких экспериментов были сформированы примерные требования к проекту «видеосъемка для интернета»:

1. Съемка видео должна выполняться с использованием штатива (в противном случае на видео заметны движения оператора)
2. Требуется поворотный стол для экспозиции небольших предметов (так как камера располагается на штативе, а необходимо показать изделия со всех сторон).
3. Съемка должна вестись на камеру мобильного телефона, т.к. одно из мест для публикации, это Instagram, в котором опубликовать видео можно только с мобильника

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

Внимание, дальше картинки и видео!

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

Но понятие «сложность» сродни термину «куча». Для кого-то и пять кокосов это не куча, а кого-то съел один и «больше не хочется» — значит для него и единственного кокоса будет много.

Так и со сложностью ПО. Вроде бы увеличение сложности является для всех очевидным и наблюдается во всех сферах применения IT технологий, да и сами языки программирования по мере своего развития становятся все сложнее, а вот оценивать «сложность» с помощью численных метрик — дело заведомо неблагодарное, но и «нельзя управлять тем, что невозможно измерить ...».

Обычно разговоры о «сложности» включают в себя только оценочные суждения без какой либо численной оценки. А так как лично меня интересует вопрос сложности языков программирования, то я решил посчитать сложность реализации компилятора gcc в каких нибудь условных попугаях. Вдруг можно будет увидеть какие нибудь закономерности?

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

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

Об этой проблеме меня заставила задуматься первоапрельская статья «Доказательное программирование»

Понятно, что дата публикации статьи говорит сама за себя. Тем не менее, новые стандарты С++, постоянно выходящие спецификации Java или новый синтаксис у PHP 8, невольно заставляют задуматься, а в нужную ли сторону идет развитие языков программирования? Ведь большинство нововведений добавляют сложность в основной рабочий инструмент и решая одни проблемы, неявно добавляя множество других.

А что должно быть в конце прогресса у развития такой дисциплины как программирование? Или хотя бы у одного конкретного языка? Ради достижения какой конечной «идеальной» цели разрабатываются новые стандарты языков программирования?

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

Например, при работе в STM32 CubeIDE, вся настройка параметров работы периферии сводится к вводу правильной частоты кварца и условного «кликанья мышкой», вместо того, чтобы программировать параметры работы железа вручную.

В продолжение серии статей про различные полезности для STM32 (1, 2 и 3), хочу рассказать, как в некоторых случаях, такое упрощение работы может стать источником совершенно не очевидных ошибок.

Почему «очередной»? Потому что первую мою статью о найденном способе обхода правил Хабра, прилетевшее НЛО принудительно скрыло в черновики, где она остается и по сей день.

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

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

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

При разработке программного обеспечения любого класса и назначения, зачастую приходится заниматься поиском ошибок, которые привели к краху всего приложения. И если в случае обычного компьютера, анализ логов и core dump`ов как правило не вызывает сложностей, то для устройств на основе микроконтроллеров бывает сложно получить «посмертную» информацию, необходимую для изучения проблемы.

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

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

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

Успел прочитал переводную статью «5 фактов о том, как Microsoft приватизировала открытый исходный код, убивая JavaScript в процессе». «Успел прочитать», потому что статью сразу безбожно заминусовали (через 30 минут уже было -12), а сейчас статья вообще скрыта в черновиках.

Её основная мысль была «Миссия Microsoft – так или иначе превратить каждого JavaScript-разработчика в дрон Microsoft TypeScript, приносящий деньги» за счет того, что «Microsoft внедрила использование TypeScript в React, Angular и Node, одновременно приватизировав Github и npm».

По мнению автора, именно для этого Microsoft купила Github, пакетный менеджер Npm (который является менеджером пакетов для NodeJS), а так же всячески продвигает свой VSCode как единственный редактор кода для TypeScript. И хотя все приведенные факты в статье имею место быть, но сам стиль подачи материала выглядит классической страшилкой из области теории заговоров, причем написанной человеком, который всей душой искренне любит JavaScript и ненавидит Microsoft.

Наверно я так и прошел бы мимо, если бы сам немого не кодил на JavaScript, и не по наслышке знаю ту боль, которую может причинить разработчику отладка на не типизированном языке. А ведь это одна из многих проблем, которую по задумке и предназначен решать TypeScript. Если бы не одно но…

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

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

Продолжая серию статей про маленькие хитрости разработки под STM32, хочу поделиться двумя очень простыми, но полезными функциями. Они никак не тянут на полноценный проект на github.com, но способны облегчить жизнь (или наоборот, выпить немало крови), при определенном стечении обстоятельств.

1. Буферизированный вывод отладочной информации в последовательный порт
2. Автоматическое включение защиты от чтения и модификации прошивки

При разработке одного девайса на базе STM32F407 столкнулся с проблемой нехватки оперативной памяти. Назначение самого девайса не принципиально, но важно, что изначальный код писался для десктопной системы и его нужно было просто портировать на микроконтроллер под управлением FreeRTOS. А так как исходный код был написан на С++ и вопрос об экономии ОЗУ даже не стоял, то и вылезла соответствующая проблема.

Заниматься оптимизацией кода, одновременно добавляя себе проблем с поиском новых ошибок, очень не хотелось. Поэтому своевременно вспомнилось, что данная версия микроконтроллера имеет на борту дополнительный сегмент ОЗУ размером 64К (CCM SRAM), который сейчас никак не был задействован. Эврика — вот оно, решение!

Но к сожалению, все оказалось не так просто.

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

И если «хотели как лучше, а получилось как всегда» случается из-за неучтенных или изменившихся требований, то это хотя бы можно объяснить. Но порой и на старуху бывает проруха и становится досадно пропустить детскую ошибку просто из-за замылившихся глаз или из-за подводных камней реального использования модной технологии.

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

А что делать, если разработчиков в компании раз-два и обчелся, либо их опыта недостаточно для экспертной оценки предлагаемого решения? Или у них просто отсутствует время или желание вникать в чужие трудности?

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

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

И пользователи, как программисты, так и не программисты, просто хотят решать возникающие перед ними задачи. И хотя задачи бывают совершенно разные, но если способ (алгоритм) её решения известен, то выбрать язык для её решения не составит никакого труда.

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

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

Так почему этого так и не случилось? В чем проблема Пролога, да и любой системы / языка программирования, назначение которых анализировать факты и искать ответы на вопросы?

Эта проблема называется «Комбинаторный взрыв» — экспоненциальная (или более) зависимость времени работы алгоритма от количества входных данных. И есть как минимум два решения этой проблемы.

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

Если вкратце, то мне была нужна миниатюрная библиотека для микроконтроллеров с сериализатором двоичных данных и последующей передачей этих сообщений по низко скоростным линиям связи, тогда как обычные форматы xml, json, bson, yaml, protobuf, Thrift, ASN.1 и др. мне по разным причинам не подходили.

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

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

После этого я прикрутил к библиотеке CBOR свой интерфейс (чтобы не перелопачивать исходники), и … решил от этого формата отказаться в пользу MessagePack :-)