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

int mirror_right = (right / 10 + (right % 10) * 10);

if (left == mirror_right) {

puts(«Yes»);

} else {

puts(«No»);

}

Вот кстати альтернативная реализация этой штуки

if((left*10+99-right)%99==0 && number!=9900) 

На одно деление меньше, зато есть на одно вычитание и одно сравнение больше.

(left*10+99-right)%99==0

А как прибавление 99 может изменить остаток от деления на 99?

Так, что там не будет отрицательного числа. Впрочем, замечание верное. Поскольку тут нужна только проверка ноль - не ноль, можно 99 не прибавлять. А ещё я обычно всё в unsigned делаю, и привык проверять чтобы нигде ничего в минус не пыталось уйти.

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

Вообще, ерундой какой-то страдаете. Also cast liksys.

// Assumes 1000 <= n <= 9999.
bool ispal(uint32_t n)
{
    // n = <ABCD>

    // <AB> = n / 100
    uint32_t AB = (n * 5243) >> 19;

    // A = <AB> / 10
    uint32_t A = (AB * 52429) >> 19;

    // <CD> = n - 100<AB>
    // <BA> = 10(<AB> - 10A) + A = 10<AB> - 99A
    //
    // <CD> - <BA> = n - 110<AB> + 99<A>

    return n + 99 * A == 110 * AB;
}

Можно ещё быстрее: я уверен, что можно подобрать множители, чтобы корректно внести умножения на 99 и 100 в скобки до сдвига. Но тут уже нужны будут uint64_t.

Если ограничиться ТОЛЬКО Столяровым, то есть высокий риск это собеседование не пройти.

Вы недооцениваете масштаб катастрофы. Это не риск, это гарантия близкая к 100%. И часть идей которые он закладывает в неокрепшие мозги выкорчевать потом довольно сложно.

Какие именно? Придирка к терминологии побочных эффектов? Это на ней liksys помешался, а так ни на что не влияет.

И часть идей которые он закладывает в неокрепшие мозги выкорчевать потом довольно сложно.

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

Беды бы не было если только Столяров был бы секстнантом, подобно тому как чуть раньше почти все собеседующие пытали на тему триединства инкапсуляции_наследование_полиморфизм и не абы какой а только классовый прям эталоножаба, так и теперь есть модные вопросы и модные ответы откланиение от них классифицируется как неадекватность ;)

Какие именно?

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

Бд это мемоизация

Он не учит писать простой код, он не учит писать эффективный код, он не учит писать надёжный код, он не учит писать расширяемый код.

При всех вопросах к Столярову, это уже не выглядит справедливым. Он учит просто программированию абсолютных новичков в 1-м томе. Сначала Паскалю, потом ассемблеру. И вроде более-менее всё по делу, я там не заметил откровенных косяков с точки зрения написания кода.

Что там у него такого ужасного увидел? Претензия к Паскалю как первому языку - это уже не к умению писать код, а к методологии, причём вопрос спорный, есть доводы и за и против.

«вектор самый бесполезный контейнер»

Это же как нужно обдолбаться, чтобы такое заявлять. В его thalassa всё на связных списках. Но это же pointer chasing, крайне неэффективно.

Мне казалось, что моему мнению о нём падать уже некуда…

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

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

И вообще, вот что конкретно плохо? Где? Программа как есть будет работать? Будет. Выравнивание и тд — норм. Будет думать больше секунды — нет. Ну и чем не устраивает? Задачу он решает, выглядит не банально, а занятно. Кстати Столяров как раз против «головоломок» в коде. И я с ним согласен, если этот код потом требуется куда-то комиттить в продакшен. Но три переменные сравнивать — это не продакшн и можно чуток развлечься.

Он не учит практически ничему что действительно важно.

С чего ты взял?

продемонстрировали

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

