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

Столярик - чемпион 1300 комментариев будет нормальный формат - обязательно прочитаю

Нету по ссылке. Я хотел сравнить со своей методикой (распаковать qpdf и пропатчить cmap, запаковать обратно или затереть строки /ToUnicode пробелами)

никого уже не удивишь фреймворками в несколько миллионов строк,

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

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

Какие например? Ну генераторы картинок и всякие LLM понятно, но ещё что-то есть?

начинать с Python, а не Паскаля - это тоже нормальный подход. С Паскаля - более академично, с Python - более практично, в обоих вариантах есть свои плюсы.

А ты уверен, что нормальный? А сможет ли тот, кто начал с питона потом освоить нормальные языки?

А сможет ли тот, кто начал с питона потом освоить нормальные языки?

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

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

DISCLAIMER: это всё по анекдотическим наблюдениям, никакой статистики на хорошей выборке у меня нет.

Кому в GTK написать, чтобы в GtkTextView сделали поддержку Alt-кодов?

Так это в Windows же. В линуксе Ctrl-Shift-U или Compose key.

Так это в Windows же. В линуксе Ctrl-Shift-U или Compose key.

Разработчики Gtk заявляют, что она переносима. А по факту в Блокноте альт-коды работают, в браузере работают, а в GEdit не работают.

Замечу, что в РФ при продаже физическим лицам есть Закон о защите прав потребителей. Там ответственность продавца за порчу имущества есть. В том числе программным обеспечением. https://zpp.rospotrebnadzor.ru/news/federal/561922

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

В случае обнаружения в цифровом продукте недостатков, если они не были оговорены продавцом, потребитель по своему выбору вправе,

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

Ну да. https://habr.com/ru/articles/122020/

Неприятно, но бывает. В случае бесплатного OpenSource даже ЗоЗПП неприменим.

https://club.dns-shop.ru/digest/166286-ii-chatgpt-5-3-codex-po-oshibke-udalil...

ССЗБ, если у ИИ-агента есть права админа и вообще права за пределами песочницы.

Столяров хочет, чтобы было больше хороших программ. Для этого учит студентов, пишет манифесты и объяснения в гостевой.

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

Сейчас в дополнение к моим словам выше Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий) ещё в 1-м томе 2.92 издания на стр. 172 наткнулся:

Последовавшие за этим «многоядерные» архитектуры представляют собой не более чем количественное развитие, притом в направлении, практически не увеличивающем реальное быстродействие системы. Дело в том, что даже серверные машины, работающие с серьёзной нагрузкой, в основном «упираются» в своей производительности не в скорость работы процессора и тем более не в конкуренцию программ за единственный процессор, а скорее в скорость дисковых обменов и работы шины; ни на то, ни на другое «многоядерность» повлиять не в состоянии. Как правило, все ядра, кроме одного, в системе бо́льшую часть времени простаивают.

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

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

Столяров, если он действительно «We professional programmers» из его манифеста (отдельно замечу, что даже мне, который далеко не на уровне native знает английский, эти и многие другие места кажутся рунглишем) мог бы научить новые поколения программистов правильному использованию и Python и Javascript и других актуальных языков и фреймворков, вместо чего он просто скопом всё отрицает и требует писать программы на уровне техник 90-х годов.

Ну вот реально, если смотреть на вещи, то что полезного в его табу?! Где в нём про правильную архитектуру вообще?

interpreted execution is for scripting and built-in DSLs only

Совремённый подход в некотором роде обратный: на интерпретируемых языках, вроде Python быстро, легко и относительно безопасно (управление памятью, etc) пишется основная логика, в которой, там где нужно быстродействие, вызываются части, написанные на компилируемых языках, вплоть даже до ассемблера, если сильно нужно.

languages that have their 'ecosystems', such as Perl, Python, Ruby and the like, are not allowed

Бред. Хотя бы задумался, а с чего вдруг эти языки и «экосистема» возникли, притом вовсе не от корпораций, а развиваясь в OpenSource сообществе.

'semi-interpreted' languages, such as Java or C#, are not allowed

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

each of your programs must link statically

