Программа без ошибок - такая же абстракция, как -273 градуса

[bekas]

Хотелось бы услышать от практикующих программистов о самых
запомнившихся (казусных) ошибках программирования из их
практики. А таковых, наверняка, было немало...

Для начала можно привести такой фрагмент программы:

signed char i;

for(i = 0; i <= 127; ++i)
{
...
}

Как сказал один мой знакомый, "экономия выходит боком", обнаружив
"бесконечность" приведенного выше цикла. Действительно, замена
char на long или даже на short позволила бы избавиться от зацикливания.
Между прочим, данный случай действительно имел быть на самом деле...

[незваный гость]

Я уже приводил этот пример:

do {
  ++i;
} while (i < 10);

Если пропустить do, то тело цикла исполняется один раз, а потом наступает бесконечный цикл while. Удовольствие - выше среднего.

[Sanyok]

У меня было следующее:

while(i--);
{
     ..... //тело цикла :)
}

Пол-дня провозился, пока заметил эту проклятую точку с запятой в конце!

[Debiloid]

Не абстракция. Есть методы, однако.

http://why.lri.fr/index.en.html

[bekas]

to Debiloid:

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

Это следует из простого подсчета всевозможных логических путей прохождения алгоритма,
число которых в случае достаточно нетривиального алгоритма практически
бесконечно, а следовательно такой алгоритм нельзя протестировать на все 100 процентов.
Тому есть много примеров, как, например, космические корабли улетали в никуда
из-за элементарных ошибок программирования, вовремя не оттестированных.

И тут не помогут никакие методы a-la автоматического доказательства
правильности программ. Мы можем только надеяться, что наша программа будет
работать только в ОПРЕДЕЛЕННЫХ УСЛОВИЯХ.

[незваный гость]

Есть три аксиомы Шура-Бура:
1) В каждой программе есть хотя бы одна ошбка.
2) Если в ней нет ошибки, то неверен алгоритм.
3) Если нет ошибки и алгорифм верен, то программа никому не нужна.

В трудах отцов-основателей сермяжная (она же посконная) правда часто проступает. Поражает глубина их понимания проблематики.

Чуть-чуть более серьезно:

Debiloid писал(а):

Не абстракция. Есть методы, однако.

Доказательство правильности программы, коли память ветренная мне не изменяет с другими, суть проблема алгоритмически неразрешимая (аки следствие немца Гёделя теоремы).

bekas писал(а):

Это следует из простого подсчета всевозможных логических путей прохождения алгоритма, [...] И тут не помогут никакие методы a-la автоматического доказательства правильности программ. Мы можем только надеяться, что наша программа будет работать только в ОПРЕДЕЛЕННЫХ УСЛОВИЯХ.

Вы не вполне корректны. Программы, правильность которых серьезно интересует, не тестируют, а доказывают. Математическое же доказательство позволяет высказываться о произвольных объектах, что ему комбинаторный взрыв, не более чем счетный по природе своей.

К сожалению, во многих современных курсах программирования большое внимание уделяется объектно-ориентированному анализу и объектно-ориентированному проектированию. Многие как-бы не замечают, что объектно-ориентированного программирования нет, есть лишь структурное. И все изучение структурного сводят к знаменитой цитате "goto считать вредным". Между тем, Дейкстра и другие (я вспомню Хоара (Взаимодействие последовательных процессов), на меня лично сильно повлиял Грис (Наука программирования) - книга Дейкстры не была доступна) определяли структурное программирование иначе - как доказательное программирование, id est процесс, при котором правильность программы доказывют. Процесс сей не может быть полностью автоматизирован, как и доказательство математической теоремы, и я верю Debiloid - он может быть автоматизирован частично.

Главным же его недостатком является стоимость (zum Beispiel, я потратил вечер - около 6 часов - для доказательства правильности 15 строк программы. Мне было очень нужно ). Он очень утомителен и очень дорог. В результате используется практиками (даже владеющими методом, хотя таких и меньшинство) весьма редко, только при написании весьма ответственного кода. Пример Майера меня мало впечатлил. Интересно, что американский стандарт на критические приложения DO-178 вооще не допускает "мертвого" кода (хотя тут еще надо разобратьься, что такое мертвый код). Всяк со своим опытом может сравнить. Но то, что дорого - определенно. А качество суть категория экономическая. Посему почти всяк начальник любого программиста, пишущего математически безошибочные программы уволит, как медленно работающего. (почти все - по определению - кроме множества меры ноль). Посему программисты выбирают не доказывать.

Я беседывал однажды с одним начальником "от программирования". Беседа шла почти дружески, и я позволил себе высказаться в том смысле, что security программы вообще нельзя отлаживать. Он страшно обиделся: "Как это?!? Мы же отлаживаем!" Ну что можно сказать такому человеку? Пожалеть разве что. Его, и его клиентуру. А заодно и калечимых им его программистов.

[незваный гость]

IBM однажды проделало экспримент - посадило разработчиков писать программы без доступа к компьютеру. То есть одни писали, а другие набивали, тестировали, и относили результаты первым. Вестимо, стоимость возросла. Но количество ошибок заметно уменьшилось. Мораль - думать надо, а не кнопки давить.

