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

Паскаль, хотя я и спорил насчёт мёртвости, но практически очень мало нужен

С этим кто-то спорит? Хотя вполне можно новый открытый проект писать и на паскале и ничем особо не хуже сишки будет. Главный скилл — понимание Pascal кода и это полезный скилл и на работе тоже. Например дадут задание: «вот у нас древний код на дельфи, а сейчас мы пилим замену на Qt, посмотри как было сделано там и сделай так же.» Будешь спорить, что это нужно? А времени это почти не тратит, так как основной акцент у Столярова во второй части первого тома на общие места императивных языков, а не нюансы паскаля. То есть оверхед примерно нулевой или даже отрицательный, если согласиться с тем, что освоить Pascal+указатели и потом C выйдет быстрее и качественней, чем сразу C с указателями. Если не согласен — пожалуйста, обосновывай, опровергай.

P.S. А ещё есть Algol — такая древняя латынь для записи алгоритмов. У меня есть бумажная книга по математике, но там приведены и алгоритмы и они записаны на Алголе. Я могу это прочитать и разобраться, потому что знаю Pascal и Bash, а те кто изучали сразу Python или C прочитать это не смогут!

i386-й ассемблер даже без simd-инструкций - это только для ориентации,

Главное в изучении ассемблера — это понять как работает то, что ты писал на паскале, изнутри. Если тебе нужен ассемблер - берёшь fasm manual, читаешь про x86_64 или берёшь мануал по risc-v, aarch64, avr, i8080 и тд и пишешь как хочешь. Я лично писал на i8080 без особых усилий, поскольку нужные нейронные связи у меня сформировались когда я изучал ассемблер 8086 (в универе было). То есть каждый программист должен написать хотя бы сколько-то кода на ЛЮБОМ ассемблере на этапе обучения. А потом перейти на любой другой ассемблер будет легко.

GUI писать на FLTK (как и на Tk) ещё сильно поискать нужно.

Главное в этом уроке — понимание ООП и event loop. Если оно есть, можешь писать хоть на FASM для KolibriOS, хоть на Qt хоть на Gtk, хоть на SDL. Пруф — посмотри мою статью. Заметь, что я никогда до этого не писал на SDL ни одной строчки. Только знал, что она нужна для игр, потому что для компиляции веснота и вообще почти всех свободных игр приходилось вначале ставить SDL. Если в мозгу есть понимание как это в принципе выглядит, то изучение любого конкретного инструмента - это вопрос небольшой практики.

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

Когда мне понадобилось написать плагин для KWrite (а там только JS), который корректировал подсветку синтаксиса Tcl я это сделал за один день, хотя до этого на JS ничего не писал. Когда мне понадобилось написать программу для решения школьной задачи на Python3 — я тоже взял и написал, хотя Python особо не изучал. Если есть база, которую как раз трёхтомник и даёт, по идее, можешь писать на любом ЯП через полчаса после того как узнал про его существование (особенно если пользоваться нейронкой, которой говоришь «как мне на Python сделать for-loop», она пример кода, ты не копипастишь, а просто смотришь как сделано и пишешь своё. Потом так же «а как мне перевести число в строку?» — просто мгновенный поисковик. Но можно и без нейронки, просто грепом по мануалу, просто будет чуть медленней).

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

нужно владение экосистемой (ещё один нелюбимый им термин) вокруг ЯП.

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

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

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

каждый программист должен написать хотя бы сколько-то кода на ЛЮБОМ ассемблере

и абы как?

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

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

Главное в изучении ассемблера — это понять как работает то, что ты писал на паскале, изнутри.

В основном с этой целью Столяров и приводит ассемблер, при этом совершенно справедливо проехавшись по замшелым преподам, которые до сих пор (условно на начало 2010-х по тексту) читают 16-ти битный асм для ms-dos. (Ранее проехался про маразм с преподаванием стандартного Паскаля с практикой в TP под MS-DOS)

Во втором семестре (речь про ВМК МГУ - прим.) дела обстоят немногим лучше. До недавнего времени язык ассемблера демонстрировался тоже под MS-DOS, то есть изучалась система команд 16-битных процессоров Intel (8086 и 80286). Программирование под заведомо мёртвую систему расхолаживало студентов, культивировало презрительное отношение к предмету, и это отношение часто переносилось на преподавателей.

