История программирования. Фортран

* "Магия ПК" 2000 №6(28), С. 49–50.

    В 1955 году увидел свет первый алгоритмический язык высокого уровня FORTRAN (FORmula TRANslator – транслятор формул). Он использовался в основном для решения научно-технических и инженерных задач, а разработали его сотрудники фирмы IBM под руководством Джона Бэкуса. Чуть позже, в 1957 году, Джон Бэкус и его сотрудники установили в IBM (Beстингхауз) первый компилятор языка Фортран. Программисты, ранее работавшие исключительно на Ассемблере, скептически относились к возможностям высокопроизводительного языка высокого уровня, поэтому основным критерием при разработке стандартов на Фортран и создания компиляторов с этого языка была эффективность исполняемого кода. Кстати, термин "компилятор" тогда еще широко не использовался, хотя уже был введен Грейс Хоппер – единственной в США женщиной-адмиралом, которую называли также "первой леди программирования и бабушкой Кобола".
    Большинство операторов Фортрана транслировались непосредственно в одну–две машинные команды, простые синтаксические конструкции и активное использование меток и goto позволяло получить очень быстрый код, и в результате программы на Фортране подчас работали быстрее ассемблерных. Сама внутренняя структура оттранслированной программы была также очень простой – весь код, все подпрограммы и все данные вместе с общим блоком размещались исключительно в статической памяти, из-за чего, правда, невозможно было использовать рекурсию.
    Поскольку Фортран был первым языком высокого уровня, отвечающим нуждам большинства пользователей того времени, да еще и простым в изучении, распространился он очень быстро.
    Из-за широкого распространения этого языка и появления множества Фортран-программ (преимущественно вычислительного характера) насущным стал вопрос его стандартизации. Сначала это был стандарт Fortran IV 1964 года, затем, по мере появления новых идей, в 1978 году был принят новый стандарт Fortran 77 (f77) с большим числом более современных и гибких синтаксических расширений. Сегодня наиболее распространенным вариантом Фортрана являются Fortran 90 (f90) и Fortran 95. Группа энтузиастов заканчивает работу над суперверсией языка F2k, которая будет опубликована в этом году.
    Хотя в новые версии языка вносились подчас как ненужные дополнения (например, расширения, связанные с динамической аллокацией памяти), так и полезные, типа модульной организации программы, работы с частями массивов и др., сегодня этот язык нельзя назвать перспективным для изучения, так как синтаксис его значительно устарел.
    Однако тем, кому довольно часто приходится решать различные вычислительные задачи, совсем не обязательно каждый раз брать в руки учебник по математике и "начинать с нуля". В 90% подобных случаев то, что вы ищете, уже давно реализовано и отлажено на Фортране. Поэтому, скорее всего, жизнь Фортрану обеспечена надолго.
    Есть и еще одна, сравнительно молодая ниша для Фортрана – параллельные вычисления, где строгая семантика языка позволяет получать высокопроизводительные программы. Обычно используется стандарт f90, немного расширенный набором операторов для указания пригодных к распараллеливанию частей программы. Параллельный Фортран имеет свой стандарт HPF (High Performance Fortran). Тем не менее фанаты Фортрана, девизом которых стала легендарная фраза "Зачем мне изучать другие языки, когда я могу всё написать на Фортране", ощущали его очевидную непригодность для крупномасштабных проектов, связанную с привязанностью к синтаксису 50-х годов, и пытались ввести в него модные идеи ООП, но объектный Фортран в качестве стандарта так и не появился.
    Среди бесплатно распространяемых версий Фортрана наиболее известен f2c, реализованный для всех UNIX-систем и преобразующий текст Фортран-программы в Си-код. Для DOS имеется версия bcf77, распространяемая бесплатно. Из коммерческих версий в первую очередь надо отметить Microsoft Fortran, позволяющий создавать dll-библиотеки, и Watcom Fortran, генерирующий высокоэффективный код. Для задач, требующих высокой точности вычислений, предназначен компилятор фирмы MicroWay. А вообще различные по качеству компиляторы Фортрана имеются на абсолютно всех компьютерных платформах.
    Однако основная заслуга Фортрана в другом. Когда появилась необходимость в разработке очень крупных проектов, недостатки Фортрана, связанные в первую очередь с "тяжелой" отладкой, стали излишне обременительны. Поэтому Фортран послужил сильнейшим стимулом для развития теории отладки и тестирования программ. Появились сотни синтаксических верификаторов Фортран-текстов, вылавливающих скрытые логические ошибки. В дальнейшем из этого направления выросли такие теоретические области программирования, как эквивалентные оптимизирующие преобразования программ, высокоуровневая компиляция, автоматическое тестирование и т.д. Так что про Фортран забывать никак нельзя. Использовать его в качестве инструментария в задачах системной интеграции, наверное, не имеет смысла, но то, что было наработано лучшими программистами за 30–40 лет, вполне может ускорить процесс разработки. По крайней мере, программных "кирпичиков" для Фортрана ныне существует несравненно больше, чем для других языков программирования. ■

