DRAKON.SU

Текущее время: Пятница, 25 Май, 2018 06:22

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 09:45 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 77
Откуда: Астрахань
Илья Ермаков писал(а):
Peter Almazov писал(а):
4. В псевдокоде, если есть цикл, так это цикл, у него есть границы, видна охрана, можно сформулировать инвариант и постусловие, наконец, его можно выделить как отдельную процедуру. В отличие от идиотского нагромождения гробиков со стрелками и фирменного изобретения "цикл со многими выходами"

Зато Вы теряете понятие "состояние". Вообще, я просто делаю вывод, что Вы не понимаете (в смысле, не чувствуете, не имеете опыта постоянного применения) формализма конечных автоматов.

Категорически поддерживаю.Люой конечный автомат сначала гораздо лучше НАРИСОВАТЬ (в виде графа) с явным выделением состояний. А уж реализаций этого автомата можно напридумывать дофига и больше. Кодт на РСДН написал статью, где один автомат реализовал 4 или 5 разными способами. Герб Саттер показал еще один.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 10:01 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3656
Откуда: Москва
Peter Almazov писал(а):
Наконец нашлось время, попробовал. Никаких трудностей ... не обнаружил....
Резюме по Дракону. Это поделка от недоучки в программировании и для недоучек. Причем она эффективно закрепляет их на этом уровне.


Уважаемый Peter Almazov!

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 12:22 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Валерий Лаптев писал(а):
Категорически поддерживаю.Люой конечный автомат сначала гораздо лучше НАРИСОВАТЬ (в виде графа) с явным выделением состояний. А уж реализаций этого автомата можно напридумывать дофига и больше. Кодт на РСДН написал статью, где один автомат реализовал 4 или 5 разными способами. Герб Саттер показал еще один.
Уважаемый Валерий! Вы ломитесь в открытые двери. Я с Вами полностью согласен viewtopic.php?p=32054#p32054 и viewtopic.php?p=32035#p32035


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 13:08 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Владимир Паронджанов писал(а):
Если можно, дайте более развернутый и широкий анализ проведенного Вами сопоставления текста и Дракона на основе Вашего примера.

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

Большое спасибо за проведенный Вами анализ.
(Разумеется, с Вашими выводами я, к сожалению, не могу согласиться).
Так я его и дал в пунктах 3, 4 и 5.
Что касается выводов, то я не сказал ничего нового. Если говорить политкорректно, я считаю, что у программистов не использующих методику Дейкстры, более подробно разжеванную Грисом, есть большие резервы для профессионального роста. Надеюсь, я не одинок в этом мнении. Хотя я не могу говорить за других, вполне возможно, что уважаемый info21 с ним согласен.
Вы к моменту изобретения Дракона не были знакомы с работами Дейкстры, я не буду искать это сообщение, но я его видел. Это первая часть вывода.
Далее, Дракон позиционируется как инструмент для непрограммистов. Это вторая часть вывода. А из пункта 5 следует заключительное предложение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 14:48 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3656
Откуда: Москва
Уважаемый Peter Almazov!

Спаcибо за ответ.
К сожалению, в Ваш ответ вкралась нбольшая неточность.

Вы пишете:
Цитата:
Вы к моменту изобретения Дракона не были знакомы с работами Дейкстры, я не буду искать это сообщение, но я его видел.


Это не так. В моей книге "Как улучшить работу ума...(1998, 2001) подробно анализируется позиция Эдсгера Дейкстры (См. главу 16, стр. 248 и далее).

Для Вашего удобства я привожу эту цитату здесь:

Цитата:
ЧЕТЫРЕ ПРИНЦИПА СТРУКТУРИЗАЦИИ БЛОК-СХЕМ,
ПРЕДЛОЖЕННЫЕ Э. ДЕЙКСТРОЙ


Попытаемся еще раз заглянуть в темные переулки истории и внимательно
перечитаем классический труд Дейкстры “Заметки по структурному
программированию”.

К немалому удивлению, мы обнаружим, что основной тезис о структурных
управляющих конструкциях (для обозначения которых названный автор вводит термины “сочленение”, “выбор”, “повторение” [2]) излагается с прямой апелляцией
к визуальному языку блок-схем!

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