Угу, на Python Столяров писать запретил, допустим захотел нейросетку написать на C++, использовав C++-вариант PyTorch'а - libtorch, но и тут засада. Вот есть несколько гиг - линкуйся с ними статически. У клиентов могут быть разные GPU c разными вариантами libtorch (для CUDA, для ROCm и др) - вот со всеми и линкуйся. Статически %-)

source tree must be self-containing, all used libraries must reside within it

Это к вопросу о хостинге. Вот все гигабайты и хости.

data not intended to be modifiable by the user, must be bundled into the executable binary

В принципе приемлемое требование, но может быть и неудобным, по большому счёту вообще непонятно зачем об этом беспокоиться. Он поясняет:

Data files 'shipped together' with your program are generally not desirable and must be limited to the data the user is supposed to provide or modify. Data not intended to be supplied or modified by the user, such as icons or other images, must be built into the executable.

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

be extremely discriminating with the standard library features

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

no automated software updates

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

no client-side scripting, including JavaScript on websites

С одной стороны я тоже против js на сайтах, но нельзя не признать, что в ряде случаев без него очень сильно неудобнее: на каждый чих (платформу, ОС) не напасёшься делать приложения, да и установка у пользователя отдельного софта для работы с каждым сервисом, где недостаточно возможностей чистого html+css хуже даже с точки зрения безопасности, чем js в браузере.

No multithreading (and shared memory)

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

No data formats with recursive nesting, such as SGML, XML, [X]HTML, JSON etc.

Опять возникает ощущение, что у Столярова какой-то ограниченный опыт. Что он предлагает:

So here's the rule: machine-readable data formats with recursive nesting are forbidden. By the way, according to the theory of databases, the 1NF is sufficient for any purpose, and 1NF only demands all values in a table being atomic.

Из того, что «1NF is sufficient for any purpose» не следует, что они (кстати, что - CSV что ли?) обязаны применяться вместо XML. Опять же, если формат данных нужен только для чтения машиной, то там хоть что угодно может быть, но форматы, вроде XML или Json придумали, чтобы и человеку в принципе можно было читать и редактировать и машине, к тому же, чтобы можно было верифицировать по определённым правилам поступающие данные.

Остальное устал всё подряд комментировать, по поводу требований к ascii идентификаторам и строкам в принципе можно и согласиться даже, но уже требовать ограниченной поддержки Unicode - маразм. То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

Далее почти каждый пункт вызывает возражения.

В итоге всё-таки, а при чём тут написание программ на авось или не авось? Это перечень «идеосинкразий» автора, к архитектуре почти не имеющий отношения, кроме разве что насчёт мультипоточности.

Селя ви, как говорят французы.

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

Правильно, можно писать свою талассу пять лет или сколько он её пишет или использовать чужие решения пусть даже на нелюбимом им питоне, жабаскрипте и чем ещё (и прочие требования), а своё время потратить на что-то другое.

И сколько бы времени понадобилось чтобы реализовать CMS со свойствами Талассы на чём-то другом? Как бы не больше.

Зато в GEdit работает Ctrl-Shift-U даже под Windows, что гораздо лучше альт-кодов.

Правда Compose ещё лучше, интересно, он работает в Windows или нет?

сможет ли тот, кто начал с питона потом освоить нормальные языки?

Если он начинал с питоновского симулятора risc-v или вообще какой-нибудь выдуманной ЭВМ? А потом набросал на питоне средства разработки программ, которые можно тестировать в этом симуляторе.

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

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

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

Какие например? Ну генераторы картинок и всякие LLM понятно, но ещё что-то есть?

Ну навскидку, просто что в голову пришло сразу:

Секвенирование и анализ ДНК. Можно в одиночку писать обработку гигабайт генетического кода.

Поиск рыночных аномалий. Высокочастотный трейдинг (HFT).

Распознавание медицинских снимков и вообще снимков. Сейчас можно в одиночку написать обработку МРТ с целью поиска определенных заболеваний. Или дефектов в дефектоскопии на производстве.

