Автор:
Некоторое время назад меня попросили рассказать или дать ссылки на историю развития IT-разработки, в которой была бы видна внутренняя логика развития, а не просто факты и события. Казалось бы, об этом должны быть книги или обзорные курсы, ведь логика развития IT-разработки в значительной мере овеществлена в логике развития языков программирования, и только в последние лет двадцать к этому добавилась логика развития фреймворков, платформ и концептуальных подходов к проектированию. Но я не нашел хороших источников.
Поэтому появился авторский текст, написанный, преимущественно, на основе моих собственных представлений. Он проверен по материалам википедии – там есть
История оказалась интереснее, чем я ее себе представлял. Мне было интересно ее писать и, надеюсь, вам будет интересно ее читать. При этом в статье наверняка осталось много моих собственных интерпретаций, которые не будут совпадать с вашими представлениями, и я буду рад обсудить различия.
Первый этап – компьютеры для вычислений
Первоначально компьютеры создавались для решения вычислительных задач. Они были исполнительным механизмом вместо человека и просто реализовывали вычисления на конечном рабочем месте.
Что интересно – массовые вычисления выполнялись задолго до компьютеров. Еще в конце 18 века во Франции была построена система, при которой большой коллектив людей разного уровня квалификации, в основном – владеющих только простыми действиями, вычисляли таблицы математических функций с высокой точностью – это было нужно для решения инженерных задач. Потом это система развивалась, и в 20 веке существовали большие счетные бюро, обеспечивающие нужды инженеров и конструкторов во многих отраслях промышленности – строительство, судостроение, авиация, военные и так далее. Но эту историю я рассказывать не готов, хотя и слышал ее в одной из
В любом случае, в конце был человек-счетчик, снабженный тем или иным арифмометром. Их-то и хотели заменить компьютером, задача была «сделать то же самое, но без человека как вычислителя».
Для разработки алгоритмов программ использовались Блок-схемы – визуальное графическое представление, показывающее последовательные шаги, циклы и ветвления алгоритма.
Первые программы писали непосредственно в машинных кодах – командах процессору, который их обрабатывал. Коды отражали конкретную архитектуру машины и развивались вместе с ней. Команда в машинных кодах «прибита гвоздями» к конкретному месту в памяти, где размещается она и ее данные, и эта привязка – наиболее жесткая. Когда ты объединяешь несколько программ для совместной работы, и оказывается, что они занимают одно и то же место в памяти, то одну из них надо переместить. Желательно, без переписывания и проверки ошибок, которые при этом возникают.
Эти задачи решали аппаратно: через команды вызова процедур, регистры для стековой организации памяти и базовых адресов и так далее. А в 1949 появилось программное решение – ассемблер. В нем команды записываются символически с мнемоникой, а не цифрами, программы можно вызывать одну из другой, вместо адресов данных указываются имена переменных и т.п. Это понемногу развивалось и совершенствовалось.
Ассемблер привязывался к конкретной машине и ее архитектуре, и это – проблема: при появлении новых, более совершенных компьютеров наработанные программы перенести было невозможно. В 1954-1957 был разработан Fortran (IBM) – первый язык, отвязанный от железа конкретной ЭВМ.
Назначение Фортрана – программирование вычислений. Поэтому из структур данных там только числа и многомерные массивы, а работа с символами – минимальна, чтобы написать сообщения человеку. Именно массивы нужны для написания программ по численному решению дифференциальных уравнений и других вычислительных задач. В результате произошел значительный подъем уровня абстракции в представлении программы: раньше формулы преобразовали в программы на ассемблере, а теперь – в программы на Фортране, имеющие значительно более читаемый вид.
Но это побочный, хотя и очень полезный эффект. Главная задача, которая была решена, – это то, что программы на Фортране можно достаточно комфортно переносить между компьютерами. Там есть сложности с различной точностью вычислений и объемами памяти, но по сравнению с ассемблером это значительный шаг вперед: созданное не пропадает с устареванием компьютера.
На Фортране написано громадное количество библиотек, реализующих различные вычисления, он живет, развивается и используется до сих пор. Отметим, что обобщение часто решаемых задач и реализация их в виде процедур, параметры которых задают вариативность реализации алгоритма и позволяют одну и ту же процедуру использовать в разных задачах, и формирование из этих процедур библиотек, которые полностью закрывают потребности какого-либо класса задач, родилось именно тогда. Это дало начало процедурной парадигме программирования.
При выделении процедур очень важна удачная параметризация. Например, при численном решении уравнений каким-либо методом возникает проблема с особыми точками и краевыми эффектами, для которых существуют вариации алгоритмов. И от того, какие вариации будут предусмотрены, зависит область применения процедуры. Фортран в этом смысле беден: в процедуру нельзя передать ссылку на другую процедуру для обработки особых ситуаций, нельзя добавить при доработке библиотеки параметры по умолчанию – все это появилось гораздо позднее, в продвинутых диалектах языка. Сейчас такие задачи решать легче, но удачное обобщение и параметризация по-прежнему остаются частью слабоформализованного искусства программирования.
Зарождение функционального и декларативного подходов
Развитие компьютеров в конце 1950-х вызвало волну энтузиазма по поводу потенциала создания искусственного интеллекта. Было понятно, что для решения этих задач будет нужен отдельный язык, выполняющий логические выводы – тогда надежды были связаны с таким подходом. Для решения задач искусственного интеллекта в 1955-1956 был создан Information Processing Language, из которого в 1958-1963 развился Lisp (историю можно прочитать в
Lisp дал начало функциональной парадигме программирования и декларативному подходу. Из этих подходов позднее выросли декларативные языки логического вывода Planner (1969), Prolog (1973) и другие, и функциональные языки Schema (1975), Haskell (1990) и Clojure (2007).
В 2008 Microsoft, помимо разработки собственного функционального языка F#, включило функциональную парадигму вместе с реляционной в объектный язык C#, положив начало мультипарадигмальным языкам программирования. Но это мы забежали сильно вперед. Вообще соотношению процедурного и декларативного подхода будет посвящена отдельная статья, это – очень интересный и актуальный вопрос.
Языки для самих программистов и бизнеса
Фортран обеспечил разработку программ для чисто вычислительных задач, закрыв потребности самого главного заказчика – военных, а заодно и других инженеров-проектировщиков. Однако, у бизнеса были и другие задачи. А главное, они были у самих программистов, они не слишком хотели писать компиляторы и системное обеспечение на ассемблере. А для этого нужна работа со структурами данных, а не просто с числами, и развитая работа с текстами и файлами.
Как и сейчас, программисты не слишком хотели разбираться в бизнес-задачах, поэтому решили придумать универсальное решение – разработать универсальный алгоритмический язык. И сделать это силами всего международного сообщества. Так начал появляться язык Алгол, Algorithmic Language. История рассказана в
И только тогда начали появляться первые реализации (список есть в английской статье), причем несколько из них сделаны
Я, кстати, в институте обучался именно на Алголе Курочкина на БЭСМ-6, который наш преподаватель любил за чистоту и полную реализацию первоначального стандарта, в отличие от более поздней реализации Алгола-68.
Проблема Алгола в том, что это прекрасный универсальный стандарт, невозможный для реализации. Попытки довести Алгол до приемлемого уровня, избавив от излишней сложности, начались сразу после создания и привели в 1968 к формированию стандарта
Долгая работа над универсальным языком Алгол и полуживой первый стандарт вызвали альтернативную ветвь развития языка для разработки бизнес-приложений, которым стал Cobol. История
На Коболе наработаны большие библиотеки приложений и поэтому он местами используется до сих пор и даже развивается… Такая долгая жизнь Cobol при его многочисленных недостатках непонятна и печалит сторонников «правильных» подходов к разработке, начиная со структурного программирования, появившегося в конце 60-х.
Но Кобол был ориентирован на бизнес-приложения, а программистам по-прежнему надо было писать компиляторы и системный софт. Дефицит языка общего назначения привел к появлению в 1964 году языка PL/I, его разработал IBM для своих компьютеров.
Неудача в доработке Алгола вызвала к жизни большое количество альтернативных разработок практического направления. Николас Вирт создал в 1968-70
Потребности разработки компиляторов и операционных систем привели к созданию в Bell Labs в 1968-69 языка C (Си) (
И в заключении интересно отметить язык
Развитие концепций программирования
Развитие концепций программирования начиналось с проработки императивной реализации алгоритмов базовой алгоритмикой. Эта работа к концу 1960-х в целом завершена выходом первых трех томов фундаментального труда Дональда Кнута
Параллельно с этим развивалась функциональная парадигма, о которой я уже говорил раньше, описывая язык Lisp. В основе функциональной парадигмы лежит некоторый математический аппарат, у ее применения есть своя ниша в части обработки тестов, графов и больших объемов данных. Этот математический аппарат позволяет очень эффективно распараллеливать вычисления, а это востребовано.
Работа над Алголом и дальнейшее развитие привели к формированию концепции структурного программирования (
Логическим завершением этапа эволюции подходов к разработке софта, начатой Алголом и продолженной другими языками, надо считать работу Николаса Вирта «Алгоритмы + Структуры данных = Программы» (1976), которая фиксирует следующий после алгоритмики Кнута этап развития концепций разработки софта.
В начале 1970-х появилась акторная модель, реализованная в языке
В 1974, с развитием обработки больших объемов данных, появилась модель реляционных баз данных и язык SQL, реализующий реляционную парадигму программирования. В ее основу лег специальный раздел математики – реляционная алгебра. Что интересно, реляционную алгебру необходимо понимать для реализации движков СУБД, но вот для использования SQL, включая построения сложных запросов, понимание реляционной алгебры вовсе не является необходимым, гораздо проще это объяснять другим образом. К этому я еще вернусь в следующих статьях.
Есть мнение, что во второй половине 1960-х зародился ООП, объектно-ориентированный подход. Однако,
На рубеже 80-х появился не только ООП вместе с языком C++, произошло еще одно принципиальное событие – появились персональные компьютеры. И это принципиально изменило задачи, стоящие перед IT-разработкой. Главное изменение состояло не в том, что появились компьютеры для домашнего использования, и потребовался софт для работы на них: текстовые и графические редакторы, компиляторы и средства разработки, базы данных и игры – это все так или иначе перенесли с больших компьютеров. Вопрос был в оптимизации и адаптации под ограниченные ресурсы. Главное изменение в том, что персоналки сделали компьютеры доступными небольшим компаниям, и потребовались системы автоматизации бизнес-процессов, которые сильно отличаются в разных компаниях, и типовую систему сделать сложно. И как раз эту задачу помог решить ООП. Но об этом мы поговорим в следующей статье.
А в заключении этой я хочу сказать, что мое знакомство с миром больших компьютеров не теоретическое. Основным студенческим компьютером в период моего обучения на Физтехе была БЭСМ-6. Персоналки пришли в СССР, только когда я уже был уже на старших курсах, и основным рабочим языком там был Forex, структурный диалект Фортрана, в котором были добавлены структуры данных и указатели, но не было динамического распределения памяти. Алгол и Паскаль тоже были, но их реализации заставляли желать сильно лучшего по объективным причинам. Алгол – тяжелый, а эффективную реализацию Паскаля сложно сделать на компьютере, где отсутствует побайтовая адресация и команды, все работает с 48-битными словами. И поэтому все эффективные операции со строками надо отдельно писать ассемблере.
Я там занимался системным программированием, это было интересно. Одним из результатов был многопользовательский интерактивный текстовый редактор, который в одном процессе обслуживал до 8 пользователей, редактирующих свои файлы с подключенных терминалов. Потому что на уровне ОС было ограничение на 15 пользовательских процессов, из которых только 6 интерактивных с пользователями, а подключенных терминалов было много больше. Там было много интересных задач: эмуляция потоков и обработка прерываний, управление памятью и так далее. Аналогичные системы были, но ресурсоемкие и с проблемами в эргономике. Поэтому когда редактор написали, то его быстро внедрили и он завоевал популярность, а я ощутил, что такое сопровождение системы, которая иногда сбоит и падает, теряя или портя пользовательские файлы. Несколько лет все это жило, а потом пришли персоналки, и я с большим интересом окунулся в мир разработки на C++.
На этом я завершаю статью. Продолжение следует…
Оригинал: История IT.
История IT. Когда компьютеры были большими…, опубликовано К ВВ, лицензия — Creative Commons Attribution-NonCommercial 4.0 International.
Респект и уважуха