Андрей Викторович Столяров: сайт автора

Ну да, всё верно. Там же в тексте ответ есть, у вас он сошёлся.

Вот только я совершенно не понимаю, что такое "сняв 2 кубика с 5 этажной башни - решение будет неправильным". Смотря как снимать. Два кубика (какие бы они ни были) -- это две комбинации (один на другом, или наоборот). Следовательно, когда сначала было сколько-то башен из пяти кубиков, а потом мы два сняли -- каждые две башни (до этого момента разные) станут одинаковыми. То есть нужно то, что было, поделить на два. Что мы и имеем: если 120 пополам поделить, то получится 60, и это верно -- действительно башен из трёх кубиков 60.

P.S. Ну вот зачем в архивную страницу-то оставлять комментарий? Тут их и так 500 с лишним, зря я, что-ли, гостевую очистил

BF полон по Тьюрингу; более того, относится к т.н. "тьюринговским трясинам", которые, несмотря на полноту, синтаксически скудны настолько, что ничего реально полезного на них сотворить практически невозможно. Больше этот язык с фамилией Тьюринга ничего не связывает.

является ли эта штука частным случаем машины Тьюринга?

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

Во-первых, и в-главных, никакие символы, не входящие в ASCII, не должны появляться в тексте программы — никакие, никогда, ни при каких условиях, даже в комментариях, а уж в литералах — тем более. Комментировать вашу околокодировочную ахинею я смысла не вижу,там всё довольно очевидно, но если для вас не очевидно — то какого чёрта вы пытаетесь изучать Си++? Ах да, на всякий случай: в gcc тип char по умолчанию знаковый. Если всё ещё неясно, почему получилось -39, то, видимо, вам вообще не стоит программировать.

Что касается типа константы, то разница демонстрируется вот таким кодом (естественно, это Си++, в чистом Си нет перегрузки функций):

#include <stdio.h>
void pr(char c)
{
    printf("CHAR %d\n", c);
}
void pr(int i)
{
    printf("INT %d\n", i);
}
int main()
{
    pr('1');
    pr(49);
    return 0;
}

Эта штука печатает

CHAR 49
INT 49

Между прочим, вы, случайно, не тот же персонаж, который, например, вот этот коммент http://www.stolyarov.info/guestbook#comment-2855 оставлял? Если вдруг да (а по стилю похоже), что что было непонятно в моём ответе?

1) однозначно VPS, причём самого-самого начального, слабенького, еле живого уровня -- оно дешевле, а для почты никакие практически ресурсы не нужны, она не жрёт ничего; и без всяких plesk'ов и прочих "пультов управления", справитесь командной строкой. Из примочек разве что backup взять, если он в базовую стоимость не входит.

2) я всегда использую postfix, он прост как валенок и надёжен как шар из чугуна

3) от доменов .su и .ru держитесь подальше, ну а .рф вообще не стоит рассматривать, почта на такие не ходила, не ходит и ходить не будет; что до регистраторов (естественно, тоже исключительно зарубежных, про российских даже и не думайте) -- я в последнее время много их перебрал, и у всех свои "приколы", приличных среди них нет вообще, либо у них сайт макаки писали, либо спамят, либо дорогие слишком, ну в общем все какие-то мерзкие. Нормальных я не видел. Точнее, когда-то видел, но они скурвились давно. Но, к счастью, с этими козлами дела иметь приходится не так уж часто.

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

А что насчёт ASCII? [...] Тоже фигня?

Ёлки-палки, да это даже не фигня, это намного хуже. Это сейчас мы набор символов ASCII воспринимаем как некую данность, потому что привыкли. А теперь мысленно перенесёмся в 1963 год. Компьютеры в те времена были большие и вообще их почти не было, вопросами компьютерных кодировок люди всерьёз начали интересоваться намного позже. Так что только телетайпы. Опять же, до всеобщей победы восьмибитного байта над другими вариантами разрядности — ещё лет двадцать. Большинство языков программирования, которые мы изучаем сегодня, ещё не появились даже в виде замысла в глубинах мозга их создателей. Чистый лист.

И вот смотрим, что такое представляет собой ASCII, если рассматривать его с чистого листа. Ну хорошо, алфавит заглавных и алфавит строчных — допустим, понятно. Плюс циферки. Уже 62 символа. Нужно явно больше. И нужна, похоже, степень двойки, это люди уже поняли, цифровая электроника (пусть пока и не компьютеры в нынешнем понимании этого слова) уже используется, да даже если бы и не, то дырка в перфоленте может быть либо пробита, либо нет, вот вам ноль с единицей. В 64 не уложились, следующая степень 128. Логично получаем семь бит. С этим понятно.

Ноль (ни одной дырки не пробито) и RUBOUT (пробиты все, код 127 -- в те времена так "выбивали" неправильно пробитые символы) имеют специальный смысл, с этим тоже всё логично. Вот только логика на этом, если подумать, заканчивается.

Ещё раз, ну буквы (те и другие), цифры — понятно. Знаки препинания: точка, запятая, двоеточие, точка с запятой, вопросительный и восклицательный знак, круглые скобки. Тоже можно согласиться. Апостроф — ну, куда ж в английском без апострофа. Двойная кавычка (не два парных символа кавычек, а одна двойная кавычка, позже ставшая "программистской") — странно, но можно перетерпеть. Арифметика: плюс, минус, дробная черта, больше, меньше, равно. Знаки доллара и процента — допустим, ладно. Ну хорошо, квадратные скобки, хотя это уже ОЧЕНЬ странно.

