Последнее время только ленивый не пишет о великом прорыве человечества в области разработки искусственного интеллекта под общим названием "большая языковая модель" (LLM, large language model). И хотя у них остается еще много возможностей для совершенствования, но за последние несколько лет подобные приложения стали действительно востребованными. Большие языковые модели привлекают своей сверхъестественной способностью резюмировать текст, понимать естественный язык и создавать контент (и судя качеству некоторых статей, в том числе и тут на Хабре).

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

Томас Валадес (Thomas Valadez) воспользовался этим творческим потенциалом, чтобы создать интересное устройство под названием «Storybook». Его проект с открытым исходным кодом превращает Raspberry Pi в рассказчика на базе искусственного интеллекта, способного создавать иллюстрированные сказки. Это устройство использует LLM и генератор изображений для создания одной страницы книги из никогда не существовавшего сборника рассказов и выводит их на E-Ink дисплей.

I always pay attention to assessing the complexity of programming in a particular language. Programming is indeed not an easy task and this is perceived as a fact and usually does not require any confirmation.

But the concept of “complexity” is akin to the term “heap”. For some, five coconuts is not so much, but for someone who ate one and “didn’t want any more,” this means that even one coconut will be too much for him.

The same goes for the complexity of programs. It seems that the constant increase in the complexity of programs is obvious to everyone and is observed in all areas of application of IT technologies, and programming languages themselves become more and more complex as they develop, but assessing “complexity” using numerical metrics is a problem. obviously a thankless task, but also “You can’t manage what you can’t measure...”

Typically, talk of “complexity” only implies value judgments without any numerical evaluation. And since I am personally interested in the issue of the complexity of programming languages, I decided to calculate the complexity of implementing the gcc compiler on some conditional “parrots”. What if we could see some patterns of difficulty changing over time?

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

А Bodyfuck — это жестовый интерпретатор Brainfuck, который позволяет писать код программы, используя различные движения тела без использования клавиатуры.

Смотрите, не перепутайте! :-)

Practically all programming languages are built either on the principle of similarity (to make like this one, only with its own blackjack) or to realize some new concept (modularity, purity of functional calculations, etc.). Or both at the same time.

But in any case, the creator of a new programming language doesn't take his ideas randomly out of thin air. They are still based on his previous experience, obsession with the new concept and other initial settings and constraints.

Is there a minimal set of lexemes, operators, or syntactic constructs that can be used to construct an arbitrary grammar for a modern general-purpose programming language?

Every programmer is familiar with the concept of "reference." This term usually refers to a small object whose main task is to provide access to another object physically located elsewhere. Because of this, references are convenient to use, they are easily copied, and they make it very easy to access the object to which the reference points, allowing access to the same data from different parts of the program.

Unfortunately, manual memory management, or more precisely, manual memory control, is the most common cause of various errors and vulnerabilities in software. All attempts at automatic memory management through various managers are hampered by the need to control the creation and deletion of objects, as well as periodically run garbage collection, which negatively affects application performance.

However, references in one form or another are supported in all programming languages, although the term often implies not completely equivalent terms. For example, the word "reference" can be understood as a reference as an address in memory (as in C++) and a reference as a pointer to an object (as in Python or Java).

Although there are programming languages that try to solve these problems through the concept of "ownership" (Rust, Argentum, or NewLang). The possible solution to these and other existing problems with references will be discussed further.

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

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

Тем не менее, ссылки в той или иной форме поддерживаются во всех языках программирования, хотя под этим термином часто подразумеваются не полностью эквивалентные термины. Например, под словом "ссылка" можно понимать ссылку как адрес в памяти (как в С++) и ссылку, как указатель на объект (как в Python или Java).

Хотя встречаются языки программирования, которые пытаются решать данные проблемы за счет концепции "владения" (Rust, Аргентум или NewLang). О возможном решении этих и других имеющихся проблем со ссылками далее и пойдет речь.

У меня уже более пяти лет пылится старый монитор ASUS VH323T. Это довольно старая модель с диагональю 23" и довольно неплохой матрицей (на КДПВ не он), но все дело портит очень плохая подсветка. Мало того, что у нее очень низкая яркость (всего 300 кд/м2), так еще лампы подсветки со временем очень сильно потускнели до противного желтого цвета, в результате чего монитор был заменен на более современный, чтобы не ломать глаза.

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

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

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

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

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

Так, на днях искал материалы про JIT компиляцию C++ в рантайме с помощью clang/llvm и поиск мне выдал мою же собственную статью трехгодичной давности: Динамическая JIT компиляция С/С++ в LLVM с помощью Clang / Хабр. В результате появилась уже эта новая статья про JIT компиляцию C/С++.

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

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

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

