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

[Dimka]

Хотя то, с чем я сталкивался в американской литературе было много механистического, или я просто мало читал.

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

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

Потому что (хоть ты с этим и не вполне согласен) у человека мышление организовано таким образом, что понимание взаимосвязей возникает как озарение, когда все необходимые части находятся в центре внимания (и самих частей не больше, чем человек способен удержать вместе). Хотя бы для банальной верификации написанного при чтении программы в поле "зрения" должны концентрироваться только те части, которые непосредственно относятся к делу. При множественных точках входа и выхода (какие-нибудь GOTO извне внутрь ветви условия и наоборот) это становится невозможным: нужно отследить процесс вычисления от каждого входа до каждого выхода (и таких сценариев оказывается полное декартово произведение входов и выходов - сложность порядка N^2), кратковременной памяти не хватает, чтобы удержать внимание на всех сценариях и на всех частях блока одновременно. Ещё больше положение усугубляется при использовании разными блоками, каждый из которых имеет много входов и выходов, каких-то общих разделяемых ресурсов (например, глобальных переменных), поскольку состояние занятости этих ресурсов можно определить только после взаимного сцепления всех сценариев предыдущего и всех сценариев последующего блоков, что приводит к ещё одному полному декартовому произведению (сложность возрастает до порядка N^4).

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

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

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

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

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

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

[ezus]

И где у Дейкстры про одномерность?

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

Там только про ограниченность в добавлении 4го измерения к статической картинке.

Поясните, пожалуйста, что за 4-е измерение. А понял - это время. Ок! Поэтому в моей модели есть как статическая, так и динамическая одномерность.

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

Так о том и речь, что СЛОЖНО.
И как этому помочь?
Мне кажется очевидным, что многомерное, представленное в двумерном, легче принять, чем то же, но в одномерном. В этом и гениальность блок-схем. А то, что они не идеальны, так и что - идеального вообще не существует.

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

[ezus]

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

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

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

[Вад]

И где у Дейкстры про одномерность?

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

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

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

Там только про ограниченность в добавлении 4го измерения к статической картинке.

Поясните, пожалуйста, что за 4-е измерение. А понял - это время. Ок! Поэтому в моей модели есть как статическая, так и динамическая одномерность.

Что есть статическая одномерность и почему это проблема?

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

Мне, напротив, кажется, что они - далеко не лучшее решение. Глаз никогда не движется по картинке так, как нарисовано на стрелочках. Он движется куда хаотичнее, и главное ему ухватить сложно, особенно если фигуры сочетаются с текстом. Вообще, нотация блок-схем мне кажется неудобной, и при необходимости что-то такое проиллюстрировать коллегам на бумаге я стараюсь упрощать.
Вот что-то вроде mind-map-ов или UC-диаграмм - пожалуй, более наглядный вариант - то есть, конечно, испортить можно всё, но в данных типах диаграмм глаз за нужное цепляется. Mind-map-ы, кстати говоря, даже лучше могут описывать код в 2d, чем блок-схемы.

[Dimka]

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

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

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

[Dale]

IMHO насчет использования GOTO проблема несколько преувеличена.

Пресловутый FORTRAN, который немыслим без использования GOTO, - это язык 50-х годов прошлого века. Не следует забывать, из чего в то время делались компьютеры. Планки памяти по 4 гигабайта в супермаркетах не продавались, даже транзисторы в обиход еще не вошли. Оперативную память делали из чего попало, в ход шли заряженные конденсаторы, ферритовые колечки, даже осциллографические трубки. ОЗУ в 8 килобайт считалось просто роскошным (сегодня далеко не каждый компилятор в этот объем уложит суперпрограмму "Hello World"). Попробуйте вогнать в этот объем более-менее приличный компилятор с его таблицами, оптимизатором и т.д.

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

Прошло некоторое время, компьютеры подросли. Тут же появился знаменитый Algol-60, который стал основой практически всех современных языков программирования. Этот язык располагал уже всеми необходимыми средствами, позволяющими обойтись без GOTO. В результате программисты на языках высокого уровня стали обходиться без него. Ну а тем, кто сегодня пишет на ассемблере, можно читать лекции о вреде GOTO, можно их стыдить, но их инструмент просто не позволяет писать по-другому.

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

[ezus]

Для меня непонятно, почему именно "одномерность".

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