Но вот дальше начинается просто какой-то угар. Третья пара скобок (фигурные), но так и нет парных кавычек. Решётка и звёздочка (нет, никто не собирался звёздочку делать знаком умножения; но как раз знака умножения — точки, располагающейся в середине по высоте строки — комитет не предусмотрел). Амперсанд (?!). Тильда (?!!). Крышка, которая grave ^ — боже, что они курили. Обратный апостроф (?!!!!!). Обратный слэш (уже рука устала восклицательные знаки рисовать). Вертикальная черта. Знак подчёркивания (это сейчас мы к нему привыкли, а тогда?) "Коммерческое а" (@). Ёшкин кот, это всё вообще о чём?

Дальше управляющие символы. Ну, пробел понятно, он и не совсем управляющий. А вот из кодов 0--31 осмысленных раз два и обчёлся: ну с нулём понятно, CR и LF тоже понятно (мы же телетайпом управляем), BS (backspace), TAB... э.... ну ладно, допустим. Можно ещё понять BEL (звонок; ну да, на телетайпах был звонок). И даже, пожалуй, FF (form feed, в просторечии "выплюнуть лист бумаги"). В своё время я на матричных принтерах этот код сам использовал. Ну и ESC. Итого восемь кодов из 32. Остальные ну вот то есть просто нахрен не нужны, только место в таблице занимают. А места-то явный дефицит, между прочим. Ладно что нет никакого "длинного тире", хотя могло бы быть даже в моноширинной ситуации (например, дефису/минусу урезать по боками пиксели, а длинное тире сделать во всю ширину знакоместа). Нету, как я уже несколько раз повторял, парных кавычек. Диакритических знаков нет, хотя уж это можно бы было догадаться, что вообще-то нужно, и для телетайпов реализуется элементарно: буква, возврат назад на знакоместо, печать диакритики. Но нет.

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

Но они зачем-то полезли в область "забавных картинок"

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

P.S. в интернете есть много других сайтов, этот не единственный. Идите там пофлеймите, что вы сюда-то припёрлись?

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

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

Вы не могли бы продублировать своё письмо? Можно ещё тут в комментах (вот прямо ответом на этот мой комментарий) сообщить, когда/сколько переводили, как Вас упомянуть в списке пожертвований и -- желательно -- на какой адрес Вам послать подтверждение (ибо комментарий я, естественно, оставлю скрытым, публично обсуждать конкретику одного пожертвования было бы странно). Ну, или можно будет рассматривать в качестве подтверждения появление пожертвования в списке.

UPD: Всё в порядке, Ваше пожертвование получено, в списке отражено, я Вам на почту написал, но не знаю, дойдёт или нет (мало ли).

> приходит человек к нотариусу

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

> у человека болезнь Альцгеймера

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

Как действующий программист, который по большей части пишет на С++ и bash, хочу заявить, что это не нужно использовать, потому что код с STL очень трудно отлаживать.
Расскажу такой реальный случай: при реализации определенного функционала решено было( не мною, а архитектором ) использовать boost::optional. Но спустя два дня после тестировния вылез баг, который правили дня 3. А почему? Потому что обнаружили такое удивительное свойство у этого опшинола, который не смог ответить ни гугл, никто либо ещё. А именно: нельзя присваивать переменной опшинал через memset. Потерянные три дня - очень много. Иными словами, все эти эстээли - один сплошной чёрный ящик, который можно познавать годами. Намного проще с нуля это всё создать аккуратно, и в случаи необходимости добавлять дополнительные возможности. Тем самым вы не только время сэкономите, но и свои нервы. Причём ни то, ни другое не вернёт никто и ничто.

Здесь слишком много вопросов (причём из структуры заданных вопросов не очевидно, что их тут на самом деле намного больше), и ответов на них требуется тоже до фига. «Почему нельзя использовать STL» — это на самом деле:

• почему неприемлемы технические стандарты просто как идея, вообще любые
• почему неприемлемо включать что попало в "стандартную библиотеку" любого языка, даже если на этот язык нет никакого стандарта
• почему вообще не должно быть никакой "стандартной" библиотеки, т.е. никакие библиотеки не должны иметь особого статуса в сравнении с другими
• почему неприемлема библиотека STL, даже если бы она по-прежнему называлась, как это изначально было, "STepanov's Library" и не была стандартной ни в том, ни в другом смысле, и даже если бы сама идея контейнерных классов была сколько-нибудь допустимой
• почему нельзя использовать контейнерные классы, даже если они свои собственные
• почему нельзя использовать шаблоны для построения "обобщённых" структур данных (шаблоны сами по себе использовать в программах можно, но не для этого)
• почему нельзя — категорически! — иметь никаких реализаций "массива вообще", "списка вообще", "стека вообще", "очереди вообще", "дерева вообще" и тому подобного, даже если для этого не используются ни шаблоны, ни классы
• ... наверняка ещё что-нибудь упустил.

Если кратко — да, все структуры данных только руками. Никаких контейнерных классов, никаких контейнеров, даже если это не классы, никаких шаблонов (точнее, никаких шаблонов для создания контейнеров, так-то шаблоны штука хорошая), и НИКАКИХ вообще средств из std::, никогда, ни для чего, даже если это всего лишь iostream, — коготок увяз, всей птичке пропасть. А вот "почему" -- это в формат коммента не уложится.

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

Понятие "придётся" к квалифицированным программистам неприменимо в принципе. При имеющихся раскладах на рынке труда программисты сами выбирают, где им работать.

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

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

Во-вторых, "в Posix так написано" — это и для меня не аргумент. Это вообще не аргумент. Мало ли чего где написано, на заборах вон тоже пишут.