Эти принципы таковы.

          1. Принцип ограничения топологии блок-схем. Структурная программа
          должна приводить “к ограничению топологии блок-схем по сравнению с различными
          блок-схемами, которые могут быть получены, если разрешить проведение стрелок
          из любого блока в любой другой блок.
          Отказавшись от большого разнообразия блок-схем и ограничившись ...тремя типами
          операторов управления, мы следуем тем самым некоей последовательностной
          дисциплине” [2].

          2. Принцип вертикальной ориентации входов и выходов блок-схемы.
          Имея в виду шесть типовых блок-схем (if-do, if-then-else, case-of, while-do,
          repеat-until, а также “действие”),
          Дейкстра пишет: “Общее свойство всех этих блок-схем состоит в том,
          что у каждой из них один вход сверху и один выход снизу” [2].

          3. Принцип единой вертикали. Вход и выход каждой типовой блок-
          схемы должны лежать на одной вертикали.

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

Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов,
они однозначно вытекают из имеющихся в его работе иллюстраций [2].

Чтобы у читателя не осталось сомнений, мы приводим точные копии подлинных
рисунков Дейкстры (рис. 131, средняя и левая графа) .

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

Однако этих близнецов ожидала разная судьба — судьба принца и нищего.


Как видно из рис. 131, предложенная Дейкстрой форма иконы “вопрос” (?) и конструкции “переключатель” (case), а также топология соединительных линий
при переходе к языку ДРАКОН подверглись модернизации и эргономическим
улучшениям.

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

Чтобы устранить эти погрешности, в язык ДРАКОН внесены необходимые
уточнения.

Например, в блок-схеме конструкции repeat-until Дейкстра использует пять
изломов и одну наклонную линию; в дракон-схеме всего два излома,
а наклонных отрезков нет вовсе — см. нижний ряд на рис. 131.

Рис. 131. Структурные блок-схемы Дейкстры
и эквивалентные им визуальные операторы языка ДРАКОН
Вложение:
.png
.png [ 43.43 КБ | Просмотров: 8244 ]

Продолжение следует


Последний раз редактировалось Владимир Паронджанов Пятница, 25 Сентябрь, 2009 20:39, всего редактировалось 10 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 14:53 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3656
Откуда: Москва
Продолжение следует

Цитата:
ПОЧЕМУ НАУЧНОЕ СООБЩЕСТВО НЕ ПРИНЯЛО
ВИДЕОСТРУКТУРНУЮ КОНЦЕПЦИЮ Э. ДЕЙКСТРЫ?


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

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

Неприятность в том, что изложенные выше рекомендации Дейкстры не были приняты
во внимание разработчиками национальных и международных стандартов на блок-
схемы (ГОСТ 19.701–90, стандарт ISO 5807–85 и т. д.).

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

В чем причина этой более чем странной ситуации?

Здесь уместно сделать отступление.

Американский историк и философ Томас Кун в книге “Структура научных
революций” говорит о том, что в истории науки время от времени появляются
особые периоды, когда выдвигаются “несоизмеримые” с прежними взглядами
научные идеи.

Последние он, следуя Р. Бергману, называет парадигмами.

История науки — история смены парадигм.

Разные парадигмы — это разные образцы мышления ученых.

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

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

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

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

Начнем по порядку.

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

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

Однако в 1972 г., в момент публикации работы Дейкстры [2], визуальное
программирование как термин, понятие и концепция фактически еще не
существовало.

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

Так родилась приписываемая Дейкстре и по праву принадлежащая ему концепция
текстового структурного программирования.

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

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

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

ПАРАДОКС СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

Мы подошли к наиболее интригующему пункту в истории структурного
программирования.

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

В литературе по этому вопросу наблюдается редкое единодушие: да, они
несовместимы.

Вот несколько отзывов.

Блок-схемы “не согласуются со структурным программированием, поскольку
в значительной степени ориентированы на использование goto” [4].

Они “затемняют особенности программ, созданных по правилам структурного
программирования” [9].

“C появлением языков, отвечающих принципам структурного программирования,...
блок-схемы стали отмирать” [10].

Парадокс в том, что приведенные высказывания основываются на недоразумении.
Чтобы логический дефект стал очевидным, сопоставим две цитаты по методу “очной
ставки” (табл. 5).

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

И наоборот, соблюдение указанного принципа сразу же ликвидирует недостаток.

Таблица 5
_____________________________________________________