[Sanyok]

незванный гость писал(а):

Я беседывал однажды с одним начальником "от программирования". Беседа шла почти дружески, и я позволил себе высказаться в том смысле, что security программы вообще нельзя отлаживать. Он страшно обиделся: "Как это?!? Мы же отлаживаем!" Ну что можно сказать такому человеку? Пожалеть разве что. Его, и его клиентуру. А заодно и калечимых им его программистов.

Не совсем понял... Вы хотели сказать, что security программы должны быть написаны сразу правильно? И еще, в связи с тем, что был упомянут ответственный код, я вспомнил про язык Ада. Сам я на нем не писал, даже не изучал, а вот то, что о нем слышал (и что меня поразило) - на период где-то до 2000 г. существовало всего лишь порядка 300 компиляторов в мире, полностью соответствовавших военному стандарту этого языка. И то, что встроенное ПО для бортовых систем аэробуса А-310 (и не только этого аэробуса) написаны именно на нем. Интересно, кто-нибудь видел этот стандарт? В чем особенность этого языка?

[незваный гость]

Sanyok писал(а):

Вы хотели сказать, что security программы должны быть написаны сразу правильно?

OK, признаюсь сразу, я плохо сформулировал. Следовало сказать secure program. Нет, не существует метода дающего 100% правильного кода. Но отладка не подходит для этого принципиально. Поскольку, как уже заметил bekas, мы можем протестировать весьма ограниченное количество случаев.

По сути, единственный метод построения secure program - правильное проектирование. Это включает верификацию исходных текстов, просмотр (code review) et cetera. Разница состоит в том, что все эти методы - анализ текста программы. В сравнении с ними тестирование суть более или менее систематическое экспериментирование с программой, то есть процесс хоть и более дешевый, но выдающий куда менее надежный результат.

В этой связи стоит помянуть и языки программирования. Я не буду касаться C - намеренно. Но любой, видевший программу на Форте признает, что анализировать ее - еще то удовольствие. (Я однажды написал на Форте отладчик. Работал - великолепно. Я драл всю группу как стоячих. И занимал всего две страницы. Проблема с ним всплыла через два года. Я просто не сумел вспомнить, как он работает, и было проще написать новый, чем прочитать старый.) Не случайно про Форт говорят - write only language. Я видел и статью, доказывавшую (притом весьма аргументированно), что программы для OS/370 на PL/1 были куда более secure. Если важно, попытаюсь найти.

Аду не помню, извините. Но количество компиляторов (300) - это не мало, а очень много. Я знаю всего 4 или 5 реализаций Python. Могу припомнить 2-3 компилятора Modula-2. В этом смысле 300 говорит о том, что язык пошел, и пошел широко. Но если Вы посмотрите вокруг себя, то он почти не виден. Несколько странное положение, не правда ли? Очевидно, он крутится где-то в оборонных конторах США, в очень замкнутом сообществе. (А встроенные системы любят свои процессоры, и это ведет к размножению компиляторов.)

[Sanyok]

незванный гость писал(а):

:evil:
IBM однажды проделало экспримент - посадило разработчиков писать программы без доступа к компьютеру. То есть одни писали, а другие набивали, тестировали, и относили результаты первым. Вестимо, стоимость возросла. Но количество ошибок заметно уменьшилось. Мораль - думать надо, а не кнопки давить.

Да, я с этим соглашусь... И тут опять возникает вопрос - требование предобъявлений - это хорошо или плохо? Во всяком случае, предобъявления способствуют тому, что бы сесть и нарисовать алгоритм, и станет ясно, сколько переменных надо и какие они должны быть! А если я могу ввести любую переменную там, где мне надо, зачем сидеть над листком бумаги и думать? Можно думать за компом, сразу набивая текст! Насчет Си я все-таки выскажусь. На мой взгляд, в программе на этом языке трудно не напортачить. Как выразился один мой друг - "программа на С - сплошные закорючки"

Цитата:

Аду не помню, извините. Но количество компиляторов (300) - это не мало, а очень много. Я знаю всего 4 или 5 реализаций Python. Могу припомнить 2-3 компилятора Modula-2. В этом смысле 300 говорит о том, что язык пошел, и пошел широко. Но если Вы посмотрите вокруг себя, то он почти не виден. Несколько странное положение, не правда ли? Очевидно, он крутится где-то в оборонных конторах США, в очень замкнутом сообществе. (А встроенные системы любят свои процессоры, и это ведет к размножению компиляторов.)

Вот то-то и оно - кажется странным, почему этот язык так мало распространен? И почему так распространен С?

[VLarin]

Sanyok писал(а):

... И тут опять возникает вопрос - требование предобъявлений - это хорошо или плохо? Во всяком случае, предобъявления способствуют тому, что бы сесть и нарисовать алгоритм, и станет ясно, сколько переменных надо и какие они должны быть! А если я могу ввести любую переменную там, где мне надо, зачем сидеть над листком бумаги и думать? Можно думать за компом, сразу набивая текст!