Очень хорошо, что Столяров в книге ассемблер базирует на i386 под вполне живой NASM и FASM, но сейчас уже 2026-й год и система команд i386 движется в том же направлении. Оно конечно, в силу особенностей архитектуры amd64 и ОС всё ещё можно компилировать программы под 32-битный код в 64-битных линуксах и виндах и исполнять их, но не грех было бы и переписать с учётом того, что 64-битная архитектура давно стандарт, а практическая польза от ассемблера не только в представлении во что компилятор превращает программы, но и в применении SIMD-инструкций, для чего даже механизм интринсиков фактически придумали.

Когда мне понадобилось написать программу для решения школьной задачи на Python3 — я тоже взял и написал, хотя Python особо не изучал. Если есть база, которую как раз трёхтомник и даёт, по идее, можешь писать на любом ЯП через полчаса после того как узнал про его существование

Школьных задач может и можно, но сколько-то реальное программирование потребует совсем не получаса. У того же Python есть свои особенности применения и практические приёмы. Например, так-то Python - весьма тормозной язык и если писать в лоб, замедление, по сравнению с C/C++, может достигать нескольких тысяч, но существуют приёмы, позволяющие на практических задачах почти не замедляться, в том числе, если нужно, даже написав критическую часть на Си, зато Python позволяет во многих ситуациях писать программы, не тратя время на рутину и экономя время программиста. Ноутбуки Python - это вообще очень удобное средство для быстрого прототипирования, когда можно на лету писать код и смотреть, что получается. И не просто код, а тут же выводить содержимое таблиц, строить графики, проигрывать звуковые и видео файлы (или содержимое памяти). Ещё и оформляя вокруг с комментариями в markdown-разметке, с добавлением иллюстраций и математических формул.

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

В итоге он всё же заметно заглубляется, но в довольно специфическом виде экосистемы чистого Си (ещё и в C89/90 варианте) с ассемблерными вставками, TCL/Tk, FLTK и сокетами/сетью. И это оказывается, наверное, единственной сферой, где новичок после его книг может всё-таки попробовать найти вакансию. Проблема в том, что там сейчас обычно уже совсем не новичковый уровень требуется.

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

Да, в этом смысле у Столярова получилась довольно-таки уникальная вещь. Тем обиднее, что эта вещь имеет недостатки, которые рискуют её вообще похоронить в итоге. Модернизировать надо текст и поменьше сектантствовать. В некоторых аспектах ведь близко к маразму уже. Давая студентам докомитетсткий C++ без шаблонов и STL он уже мало чем отличается от тех, кого сам же раскритиовал за мертвечину. А рассуждения про малополезность многоядерных процессоров и вовсе выглядят дико, даже приправленные у него законом Амдала. Он тут раскрывается как теоретизатор без практики.

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

1) Peter Van Roy, Seif Haridi. «Concepts, Techniques, and Models of Computer Programming» - https://webperso.info.ucl.ac.be/~pvr/VanRoyHaridi2003-book.pdf

К сожалению, видимо более новых изданий с 2003-2004-го года у неё нет или я не заметил их наличия. Кроме того, представляя собой введение в концепты и парадигмы программирования, упоминая самые разные языки, она не учит конкретно-практическому программированию, т.к. примеры в ней предназначены для исполнения в некоей «Mozart system»

2) Как ни покажется странным, но книга Бьярна нашего Страуструпа «Programming Principles and Practice Using C++» (не путать с его книгой по языку C++). В ней автор последовательно учит именно, что принципам программирования. Конечно с C++, но упоминая и другие языки и между прочим, в том числе с использованием FLTK и некоторых других фреймворков. Книга при этом ориентирована явно на Windows и Visual Studio.

