вопросы диагностики

[sab123]

Во втором документе из http://ramlamyammambam.livejournal.com/323487.html

http://keldysh.ru/papers/2014/prep2014_37.pdf
http://keldysh.ru/papers/2014/prep2014_38.pdf
:

<<
Вспоминается случай большого напряжения, когда уже близко к моменту начала полёта к Марсу мы на протяжении долгого времени не могли найти ошибку в колоде перфокарт с алгольной теорией движения Фобоса и Деймоса, присланной нам из Института теоретической астрономии. Героем найденной ошибки стал В.Б. Бритков, который, непрерывно транслируя эту колоду, методом деления пополам выделил, наконец, ту единственную перфокарту с ошибкой. На перфокарте – несколько операторов Алгола. И вот – на протяжении недели не менее 5 пар глаз безуспешно пытались найти причину непонятных сообщений транслятора об ошибке. Причиной оказалась тривиальной: вместо квадратных скобок в некоем месте перфокарты были набиты фигурные! Ситуация со скобками Алгола знакома многим, а нам после этой истории – особенно...
>>

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

Ну и кстати, прислать программу, которая не компилируется? Видимо, вопрос о том, правильно ли она работает, тем более не проверялся.

Comments

[juan-gandhi.livejournal.com]

Какой это год был? У них, может, и АЦПУ не было, а была узкая печать, где весь текст выдавался в виде трехзначных кодов символов, и надо было насобачиться его читать.

Потом этот алгол улучшили, конечно, и на АЦПУ уже вполне приличные сообщения об ошибках выдавались.

Послали же то, что было готово в срок. Как сказала однажды моя начальница, "программа разработана, но еще не написана".

[sab123.livejournal.com]

Вроде при полетах к Венере, вроде где-то середина-конец 60-х. Про АЦПУ не знаю, но пишут, что картинка из журнала с длинным рулоном широкой бумаге была похожа на действительность. Да и номер строки можно выдать цифрами.

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

[spamsink]

Самый сок процитированного абзаца в том, что ни в советских кодировках (ГОСТ 10859-64) не было фигурных скобок, ни в IBM-овских.

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

[sab123.livejournal.com]

А какая у них там была кодировка на БЭСМах? Возможно, что фигурные скобки заменялись какой-нибудь парой символов?

[spamsink]

Я же говорю. На БЭСМах официальная кодировка была http://en.wikipedia.org/wiki/GOST_10859#7-bit_code:_Cyrillic_.26_Latin_upper_case_letters

Идея фигурных скобок могла возникнуть только с распространением ASCII/ISO, но в русских вариантах этих кодировок на месте фигурных скобок были буквы Ш и Щ. Паскалевские {* ... *} превратились в (* ... *), а { ... } исчезли совсем.

[juan-gandhi.livejournal.com]

Я вообще не помню никаких фигурных скобок в алголе, на самом деле.

[spamsink]

Разумеется, их не было, иначе бы они были в кодировке ГОСТ, в которую вошли все алгольные значки.
Но очевидно, что там были не фигурные скобки, а что-то допустимое, иначе алгол тут же выругался бы "в языке нет символа зю" и указал бы на правильную строку.

[amarao-san.livejournal.com]

В этом вся драма. computer science идёт огромными шагами, а software engeneering тащится в хвосте, до сих пор не решив для себя раз и на всегда проблему с зависимостями (как только её решают, тут же появляется новая система, в которой эту проблему начинают решать ещё раз).

[sab123.livejournal.com]

Что за проблема с зависимостями?

Ну а что касается диагностики, то тут наверное как всегда: наверное компилятор писали люди, постигшие computer science, но не постигшие software engineering. Software engineering - гораздо более сложная дисциплина.

[sab123.livejournal.com]

Логично. Да и как ввести символ не в кодировке? А каких-нибудь угловых скобок типа < > там не было?

Кстати, если взять несоответствующую пару скобок, например [ ) или ( ], то неправильная закрывающая скобка тоже должна дать синтаксическую ощибку.

[sab123.livejournal.com]

Пардон, прям тут написано про Марс, а год запуска я нашел - видимо, 1962.

[spamsink]

Угловых скобок не было, были знаки больше-меньше.
В идеале, конечно, неправильная закрывающая скобка должна дать ошибку, но если перфораторщица прочитала какое-нибудь a[1]+b как a[13+b, то опаньки. Первым неправильным символом может быть точка с запятой или end (в алголе точка с запятой не терминатор, а разделитель операторов), и что-нибудь могло быть упущено из рассмотрения.

[amarao-san.livejournal.com]

cpan, pip, gem'ы. Каждая среда изобретает своё, со своими граблями и неудобствами.

[sab123.livejournal.com]

Так ведь задача в общем случае сложная.

[amarao-san.livejournal.com]

Дело даже не в том, что "она сложная", а в том, что её каждый раз начинают решать с нуля, причём каждая последующая получается едва ли не хуже предыдущей. На фоне изящества so'шек, любой pip/hackage/cpan выглядит уродливым монстром.

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

[sab123.livejournal.com]

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

Проблема гораздо сложнее, там главная сложность: нам надо использовать библиотеку A и библиотеку B, они обе хотят библиотеку C, но A хочет C в версии X, а B хочет C в версии Y.

Ну, это не говоря уже об установке всех зависимостей и их разделении, неразделении и конфликтах.

[amarao-san.livejournal.com]

Я понимаю. Но это всё недостижимая rocket science по сравнению с текущими "достижениями" в районе pip'а...