Что есть статическая одномерность и почему это проблема?

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

Мне, напротив, кажется, что они - далеко не лучшее решение. Глаз никогда не движется по картинке так, как нарисовано на стрелочках. Он движется куда хаотичнее, и главное ему ухватить сложно, особенно если фигуры сочетаются с текстом. Вообще, нотация блок-схем мне кажется неудобной, и при необходимости что-то такое проиллюстрировать коллегам на бумаге я стараюсь упрощать.
Вот что-то вроде mind-map-ов или UC-диаграмм - пожалуй, более наглядный вариант - то есть, конечно, испортить можно всё, но в данных типах диаграмм глаз за нужное цепляется. Mind-map-ы, кстати говоря, даже лучше могут описывать код в 2d, чем блок-схемы.

И UML, и mind-map, в русском переводе "карты памяти" - прекрасная вещь.
Но ведь их использование только подтверждают мои выводы. Почему Вы используете картинки, а не обычный линейный текст? Если все так просто, то зачем картинки?

"Глаза двигаются хаотично" -  это правильно, если вы имеете ввиду движение зрачков.  Но их скорость намного превышает скорость нашего осознанного восприятия, поэтому мы не чувствуем этой хаотичности и воспринимает картинку уже готовой в целости, в её двухмерности. Конечно, и этот способ восприятия имеет свои ограничения, но он все-таки мощнее восприятия линейного текста.
Теперь о блок-схемах. А я и не говорил, что это что-то сверх ого-го. Мы от них отказались еще в 76 году, взяв на вооружение другие нотации. Я говорил лишь о том, что блок-схемы были ПЕРВОЙ удачной попыткой борьбы с нашей одномерной ограниченностью.

[ezus]

IMHO насчет использования GOTO проблема несколько преувеличена.

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

Тут же появился знаменитый Algol-60, который стал основой практически всех современных языков программирования. Этот язык располагал уже всеми необходимыми средствами, позволяющими обойтись без GOTO. В результате программисты на языках высокого уровня стали обходиться без него.

Да ничего подобного.
Возможно Вам повезло и Вы не встречали программ на Algol-е, написанных в классическом стиле спагетти с томатным соусом.
Сам по себе язык, только дал возможность писать структурно, но и только. Для того, чтобы отказаться от GOTO потребовалось еще 10 лет, я бы даже сказал 15-20.

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

Проблема ведь не в команде JMP, а в алгоритмическом GOTO. Мы и на Коболе писали структурно. Проблема в произвольности точки перехода GOTO. Если эта точка фиксированная( типа конец цикла или условного оператора), и мне не надо думать, что там за ней, то в самом переходе нет проблем.

Так что говорить о вреде GOTO сегодня - все равно что говорить о вреде хождения на четвереньках.

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

[Вад]

Для меня непонятно, почему именно "одномерность".

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

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

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

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

И UML, и mind-map, в русском переводе "карты памяти" - прекрасная вещь.
Но ведь их использование только подтверждают мои выводы. Почему Вы используете картинки, а не обычный линейный текст? Если все так просто, то зачем картинки?

Картинки - это только абстракция. Для сжатого выражения идей, которые можно выразить в коде. Более лаконичный и менее неоднозначный язык - только и всего.

[ezus]

To Вад.
Возможно, Вы и правы, и мои сомнения, рассуждения надуманы и не имеют под собой никакой почва.

Но если исходить из Вашей позиции, то и кодирование в кодах машины не должно вызывать трудностей, ведь учили, учились и писали.
Зачем эти языки? Зачем придумали модульность, структурное программирование, тоже ООП, та же функциональная парадигма, UML, и др. и др?

Как мне кажется Ваша позиция не конструктивна, поэтому я пока останусь при своем мнении.

[Dale]

...
Установлено, что в свое время программисты допускали ошибки при использовании оператора GOTO в пять раз чаще, чем все остальные ошибки вместе взятые.
...
Сам по себе язык, только дал возможность писать структурно, но и только.
...
Мы и на Коболе писали структурно.

Замечательно. Подведем краткий итог:

1. Есть заведомо опасный оператор GOTO, использование которого чревато ошибками.
2. Появляются языки программирования, которые позволяют обходиться без него и тем самым создавать более ясные и элегантные программы.
3. Кроме того, создается методология структурного подхода к написанию программ, использование которой позволяет писать структурированные программы даже на изначально неструктурных языках.
4. Несмотря на все это, многие "профессионалы" продолжают игнорировать новые возможности и производить заведомо низкокачественный код, имея при этом все объективные возможности избежать этого:

Возможно Вам повезло и Вы не встречали программ на Algol-е, написанных в классическом стиле спагетти с томатным соусом.
...
Для того, чтобы отказаться от GOTO потребовалось еще 10 лет, я бы даже сказал 15-20.

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

[Вад]

Но если исходить из Вашей позиции, то и кодирование в кодах машины не должно вызывать трудностей, ведь учили, учились и писали.
Зачем эти языки? Зачем придумали модульность, структурное программирование, тоже ООП, та же функциональная парадигма, UML, и др. и др?

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

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

[ezus]

А зачем люди вообще создают новые инструменты? Для эффективного решения задач.

Простите, но Вы возражаете только для того, чтобы возразить? Или Вы действительно не видите, что льете воду на мою мельницу?

Вам НУЖЕН кран для того, чтобы занести буханку хлеба себе домой? А мешок картошки? А шкаф? А концертный рояль?
Да и с хлебом не все понятно: если это первый этаж или пятый, то вопросов нет, а если 25 или 125? Вам лифт нужен? А зачем?

Ответ прост: мы физически слабы, ОГРАНИЧЕНЫ. И хоть ты уобучайся, утренируйся на 125 этаж рояль не затащищь.
Тоже и с нашими мозгами. Только после того, когда мы поймем в чем мы ОГРАНИЧЕНЫ, мы сможем придумать нужные "краны и лифты" для своих мозгов.

[Вад]

Команда из нескольких десятков человек затащит рояль хоть на 125й этаж. Только дешевле будет всё же лифт.

Не знаю, почему вам кажется, что это ваша мельница Самое главное ограничение у программиста и у его работодателя - это время ("Что ни день - то к смерти ближе"). Зачем тратить время на лишние детали реализации, если можно взять высокоуровневый язык и написать на нём всё то же самое, но во много раз быстрее и короче? Зачем годами тащить рояль на 125й этаж, если можно вызвать лифт?

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

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

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

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

И, кстати, языки вполне чётко отражают реакцию на те проблемы, которые встают перед программистами. Сейчас на глазах прокатывается вторая волна эволюции языков. Первая волна была от машинных кодов и ассемблеров через алголы к лиспам, Smalltalk и т.п. Вторая - опять от ассемблера через C/C++ к языкам высокого уровня типа java/Python/C# и т.п.. По мере удешевления процессорного времени и памяти опять можно перестать дрожать за каждый байт, ввести ссылки и сборку мусора, и даже пользоваться интерпретаторами. Словом, забрать у программиста ненужную рутину (пусть и ценой падения эффективности - ну и что) и освободить его для решения более масштабных задач.

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

[ezus]

To Вад.
Возможно, Вы и правы.

[ezus]

Замечательно. Подведем краткий итог:
1. Есть заведомо опасный оператор GOTO, использование которого чревато ошибками.
2. Появляются языки программирования, которые позволяют обходиться без него и тем самым создавать более ясные и элегантные программы.
3. Кроме того, создается методология структурного подхода к написанию программ, использование которой позволяет писать структурированные программы даже на изначально неструктурных языках.
4. Несмотря на все это, многие "профессионалы" продолжают игнорировать новые возможности и производить заведомо низкокачественный код, имея при этом все объективные возможности избежать этого:

Algol-60 потому и 60, что был изобретен в 60 году.  В 60-ом году оператор GOTO был обычный оператор, он не был опасен, он ничем не отличался от других, он был необходим как и любой другой оператор. О том, что он плохой впервые было сказано в 64 году, и для этого потребовался гений Дейкстры. Тольно в 66 году было доказано, что без GOTO можно обойтись. И только в начале 70-ых годов Дейкстра и Вирт предложили структурное программирование. Первый печатный перевод в России появился только в 76 году. Поэтому ничего удивительного, что еще 20 лет после Algol-60 программисты считали GOTO одним из главных операторов ЛЮБОГО языка.
Еще в начале 80-х годов слушатели профессиональных курсов повышения квалификации слыхом не слыхали о проблеме GOTO и структурном программировании. Кстати, одной из причин появления моей коллекции моделей была попытка убедить уже опытных программистов в том, что не все ладно в нашем королевстве. Они не понимали зачем нужно то, о чем я рассказывал - они писали программы без всех этих философий и будут писать. А сейчас? Многие ли задумывается над основами своей профессии? А это была вторая причина для коллекции: отличаются ли профессиональные программисты от любителей, получивших знание в школе в виде Бейсика?

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

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