Игры с фотореализмом в 3D. Движки Unreal Engine, Unity позволяют в одно рыло сделать довольно крутые вещи. Конечно полноценная игра AAA уровня потребует привлечь и актеров и много чего ещё, но есть и инди-проекты.

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

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

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

В случае бесплатного OpenSource

Так он поэтому и бесплатный. Как только взял хоть рубль за программу, так отвечаешь. А так да, программисты пишут «для развлечения», остальные могут пробовать что-то запустить на свой страх и риск.

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

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

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

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

Бред. Хотя бы задумался, а с чего вдруг эти языки и «экосистема» возникли, притом вовсе не от корпораций, а развиваясь в OpenSource сообществе.

Вы же сами выше писали. Потому что в этом сообществе принято, что никто ни за что не отвечает, потому что бесплатно. А «for fun» с экосистемой веселее.

Хоят и меньший, но отсекает чуть ли не весь совремённый документооборот

Его невозможно писать на Си и Коболе? То, что принято писать на Java, не значит, что так лучше.

Вот есть несколько гиг - линкуйся с ними статически. У клиентов могут быть разные GPU c разными вариантами libtorch (для CUDA, для ROCm и др) - вот со всеми и линкуйся. Статически %-)

Так клиент статически и слинкует. Вряд ли он GPU без выключения компьютера постоянно меняет.

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

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

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

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

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

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

Нда, и что же люди дураки такие покупают процессоры с более, чем сотней ядер?

Сейчас например серверы работают с десятками и сотнями докер-контейнеров, в которых крутятся виртуальные машины с сервисами, что-то обрабатывающими. А на десктопе параметр -j часто почти линейно ускоряет компиляцию. Даже архиваторы научились много ядер использовать в работе. Видеостримминг, 3D-рендеринг и тд. всё это не экзотика. Игрушки сейчас умеют использовать несколько ядер, до 6-8 обычно. Хотя больше редко.

А даже если упор в I/O при чтении файла, то всё-равно несколько ядер позволяют быстрее обслуживать это чтение. Одно ядро ждёт чтения, другое (или вообще несколько) - обрабатывают и это часто имеет существенное значение на практике. К тому же с появлением SSD, особенно быстрых SSD не такой уж и малой бывает скорость чтения. Например, пиковая пропускная способность базового модуля DDR5 - 38.4Гб/сек, в двухканальном режиме - 76.8 Гб/сек. Пиковая скорость чтения с SSD Samsung 9100 Pro - 14.8 Гб/сек. Всего в 2-5 раз медленнее RAM.

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

Вы же сами выше писали. Потому что в этом сообществе принято, что никто ни за что не отвечает, потому что бесплатно. А «for fun» с экосистемой веселее.

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

Его невозможно писать на Си и Коболе? То, что принято писать на Java, не значит, что так лучше.

Лучше не лучше, но в здравом уме никто на Си писать корпоративный документооборот не станет. Напишут на java, на C#, даже на Python, но точно не на Си. Даже на C++ не станут. Потому что есть сложившаяся экосистема из библиотек, потому что есть сборщик мусора, необходимость которого в имеративных языках Столяров отрицает, потому что в итоге пишется быстрее и требует меньшей программистской квалификации от разработчиков.

Так клиент статически и слинкует. Вряд ли он GPU без выключения компьютера постоянно меняет.

Это вообще без комментариев, надо просто видеть работу.

Это к вопросу о хостинге. Вот все гигабайты и хости.

Выше про left-pad и использование библиотек из Интернета уже обсуждали. И для компиляции ведь всё равно скачивать приходится.

но в общем-то всё тот же вопрос: какого хрена?

Чтобы можно было запускать скопированный файл, а не раскладыванием предварительно нужных файлов в /usr/share (или /usr/local/share или /opt/share/…).

на каждый чих (платформу, ОС) не напасёшься делать приложения, да и установка у пользователя отдельного софта для работы с каждым сервисом, где недостаточно возможностей чистого html+css хуже даже с точки зрения безопасности, чем js в браузере.