* * *
    Джон Бэкус родился 3 декабря 1924 в Филадельфии, штат Пенсильвания, в богатой семье, детские годы провел в Вилмингтоне. Закончив школу в 1942 году, он поступил в университет штата Вирджиния на химический факультет (по настоянию отца-химика), но спустя некоторое время перестал заниматься и в 1943 году был призван на военную службу.
    Бэкус начинал служить в бригаде противовоздушной обороны в форте Stewart, штат Джорджия, но впоследствии был направлен в колледж для изучения медицины.
    Некоторое время он с увлечением работал в городской больнице, но в 1946 году охладел к этой работе, оставил армию и переехал в Нью-Йорк, хотя не знал за что браться и как жить дальше.
    Через некоторое время Бэкус поступил в школу подготовки радиотехников. "У меня был очень хороший преподаватель, и он попросил, чтобы я вычислил характеристики некоторых схем. Это было страшно утомительно, но крайне интересно".
    Вскоре Бэкус поступил в Колумбийский университет (Нью-Йорк), чтобы изучать математику, где и получил высшее образование (1949 г.). Незадолго перед тем, как закончить обучение, он посетил компьютерный центр IBM на Мэдисон Авеню. И здесь удача во второй раз улыбнулась ему – в 1950 году Бэкус стал программистом компании IBM.
    О доминировании IBM в компьютерной индустрии впервые заговорили в 1952 году. Всё началось с модели 701, известной также под именем Defence Calculator (оборонный вычислитель). Сразу после выпуска модели 701 специалисты подразделения прикладных исследований приступили к ее совершенствованию (1955–1956 годы).



    Наиболее серьезные изменения предложил внести Джон Бэкус, впоследствии принимавший активное участие в создании компьютера 704. В частности, благодаря ему появилась технология так называемого "ускоренного кодирования" (speed-coding), позволившая заметно упростить написание программ для 701. "Возможность ускоренного формирования кода для машины 701, которая представляла собой одноадресный компьютер с фиксированной запятой без индексных регистров, превратила ее в систему с плавающей запятой, произвольной адресацией и индексными регистрами, – вспоминал Бэкус. – Таким образом, пользователям больше не нужно было мучиться с двоичным кодом".
    Уже тогда появились первые компоненты технологии быстрого написания программ, которая используется сегодня. Фактически данная система стала предшественницей аналогичных комплексов, которые были выпущены в 50–60 годах и впоследствии вытеснены языками высокого уровня.
    А в 1955 году Бэкус "изобрел" Фортран, первый машинный язык высокого уровня. Впоследствии, вспоминая этот период, Бэкус скажет: "Мы не знали, к чему стремиться, и не знали, как это сделать". Первоначально все работы планировалось завершить в начале 1954 года, однако разработка языка завершилась практически через два года.
    Первая версия компилятора состояла из 25000 строк машинного кода, записанного на магнитной ленте. Каждая IBM 704 обеспечивалась копией программы с руководством по программированию на 51 странице.
    В 1959 году Бэкус разработал грамматические правила для описания синтаксиса языков высокого уровня (нормальная форма Бэкуса-Наура, сокращенно БНФ).
    В 1976 году Джон Бэкус был награжден Национальной медалью за вклад в науку, а с 1991 года перестал заниматься компьютерной тематикой.

Владимир Буслаев

OCR: fir-vst, 2016

Программирование "с нуля". Как изучать системное программирование

