Как вы считаете, возможно ли программировать без ошибок, без необходимости отладки (т.е. поиска ошибок)? Что для этого нужно? Хороший проект? Какая нужна организация работ? Конфигурационное управление? Что говорит сегодняшняя наука по этому поводу? Какие есть методы борьбы со сложностью, минимизации программ?

(2) калькулятор со второго раза можно

Нет

(0) Можно и нужно! Наука не против...

а почему вообще такой вопрос встал?

Структурный подход снижает количество ошибок в алгоритмах и программах. Однако и при этом подходе число ошибок также зара­нее неизвестно. Хотя структурная форма записи и упрощает поиск и исправление ошибок в текстах программ, гарантии отсутствия ошибок структурный подход не дает.

Безошибочное программирование - это составление алгоритмов и программ с гарантиями отсутствия в них ошибок. А составление алгоритмов и программ с одновременным доказательством правиль­ности называется доказательным программированием. И в том и другом подходе необходимо составление формальных (!) спецификаций.

без отладчика можно.
без отладки навряд ли.

(4) Хочется программировать без ошибок. Что для этого нужно?

(0) Если работать только с помощью волшебников, то ошибки исключены. Так что, отладчик это пережиток прошлого...

(7) утопия

сроки увеличиваются на порядок, цена тоже

имхо программирование без отладки - это собирать конструктор вслепую... можно, но далеко не каждый сможет

(10) Это неважно. Вопрос теоретический, даже философский.

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

(0)а почему не опрос?

(0)что нужно? быть богом, и тот вон с людьми накосячил :)
ракеты в космос запуская, учитывают ошибки и правят их в следующих проектах, а ты про программирование....

(7) ты уже слишком стар и привык программировать с ошибками.
тебя не переучишь

(13) Как поставить работу, чтобы не требовалось удерживать всё в памяти?

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

(7) Для этого нужно всего лишь думать...

Нет уверенности даже в среде, ты не можешь быть уверен в том что данный метод выдаст то, что ожидаешь.

(19) Интересная формулировка для непробиваемой тупости...

(18) перестать программировать вообще

(21) Пишите программы, которые не зависят от среды...

Humanum errare est - человеку свойственно ошибаться.

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

(21) Допустим, что среда работает правильно. Речь идёт о наших собственных ошибках, т.е. в наших программах.

При создании чего либо, есть 2 этапа. Проектирование, и реализация. Если половину сил и времени угрохать на проектирование программы, то реализация будет уже практически без ошибок. Аналогия со строительством дома. если ошибки на стадии проекта, то потом фундамент перемещать, стены ломать, крышу перебирать и т.д, что удорожает строительство раз 10. А если на стадии проекта все обдумали хорошо, то дом строится ровно на ту сумму, на которую планировали.

(24) А такие бывают?

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

Для этого нужно
1. Опыт
2. Идеальную память - помнить все синтаксисы и тп
3. Перестать быть человеком.

+(27) Любая аналогия условна.

(23) Ты почти угадал. Чем меньше программа по размеру, тем меньше в ней ошибок.

Невозможно писать без ошибок. Возможно ~80% выявить при тестировании.

(28) Функционально программирование как раз для таких случаев и создавалось...

(30) Зачем нужна память, если есть базы данных?

(32) Неа...

(32) В программе hello world, возможно, нет ошибок.

(37) Ошибка в самой целе написания данной программы...

(34) А оно происходит не в какой либо среде?
(30) Если БД интегрировать с мозгом, то да, иначе оперативность не та.

(37) Т.е. при написании элементарных программ ошибок практически не бывает. Значит надо свести большую программу к элементарным.

В процентах времени, имхо:
Написание - 30%
Тестирование, отладка, доработка - 70%

Волшебник, ты совсем сошел с ума.
Золото из свинца делать не хочь?

(35) Надо помнить весь синтаксис, чтобы знать какую конструкцию оптимальней применить...

(40) И появятся ошибки во взаимодействии этих элементарных

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

(42) Золото из свинца уже научились делать.

(44) Как их не допустить?

(39) Не могли бы Вы уточнить, что такое "среда" для Вас?

(12) Как раз это чаще всего важно. Никому не нужен софт без ошибок через 10 лет. Каждая сложная программа содержит какой-то процент невыявленных ошибок - просто важно насколько они критичны. П.э. (0) - это утопия.

(43) Есть синтакс-помощник. Перед нажатием на любую клавишу в редакторе модулей, загляни туда.

(47) Идеальное проектирование, которое как и все идеальное не может существовать.

Предположим погрешность элементарной программы 0.01 копейка, Если считаем до копеек - ошибок нету. А теперь делаем комплекс из тысяч элементарных программ - и полезут ошибки. Они, как правило, имеют свойство накапливаться.

(46) вряд ли.
Много стран были бы против, учитывая значения золотого запаса

(47) Что Вы делаете, чтобы ходить и не падать? Почему так же не подойти к написанию программ?

(49) Софт без ошибок легче развивать. Периодический рефакторинг кода может привести к "вечно живым" программам. Рефакторинг заключается в написании новой программы с сохранением функциональности и добавлением новой. Конечно, при этом опять не должно быть ошибок.

(48) В том то и дело, что средой может быть все, от среды исполнения(включая железо, которое тоже не безгрешно) до внешней среды, с которой будет взаимодействовать программа.

(0) Наука говорит о том что тестирование это по сути бесконечный процесс, отладка в свою очередь является тестированием программы с использованием методов белого ящика, и чем ниже степень тестирования тем меньше вероятность того что программа будет работать безошибочно. То есть если поступиться качеством то можно обойтись и без этого..

(55) А кому нужны мертвые программы?

(52) Как организовать этот комплекс из тысяч элементарных программ, чтобы гарантировать отсутствие ошибок в нём, подразумевая, что в каждой элементарной программе ошибок нет?

(53) Чувак, золото из свинца уже давно делают. Просто оно дороже натурального в 1000 раз.

