Адмиралы и Грейс

Вернёмся еще на немного в доисторическую эпоху динозавров от ЭВМ.
Я уже давно обращал внимание на странный синтаксис арифметики в древних языках программирования — например ABAP от SAP/R3, где складываются числа вот такой многобуквенной конструкцией:

Код (Text):

1.  
2. ADD x WITH y TO z
3.  

т.е., выражаясь современным языком: z=x+y.
Или вот пример на языке COBOL: http://www.csis.ul.ie/cobol/examples/Accept/Multiplier.htm

Код (Text):

1.  
2. MULTIPLY Num1 BY Num2 GIVING Result.
3.  

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

Грейс с детства была такой любознательной, что в возрасте семи лет разобрала семь будильников пытаясь понять как они работают. Эта тяга к знаниям вела её сквозь всю жизнь и в 1949–ом году привела к одной из первых полноценных ЭВМ — компьютеру UNIVAC.

Архитектура UNIVAC довольно необычна даже для 60–х годов.

Хотя слово в этой ЭВМ состояло из 72 бит, но машина применяла десятичное кодирование чисел. Каждое слово трактовалось как строка из 12 шестибитных символов (буквы, цифры, знаки препинания), а если в ячейке хранилось число то оно хранилось как 12 цифр в этой же самой кодировке (цифры кодировались начиная с символа с кодом 3). Однако еще первый символ отводился весь под знак и таким образом в эффективном числе было 11 значащих цифр. Машинные инструкции занимали 6 символов слова — в каждом слове помещалось поэтому две инструкции (они назывались левая и правая) при этом три первых символа означали обычно человекочитаемый код инструкции, а последние три символа чаще всего содержали цифры ссылающиеся на ячейку памяти с которой инструкция (однооперандная) работала — таким образом получилась, что в юниваке было 1000 ячеек памяти максимально.

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

Такое отношение к данным сильно отразится на линейке компиляторов, которые Грейс разработает на этой ЭВМ и ляжет в основу системы определения данных языка COBOL, который на 95% по словам самой Хоппер и будет состоять из её разработок.
В COBOL данные описываются так: http://www.csis.ul.ie/cobol/course/DataDeclaration.htm
После имени переменной идёт ключевое слово PIC и далее задаётся как бы посимвольная маска того что в переменной находится из следующих символов:

Код (Text):

1.  
2. 9 — цифра числа
3. X — любой символ
4. A — символы от A до Z плюс пробел
5. V — место где находится десятичная точка (сама точка не хранится)
6. S — знак, может находится только в начале
7.  

Кроме того в круглых скобках можно записать число повторений символа слева для краткости.
Таким образом аббревиатура S9(6)V9(3) означает число со знаком с шестью цифрами до запятой и тремя цифрами после запятой.

Думаю понятно, что такой подход явно продиктован внутренним устройством UNIVAC.

Но вернёмся к Грейс Хоппер — под руководством этой женщины был выпущен первый в мире компилятор, названный A–0. Далее он претерпел цепочку изменений A–1, A–2, A–3 и B–0.
Любопытно, что программы на A–3 состояли из нумерованных строк, как в Basic 1.x, но при этом еще номера строк должны были быть окружены круглыми скобками и было доступно максимум 2 символа, таким образом официально в этом языке программы не могли превышать ста строк кода, которые еще размещались на перфокартах и каждая потому не могла быть длиннее 80 символов.
Насколько я понял в линейке A–X Хоппер использовала математическую нотацию — x+sin(y) и так далее. Но как раз с B–0, известном еще как FLOW–MATIC происходит еще одна "революция сознания" — математическая нотация уступает место "человекочитаемому коду".
Грейс становится еще и изобретателем концепции "natural language programming", т.е. программирования на понятном человеку языке.
Между прочим смена буквы "A" на "B" в B–0 происходит слова "business" — бизнес, в то время как изначальная "A" означала "arithmetic" — арифметический язык (надо ли напоминать, что упомянутый в самом начале SAP/R3 — это как раз на 100% business?).
Как уже отмечено выше в дальнейшем B–0 ляжет в основание языка COBOL, который до сих пор имеет огромное легаси в банковской сфере. Вообще это моё небольшое исследование родилось из замечания одного хорошего знакомого программиста, что у его компании появился клиент которому нужен обмен данными в формате чисел как раз из COBOL.

Так вот, далее процитирую саму Грейс Хоппер из английской википедии:

"I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would.... They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make them first attempt to teach those symbols to vice–presidents or a colonel or admiral. I assure you that I tried it."

мой перевод:

"Когда то я работала профессором математики. В то время я обнаружила, что некоторое количество студентов не могли обучиться математике. Далее мне поручили работу по упрощению применения компьютеров для бизнесменов. Тут уже я обнаружила, что не стоит вопрос смогут они обучиться математике или нет. Вопрос стоит в том будут ли они вообще её изучать.... Они говорили 'выкиньте эти символы отсюда, я не знаю что они означают и у меня нет времени заучивать символы'. Заранее отвечу тем, кто считает, что людям в обработке данных надо использовать математические символы — попробуйте сперва обучить тому что эти символы значат вице–президентов, полковников или адмиралов. Уверяю вас — я пыталась."