Резюмируя: главные претензии к книге (курсу), что 1) автор не считает даже за ошибки некоторые явные маразмы в нем, 2) что книги уже существенно в ряде аспектов устарели, вплоть до того, что условно в 2006-м году (если бы тогда вышли) можно было бы легко найти работу только после их изучения, в 2016-м (1-е издание) - уже с трудом и сейчас в 2026-м они начинают выглядеть отсталыми. Важно, что сама по себе ориентация на базу и теорию великая вещь, например, даже 1-е издание книг Кнута (конец 60-х - начало 70-х) очень полезная и сейчас вещь, но вот только не следует и никогда не следовало воспринимать Кнута как введение в профессию. 3) вытекает из 2-го, что для базово-теоретического курса Столяров многие существенные вопросы оставил вообще неосвещёнными.

при этом совершенно справедливо проехавшись по замшелым преподам, которые до сих пор (условно на начало 2010-х по тексту) читают 16-ти битный асм для ms-dos.

А я не совсем согласен кстати. Я изучал как раз 16-битный асм и даже настолько заинтересовался, что пытался написать свою «ОС», качал Ralf Brown’s Interrupts List и и тд. Там довольно забавная модель с сегментами. В общем меня «мёртвость» не остановила. Наоборот я вообще перешел на i8080.

Python позволяет во многих ситуациях писать программы, не тратя время на рутину и экономя время программиста.

А Tcl не позволяет? Он так-то пошустрее. А если LuaJIT так и вообще, но мне Lua не нравится.

В итоге он всё же заметно заглубляется, но в довольно специфическом виде экосистемы чистого Си (ещё и в C89/90 варианте) с ассемблерными вставками, TCL/Tk, FLTK и сокетами/сетью

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

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

Я изучал как раз 16-битный асм и даже настолько заинтересовался, что пытался написать свою «ОС», качал Ralf Brown’s Interrupts List и и тд. Там довольно забавная модель с сегментами. В общем меня «мёртвость» не остановила. Наоборот я вообще перешел на i8080.

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

А Tcl не позволяет? Он так-то пошустрее. А если LuaJIT так и вообще, но мне Lua не нравится.

У Tcl слабая поддержка сложных структур данных. Кроме того, для Python разработано огромное количество пактетов для веб-разработки, Data Science, анализу данных, машинному обучению, есть биндинги к GUI тулкитам (PyQt, PyGObject и к любимому Столяровым FLTK - pyFLTK) и мало найдётся под что нет нужного пакета. Причём такое богатство не появилось бы, если бы разработчикам Python не казался удобным. Минус Python в этом же разнообразии: есть проблема ада зависимостей у этих пакетов, в результате совершенно нормально наплодить у себя кучу отдельных виртуальных окружение venv или conda ещё и с разными версиями самого Python.

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

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

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

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

Ну ntvdm не был прямо таким уж эмулятором как DOSbox, а все компы начинали запускаться с 16-битного кода. Может в этом дело конечно.

У Tcl слабая поддержка сложных структур данных.

Да ладно?

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

Не знаю, не знаю. По-моему введение в программирование особо не меняется не то что с 2016, но и вообще с 1970-х годов — уже тогда почти все основные используемые сейчас ЯП, то есть Lisp, C, Pascal, Basic, Fortran, Forth, ООП придумали и тд. По-моему из кардинально нового за всё это время появилась только ИИшница. И то всякие перцептроны начали изобретать уже тогда.

Ну ntvdm не был прямо таким уж эмулятором как DOSbox, а все компы начинали запускаться с 16-битного кода. Может в этом дело конечно.

На 32-битной винде, в 64-х битной архитектура x86_64 не позволяет иметь ntvdm (т.е. это не искусственное ограничение, просто убрали виртуальный 8086, который был с 386-го процессора), впрочем на начало 2010-х ещё далеко не все использовали 64-битные ОС. Где-то внутри UEFI и сейчас компы с 16-ти битного кода запускаются. В любом случае 16-битный ASM стал сильно нишевой технологией, тут я со Столяровым согласен, что он использовал более совремённый 32-битный. Не согласен, что и сейчас использует: было бы неплохо использовать 64-битный и дать понятие об simd-инструкциях, особенно AVX, AVX2, AVX512 и интринсиках.

Да ладно?

Cписки, ссылающиеся сами на себя. Циклические графы. Множества set с проверкой уникальности за O(1). Кроме того, yield. Объекты-итераторы в Python лениво вычисляют список, а в Tcl, вроде как объект сразу в памяти целиком должен быть.