(56) Программа как раз и пишется для взаимодействия с внешней средой. А вот от внутренней среды (от самой программы) надо отвязываться...

(59) Зайдите в книжный магазин, книг на эту тему сотни...

(59) смотря, что понимать под ошибкой

(57) Тестирование и отладка - разные вещи. Тестирование - это поиск ошибок/несоответствий, отладка - поиск причины (места в программе) конкретной ошибки.

(61)Элементарный нюк - это непредвиденное поведение внешней среды.

(55) "вечно живой"программой должен заниматься 1-2 человека и все

(62) Порекомендуй чего-нибудь

(63) "Ошибка - это недокументированная фича"

(59) Никак :)
Только Бог может это сделать...Человек, как существо органическое, не способен реализовать такие проекты. Тут нужна дискретная логика, без всяких погрешностей...

(0) Стас, ну от тебя не ожидал. Вроде бы на мисте же статью и видел, как-то связанно с экстремальным программированием. Смысл простой, к основной программе нужно писать прогу тестировщик, которая проверяет все и вся. Т.е. дописываешь ты в базу пару строк, то что требовалось работает, но цепляет что-то еще и косяк вылезает уже в процессе работы. А если есть тестировщик, достаточно его запустить, и все ошибки будут найдены до того как твой шедевр дойдет до пользователя. Т.е. ответ да, возможно, только вот кода становится не меньше, а наоборот гораздо больше, потому что написав 2 строчки кода в основной программе нужно дописать два десятка в тестировщике.

(65) Допустим внешняя среда ведёт себя предсказуемо. Я говорю именно о наших собственных ошибках.

(65) Предусмотрите на этапе проектирования непредвиденные изменения во внешнем окружении...

(70) "цепляет что-то" - ведь это можно отследить, если заранее составить полную карту всех зависимостей

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

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

(67) Брукс, Йордан, ДеМарко хотя бы...

(55) Не вбывает ничего вечного, особенно если требования/условия меняются... Вот Кармак идиот - написал новый движок на Дум3... И чего он просто к Вольфинштейн 3D рефакторинг не применил.

(70) глупо писать 2 програмы заместь 1ой нормальной

Билли уже вон сколько софта понаваял и до сих пор ошибки вылаваливают.

(74) это точно... хороша ложка к обеду...

(74) Допустим, мы не торопимся.

(70) XP нормально работает только для мелких поделок...

(0) Короче - можно не выгодно

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

Если программа заработала без ошибок, значит она написана неправильно...Так вроде звучит основной постулат программирования ?

(83) Допустим, мы говорим об открытом ПО, т.е. разработчики работают для нас бесплатно.

(74) Кривая прога для искуственного сердца или для управления самолетом лучше, чем прога с опозданием?

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

(86) Открытое ПО <> Бесплатно!

(85)
:)
"если программа запустилась с первого раза,
значит в ней четное количество ошибок.."(с)

(85) Думаю, что правильно написанная программа СРАЗУ должна работать без ошибок. Т.е. не должно быть периодических прогонов-проверок. Если написана строчка, она СРАЗУ должна работать.

(81) А рисование всех процессов проги и отдельных, особо сложных, кусков кода на бумаге, а потом продумывание и исправление этого там-же, на бумаге - это отладка?

(10) Как только решишь (читай формализуешь процесс) - готовься к освоению новой специальности. Заодно, подумай, что делать с автоматически возникающей ненужностью человека вообще.

(90) Это афоризм, который мы можем опровергнуть.

(81) (83) Ну тогда нужно больше внимания уделять проектированию и говорить о методах и средствах которые сейчас актуальны для этого.
Не выгодно имелось ввиду не в плане денег. Тут смысл такой если прога вышла раньше значит она уже к выходу второй успеет завоевать рынок. Попробуй потом объясни людям что твоя прога лучше потому что ты ее грамотно проектировал, когда первая (глючная) уже внедрена во многих процессах.

(91) Так строчка может будет работать, а вот следующие за ней могут перестать...

(91) Понимаешь, прога-то может работать сразу, а вот результат работы предсказать иной раз очень тяжело...
"- Че пишешь?
- Ща допишу, скомпилирую и узнаю..."

(91) но если постановка задачи поменяеться, строчка будет работать, но результат нужен не тот.
это тоже ошибка. Как такое предвидеть?

(81) Дело за малым - найти такого же неторопливого клиента.

(87) Ну тут все относительно. Надо правильно понимать "кривизну проги". Кривая прога не значит не работающая, а работающая при соблюдении опред правил.
Лучше такая прога для управления сердцем если она нужна срочно, чем никакая :)

(91) Теоретически верно. Можно поручить написание программ самим программам, тогда человеческих ошибок не будет.

(92) Исправление с целью устранения ошибок - отладка. А вот исправление с целью расширения функциональности, оптимизации допускается.

(101) Т.е. нам нужен компилятор с языка проектирования на язык программирования высокого уровня?

гм..гм.. давайте начнем с определений и для начала разберемся, что мы понимаем под "ошибкой программы".
могу предложить следующую детализацию:
1. ошибки синтаксические - (тупо неправильно написал оператор) - выявляются на стадии компиляции кода.
2. ошибки времени выполнения - исключения (типа деления на 0, переполнение стека, чтение несуществующих файлов и т.п.). выявляются на стадии тестирования и/или перехватываются через try/except
3. ошибки смысловые - самые опасные. программа работает корректно, в смысле не валится, но делает не то, что надо. т.е. не соответствует ожиданиям пользователя.

с какими ошибками будем бороться?

если честно - больной вопрос... сама всегда думаю об этом, но пока... НИ ОДНА сложная программа сразу правильно не работала у меня... и проблема не в том, что строчка - должна правильно работать... чем сложнее логика работы системы, тем труднее ее сразу сделать - правильной...

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

