DRAKON.SU

Ну, время покажет, кто прав. Лично моё "теоретическое" физмат-образование вкупе с 9-летней непрерывной практикой программирования (практически все типы ПО) и 6-летней педагогической говорит мне, что "крутые практики", "рефакторинги" и проч. - просто шарлатанство и мыльный пузырь.

Смешно считать теоретиком, например, Дейкстру или Хоара, или Хансена. Людей, которые спроектировали и реализовали столько систем (класса ОС, например). И хорошая образованность просто позволяла им видеть за деревьями лес и выделять принципиальные вещи и математизированные методы работы.

Уважаемый Геннадий Николаевич, Вы не знаете и не хотите знать, какой фон понимания стоит за теми утверждениями, которые кажутся Вам "предметами богословского диспута". Та же математика, столь Вами нелюбимая, позволяет чётко видеть существенные вещи, которые у практика просто "замылены", "размазаны", не выделены и не осмыслены.

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

К практикам и студентам у Вас можно наблюдать отношение: "ниже плинтуса", "просто шарлатанство и мыльный пузырь.", "сводит скулы", "Надо кого-то линейкой по рукам".

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

Какой "практики"? За ту, которая распространена, нам должно быть стыдно перед нормальными инженерами из нормальных отраслей. Безответственность, халтура, отсутствие дисциплины и контроля качества, необразованность - вот что у нас в ИТ творится.

Следует ясно понимать, что эта ситуация временная. Вызвана резким бумом 90-х - широким распространением ПК, и т.п. Потребность в программистах возникла большая, образование выпускать столько подготовленных инженеров просто не могло. Если мы посмотрим на технологии, то увидим повсеместный откат назад. Потому что приходящие новички были в принципе не знакомы с тем, что было наработано на "больших машинах" и для больших задач; и сами шли по тем же граблям (пройденным в отрасли ещё в 60-х) - через Бейсики всякие, и т.п. Возьмите практически любой раздел - технологии создания хороших языков (а концепция хорошего языка уже сложилась в 80-м; если бы тогда были предложены С++, Perl и проч., то специалисты просто бы покрутили пальцем у виска), технологии ОС (люди, работавшие на наших машинах типа БЭСМ-6 и Эльбрус просто плечами пожимали на Юникс - ну что за детская поделка)...

Такая оценка ситуации - не моя личная. На разных конференциях, общаясь с разными старыми специалистами, я слышал от них именно такое мнение.

Романтизация необученного программиста ПК - это как романтизация ковбоев на Диком Западе. Ну, были такие крутые парни, скакали по прериям - ну и что... Ну, крутые, молодцы, всё своим умом... Ситуация такая была, все в программисты дунули.

Что Вы знаете о моей практике?

Цитата:

Взять глыбу мрамора и отсечь от нее все лишнее. Огюст Роден

К вопросу о стиле программирования - "Скульптор".

Уважаемый Геннадий Николаевич.

Было бы интересно увидеть не пример-"слепыш", а конкретный алгоритм такого вида.

Ручаюсь, что одно из двух:
1) Если это будет вычислительных алгоритм, то можно будет предложить (= аккуратно формально вывести) красивый и понятный вариант без break и continue (последовательность условий в начале цикла с отдельными выходами вниз я не считаю за break).
2) Если это будет цикл типа обработки каких-то событий (в графическом интерфейсе и т.п.), то его надо будет почикать на ветки и переключения по адресу.

Прошу прощения. Невнимателен.

Та схема, которую Вы предложили, вообще не имеет отношения ни к break, ни к continue.
У Вас же действие одно - и оно глубоко внутри. Вы из него не выпрыгиваете.

У Вас получается самый обычный



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

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

Вот именно. Я к ней, например, присоединяюсь полностью.

Это у Вас корпоративный, вузовский подход.

Тема имеет продолжение от 22.01.2010 в закрытом для посетителей разделе "Список форумов » Разное » Отвлеченные темы » Опять двадцать пять" в теме "Стиль "Скульптор" и "Снова о методах".
Смотрите http://forum.oberoncore.ru/viewtopic.php?p=40791#p40791.

Поскольку уважаемый Пётр Алмазов опять поднял эту тему (viewtopic.php?f=62&t=2353&start=0), глянул ещё раз на его текстовые варианты (которые глубоко не копал прошлый раз по причине совершенной непрозрачности).

Нашёл циклы, "границы которых скрыл ДРАКОН".
Оказывается, в этих "прояснённых" циклах Петру пришлось употребить булевы переменные, которые стоят в условии и которым внутри в нужных местах присваивается значение.

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

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

Да на Драконе рисуйте, не заморачивайтесь.

Если и есть какая-то аналогия, то очень далекая. Я разделяю исходные принципы, сформулированные Геннадием Тышовым, но лепим с ним мы разные вещи.

Пару слов о дискуссии на этой ветке Форума.

Здесь Дракон выигрывает за явным преимуществом. Исходная программа Ильи Ермакова добротна и смотрится органично. Тогда как программа, изнасилованная структурным программированием, -- версия Петра Алмазова -- безобразна. И это вроде бы всем понятно, кроме Петра, который всем хамит с идиотской уверенностью в своей правоте, характерной для некоторых глубоко верующих в структурное программирование.

Чтобы поединок Дракона был честным, необходимо зеркально переписать программу Ильи Ермакова на Фортран или другой специальный язык для автоматного программирования. Языки Си и Паскаль здесь не годятся; на этом поле Дракон будет переигрывать.