* "Магия ПК" 2000 №5(27), С. 43–45.

    Итак, вопреки всякой логике вы всё же решили научиться писать программы. Причем именно писать, а не "ваять" наскоро что придется и как придется. Неважно, что сподвигло вас на это решение, – стремление получить престижную профессию, врожденная любознательность, желание выделиться среди друзей или взломать сервер Пентагона. В любом случае вам придется пройти тернистый путь, лишь изредка перемежающийся минутами подлинного торжества.
    О том, с чего нужно начинать учиться программированию, сказано немало. Неоднократно писала об этом и "Магия ПК". Однако многое из того, что советуют профессиональные педагоги, на практике оказывается более чем спорным. А потому взглянем на эту проблему еще раз – с позиций практики.

Антиутопия компьютерной педагогики
    Во многих современных учебниках по программированию настоятельно рекомендуется начинать с освоения какой-либо системы визуального программирования – Delphi, C++ Builder, Visual C++ или Visual Basic. При этом приводятся следующие аргументы:

• визуальные среды позволяют быстро получить привлекательный результат;
• все современные системы программирования ориентированы на объектный подход; к чему учиться устаревшим парадигмам, если ООП – наиболее современен?
• визуальные среды – профессиональный инструмент, знание которого пригодится в будущей работе.

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



    Еще более спорным является тезис о целесообразности начинать изучение программирования непосредственно с объектного подхода. Спору нет, ООП – прогрессивная и современная технология, однако это – не панацея. И сейчас во многих случаях решения, диктуемые этим подходом, оказываются далеко не оптимальными. Но не это главное. Главное заключается в том, что идея программного моделирования предметной области, лежащая в основе концепции ООП, слишком сложна для восприятия без предварительной подготовки. И если понять сам принцип восприятия мира как множества взаимодействующих сущностей при наличии определенного философского фундамента еще возможно, то осознать, как исполняется объектная программа на ЭВМ, – почти непосильная задача.
    Наконец, третий тезис также не бесспорен. Во-первых, потому что изучение программирования лишь на несколько процентов состоит в освоении конкретной среды, а большую часть времени и сил приходится тратить на осознание общих принципов, формирование специфики мышления, ознакомление с типовыми подходами и приемами. Во-вторых, практика показывает, что профессиональному программисту труднее всего работать именно в той среде, с которой начиналось его обучение.
    Это легко объяснимо – на начальной стадии каждый из нас делает массу ошибок, формирует множество неверных представлений, которые впоследствии пересматриваются, однако оставляют заметный след в нашем сознании. И, вторично оказываясь в той же ситуации, с которой ему приходилось сталкиваться в процессе обучения, специалист как бы теряет накопленные профессиональные навыки и непроизвольно ищет решение на основании давних ассоциаций новичка. По крайней мере таково его первое движение, а именно оно играет основную роль в принятии разработчиком ключевых проектных решений.
    Однако главное заключается в другом: использование визуальных сред, во всяком случае правильное использование, полностью заслоняет от пользователя архитектуру машины, специфику выполнения ею написанной программы. А между тем, для того, чтобы программирование не превращалось в мистический процесс укрощения своенравного компьютера, а оставалось ремеслом, профессией, очень важно, чтобы разработчик хорошо понимал принципы выполнения своей программы. И с этой точки зрения обучение на основе визуальных сред и ООП бессмысленно, ибо человек, наученный таким образом, подобен монтеру из известной рекламы – работающая программа невольно вызывает у него восклицание: "Ё-мое, что ж я сделал-то?"