((104) с №3

+100 Все относительно и рассматривать надо соотношение кривизна проги/длительность разработки, но опять же практика показывает что лучше хуже но быстрее.

(103) Примерно так, нужен качественный переход к декларативному программированию. Не как программа работает, а что она должна делать.

(106) а на большее никто не способен

(104) с 3-ми, 1 и 2 - это для программиста не ошибки

(104) А пользователю какая разница какую именно он ошибку поймал? Пользователю надо чтобы ошибок не было совсем...

(104) Со всеми.
1. Написанная строчка должна быть синтаксически-корректной. Т.е. выявление ошибки на этапе синтаксического контроля говорит уже о непрофессионализме программиста, не закрыл скобку, не заглянул в синтакс-помощник, ошибся с числом параметров.

2. Исключения - это хорошо, но только для отлавливания ошибок внешней среды.

3. С этими сложнее всего. Нужны формальные спецификации, автоматическое тестирование (но это уже поздно). Хочется не допускать такие ошибки.

(111) ну не совсем так. ошибки второго рода иногда выявить очень сложно, поскольку проявляться они могут только в очень специфических условиях.

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

(111) легко - нужно крепко отдыхать и спокойно работать вмеру

(109) Этот переход был сделан еще в 1958 году, когда появился lisp...

(113) не закрыл скобку - мама дорогая! ты, видимо, никогда не видел lisp :)

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

+(115) т.е. даже природа проблему ошибок не решила, а мы хотим стать круче еЁ? :-)

(78) Не глупо, например применительно к 1С, есть у тебя в бухии объект документ, доки бывают разные, но основная структура одна и та же, есть реквизиты шапки, табличной части, на выходе есть набор проводок с известной структурой. Вторую прогу можно сделать универсальной для всех документов, вбиваешь наименование документа, наименование и значения реквизитов и что должно быть на выходе. В результате при написании нового документа тебе не нужно переписывать тестировщик, достаточно дописать в него тестовые данные для нового дока.

(120) Точность копирования ДНК почти 99.99999%. Точность программирования что-то около 50% (правильно или неправильно).

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

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

(120) У природы есть ошибки? Назовите хоть одну, кроме человека...

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

(119) можно прийти к тому что проще написать сначала чем дописывать.
Тогда ошибок меньше - результат качественнее

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

(112) "Пользователю надо чтобы ошибок не было совсем..." - ИМХО Это не реально. Все в мире относительно и надо рассматривать в сравнении степень ошибки/важность проги.
Вот представь ситуацию: 100 человек которым срочно нужно серце и прога для его управления
Вариант 1. Кривая прога но быстро
20 человек умерли из-за ошибки программы
80 человек остались живы, в прогу внесли изменения
Вариант 2. Хорошая прога но долго
60 человек не дождались и умерли
40 остались живи
Все относительно

(126) Ты зачем в исключения  вписал критикал эррор?

(127) Смотри на экран, а не клавиатуру, когда пишешь программу.

(129) Подробности есть?

(122) Программистов с такой точностью надо кастрировать, чтобы не портили генофонд...

(134) Может лучше дать ему какой-нибудь инструмент?

(117) не было еще такого перехода
(129) вот про это я и говорю, могут быть ошибки качественные в алгоритме (ошибки 3-го рода), а ошибок 2-го рода не будет

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

(137) если бесконечная рекурсия - алгоритм неправильный

(121) зачем тестить?
Забиваешь в прог-му допустмые варианты значений, остальные тупо отбрасываешь
Если ... Тогда
ИначеЕсли ....
ИначеЕсли ....
ИначеЕсли ....
Иначе
  Сообщить("недопустимое значение " + Строка(х));

(130) 20 человек умерли на первом цикле исправления ошибок, 20 на втором, 20 на третьем, 20 на четвертом и вот смертность от ошибок уже превысила смертность от ожидания...

(132) Посмотрю я на тебя, как ты отловишь одну случайно пропущенную букву после н часов кодирования, глядя на экран, а не на клаву во время написания...

(138) иногда это не очевидно

(122) Я говорю не про копирование ДНК, а про рабочую развивающуюся клетку человеческого организма. А вообще, если подумать, то природа создала очень мощный биологический компьтер с мощными работающими программами, т.е. человека. Может у нее поучиться? :-)
(126) Природа вообще постоянно ошибается. Просто то что ошибочно, не выживает.

(135) Никакой инструмент не заменит необходимость думать...

(133) ну какие подробности? был написан компилятор на си, который преобразовывал формализованный текст в код на си. вся проблема в том, что сложные логически алгоритмы невозможно было описать формально...

(136) Переход был, только писать программы с ошибками экономически выгоднее в краткосрочной перспективе...

Человеческий фактор - неизбежен! Так-что прогу без единой ошибки написать не реально.

(143) С чего Вы взяли, что это именно ошибки?

возьмем, к примеру, smalltalk (честно скажу, в нем я специалист никакой - два раза в универе чего-то писал типа "hello, world"). так вот в нем идеологически заложено, что написание и отладка программы - один и тот же процесс.

(146) Все зависит от применения, если это 1С - оно конечно, а если например медицинское оборудование программить возьмешься?

(143) Этому мощному биологическому компьютеру свойственно ошибаться. Не подходит.

(144) Можно думать о незакрытых скобках или бесконечной рекурсии, а можно думать о новых фичах.

(145) Почему?

(146) Мы говорим про OpenSource, где деньги и сроки не очень важны.

(143) Человечество вымрет, а значит оно ошибочно. Так что ли?

(152) ошибочен, но только на момент вымирания

(151) [Мы говорим про OpenSource, где деньги и сроки не очень важны.] - ты хочешь сказать, что "писатели" линуксов не хотят есть? или они живут при коммунизме?

(149) ну на smalltalk-е тоже не тривиально программить... также ошибки лезут, когда логика сложная... делали мы систему на нем

(151) OpenSource - это огромные деньги...

(155) Наличие ошибок связано не с языком, а с программистами...

(152) "человек - лишь промежуточное звено для создания истинного шедевра природы - бокала Мартини с лимоном" (С) не мое

(140) Спорить можно бесконечно долго. Как вариант 20+20+20 Еще прожили на какое-то время дольше чем те которые не дождались проги :) Смысл в том что на практике скорость выхода программы важнее чем ее безошибочность (опять же в разумных пределах).

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