Лучше бы линукс в виртуалке для таких приложений запускали (придумали же docker). Браузер — программа для просмотра гипертекста. Представьте себе, что кто-нибудь решил бы писать программы на скриптах OpenOffice (а что? сразу переносимость всюду, где он запускается).

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

Практически всегда.

ощущение, что у Столярова какой-то ограниченный опыт

Он просто проповедует аскезу.

То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

Вы много программ знаете, которые работают с текстами в utf-16 и корректно обрабатывают все ситуации с суррогатными парами?

В итоге всё-таки, а при чём тут написание программ на авось или не авось?

При том, что либо пишешь программу так, что понимаешь её поведение полностью. Либо «программа поддерживает юникод (авось разработчики библиотеки полностью реализовали поддержку), умеет работать с JSON (авось разработчики библиотеки …), умеет импортировать XML (авось разработчики библиотеки …), …».

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

параметр -j часто почти линейно ускоряет компиляцию.

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

Одно ядро ждёт чтения, другое (или вообще несколько) - обрабатывают

Как же деды ждали окончания ввода-вывода без дополнительных простаивающих ядер? Конечно, у них были КАНАЛЫ, но речь-то о CPU.

Как же деды ждали окончания ввода-вывода без дополнительных простаивающих ядер? Конечно, у них были КАНАЛЫ, но речь-то о CPU.

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

И для компиляции ведь всё равно скачивать приходится.

Придётся. С другого сайта. Да, понимаю, зависимости могут бесить и вообще протухнуть, но и средства их хостить у себя не у всех имеются. Вопрос размера.

Чтобы можно было запускать скопированный файл, а не раскладыванием предварительно нужных файлов в /usr/share (или /usr/local/share или /opt/share/…).

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

Лучше бы линукс в виртуалке для таких приложений запускали (придумали же docker). Браузер — программа для просмотра гипертекста. Представьте себе, что кто-нибудь решил бы писать программы на скриптах OpenOffice (а что? сразу переносимость всюду, где он запускается).

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

Вы много программ знаете, которые работают с текстами в utf-16 и корректно обрабатывают все ситуации с суррогатными парами?

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

При том, что либо пишешь программу так, что понимаешь её поведение полностью.

Мда, наверное реально полностью поведение своей программы я понимал только на программируемом калькуляторе МК-52, да и то там некоторые мелкие нюансы могли быть, хотя бы вокруг особенностей округления. Но даже оставив в стороне заведомо неполное понимание из-за системы и аппаратуры, всё тот же вопрос про сложность библиотек. У разработчиков нет физических возможностей полностью понять всё что они используют. Или надо отказываться от крупных библиотек и задач для которых они нужны.

P.S. Мне тоже многое не нравится в совремённой разработке, но я при этом понимаю, что это часто следствие более глубоких причин, чем просто вредные привычки. Поэтому попытки провозгласить табу тут ничем не закончатся, никакого rebuild world с хорошими и правильными программами не произойдёт.

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

Обучающийся подготовится к выпускным экзаменам по ИКТ

Куча людей теряет данные, например, в офисных программах, вроде Word при их сбоях, что-то никто не отсудил ничего.

Есть ссылка на решение суда или хотя бы номер дела? Крайне интересна аргументация судьи.

Он сам же утверждает, что параллельная работа часто упирается в I/O, а не процессор, в этом случае проще распределять работу по нескольким асинхронным потокам в рамках одного процесса.

Практически одинаково.

В простейшем случае, например, при ожидании ввода пользователя и работе в фоне.

Так делишь на интерфейс демон. Как mpc + mpd. В пределе они даже на разных языках могут быть.

Сейчас например серверы работают с десятками и сотнями докер-контейнеров, в которых крутятся виртуальные машины с сервисами

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

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

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

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

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

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

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

проще находить и использовать готовые решения?

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

Хотя вру. Есть TeX и qmail. Но эти обе программы написаны по заветам Столярова (без внешних зависимостей кроме операционной системы).

А почти во всём остальном выбор из нуля нормальных решений.

Потому что есть сложившаяся экосистема из библиотек

Вот именно. Не надо как лучше, а надо как принято. Поэтому вся эта экосистема и ухудшается на каждом этапе.