МНЕНИЕ КРИТИКОВ,
УБЕЖДЕННЫХ В НЕВОЗМОЖНОСТИ
СТРУКТУРИЗАЦИИ БЛОК-СХЕМ


«Основной недостаток блок-схем заключается в том, что они не приучают к аккуратности при разработке алгоритма: ромб можно поставить в любом месте блок-схемы, а от него повести выходы на какие угодно участки. Так можно быстро превратить программу в запутанный
лабиринт, разобраться в котором через некоторое время не сможет даже сам ее автор» [10]

ПРЕДЛОЖЕНИЕ Э. ДЕЙКСТРЫ
О СТРУКТУРИЗАЦИИ БЛОК-СХЕМ


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

Отказавшись от большого разнообразия блок-схем и ограничившись... тремя операторами управления, мы следуем тем самым некоей последовательностной дисциплине» [2]
_____________________________________________________

ПЛОХИЕ БЛОК-СХЕМЫ
ИЛИ ПЛОХИЕ СТАНДАРТЫ?


Проведенный анализ позволяет сделать несколько важных замечаний.

• Обвинения, выдвигаемые противниками блок-схем, неправомерны,
потому что ставят проблему с ног на голову.
Дело не в том, что блок-схемы по своей природе противоречат принципам
структуризации, а в том, что при разработке стандартов на блок-схемы указанные
принципы не были учтены.
На них просто не обратили внимания, поскольку в ту пору — именно в силу парадигмальной “слепоты” — считалось, что на практике структурное програм-
мирование следует применять к текстам программ, а отнюдь не к блок-схемам.

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

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

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

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

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

• Современные стандарты на блок-схемы (международный стандарт
ISO 5807–85, отечественный ГОСТ 19.701–90 и другие национальные стандарты,
в том числе американский стандарт ANSI), а также инструкции по их применению
следует признать устаревшими, так как они игнорируют принципы структуризации,
формализации и эргономизации и объективно содействуют снижению качества
соответствующей интеллектуальной продукции…

ПОЧЕМУ САМОЛЕТ НЕ МАШЕТ КРЫЛЬЯМИ?

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

Поэтому видеоструктурное программирование нельзя рассмат¬ривать как результат механического перевода устоявшихся понятий классического структурного
программирования на новый язык.

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

Это значит, что столь тщательно обоснованная Дейкстрой коллекция ключевых слов
структурного кодирования (if, then, else, case, of, while, do, repeat, until, begin, end [2])
при переходе к визуальному программированию становится ненужной —
для программиста она просто перестает существовать!

В равной степени становятся лишними и отмирают и другие ключевые слова,
используемые оппонентами Дейкстры в различных вариантах расширения
структурного кодирования: goto, continue, break, exit и т. д.

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

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

Например, две видеопрограммы на рис. 27 можно построить с помощью понятий
if-then-else и goto.

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

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

Что касается собственно видеопрограмм, то они, будучи “выполнимой графикой”,
строятся из “выполняемых” икон и “выполняемых” соединительных линий.

Причем — подчеркнем еще раз — в процессе построения (которое реализуется
с помощью ДРАКОН-редак¬тора) пользователь не применяет понятия if-then-else
и goto, ибо в этом нет никакой необходимости.

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

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

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

Очевидно, что использование понятий, выражаемых ключевыми словами классического структурного программирования, не является самоцелью, а служит лишь для того,
чтобы “делать наши программы разумными, понятными и разумно управляемыми” [22].

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

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

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

Поэтому высказываемое иногда критическое замечание: “недостаток шампур-метода
в том, что он не удовлетворяет требованиям структурного программирования” является
логически неправомерным.

Нельзя упрекать самолет за то, что он не машет крыльями.

ВЫВОДЫ

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

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

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

4. В отличие от текстового структурного программирования шампур-метод является полностью формальным.

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

6. Широко распространенное мнение о несовместимости блок-схем и структурного программирования является мифом, нелепой ошибкой, основанной на невнимательном прочтении классической работы Э. Дейкстры “Заметки по структурному программированию”.

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

8. Существующая литература по блок-схемам, включая международные и национальные стандарты, на 99% устарела.

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

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