(155) именно. я его привел как контрпример. программирование и отладка - суть неразрывные вещи. такова природа программирования.

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

+159 Куда движется программирование? В сторону увеличения скорости разработки или в сторону уменьшения количества ошибок при разработке?

(159) С таким знанием всех видов практики, как у Вас, спорить бесполезно :-)

(163) Программирование никуда не движется в большинстве своем, оно гадит под себя. А то что движется, то движется в сторону сокращения количества ошибок, ибо исправление ошибок и их последствий сильно дороже, чем увеличение сроков изначальной разработки

+(160)Под «программой» часто понимают правильную программу, т.е. программу, не содержащую ошибок, соответствующую спецификации и дающую возможность формального вывода программы из формального набора предпосылок. Однако понятие ошибки в программе трактуется программистами неоднозначно. Будем считать, что в программе имеется ошибка, если она не выполняет того, что разумно ожидать от нее на основании документации по применению программы. Следовательно, правильнее говорить о несогласованности между программами и документацией по их применению.
В связи с тем, что задание на программу обычно формулируется не формально, а также из-за неформализованности понятия ошибки в программе, нельзя доказать формальными методами (математически) правильность программы. Нельзя доказать правильность программы и тестированием: как указал Дейкстра, тестирование может лишь продемонстрировать наличие в программе ошибки.
Альтернативой правильной программы является надежная программа. Надежность программы - это ее способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. При этом под отказом в программе понимают проявление в нем ошибки. Таким образом, надежная программа не исключает наличия в ней ошибок - важно лишь, чтобы эти ошибки при практическом применении этой программы в заданных условиях проявлялись достаточно редко. Убедиться, что программа обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные программы.
Разрабатываемая программа может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать вероятностью работы программы без отказа в течение определенного периода времени. Однако в силу специфических особенностей программ определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике.
При оценке степени надежности программ следует также учитывать последствия каждого отказа. Некоторые ошибки в программах могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности программных средств иногда используют дополнительные  показатели, учитывающие стоимость (вред) для пользователя каждого отказа.
P.S.это из учебника по теории вычислительных процессов

(164) Приведите пример. 2 проги одна вышла на рынок на год раньше но в ней было больше ошибок чем в той которая вышла на год позже. Причем к выходу второй, в первой уже часть ошибок исправили. И вторая прога завоевала рынок. Вам пример пожалуйста.

(165) Откуда такие данные? Можно ссылочку хоть на одну статью на эту тему?

(94)
:))
это шутка, которую вы можете "опровергнуть"?!
;)

(167) Apache и IIS
(168) Брукс, Йордан, ДеМарко и т.д.

Либо много времени на разработку алгоритмов - мало на кодинг, либо  -  быстрый кодинг и долгая отладка. Сейчас, учитывая требования к скорости решения задач, никто аглоритмами не занимается -  клепаем на "скорую руку", а там  -как кривая вывезет, зависит от мастеровитости и опыта

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

(172) Подтвержено многолетным опытом ;)

А вообще - Волшебник начал усиленно пиарить Мисту... вначале США, теперь это...
Раньше для этого использоваль войны форумов и тд...

(174) Я просто хочу написать новый движок форума без ошибок.

(175) Давно пора :-)

(176) Ну так помогите технологией

(175)Не сынок - это фантастика (с) Не с того конца начала - так не взлетит - ты просто исправляй найденные ошибки и все - а тестировщиков полно ;)

ИМХО (и не только мое), что сейчас у программистов просто нет времени на всякие выкрутасы с "правильным проектированием, хорошим кодированием и т.п. "
"пользователям не нужны программы, пользователям нужны _результаты_ работы программы" (С) не мое - вот это запомните, распечатайте большим красным шрифтом и повесьте у себя над столом.
программа может содержать ошибки при условии:
1. ошибки могут быть оперативно и недорого устранены
2. ошибки не являются критическими
3. стоимость наличия ошибки не превышает стоимость ее исправления

можно еще причин накидать...

(178) При исправлении ошибок вносятся новые.

(177) Технология Вас не спасет. Надо очень тщательно спроектировать всю систему и только потом садиться что-либо кодить. А если сразу схватитесь за какую-то технологию, то багов наплодите кучу...

Создай секцию - ошибки форума - и отслеживай.

(181) ага, про "тчательное проектирование" почитай у тех же бруксов-йорданов :)

(181) Как проектировать? Как от проекта переходить к реализации?

(182) Есть секция "Жизнь форума". Но речь идёт о том, чтобы не допускать ошибки, а не о том, чтобы их ловить и исправлять.

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

А способ не допускать ошибок один - не делать ничего.
тот не ошибаеться - кто не работает.

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

(177) Набросай на бумаге, чего хочешь и начинай писать с нуля, не заглядывая в предыдущий код. Сделай второй(тестовый форум) типа песочницы.

(186) Этот афоризм придумали программисты, чтобы оправдать свои ошибки. В некоторых случаях ошибки приводят к большим потерям (например, ошибки в F-35, ошибки в космических аппаратах, в других критических приложениях).

(187) + а потом каждый из разделов надо продумать как можно подробнее. когда продуманы все разделы до уровня относительно простых операций, вот тогда можно браться за кодирование...

(188) Как при написании с нуля сразу писать без ошибок (без многократных отладочных прогонов)?

(191) Надо сначала думать о том что и для чего пишется. А не потом, во врем прогонов...

(186)Вообщето
"тот не ошибаеться - кто не работает." - это народное и придумано задолго то появления компов.

(191) Определить сразу функционал. Не дописывать/доделывать потом.

(194) Но требование такое, чтобы дописывать было легко и с гарантией безошибочности. Т.е. определяем базовый функционал - пишем. Всё работает. Определяем новый функционал - дописываем. Опять всё работает и старое не ломается.

(0) влом читать все...
все описанное в (0) позволяет делать Extreme programming