Ну и «надёжный» код, где на каждый чих проверки теряет в читаемости. А толку от эти проверок тоже не особо много, что так код крашнется, что эдак, просто если ты сам напишешь writeln(ErrOutput, '...'); halt(1) ты выбираешь, что писать, а если нет, то компилятор.

Мне казалось, что моему мнению о нём падать уже некуда…

Страница 13 1го тома:

разумеется, дальше vector’а и list’а обучение никогда не заходит (как раз эти два контейнера, пожалуй, самые бесполезные из всего STL)

Вот оно как оказывается, мальчики и девочки :)

я уже умел программировать

Эвона как! Смело, очень смело…

Если ты такой крутой программист и умеешь программировать в 100500 раз лучше меня, зайди в тему, где я выкладывал код не в пять, а в ~300 строк и напиши какую-нибудь критику по существу. А то любой дурак может взять любой выложенный кем угодно пример кода и заявить, что он «говно» под надуманными основаниями, особенно если он решает задачки уровня «сравнить три числа»

Бд это мемоизация

Мемоизация — это прицепить к функции массив или словарь с уже вычисленными значениями аргументов. В некоторых рекуррентных последовательностях ускоряет вычисление результата на много порядков.

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

Если нет статических локальных переменных — можно на глобальной.

Что такое «абстракция»? (У нас такой вопрос был на экзамене по ООП)

Нет, внести множители нельзя. Они неизбежно испортят побитовое расположение информации в числе перед сдвигом.

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

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

Причём это мнение своё он аргументирует, а не просто высказывает.

Так можешь ответить, какую ОС ты используешь? Какой компилятор Pascal? Какой текстовый редактор или IDE? Мне интересно, а ты не ответил.

Так можешь ответить, какую ОС ты используешь? Какой компилятор Pascal? Какой текстовый редактор или IDE? Мне интересно, а ты не ответил.

Обычная ubuntu-26.04, free pascal compiler, текстовый редактор vim.

зайди в тему, где я выкладывал код не в пять, а в ~300 строк и напиши какую-нибудь критику по существу

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

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

Очень даже объективными, жаль что вы этого не понимаете.

особенно если он решает задачки уровня «сравнить три числа»

Дык, вы же и в этом (мягко говоря) обкакались.

история с goto - это эталонный пример отсутствия у существенной части преподавателей(и обучаемых) абстрактного мЫшленья

обобщение путём загрубления «несущественного» :)

ваще хайп с ООП(дело вообще не в плохости ООП - оно реально годное как некоторая частность структурного программирования а именно использование записей как атд с сокрытием{ну а наследование оказалось в классовом исполнение(в отличии от изначального прототипного) помесь динамики с компиляцией и показало что очередная серебряная пуля оказалось очередным змеиным маслом} пример вымывания матана из универа и замена на псевдоscience - если историю полистать можно обнаружить не такой массовый(индустрия была меньше) хайп именно со структурным программированием которое прошло вышло из моды под грузом накопившегося начётничества в образовательных учереждениях которое по сути не имело отношения к идеям выкристаллизованным Дейкстрой(Далом Хоаром..)

забавно что случившееся(смена мод в индустрии) не аберрация а полезная фича для постоянного движа

слу ну и паскаль не нужен достаточно 3рёх ленточной машины Тьюринга

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

Ты ) потерял.