Всем участникам обсуждения этого "глупого" вопроса СПАСИБО. Был ряд очень интересных и полезных замечаний.
Особое СПАСИБО за ссылку на архив статей Дейкстры.

[Dale]

Algol-60 потому и 60, что был изобретен в 60 году.

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

В 60-ом году оператор GOTO был обычный оператор, он не был опасен, он ничем не отличался от других, он был необходим как и любой другой оператор. О том, что он плохой впервые было сказано в 64 году, и для этого потребовался гений Дейкстры.

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

Первый печатный перевод в России появился только в 76 году.

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

Поэтому ничего удивительного, что еще 20 лет после Algol-60 программисты считали GOTO одним из главных операторов ЛЮБОГО языка.

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

Еще в начале 80-х годов слушатели профессиональных курсов повышения квалификации слыхом не слыхали о проблеме GOTO и структурном программировании.

К тому времени даже в СССР был вполне доступен тот же Pascal, так что, как говорится, было бы желание...

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

А если не отличаются, то в чем тогда заключается их профессионализм? Только в амбициях и в том, что они за свою писанину еще и деньги получают?

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

Вот здесь не совсем понятно.

[Dimka]

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

Возражаю "Другой" не значит "отсталый". "Отставание" или "опережение" очень сильно зависит от выбора параметрической базы для сравнения

[ezus]

Не совсем так. Это не изобретение, а итог работы коллектива, который начал работу в 1958 году

Согласен, некорректная фраза с моей стороны.

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

Согласен, но это частности и не меняет сути дела.

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

Согласен, но это частности и не меняет сути дела.

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

Снова согласен, но это как раз показатель - показатель того, что программисты не знают "Что такое, хорошо, а что такое плохо". И даже, если и знают, то не понимают ПОЧЕМУ. А когда не понимаешь, то и действуешь не всегда в соответствием с рекомендациями каких-то дядь.

К тому времени даже в СССР был вполне доступен тот же Pascal, так что, как говорится, было бы желание...

Желание возникает из потредбости, а вот ее то и не было.

А если не отличаются, то в чем тогда заключается их профессионализм? Только в амбициях и в том, что они за свою писанину еще и деньги получают?

Для меня "профессионал" - это тот, кто ПОНИМАЕТ "ЧТО и ПОЧЕМУ" в его сфере деятельности, а не только знает набор частных приемов.
Возможно, я не прав в определении, но только в слове "профессионал". Если сможете, то предложите другое слово.

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

Вот здесь не совсем понятно.

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

И в то и в другом случае надо пойти поспать и подумать.

[Dale]

Возражаю "Другой" не значит "отсталый". "Отставание" или "опережение" очень сильно зависит от выбора параметрической базы для сравнения

Хорошо, вот "параметрическая база".

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

• мэйнфрейм ЕС-1061, доступ к телу которого расписывался по часам;
• несколько СМ-4 (объем ОЗУ 256К, каждая обслуживала 16 терминалов типа VT52 или VT100);
• несколько штук "персоналок коллективного пользования" ДВК-2 с двумя флоппи-дисками смешной емкости (если на системном диске размещался компилятор Pascal, места для утилит уже не оставалось, нужно было жонглировать дисками, как заправский ди-джей);
• несколько штук ЕС-1840 (кто не помнит - аналог IBM PC (даже не XT) в весьма спартанской конфигурации), на которые также выстраивались очереди не меньше, чем за кобасой или импортными сапогами

Вот такой внушительной технической базой располагал коллектив в несколько тысяч человек.

Когда речь заходила об автоматизации измерений или техпроцессов, засучивали рукава умельцы, способные спаять нечто на базе микропроцессора 580ВМ80.

Вот такая "параметризация" глазами очевидца. Кстати, в политкорректных Соединенных Штатах словом "другие" называют, например, больных синдромом Дауна...

[Dimka]

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