Экстремальное программирование. Дисциплина разработки ПО, объединяющая более десятка методологий и практик в этой области для небольших и средних по размеру команд программистов, занимающихся реализацией проекта в условиях неясных или быстро меняющихся требований. Основатель движения за продвижение XP – Кент Бек (Kent Beck).

Правда на сегодняшний день в 1С это практически не применимо. Разве, что некоторые пункты позволят добиться улучшения.
А так Java, Smalltalk

(191) Как пишут ПО для американских шаттлов
http://kholeg.spaces.live.com/blog/cns!D006ED9CB32B0F60!152.entry

(190) это идеальный случай.. а в реальности все начинается с необходимости уложится в сроки и в бюджет..
а "лирика" про целевую группу, которым предназначено ПО отодвигается на задный план..

Есть технология MDA. Смысл её в том, что код генериться автоматически на основании модели и все изменения также вносяться не в код, а в модель а затем снова генериться уже изменённый код. Для Дельфей есть готовый перобразователь из, грубо говоря, UML модели в, опять же грубо, Object Pascal. Может и для php есть что-то похожее.

(198) При плохом руководстве, можно завалить любой проект...

(0)  прочёл тут книжку по НЛП.  Есть там такая тема - фильтр. Человек не может видеть реальный мир, он видит то, что пропускает его фильтр.  Магия НЛП, по мнению авторов книги - в том, чтобы поменять фильтр человека. И мир становится другим.

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

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

(0) "hello world" всегда без отладки пишется. Все зависит от того, что понимать под "программированием".
Возможно ли есздить на велосипеде с закрытыми глазами?
Возможно, но - смотря на какое расстояние.
Моя резолюция: тупая ветка...

(202) на ассемблере... с первой попытки..

(203) http://www.roesler-ac.de/wolfram/hello.htm - отсюда? :-)

(196)+ в Extreme programming есть один минус, мало хорошей литературы на русском, хотя если англ на хорошем уровне, то это проблемы не составит
Может за последний год картина изменилась, но я в свое время откопал в основном подлинники, может оно и к лучшему.
Думаю в нете можно много инфы найти о то что, это и с чем едят, не в даваясь в тонкости методологии и разработки.
В принципе если интересно могу порекомендовать литературу

(203) вырожденный случай. Однако, есть люди, которые даже на BrainFuck'е смогут "hello world" без отладки наваять, но это не программирование, равно, как и езда на велосипеде с закрытыми глазами - не езда

(204) не.. я предлагаю Лёвычу сделать с одной попытки на ассемблере)). чтоб прочуствовался моментом

(204) Класс)))

(0) я думаю автору будет полезно ознакомиться со статьей Брукса "Серебреной пули не существует."

(197) Отличная статья.

"Здесь существует культура: бортовая группа шаттла производит взрослое программное обеспечение и способ, при помощи которого оно производится, сама также являясь взрослой. [...] Когда вы уже готовы сделать следующий шаг – писать совершенное ПО, вместо достаточно хорошего – значит пришло время взрослеть."

(201) ты даже не представляешь, как ты прав. :-) Если смотреть с этой точки зрения, то идеально безошибочная программа, - будет та, которая идеально реагирует на реальность. Но с точки зрения неидеальных пользователей - она будет ошибочной.

Для меня важно несколько факторов, чтобы не было "ошибок":
1. Изначально правильно поставленная задача (знать проблему)
2. Максимальное удобное ПО и оборудование для написания
3. Как можно больше мотивации (денег) и времени
4. Большое количество удобных средств отладки, предсказания ошибок, технологий (ООП, СУБД и т.д.) в среде программирования
(5) Собственные знания, что есть правильное в каждом из выше указанных пунктов

А вообще я не понимаю, что такое программист.. Я понимаю что такое группа разработчиков (например 1С, аксапта), а что такое программист не пойму никогда..

(212) программист - самый жадный и ленивый член группы разработчиков..

Вот ещё фраза из статьи:

"В группе шаттла, все делается правильно с первого раза. И никто не изменяет программное обеспечение без изменения плана. Вот почему их ПО настолько совершено.

Каким образом они пишут правильную вещь?

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

Разработчики даже начали проводить свои собственные ревизии кода на заседаниях, скрупулезный анализ, который, как они надеются, расстроит тестеров.

В результате такой дружеской конкуренции группа шаттла сейчас обнаруживает 85% ошибок до начала формального тестирования, и 99.9% до того, как программа отправляется в НАСА.

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

Другая база данных – это база данных ошибок, является своего рода памятником тому пути, которым прошла бортовая группа шаттла в своей работе. Здесь содержатся все ошибки, которые были когда-либо допущены при написании или при работе с ПО, на протяжении почти 20 лет. Для каждой ошибки в базе данных хранятся записи о том, когда эта ошибка была обнаружена; какой набор команд привел к ней; кто обнаружил ошибку; на какой стадии ошибка была обнаружена – при тестировании, при тренировке или в полете. Здесь отслеживается как ошибка проявилась в программе; как ошибке удалось просочиться сквозь фильтры на каждой стадии поиска ошибок – почему она не была обнаружена при проектировании? при ревизиях кода? при тестировании? В конечном итоге база данных содержит информацию о том, как ошибка была исправлена и не могли ли подобные ошибки просочиться сквозь эти дыры.

4. Мало исправить ошибку – в первую очередь, необходимо исправить все, что позволило этой ошибке случиться.

"В результате такой дружеской конкуренции группа шаттла сейчас обнаруживает 85% ошибок до начала формального тестирования, и 99.9% до того, как программа отправляется в НАСА."
ответ на вопрос в (0)?

(197) Действительно классная статья.

(214) Волшебник, что Вам мешает писать настолько же качественный код?

(215) Да. Значит всё-таки программировать без ошибок можно.

(217) Я уже начал думать на эту тему.

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

Волшебник, видел (196), (205)?
или не заинтересовало?

(214) понравилось 4. Мало исправить ошибку – в первую очередь, необходимо исправить все, что позволило этой ошибке случиться.