"К четырем прибавить два..."
    Интересно, что идея начинать обучение с конца характерна только для программирования. В самом деле, никто ведь не пытается преподавать релятивистскую механику прежде законов Ньютона! Все науки прошли долгий путь развития, множество ошибочных и неточных теорий, некорректных экспериментов. Школьник, изучая их, как бы повторяет за несколько лет всё, что делало человечество в течение тысячелетий. Бессмысленная трата времени? Нет! Двигаясь таким образом, ученик как бы сам приходит к тем же выводам, что и его великие предшественники.
    Отчего же не начать программирование с начала? Нет, не с тумблеров и светодиодов разумеется, но с фон-неймановской архитектуры и понятия программы как последовательности исполняемых команд. Естественно, рассматривать принципы машинной организации "всухую", особенно если вы молоды и честолюбивы, совсем неинтересно. А потому, если уж начинать писать программы, то лучше всего сразу осваивать язык ассемблера.
    Парадокс? Ведь Ассемблер по сей день считается едва ли не самым сложным из языков программирования. Однако на самом деле он имеет немало достоинств именно с точки зрения "обучения с нуля".
    Во-первых, Ассемблер прост. Это не просто сенсационное заявление – это факт. Архитектура компьютера, будь то IBM-совместимый ПК или промышленный контроллер от Toshiba, как правило, сравнительно проста – память, регистры, стек. Несколько видов адресации да условные и безусловные переходы. Порождаемый каждой командой эффект обычно тривиален для понимания, а потому весь процесс изучения сводится к механическому запоминанию мнемоник инструкций. Если последние достаточно логичны, как, например, в Ассемблере процессоров Intel, учить машинный язык совсем несложно.
    Во-вторых, изучая язык Ассемблера, учащийся волей-неволей вынужден сталкиваться с архитектурными особенностями своего компьютера. Такие понятия, как сегменты памяти, порты или escape-последовательности из чисто абстрактных категорий становятся инструментами для решения прикладных задач. Более того, понимая, можно ли реализовать ту или иную программу на Ассемблере, хотя бы теоретически, программист ощущает пределы возможностей машины, осознает, что можно требовать от компьютера, а что – нет.
    Еще одно несомненное преимущество заключается в том, что переход от Ассемблера к языку высокого уровня значительно проще, чем наоборот. Осваивая C++ или Паскаль, ассемблерщик представляет себе, как работает та или иная конструкция на уровне машинного кода, во что она будет скомпилирована. Соответственно, он понимает свою программу, не боится ее.
    Кроме того, и это психологически важно, Ассемблер благодаря своей универсальности рождает уверенность, что в случае необходимости отдельные фрагменты программы могут быть написаны или отлажены на самом низком уровне. А это – пусть эфемерная, но всё же гарантия того, что любая техническая проблема может быть решена, пусть большой кровью, но наверняка.
    И, наконец, даже сейчас язык Ассемблера иногда бывает полезен и даже незаменим. И не только при программировании для спецмашин, контроллеров и другого "экзотического" оборудования, но и при разработке некоторых программ для ПК – драйверов, системных утилит, фрагментов операционных систем, при реализации алгоритмов, требующих повышенной производительности.
    Очень часто основным недостатком Ассемблера называют громоздкость написанных на нем программ и сложность их тестирования и отладки. Действительно, работать с десятками и сотнями тысяч строк кода самыми примитивными средствами нелегко. Но именно так рождается то упорство, та бесконечная настойчивость, без которой самый одаренный человек никогда не сможет стать хорошим программистом. Ибо для хорошего профессионала мало придумать красивый алгоритм, нужно еще уметь при необходимости дни и недели "выуживать" из него неуловимую, непонятную ошибку.

"Мы всё начнем сначала…"
    Если вы вознамерились начать учиться программированию с освоения Ассемблера, то небесполезно будет знать несколько азбучных истин, способных существенно облегчить учебный процесс.
    Во-первых – о книгах. Учиться программированию проще и эффективнее с книгой в руках, но достать в наше время хорошую книгу по Ассемблеру непросто. Чаще всего попадаются либо справочники по архитектуре ЭВМ, либо толстые учебники с массой примеров, лишающие читателя всякого удовольствия от самостоятельного творчества и мешающие воспринимать принципы построения программ, затмевая их массой ненужных деталей. Начинающему лучше всего подойдет простой справочник по системе команд процессора и функциям операционной системы. Удобным компьютерным вариантом такого пособия может служить система TechnoHelp.
    Не стоит пытаться писать на Ассемблере под Windows. Вообще, желание сразу получить красивые окошечки мало совместимо с последовательным изучением программирования. В данном же случае вы рискуете утонуть в массе ненужных и непонятных деталей.
    Первое, с чем следует ознакомиться, – организация ЭВМ: регистры, память, стек. Первые несколько программ логично написать максимально просто – несколько пересылок между регистрами и памятью, запись и чтение из стека, передачи управления, вызов процедур. Работу программ можно изучить по шагам (в режиме трассировки) в любом доступном отладчике – Turbo Debugger, AFD и даже MS Debug.
    Далее можно переходить к функциям DOS – выводу на экран, работе с файлами, распределением памяти. Последний шаг – программирование внешних устройств: динамика, таймера, параллельного и последовательного порта. Имея в запасе такой инструментарий, можно переходить к реальным задачам. Интереснее, но и сложнее всего разрабатывать резидентные программы и драйверы: овладев этим искусством, вы можете смело переходить к языкам более высокого уровня.