В-третьих, не надо использовать такой редактор текстов, который в конце не ставит перевод строки. А если всё-таки используете (например, Joe этим славится) — не забывайте проверить, что сами этот Enter нажали где надо. Потому что корректный текстовый файл состоит из законченных строк, то есть в нём каждая строка, включая последнюю, должна завершаться символом перевода строки. И это безотносительно всевозможных позиксов и прочих хренозиксов.

В-четвёртых, вот чего я категорически не понимаю, так это при чём тут cat.

Мне это самому интересно :(

В общем случае побочные эффекты увеличивают сложность восприятия программы, превращая отдельные её фрагменты в ребусы, которые требуется разгадывать. Больше того, вообще побочный эффект как явление противоречит привычкам условного новичка, мышление которого ещё не изогнулось под программистские реалии. Дело тут в том, что с математикой (и, соответственно, с выражениями) люди сталкиваются обычно раньше, чем с программированием, так что от выражения как-то так подсознательно не ожидают, что оно начнёт себя как-то вести, вместо того чтобы просто превратиться в значение. С восприятием условных выражений в заголовках ветвлений и циклов всё ещё хуже: весь наш опыт, включающий раннее знакомство с алгоритмами вне программирования, просто-таки восстаёт против каких бы то ни было побочных эффектов в них, ведь там же просто сравнение. Вот это вот "просто сравнение" в мозгу может засесть настолько прочно, что люди вообще не могут в заголовке if или while написать что-то отличное от сравнения — вызывают, к примеру, логическую функцию, а результат её, вместо того чтобы просто оставить как есть, сравнивают с true. А любые проявления когнитивного диссонанса отнюдь не способствуют комфортности чтения кода.

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

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

Откуда вы вообще взяли такую хрень, а? Или даже так: как вообще, из какого места, каким образом в голову могла прийти такая бредятина?!

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

Судя по тому, какая ерунда у вас тут возникла, вы к Си++ приступили слишком рано. Бросайте это дохлое занятие и начинайте с азов -- Паскаль, язык ассемблера, чистый Си, причём именно в такой последовательности. И пока не напишете самостоятельно хотя бы одну или две программы объёмом в 2-3 тысячи строк каждая, причём такие, которые будет (добровольно!!! а не по вашей слёзной просьбе) использовать кто-то кроме вас -- даже не думайте о том, чтобы вернуться к изучению Си++. Если же такая рекомендация вам не нравится -- то идите ищите другого советчика.

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

С добавлением const к операции как раз всё понятно -- операции допускается перегружать по признаку константности аргумента. Далее, если из заголовка операции, которая метод класса, убрать const -- то её параметром уже нельзя будет делать временный/анонимный объект, так что она оказывается не у дел при вызове, требующем преобразования. Хуже с фразой про ISO: за ней явно стоит недоумение разработчиков gcc очередной нормой стандарта, так что это просто лишнее подтверждение необходимости физического уничтожения всех, кто входит в комитеты (любого рода).

А теперь самое главное: чёрт подери, ну не надо так делать! Вот просто не надо и всё. Или член класса, или внешняя функция. Кстати, если вы думаете, что она обязана быть friend, то вас жёстоко нае^Wобманули, это вообще довольно распространённое и совершенно дикое заблуждение, что-де операцию можно или членом, или другом класса. Спасибо идиоту Шилдту.

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

Честно говоря, мне вообще непонятен ваш вопрос. У вас на каждый read выполняется writeln. Какая разница, char'ы тут, не char'ы, однобайтовые, многобайтовые — что прочитали, то и отдаём, всё, все свободны. С какого бодуна тут что-то должно отброситься?

На всякий случай: если эту программу запустить, ввести fff и нажать Enter, ваш цикл прокрутится четыре раза — по одному для каждой введённой буквы f и один раз для символа перевода строки.

Хозяин сайта ответил на вопрос, поэтому позволю себе вставить 5 копеек. Тут где-то в обсуждениях проскакивал "крик души" человека, закончившего 7 классов и столкнувшегося с трудностями при понимании математического минимума, изложенного в 1 томе "Введения в профессию". 5 и 3 классы - всё же несколько другой уровень. В этом возрасте с "вот непонятно вот прям тут" достаточно столкнуться на первой-второй странице, чтобы потерять всякий интерес и тягу к предмету, да и тяжеловато для школьника вообще (даже для выпускника, что уж там о "началке") принять факт, что нужно если не прочитать, то хотя бы пробежать глазами книжку в ~500 страниц, которая, несмотря на толщину едва ли не большую,чем все учебники за год, не делает "кулхацкером" (внезапно!), а просто вводит в курс дела и задаёт вектор, в котором следует двигаться дальше.
Я бы посоветовал знакомить детей такого возраста с программированием в игровой форме и постепенно подводить к концепции ЯП. Есть довольно много головоломок, завязанных и на программировании, и на решении алгоритмических задач вообще. Могу порекомендовать, например, игру от Tomorrow Corporation - Human Resource Machine (внимание, здесь и далее - проприетарщина, хотя, судя по упоминанию Block Strike, это не проблема). Игрушка о трудовых буднях офисного работника, под строгими взглядами начальства перекладывающего корреспонденцию с конвейера на конвейер в соответствии с написанной пользователем программой по определенному ТЗ. Программы составляются из графических блоков, причем весьма низкоуровневых (input, output, add, sub, jmp и т.д.), но могут быть скопированы в текстовый редактор в этаком "ассемблерообразном" виде. Можно будет на определенном этапе показать ребёнку, во что превращается его программа из блоков, чтобы стать понятной машине - вот и переход к ЯП. Ещё интересные головоломки у Zachtronics - Infinifactory (похожая на популярные нынче "кубические" песочницы вроде Minecraft или того же Block Strike), Spacechem, Opus Magnum и т.д. Если почувствуете, что ребёнку интересно - можно попробовать тот же Паскаль по первой части "Введения", а дальше видно будет. Конструктор игрушек какой-нибудь простенький можно поковырять со скриптованием (Love2D, например; это, правда, фреймворк и едва ли для новичков, но какие-то азы можно дать), дети как-то охотнее самостоятельно нарисованный мячик по экрану гоняют, чем считают корни квадратных уравнений, а эффект сопоставимый. Можно и в готовую игрушку, допускающую моддинг, влезть (там частенько скрипты на Lua).
При знакомстве с ЯП есть определённая проблема в отсутствии нативного понимания детьми английского, пусть даже и минимального набора слов. Где-то в интернетах попадался комментарий в духе "как вижу программу я и как видит её мой сын", где на первой картинке условный "хелловорлд", а на второй - мешанина из китайских иероглифов и цифр. Хотя дети сейчас изучают английский со 2 класса, а не с 4-5, как раньше, но сомневаюсь, что вот прям "шпрейхают на инглише" в этом возрасте.
В любом случае, чего точно лучше не делать в начале пути, так это сажать за Ruby, Python и прочий JavaScript. Языки, конечно, мегапопулярные нынче, но вот чему они точно не научат, так это культуре программирования. В этом смысле их, пожалуй, можно назвать "Бейсиками XXI века" (вспоминая меткое изречение Дейкстры). Go в этом плане чуть строже, там компилятор не даст пуститься совсем уж во все тяжкие, но сборщик мусора не приучит к бережной работе с памятью.
В общем, универсального совета здесь нет и быть не может. Присматривайтесь к своим детям и поддерживайте их интерес и начинания. Только не переусердствуйте - в этом возрасте еще сто раз поменяются и увлечения, и предпочтения, насильственно "увлекать" ничем не надо!

Я не педагог (в строгом смысле — то есть я не специалист по обучению детей), и возрастную психологию никогда не изучал, но думаю, что мои книги можно "давать" в любом возрасте, в котором ребёнок их согласится "взять". Подсуньте ненавязчиво и посмотрите, что будет.

Только учтите, Linux они сами не поставят, в терминал сами не залезут. И заставлять их туда лезть бесполезно — получите эффект отторжения. Так что разве что личным примером.

И нет, scratch не об этом. Вообще.

Ну вот башен из одного кубика сколько будет разных? Четыре, так ведь? Цветов-то всего четыре.

А из двух? Первый кубик выбираем четырьмя способами, второй — тоже четырьмя, итого 4x4=16.

На каждую из таких башен (при том что они все разные) можно четырьмя способами пристроить ещё один кубик. Итого из трёх кубиков получаем 64 разные башни. А из четырёх — 256.

256+64+16+4 сколько будет? Вот, собственно, и вся задача.

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

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

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

> Про высшее образование понятно - оно лишь даёт вектор направления

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

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

> А вот если недопрограммист пойдёт куда-нибудь

Замечу, помешать мы ему в этом не можем.

> ему только мозги изуродуют или действительно будет толк

Depends. Зависит от индивидуальных характеристик.

> Помимо того, что он в дальнейшем будет работать в организации, от которой нам будет только хуже и сфере IT.

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

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

Может быть, кто-нибудь ещё объяснит нам, в чём тут дело?

Он еще и JavaScript назвал в ответ на вопрос о худшем ЯП. Наш человек, наш...

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

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

Ну и? Сплошь и рядом такое происходит. Впрочем, могу даже предложить пару реальных случаев для сравнения. Н.Вирт свой Паскаль придумал, реализовал, потом на него забил; в ISO приняли стандарт, который, к счастью, никто никогда не пытался применять. В итоге есть минимум две вполне живые реализации сильно модернизированного Паскаля — Delphi и Free Pascal, который я в книжке использую. А раньше их было ещё больше, Паскаль был довольно популярен в 1980-е и 1990-е. И, главное, никаких стандартов — на "стандартный Паскаль" никто не оглядывался, а то бы Паскаль точно помер.

А вот другой пример: Лисп. Маккарти именно что от дел отошёл, забил на Лисп, а зря — пришёл особо злостный вредитель Guy L. Steele Jr., организовал процесс стандартизации Лиспа, результатом которого стал Common Lisp, ну в общем нету больше у нас Лиспа. Common Lisp и некоторые его условно-живые (поддерживаемые) реализации я подробно рассматриваю в четвёртом томе, и, увы, всё это рассмотрение можно свести к одной фразе: перестаньте пинать труп CL, нужен новый лисп.

Возможно теперь каждый желающий может написать свою спецификацию и они будут между собой конкурировать, какая кому больше по душе?

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

Скажу больше, одно изделие (например, компилятор) может поддерживать много разных спецификаций (и не поддерживать ещё больше других). И да, выбирать, что поддерживать, а что нет, должны создатели компилятора — а кто ещё?

полная поддержка CSS3 и HTML5

А зачем эту хрень поддерживать? CSS3 нормальные люди не юзают, по причине, мягко говоря, ущербности. Как и CSS2. HTML5 - это вообще диверсия, макакинг - "стандарт", поощряющий встраиваивание жабаскриптов. Создание браузера с нуля с поддеркжкой этих макакинг-технологий??? Зачем, если это дерьмо и так намертво прибито гвоздями к любому нынешнему браузеру. Браузерный скриптинг - безусловное зло.

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

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

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

Так вот, это тоже можно сделать с копеечными затратами ресурсов. Нужно только написать свой собственный интерпретатор JS, который с точки зрения приложения, в которое он встроен, представляет собой не то, что сейчас — некую процедуру, которой мы вынуждены отдать управление и надеяться, что она когда-нибудь завершится — а сущность совершенно иную: виртуальная машина должна быть оформлена как конечный автомат (точнее говоря, скорее "формальный автомат", поскольку "конечный автомат" — это строгий термин, и в этом смысле с его помощью реализовать тьюринг-полный язык нельзя, поскольку сами КА не тьюринг-полные), меняющий своё состояние по мере неких элементарных "шагов", каждый такой "шаг" выполняется за очень короткое (и уж точно заведомо детерминированное) время. Браузер реализуется однопоточным и никогда не отдаёт управление скриптам на JS — вместо этого он, обработав все входящие события вроде воздействий на GUI и данных, пришедших из сокетов, позволяет автоматам, выполняющим все активные в настоящий момент скрипты, сделать по одному шагу. Если событий нет, а активные скрипты есть -- фигачим, скажем, по 100 или 200 шагов, равномерно распределив их между активными скриптами, после чего снова проверяем, нет ли событий, подлежащих обработке. В toolbar'е браузера размещаем ВОООТ ТАКУУУУУЮ кнопку "stop scripts now".

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

Опечатка, конечно. Её даже уже нашли, но всё равно спасибо за внимательность :-)

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

