В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
Для начала разделю программистов по поколениям на основе источников доступной информации, а так же способам программирования, они же парадигмы программирования.
Как известно более старые книги по математике времён СССР лучше более поздних того же СССР и России. В некотором роде книги по математике деградировали так же, как и книги по программированию. Люди, до 60-ых годов получали гораздо более простые и насыщенные источники информации, просто потому, что у них не было выбора взять худшие варианты из будущего. Похожее случилось и с программированием.
Для начала стоит отметить, что в те времена компьютеры ещё не получили широкое развитие. И даже более того, алгоритмы в описании не использовали парадигмы программирования. Для тех кто не помнит, что это такое, краткий экскурс.
инструкции: блоки, ветвления, циклы.
особенность: отказ от безусловного перехода.
инструкции: подпрограммы (процедуры и функции).
особенность: значения как аргументы.
инструкции: функции.
особенность: функции как аргументы.
инструкции: логические (пространства имён).
особенность: физические (включение файлов).
инструкции: классы.
особенность: наследование, инкапсуляция, полиморфизм.
инструкции: шаблоны функций и классов.
особенность: типы как аргументы.
С одной стороны кто-то спросит, а в чём преимущество отсутствия парадигм?
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!");
}
}
Поколение математиков были лишены всего этого безобразия, в том числе и структурной парадигмы заложенной в языке.
С развитием компьютерной техники приходит поколение аппаратчиков. Это моё определение выдуманное только что, можете обозвать их сами. Их отличие в том, что в 60 годах и позже поколения программистов математиков начали внедрять устойчивые программные конструкции в языки программирования. Такие конструкции назвали инструкциями, а их набор парадигмами программирования.
Как показала практика не все парадигмы одинаково полезны. Некоторые приводят к размазыванию алгоритмов по огромному количеству файлов. Вроде бы код открыт и даже свободен, читай и используй, но нет, не получается. Отсюда и мем, что проще написать программу с нуля, чем дописать готовую.
Но давайте пока возьмём другой случай, а именно ограничения, которые приносят с собой парадигмы. Возьмём простую задачу, обмен двух значений, то есть значение A должно принять значение B, и наоборот, значение B должно принять значение A. Да, можно использовать буфер обмена, или хитрые арифметические операции. Но согласится ли с таким подходом пользователь ассемблера.
Если поколение математиков было сосредоточено на алгоритмах включая математические, то с развитием компьютеростроения поколение аппаратчиков сосредоточено на машинных командах. По мере появления парадигм программирования аппаратчиков, то есть людей понимающих как на самом деле работает аппаратура, становится меньше.
Постепенно парадигм программирования становится больше. По ним пишутся книги и всё больше связь с реальностью, то есть аппаратным обеспечением утрачивается. Однако, всё ещё не так плохо, ведь алгоритмы хоть и представлены в иных парадигмах программирования, но всё же это ещё полноценные алгоритмы, а не вызови вот это, получи результат, а как оно там работает не важно.
Давайте я очень условно возьму, что поколение аппаратчиков это 60-80 годы. Ну, а что вы хотите, если в начале 80-ых уже появился Си с классами, а это уже даже не Си. Далее перейдём к следующему поколению.
Опять же все даты условны чисто для красоты изложения. Программисты математики и аппаратчики всё ещё живы, но благодаря накоплению парадигм и попытки их использовать начали накапливаться абстрактные проекты. Думаю многие слышали про
языки низкого уровня абстракции, и
языки высокого уровня абстракции. Так вот некоторые ошибочно полагают, что тот же Си это язык низкого уровня абстракции. А на самом деле машинный код и ассемблер это языки низкого уровня абстракции. А вот всё, что выше это языки высокого уровня абстракции.
И здесь вот какое дело, к этому времени книги по математике уже испортились. А так же появились книги по программированию, которые не описывают алгоритмы, а впаривают какую-нибудь готовую библиотеку алгоритмов без объяснения как она на самом деле работает. Да и сама библиотека на языке высокого уровня абстракции, и нормальному человеку исследовать её удобно лишь в режиме чёрного ящика, когда знаешь, что если вызовешь вот это, произойдёт то.
Собственно уже на этом этапе становится понятно, что поколение программистов, которые пишут алгоритмы вырождается. Книги засраны абстракциями с которыми и с пол бутылки водки не разберёшься. Ну или там ещё какая-нибудь толстая книжонка типа MFC для дурачка. Те люди которые писали эти библиотеки, они да, действительно получали какой-то опыт. Но те кто используют эти библиотеки превратились в обычных пользователей.
Но это ещё не закат эры. Давайте перейдём к следующему поколению.
Всё уже написано до нас, хотя на самом деле нет. Но квалификации опровергнуть это утверждения есть не у всех. Вот смотрите, математики могли идти по пути только математиков. Аппаратчики уже могли идти по пути математиков и аппаратчиков. А абстракционисты могли идти по пути математиков, аппаратчиков и абстракционистов. Казалось бы компьютеры стали быстрее и поколение пользователей могли бы идти по пути математиков, аппаратчиков, абстракционистов и пользователей.
Проблема в том, что в каждом поколении есть свои тренды. Если человек начал как пользователь какой-то библиотеки, то ему сложно будет пройти по предыдущим путям. Да и захочет ли он так делать, ведь вызывать готовую функцию всяко проще, чем писать её самому. А даже если и захочет, то появилось куча мусорной литературы. Я бы даже сказал так, поколение программистов пользователей может даже не понимать, что у них в образовании имеются некие проблемы, да и не для всех это действительно проблемы.
Далее перечислю основные проблемы программистов.
Литературы много, но нет универсальной. Чтобы получить какие-то ответы нужно перелопатить тонну учебников читая одно и тоже, и не факт, что в этой тонне будет то, что нужно. Тогда придётся перелопачивать следующую тонну. Так же литература страдает словоблудием и плохой организацией.
Можно, конечно, и перелопатить тонны книг, но здесь нужен грамотный подход. Хотя бы какая-нибудь программа, которая позволит писать и документировать код, вроде AsciiDoctor. В любом случае решение проблемы остаётся исключительно за каждым программистом.
Почему люди не стремятся читать код свободных библиотек алгоритмов или программ. Да потому, что там всё на абстракциях. Принцип разделяй и властвуй на многих парадигмах не работает. То же ООП называют катастрофой на триллион долларов.
Но давайте представим, что нашёлся герой, который готов прочитать библиотеку алгоритмов. Только вот реализаций огромное количество. И каждую реализацию писал кто-то со своим словарным запасом. Мало того, что для большинства жителей Земли, английский не родной, так ещё и имена выдумывают как попало.
Уже не раз проскакивало такое высказывание, что сложно написать алгоритм понятный другим программистам, а не только машине. Вот только те, кто это говорят не сказал бы, что пишут что-то понятное и вменяемо структурированное. Мысль то может и правильная, где реализация.
В принципе я обозначил проблему. И не только я, в интернете иногда об этом говорят. Что касается решения, то здесь как всегда нужно проводить опыты.
