Введение

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

Поколения программистов

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

1. Поколение программистов математиков (1940-1960)

Как известно более старые книги по математике времён СССР лучше более поздних того же СССР и России. В некотором роде книги по математике деградировали так же, как и книги по программированию. Люди, до 60-ых годов получали гораздо более простые и насыщенные источники информации, просто потому, что у них не было выбора взять худшие варианты из будущего. Похожее случилось и с программированием.

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

1) Структурное программирование

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

2) Процедурное программирование

инструкции: подпрограммы (процедуры и функции).
особенность: значения как аргументы.

3) Функциональное программирование

инструкции: функции.
особенность: функции как аргументы.

4) Модульное программирование

инструкции: логические (пространства имён).
особенность: физические (включение файлов).

5) Объектно-ориентированное

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

6) Обобщённое-программирование

инструкции: шаблоны функций и классов.
особенность: типы как аргументы.

С одной стороны кто-то спросит, а в чём преимущество отсутствия парадигм?
1) Алгоритмы находятся в одном месте без размазывания по тысячам файлов.
2) Не нужно учить парадигмы, чтобы написать алгоритм, достаточно здравого смысла.
3) Парадигма программирования это всегда ограничение возможностей.

Для примера Си не даёт вам написать инструкции структурного программирования вне парадигмы процедурного программирования.

test01.c

int c = 0;

int main()
{
    {} // блок правильно
    if (c) {} // ветвление правильно
    while (c) {} // цикл правильно
    return 0;
}

test02.c

int c = 0;

{} // блок неправильно
if (c) {} // ветвление неправильно
while (c) {} // цикл неправильно
   
int main()
{
    return 0;
}

Но с тем же языком Lua таких проблем нет, глобальные структурные инструкции такие как блоки, ветвления и циклы разрешены.

test03.lua

c = false

do end -- блок правильно
if c then end -- ветвление правильно
while c do end -- цикл правильно

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

C#

using System;

class HelloWorld
{
    static void Main()
    {
      Console.Write("Hello, world!");
    }
}

Java

public class HelloWorld
{
    public static void main(String[] args)
    {
        System.out.println("Hello, world!");
    }
}

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

2. Поколение программистов аппаратчиков (1960-1980)

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

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

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

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

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

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

3. Поколение программистов абстракционистов (1980-2000)

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

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

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

Но это ещё не закат эры. Давайте перейдём к следующему поколению.

4. Поколение программистов пользователей (2000-2020+)

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

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

Проблемы программистов

Далее перечислю основные проблемы программистов.

Мусорная литература

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

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

Мусорные алгоритмы

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

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

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

Итоги

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

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

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

Падение среднего уровня подготовки программиста это не проблема, а результат многолетних трудов по снижению барьера входа. Чтобы профессия могла быть массовой, работники — дешевыми, количество сделанной работы — большим. А если бы программирование было столь же сложным, как 50 лет назад, фигу бы мы имели, а не work from home.

Тоже мне бином ньютона

Почему программисты прошлого были умнее

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

Здравствуйте, velkin, Вы писали:

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

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

А про ООП так говорят те, кто либо не написал на нём ни строчки, либо зазубрил бучизмы и применял их где надо и не надо. Последних уравновешивают не менее упоротые последователи Александреску.

V>В принципе я обозначил проблему ...

Спасибо, прямо глаза открыл.

V>... Что касается решения, то здесь как всегда нужно проводить опыты.

Вот, займись и нам расскажешь.

Здравствуйте, SkyDance, Вы писали:

SD>Можно было бы обойтись несколько менее пространным и более простым объяснением.
SD>В прошлом программистов было десяток-сотня реально увлеченных фанатиков, а сейчас — миллионы, для многих из которых это все та же конвейерная сборка.

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

SD>Падение среднего уровня подготовки программиста это не проблема, а результат многолетних трудов по снижению барьера входа.

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

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

SD>>Падение среднего уровня подготовки программиста это не проблема, а результат многолетних трудов по снижению барьера входа.
V>Да, это так. Только проблема в том, что попытка снизить уровень входа так же сильно его повысила. Сильнее всего вход снижается, когда используются готовые библиотеки. Когда человек хочет программировать сам, то он натыкается на сложные парадигмы программирования вроде ООП или даже обобщённое, на которых ему предлагают использовать шаблоны проектирования.

Звучит примерно как "хочу махать молотком, а на работе заставляют пользоваться станком ЧПУ"

Здравствуйте, Muxa, Вы писали:

M>Звучит примерно как "хочу махать молотком, а на работе заставляют пользоваться станком ЧПУ"

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

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

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

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

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

Здравствуйте, velkin, Вы писали:

V>Здесь речь про фундаментальные знания. Простой вопрос, нужно ли изобретать алгоритм самому, если он уже изобретён. Лично я считаю, что не обязательно, достаточно заучить.

Всё ещё проще: если готовый алгоритм решает поставленную задачу, берём и используем. Если не решает, то не используем — придумываем свой.

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