$ echo '•••Твой пост <3-ий абзац>•••' | tr -cd '(){}'
({()}()()

Северанс начинает с питона

Всем был бы хорош питон как первый язык, если бы не был так хорош как непервый.

Взять последовательность обучения от Столярова: паскаль -> асемблер -> си -> си++ Но сам материал, где раскрывается предмет, брать других авторов. Каких? Тех, которых рекомендует большинство.

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

нулевым годен какаяйнить двухадресная(можно и иной арности - для любителей нуль) опкод на строку регистровая псевдомашина - чисто что бы при освоении hll была годная модель во что транслируются удобства

например через декораторы хорошо инструментализируется отлаживаемый метод/функция

даже в форте заменой поля внутреннего интерпретатора получаема декорация в Паскаль/Си подобное поведение(без модификации потрохов блока) возможно только через альтерацию транслятора

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

уровень знаний FreePascal, nasm для 32-разрядного linux на i386, Си начала 1990-х и C++ до стандартов?

Или конечная цель какая-то другая?

брать других авторов. Каких? Тех, которых рекомендует большинство.

Не думаете, что творчество этих авторов тоже может увести Ваши нейронные сети не в ту степь?

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

А каких, если не секрет? Я вот посмотрел ту книгу «Паскаль для школьника». Сразу не понравились комментарии на русском языке.

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

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

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

Вообще, задумался, что академичность академичностью, но новичку после изучения всех трёх томов Столярова с подзаголовком «Введение в профессию» (профессию) невозможно претендовать практически ни на какую вакансию! Хорошее такое введение получается. Материал вроде бы обширный, на его освоение с нуля запросто пара лет уйдёт, емнип, сам Столяров что-то про 2-3 года говорил. Допустим даже год, если интенсивно изучать. Но итог какой-то очень сомнительным выглядит.

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

невозможно претендовать практически ни на какую вакансию!

Почему это?

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

А кто запрещает? Введение в профессию даст фундамент. После этого трёхтомника можно легко и непринужденно изучить любой ЯП за пару вечеров, а дальше шлифовать тонкости.

Почему это?

А на какую вакансию? Паскаль, хотя я и спорил насчёт мёртвости, но практически очень мало нужен, C++ в докомитетском виде, как у Столярова и совремённый - это во многом разные языки и нужен совремённый, i386-й ассемблер даже без simd-инструкций - это только для ориентации, остальные языки у него бегло затронуты, да и те сильно далеки от мейнстрима как lisp, scheme, prolog, tcl/tk., GUI писать на FLTK (как и на Tk) ещё сильно поискать нужно. Максимум, что может всё же сразу пригодиться из даваемого Столяровым - это чистый C и немного знания ОС и сетей. Но это довольно узкие места, вроде разработки драйверов или эмбеддинга и новичков там не очень ждут.

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

Это что касается языков.

С задачами у него тоже низкая практическая ориентированность. Решая их новичок, кроме освоения языков и парадигм, из практического научится делать простые вещи в ncurses, немного GUI в FLTK и может самое полезное кое-какой работе с tcp/ip/udp сетями, сокетами и немного с ядром Linux. Может быть, всё же куда-то где пишут драйвера и сетевые штуки его и возьмут стажёром-джуном.

Введение в профессию даст фундамент.

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

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

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

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

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

С этим кто-то спорит? Хотя вполне можно новый открытый проект писать и на паскале и ничем особо не хуже сишки будет. Главный скилл — понимание 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 - это не столько свойства языка, сколько предпочтения автора. Хотя в принципе могут вылезти какие-то неочевидные косяки, если для работы одновремённо применять и потоки и си-шную работу с файлами, чего-нибудь там с синхронизациями потока программы и входного/выходного потока.

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

Xenius, liksys С другой стороны, мы вот тут покусали Столярова за некоторое ретроградство и манямирки, но всё путём сравнения познаётся.

Пошарился я на днях нечаяно в либгене по совремённым учебникам и брошюрам по обучению программированию и С и C++. Часто это неописуемо. В некоторых учебных пособиях, например у БелГУ, до сих пор похоже ориентируются на обучение Си в MS-DOS. Ничтоже сумняшеся пишут (автор Брусенцева) про 6 моделей памяти в языке Си, ну там tiny, small и прочая мсдосовщина лохматых годов. (Причём не понимая, что это не у Си модели памяти, а у компилятора для ms-dos). И тд. и тп., говорится. Какая там декомпозиция задачи с делением на Python и Си-часть...

Так выбор из двух стульев. Я бы предпочел в принципе гнать в шею стулогрелочных индивидов вон из преподавания.