Прочитал материал "М.Видео: Нам всё равно" и невольно восхитился терпению его автора (Mike-M):

3 месяца и 40 обращений. Ровно столько времени и усилий мне потребовалось, чтобы прийти к выводу в заголовке статьи.

Тогда как мне хватило всего одного раза столкнуться с непониманием продавца-консультанта, чтобы решить написать обратную связь. Правда не для сети М.Видео, а для магазина ДНС, но это разница не принципиальная.

А поводом ко всему послужили установленные в магазине ДНС постоматы, хотя все началось с покупки SSD диска для ноутбука в магазине Озон :-)

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

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

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

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

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

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

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

Enable 2FA now. You'll be able to continue on with your work right after.

Но как обычно, дьявол в деталях. Ведь чтобы добавить аппаратный ключ нужно, чтобы двухфакторная аутентификация была УЖЕ активирована.

И в данном случае фокус с отправкой SMS на левый номер какого нибудь сервиса для временных телефонных номер вряд ли будет хорошей идеей.

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

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

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

Как говорится, предупрежден, значит вооружен. И данная статья — предупреждение другим возможным потенциальным жертвам, а так же простые рекомендации как не попадать на ту же самую уловку, на которую попался я при оплате очередного "выгодного" предложения из Китая.

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

Оборудование с подобной функциональностью уже присутствует на рынке (милли или микроомметры). Его можно свободно купить, запрограммировать на световую или звуковую индикацию при настройке нужного диапазона, но было несколько НО. Устройство требуется сперва настроить и перед началом каждой смены нужно переключать на необходимый для работы диапазон. Да и ценник у подобного оборудования находится в пределах 50-120тыс. руб., а самих приборов нужно было сразу несколько штук.

Типов контролируемых изделий было несколько и у них совершенно разные характеристики, но самая большая проблема была общая — очень узкий диапазон измерений (от единиц до полутора десятков Ом) и необходимость обеспечения высокой степени точности (в некоторых случаях требовалась погрешность порядка 1%).

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

Что из этого в конце концов вышло?

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

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

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

Ведь в жизни практически любого программиста может наступить момент, когда ему в голову приходит светлая идея — разработать свой собственный язык программирования. Может быть и не ради захвата мира, наравне с C/C++, Python или хотя бы PHP, а в качестве личного пет-проекта, с которым он, длинными зимними вечерами будет оттачивать собственное мастерство.

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

Это история — заметки на память о муках выбора связки лексер-парсер для разбора грамматики NewLang. А так же попытка описать и систематизировать выводы об особенностях разных анализаторов с которыми пришлось поработать при выборе парсера для разбора грамматики у своего языка программирования.

Понравилась статья HabraTab — девайс для хаброзависимых, где описана разработка устройства для визуализации рейтинга пользователя на Хабре.

И мне очень захотелось подобное устройство, вот только было несколько но:

• Очень лень было делать, заказывать и паять печатную плату
• Еще хотелось выводить рейтинг последней статьи, но хардкодить адрес и каждый раз пересобирать прошивку показалось очень муторно.
• Разработка на С/С++ меня не пугает, так как занимаюсь этим более 20 лет, но писать что-то под Arduino у меня душа не лежит. И это не говоря про необходимость настройки системы сборки под конкретный микроконтроллер.

Короче, немного поразмыслив, было принято решение делать свое устройство для визуализации рейтингов на Хабре, и как обычно с блекджеком и… ну вы поняли. И самое главное, чтобы можно было собирать устройство из покупных деталей с Алиэкспресса для максимально простого повторения и кодить на чем-нибудь попроще, чем на С/С++.

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

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

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

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

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

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

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

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

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

This is a translation of my own article

The release of NewLang language with a brand new "feature" is coming, a remodeled version of the preprocessor that allows you to extend the language syntax to create different DSL dialects using macros.

What is it about?

DSL (Subject Oriented Language) is a programming language specialized for a specific application area. It is believed that the use of DSL significantly increases the level of abstractness of the code, and this allows to develop more quickly and efficiently and greatly simplifies the solution of many problems.

Conditionally, we can distinguish two approaches to DSL implementation:

• Development of independent syntax translators using lexer and parser generators to define the grammar of the target language through BNF (Backus–Naur form) and regular expressions (Lex, Yacc, ANTLR, etc.) and then compiling the resulting grammar into machine code.
• Development or integration of the DSL dialect into a general-purpose language (metalanguage), including the use of various libraries or special parsers / preprocessors.

We will talk about the second option, namely the implementation of DSL on the basis of general-purpose languages (metalanguages) and the new implementation of macros in NewLang as the basis for DSL development.