Так вот откуда растут ноги у этих самых ADD x TO y — от вице–президентов и адмиралов с которыми Невероятная Грейс так и не смогла справится, что пришлось изобретать новое направление в языках программирования.

 

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

 

Мне это тоже сперва показалось дико, но подумав, я решил, что нельзя списывать со счетов эпоху - flow-matic разработан в середине 50-х годов прошлого века и по видимому грамотность была совсем совсем не так распространена и привычна как сейчас. И скорее всего типичная инструкция/шпаргалка для бухгалтера действительно описывала процесс извлечения НДС словами, а не формулами, что надо доходы просуммировать, вычесть расходы и потом умножать-делить. Академический стиль был не настолько вживлён в жизнь чтобы общаться с девушками которые обсчитывали гросс-бухи на счётах языком формул. И это касалось всего.
И когда глядишь на то, как выглядел вычислительный центр с дорогостоящим оборудованием 100 лет назад, то явственно чувствуется, что реальность была осязаемо другой:

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

 

aa_dav, не могу согласится, что публика в те времена была такой уж безграмотной - вот кто сейчас быстро сможет посчитать на счётах, чертить в ручную и пользоваться логарифмической линейкой??? потом, если мы возьмём бум инженерной деятельности, то он во многом был без компов (даже в западных странах). 1ые цифровые компы стали появляться в 4оых, к 70ым стали широко использоваться.. а к 2000ым уже сильно просела инженерная деятельность и сий факт замаскировали ростом игровых компов. в начале же выч техники все прогеры были сугубо инженерами, тч графоманство кобола уж никак невозможно записать на то, что те ребята не могли понять мат запись.

 

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

 

кобол казался нормальным лишь очень ограниченному кругу извращенцев, но (конечно) по-своему уникальный яп

 

На счёт этого кобола, а с чего взяли что это высокоуровневый ЯП? Что ассемблер, что этот ваш кобол: add eax,666 vs ADD 666 WITH a TO a
Ну и хрееееньььь, я лучше на ассме буду кодить, хоть проекты на 100 млн строк чем этим. Ну что с них с пиндосов взять.

 

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

Как мы помним из рассказа выше - первые версии того что она называла компилятором назывались A-0, A-1, A-2 и A-3 в порядке совершенствования.
Похоже что A-0 и A-1 не особо вышли из застенок лаборатории, поэтому первые публикации которые можно прочитать касаются уже A-2: http://bitsavers.trailing-edge.com/pdf/computersAndAutomation/195510.pdf (начиная с 15-ой страницы, англ.)
Так вот - оказывается, что этот язык не очень то и компилятор, а скорее виртуальный ассемблер для виртуальной машины.
Напомню еще раз что за машиной являлся сам UNIVAC - это была машина память которой состояла из тысячи 72-битных слов которые на машинном уровне разделялись на 12 шестибитных алфавитно-цифровых символа.
Вообще само понятие "машинного слова" как именно "слова" судя по всему возникло как раз на этой первой американской полноценной ЭВМ - ибо ячейки памяти её действительно по факту являлись 12-буквенными словами.
Даже числа представлялись как просто последовательности символов цифр в кодировке этой машины (символ нуля имел код 3, далее по нарастающей и сразу следом - буквы и некоторые знаки препинания) занимающих всё слово.
Машинные инструкции состояли из 6 символов каждая, таким образом в одном слове их помещалось две - первую называли "левой", а вторую - "правой". Выполнялись они просто по очереди.
Первые три символа отводились под код инструкции, а вторые три - под номер ячейки памяти, откуда и возникало ограничение в 1000 ячеек памяти у UNIVAC.
Еще раз напоминаю, что нумерация осуществлялась сильно избыточно трактуя номер ячейки как алфавитно-цифровое представление в памяти в котором использовались только коды цифр, алфавитная же информация не имела смысла и по сути биты памяти не использовались рационально.
Типичная последовательность инструкций для сложения двух ячеек памяти с номерами 111 и 222 выглядит примерно так:
L00111 A00222
; первая (левая) инструкция в слове L00 загружает в аккумулятор содержимое ячейки 111
; (L от LOAD, остальные два символа триады кода инструкции добиты нулями)
; вторая - (ADD) - складывает аккумулятор с ячейкой 222
S00333 ...... ; сохраняем аккумулятор в ячейку 333
Я тут использовал не настоящие коды UNIVAC - просто для понимания общей концепции.
В реальности буквы другие, но принцип такой.
И вот приходит Грейс и делает компилятор A-0/1/2.
Что из себя представляет A-2 на деле - это виртуальный ассемблер в котором каждое слово UNIVAC представляет собой одну длинную 12-символьную инструкцию.
За счёт расширения длины инструкций они несут больше полезной нагрузки.
Например почти все арифметические инструкции трёхоперандные - в них указываются три номера ячеек памяти для как бы A = B & C, где & это операция.
Например сложение ячеек памяти выглядит так:
AA0111222333
Здесь первая буква A означает, что операция принадлежит к категории "Arithmetic" (арифметика), вторая буква A - что это операция "Add" сложения, последующий ноль просто добивает код операции до длины три и далее идут 3 номера ячеек памяти - сумма первых двух будет помещена в третью.
Другой пример:
TS0111000222
T - класс тригонометрических процедур
S - Sinus (Синус)
все нули - просто добивка незначащих разрядов нулями
В итоге в ячейку памяти с адресом 222 помещается синус от значения в ячейке памяти 111
Этот ассемблер не знает еще меток - номера ячеек памяти программист должен был помнить сам.
Все его упрощения - это лучшая систематизация операций по классам и трёхадресная система адресации.
После прогонки через транслятор эти инструкции превращались в вызовы процедур нативного кода на UNIVAC.
Таким образом A-0/1/2 это предтечи языков программирования - виртуальные ассемблеры.
Версия A-2 получила побочное название ARITH-MATIC и по сути была больше похожа на библиотеку математических процедур с удобным, но ассемблероподобным синтаксисом их вызова - программирование на этом было подобно программированию на голых машинных кодах без меток и прочих удобств так привычных современному программисту.