Доброе напутствие
    Чтобы закончить с общими рекомендациями по тому, как проще всего освоить язык Ассемблера, стоит дать еще несколько конкретных советов:
    1. По мнению большинства ассемблерщиков, лучший транслятор для IBM PC – TASM фирмы Borland. Версия, поскольку вы вряд ли будете писать очень сложные программы, решающего значения не имеет.
    2. Знание Ассемблера – не вершина, а только первая ступень к профессионализму. Если вам удалось в совершенстве овладеть этим языком, вы скорее всего хорошо представляете себе устройство компьютера и базовые принципы исполнения программ в однозадачной операционной системе. Это – необходимые навыки, но не более того.
    3. Закончив изучать Ассемблер, познакомьтесь с одним из процедурных языков, лучше всего Паскалем или C++ в режиме расширенного C. Только поняв особенности конструкций высокого уровня, овладев технологией структурного программирования можно начать готовиться к штурму ООП.
    4. Разрабатывая программы на Ассемблере, не стремитесь как можно шире использовать макросредства и специальные директивы компилятора. Во-первых, этим вы, скорее всего, сведете к нулю переносимость своей программы, во-вторых, для целей обучения значительно полезнее, чтобы каждая инструкция, исполняемая в программе, была написана вами собственноручно.
    5. Не "срисовывайте" готовые примеры. Возможно, есть люди, способные обучаться на чужом опыте эффективнее, чем на своем, но только мне такие не известны. Естественно, модификация работающих примеров позволит получать результат значительно быстрее, чем при работе "с нуля", только познавательный эффект от нее будет, увы, невелик.
    6. Стремитесь не только узнать, но и сделать: доделывайте работу до конца. Разработать хорошую программу на Ассемблере не просто, но если вы справитесь с этой задачей, быстрота и компактность вашего детища станут достойной наградой за труды.
    Дерзайте, леди и джентльмены!

Константин Хайт

OCR: fir-vst, 2016
Рисунок: Игорь Копельницкий ©

________
⇑ Лучшие книги по программированию. Топ-5
⇑ Лучшие книги по Java. Топ-5
⇑ История программирования. Фортран

14 признаков фашизма по Лоуренсу Бритту

1. Мощный и продолжительный национализм — фашистские режимы постоянно используют националистические лозунги, девизы, символы, песни и так далее. Знамена можно увидеть везде, как и символы флага на одежде и в общественных местах.
2. Пренебрежение к общепризнанным правам человека — из страха перед врагом и под предлогом обеспечения безопасности фашистские власти убеждают, что права человека могут игнорироваться в определенных случаях ради «необходимости». Людей заставляют «думать по-другому» или даже одобрять избиения, убийства.
3. Выявление врага: расовых, религиозных или национальных меньшинств, либералов, коммунистов, социалистов, террористов и т.д.
4. Преимущественное положение вооруженных сил — даже если в стране есть много острых внутренних проблем, вооруженные силы получают непропорционально большое бюджетное финансирование. Пропаганда навязывает привлекательный образ военных и военной службы.
5. Сильная дискриминация по признаку половой принадлежности — в фашистских правительствах доминируют мужчины. Отрицательное отношение к абортам и гомофобия.
6. Контроль над СМИ — они контролируются непосредственно правительством или косвенно через сочувствующих журналистов либо руководителей СМИ. Распространена цензура — особенно в военное время.
7. Маниакальное увлечение национальной безопасностью — страх используется как мотивационный инструмент правительства для давления на массы.
8. Переплетение религии и правительства — правительства фашистских стран используют религию как инструмент управления общественным мнением.
9. Защита корпораций.
10. Притеснение профсоюзов.
11. Презрение к интеллигенции и искусству.
12. Навязчивая идея преступления и наказания — при фашистских режимах полиции даются почти неограниченные полномочия. Люди во имя патриотизма во многих случаях предпочитают не замечать полицейских злоупотреблений, даже нарушение своих гражданских свобод. Часто создается национальная полиция с неограниченной властью.
13. Необузданное кумовство и коррупция — фашистскими режимами почти всегда управляют кланы приятелей и партнеров, которые назначают друг друга на правительственные должности и используют власть для защиты членов своего клана от ответственности.
14. Мошеннические выборы — выборы в фашистских государствах часто превращаются в фарс.