Но "другой" выбор отраслевых приоритетов, нежели в тех же США, вовсе не отменяют упомянутых умельцев, отдельные уникальные и до сих пор интересные наработки проектировщиков, конструкторов и схемотехников.

Поэтому не во "всём".


P.S. По поводу больных синдромом Дауна могу посоветовать почитать книжку Нильса Кристи "По ту сторону одиночества" - там понятие социальной нормы показано в неожиданном свете. Расширяет кругозор и обогащает мировосприятие.

[Dale]

Желание возникает из потредбости, а вот ее то и не было.

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

Инженерные науки тоже требуют определенной культуры.

В основе моих размышлений лежит тезис об ограниченности возможностей нашего мышления.

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

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

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

[Dale]

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

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

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

[ezus]

Инженерные науки тоже требуют определенной культуры.

А почему Вы не продолжаете?
А откуда берется культура? Ее кто-то делает?
Я не думаю, что Вы придерживаетесь взгляда, что культура берется только с Великого Запада, а мы должны безропотно, с закрытыми глазами, хавать то что есть у них, и бездумно применять у себя.
Я не считаю, что они на много умнее нас, просто у них фора. Но могут быть и шоры.
Поэтому я хочу САМ понять, и если у них нет ответов на мои вопросы, то попробовать найти их самому.

В основе моих размышлений лежит тезис об ограниченности возможностей нашего мышления.

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

Было несколко причин, по которым я выбрал GOTO. У меня были сомнения на этот счет, и я сам возражал себе почти Вашими словами.

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

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

3. Это только пример, и я ни где не говорил, что это актуально. Просто это понятно.

4. И последнее, но может быть главное. Моя коллекция бесспорно устарела, и я хотел ее обновить. Придумывать что-нибуть новое не было времени и я использовал свои старые примеры и рассуждения. Я надеялся, что кроме критики я найду в обсуждении что-нибуть конструктирное, но увы. Наверно, сам виноват.

[Dimka]

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

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

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

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

Намедни с Вадом просматривали один сборник, посвящённый использованию суперкомпьютеров в РФ. В частности там одна  рабочая группа предлагала использовать суперкомпьютер для расчёта колеса железнодорожного вагона! Вкратце ключевой аргумент: уж коли есть ресурс, то проще тупо посчитать полным перебором, нежели корпеть над аналитическими моделями.

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

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

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

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

P.S. Глядя на АРМ банковских операционистов, магазинных кассиров, гостиничных администраторов и т.п., мне всегда казалось, что в принципе для подобных задач достаточно старинных 8-иразрядных PC типа Robotron или Spectrum в сети с одной машиной помощнее. При желании, даже отставая по элементной базе лет на 20, можно было бы массовым производством и соответствующими архитектурными решениями добиться качественных изменений в быту людей и деятельности многих предприятий. Ведь качественное оружие (в основном, всякие ракеты, космические аппараты и РЛС) на такой жлементной базе благополучно функционировало.

[ezus]

)

[Dale]

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

Аналогично где-то у Эда Поста была фраза о том, что "закоренелый  настоящий  программист может написать фортрановскую программу на любом языке". Когда массовый производитель свистулек и погремушек осваивает ООП, через некоторое время с его конвейера начинают сходить свистящие и гремящие объекты. Что же тут удивительного?

[Dimka]

Что же тут удивительного?

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

[Dale]

А почему Вы не продолжаете?
А откуда берется культура? Ее кто-то делает?

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

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

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

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

Я не считаю, что они на много умнее нас, просто у них фора. Но могут быть и шоры.

Помилуйте, откуда это размежевание - "мы", "они"? И за бугром, и здесь есть настоящие умницы и трудяги, есть середнячки и есть ниже среднего, мягко говоря. И форы давно никакой нет. Давно ушли те времена. Сейчас в любом супермаркете можно не слишком дорого купить персоналку не слабее той, на которой учатся программировать студенты Кембриджа или Оксфорда. Можно скачать на нее тот же софт, которым они пользуются. Наконец, благодаря интернету можно читать те же учебники. Какая тут фора?

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

Я надеялся, что кроме критики я найду в обсуждении что-нибуть конструктирное, но увы. Наверно, сам виноват.

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

[ezus]

Вы правы. Пожалуй, я просто выбрал не те слова.
А "конструктив" я имел ввиду исключительно, с т.зр. пополнения моей коллекции.
За остальное - Спасибо.