Павел Косов опубликовал статью "Трансформация процедурно–параметрических конструкций языка программирования C в промежуточное представление компилятора Clang": http://digital-economy.ru/stati/%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80%D0%BD%D0%BE%E2%80%93%D0%BF%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85-%D0%BA%D0%BE%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D0%B9-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-c-%D0%B2-%D0%BF%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D0%B5-%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%B0-clang

Наткнулся на удивительный рассказ "Шпаргалки" Александра Леся. Рассказ написан в 90-е, но такое ощущение, что написано про современную ситуацию с нейросетями и прочими интеллектуальными помощниками.

https://royallib.com/book/les_aleksandr/shpargalka.html

Первая сборка Тривиль на Эльбрус 8СВ состоялась!

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

https://gitflic.ru/project/alekseinedoria/trivil-0/issue/37

Терминологию из области построения языков и компиляторов довольно трудно переводить на русский язык. Почти везде используется транслитерация и "калька" с иноязычных терминов. Сегодня наткнулся на интересный аналог термина desugar — "высолаживание":

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

https://sugar.ru/node/12149

12 апреля 2025 нас ждет юбилей - 1000000 лет со дня первого полета человека в космос. И пусть это двоичный юбилей, но разве это делает его менее великим?

Накануне, 11 апреля, в Москве, мы проводим рабочую встречу (антиконференцию) на тему "Технологический суверенитет в базовом ПО" под скромным названием "Поехали!".

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

И чтобы сразу начать, вот первые заявки:
- А. Недоря "Куда идем мы с ... языками программирования"
- А. Недоря "Архитектурное программирование"

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

Запись моего выступления на CompuTech@2025 - Языки программирования: прошлое и будущее
https://disk.yandex.ru/i/U0yTaHHDRPgBCg

Заметка об ООП

Автор: Дмитрий Власов @vlasov_dmitry

Имея длительный опыт написания кода на разных языках, по крайней мере 20 лет, я хотел бы поделиться некоторыми мыслями относительно правильного использования ООП. На самом деле, после знакомства с такими языками, как C++ или Java в середине нулевых, очень заманчиво использовать ООП как серебряную пулю и использовать его для всего. Я тогда прошел этот этап (где-то в середине нулевых).

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

Если попытаться сформулировать это кратко, то ключевая функция ООП — это обеспечение расширяемости системы путем повторного использования классов с сохранением некоторой части их поведения и корректировкой некоторой части поведения для конкретного случая путем переопределения. Вы можете рассмотреть так называемый принцип открытости-закрытости (https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D1%81%D1%82%D0%B8/%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D1%81%D1%82%D0%B8) как основной предикат для проверки, действительно ли вам нужно ООП в этом конкретном месте вашей системы или нет.

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

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

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

Осталось два месяца до "антиконференции" в Москве. Настоящих буйных мало... Предлагаю темы для обсуждения, которые, на мой взгляд, стоит обсуждать (и надеюсь на то, что будут желающие их модерировать):
- АРМ разработчика программ - что мы хотим вместо/после IDE
- Интернет объектов - какие языки/инструментальные средства нужны
- Что после LLVM: MIR, SIL, MLIR - очень хочется услышать обзор состояния дел и мысли о развитии и о том, что мы можем сделать
- Обучение системному программированию - темы, межвузовские проекты, ...
- Летняя школа
+ Развитие языков программирования
+ Архитектурное программирование
"+" в списке означает - буйный есть, "-" - еще нет
Те, кто могут/хотят модерировать или сделать вводное сообщение, но сомневаются, пишите - сделаем отдельную группу и обсудим.

Данную новость не могу не опубликовать:

Создатель Linux Линус Торвальдс (Linus Torvalds) подключился к спору между фанатами Rust и С, пишет The Register. Он сделал вполне конкретный выбор между теми, кто хочет сделать ядро Linux более безопасным, переписав его на Rust, и теми, кто не желает тратить на это время и намерен добиться выдворения всех строчек Rust-кода из ядра, оставив только код на С.

https://www.cnews.ru/news/top/2025-02-10_problema_v_tebelinus_torvalds

Введение в архитектурное программирование
http://digital-economy.ru/stati/третья-структурная-эволюция-введение-в-архитектурное-программирование

Ближайшее заседание семинара STEP состоятся во вторник 11 марта с 14:10 до 15:40 мск (18:10-19:40 в Новосибирске)

Выступит Алексей Недоря

Тема: Ретроспектива: что я защищал в кандидатской 11 тысяч 111 лет назад.

Авторская аннотация: Ровно 31 год назад, 11 марта я защищал кандидатскую диссертацию "Расширяемая переносимая система программирования, основанная на биязыковом подходе". В этот раз поговорим о том, как я тогда дошел до такой жизни и такой диссертации. Что я защищал тогда и что сейчас я думаю об этом.

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

Запись семинара: https://rutube.ru/video/private/603667a71601c32085250783ee47fd0d/

Тривиль версия 0.95 выложена в мастер (описание языка и компилятор). Добавлены анонимные типы векторов, изменены грамматические правила Указ-типа и Операнд. Изменение небольшое, но для меня важное.

Наткнулся на фото, не помнил, что такое есть. Думаю, что Цюрих 1991, Вирт, я и Гуткнехт

Опубликовал релизы для Windows и Linux. Включил в релизы сгенерированные файлы *.c

https://gitflic.ru/project/alekseinedoria/trivil-0/release/c09308df-49c1-4297-8e1c-a41030933720

Хочу совет по лексике. В Тривиле, исходя из частоты использования, логические операции '&' (conditional and), '|' (conditional or) сделаны короткими, в отличие от Си традиции. При этом возникает вопрос о битовых (bitwise) операциях. Я сделал их с префиксом ':'
:&, :|, :~ (инвертирование), чтобы читалось как "битовое И", "битовое или". Но вот теперь, посмотрев на это, мне кажется, что лучше сделать наоборот: '&:', '|:', '~:'. В этом есть еще один смысл, я написал (:~ x), что в Тривиле разбирается как лексемы проверка типа '(:' и not '~'.
Вопрос 1: есть ли смысл менять? Или может есть другие варианты?