потому что есть сборщик мусора

Он ещё на лиспе был. Почему-то не пишут корпоративный документооборот на лиспе. Наверное, всё-таки дело не в нём.

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

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

Придётся. С другого сайта. Да, понимаю, зависимости могут бесить и вообще протухнуть, но и средства их хостить у себя не у всех имеются. Вопрос размера.

Если их всё равно надо скачать для компиляции, значит место под них есть. Ведь компилятор прямо из Сети файл не возьмёт Зачем их удалять после компиляции?

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

Вот по Столярову все программы должны быть такими. Аскеза.

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

На смартфонах так и есть. Всем удобно.

Или, наоборот, тебе как разработчику сервиса непременно надо было бы наплодить вариантов для разных ОС и аппаратных платформ.

Когда-то для этого придумали Java. Но потом что-то пошло не так и Java ушла на сервера, а пользователям вместо этого сделали среду выполнения в браузере. И из-за этого для использования сервиса вроде yandex map приходится ставить неподконтрольную программу, которая есть больше ресурсов, чем все остальные программы вместе взятые. Если использовать браузер, который только браузер, типа NetSurf, то эти сервисы работать не будут.

Сейчас придумали докер. Но опять что-то идёт не так.

В жизни на практике чаще нужно, чтобы программа смогла хоть как-то что-то сделать

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

Или надо отказываться от крупных библиотек и задач для которых они нужны.

Крупные библиотеки должны идти с гарантией работоспособности. Примерно такой: https://cr.yp.to/qmail/guarantee.html, но не про безопасность, а про соответствие заявленной функциональности.

Зато в GEdit работает Ctrl-Shift-U даже под Windows, что гораздо лучше альт-кодов.

Хуже отсутствием единообразия.

Есть ссылка на решение суда или хотя бы номер дела? Крайне интересна аргументация судьи.

В том-то и дело, что нет. Даже попытки отсудить что-то не делалось в подобных ситуациях. И что-то мне подсказывает не потому, что люди своих прав не знают.

Практически одинаково. Так делишь на интерфейс демон. Как mpc + mpd. В пределе они даже на разных языках могут быть.

Я не сомневаюсь, что можно, я о том как удобнее. Можно вообще сделать микросервисы. Да и async wait бывает, что прячут под капот.

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

Жуть не жуть, но многоядерные процессоры для сотен процессов по-любому нужны.

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

См. выше. Отдельное ядро не обязательно, я о том, что ускоряется вообще обработка пока I/O происходит

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

Такую, что повторюсь, Столяров, а за ним и ты делаете логическую ошибку, считая некий средний за 24/7 процент загрузки системы. А считать надо скорость исполнения задач пользователя. На одном ядре у меня программа компилируется полчаса, на 12 ядрах с make -j 12 - 3 минуты. Вот это и есть разница! На одном ядре fps в игре (ещё не всякая игра запустится) 10 fps, на 8 ядрах - 50 fps. Видеостриминг в видеоконференции в Zoom или аналоге на одном ядре заткнётся, на 8 ядрах спокойно тянет несколько человек. И тд. И тп. А не суперсофт для физических экспериментов.

Про скорость открытия гаража, то есть, разницу между ожиданием I/O и скоростью обработки данных, я выше уже кидал сравнение линейной скорости чтения. Она на топовых, но всё же даже консьюмерских SSD всего в 2-5 раз меньше скорости чтения из RAM.

Вылазьте со Столяровым из под коряги! Со времён Core2 Duo уже почти 20 лет прошло. Рассуждения в 2026-м году про удивительную малополезность и тем более дебильность многоядерных процессоров - это бред.

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

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

А не надо к обычным программам предъявлять требования, как будто их в управление полётом на авиалайнер, космический аппарат или куда-то в аналогичное mission critical место ставить собрались. А если всё же хочется, то готовьте очень толстые кошельки.

Хотя вру. Есть TeX и qmail. Но эти обе программы написаны по заветам Столярова (без внешних зависимостей кроме операционной системы).

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

Он ещё на лиспе был. Почему-то не пишут корпоративный документооборот на лиспе. Наверное, всё-таки дело не в нём.

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

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

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

Если их всё равно надо скачать для компиляции, значит место под них есть. Ведь компилятор прямо из Сети файл не возьмёт Зачем их удалять после компиляции?

Локально незачем. Но чтобы распространять свой проект, по Столярову, придётся и все внешние фреймворки распространять сколько бы они ГБ не заняли.

Вот по Столярову все программы должны быть такими. Аскеза.

Ну и пусть сам аскетстствует. Но не надо его аскезу выдавать за правильный архитектурный подход.

На смартфонах так и есть. Всем удобно.

Можно и из браузера. На смартфонах.

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

Крупные библиотеки должны идти с гарантией работоспособности. Примерно такой: https://cr.yp.to/qmail/guarantee.html, но не про безопасность, а про соответствие заявленной функциональности.

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

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

требовать ограниченной поддержки Unicode - маразм. То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

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

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

А вот тут автор как раз и пишет как это можно реализовать без всяких потоков.

А всякие компиляции — это многопроцессность, а не многопоточность. Ничего не мешает так же делать и в приложениях, делить их на процессы, а не потоки.

Обучающийся подготовится к выпускным экзаменам по ИКТ

А сможет он потом нормально программировать на других языках, хотя бы паскале/fpc или придётся переучиваться?

Жуть не жуть, но многоядерные процессоры для сотен процессов по-любому нужны.

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

Многоядерные процессоры теоретически нужны для суперкомпьюетров для задач с очень сильной связностью по памяти (когда на кластер потоки не раскидать). Но таких задач на весь мир на один суперкомпьютер будет. А всё остальное — размазывание стоимости этого суперкомпьютера на пользователей смартфонов с 10-ядерными процессорами.

И распухание требования ПО, думаю, для этого же.

На одном ядре fps в игре (ещё не всякая игра запустится) 10 fps, на 8 ядрах - 50 fps.

Там видеокарта важна, а не процессор.

Со времён Core2 Duo уже почти 20 лет прошло.

Реально все потребности пользователей были закрыты ещё пентиумом 3. Дальше некоторое время была безумная реклама про то, как «новый процессор ускоряет Интернет», а потом просто начали пихать алгоритмы Шлемиэля во все поля. Современная игра по воспринимаемому качеству почти такая же, как 20-летней давности, но требует новый процессор «а то не запустится». Про отрисовку клавиатуры, требующую ресурсов как хорошая ОС, я уже писал.

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

А если всё же хочется, то готовьте очень толстые кошельки.

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

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

Если есть надёжные компоненты, сложность не проблема. Но предпочитают делать на авось. И поэтому спроса на надёжные компоненты нет (кому нужен надёжный daemontools, если есть модный systemd c QR-кодом и веб-сервером).

Дело не в нём, но порог вхождения и надёжность повышается от того, что не надо дрочиться с управлением памятью.

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

Так-то утечку памяти

Утечку можно и в Java легко сделать. Достаточно складывать объект в какой-нибудь хеш и забыть его оттуда удалить. В Си опаснее порча памяти.

Качественный софт.

Столяров больше теоретик. Если нужны практики с такими же взглядами, то Кнут, https://cr.yp.to/djb.html, https://suckless.org/.

Столяров просто фриком уже выглядит за пределами темы обучения новичков программированию

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

Можно и из браузера. На смартфонах.

Если разработчик страницы соизволил. Иначе ползаешь по сайту как муравей по слону. А если сервис ещё и правую кнопку мышки использует, то вообще труба.

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

Ещё раз, я не про то, что всё писать с нуля. Я про то, что, по-хорошему, надо вернуть желание писать надёжно. Были же коммерческие библиотеки. Но умерли, так как появились бесплатные и почти работающие. Как желание покупать китайский ширпотреб гробит местное производство, так желание использовать почти работающее бесплатное ПО гробит нормальное ПО. И когда оно действительно надо, готовых компонентов нет совсем.