Последний раз редактировалось Владимир Паронджанов Пятница, 25 Сентябрь, 2009 15:22, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 15:19 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Не пойдет.
Я, видимо, сам виноват, что не указал, о какой работе Дейкстры идет речь. Но те, кто в теме, по упоминанию Гриса сразу понимают, что речь идет о книге Э. Дейкстра. ДИСЦИПЛИНА ПРОГРАММИРОВАНИЯ. М.:МИР, 1976,1978.

О книге Гриса А.П.Ершов сказал так: "Если считать переломную книгу Э. Дейкстры интеллекинтеллектуальным откровением, то книга Д. Гриса — это апостольское деяние, направленное на то, чтобы превратить учение одиночки в мировую религию."
Д. Грис. Наука программирования. М.:Мир,1984.

А книга "Структурное программирование" и ранние споры про блок-схемы и GOTO – это просто беллетристика.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2009 17:51 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Лирическое отступление к вопросу о формальных методах.

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

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

А Вы, как мне кажется, с упорством чистого математика "сушите" Дейкстру до раз и навсегда зафиксированного арсенала "делай так".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 00:05 

Зарегистрирован: Среда, 27 Май, 2009 01:41
Сообщения: 33
Объясните неграмотному (желательно от автора ветки) в чем "сакральный" смысл конструкции типа
Процедура ЧтоТо()
Если Условие=Истина Тогда
тут много
много
много
много
строчек
кода на кучу
экранов вниз
Иначе
а тут совсем ничего строк, мизер
КонецЕсли
Конецпроцедуры Чтото
...????
по роду деятельности приходится программит много учетных алгоритмов
где такие условные ветки - лчень длмнные и вложенные...
.
почему не транфсофрмировать такую лестницу условий в более линейную последовательность:
.
Процедура
Если Условие=Ложь Тогда
а тут совсем ничего строк, мизер
Возврат;
КонецЕсли;

//сюда попали если выполнилось условие какое-то
тут много
много
много
много
строчек
кода на кучу
экранов вниз

КонецПроцедуры

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 03:17 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Tomba писал(а):
Объясните неграмотному (желательно от автора ветки) в чем "сакральный" смысл конструкции типа
...
с таким подходам зачастую многоэтажные разветвленные если превращаются в практически линейный код. Почему такая нотация не используется?

Не автор ветки, но могу сказать:
Такой стиль программирования можно назвать стиль - СКУЛЬПТОР, т.е. отсекаем все лишнее и производим отделку, обработку оставшегося материала.

Используем: "Возврат" (RETURN) для выхода из процедуры; "Прервать" (Break, EXIT) для выхода из цикла; "Продолжить" (Continue) для перехода на конец цикла, т.к. нет смысла и необходимости оставаться в процедуре или цикле. При этом сама обработка оставшегося материала выводится из вложености.
Проверка условий для выхода (перехода в конец цикла) и выход (перехода в конец цикла) производится раздельно по каждому критерию. При этом нет необходимости создавать сложные логические выражения, логика программы становится локальной, четкой, не размазанной.
Для локальности, переносим логику вызова процедуры в саму процедуру.

Мой пример здесь.

Ограничиваем использование академической идеи структурного программирования в пользу практичности, по В.Д. Паронджанову исключаем проявление интеллектуального терроризма, уходим от ортодоксальной позиции.
На форуме можно наблюдать переход к практичности: у И. Ермакова - принятие русских идентификаторов в прикладном программировании, у Ф. Ткачёва - замена учащимся в КП ключевых слов русскими.
Также примером практичности в прикладном программировании являются языки семейства 1С:Предприятие.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 08:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Предположим, что мы запретим RETURN из середины процедуры. Тогда Вы начнёте жаловаться, что "тут много-много, а там ниже далеко ELSE". А потом ещё чуть-чуть подумаете - и поймёте, что это "много-много" надо поделить на пяток отдельных процедур. :)
Т.е. данная проблема - надуманная, при принятии за правило, что одна процедура не должна быть длиннее 10-15 строк, в среднем.

А разреши RETURNы - так хочется и под 50 навалять, не правда ли? :)

"Разделяй и властвуй". И стройте сверху вниз, используя имена ещё неописанных процедур, а потом их определяя.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 09:46 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Tomba писал(а):
Объясните неграмотному (желательно от автора ветки) в чем "сакральный" смысл конструкции типа ...
Уважаемый Tomba!

