Почему программисты допускают ошибки?

[ezus]

Вад(76):
Все правильно, но не все конструктивно.
Моя цель, мои желания - уменьшить искусство в программировании, увеличить объективизм.
Хотелось бы, что бы программа не зависела от программиста, а определялась только задачей, средой и вышестоящими критериями и ограничениями. Это, конечно, умоляет высокую роль ПРОГРАММИСТА, да и мне самому, как программисту, совсем не нравится, но, проработав много лет руководителем различных программистских коллективов, как руководителю, мне не хотелось бы зависеть от отдельного программиста. И мне это удалось, правда, это было давно, можно сказать, в другой жизни, в другой среде и других программных средствах. Но желание осталось.

[ezus]

Возьмешься на оформление статьи?

В этом то и моя проблема - статьи писать НЕ МОГУ. Вот, если бы в паре с кем-нибудь. Авторство меня уже мало волнует.

[Sla]

ezus, тут не писательство надо, надо собрать до кучи - писатели найдутся.

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

[ezus]

Sla(82):
Красивая выборка и спасибо за ссылку.
Если интересные мысли, которые хочется добавить в коллекцию.

[ezus]

ezus, тут не писательство надо, надо собрать до кучи - писатели найдутся.

Куча-то у меня есть.
Я попробую ее тут кратко представить, и если она представляет интерес, то ...

я тоже не писатель, но две статьи в кармане уже есть, третья чего-то ждет, или кого-то

Где-то можно посмотреть?

[Sla]

ezus, та не вопрос
http://slasoft.kharkov.ua/article/


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

[Sla]

сейчас подсчитал :)Четыре! моих

[ezus]

Ок! Будем просвещаться.
У меня тоже были когда-то что-то в каких-то сборниках. Но кто сейчас помнит? Это было давно и неправда.
За ссылки спасибо.

[ezus]

Несколько комментариев к, наверняка, очень полезной статье "Семь хороших объектно-ориентированных привычек при программировании на PHP" Натана А. Гуда

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

Конечно, повторное использование подразумевает модульность, если исключить COPY/PASTE .
Но ведь после FORTRANа главное назначение модульности - это борьба со сложностью. Основная масса функций и процедур никогда больше не будет использоваться. Они были созданы не для этого. а для обеспечении большей прозрачности кода, лучшей управляемости процесса проектирования. Большенство из них вообще не имеют смысла вне данного контекста.
А если говорить об ООП, то это в полной мере относиться private методам. Да и к public методам обращаются часто только из одного места. Во всяком случае я к этому стремлюсь.

преимущества ООП-подхода проявляются при последующем сопровождении.

И опять. Конечно, ООП-подход очень помогает при сопровождении, но ведь главный эффект достигается при проектировании программы.
Это мне напоминает эпопею с GOTO 30 лет назад.
В то время, до внедрения структурного программирования, обычную среднюю программу я писал 2-3 недели. Свою первую программу "без GOTO" я писал 1.5 месяца, но я знал, что это правильно и так надо. После осмысления того, что же такое "структурное программирование", написание таких же программ занимало несколько часов. Я не преувеличиваю. Такой эффект был не только у меня, но и у всех наших сотрудников. Через слезы, ругань, переписывания уже отлаженного кода.
Самое интересное, что авторы тех статей и книг, с которых мы начинали, тоже считали, что структурное программирование увеличивает время разработки, но зато сокращает затраты на сопровождение.
Но это чушь.
Вся проблема в изменении метода мышления. Если ты мыслишь по-старому, то применение новых методик только ухудшает ситуацию. Спагетти можно устроить и в ООП, а можно писать структурно на ассемблере. Кстати, мы начинали с Кобола, который был, ох уж как, не структурный, но это нам не мешало.

[Sla]

Offtopic:

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

Поставлю в угол.

[Sla]

ezus, я не сильно от тебя отстал в возрасте, но меня сразу научили структурному программированию. Изучая фортран, меня просто клинило от необходимости писания goto. Это приводило к ошибкам написания кода, к поиску меток, к ошибкам ссылок на метки и прочее. Благо, первым языком для меня стал PL.

[Sla]

я бы еще привел одну "ошибку" - необоснованность применения ООП методов программирования.

Стоит маленькая задача. Написать простенькую обработку.
Ааа. Что?
Класс. Бац. Метод, Бац.
Бац! А оно не работает. А почему? а потому, что не то наследовал, не тот конструктор и т.д.

Т.е. есть задачи и есть ЗАДАЧИ.

Применение различных методов решения к различным задачам. Но это уже относится к средствам и методам избегания/недопущения ошибок.

[Dale]

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

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

Замечательно. Будет очень интересно ознакомиться. Думаю, отнюдь не мне одному.

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

[Sla]

Та какой там такт? Та почти поголовно всех к стенке
Основная ошибка - отсутствие желания получения знаний.

[Dale]

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

Основная ошибка - отсутствие желания получения знаний.

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

[ezus]

меня сразу научили структурному программированию.

Вам повезло - не надо было ломать свое мышелние. Конечно, если Вас правильно учили. На заре структурного программирования его иногда называли "программирование без goto". Что, конечно, далеко не так. Не потому надо избегать goto, что он плохой оператор, а он просто не нужен при правильном мышлении. Кстати, языковя модель коллекции это нелпохо объясняет.

Изучая фортран, меня просто клинило от необходимости писания goto. Это приводило к ошибкам написания кода, к поиску меток, к ошибкам ссылок на метки и прочее.

Вот передо мною и встал вопрос "Почему", чем этот оператор так уж плох.

Благо, первым языком для меня стал PL.

Мощный язык, но уж больно тяжелый. Одно слово IBM 360

[ezus]

я бы еще привел одну "ошибку" - необоснованность применения ООП методов программирования.

Т.е. есть задачи и есть ЗАДАЧИ.

Применение различных методов решения к различным задачам. Но это уже относится к средствам и методам избегания/недопущения ошибок.

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

[ezus]

Dale:(102) "Срочно пАмАгите!!!"
Забавно, интересно и,дейтвительно, может быть полезно.
Давайте попробуем.
Хотя на маленьких примерах далеко не все можно показать.

[Алексей++]

А меня программированию не учили Самоучился, и никакого, естественного, структурного программирования не знал поначалу. Машинка - Орион128 , если кто встречал, поваял там на бейсике - тесно, перешёл на ассемблер (он там простенький). Нагородил без знания ООП много всего ()сейчас на той самой машине я бы совсем другой подход к asm-программам осуществил) , что-то работало, что-то с ошибками, но модифицировать сложно. Одной игрой моей отец даже заигрался потом ) Но иногда она сглючивала, а лезть в старую кашу кода не хотелось. Главное - юзверь (отец) был доволен, а что ещё надо ? ) Кстати, это он меня и сподвигнул и заинтерисовал программированием. Сам он тоже самоучка, методом проб и ошибок (ведь тогда интернетом у нас и не пахло, а из литературы - редкие книги да "Радио" )
Когда перешёл на с++ , от goto отказался сразу, хотя было желание применять. Но прочитал где-то - НЕХОРОШО ))) И не стал применять

[Антон (LogRus)]

http://ru.wikipedia.org/wiki/GOTO

[Алексей++]

LogRus, даёшь добро ? ) Ну тохда ой. Приступаем к использованию ) На самом деле, были такие случаи, когда из кучи циклов хочется выйти goto, но не делал такого. Насчёт быстродействия в курсе. Всё таки стОит ?

[Sla]

Алексей1153++, по-большому счету ты иногда используешь неявный goto, смотри пример с break

[Вахмурка]

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

[ezus]

Огромное спасибо переводчикам и составителям подборки статей великого Дейкстры.
Наконец, произошло то, о чем я даже не мечтал.
Я впервые прочитал статью, на которую ссылался последние 30 лет.
Простенькая небольшая статья Дейкстры "Доводы против оператора goto".

Сейчас она может показаться уже не актуальной, но...

Из краткого описания ПСИХОЛОГИЧЕСКОЙ МОДЕЛИ

В рамках данной модели рассматриваются 3 фактора:
-   проблема сложности
-   проклятье одномерности
-   феномен тривиальности

 2. Проклятье одномерности
...
1. Структурная одномерность:
-   одномерность нашего сознания вступает в противоречие с многомерностью окружающего мира, объектов, задачю
-   мало того, что мы осознать не можем, так мы должны еще  проебразовывать все это в линейный текст программы   именно поэтому так тяжело даются нам эти циклы, условия - особенно goto

2. Динамическая дискретность
- свойство мозга фиксировать состояние объекта для осмысления, а объект уходит вперед, изменяется

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

И вот

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

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

Читайте классиков, господа.

[ezus]

Алексей1153++, по-большому счету ты иногда используешь неявный goto, смотри пример с break

Лингвистика, лингвистика!!!
А если я назову оператор break не переходом на конец цикла, а выходом из цикла, или еще лучше "прекращением цикл", то какое это имеет отношение к goto?
Ведь главная проблема goto - это переход в ПРОИЗВОЛЬНУЮ точку, что и вызывает основные трудности. А точка перехода оператора break четко и однозначно определена - нам не надо думать о том, что там дальше.
Кстати break не единственный такой оператор. Есть еще
continue - прекращение ТЕЛА цикла
return - прекращение работы данного модуля.

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

[Алексей++]

ezus, я тоже к break и continue ровно отношусь и не считаю полным эквивалентом goto по той простой причине, что это внешне не так ) Хоть даже внутренне так. Точка перехода задаётся синтаксисом, а не вручную, и не "переедет" случайно при правке кода

[ezus]

ezus, я тоже к break и continue ровно отношусь и не считаю полным эквивалентом goto по той простой причине, что это внешне не так ) Хоть даже внутренне так. Точка перехода задаётся синтаксисом, а не вручную, и не "переедет" случайно при правке кода

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

Освобождаем наши мозги от ненужного хлама!!! Ясность мыслей и ничего лишнего. Их(мозгов) и так не хватает.

[Dimka]

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

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

[ezus]

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

Возможно, потому не все понял.

Если так интересуют ошибки вообще, то есть капитальная (фундаментальной назвать не решусь) и ключевая научная работа по этой теме James Reason "Human errors"

К сожалению моего английского врядли хватит на освоение этого капитального труда. Очень жаль. Хотя то, с чем я сталкивался в американской литературе было много механистического, или я просто мало читал.

Кстати, ты не мог бы со своих позиций прокоментировать мой пример с оператором IF?

А будто бы я это уже сделал, упомянув подпрограммы.

Вот это место я точно не понял.

Какое главное свойство стркуктурного оператора? - Один вход \ один выход?
А почему? Зачем? Как это может нам помочь?

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

Все правильно. Но меня интересует: ПОЧЕМУ от программиста требуются дополнительные усилия?;
ЗАЧЕМ на уровне человекочитаемой программы НУЖНО "однозначное взаимное упорядочивания частей алгоритма"?.

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

в диалоговом режиме код программы - это не только продукт писания, это ещё и объект чтения.

Скорее все наоборот. Раньше программа не писалась, а читалась - на бланка, в распечатках. Другого способа работы с программой просто не было. Только через её текст.
Это сейчас на код многие смотрят только через окно дебагера, а текст только пишут.

Но давай эту мысль рассмотhbv в ретроспективе. Есть какие-то внятные рекомендаци, какие действия и в каком порядке включать в алгоритм для того, чтобы алгоритм решал поставленную задачу? По-моему, всё сводится к туманным словам о том, что это вопрос творческий

Почему же - были и очень даже конструктивные. Этому посвящена отдельная часть моей коллекции: декомпозиционные модели. Там рассматриваются различные стратегии и критерии декомпозиции - объективные критерии.

[Вад]

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

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

И где у Дейкстры про одномерность? Там только про ограниченность в добавлении 4го измерения к статической картинке. Ну так, всё верно, сложно удерживать в памяти многомерное меняющееся во времени тело. Поэтому изменяемые состояния и считаются основным источником проблем.

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