всёж стоит полистать(достаточно даже первые страницы) Хенеси_Патерсона 2026(27)г редакция по ахертектуре нонешних компов(качественный подход) - многоядерность обусловленна в частности что интеграция продолжается (не так муровски но всёж) а частоты упёрлись в материал (частоты можно и в ренгеновские докрутить тока там совсем другие обвесы потребны и пока? экономика не срастается - возможно(моя имха) если датаценты запулять в орбиты округ солнца там и частоты смогут до десятков гигагерц(если это ваще понадобится) ) - крч Хенеси_Патерсон качественный подход - очень вменяемо базу декларируют

Реально все потребности пользователей были закрыты ещё пентиумом 3

Обратись к доктору, пока не поздно.

Видел этот тред на 27-ми страницах.

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

Столяров ходит на такие сайты через ффокс 76 или palemoon, он же писал

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

Видел этот тред на 27-ми страницах.

Но их же 14

Хуже отсутствием единообразия.

Ладно, а какие ты символы вводишь через эти несчастные альт-коды? Почти всё доступно с клавиатуры. Контрол-коды вводятся через Ctrl-V Ctrl-Letter например.

  │ .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
──┼────────────────────────────────────────────────
0.│ ^@ ^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M ^N ^O
1.│ ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z ^[ ^\ ^] ^^ ^_
2.│     !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /
3.│  0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?
4.│  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O
5.│  P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _
6.│  `  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o
7.│  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~ ^?
8.│  Ђ  Ѓ  ‚  ѓ  „  …  †  ‡  €  ‰  Љ  ‹  Њ  Ќ  Ћ  Џ
9.│  ђ  ‘  ’  “  ”  •  –  —  �  ™  љ  ›  њ  ќ  ћ  џ
A.│ NBS Ў  ў  Ј  ¤  Ґ  ¦  §  Ё  ©  Є  «  ¬ SHY ®  Ї
B.│  °  ±  І  і  ґ  µ  ¶  ·  ё  №  є  »  ј  Ѕ  ѕ  ї
C.│  А  Б  В  Г  Д  Е  Ж  З  И  Й  К  Л  М  Н  О  П
D.│  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Ъ  Ы  Ь  Э  Ю  Я
E.│  а  б  в  г  д  е  ж  з  и  й  к  л  м  н  о  п
F.│  р  с  т  у  ф  х  ц  ч  ш  щ  ъ  ы  ь  э  ю  я

если по 1к месаг итого меньшее

Если будет потом программировать, то будет программировать так, как научится.

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

Ладно, а какие ты символы вводишь через эти несчастные альт-коды?

« » – — 

Контрол-коды вводятся через Ctrl-V Ctrl-Letter например.

Ctrl-V = вставить из буфера.

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

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

А в компьютерных технологиях сплошь и рядом. Сначала из Emacs сделали ОС. Потом из Java серверный язык программирования. Теперь из браузера ОС делают с JavaScript в качестве ассемблера. Шифрование для обеспечения целостности сообщений (вместо подписи). Версионирование символом динамической библиотеки (вместо имени файла). Передача бинарных файлов через протокол передачи гипертекста или протокол удалённого управления (вместо протокола передачи файлов).

эффект безбилетника

паразитический payload

это всё очень биологично

почему в этой области настойчиво используют инструменты не по назначению

из хакерского интереса

Версионирование символом динамической библиотеки (вместо имени файла).

собственного имени файла может и не быть

из хакерского интереса

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

собственного имени файла может и не быть

Это как? У динамической библиотеки всегда есть имя файла.

Для Windows есть kbdasm (статья на хабре) по мощности почти эквивалентный Compose Key в полноценных ОС. Кроме того позволяет переключать раскладку CapsLock без установки дополнительного ПО.

Есть. Ради программы на Gtk системную раскладку клавиатуры ломать? По-моему, перебор.

P. S. Обход, конечно, есть: на уровне приложения отлавливать нажатие/отпускание Alt, но логичнее эту функцию выносить на уровень текстового виджета.

По-моему в некоторых версиях Gtk этот kbdasm всё равно не работает. Но ты проверь. И ломать не надо, просто копируешь в system32 и прописываешь в реестре, а потом выбираешь.