Но по ссылке в (197) у меня вырисовывается следующая картинка. Стая дятлов под руководством очень умных дятлов очень долго, скрупулезно, документируя каждый удар клювом, и обсуждая каждую отлетевшую щепку каждые 10 секунд долбят одно маленькое тощее деревцо.

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

(220) Экстремальное программирование

(222) так дерево не маленькое почти в полмиллиона строк кода

в придачу нигде не сказано что они пишут без ошибок, а постоянно говориться что они их выискивают и правят...

(224) что ты сам думаешь по поводу XP в отношении к (0)?

(226) Да, ошибки остаются. Но 20 ошибок на полмиллиона строк кода, это 1 ошибка на весь движок форума 0.2 ошибки на весь движок форума.

(227) Думаю, XP - это хорошо. Нужно применять.

(218) В свете (117)???
Тут говорится о том, что ошибки отлавливаются и исправляются. Причем большая часть - до начала теситрования, еще часть - до отправки релиза. Или я чего-то не понял?

(228) Все можно вылизать: было бы желание. а у них есть и желание и самое главное стимул. Не думаю что они мало получают!

(222) От эитх документированных ударов зависит не правильность и полнота начисления налога в заурядной конторке в Мухосранске... От них зависит нечто большее...

+(231) мне кажеться была бы 1с статична- она бы уже давно была бы вылизана...

(231) По Маслоу, зарплата не является стимулирующим фактором.

"Важно заметить, что группа избегает обвинять людей в ошибках. Все обвинения берет на себя процесс – и именно процесс подвергается анализу, чтобы определить как и почему произошла ошибка. В то же время, ответственность является принципом команды: ни один человек не отвечает единолично за написание или ревизию кода. "Вас не будут наказывать за то, что вы допускаете ошибки", - говорит Маджори Сейтер, старший сотрудник технического персонала. "Если я делаю ошибку, а другие проверяют мою работу, значит я не одинок. Меня не будут обвинять в этом." " - хороший абзац.

(234) Что же тогда является стимулирующим фактором?

(234) видимо, Маслоу был небедным чуваком :)

(237) это зависть, понятия небедного нету. человеку всегда мало )

(235) Типа если и они не нашли как тогдя я бы смог найти ее. с одной стороны это перекладывание на другого ответственности с другой стороны когда осуществляеться такая проверка кода то это снижает шанс ошибки проскочить мимо разработчиков. но это вроде и так понятно что не замыленым глазом лучше проверять...

(239) Ты статью прочитай. Статья очень интересна и познавательна. Вроде ничего нового, но рассказано о том, как все это надо применять.

(236) Для кого-то - похвала начальника, для кого-то - одобрение коллектива, для кого-то - признание общестивенности.

(240) Не о том как НАДО применять, а о том как ПРИМЕНЯЮТ...

(241) что много примеров есть у тебя?

(242) Ну, то, что описано в статье, можно взять за эталон в очень многих компаниях. Так-что так именно НАДО применять, и это потверждено опытом и результатами.
(243) Где-то ветка пробегала, вроде от AnnaK, поищи)))

убейте эту ветку

(189) Колумбия, Челленджер, Союз-1 -- это были ошибки не программистов, а конструкторов. Ни нет ни одной области человеческой деятельности, где можно было бы избежать ошибок. По этому программы тестируются, космические корабли, самолеты и автомобили -- испытываются.

(246) когда то в будущем в космосе летит привет: "ядерная бомба - тоже была ошибкой"..

(13) Истину глаголишь, уважаемый!

Имхо для того чтобы писать сложный безошибочный код необходимо в голове одного человека полностью смодулировать во всех делталях и со всеми взаимосвязями:
1. Компилятор.
2. Программный код.
3. Задачу.

(24) Независимые от среды программы, это байка.

(40) Порой, для того, чтобы свести сложный процесс к нескольким простым, нужно полностью смоделировать в голове этот процесс и выявить взаимосвязи, которые порой бывают очень многочисленными.

(55) +1

(250) Зависимые от среды - это не программы, это скрипты

(106) Проблема в том что количество взаимосвязей и зависимостей между отдельными частями в реальности стремится к бесконечности.

(254) Только при плохом дизайне.

(214) Эта статья говорит о том что можно писать программы и при этом эффективно бороться с "уже допущенными ошибками" и их источниками.

Но эта статья не говорит о том как писать код без ошибок. :0)

(256) Да ну...

(257) Возможно кто-то не заметил, но в их коде всё таки находились и находятся ошибки. :0)

(255) :0)

(257) Ну да. Вопрос в том, что считать ошибкой. В какой момент ошибка считается ошибкой, в момент тестирования, или в момент написания? Если написал, проанализировал, ликвидировал, только потом передал в тестирование - это ошибка?

(260) Пока я свой код никому не отдал с отметкой "закончено", ошибок в таком коде нет.

(261) Тоесть ошибки уже пользователи ищут? :0)

(262) Если отдаешь сразу пользователям, то они их ищут. Если отдаешь код тестерам, то тестеры ищут.

(263) А если не отдавать ни кому, то и ошибок не будет. :0)

(264) Ну если по-другому ошибок избежать не можете...

(265) А ты видать умудряешься избегать ошибок. :0)

(266) Таки Вы это заметили :-)

(267) На самом деле я не заметил, ибо я не видел своими глазами чтобы ты писал код непрерывно и без ошибок. :0)

(268) А много моего кода Вы видели? И сколько в этом коде было ошибок?

(269) Не видел. В конечном коде ты уже мог найти и исправить все ошибки, а это не безошибочное программирование. :0)

(270) Если ошибок нет, то почему же оно не безошибочное? :-)

(271) Если ошибок уже нет, то это не значит что их вообще небыло. :0)

(271) Сколько раз запускал программу в процессе написания?

(273) Запускал какое-то количество раз. Но как можно говорить об ошибках, если я, как автор программы, еще ее не написал? Вот когда я сказал, что все сделано и отдал ее в тестирование или сразу пользователям, вот тогда начинаются ошибки. А до этого момента ошибок нет :-)

