Igor Ivanov

Вобщем, ответ на ваш вопрос - это на первый взгляд в IT все бежит, если углубиться, все эти новые js или не js фреймворки это малая доля от того что нужно знать и что меняется, а на фундаментальном уровне за 20 последних лет ничего кардинально не меняется. Книги по конкретным фреймворкам которые не вносят чего-то необычного (типа actor model) и современные читать смысла не много(ибо дока + паттерны под капотом и архитектурные правила те же что и раньше), а чтобы понять какой-нибудь MVC(а большинство не понимает что это такое аля "создал папочку контроллеры значит MVC т.к. так на Хабре пишут") и сейчас читать записи 70-х годов по сути необходимо, если вдруг когда-нибудь захочется углубиться, конечно. Тоже самое с очень многими темами.
P.s. В общем, читать Совершенный Код исключительно хорошее занятие, как и Рефакторинг от Фаулера например :)

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

Шансы от этого не зависят.
Учиться в любом случае придётся самостоятельно.

Ничего не изменилось: вы по-прежнему можете изменять стили напрямую у элемента.

при обращении к элементу в JS и изменении стилей методом style DOM дерево

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

Есть tailwindcss с новым (по отношению к 2015 году) подходом - чтобы поменять 1-2 стиля нужно добавить/удалить 1-2 класса. Часто это удобнее.

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

Впрочем, от style всё равно не уйти полностью. Например, динамически высчитываемые анимации - только class не обойтись.

Самый первый пример в документации по модальным окнам как раз для вас https://getbootstrap.com/docs/4.0/components/modal/

$('#myModal').on('shown.bs.modal', function () {
  $('#myInput').trigger('focus')
});

Как создать свой язык программирования?

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

Без другого языка программирования! Полностью с нуля.

В самом низу находится машинный код. Выглядит примерно вот так:
08 04 83 fa 08 04 83 fb 08 04 83 fd 08 04 84 00
У каждого процессора есть свой набор инструкций, которые кодируются машинным кодом. Открываем справочник и пишем нужный код для нужной ОС/железа. Ничего сложного, правда же? =)

Ведь как-то создали первый ЯП.

Достаточно почитать историю появления первых ЭВМ. Они представляли из себя набор переключателей отдельных битов, которые позже эволюционировали в перфокарты, которые в свою очередь представляли из себя прообраз современных исполняемых файлов. С увеличением количества доступных команд, усложнением техники и появлением накопителей программы так же становились все сложнее и сложнее: поэтому решили упростить запись и придумали первый ассемблер. Дальнейшее развитие привело к появлению первого ЯП высокого уровня и далее более высокие уровни абстракции, используя которые сегодня пишутся все программы.

Так что в вашем случае вам надо пройти весь этот путь самостоятельно. Примерно так:

1. На машинном коде реализовать минимальный ассемблер
   
2. Используя свой минимальный ассемблер реализовать простейший компилятор этого ассемблера
   
3. Расширить компилятор ассемблера до стандартного набора инструкций
   
4. На ассемблере реализовать транслятор и компилятор ЯП высокого уровня
   
5. Реализовать необходимый набор инструкций для написания компилятора этого же ЯП
   
6. Написать этот самый компилятор своего ЯП на нём же и далее уже скомпилировать первую самостоятельную версию своего ЯП без использования других ЯП
   

https://datatables.net/reference/option/language.search

С основ
https://doc.lagout.org/science/0_Computer%20Scienc...

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

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

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

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

Это нормально. Есть книги которые вообще не читаются с первого раза. Совершенно нормально прочитать и не понять с первого раза. В таких случаях лично я просто продолжаю читать дальше и вернусь к такому моменту на втором прочтении или когда понадобится на практике.
И очень советую сразу что-то писать пробовать. Какой-нибудь To Do List или крестики нолики (как пример).

Последние 10 -15лет частота не является определяющим параметром (ее потолок уже достигнут). Важными параметрами являются размер кеша процессора и количество ядер (последнее не сильно актуально для разработчика, за исключением c++ разработчиков, которым приходится пересобирать такие крупные проекты как например chromium). К сожалению, так как обычно кеши процессора делятся на ядра, чем больше этих ядер тем меньшее значение имеет очередное увеличение его размера. Так для современных процессоров кеш меньше 16мб..32мб - уже маленький.

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

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

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

https://github.com/torvalds/linux