По-моему введение в программирование особо не меняется не то что с 2016, но и вообще с 1970-х годов — уже тогда почти все основные используемые сейчас ЯП, то есть Lisp, C, Pascal, Basic, Fortran, Forth, ООП придумали и тд.

Основные языки сейчас - это Javascript, Python, Go, C#, Java, C++ . Ещё SQL. И ещё языки разметки Json, XML (уже подустарел), HTML+CSS, yaml. Ничто из этого, фактически не освещено у Столярова, даже С++ в слишком старом виде. Кроме того, важнейшей технологией сейчас является умение писать параллельный/асинхронный код, в том числе с использованием библиотек для параллелизации вроде OpenMP, распараллеливания с использованием SIMD-инструкций (это то, где компиляторы пока не очень хорошо справляются) и с использованием GPGPU.

Мало того, почти всё из этого удостоено ругани с его стороны, если не в книге, то где-то ещё показывая его позицию: он и не станет о подобных вещах писать. Про параллельное программирование всё же написал главу, но только про fork и pthread и оговорив его малоприменимость на практике и с лулзами про малополезность многоядерных процессоров. Может быть язык Си ещё можно считать основным, но у него относительно узкая ниша применения, в отличие от остальных.

Ещё из практического программирования сейчас важно, кроме работы с системами контроля версий (про git Столяров немного пишет в 3-м томе) хотя бы минимальное знание докера.

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

Так что с 70-х годов введение в программирование сильно изменилось.

хотя бы минимальное знание докера.

Ну а зачем это в книге по программированию? Ну и у меня вот нет этого знания docker. Но я так понимаю, это просто костыль чтобы команду chroot не писать? И зачем мне его знать? Понадобится — почитаю man docker.

Вот chroot я пользовался. У меня ноутбук с android на арм-процессоре. Я там распаковал архив с полноценным дистром и делал туда chroot чтобы получить аналог termux, которого тогда ещё не было вроде.

Про параллельное программирование всё же написал главу, но только про fork и pthread и оговорив его малоприменимость на практике

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

Ещё SQL. И ещё языки разметки Json, XML (уже подустарел), HTML+CSS, yaml. Ничто из этого, фактически не освещено у Столярова

А это и не программирование.

Основные языки сейчас - это Javascript, Python, Go, C#, Java, C++ .

Javascript — кошмар. Зачем на нём писать? А читать можно зная C.

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

C# и Java — а они ещё не умерли? Это в 90-х и ранних 2000-х был тренд. А сейчас-то зачем?

Go — и чем он лучше ну хотя бы D?

C++ — есть ли необходимость использовать то, что Столярову не нравится? Или всё-таки его подмножество достаточно неплохое?

Cписки, ссылающиеся сами на себя. Циклические графы. Множества set с проверкой уникальности за O(1). Кроме того, yield.

