Моя производительность в написании программ

[vek88]

creative в сообщении #359463 писал(а):

И опять через месяц я обнаруживаю, что нибудь новое, что раньше не замечал...

Конца этой разработки я не вижу (хотя бы убрать критические баги).

А разве Вы не знаете прописную программистскую истину - в каждой отлаженной программе есть еще одна ошибка.

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

[Joker_vD]

Maslov
С удовольствием послушаю про другой надежный способ. Но даже если полностью не верифицировать, то все равно надо в "опорных точках" кода определять условия, которые обязаны там выполняться и хотя бы ставить assert'ы.

creative
Вы на Си пишете?

[Maslov]

Joker_vD в сообщении #359545 писал(а):

Maslov
С удовольствием послушаю про другой надежный способ.

Знал бы способ, ... :)

Joker_vD в сообщении #359545 писал(а):

Но даже если полностью не верифицировать, то все равно надо в "опорных точках" кода определять условия, которые обязаны там выполняться и хотя бы ставить assert'ы.

Тут Вы абсолютно правы. Assert'ы, трассировка, покрытие тестами -- это все, безусловно, необходимо.
А формальная верификация программ или какая-нибудь другая "серебряная пуля" -- увы...

[Joker_vD]

Цитата:

трассировка, покрытие тестами

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

Единственный способ писать большую надежную программу — это в каждый момент времени точно быть уверенным, что программа делает ровно то, что должна. В случае многопоточного программирования это очень сложно. Вообще, я заметил, многие программисты не осознают, что программа будет выполняться в многозадачном окружении. Это ничего, если программа решает ДУ методом Рунге-Кутты, но что, если она должна работать с файлами и устройствами?

Но как бы то ни было, тестирование может лишь выявить ошибки. Доказать, что ошибок нет, оно достоверно не может. Так что встает философский вопрос: "Можно ли написать программу без ошибок?". Знаете, ответ "нет" меня решительно не устраивает.

[Maslov]

Joker_vD в сообщении #359570 писал(а):

Цитата:

трассировка, покрытие тестами

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

На мой взгляд, Вы излишне категоричны: иногда всё-таки удается написать и запустить в эксплуатацию довольно большую программу вполне приемлемого качества :)

Joker_vD в сообщении #359570 писал(а):

Но как бы то ни было, тестирование может лишь выявить ошибки. Доказать, что ошибок нет, оно достоверно не может. Так что встает философский вопрос: "Можно ли написать программу без ошибок?". Знаете, ответ "нет" меня решительно не устраивает.

Да что уж в нём такого философского, в этом вопросе? Конечно, можно. Вот, например

void main() {}

Теоретически -- можно, практически -- очень трудно, очень долго и очень дорого. Ну и что дальше? Завязываем с программированием?

[venco]

(Оффтоп)

Maslov в сообщении #359577 писал(а):

Joker_vD в сообщении #359570 писал(а):

Но как бы то ни было, тестирование может лишь выявить ошибки. Доказать, что ошибок нет, оно достоверно не может. Так что встает философский вопрос: "Можно ли написать программу без ошибок?". Знаете, ответ "нет" меня решительно не устраивает.

Да что уж в нём такого философского, в этом вопросе? Конечно, можно. Вот, например

void main() {}

main.cpp:1: error: `main' must return `int'
main.cpp:1: error: return type for `main' changed to `int'

[Maslov]

(Оффтоп)

venco в сообщении #359582 писал(а):

Код:

main.cpp:1: error: `main' must return `int'
main.cpp:1: error: return type for `main' changed to `int'

Вы бы её ещё в Java загнали :)

d:\Temp>cl void.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

void.c
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:void.exe
void.obj

d:\Temp>void
d:\Temp>

[creative]

(Оффтоп)

Maslov в сообщении #359595 писал(а):

venco в сообщении #359582 писал(а):

Код:

main.cpp:1: error: `main' must return `int'
main.cpp:1: error: return type for `main' changed to `int'

Вы бы её ещё в Java загнали :)

А я последнее время вообще компилирую только в самом строгом режиме компилятора:

# gcc -pedantic-errors -o test test.c
test.c:1: error: return type of ‘main’ is not ‘int’

Joker_vD

Да, пишу на C под FreeBSD и Linux (хотя уровень пока не такой высокий, чтобы предпочитать какую-то одну платформу, так как на моём уровне они мало различимы). Что Вы подразумеваете под спецификациями? Если то, что программа должна выдавать на выходе, то этого недостаточно, так как программа может для многих входных данных давать правильные выходные данные, только потому, что не выпал сегфолт после обращения к освобождённой памяти, так как ОС ещё не пометила эту страницу как не используемую.

[vek88]

vek88 в сообщении #359533 писал(а):

А разве Вы не знаете прописную программистскую истину - в каждой отлаженной программе есть еще одна ошибка.

В дополнение к этому напомню, что

хороший программист не тот кто быстро пишет программы, а тот, кто быстро находит ошибки.

ИМХО это удел программистов - постоянно работать в окружении ошибок.

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

О принципиальной сложности поиска ошибок в реальных ситуациях я уже пытался высказаться в теме Ошибки мышления. См.

vek88 в сообщении #290039 писал(а):

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

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

Пример с телевизором подходит и к программированию - Вы тестирует программу - все работает. Отдаете заказчику - она валится. ИМХО вполне типичная ситуация.

И ничего здесь не поделаешь - селя ва. Другими словами, идет вечная борьба бобра с ослом.

[creative]

vek88

Тем не менее такие парни как Линус написали работающее ядро, а другие всю жизнь остаются на уровне написания маленьких програмулек. Он же как то это делает, значит есть какие-то методы, упрощающее надежное кодирование.

[Joker_vD]

Цитата:

Что Вы подразумеваете под спецификациями?

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

{i - целое число}
???
{i увеличилось на единицу}

К сожалению, написать код, реализующий даже такую простую спецификацию, не так-то просто.

[vek88]

creative в сообщении #359631 писал(а):

vek88
Тем не менее такие парни как Линус написали работающее ядро, а другие всю жизнь остаются на уровне написания маленьких програмулек. Он же как то это делает, значит есть какие-то методы, упрощающее надежное кодирование.

Сколько ж можно Вас уговаривать не комплексовать. Короче, я устал это делать. Похоже, Вы не просто комплексуете - Вам публичное самобичевание доставляет удовольствие.

Ну что ж, флаг Вам в руки - мазохируйте, а я к Вам больше не ездюк, беру шинель - иду домой.

[creative]

Joker_vD в сообщении #359688 писал(а):

Цитата:

Что Вы подразумеваете под спецификациями?

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

{i - целое число}
???
{i увеличилось на единицу}

К сожалению, написать код, реализующий даже такую простую спецификацию, не так-то просто.

Да, помню эту старую добную книжку. То о чём Вы говорите, немного написано в начале первого тома Кнута (там есть ссылка на метод Флойда). В современном виде одна из подобных систем доказательства корректности алгоритмов - логика Хоара. (Кстати посмотрел оригинал статьи Хоара, достаточно доступно написано, предшествующую оригинальную статью у Флойда я не осилил, надо будет почитать.)

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

Но инварианты цикла полезны всегда.

Поэтому вопрос о написании надежного ПО за разумные сроки остаётся открытым.

(Оффтоп)

vek88

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

[Alexu007]

creative в сообщении #359879 писал(а):

Поэтому вопрос о написании надежного ПО за разумные сроки остаётся открытым.

Разбиваете проектируемое ПО на части - и нанимаете столько программистов и такой квалификации, чтобы написали каждый свою часть вовремя и без ошибок. Для этого и существует руководитель проекта. Если же ваша производительность составляет несколько строк кода (ну конечно же гениального, другого не пишем!!!) в день - очевидно вы неготовы для работы в таком проекте. В любом проекте. Тренируйтесь на кошечках.

[worm2]

Alexu007 писал(а):

Разбиваете проектируемое ПО на части - и нанимаете столько программистов и такой квалификации, чтобы написали каждый свою часть вовремя и без ошибок.

Сразу закон Брукса вспомнился