Можно пример?
Что за алгоритм, что за абстракции?
Ощущение, что писал ӍїϛϮϠǷiя-ȺҜ под веществами.


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

Отлично! Берём классику — книжку Кнута/Кормена/Ульмана/Седжвига/Скиены — кто нравится больше и начинаем составлять фундамент . Просто, доступно, безо всяких абстракций.

Какую-то проблему сочинил и предлагаешь с ней бороться. Нет проблемы. Есть разделение труда. Есть "пользователи", которые программы составляют из кирпичиков и есть "математики"/"аппаратчики", создающие эти кирпичики. Все заняты, все счастливы.

Здравствуйте, velkin, Вы писали:

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

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

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

Здравствуйте, velkin, Вы писали:

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

Может всё гораздо проще? Просто велосипедостроение порицаемо окружающими
https://www.youtube.com/watch?v=nA-YFafnV68&t=2271s

Здравствуйте, kov_serg, Вы писали:

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

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

Хотя главный демотиватор программистов новичков и не только не писать самим это то, что каждый труд требует:
1) времени.
2) мозговых усилий.
3) знаний.

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

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

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

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

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

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

Здравствуйте, velkin, Вы писали:

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

У современных программистов жилья нет. А чтобы оно было, нужна ипотека. А на работе за ипотеку велосипеды писать не дадут, там велью (value) ковать надо. Можно и без жилья, с родителями жить, но тогда девушки давать не будут, сейчас не 60ые с романтикой, а 2020ые с рейсами инстаграмщиц в Дубай.

Здравствуйте, velkin, Вы писали:

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

Такой сумбур, перепутаны причины и следствия. По моему скромному мнению, условных "программистов прошлого" отличают:

1. Более глубокая математическая подготовка — на программистов не учили, учили на математиков-кибернетиков.
2. Широта знаний — когда нет готовых библиотек, приходится всё писать самому.
3. Отсутствие глубины знаний — вытекает из пункта 2, потому как невозможно быть "и тут, и там". А ещё нет накопленного опыта предков. Оттого и чрезвычайно глупые и "детские" ошибки в старых стандартах и алгоритмах.
4. Отсутствие культуры программирования — те самые парадигмы вместе с общепринятыми приёмами, которые позволяют сотне-другой человек работать над общей кодовой базой без желания уничтожить друг-друга.

При желании можно ещё добавить, я просто взял из головы основное. Но как бы то ни было, их нельзя назвать глупее или умнее, потому что срез культуры программирования в любой момент определяется уровнем развития аппаратного обеспечения и культурой потребления ПО на момент среза. Было время, когда изощрённый алгоритм мог обеспечить компании годовую доходность, тогда и у руля стояли "гении-задроты". Сейчас успех определяется скоростью выхода на рынок, поэтому есть спрос на голодных студентов, готовых перерабатывать сублимированную лапшу в виртуальную 24/7.

Здравствуйте, cppguard, Вы писали:

C>Сейчас успех определяется скоростью выхода на рынок, поэтому есть спрос на голодных студентов, готовых перерабатывать сублимированную лапшу в виртуальную 27/7.

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

Здравствуйте, velkin, Вы писали:

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

Such is modern computing: everything simple is made too complicated because it's easy to fiddle with; everything complicated stays complicated because it's hard to fix.

(c) Rob Pike, the author of Go lang.

Здравствуйте, cppguard, Вы писали:

C>При желании можно ещё добавить, я просто взял из головы основное.

Я уже выше всё это написал, и в статье, и в комментариях.

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

И это я тоже выше написал.

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

У тебя просто идёт повторение моих мыслей из статьи.

В самом начале пути бытие определяет сознание, а не сознание определяет бытие

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

Возьмём Мартина Роберта (рождение 1952, карьера 1969) аппаратчик

У него много книг, такие как:
1) Чистый код.
2) Чистая архитектура.
3) Чистый Agile.
4) Идеальный программист.
5) Быстрая разработка программ.
6) Принципы паттерны и методики гибкой разработки на языке C#.
7) Гибкая разработка программ на Java и C++.

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

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

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

Мартин Роберт

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

В те дни допускалась масса ошибок. Конечно, в те дни мы не знали, что это
ошибки. Да и не могли знать.

...

Это было в 1969 году. Мне тогда было 17 лет. Мой отец убедил местную
фирму под названием ASC нанять меня программистом на неполный
рабочий день.

И пример его программы выдаёт в нём то поколение аппаратчиков.

PRTCHR, 0
TSF
JMP .-1
TLS
JMP I PRTCHR

А теперь давай возьмём Дональда Кнута (рождение 1938, карьера 1960) математик

Его книги:
1) Конкретная математика. Основание информатики.
2) Искусство программирования.
3) Компьютеры и набор текста.
4) Всё про ΤΕΧ.
5) Всё про METAFONT».