yield точно есть: coroutine, yield, yieldto - Create and produce values from coroutines`` — изman n yield`

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

Не согласен, что и сейчас использует: было бы неплохо использовать 64-битный и дать понятие об simd-инструкциях, особенно AVX, AVX2, AVX512 и интринсиках.

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

Ну а зачем это в книге по программированию?

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

Но я так понимаю, это просто костыль чтобы команду chroot не писать?

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

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

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

Готовые библиотеки, вроде OpenMP использует многопоточную модель параллельности. Например:

   // Директива OpenMP для распараллеливания цикла
    #pragma omp parallel for
    for(int i = 0; i < n; i++) {
        c[i] = a[i] + b[i];
    }

А что по Столярову надо тут заморочиться с раскидыванием цикла по разным процессам с fork() и execv()? Оно ещё и тормозить будет, лишние копирования производить. И вот какой парадокс: отдаю ему должное, что в главе про параллельные вычисления он кое-что написал, чего я не знал и с интересом у него почерпнул новое, но при этом ему не пришло в голову, где ещё, кроме GUI будет нормальным выбором мультипоточность.

А это и не программирование.

Языки разметки формально не программирование, но это важная часть профессии.

Javascript — кошмар. Зачем на нём писать? А читать можно зная C.

От Си там только синтаксис, концептуально js - это диалект лиспа Scheme. Именно Scheme хотел запилить в браузере Netscape Брендан Эйх, но руководство Sun и Netscape настояли, чтобы язык выглядел как младший брат Java. Эйху приказали отбросить синтаксис Scheme с его обилием круглых скобок и спешно натянуть на язык синтаксис в стиле Java/C (с фигурными скобками, точкой с запятой и ключевыми словами). Буквально за 10 дней он разработал в итоге Javascript. Ещё от какого-то другого языка он воткнул ООП, в итоге такой вот франкенштейн вышел.

Python — мне не нравится.

Вопрос не в нравится/не нравится, а что это язык, с которым сейчас сталкивается практически любой программист. Когда-то в такой роли был Basic и даже Pascal.

C# и Java — а они ещё не умерли?

Чего это они умирать должны? Одни из самых распространённых языков и платформ, за ними стоящими с кучей вакансий. Java и Kotlin (диалект Java) - основные языки для программирования мобильных приложений в Androd, основные языки для вообще всякой корпоративной разработки везде. C# и .Net более внутри Windows экосистемы сосредоточены, но и в Linux неплохо себя чувствуют.

Go — и чем он лучше ну хотя бы D?

Тем, что на Go кучи вакансий, а вот про D ещё не все слышали.

C++ — есть ли необходимость использовать то, что Столярову не нравится? Или всё-таки его подмножество достаточно неплохое?

Оно может и неплохое, но у Столярова - это фактически Си с классами без STL. А совремённый C++, кроме привычного использования STL, стоит считать чуть ли не другим языком вообще. C++ можно разделить на классический С++ вплоть до версии C++03 и совремённый, начиная с C++11. И совсем совремённый с C++20. Появилась куча всякого разного (на что он ругается), которая не просто добавление возможностей, о которых можно прочитать в справке, но всё это меняет стиль написания программ на C++. rvalue-ссылки && и std::move. smart pointers поменяли приёмы работы с памятью. Лямбды, for по диапазону в контейнере, нативная поддержка тредов (мультипоточность), и много чего ещё.

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

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

В целом, это не моё предпочтение Javascript, Python, Go, C#, Java, совремённый C++, а констатация факта, что основные языки сейчас вовсе не те, что были в 70-х, не те, что в 80-90-е и даже не совсем то, что в нулевые было.

yield точно есть: coroutine, yield, yieldto - Create and produce values from coroutines`` — изman n yield`

Тут не буду спорить, я не очень знаю Tcl, может ты тут и прав.

А остальные извращения точно нужны?

Они используются.

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

SIMD вообще и AVX в частности - это сейчас не экзотика, а то во что при оптимизации часто компилирует код совремённый компилятор. И вообще, у него в части про ассемблер есть параграф про работу с числами с плавающей запятой, в котором он рассказывает о работе и командах x87 FPU. Опять же нравится или нет, но x87 с появлением архитектуры x86_64 стал легаси, deprecated, а фактически ещё с появлением SSE2. x87-й код работает медленнее. Причём, если в Linux ещё возможно использовать x87-й код, то в 64-битной винде - нет из-за особенностей её ABI.

Фактически есть только одна причина его использовать в некоторых ситуациях: если не хватает 64-битной точности типа double, у x87 есть 80-битный нестандартный, не описанный в IEEE-754 тип (на момент появления процессора 8087 стандарта ещё не существовало). Но и то, эмуляция даже не 80-ти битного типа, а 128 битного (long double) с помощью AVX2 будет быстрее, если код удастся векторизовать (простые скалярные операции над 128 битами скорее всего окажутся медленнее).

Мне кажется, что если речь идёт именно о профессии, автор учебника обязан был хотя бы в примечании рассказать об этом. По-хорошему бы даже про aarch64 ассемблер вкратце упомянуть, тем более, что в нём имеются схожие simd-инструкции, в которые компилятор старается векторизовать код.

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

А кто мешает самому про это прочитать?

Понятно, что Столяров не потянет вообще про всё рассказывать, но введение в профессию определённо, на мой взгляд, стоило бы модернизировать, приблизив к совремённым реалиям. Хотя бы согласиться, что надо.