Все.

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

Эта известна уже давно, почему-то её всегда замечают первой. Спасибо за внимательность :-)

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

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

Это зависит, скорее всего, не от дистрибутива, а от сочетания версии libc и версии самого valgrind. В любом случае "still reachable" -- это не криминал.

Так классика же. И да, в здравом уме такое в голову не придет, тут вы правы.

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

Будет.

Ч.Петцольд - Код. Тайный язык информатики

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

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

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

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

vim-xkbswitch

set keymap=russian-jcukenwin
set iminsert=0
set imsearch=0
inoremap <C-l> <C-^>

Переключатся в режиме вставки ctrl + l

У меня в .vimrc есть такой кусок:
set langmap=
\ёйцукенгшщзхъфывапролджэячсмитьбю;`qwertyuiop[]asdfghjkl\;'zxcvbnm\\,.,
\ЁЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ\\,;~QWERTYUIOP{}ASDFGHJKL:\"ZXCVBNM<>?

Вот не вижу проблемы.

Мне этот вопрос уже не впервые задают, и меня это несколько удивляет. Да, я переключаю раскладку "каждый раз", и не только при переходе в режим команд. Я, например, точку с запятой и двоеточие набираю, переключаясь на латинский регистр, ну то есть я тупо не помню, где они в русской раскладке. Вот сейчас поискал, они оказалось на четвёрке и шестёрке; я этим не пользуюсь никогда, вот то есть вообще, я не знаю и не помню, где там что на Shift-циферках в русском варианте. Хотя нет, вру -- восклицательный знак и двойную кавычку набираю таки как shift-1 и shift-2. Попробовал сейчас вопросительный знак набрать, пальцы сами собой переключили регистр и нажали shift-? (ту кнопку, которая рядом с shift'ом). Про двоеточие я это за собой знал, про вопросительный вот сейчас только выяснил.

Возможно, это потому что у меня переключение регистров висит на правом Alt. Я сам не замечаю, когда успеваю переключить раскладку туда и обратно. А вот как люди могут работать с переключениями по всяким Ctrl+Shift, вообще не представляю, причём вне всякой связи с vim'ом. Это же положение руки сменить надо, чтобы переключить раскладку. Кто придумал такое?!

аудиторию заинтересованных спонсоров

Пожалуйста, не надо путать спонсорство с благотворительностью.

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

Существует, причём появился даже раньше. Называется ARM TrustZone. Именно на его основе работает AMD PSP (аналог Intel ME на AMD), например.

Правда это не совсем полный аналог и ближе к режиму SMM чем к ME, насколько я понимаю. Но эффект такой же — код производителя железа, который имеет более высокие привилегии чем ядро ОС.

Мне об этом ничего не известно.

Попросту говоря, в де{би|ву}ане меню генерируется автоматически, а во фре это дело оставлено на усмотрение пользователя.

Файс с описанием меню можно создать вручную, а можно запустить какой-нибудь автоматический генератор. В комплекте с IceWM, вроде бы, должен быть какой-то генератор меню (может даже не один, в зависимости от ОС и версии IceWM). Ну или можно установить универсальный menumaker.

А пакетные менеджеры давно есть во всех основных *BSD системах (ну вот про DragonFlyBSD не уверен, а в остальных трёх точно есть). К тому же, даже собрав софт самостоятельно из портов, удобно получить на выходе готовый пакет, а не просто россыпь файлов.

Андрей Викторович отчасти правильно сказал, во фре поставляется ПО как это говорят "ванильное", без всяких придуманых за вас конфигов.

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

А про меню в icewm - на форуме FreeBSD очень подробно и детально описана конфигурация это wm:
https://forums.freebsd.org/threads/howto-icewm-configuration.59161/

Здесь сказывается принципиальная разница в подходах к построению программного окружения. В линуксах есть пакетные менеджеры, на которые возложено создание списков установленных программ, а пакеты, в которые завёрнуты оконники, из этих списков тем или иным способом генерируют свои менюшки. Когда я в последний раз имел дело с FreeBSD (а это, увы, было очень давно -- лет пятнадцать назад), ничего похожего на пакетные менеджеры там не было, вместо них присутствовала port collection, но эти порты никак друг на друга не оглядывались и на присутствие-отсутствие друг друга не реагировали.

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

В чьей-чьей профнепригодности вы собрались сомневаться? Торвальдса? Ну сомневайтесь, сомневайтесь. На здоровьечко.

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

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

Добавлю... В файле /etc/fstab, вместо фиксированныъ имен устройств, лучше использовать UUID устройства, так как имя устройства может поменяться, по мере подключения друних устройств, а вот UUID не поменяется. Команда lsblk покажет имена устройств, и куда они смонтированы, а blkid покажет UUID всех подключенных к системе устройств.

Команда blkid | grep [имя_устройства] | cut -d' ' -f2 | tr -d '"' даст Вам UUDI интересуюущего Вас устройства. Остается потом только это дело записать в /etc/fstab

Дополню Андрея по поводу автомонтирования.

Есть такой лёгкий демон ldm. Он у меня неплохо работает на компе пожилых родителей в комплекте с IceWM и лёгким файловым менеджером ROX-filer (они привыкли к винде с иконками, да).

Desktop Environment, который помимо рисования окошек отвечает много за что ещё.

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

1) Из текстовой консоли под root-ом. Не всегда приемлемо.

Практически никогда не приемлемо. Ради флешки каждый раз рутом заходить — очевидный перебор.

2) Прописать в fstab. Проблематично, так как туда заносятся фиксированные имена устройств.

Фиксированные? Да неужели? И что из этого? У вас их что, так много бывает разных?

Вот, если что, мой кусок fstab'а:

/dev/sdf        /mnt/sdf        auto    noauto,user,owner       0       0
/dev/sdf1       /mnt/sdf1       auto    noauto,user,owner       0       0
/dev/sdf2       /mnt/sdf2       auto    noauto,user,owner       0       0
/dev/sdf5       /mnt/sdf5       auto    noauto,user,owner       0       0
/dev/sdg        /mnt/sdg        auto    noauto,user,owner       0       0
/dev/sdg1       /mnt/sdg1       auto    noauto,user,owner       0       0
/dev/sdg2       /mnt/sdg2       auto    noauto,user,owner       0       0
/dev/sdg5       /mnt/sdg5       auto    noauto,user,owner       0       0
/dev/sdh        /mnt/sdh        auto    noauto,user,owner       0       0
/dev/sdh1       /mnt/sdh1       auto    noauto,user,owner       0       0
/dev/sdh2       /mnt/sdh2       auto    noauto,user,owner       0       0
/dev/sdh5       /mnt/sdh5       auto    noauto,user,owner       0       0

В большинстве случаев требуется только sdf, остальные появляются крайне редко. Устройства, не входящие в этот список, для usb stick'а моя система не задействовала ни разу, иначе они были бы уже в списке.

3) Использовать pmount или его аналог. Возникает вопрос о безопасности данной утилиты (к монтированию через DE это тоже относится).

Ну уж во всяком случае она точно не опаснее, чем DE. Хотя бы исходя из объёма кода. Оконным приложениям вообще нельзя ничего критического доверять, одна Xlib для этого уже слишком жирная, а всякие gtk/qt/... (подставить по вкусу) — это вообще не такие программы, относительно которых можно всерьёз говорить о безопасности.

Можно ещё и udev сконфигурить, чтоб флешки автоматически монтировал, или есть такой пакетик usbmount (он в том числе и udev переконфигурирует, но не только, у него бинарник свой). Есть, в принципе, ещё много чего.

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

Позвольте посоветовать OpenBSD. Для изучения Unix'а, в силу своей простоты, подходит ещё больше, чем FreeBSD. Но при этом вполне рабочая система. Да и с "поставить и настроить" в ней я особых проблем не наблюдаю. (Хотя, конечно, адекватно оценить это с позиции "начинающего" не смогу.)

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

Xfce не ставьте, тут я с Андреем полностью согласен. Поставьте какой-нибудь простой оконный менеджер (window manager, в противовес сложному desktop environment), помимо IceWM есть ещё, например, JWM, Fluxbox, Openbox, и многие другие.

А вот Devuan и прочие деривативы Debian я бы не рекомендовал для "изучения Unix". Мало того, что линукс в принципе во многом отступает от классических принципов Unix, так дебиан с последователями ещё добавляет туда приличное количество собственной специфики, которая нигде, кроме дебианов, неприменима.

Доброго времени суток. Хотел бы поделиться опытом в теме изучения Linux'а среди начинающих. Сам пользуюсь Linux-ом уже 3 года, и изучаю программирование по книжкам Андрея Викторовича. Если вы начинающий, вряд ли вы столкнётесь в процессе обучения программированию с системами инициализации(я спустя три года изучения до этого ещё не добрался), а работа с консолью, компиляция программ, настройка пользовательского окружения и т.д. во всех Unux'ах +- одинаковая. Поэтому, с моей точки зрения, не стоит быть таким категоричным в отношении Linux'а. Попробуйте начать с "Дружественных" дистрибутивов по типу Убунты или Минта, хотя все дистры с графическим интерфейсом из коробки ставятся не очень сложно, и тут имеет смысл просто попробовать разные варианты. По мере накопления опыта и навыков, вы сами начнёте понимать, что в системе работает плохо, а что хорошо. Главное эти опыт и навыки получить, ну а потом вы сами сможете принять осознанное решение, какая система лучше, а какая хуже. Тем более для вас не будет проблемой поставит FreeBSD или что либо ещё. Сейчас же для вас куда важнее просто начать работать в Unix'е каким бы он ни был.
P.S. Также знание английского языка поможет сильно сократить время обучения. Лично я очень жалею, что не смог его выучить. Информация по любой детали системы доступна либо в manах либо в интернете. Не пренебрегайте этим.
P.S.S. Попробуйте посмотреть в сторону manjaro xfce, бысто ставится, не требовательна к ресурсам и выглядит красиво, хорошая замена убунты.

Для начала -- зачем вам Xfce, это же desktop environment. Возьмите IceWM или что-то ещё такое, что не рисует иконок.

Что до FreeBSD, то идея, несомненно, хорошая, если вы справитесь её поставить и настроить. Для начинающих это довольно сложно (хотя и не скажу, чтобы совсем невозможно).

Ubuntu годится довольно условно -- то есть в принципе годится, но лучше всё-таки какой-нибудь другой дистрибутив. Хоть даже тот же Devuan.

Честно говоря, не знаю, я никогда не занимался ни с кем школьной математикой (когда-то давно занимался абитуриентской, то есть готовил к вступительным экзаменам, но это совершенно другое дело). Поэтому я просто не в курсе, какая на эту тему есть литература.

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

Очень хочется сказать, что да — но нет. Без внешней поддержки мне это не поднять.

что еще бывает и чем отличаются

Если совсем упрощённо, то императивное программирование - это реализация решения задачи в "терминах компьютера". Все остальные парадигмы предполагают реализацию "в терминах более понятных человеку". К примеру, sql-запросы составляются "в терминах баз данных", что и откуда выбрать, по каким критериям и т.д. При этом, в общем случае, пользователь не задумывается каким образом всё это происходит на уровне машинных команд. Т.е. пользователь просто описывает то, что хочет получить в итоге, а СУБД исполняет его указание.
Другой пример: работа с текстом, к примеру, с помощью Perl'a. Пользователь с помощью синтаксиса регулярных выражений составляет указание интерпретатору найти какие-то сочетания в текстовом файле (к примеру), интерпретатор исполняет это указание, при этом пользователя совершенно не волнует что там происходит на уровне машинных команд.

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

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

На днях мне одному приятелю пришлось объяснить разницу между языком С и С++. И в ответ я услышал: "не нужно смешивать возможности языка и сам язык, они почти одинаковы. Лучше сейчас вообще использовать Python" . Честно говоря, у меня волосы дыбом встали. И это говорит человек, который уже почти три года проработал "программистом".

Тот, кто "разрабатывает ПО" на Python или любом другом скриптовом языке, не может называться программистом по определению. Такого деятеля нужно называть "пользователь интерпретатора", который в силу своей необразованности ваяет поделия на скриптовых языках под видом ПО. Типичный представитель "макако-ориентированного программирования". Но особенная дичь начинается, когда подобные адепты начинают ваять на "современном С++", начиная тянуть "возможности" из С++ 11 и последующих стандартов. Получаемая на выходе высокоуровневая лапша выдаётся за "модные паттерны". На уровне машинных команд там, естественно, дичайший треш. Зато "я пишу на современном С++, который безопасен, словно жаба, везде пихаю STL-контейнеры, мозг не включаю".

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

Преодолеем ли мы это когда-нибудь? Вряд ли. Но тем ценнее будут те, кто понимает, что к чему.

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

К сожалению, ни о каком "хотя бы в электронном виде" речи идти не может, эти события жёстко связаны: электронная версия появится на сайте через 1-2 дня после выхода книги в бумаге.

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

Была такая книжка, да. Мне попадалась. Нет, родственников таких у меня нет, но это и не удивительно — моя фамилия не относится к редким.

Ошибка состоит в отсутствии файла stud_io.inc, спасибо Капитану Очевидность.
Файл берёте здесь: http://www.stolyarov.info/books/extra/stud_io_inc
Его нужно будет переименовать в stud_io.inc.
Про это говорится на странице, посвящённой второму тому.

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

Я.И.Перельман "Живая математика" вот тут, например: https://math.ru/lib/book/djvu/perelman/alive_math.djvu

Другие книги того же автора тоже весьма способствуют.

Больше того, вообще удивительно, что под виндой у вас заработало хоть что-то.

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

Проблема в том, что у нас в вузе начинают сразу с плюсов
У вас там часом не для хухля программистов готовят? Тамошние "гении" вон возможности С++ 17 используют в аллокаторах памяти - http://www.opennet.ru/opennews/art.shtml?num=52364#13
Такая вот "работа мечты", как любят вещать маркетолухи: stl-макакинг, бессмысленный и беспощадный.

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

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

Добавил nosystemd.org в начало списка, очень, кстати, понравился их слоган. without-systemd пока не убираю, вдруг оживёт.

Лично мне не потребовалось ни разу.

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

Кавалерийский наскок стукнутых ньюфагов кончился ничем. Это хорошо.

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

Но, кстати, про IT-ПТУ я полностью согласен с текстом новости: чтобы просто топтать кнопки или тем более админить, высшее образование не нужно от слова "совсем". И, кстати, есть шанс, что при наличии адекватных средних специальных учебных заведений, где учат именно что админить и кодить, всякая корпоративная (копроактивная) шушера, рыщущая в поисках источника кадров, пойдёт туда, вот в эти ПТУ, техникумы и прочее, и перестанет, наконец, портить воздух в университетах.

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

Вот не понимают люди, что нельзя такие вещи решать голосованиями; в голосованиях бывают те, кто за, и те, кто против, и когда большинство перевешивает, получается, что интересами меньшинства просто пренебрегли (замечу, именно поэтому я не считаю себя демократом). Между прочим, если пройдёт "proposal F", можно будет констатировать, что Дебиан нынче находится под руководством комитета, т.е., читай — превратился в токсичную и вредоносную сущность.

Организация, курирующая разработку Devuan, написала

В упор не вижу никакой "организации", вижу частное лицо Denis Roio, письмо написано от первого лица. Вообще говоря, напоминает паникёрство.

Так или иначе, на Дебиане свет клином не сошёлся. Ну, уйдём на Слаку или ещё куда. Хотя мне, в принципе, видится ещё один вариант развития ситуации -- сейчас в Дебиане происходит как раз то, что нам не нравится, после чего большая часть проекта заявляет "вы достали" и уходит в Devuan. Маловероятно, конечно, но не так чтоб совсем невозможно.

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

Если второе — то можете использовать что угодно и для чего угодно, только зачем об этом спрашивать у меня? Я никого не учу GameDev'у и никогда не пытался, сам его никогда не трогал, меня вообще эта область не интересует.

Если первое — то та хреновина, на которую вы постили ссылку, никакого отношения к программированию не имеет. Вообще. Те мелкие скриптики, которые в этой "среде" пишутся на непонятном языке (вроде C#, а вроде и нет) — это не программы, это именно что скриптики, а стряпанье игр в подобных "средах" — ну, с таким же успехом можно программистами считать, например, продвинутых пользователей Excel, там ведь тоже бывают макросы.

для среды Unity

Если под любую из Unix-систем разрабатывается программа, предполагающая графический интерфейс, то она не имеет права быть завязана на конкретный оконник. Все эти "для Unity", "для KDE", "для Gnome" — результат деятельности безграмотных моральных уродов, не понимающих действительной роли оконного менеджера в экосистеме X Window.

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

С другой стороны, там про меня исключительно лажа. И фанатом Столлмана я никогда, собственно говоря, не был, а сейчас даже перестал, пожалуй, быть его сторонником. Не, ну я всё понимаю, но чтобы в погоне за этой "свободой", которая, собственно, им самим и придумана и на самом деле свободой не является — не просто забыть исходную цель (ликвидацию копирайта и прочей интеллектуальной собственности), а наехать на пиратские партии, что, мол, они требуют отмены копирайта, а GPL основана на копирайте, как же мы без копирайта теперь будем свободу защищать... короче, клиническая картина ясна.

И книжки у меня свёрстаны вовсе не под A4, а под A5, и ни в одной из них нет строчек длиннее 65 символов, и про нормы эти я, разумеется, в курсе (см. книжку про оформление кода, стр. 28, абзац в середине).

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

В общем, не тот уж критик пошёл, не тот. Вот раньше критики бывали, уууууу. А нынче — разве ж это критики.

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

Теперь по поводу "сверхтоксичных" и "радиоактивных". В принципе, в словосочетании "способен изготовить человек" я имел в виду именно человека, т.е. индивида или группу таковых, а не всё человечество в целом, государство и т.п., т.е. я не призываю, например, к свободной продаже ядерного оружия (хотя свободная продажа огнестрела с моей точки зрения — просто аксиома, то есть пока оборот огнестрела ограничен, государство остаётся моим заведомым врагом). Изготовить радиоактивные вещества вообще вроде бы пока невозможно, их нужно добыть, а координация добычи полезных ископаемых, с моей точки зрения, как раз вполне себе одна из естественных функций государства. С химическим оружием тоже вроде бы всё не так чтоб совсем просто, то есть его невозможно изготовить, не прибегнув к помощи государства. Ну то есть, к счастью для человечества, вопрос запрещения изготовления оружия массового поражения частными лицами пока что не стоит.

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

> который продаёт свои книги через свой собственный сайт

буду краток: шоб он сдох, как и все копирасты

> С одной стороны, эта деятельность сомнительна

Она не "сомнительна" ни разу. Ну то есть у меня сомнений на этот счёт нет ни малейших.

> а как вообще можно заработать написанием художественной литературы

Никак. Художественная литература не должна быть работой. Впрочем, НЕхудожественная — тоже.

> Crowd funding как видим на примере вашей книги по программированию, работает

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

> но подойдёт ли он для художественной литературы?

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

> Доска-мел-тряпка-вот-это-вот-все

Именно.

> слайды?

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

> Все же код отличается

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

Что я точно знаю -- так это что если мне на какой-то пример кода не хватает доски и/или скорости его написания, то этот пример для лекции не годится, ибо слишком громоздок.

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

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

Undefined behavior (само понятие такового) — это порождение проклятых стандартизационных комитетов. Между прочим, согласно пресловутым стандартам, сложение двух целых чисел может вызвать UB — если числа знаковые и результат не поместится в разрядность. Как можно это воспринимать всерьёз, лично для меня вопрос открытый.

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

Ну а если хотите понимать — берите всякие источники и экспериментируйте с компьютером.

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

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

Смысл, может, и есть, времени нет.

Эту уже нашли, но всё равно спасибо :-)

Каких ещё "модификаторов"? Там тупо адрес хранится/передаётся, так же как и в указателях. И да, ссылки — это синтаксический сахар, не более того; но языки программирования вообще состоят из синтаксического сахара.

Мне вот другое интересно, если вы не программист, то за каким лешим вам сдался C++?

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

Мне довольно сложно понять, что конкретно вам оказалось непонятно. Могу посоветовать взять вот такую программу:

program CharInput;
var
    c: char;
begin
    while not eof do
    begin
        read(c);
        if c = #10 then
            writeln
        else
            write('[', c, ']')
    end
end.

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

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

Чтобы сделать возможным JIT, нужно затребовать у системы новую секцию памяти с соответствующими флагами (одновременно доступную на чтение, запись и исполнение). В *nix-системах это делается с помощью системного вызова mmap. И да, это возможно сделать, в книге утверждение слишком категоричное. Во втором издании поправлю.