Во-первых, писать внутри любой скобочной конструкции "много много много строчек кода на кучу экранов вниз", по моему мнению, не надо никогда. Это можно прочесть в любой книге по стилю программирования или по рефакторингу.
Я тоже видел подобный код, например, в программе 1С Зарплата и Кадры 7.7 был кусок:
Код:
начало цикла
   5 тысяч строк кода (это не шутка!)
конец цикла
Здесь, видимо, требуется медикаментозное лечение, как минимум.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 09:51 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Геннадий Тышов писал(а):
Мой пример здесь.
Уважаемый Геннадий!
Ваш пример я видел, и даже задал по нему уточняющий вопрос. Пример не произвел на меня впечатления. Видно, что Вы используете только один инструмент в программировании – здравый смысл. С помощью него можно добиться в программировании впечатляющих результатов. Ваш редактор для Дракон – наглядный пример (на полном серьезе). Не сомневаюсь, что есть еще.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 11:19 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Геннадий Тышов писал(а):
Ограничиваем использование академической идеи структурного программирования в пользу практичности, по В.Д. Паронджанову исключаем проявление интеллектуального терроризма, уходим от ортодоксальной позиции.
На форуме можно наблюдать переход к практичности: ... принятие русских идентификаторов в прикладном программировании, ... замена учащимся в КП ключевых слов русскими. ...

Протестую.

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

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

Позаниматься НЛП можно и в противоположном направлении -- употребляя понятие "рукосуйство" и связывая его с "неакадемичностью".

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

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

Пока отказ от структурированности в ДРАКОНе не будет обоснован так же тщательно, как структурное программирование по Дейкстре и др., этот отказ будет проходить по разряду рукосуйства.

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

Но пока вопрос открыт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 17:45 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Геннадий Тышов писал(а):
Такой стиль программирования можно назвать стиль - СКУЛЬПТОР, т.е. отсекаем все лишнее и производим отделку, обработку оставшегося материала.

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


Такой стиль хорошо известен в дидактике начальной школы :)

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

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

ИТ как отрасль как раз на стадии той самой ранней начальной школы. Заставить, наконец, выучить уравнения может, видимо, только введение юридической ответственности за ошибки в программах, которое в Европе уже планируется. Работодатель вряд ли захочет отвечать за ошибки в программе, которая написана "методом скульптора" - и нужно верить на слово этому гениальному скульптору; т.к. его творения не поддаются проверке никаким "сопроматом".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 18:35 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Странные возникают видения при знакомстве со стилем скульптор (использование предусловий) у:
Info21 писал(а):
... попытки "нейролингвистического программирования" -- попытки внедрить в подсознание ...
... употребляя понятие "рукосуйство" и связывая его с "неакадемичностью".

Илья Ермаков писал(а):
Такой стиль хорошо известен в дидактике начальной школы
....
Работодатель вряд ли захочет отвечать за ошибки в программе,...

Ведь я дал ответ на вопрос Tomba, и в нем все аргументировано.

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


Последний раз редактировалось ==== Воскресенье, 27 Сентябрь, 2009 18:48, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 18:46 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
В аргументации такого рода предлагается полагаться не на строгие инженерные методы, позволяющие проектировать и гарантировать свойства конструкции, а на какие-то... просто слова... Слов можно наговорить много. Но они ничего не гарантируют. Кроме того, что все должны поверить автору конструкции, что он мастер и всё продумал. Либо сидеть и проверять по строчкам, изображая из себя компьютер. Всё это, кстати, нарушает принцип паронджановской когнитивной эргономики. Отказ представлять продукт в такой форме, в которой правильность его будет легко удостоверяема.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 18:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Эта идея меня, кстати, вообще шокировала:

Цитата:
Для локальности, переносим логику вызова процедуры в саму процедуру.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 18:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
У меня вообще впечатление, что Вы не читали "Дисциплину программирования" (http://europrog.ru/book/dped1978r.djvu), т.к. не понимаете, об чём идёт речь (не возражаете с пониманием, а "проглатываете" - и повторяете то же самое).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 27 Сентябрь, 2009 18:55 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Я дополнил свое сообщение.
Об отказе что то предоставить, не было речи.
Был ответ на конкретный вопрос Tomba.
Жизнь такая многообразная в своем проявлении, и вряд ли, кто имеет право сократить многообразие.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB