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

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

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

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

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

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

И хотя сам материал содержит вроде бы обоснованные способы борьбы с контрафактом, но по факту, наше текущее законодательство дает возможность владельцам авторских прав использовать данные инструменты со значительными злоупотреблениями. И как в подтверждение этого, совсем недавняя статья Роскомнадзор заблокировал портал и форум 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 :-)

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

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

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

Micro Property — библиотека для сериализации данных с минимальными накладными расходами. Она разработана для использования в микроконтроллерах и различных встраиваемых устройствах с ограничениями по размеру памяти, которым приходится работать по низкоскоростным линиям связи.

Конечно, я знаю про такие форматы как xml, json, bson, yaml, protobuf, Thrift, ASN.1. Даже нашел экзотический Tree, который сам является убийцей JSON, XML, YAML и иже с ними.

Так почему же они все не подошли? Зачем я был вынужден написать еще один сериализатор?

Уже после публикации статьи в комментариях дали несколько ссылок на пропущенные мной форматы CBOR, UBJSON и MessagePack. А они с большой долей вероятности решают мою задачу без написания велосипеда.
Жаль, что я не смог найти эти спецификации ранее, поэтому добавлю этот абзац для читателей и для собственного напоминания, что не следует торопиться писать код ;-).
Обзоры форматов на Хабре: CBOR, UBJSON

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

Потом, когда пришло не только жене, но и мне — полез смотреть откуда… и неожиданно узнал что рекламу теперь может слать и mos.ru
Совсем потеряли совесть…

Давно уже реализуемая практика. Стоит зарегистрироваться на портале. или оформить обращение… Не важно на mos.ru, или прокуратуру с полицией, вам тут же начнутся звонки и сомнительные смс.)
Не хочется об этих всех службах думать плохо. Но повторные обращения и снова звонки и смс. Так что борьба с мошенничеством стоит под контролем. Мошенники сами себя не ловят.)

Точно. Сходил пару раз в МФЦ и просто шквал звонков с разной рекламой. Причем сплошняком роботы текст зачитывают.

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

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

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

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

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