Предопределение - это опять-таки дело привычки. Временные переменные к основному алгоритму имеют малое отношение, а только вспомогательное значение.

По поводу грамотного подхода к проектированию програм с помощью листа бумаги - я последнее время вообще отвык писать ручкой, все больше на компьютере, и использую для проектировнаия подход "сразу набивая текст":)). Набрасываю прототипы основных функций, связь, организацию классов прям в header'ах, строя диаграмы зависимостей в голове и отчасти в header'ах:)

[Sanyok]

VLarin писал(а):

По поводу грамотного подхода к проектированию програм с помощью листа бумаги - я последнее время вообще отвык писать ручкой, все больше на компьютере, и использую для проектировнаия подход "сразу набивая текст":)). Набрасываю прототипы основных функций, связь, организацию классов прям в header'ах, строя диаграмы зависимостей в голове и отчасти в header'ах:)

Тогда меня интересует такой вопрос: часто так было, что бы Вам не приходилось искать ошибки в том, то Вы написали? Т.е. тестирование небольшой проги (или какого-то модуля или класса объемом строк в 200-300) сразу проходило гладко?

[VLarin]

To Sanyok:
Не ну как - когда пишешь что-нить алгоритмически простое, ошибки зачастую связаны только с опечатками, если сложное - то тут уж можно что-нить и не учесть. Когда переходишь от простых программ к сложным комплексам, простые алгоритмы уже на автомате пишутся.
Но вопрос я бы сказал не по-существу - бывает по-разному:)))

[незваный гость]

VLarin писал(а):

Предопределение - это опять-таки дело привычки. Временные переменные к основному алгоритму имеют малое отношение, а только вспомогательное значение.

Я бы все-таки добавил - и языка. С++ стимулирует определение переменных по мере надобности. Некоторые решают эту дилему просто - практически нет объявлений - например, в Python.

VLarin писал(а):

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

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

Кстати, именно в этом была суть IBM'овского эксперимента - доказать, что проектирование "на лету", "сразу набивая текст" дает код худшего качества (более точно, сравнить - результат очевиден не был).

[незваный гость]

Sanyok писал(а):

Вот то-то и оно - кажется странным, почему этот язык так мало распространен? И почему так распространен С?

Ваше утверждение почему Ада так мало распространена мне не очень понятно. По некоторым косвенным признакам у меня создалось впечатление, что она очень распространена в своей нише - минобороны США и его контракторы. Это все же нишевой язык, очень тяжеловесный, на данный момент первая версия стандарта устарела во многих отношениях (есть новый стандарт Ada-95, его не видел ).

На вопрос о распространнености других языков единого ответа нет. Как это не покажется странным, ответ редко связан впрямую с достоинствами и недостатками языка. Причины часто экономические. С пришел в Юникс как основной язык. Компилятор С входил в дистрибутив Юникса. Этого было мало. ATT разрешило бесплатное использование Юникса университетами (в рамках борьбы с монополией IBM). И своего достигло - университеты и профессора стали выбирать Юникс и С. Дла обучения, для того, чтобы показать как устроено ядро ОС, для того, чтобы написать свой экспериментальный вариант ядра. И в мир хлынул поток специалистов пишущих на С и морщащихся при слове IBM. Юникс пошел в бизнесс. Значит, нужны специалисты по проектированию на Юникс/С, и их стали уже целенаправленно готовить университеты.

Когда встал вопрос о развитии С, то идея была опереться на толпу программистов уже знающих язык. Бизнес не приветствует революций. Революция - это деньги из его, бизнеса, кошелька. В виде затрат на переобучение персонала, в виде потери производительности, в виде затрат на поддержание старого кода или переписывания его. Поэтому у похожего языка больше шансов быть принятым - психологически. Поэтому родимые пятна С (70е) так проступают тридцать лет спустя в Java и C#.

Поучительно сравнить историю С с историей Виртовских языков (Pascal, Modula-2, Oberon) и с историей Pyhon. Вирт переписывал язык раз в десять лет, чтобы язык соответствовал концепциям программирования эпохи. Получались новые языки, но Вирта это беспокоило мало - он делал языки, чтобы самому учить студентов. Вовсе не для широкого индустриального програмирования. Его, несомненно, радовало признание, но это были все же не "языки программирования", не "алгоритмические языки", а "языки обучения программированию". Python, с другой стороны, не имеет стандарта. примерно раз в год выходит новая версия компилятора языка. Язык непрерывно эволюционирует, но очень, очень акуратно, с тщательным анализом последствий для уже существующих програм. Иногда нововведение ломает существующий код, и в этом случае его придерживают на несколько лет. Пример тому - Python - едиственный язык, в котором целочисленное деление возвращает реультат с плавающей точкой. Процесс перехода начался года два назад, и кончится (надеюсь) в следующем году. [int/int во всех языках возвращает int. Однако целочисленное деление в программах используется чрезвычайно редко, а вот ошибки возникают гораздо чаще - из-за забытого приведения (float)(i)/int. Проще принять, что для целочисленного деления используется операция //]