Теперь о хорошем. Для того, чтобы нам не терять качество, мы сделали дополнительное место - группу в Онтосети,
там статья "Практическое упражнение" уже выставлена. Это наше место для статей и файлов, дополнительное к каналу
(открыто для чтения всем, публикация для участников). Для того, чтобы стать участником,
надо присоединиться к группе.

Предлагаю всем, кто выкладывал статьи в канал: 1) стать участником группы и 2) выложить свою статью.
Учтите, что код группы дорабатывается прямо по ходу, так что неудобства и шероховатости точно есть и будут устраняться.

Как найти статьи (временный хак):

Всё исправлю, пункты меню переставлю :)

Добрый день. Если кому-нибудь интересно. На STEP (https://persons.iis.nsk.su/en/STEP-2024) опубликовали видео нашего доклада по некоторым техническим приемам ППП в ppclang: https://rutube.ru/video/76af8364475d8444822b0e4307cccaf1/
Там же опубликована презентация: https://persons.iis.nsk.su/files/persons/pages/legalov13jan25.pdf

Выложил "Дневник разработки Тривиля": https://ontonet.org/blog/дневник-разработки-тривиля, в котором собраны записи из моего блога. Надеюсь, читать будет интересно - по записям видно, как менялся язык, как менялось мое видение языка.

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

Кроме того, там же, в раздел Файлы можно выкладывать полезные материалы. Я уже выложил работы конференции HOPL (History of Programming Languages).

Добрый вечер. Раз появляются дискуссии и обсуждения и проблемы с их введением, то может быть на онтосети помимо блогов сформировать форум. Там обычно темы более структурированы и отслеживаемы. Удобнее общаться и оперативно отслеживать изменения интересующих тем. Или форумы уже считаются динозаврами (давно не общался, поэтому не знаю)?

Павел Косов опубликовал статью "Трансформация процедурно–параметрических конструкций языка программирования 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