Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

Вот раньше были хорошие матричные принтеры.

Они и сейчас хорошие, но перешли в разряд профессиональной техники за много денег.

На рулоне можно было печатать.

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

Как ЭТО печатать?

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

А как читать?

Только в просмотрщике, поддерживающем скроллинг непрерывной ленты страниц. Книги годные, но автор - человек специфический.

Но эти книги там продаются много лет, автор наверняка про это знает и никаких претензий не предъявил ;)

А как он предъявит? Он даже не в РФ сейчас.

Исходя из комментариев самого автора в своей гостевой...

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

А как он предъявит? Он даже не в РФ сейчас.

• Когда книги начали печатать он вполне себе был в РФ.
• Легко. Нанимается адвокат (для этого приезжать не обязательно) и вперёд.

Автор писал, что ему лень, но был бы рад, если найдётся какой-то юрист, кто помог бы прищучить это дело: http://stolyarov.info/node/422.

И примерно тогда он и решил изменить формат страниц.

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

Автор писал, что ему лень, но был бы рад, если найдётся какой-то юрист, кто помог бы прищучить это дело

Автор таким образом поддерживает определённое реноме «бессребреника». Это самый обычный маркетинг и не более того.

оверинжиниринг для простых случаев

Если можно обойтись последовательностью «запись во временный файл на том же разделе -> fsync -> rename временного файла на постоянное место», либо если целостность данных не важна (не собираемся их парсить), то можно и без СУБД.

В остальных случаях попытка работать с файлами напрямую выливается в ad-hoc кусок СУБД-шного бэкенда. Сложный, херово протестированный, не имеющий отношения к собственно логике приложения. Не надо такое плодить, просто возьмите sqlite.

А это что?

short.c:1:1: ошибка: по умолчанию возвращаемый тип функции - «int» [-Wimplicit-int]
    1 | main(){printf("hi all");}
      | ^~~~
short.c: В функции «main»:
short.c:1:8: ошибка: неявная декларация функции «printf» [-Wimplicit-function-declaration]
    1 | main(){printf("hi all");}
      |        ^~~~~~
short.c:1:1: замечание: include «<stdio.h>» or provide a declaration of «printf»
  +++ |+#include <stdio.h>
    1 | main(){printf("hi all");}
short.c:1:8: предупреждение: несовместимая неявная декларация внутренней функции «printf» [-Wbuiltin-declaration-mismatch]
    1 | main(){printf("hi all");}
      |        ^~~~~~
short.c:1:8: замечание: включите «<stdio.h>» или предоставьте декларацию для «printf»

gcc (GCC) 15.2.1 20260209

Да, в старых сях такое могло быть проглочено, но за это приходилось платить более страшными глюками…

Да. Минимально так:

$ gcc 1.c && ./a.out 
hi all
$ cat 1.c 
int printf(const char *, ...);
int main(){
    printf("hi all\n");
    return 0;
}

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

У каждой строчки справа указано как этот варнинг отключить.

Я - простой учёный, работаю в области моделирования материалов для катализа, пишу код для потенциалов, использую LAMMPS. Всех файлов - входной, да пара-тройка по каждому элементу в материале, все текстовые, килобайт 10. Вывод в stdout. Зачем мне база данных?

Я - простой учёный, использую OpenFOAM для моделирования течения топлива в двигателе внутреннего сгорания. Дискретизация области выполняется моей MPI программой и выводится в один большой файл, OpenFOAM читает. В каждом процессе использую MPI_File_wtite_at, которое позволяет записать всем процессам в один файл с индивидуальным смещением. OpenFOAM такие файлы поддерживает. Зачем мне база данных?

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

Они и сейчас хорошие, но перешли в разряд профессиональной техники за много денег.

Когда перешли? Я где-то 15 лет назад купил матричный LPT-принтер задёшево (не б/у, в магазине).

Как его здоровье, кстати? Кто-нибудь в курсе?

Да, разумеется, опции монтирования – дефолтные, т.е. data=ordered

В частности, я так понимаю, что xfs в случае блэкаута целостность в принципе обеспечивает только для метаданных, у него нет аналогичных ext4 опций монтирования. soomrack

У всех этих примеров одно общее свойство - ты готов потерять данные из-под этих программ в случае блэкаута или исчерпания места на диске или ещё каких-то неприятностей. Просто запустишь вычисления заново, not a big deal.

Прикол. Сайт без https в 2026 году. Лень проверять, но возможно это принципиальная позиция автора.

Угу, include «<stdio.h>» or provide a declaration of «printf»

О чём я и говорил.

Да, правильно.

Но еще раз. Если ФС подвержена озвученным тобой проблемам при потере электричества, то СУБД тебя тоже не спасет, у нее будут те же самые проблемы. Поэтому, все равно, для критических данных нужно ставить «writeback» или UPS и батарейку на hard RAID.

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

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

Мне даже встречались уникумы, которые всю медийную статику сайта кладут в СУБД.

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

Не совсем. Если такое произойдёт и хотя бы байт потеряется, кто-то в DOE получит очень большой пистон.

Я хотел сказать, что зона ответственности на уровне пользователя и на всех уровнях ниже определена по разному и не всегда следует решать проблему более низкого уровня самому. Но я и согласен в том, что мои примеры очень искусственные, подходят только для определённого рода деятельности. А значит могут в других случаях быть неприменимы.

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

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

А ещё СУБД общего назначения я абсолютно бесплатно получаю фильтрацию по разным критериям, сортировку по разным критериям, объединение данных, всякий там анализ… В «куске СУБД под свою задачу» это либо придётся велосипедить самому, либо делать вид, что это ненужно.

Не, я не спорю, есть задачи, где другого выхода просто нет. Когда надо выжать максимум эффективности. И то в этом случае специализированное хранилище нередко применяется не вместо, а вместе с реляционной СУБД.

Нет, это вообще даже не варнинг а непрошенный хелп к варнингу выше. Отключается флагом -fno-diagnostics-show-caret, что я себе давно прописал в дефолтные аргументы gcc.

А варнинги это вот -Wimplicit-int -Wimplicit-function-declaration -Wbuiltin-declaration-mismatch, надо дописать -Wno-implicit-int -Wno-implicit-function-declaration -Wno-builtin-declaration-mismatch чтобы их убрать.

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

бинарные версионированные форматы (никто не забыл, откуда это?)

Поиск находит Метапрог. Или было что-то до него?

Да, я про него. А разве этого мало? :) Это ж легенда ЛОРа, наравне с Санычем практически.

Когда перешли?

Где-то в 2010-х. Сейчас на Озоне или Яндекс-маркете новый — от 19-20 тысяч. Хотя можно найти те же модели б.у. за 1-3 тысячи на Авито. Более старые бывают ещё дешевле.

Вот тут за 16к можно купить https://www.nix.ru/autocatalog/printers_epson/Epson-LX-350-matrichnyj-9-pin-A...

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

Ты у нас не только в японской лингвистике, но еще и в computer science специалист? Как там твоя пробабушка поживает, рисовавшая на ASIC-терминале X11 Сатурн-V?

2all: просто загляните в ссылку ^^^, чтобы понимать, с каким персонажем вы взаимодействуете.

Но еще раз. Если ФС подвержена озвученным тобой проблемам при потере электричества, то СУБД тебя тоже не спасет, у нее будут те же самые проблемы.

Дык бэкенд СУБД специально написан так, чтобы их решать! Это специализированная, и совсем не наивная вещь (wal, o_direct, правильно расставленные fsync и fdatasync, учет размера дискового блока, и тд и тп). См, например, https://sqlite.org/psow.html . У СУБД проблем нет (она специально протестирована на этот предмет!), а у наивного прикладного кода (где блочная запись данных даже не вынесена в отдельный слой) они есть.

Поэтому, все равно, для критических данных нужно ставить «writeback» или UPS и батарейку на hard RAID.

Глупо спорить с этим. Однако не везде применения настолько дороги, чтобы нанять админа, который настроит ФС. Или даже просто чтобы иметь UPS. Программы на банальном домашнем компьютере тоже ведь не должны ломаться.

Любой мало-мальски уважающий себя программист в 2026 году должен уметь оперировать следующими понятиями:

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

Любой мало-мальски уважающий себя программист в 2026 году должен уметь работать со следующими технологиями:

Claude Code, CUDA, Docker, Hardhat, Kafka, Kubernetes, LangChain, Lean, Model Context Protocol, Nix, Pandas, Postgres, PyTorch, TensorFlow, WASM, WebGPU, и иже с ними.

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

СУБД комбинирует свой собственный журнал транзакций и правильное использование fsync. Это даёт гарантии надёжности на любой ФС, лишь бы жёсткий диск не врал и правильно отрабатывал fsync, но обычно не врёт.

Если ты реализуешь это же без СУБД, у тебя есть такие варианты:

Простой. Ты просто пишешь данные в новый файл и переименовываешь его со старым. Там тоже надо fsync сделать в нужных местах, но в целом тут всё просто. Если у тебя данные крохотные и тебя устраивает такой подход, проблем нет, БД тебе не нужна.

Пофиг. Ты просто ничего не делаешь. Данные могут пропасть при отключении электричества. Этот подход работает там, где данные не очень важны (например логи), или там, где ты можешь определить, что данные побились и вытащить их откуда-нибудь ещё (например кеши). Тут подчеркну, что желательно определять, что данные побились. ФС таких гарантий тебе не даёт, после выключения электричества ты можешь прочитать нули из файла, например, там, где должны были быть данные. То бишь какие-то свои контрольные суммы тут не помешают.

Вообще пофиг. Ничего не делаешь и бог с ним. Пропадут данные и ладно. Заново вобьют. Кажется так делают большинство программ. Но это не очень-то хорошо.