но x87 с появлением архитектуры x86_64 стал легаси, deprecated, а фактически ещё с появлением SSE2. x87-й код работает медленнее. Причём, если в Linux ещё возможно использовать x87-й код, то в 64-битной винде - нет из-за особенностей её ABI.

Я тут слегка косноязычно выразился. x87 не является deprecated в том смысле, чтобы были планы отказаться от него, но оставлен фактически только для обратной совместимости и схемы/микрокод CPU не оптимизируются на скорость работы x87 . x87 в 64-х битной винде тоже можно, но не в msvc, например, в MinGW можно, хотя есть ряд ограничений, связанных как раз с ABI: хотя при переключении задач контекст сохраняется, но вызов в программе любой внешней функции может испортить стек FPU.

Затем, что книга называется «Программирование: введение в профессию», а не просто программирование.

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

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

А нормально это разве сделать нельзя, без собственно docker? Кажется в BSD была firejail, это примерно то же самое по описанию. Ну и кстати, пользователи же в /etc/passwd, а он при chroot заменится, то есть свои пользователи будут и у chroot.

Готовые библиотеки, вроде OpenMP использует многопоточную модель параллельности. Например:

Хм, что всё так просто, обычный код пишешь и расставляешь прагмы? А как же всякие семафоры и атомарные операции?

Языки разметки формально не программирование, но это важная часть профессии.

Но у него же есть книга про LaTeX, так что языки разметки он тоже закрыл. Но я считаю, что осилить HTML можно и без жирного тома. Сложность-то в фундаментальных понятиях, вроде рекурсии, указателей, функциональных операторов. А писать трёхтомник для «программиста на bbcode» — это избыточно

Они используются.

А для чего?

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

Не думаю. По-моему именно введение не устаревает. А те темы которые он покрывает — VCS, gdb в любом случае пригодятся любому программисту, тогда как всё что ты перечислил заведомо или пригодится не любому или легко изучить и без книги.

Что касается C, я помню, что в универе показывали кажется cin/cout, а у Столярова даже на C++ используются printf/scanf или что там. Как по-твоему, как лучше на C++, проверенная временем libc или сомнительная std от C++?

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

Возникает вопрос, что входит в минималку, а что нет. Системы контроля версий у Столярова входят. Механизмы развёртывания приложений - нет. Может и правильно, но я просто вижу на практике, что 10 лет назад (1-е издание) про докер мало кто слышал и его не спрашивали на собеседованиях. 5 лет назад он уже стал широко распространённым, а сейчас его спрашивают похоже везде. И вопрос уже стоит не о том хорошая это технология или нет и как можно без него обойтись, а когда его изучать? По книге или потом самостоятельно.

Хм, что всё так просто, обычный код пишешь и расставляешь прагмы? А как же всякие семафоры и атомарные операции?

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

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

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

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

Но у него же есть книга про LaTeX, так что языки разметки он тоже закрыл. Но я считаю, что осилить HTML можно и без жирного тома. Сложность-то в фундаментальных понятиях, вроде рекурсии, указателей, функциональных операторов. А писать трёхтомник для «программиста на bbcode» — это избыточно

Языки разметки, вроде XML или JSON - это не столько про bbcode или даже LaTeX, сколько про способ записи данных, их валидацию по формальным шаблонам на соответствие правилам, и приёмы работы с ними. Например, для XML для его валидации существуют язфки описаний шаблонов данных XSD (который сам по себе тоже XML), DTD (исторически первый, корни с 60-х годов) и некоторые другие расширения и новшества. Для работы с ним есть разные правила и специфические языки, вроде выражений XPath и XSL.

А для чего?

Связанные списки для чего используются?

Не думаю. По-моему именно введение не устаревает.

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

Как по-твоему, как лучше на C++, проверенная временем libc или сомнительная std от C++?

По моему, неважно. Хочет Столяров использовать в С++ в ходе обучения stdio вместо iostream - большой разницы нет. cin/cout или printf/scanf - это не столько свойства языка, сколько предпочтения автора. Хотя в принципе могут вылезти какие-то неочевидные косяки, если для работы одновремённо применять и потоки и си-шную работу с файлами, чего-нибудь там с синхронизациями потока программы и входного/выходного потока.