(274) Дык запуск и есть отладка

(274) В идеале это должен быть 1 раз. Если программа написана, но при компиляции или выполнении выдаёт неожиданные результаты, значит ошибка уже допущена! Нужно разбираться, почему она была допущена, вносить её в базу ошибок и устранять причины возникновения ошибки.

(276)+ Забыл закрыть скобку - внеси её в базу ошибок. Устрани причину: при нажатии на открывающую скобку сразу же ставь закрывающую.

Ошибся с числом параметров функции - внеси в базу ошибок. Устрани причину: при написании имени функции сверься с хелпом или, если это твоя функция, то с её заголовком.

(277)+ Подобная постоянная работа с базой ошибок быстро выработает подсознательный рефлекс - программировать безошибочно, чтобы программа запускалась и работала правильно с первого раза.

(278) скорее это сформирует рефлекс писать в базу ошибок, как Гений1С - в КЗ

(279) Если каждая запись сопровождается датой и временем, то статистика покажет, произошло ли явное снижение количества ошибок или нет.

(280) И время внесения в базу ошибок будет занимать треть всего времени...
Не говоря уже о ДОРАБОТКАХ....Ведь написание с нуля - это одно, а доработка существующей - совсем другое.

(278) Это будет средство против не допущения повторения уже известных ошибок, но сама по себе это средство не приведёт к устранению источника появления всех ошибок. :0)

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

Мы уже договорились, что сроки и деньги нас не ограничивают. Нас интересует качество. Допустим, нужно написать программу ориентировочно в 10000 строк за год, располагая десятком разработчиков. Можно ли гарантировать, что в этих строках не будет ошибок (или будет 1-2 ошибки)?

(280) предложенное тобой в (276-278) - это не работа, а kind of бюрократия. [Иде я] пральна сказал, такая работа породит рефлекс не кодить без ошибок, а вместо работы в базу ошибок отписки совать

(284) База предполагает не только описание ошибки и её устранение, но также устранение ПРИЧИН этой ошибки.

(285)+ причин возникновения этой ошибки, т.е. чтобы в будущем ошибки подобного класса больше не возникали.

(283) Если допускать хотябы одну ошибку, то это будет означать что источник проблемы не решен. :0)

(282) знаешь сколько в КЗ и в БЗ дублирующих веток? И я не знаю, но думаю, ты со мной согласишься, что - туева хуча. А ведь КЗ и БЗ создавались для того, чтобы не дублировать ответы на однотипные вопросы... Вывод выводить или он очевиден?

(286) Способов ошибаться - бесконечное число. :0)

(276) Эдак Вас понесло, уважаемый....
Почему не заносить новую ошибку в базу, после нажатия каждой кнопки?

Прораммист - ленив по своей природе.

+(291) и в итоге программист напишет скрипт, который будет за него вносить "ошибки" в базу ошибок, а сам пойдет пить пыво

(287) Совершенства не бывает, но стремиться к нему надо. По нынешним меркам программа, содержащая 1 ошибку на 10 тыс. строк, практически идеальна.

(293) Согласен.

(293) Не верю в существование таких программ в 1С.

(295) А в 1С их нет и не будет в обозримом будущем...

(295) Язык не имеет значения. Мы говорим про НАШИ ошибки, а не ошибки платформы, компилятора и т.д. В общем случае, чем выше язык программирования, тем меньше ошибок.

осталось мелочь...
посчитать количество строк кода в УПП
посчитать количество ошибок в УПП

и сказать, что УПП идеальна..

(297) Тем наоборот ошибок больше. Чем больше операций выполняет одна конструкция языка, тем сложнее учесть все последствия этих операций...

(298) Простой подсчёт точек с запятой и веток форума показывает, что любая типовая конфигурация от "1С" далека от идеала.

(298) Количество ошибок (только зарегистрированных) в ней огромно. До идеала ей очень далеко...

(299) Мы подразумеваем, что неблагоприятных последствий нет, т.е. среда безошибочна.

(300) (301) сколько строк и сколько ошибок - есть статистика?.. всеж, если руководствоватся 10 тыс.строк - 1 ошибка, то в УПП, при 1 000 000 всего то 100 ошибок..

(303) Там больше 100 ошибок :-)

а что вообще считать ошибками? вот к примеру можно написать КанецЦикла. это ошибка и не взлетит. а можно допустить кучу методологических ошибок. допустим, рассчитать себестоимость продукции по методике расчета больничного листа (утрированно конечно говорю) вроде как синтаксически правильно, программа работает, даже рассчитывает, но вреда-то от таких ошибок в разы больше!

(305) Ошибка, это когда поведение готовой программы не соответствует изначально поставленной задаче.

(303) Я насчитал там 550 тыс. строк (редакция 1.1.4.4)

Есть еще один забавный аспект.
Текст программы может быть без ошибок.
А сама программа - неработоспособной.
Например в ходе одной из бесед на этом форуме один уважаемый и весьма высококвалифицированый специалист очень долго пытался написать тот самый "хеловорд". Он не работал. Причина неудачи была в том, что автор был уверен, что пишет на С++, а на самом деле писал на каком-то из майкрософтовских диалектов, которых никто кроме вижалстудии не разумеет.
Это же пример того, что даже хорошо владея инструментом (языком) без наличия привычного окружения допускаются мелкие неточности (например забыть инклуд), которые формально являются ошибками, но с легкостью корректируются средой автоматически или явным указанием на этапе предкомпиляции. Но вот пользоваться ли этим инструментом? Если "среда идеальна" - почему нет. Но разве у нас такая есть?

(308) Если разработчики процессоров, компиляторов, операционок, баз данных и т.д. будут программировать безошибочно, то такая среда со временем появится. Но начать можно с себя и своих программ.

(309) Неа, нам столько не платят. И сроки не такие. И мотивации нету писать без ошибок :)

Для начала надо ставить задачу без ошибок :)

Кстати, разработчики процессоров и компиляторов по качеству кода очень близки к разработчикам ПО шаттлов. Ошибки в процессорах и компиляторах исключительно редки.