По одним только названиям я могу сказать, что Дональд Кнут больше уделял внимание математике и набору текста, он из поколения математиков. Тогда как Мартин Роберт больше зациклен на чистоте от абстракций. Да, книги "Чистый код", "Чистая архитектура", да и не только это всё про загрязнение кода абстракциями. Чистый алгоритм, вот основная идея идущая через его творчество.

Далее возьмём Страуструпа Бъёрна (рождение 1950, карьера 1975) абстракционист

Казалось бы он чуть старше Мартина Роберта, хотя и гораздо младше Дональда Кнута. Но он создатель языка C++, то есть человек повёрнутый на парадигмах. Закончил университет в 1975 году, стал доктором философии в 1979 году и тогда же стал работать в "Bell Telephone Laboratories". А Си с классами появился в 1980 году.

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

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

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

Вот так мы и докатились

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

Моя статья о том, чтоб дать понять людям, что да, ты пропустил вот это и это. Я не говорю, что гуру программирования должны с открытыми ртами мне внимать. Но это важная тема и она периодически возникает. Об этом говорят образовательные каналы на ютубе. Об этом пишут книжки в том числе про то, как устроиться на работу "Макдауэлл Гейл.Карьера программиста", "Монган Джон.Работа мечты для программиста", причём не в прямой форме, а в косвенной, когда вам говорят, что будут вот такие тестовые задания.

Ещё раз о главной мысли

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

⢀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⠀⠀⣠⣤⣶⣶
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⠀⢰⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⣀⣀⣾⣿⣿⣿⣿
⣿⣿⣿⣿⣿⡏⠉⠛⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⣿
⣿⣿⣿⣿⣿⣿⠀⠀⠀⠈⠛⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠿⠛⠉⠁⠀⣿
⣿⣿⣿⣿⣿⣿⣧⡀⠀⠀⠀⠀⠙⠿⠿⠿⠻⠿⠿⠟⠿⠛⠉⠀⠀⠀⠀⠀⣸⣿
⣿⣿⣿⣿⣿⣿⣿⣷⣄⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⣿⠏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⣴⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⡟⠀⠀⢰⣹⡆⠀⠀⠀⠀⠀⠀⣭⣷⠀⠀⠀⠸⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⠃⠀⠀⠈⠉⠀⠀⠤⠄⠀⠀⠀⠉⠁⠀⠀⠀⠀⢿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⢾⣿⣷⠀⠀⠀⠀⡠⠤⢄⠀⠀⠀⠠⣿⣿⣷⠀⢸⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⡀⠉⠀⠀⠀⠀⠀⢄⠀⢀⠀⠀⠀⠀⠉⠉⠁⠀⠀⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⣧⠀⠀⠀⠀⠀⠀⠀⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢹⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⣿⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿

Здравствуйте, velkin, Вы писали:

V>Здравствуйте, cppguard, Вы писали:

C>>При желании можно ещё добавить, я просто взял из головы основное.

V>Я уже выше всё это написал, и в статье, и в комментариях.

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

V>И это я тоже выше написал.
V>[q]
V>Проблема в том, что в каждом поколении есть свои тренды. Если человек начал как пользователь… … …

V>[skipped]

V>

Далее возьмём… Далее возьмём… Далее возьмём…

А как же Эдсгер Дейкстра? Как это без него?

Здравствуйте, Carc, Вы писали:

V>>

Далее возьмём… Далее возьмём… Далее возьмём…

C>А как же Эдсгер Дейкстра? Как это без него?

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

1) Представь, что современный программист перенесётся во времена молодости Дейкстры. Пусть он даже в нынешнем времени программирует смартфоны, но там ему ничего не останется как стать программистом математиком.

2) А теперь обратная ситуация, в наше время у нас есть все наработки Дейкстры. Но какова вероятность, что родись он 20-30 лет назад, то сейчас стал программистом математиком. Нужна какая-то среда, которая хотя бы намекнула, что не плохо бы почитать книжки 70-летней давности.

Заметь, циклы и прочие конструкции уже были в математике. Это не было инновационным понятием с приходом аппаратного обеспечения. И даже ООП и прочие парадигмы давно были описаны в науке логике. Более того, они там лучше описаны, чем в книгах по ООП.

Но здесь главную роль играет как человек работает с одним и тем же понятием.
1) Одно дело алгоритм написан на бумаге.
2) Другое закодирован для исполнения каким-то компьютером в машинных командах.
3) Третье используются абстракции на парадигмах программирования.
4) А четвёртое человек использует готовые библиотеки.

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

Здравствуйте, velkin, Вы писали:

V>

Мусорная литература

Эту проблему решает высшее образование же. Тебе в вузе преподают, дают список литературы не уровня "C++ за 21 день", а вполне нормальной. Также преподают все те достижения, которые нам остались от математиков, аппаратчиков и абстракционистов.

V>

Мусорные алгоритмы

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

V>

Итоги

V>В принципе я обозначил проблему. И не только я, в интернете иногда об этом говорят. Что касается решения, то здесь как всегда нужно проводить опыты.

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