Но в A-3 происходит резкое усложнение концепций - эта штука как раз уже начинает походить на традиционный ЯВУ с математической нотацией и имеет брендовое название MATH-MATIC:

Код (Text):

1.  
2. (2)  TYPE-IN ALPHA .
3. (2A) READ A B C SERVO 4 STORAGE A IF SENTINEL JUMP TO SENTENCE 8 .
4. (3)  READ D F SERVO 5 .
5. (4)  VARY Y 1 (0.1) 3 SENTENCE 5 THRU 6 .
6. (5)  X1 = (7*103*Y*A*SIN ALPHA)3 / (B POW D+C POW E) .
7. (6)  WRITE AND EDIT A Y D E X1 SERVO 6 .
8. (7)  JUMP TO SENTENCE 2A .
9. (8)  CLOSE-INPUT AND REWIND SENTENCE 3 .
10. (9)  CLOSE-OUTPUT SENTENCE 6 .
11. (10) READ F G H N SERVO 4 STORAGE A IF SENTINEL JUMP TO SENTENCE 20 .
12. (11) EXECUTE SENTENCE 3 .
13. (12) X2 = (3 ROOT (E-G)+LOG (D+N)) / (F2.6*EXP H) .
14. (13) WRITE EDIT F D F X2 SERVO 6 .
15. (16) JUMP TO SENTENCE 10 .
16. (20) STOP .
17.  

(код с вики)

Таким образом совершенно верно замечание выше - мы действительно имеем плавную эволюцию от неудобного и многословного машинного кода UNIVAC к упрощению кода с помощью "виртуального ассемблера" где библиотечные процедуры типа SIN или TAN выглядели как просто инструкции виртуальной машины и только потом по настоящему к человекочитаемому коду с математическими формулами.
И действительно сделать тут шаг в сторону "business модели" где вместо математических закорючек пишется словами конкретное действие ADD A TO B RESULT IN C было даже проще, чем парсить формулы.

 

эти мат "закорючки" как-то сильно проще: "c = a + b" == 5 значащих символов + несколько пробелов и символ-разделитель. кобол же чудовищен как для прогера, так и для машины - такое графоманство попросту избыточно, даже хелоу ворлд в реферат превращается//

Код (Text):

1. IDENTIFICATION DIVISION.
2. PROGRAM-ID. IDSAMPLE.
3. ENVIRONMENT DIVISION.
4. PROCEDURE DIVISION.
5.     DISPLAY 'HELLO WORLD'.
6.     STOP RUN.

 

Как видно код на A-3 тоже пестрит штуками типа "CLOSE-INPUT AND REWIND SENTENCE 3", т.е. он не проще в плане вот этих "сетапов для операций ввода-вывода".
А речь про арифметику - на вики той же в статье про MATH-MATIC можно так же увидеть, что транслируется он не напрямую в машкоды UNIVAC, а в... A-2, т.е. виртуальный трёхадресный ассемблер разработанный Грейс ранее.
И вот тут действительно происходит резкое упрощение в B-0: ADD x WITH y TO z действительно просто и естественно транслируется в трёхадресную инструкцию одноимённую A-2 и не требует разбора приоритетов, сохранений промежуточных результатов выражения и прочего - это реально проще транслировать в разы. Собственно тут видно как переплетаются все эти штуки в одну продолжительную серию мозговых штурмов и как новые концепции возникали по ходу внедрения предыдущих концепций.

 

сам кобла за гранью добра и зла, а тута ещё они его и с жабой скрещивают https://www.ibm.com/docs/en/cobol-z...ty-outside-object-oriented-oo-cobol-framework