Решаем проблемы на другом слое. Можно попробовать найти ФС, в которой данные не бьются. Я, правда, такую не знаю. Но может и есть такая. Пишут про ext4 с нетривиальными опциями монтирования. Не разбирался, честно говоря.

Переизобретаем БД. Реализуем журнал, пишем патчи в журнал, модифицируем данные в файле, коммитим журнал. Это даёт нам возможность делать надёжную запись на не слишком надёжной ФС (но жёсткий диск всё равно должен не врать на fsync). И вот тут надо очень аккуратно и правильно дёргать fsync на нужное. Хотя не думаю, что это так уж сложно, статьи есть, просто надо про это заранее знать. Тут самое противное, что тестировать это всё практически невозможно, поэтому надо полагаться на своё мастерство писать код, который будет проверяться уже в бою, причём раз в 5 лет.

Вот последний случай очень сильно намекает на то, что всё же лучше использовать готовую СУБД, пусть даже в библиотечном виде вроде sqlite. Ибо они всё протестировали неплохо и уж заведомо лучше тебя.

Вот это мощный список баззвордов для зомбификации, конечно.

По БиДе будут книжки? Или не нужно?

С одной стороны трудно не согласиться. С другой стороны, ну и кто будет восполнять этот недостаток?

В плане написания и издания книжек — не нужно. Пока кто-то это напишет, отполирует, пока кто-то это прочитает, мир уже уйдёт далеко вперёд. Книги — устаревший способ передачи опыта, непригодный для скорости современной индустрии ПО.

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

Единственный способ научиться актуальным знаниям — следить за новостями, брать в руки актуальные технологии, документацию и браться за работу. Читать свежие статьи на arXiv. Если сложно или нет знаний английского — ЛЛМ разжуют. Пользы от разговора с Claude в одном окне и эмулятора терминала в другом будет намного больше, чем от размеренного чтения толстой книжки.

Если ты опасаешься потери данных из-за отключения электричества, данные тебе важны, и по каким-то причинам у тебя нет UPS (который стоит совсем недорого), то можно монтировать ext4 с опцией «writeback». Это стандартная опция для стандартной ФС. Если ты озабочен сохранением данных в условиях вероятной потери питания, то ты про нее должен знать, ведь работа на компьютере не ограничивается работой твоей программы.

Если бинарные данные у тебя статичны, то как СУБД защитит их, в чем угроза?

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

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

Чего там fsync делает еще большой вопрос, точнее вопрос в том, будет ли результат тот, который ты ожидаешь. Было много примеров, что нет, т.к. часто ему диск отвечал, что «все отлично, записано», а по факту данные из кеша диска еще не приземлились.

Грамотная настройка СУБД и последующее взаимодействие с ней, это на два порядка сложнее задачи смонтировать ext4 с опцией «writeback» и дергать fsync из программы. И уж тем более, гораздо сложнее, чем пойти и купить UPS для домашнего компа.

Если же работа ведется в виртуальном окружении, то там вообще непонятно, что ваши fsync делают, что из системы, что из СУБД.

Короче, мой посыл был простым: задача сохранения целостности файлов это задача ФС, соответственно, ее и нужно грамотно настраивать. Но если требуется обеспечить целостность файлов в контексте наличия отношений с другими данными, или же регулярно частично обновлять содержимое файлов, а файлы это не абстрактные бинарники, а имеют какую-то структуру, то использование СУБД в этом случае может быть очень логичным и правильным, потому как это задача СУБД – обеспечить целостность данных с учетом их отношений.

Какие прорывные технологии ПО за последние 20 лет? Как говнякали на сишечки, так и продолжают. И уверен, что 80% этих говнякателей, Кнута не читали, т.к. «книги — устаревший способ передачи опыта, непригодный для скорости современной индустрии ПО.»

ext4 с опцией «writeback»

Лучше родного zfs из солярки, еще ничего не придумали.

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

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

Кибернетика — важный исторический урок для всех, кто хочет отмахнуться от ИИ.

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

Сейчас всё как раз в облаках, см. AWS. А на базе каких данных создаются большие языковые модели, как не больших?

Сейчас всё как раз в облаках

Если быть более конкретным, то сейчас основная концепция хранения больших данных это «data mesh» – «сеть данных», некоторая структура поверх озера данных, которое находится в облаке, но роль «облака» тут примерно как роль HDD в компе.

Да, но что из этого оказалось прям «серебрянной пулей» ? Почему-то всё больше в моду входят приватные «облака», или гибридные (половина инфры в публичном «облаке», половина в частном). «Большие» данные тоже оказались нужны почему-то далеко не всем. С электронными болванчиками «ИИ» тоже не всё так просто - и глючат они временами, и врут периодически, и в контроле жестком нуждаются.

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

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

Что ты будешь делать когда aws физически ликвидируют?

Когда перешли?

15 лет назад

матричный LPT-принтер

Эх, мои 15 лет назад тоже как будто вчера были.

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

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