в основном эта ветка - "с пустого в порожнее"

(312) ошибок в компиляторах выше крыши и gcc хорошие пример этого!

(313) Если бы только эта ветка...

(313) Ну почему же. Есть интересные мысли.

Если программа идеальна, то нужны ли конструкции типа
Попытка
Исключение
КонецПопытки;

(315) но эта особенно поражает серьезностью темы и содержания.
Типа: "как добиться мира во всем мире?" или "построить крепость из спичек"

(317) Этими конструкциями можно защититься от внешних неидеальных программ.

(317) Есть методы программирования без таких конструкций. На channel9 есть интересные интервью на эту тему (не помню сейчас фамилию дядки, который про такие способы рассказывал).

(319) Можно защитится кучей других конструкций...

to Волшебник

те ошибки, о которых ты говоришь, не являются существенными для качества.
И устраняться они должны не за счет тренировки программиста, а за счет совершенствования инструментальных средств.
Т.е. текстовый редактор программы должен контролировать закрытие скобок и прочие ошибки синтаксиса. Более того, он должен исключить возможность части ошибок и, например, не допускать внесение строки по вызову функции с неуказанными параметрами. По большому счету, редактор программы должен обладать свойством мнгновенной компиляции, т.е. компиляции на стадии ввода кода.
Другой выход состоит в повышении уровня абстракции мышления, оперировании при программировании понятиями более высокого уровня.
Этот процесс идет с самого зарождения программной индустрии и будет и дальше развиваться.
НО! Проблема не в устранении синтаксических ошибок, а в устранении ошибок проектирования. А вот это уже гораздо сложнее.

А можно еще проанализировать обнаруженные ошибки, и попытаться установить причину их появления.

(322) Я с тобой полностью согласен.

в упп (релиз 1.2.4) около 300 ошибок при 867 984 ошибке...

(325) 1с - дармоеды

(325) 867 984 ошибок - это мощно! Это повод для гордости!

(322) Это да, только такие программисты (которые и спроектируют хорошо)
выдавлены демпингом быдлокодеров на той же, например, 1С :) Не все, конечно же,
ведь конторы, готовые платить нормальному программисту, держат нормального
программиста.

(327)да.. мощно.. ))..

надо бы апнуть

(330) А смысл? Все равно никто не бросится в корне менять свой подход к работе, чтобы сократить количество ошибок...

(331) Я хочу попробовать новую технологию при реализации нового движка форума.

какой щастье, когда есть желание что либо делать..

(333) Счастье - это когда тебе есть кого любить, что делать и на что надеяться. Китайская мудрость

(334)  66 процентов набрал.. блин.. чот дьявольское получилось..

(332) ну успехов.
Только какие новые фичи ты хочь сделать?

(332) Что-нить типа Экстремального Программирования? :) Или что-то
действенное? :)

(336) Книга знаний: Планы развития сайта mista.ru

(338) А как относится перевод на InnoDB к ускорению? Это скорее
затормаживание...

(339) За счёт определенного уровня изоляций транзакций, поддерживающих. "грязного чтения". И радикально повышается надёжность. MySQL-таблицы часто рушатся.

Из серьёзных недостатков InnoDB могу отметить только то, что в них нет полнотекстового индекса.

(240) InnoDB и MyISAM пока выступают как надёжный и быстрый концы. Консенсуса
нет :) Нужно что-то выбрать :)

(341) Текущий движок форума уже переведён на InnoDB. Результаты положительные. Таблицы не рушатся. Быстродействие заметно не пострадало.

(342) По идее, SELECT'ы не должны сильно замедлиться, а вот INSERT'ы, UPDATE'ы
и DELET'ы должны чуть затормозиться...

(343) Соотношение операций модификаций к операциям чтения примерно 1 к 100.

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

(341) MyISAM нужен только для полнотекстового поиска. Про его якобы быстроту расскажи Волшебнику, когда тут все тормозило. :-)

На одиночных операциях может MyISAM и быстрее, но когда 100 человек читают и один пишет, то он обламывает 100 читающих (чтение начинается сначала). REPEATABLE READ происходит, как я понимаю.

(0) тяжело но "ДА".

(0) Я думаю, что скоро будет смена ПАРАДИГМЫ в программировании.

Ошибки кодинга.
Мощность компов растет, пора бы облегчить жизнь кодерам :)
Если растет уровень языка, количество ошибок кодера уменьшается. Чем мощнее наши компы, тем более высокого уровня языком можно пользоваться, при необходимости оптимизируя критичные для нужного быстродействия куски программы.
Через несколько лет будет 1С 9.9, и в ней модуль проведения документа будет состоять из 1-5 строк :), а типовой отчет из 1 строки :)
Ошибкам кодинга при такой лаконичности языка просто не будет физически места в коде, негде им будет спрятаться :)

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

(348) Поголовно перейдём на функцональное программирование?
А от 1С не дождёмся нормальной архитектуры, по-видимому, никогда. Тем более в
свете грядущего вендекапеца.

Все ниасилел
Отладчики нужны, т.к. мы живые люди.
И это прекрасно!

Ребята, а вы классиков вообще читаете? Ну там Макконнела или Фаулера? Программ без ошибок не бывает. Совсем. Просто можно писать программы с минимумом ошибок(ну например 10 на 1000 строк кода).

(334) ну какая ты все-таки умница...

фуф, осилил... писать надо с ошибками, чтоб потом можно было бабла срубить за исправление ошибки :)

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

(351) Опять же, какие ошибки имеются в виду? Никакой кодер не сможет писать без
логических ошибок, если архитектура проекта плохо спроектирована (например, не
выделены ортогональные модули с описываемым функционалом).

(351) Умудрился написать обработку на полторы тыщи строк без ошибок... Прошу прощения, я не нарошно... И, к сожалению .порка это единственный случай...

Пока)))

(332) Пожалуйста, не надо новых технологий, просто подойдите к работе не торопясь и с умом.

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