DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 01:36

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




Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 23 Июль, 2007 20:09 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Прочитайте все-таки обсуждаемый текст, info21. А потом уже говорите является ли данное обсуждение оффтопиком.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Июль, 2007 20:40 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 56
Откуда: Узбекистан, Чирчик
info21 писал(а):
неандертальцев, которые, по текущей гипотезе [мне неизвестно, на чем основанной], не обладали развитым языком коммуникации.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Июль, 2007 20:54 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 33
Иван А. Кузьмицкий писал(а):
У меня под рукой монография профессора кафедры русского языка Самарского государственного университета, д.ф.н Людмилы Борисовны Карпенко «Священная азбука Кирилла».

В частности, в этом тексте есть такие мысли:

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

Какие образы?

Вы сначала задайтесь вопросом, почему "испокон веков" (ну, скажем с 988 года от Р.Х.) в насквозь (как нам всегда говорили) ХРИСТИАНСКОЙ, Православной Руси не было НИ ОДНОГО храма, посвящённого Христу? Про Храм Христа-Спасителя в Москве – чур – молчок, то, по историческим понятиям, - «новодел». Причём, - из той же «общественно-политической оперы», что и его восстановленная копия...
И почему за предыдущие 74 года до Октября в России церквей было разрушено чуть ли не в два раза больше, чем за годы Советской Власти?
Иван А. Кузьмицкий писал(а):
"Важнейшая задача, которую должен был решить Константин-Кирилл Философ, отправляясь в славянские земли, — задача создания литургии на славянском языке. Поэтому, разрабатывая буквы для славянского алфавита, первоапостол решал и задачу закрепления системы солнечно-лунного календаря, который обеспечивает вычисление новолуний и определения священных праздников. Модель глаголического вселенского круга как раз и служит доказательством соединения идеи первой славянской азбуки с идеей календаря".

Вы подходите к данным вопросам (азбука и астрономические счисления), имея в виду априорным традиционные, принятые западной церковью и светскими учреждениями, хронологией, «ходом исторических событий» и их интерпретацией...
Для начала дискуссии по тематике алфавитов (не только славянского), я не уверен, что выполняются условия:
1) нам здесь уместно этим заниматься,
2) нам здесь хватит для этого места, :о)
3) вами не будет с ходу отвергнуты мои аргументы, потому, что они не согласуются с «записанными на подкорке» трактовками «исторических фактов» и хронологии у 99,(9)% населения.

Давайте лучше - "про реактор и любимый лунный трактор" - про обероны... :о)))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Июль, 2007 21:38 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
Wlad писал(а):
Иван А. Кузьмицкий писал(а):
У меня под рукой монография профессора кафедры русского языка Самарского государственного университета, д.ф.н Людмилы Борисовны Карпенко «Священная азбука Кирилла».

В частности, в этом тексте есть такие мысли:

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

Какие образы?

Вы сначала задайтесь вопросом, почему "испокон веков" (ну, скажем с 988 года от Р.Х.) в насквозь (как нам всегда говорили) ХРИСТИАНСКОЙ, Православной Руси не было НИ ОДНОГО храма, посвящённого Христу? Про Храм Христа-Спасителя в Москве – чур – молчок, то, по историческим понятиям, - «новодел». Причём, - из той же «общественно-политической оперы», что и его восстановленная копия...
И почему за предыдущие 74 года до Октября в России церквей было разрушено чуть ли не в два раза больше, чем за годы Советской Власти?


А причём тут, извините, глаголица?

Цитата:
Иван А. Кузьмицкий писал(а):
"Важнейшая задача, которую должен был решить Константин-Кирилл Философ, отправляясь в славянские земли, — задача создания литургии на славянском языке. Поэтому, разрабатывая буквы для славянского алфавита, первоапостол решал и задачу закрепления системы солнечно-лунного календаря, который обеспечивает вычисление новолуний и определения священных праздников. Модель глаголического вселенского круга как раз и служит доказательством соединения идеи первой славянской азбуки с идеей календаря".

Вы подходите к данным вопросам (азбука и астрономические счисления), имея в виду априорным традиционные, принятые западной церковью и светскими учреждениями, хронологией, «ходом исторических событий» и их интерпретацией...
Для начала дискуссии по тематике алфавитов (не только славянского), я не уверен, что выполняются условия:
1) нам здесь уместно этим заниматься,
2) нам здесь хватит для этого места, :о)
3) вами не будет с ходу отвергнуты мои аргументы, потому, что они не согласуются с «записанными на подкорке» трактовками «исторических фактов» и хронологии у 99,(9)% населения.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Июль, 2007 23:14 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
GUEST писал(а):
Прочитайте все-таки обсуждаемый текст, info21. А потом уже говорите является ли данное обсуждение оффтопиком.


Да, сначала я невнимательно просмотрел. Офтопу чересчур.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Июль, 2007 09:22 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
Просматриваю книгу "Как улучшить работу ума", и наткнулся на фразу:
Цитата:
замена текста эквивалентным ему чертежом (например, переход от текстового программирования к визуальному) обеспечивает более высокую продуктивность мозга за счет “симуль­танизации”, т. е. увеличения скорости работы мозга при переходе от медленного сукцессивного восприятия текста к быстрому си­мультанному восприятию чертежа.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Июль, 2007 09:49 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Июль, 2007 12:55 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
Илья Ермаков писал(а):
...Основной упор у П не на лёгкость написания в графике, а на читабельность кода управляющих систем, с возможностью быстрой проверки разными людьми. Т.е. всё та же верная мысль - большая часть времени проводится за чтением кода...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Июль, 2007 16:25 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 24 Февраль, 2008 16:53 

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

Благодарю Вас за то, что Вы обратили внимание на язык Дракон, описанный в моей книге «Как улучшить работу ума. Алгоритмы без программистов – это очень просто!». М.: Дело, 2001.

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

Владимир Паронджанов

Нижеследующий текст построен по следующему плану.
Часть 1. Сначала я приведу фрагмент дискуссии на сайте Натахаус.
Натахаус — это познавательный сайт. Поэтому мои ответы на критику носят не строго научный, а упрощенный, научно-популярный характер.
Часть 2. Затем я отвечу по возможности строго на Ваши высокопрофессиональные критические замечания.

Часть 1. Фрагмент дискуссии на сайте Натахаус
(комментарии 4, 6, 7—9, 11—15)
http://www.infanata.org/2007/11/04/kak-uluchshit-rabotu-uma.-algoritmy-bez.html

Комментарий 4 (Fregatte 06/11/2007)

«Скачал, попытался прочесть и понять... Обычные блок-схемы названы супер-новым языком программирования. Понятно, что блок-схему можно составить красивыми ровными рядами, а можно все запутать в клубок... Но от этого блок схема не становится языком программирования»

Комментарий 6 (Ответ Паронджанова 09/02/2008)

Не могу согласиться с уважаемым автором этого комментария по следующим причинам.
    • Автор комментария безусловно прав, когда говорит, что «блок-схему можно составить красивыми ровными рядами… Но от этого блок схема не становится языком программирования». Но суть моего предложения не только в том, чтобы сделать блок-схему красивой и легкой для понимания. А прежде всего в том, чтобы превратить блок-схему из запутанного клубка, лишенного строгой математической основы, в математически строгий объект, способный превратиться в компьютерную программу. Это доказано в главах 14—17 книги, до которых уважаемый автор комментария, видимо, не добрался.
    • Говоря кратко, логико-математическая суть дела состоит в том, что графический синтаксис языка ДРАКОН (в отличие от обычных блок-схем) представляет собой графическое логическое исчисление, которое я назвал «исчислением икон». Доказательство этого факта и построение исчисления икон описано в главе 17 книги.

Язык ДРАКОН разработан совместными усилиями Федерального космического агентства (Научно-производственный центр автоматики и приборостроения им. академика Н.А. Пилюгина, г. Москва) и Российской академии наук (Институт прикладной математики им. академика М.В. Келдыша, г. Москва).

Язык ДРАКОН возник как обобщение опыта работ по созданию космического корабля «Буран». Разработка нового языка и системы программирования началась в 1986 и завершилась через 12 лет. В 1997 году на базе ДРАКОНА построена автоматизированная технология проектирования алгоритмов и программ (CASE-технология) под названием «ГРАФИТ-ФЛОКС». Она успешно используется в ряде крупных космических проектов (ракет-носителей и разгонных блоков): «Морской старт», «Фрегат», «Протон-М», ДМ-03, ДМ-SL-Б («Старт в пустыне»), Ангара и др.

Дракон — очень легкий язык. Чтобы убедиться в этом, можно прочитать мою книгу, предназначенную для школьников 5—9 классов «Занимательная информатика. М.: Дрофа, 2007».

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

Комментарий 7 (Al_Mel 10/02/2008)

"Насчет блок-схем. Честно говоря, никогда не понимала, зачем они нужны. Сама никогда их не использовала и вообще никогда не видела ни одного программиста, который бы перед тем, как писать программу, рисовал бы эти самые блок-схемы. Преподаватель, с которым мы спорили по поводу нужности блок-схем, так и не сумел мне вразумительно объяснить это. Может, Вы объясните?"

Комментарий 8 (Ответ Паронджанова 11/02/2008)

Первобытный человек по имени "Старый Чип" привык работать каменным топором. А к нему приходят какие-то чудаки и говорят: "Вот тебе железный топор. Он намного лучше".

Но Старый Чип не понял новых веяний. Он подумал, что ему предлагают работать не одним топором (каменным), а двумя (каменным и железным). И ответил: "Мне неудобно возиться с двумя топорами". Он выбросил железный подарок в реку. И, как и в доброе старое время, продолжал свое дело, пользуясь каменным топором.

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

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

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

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

Вы спросите: чем же они отличаются?
Назову два отличия:
1) Старая блок-схема - это всего лишь жалкий рисунок; это не программа, которую можно ввести в компьютер и исполнить. А дракон-схема - это именно программа, которую можно транслировать в объектный код и получать загрузочные модули.
2) Дракон схема удовлетворяет критерию сверхвысокой понимаемости (понятности). Она позволяет покончить с дурной привычкой программистов писать программы, которые они сами не в состоянии понять через несколько месяцев.

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

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

Владимир Паронджанов

Комментарий 9 (Dvuugl 14/02/2008)

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

Комментарий 11 (Ответ Паронджанова 16/02/2008)

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

Комментарий 9 продолжение (Dvuugl 14/02/2008)

«Но. Как язык (в смысле инструмент!) программирования он НА ДЕЛЕ не существует. Здесь автор хватил через край. Потому что никто не может скачать его в сети, нарисовать схему, скомпилировать, получить exe-файл, запустить и узреть "Hello world!" Нет этого. Нет — и всё тут. Для C есть, для Паскаля есть... а для Дракона нет. То что "в принципе возможно"— это не язык программирования, не инструмент. Мало ли что "в принципе возможно". "В принципе" на хлеб не намажешь».

Комментарий 11 продолжение (Ответ Паронджанова 16/02/2008)

Благодарю за критику, но, к сожалению, не могу с Вами согласиться на 100%.
Потому что человек, прочитавший Ваши слова, может подумать, что Дракон не имеет практической реализации и НИГДЕ не используется в качестве языка программирования. Но это не так.
Начиная с 1997 года, Дракон используется как язык программирования во многих космических проектах, а именно: Морской старт, Фрегат, Протон-М, ДМ-03, ДМ-SL-Б (Старт в пустыне), Ангара и др.
Разработчики алгоритмов и программ для перечисленных ракет-носителей и ракетных разгонных блоков выполняют все описанные Вами операции: рисуют схемы с помощью дракон-редактора, компилируют, получают загрузочные модули и т.д.

Правда, они не видят надпись "Hello, world!". Потому что дракон-программы исполняются не на РС, а на бортовых и наземных компьютерах под названием "Бисер", используемых в системе управления ракет и разработанных в нашем институте (Научно-производственный центр автоматики и приборостроения им. академика Н.А. Пилюгина).

Если Вы сомневаетесь в этом, я приглашаю Вас в наш научный центр. Я покажу Вам всю технологическую цепочку разработки алгоритмов и программ на языке Дракон. (Эта технология, точнее CASE-технология, носит название ГРАФИТ-ФЛОКС). Если у Вас действительно есть такое желание, напишите мне по адресу vdp2007@bk.ru И мы договоримся об удобной для Вас дате визита.

Так что язык программирования Дракон существует не "в принципе", а НА ДЕЛЕ, но только в ракетном огороде. Его вполне можно намазать на ракетный хлеб. Дракон — это рабочий инструмент. Он широко используется при создании системы управления ракет и приносит большую пользу.
Но Вы, разумеется, полностью правы, когда говорите, что наша система программирования (СASE-система ГРАФИТ-ФЛОКС) недоступна никому в сети Интернет.
Почему недоступна? Я готов рассказать, но думаю, что это Вам вряд ли интересно.
С уважением Владимир Паронджанов

Комментарий 12 (Al_Mel 16/02/2008)

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

Комментарий 13 (Ответ Паронджанова 16/02/2008)

1.Ваш вопрос, безусловно, имеет право на жизнь. Но он поставлен несвоевременно.

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

3.Но! Конкретная реализация Дракона в ракетной технике полезна только для ракет. Ее невозможно перенести в другие области.

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

5. Для других целей надо указать другие правила заполнения слепыша текстом. Если взять эти правила из языка СИ, получим язык Дракон-СИ (см. стр. 178, 179 книги). Если взять правила из языка Паскаль, получим Дракон-Паскаль и т.д.

6.Моя книга — это обращение к творческим умам, призыв к энтузиастам. Ребята! Если вам нравится идея Дракона, создайте на его основе хороший язык.

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

8.Al_Mel! Теперь я отвечу на Ваш вопрос. Язык программирования Дракон сегодня изучить нельзя. Потому что для всех случаев, кроме ракетной техники, он не существует в природе. Сначала его нужно создать.

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

11.А что делать сейчас, пока первопроходцы не закончили свой труд и не предъявили восхищенному миру свои замечательные результаты? Ответ прост: уже сейчас любой желающий может заполнять клеточки дракон-схем надписями на естественном языке. То есть использовать его не как язык программирования, а как алгоритмический язык - для разработки и удобного описания алгоритмов. Многие именно так и поступают.

Комментарий 14 (Al_Mel 17/02/2008)

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

Комментарий 15 (Ответ Паронджанова 20/02/2008)

Да, Вы поняли меня правильно. Но, если позволите, я хотел бы добавить несколько пояснений.

1. Мы привыкли к тому, что язык должен иметь синтаксис (подразумевается ОДИН синтаксис). Но Дракон - графический язык. Поэтому он имеет не один, а ДВА синтаксиса: графический синтаксис и текстовый синтаксис. На универсальность претендует ТОЛЬКО графический синтаксис. Именно он подробно и строго описан в моей книге. Именно графический синтаксис претендует на "мировое господство". А текстовый синтаксис никаких претензий не имеет. Более того, он даже не рассматривается. Каждый (кому нравится идея Дракона) может придумать такой текстовый синтаксис, какой ему нужен.

2. Разделение синтаксиса на две части (графический синтаксис и текстовый синтаксис) - это фундаментальная для Дракона идея.

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

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

5. Пункт 4 не следует понимать слишком узко. Зададим вопрос: может ли Дракон конкурировать с объектно ориентированными и визуальными языками, например С++, Дельфи, Visual Basic? Этот вопрос неправильно поставлен. Дело вот в чем. В объектно ориентированных и визуальных языках есть процедурная часть. На мой взгляд, реализация процедурной части этих языков далека от совершенства. А если отбросить деликатность, не выдерживает критики. Но ситуацию можно поправить. По моему мнению, эти языки следует частично доработать. А именно, заменить слабое звено этих языков (процедурную часть) на Дракон. Эту мысль впервые высказал Николай Сенюгин.

С уважением Владимир Паронджанов

(Конец 1-й части. Конец фрагмента дискуссии на сайте Натахаус)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Февраль, 2008 11:35 
Модератор
Аватара пользователя

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

Но... Вы обещали вторую часть :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Февраль, 2008 20:01 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 56
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
А в задачах с упором на структуры данных и их обработку отдачи от графики не будет никакой.
Как обычно, не могу с Вами согласиться... :lol:

Когда-то была очень популярна методология Джексона, которую в нескольких словах можно так описать: структура входных и выходных данных определяет структуру алгоритма обработки этих данных. Идея такая -- рисуете диаграммы, описывающие структуру данных (входных и выходных), затем сливаете их общие подструктуры и получаете алгоритм обработки (в виде диаграммы и реальной программы). Эти диаграммы по сути являются графическим представлением нотации БНФ.

Подробнее можно прочитать, например, в книге Дэвида Кинга "Создание эффективного программного обеспечения", ISBN 5-03-002005-5

Очень интересная методика визуального проектирования структур данных и алгоритмов. (Ничего общего с ДРАКОН'ом не имеет). К сожалению, мне что-то не попадаются инструменты поддержки этой методики... :о(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Февраль, 2008 21:23 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Февраль, 2008 21:35 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Владимир Паронджанов писал(а):
Они с жаром взялись за работу. А именно, заменить слабое звено этих языков (процедурную часть) на Дракон. Эту мысль впервые высказал Николай Сенюгин.

?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Февраль, 2008 22:20 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 56
Откуда: Узбекистан, Чирчик
GUEST писал(а):
Владимир Паронджанов писал(а):
Они с жаром взялись за работу. А именно, заменить слабое звено этих языков (процедурную часть) на Дракон. Эту мысль впервые высказал Николай Сенюгин.

?

Думаю, речь идёт вот об этом:
http://old.osp.ru/w2k/cgi-bin/forum.cgi ... ad&id=1808


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Февраль, 2008 19:10 

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

С глубоким уважением Владимир Паронджанов

Часть 2. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования “Дракон”, представленные на 1-й странице форума
Замечания обсуждаются в том порядке, в каком они появились на форуме.

Ярослав Романченко Четверг, 31 Май, 2007

Ради интереса поискал историю названия "Графит-Флокс". Оказывается - ракетное топливо "Графит-ФлОкс" - Графит+Фтор+Кислород

Ответ Паронджанова

Это неверно. ГРАФИТ расшифровывается так: ГРАФика И Текст.
ФЛОКС означает Формализованное Логическое Описание Крупных Систем.

Теперь по существу. Графит-Флокс — это технология (точнее CASE-технология) разработки алгоритмов и программ по методу «программирование без программистов». (Закавыченные слова нуждаются в оговорке, но для краткости я ее опускаю).

Графит — это графический процедурный язык реального времени, в котором есть особенность, а именно: в клеточках блок-схем Графита используются, так называемые флокс-идентификаторы (идентификаторы данных и объектов, написанные по специальным правилам). Но значение этих идентификаторов в языке Графит ПРЕДНАМЕРЕННО НЕ ОПРЕДЕЛЕНО.

А где оно определено? Значение флокс-идентификаторов задается с помощью специального языка — декларативного языка Флокс. Последний служит для описания данных, объектов и обязательных частично формализованных комментариев.

При этом используются два редактора:
    • графит-редактор (для формального графического описания алгоритмов);
    • флокс-редактор (для формального описания данных, объектов и обязательных формализованных комментариев).

Совокупность флокс-описаний вводится в реляционную базу данных ФЛОКС, которая затем преобразуется в реляционную базу объектов. База данных ФЛОКС обычно содержит около 3000 флокс-описаний (для разных ракет это число заметно варьирует). У каждой ракеты-носителя и у каждого разгонного блока свое наполнение базы данных ФЛОКС.

Заметьте: ГРАФИТ и ФЛОКС — это не два самостоятельных языка, а две половинки одного языка — языка ДРАКОН.
Удобство в том, что во многих случаях (хотя и не всегда) можно исправлять флокс-описания, не меняя графит-алгоритмы. И наоборот, вносить изменения в графит-алгоритмы, не трогая базу данных ФЛОКС.

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

Я ввел понятие «флокс-формуляр» и предложил ввести в систему конструкторской документации новый документ под таким же названием. Так и было сделано. Каждая лаборатория, разрабатывающая флокс-описания, выпускает свой флокс-формуляр, который имеет строго определенную форму, строго определенные разделы и прочую начинку. Совокупность флокс-формуляров описывает содержание базы данных ФЛОКС.

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

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

В сети встречается информация, что Графит-Флокс — это операционная система. Это неверно.
Конечно, у нас есть операционная система реального времени компьютера Бисер. Но она не имеет специального названия.

Илья Ермаков Четверг, 31 Май, 2007

Штука очень интересная. Предлагаемая нотация действительно сильная и понятная.
Однако все же хочется поспорить с автором - Паронджановым. Все то же избитое утверждение, что "графическое представление информации понимабельнее, поэтому выбирать надо именно его, а текстовое представление программ неизбежно отомрет". При этом аргументация такова, что панорамным видением ("симультанный режим") человек может воспринимать информацию на порядок быстрее, нежели концентрированным ("сукцессивный режим"). Вроде бы не поспоришь, но лично я вижу тут два НО:
1) Все эти рассуждения базируются на тезисе "при возможности эквивалентного графического представления". А это предположение верно только для относительно простых систем. В сложных системах структура многомерна, и эквивалентно отобразить ее в плоский чертеж просто невозможно. Текстовый язык отображает эту структуру за счет символических связей между сущностями, именных ссылок, так сказать. Это позволяет хоть как-то воспринимать структуру системы в том или ином разрезе, формируя в уме многомерную семантическую сеть. Отобразить же многомерные связи графически - да повеситься можно... Электронщики-то неспроста уже давно ушли на текстовую нотацию - понять спецификацию на Verilog/VHDL - или что там у них - как-то получается, но разобраться в сгенерированной по спецификации топологии - специалисты говорят, что это практически невозможно.
2) Панорамное внимание на то и панорамное, что работает "по верхам", формируя общую, примерную картинку. А часто наоборот требуется искусственное замедление восприятия, фокусировка, и текстовое представление это дает, а графическое будет наоборот рассеивать, "замыливать" взгляд.

Ответ Паронджанова

Уважаемый Илья!

Вы приписываете мне фразу «Графическое представление информации понимабельнее, поэтому выбирать надо именно его, а текстовое представление программ неизбежно отомрет».
По-моему, это неточная цитата. Мне кажется, я такого не говорил. Потому что без текста обойтись, разумеется, нельзя.

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

Далее Вы пишете: «Электронщики-то неспроста уже давно ушли на текстовую нотацию - понять спецификацию на Verilog/VHDL - или что там у них - как-то получается, но разобраться в сгенерированной по спецификации топологии - специалисты говорят, что это практически невозможно.

Уважаемый Илья! Большую часть своей жизни я проработал инженером — разработчиком вычислительных устройств. В период создания орбитального корабля «Буран» я был начальником лаборатории комплексной разработки вычислительной системы Бурана. Так что об этих делах знаю не понаслышке.

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

Но Ваше утверждение, что «Электронщики… уже давно ушли на текстовую нотацию» является в корне ошибочным. С равным успехом Вы могли бы сказать «Географы уже давно отказались от географических карт и принялись описывать их словами». «Конструкторы уже давно отказались от конструкторских чертежей» и т.д.
Смею Вас заверить: при разработке электрических (логических) схем, временных диаграмм (циклограмм) и других (важных для мыслительного процесса разработки) документов электронщики никогда не переходили на текстовую нотацию! И никогда не перейдут! Приведенный Вами пример справедлив, НО СОВЕРШЕННО НЕ ТИПИЧЕН.

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

В моей книге на стр. 52—53 Вы найдете цитату из Джеймса Мартина:

    В 1989 г. журнал “Форчун” попытался выяснить, почему так трудно писать программы: «Программное обеспечение — это “материя чистой мысли”, бестелесная и умозрительная; поэтому проектировщики не в состоянии нарисовать ясные, точные и подробные чертежи и схемы, как это делают разработчики электронных приборов, чтобы дать четкие указания программистам, что нужно сделать. Следовательно, повседневное общение между программистами, их начальниками и обычными людьми, которые используют программы, — это вещь в себе». Однако сторонники RAD думают по-другому. Комментируя указанную статью, Джеймс Мартин пишет: «Важно понять, что эта народная мудрость сегодня уже неверна». В рамках RAD применяются «точные и детальные чертежи и схемы (аналогичные тем, что рисуют конструкторы электронного оборудования) с помощью технологии I-CASE, причем из этих чертежей генерируется программный код. На уровне чертежей выполняется значительная часть проверок. Эти чертежи и схемы весьма эффективны при повседневном общении программистов, системных аналитиков, менеджеров и конечных пользователей. Попытка создавать программы без этих средств означает только одно — безответственное руководство» [16].

Откуда взята эта цитата? Из хорошо известной Вам книги «Martin J. Rapid Application Development. N.-Y.: Macmillan Publishing Co., 1991». Это руководство по методологии RAD (Rapid Application Development), в котором больше 800 страниц. Сегодня эта книга частично устарела, но мудрая мысль о том, что ПРОГРАММИСТАМ НУЖНО ВСЛЕД ЗА ИНЖЕНЕРАМИ НАУЧИТЬСЯ ДЕЛАТЬ ХОРОШИЕ ЧЕРТЕЖИ, на мой взгляд, полностью сохраняет силу.

Илья! В Вашем сообщении есть и другие пункты, с которыми я не могу согласиться. Но мой ответ и так чрезмерно затянулся. Если хотите, можно подробно обсудить все интересующие Вас детали по телефону или при личной встрече. Будете в Москве — заходите в гости. Я живу в Новых Черемушках. Мой телефон 331-50-72. Звоните, я буду рад.

Илья Ермаков Среда, 18 Июль, 2007 23:42

«…исходной идеей для Дракона послужили работы Дейкстры, который выработал концепцию структурного программирования…»

Ответ Паронджанова

Уважаемый Илья!
Мой комментарий будет не совсем обычным. На это есть две причины.
    Причина 1. Знаю, что Вы интересуетесь работами Дейкстры. Видел Вашу подборку его статей на этом сайте.
    http://oberoncore.ru/index.php?Itemid=2 ... &task=view
    Поэтому мне хочется считать Вас экспертом по Дейкстре. И обсудить с Вами кое-какие бредовые идеи.
    Причина 2. Читая Ваши сообщения на этом и других сайтах, я обратил внимание, что Вы, во-первых, делаете акцент на эргономичности языка Дракон (хотя и с оговорками) и, во-вторых, отмечаете, что графический синтаксис этого языка является строгим формализмом. Но в чем математическая суть этого формализма? Мне показалось, что на последний вопрос Вы обратили недостаточное внимание.

Начну с математики. Говоря о математических основах графики Дракона, выскажу 10 замечаний.

:arrow: Замечание 1. Математическая суть графики Дракона не очень проста. Но! Эта сложность спрятана на дне глубокого колодца и полностью скрыта от программистов и пользователей, которые создают программы на языке Дракон. Им кажется, что никакой сложности нет и в помине. Что все очень легко и просто. Они могут ничего не знать об этой математике. Больше того, им вовсе не надо ее знать. Где же спрятана эта математика? Она спрятана во внутренних алгоритмах графического дракон-редактора (дракон-конструктора). Самое интересное в том, что разработчики дракон-редактора тоже могут ее не знать. Знание математических основ настолько глубоко спрятано, что никто не обязан их изучать. Как будто их и вовсе нет. Но они (математические основы), конечно, есть.

:arrow: Замечание 2. Илья! Первая возможная трактовка конструкции «силуэт» Вам хорошо известна, поскольку Вы пишете: «это детерминированный конечный автомат! В каждом состоянии выполняется некая ветка алгоритма, по окончании которой происходит переход в какое-либо другое состояние… Это особенно интересно — прямая поддержка автоматного программирования».
Я тоже об этом упоминаю (см. сноску на стр. 260 и рис. 137).

:arrow: Замечание 3. Но существует и несколько иная трактовка, связанная с методом (теоремой) Ашкрофта-Манны. Этот метод позволяет преобразовать неструктурную программу в структурную путем введения переменной состояния (см. Йодан Э. Структурное проектирование и конструирование программ. М.: Мир, 1979. С. 192—196, а также Котов В.Е., Сабельфельд В.К. Теория схем программ. М.: Наука, 1991. С. 233—238).

:arrow: Замечание 4. Опираясь на идею Ашкрофта-Манны и теорему структуризации, я сформулировал две теоремы:
    Теорема 1. Любая структурная программа может быть изображена на языке ДРАКОН двумя способами: в виде примитива и в виде силуэта.
    Теорема 2. Произвольная (неструктурная) программа в ряде случаев не может быть изображена в виде примитива; однако с помощью эквивалентных преобразований, допускающих введение дополнительных переменных (идентификаторов ветки), она всегда может быть изображена в виде силуэта (см. мою книгу, стр.100).

:arrow: Замечание 5. В замечаниях 1—4 речь шла об узком вопросе — математике конструкций «силуэт» и «ветка». В замечаниях 6—10 речь пойдет о более широком взгляде на проблему — о математических основах всего графического синтаксиса.

:arrow: Замечание 6. Эта более широкая математика может показаться еще более сложной, так как она подразумевает почти полный отказ от традиционного понятийного аппарата и замену его на принципиально новый и непривычный понятийный аппарат. Чтобы математически обосновать графический формализм языка Дракон, я разработал два новых теоретических подхода:
    • графическое структурное программирование (которое коренным образом отличается от текстового структурного кодирования — см. главу 16);
    • графическое логическое исчисление (исчисление икон) — см. главу 17.

:arrow: Замечание 7. Однако ничего страшного нет. Эта математика также спрятана на дне глубокого колодца. Она полностью скрыта от программистов и пользователей, которые создают программы на языке Дракон. Им кажется, что никакой сложности нет и в помине. Что все легко и просто. Они могут ничего не знать об этой математике. Больше того, им вовсе не надо ее знать. И так далее (см. Замечание 1).

:arrow: Замечание 8. На основе указанных новых теоретических походов разработано формальное описание графического синтаксиса языка Дракон (см. главу 15).

:arrow: Замечание 9. Надо ли знать формальное описание графического синтаксиса программистам и пользователям, которые пишут программы на Драконе? Нет, не надо. Потому что это описание «зашито» во внутренних алгоритмах дракон-редактора. Они должны знать только инструкцию по использованию дракон-редактора. Чтобы ее освоить, сидя за компьютером, надо потратить примерно час-полтора.

:arrow: Замечание 10. Однако это описание (формальное описание графического синтаксиса) должны хорошо знать разработчики дракон-редактора. Подробная инструкция по разработке такого редактора изложена в главе 14.
Илья! На этом я заканчиваю обсуждение математики Дракона, на которую хотел обратить Ваше внимание.

:mrgreen: Перехожу ко второй теме — изложению моей бредовой идеи.
В книге я постеснялся ее высказать. Есть тема, которая изложена в книге плохо — робко, обтекаемо, без острой постановки вопроса и почти без критики в адрес Эдсгера Дейкстры. Сейчас я хочу нарочито заострить вопрос и посоветоваться с Вами и Вашими коллегами как с профессионалами высокого класса. Так сказать, вынести бредовую идею на обсуждение и выслушать Вашу критику. Если критика будет убийственной, придется забить осиновый кол в ее могилу. Если нет, я опубликую ее при переиздании книги.

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

В чем суть? Как известно, Дейкстра ввел три конструкции: сочленение, выбор, повторение. Он пишет (цитирую по русскому переводу):
    «Итак, мы познакомились с тремя типами разложения; можно называть их соответственно “сочленение”, “выбор”, “повторение”. Для понимания первых двух служит рассуждение с перечислением, а для последнего нужна математическая индукция».
    «Программы, при написании которых управление последовательностью действий осуществляется только при помощи выбора и повторения, допускают непосредственный перевод на некий язык программирования, который отличается от исходного только тем, что все управление последовательностью действий должно быть выражено передачами управления на метки. Однако обратное утверждение было бы неправильным. Напротив, если мы ограничимся указанными тремя типами разложения, то это приведет к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись данными тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине».
    «Почему я предлагаю придерживаться этой последовательностной дисциплины? Это решение может быть обосновано различными способами, и я попытаюсь изложить несколько таких обоснований в надежде на то, что хотя бы одно из них удовлетворит моих читателей». См. Э. Дейкстра. Заметки по структурному программированию. В кн.: У.Дал, Э. Дейкстра, Ч. Хоор. Структурное программирование. М.: Мир, 1975. С. 28.

:mrgreen: В чем состоит моя «бредовая» критика в адрес Дейкстры?
Я полагаю, что Дейкстра либо не был знаком с математической логикой в должной мере, либо не сумел применить ее к приведенным выше рассуждениям. К чему это привело?

Дейкстра выделяет три понятия: сочленение, выбор и повторение. Он называет их ОПЕРАТОРАМИ управления. С точки зрения математики, здесь все правильно. Но аляповато.
    Пример 1. Если посмотреть на программу, никто не увидит оператор сочленения. Операторы выбора есть, операторы повторения (циклы) есть, а оператора сочленения нет. Нет, и все тут! Конечно, само сочленение есть: оно состоит в том, что команды пишутся подряд. Но ОПЕРАТОРА сочленения нет — корова языком слизала. Выходит, что некоторые операции из выделенной Дейкстрой тройки понятий имеют операторы и ключевые слова, а другие нет. Это некрасиво (а если отбросит деликатность — коряво).
    Пример 2. А где оператор вложения? Ведь само вложение есть (например, «цикл в цикле». А оператора вложения нет. Неувязочка получается.

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

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

Дракон — это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно — новое мировоззрение.

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

:mrgreen: Вернусь к «бредовой» идее. Суть ее такова.
Дейкстрианская революция состоит в том, что Дейкстра ввел строгую дисциплину в анархическом царстве процедурного программирования. Но любая дисциплина — это ограничение свободы. Недостаток в том, что Дейкстра ввел неоправданно жесткие ограничения. Фактически Дейкстра добился успеха за счет того, что ввел интеллектуальное рабство и заковал программистов в кандалы.

Первые голоса протеста прозвучали в самом начале его мощной атаки против засилья анархистов. Оппоненты доказывали, что хлесткий лозунг Дейкстры «GOTO considered harmful» в ряде случаев не верен. Со временем им удалось заметно облегчить тюремный режим и сделать кандалы более легкими. Они действовали методом троянского коня, используя приемы, которые я называю «заменителями goto» (см. стр. 246—253 моей книги).

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

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

Лозунг академика Андрея Ершова «Программирование — вторая грамотность!» оказался утопическим. Потому что Дейкстра построил удивительно прочную тюрьму, в которой почти все запрещено. Куда ни повернись — все нельзя!
Задача состоит в том, чтобы спилить решетки на окнах тюрьмы, резко уменьшить число запретов и ограничений, то есть предоставить узникам свободу.

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

:mrgreen: Многие запреты Дейкстры противоречат здравому смыслу и затрудняют понимание алгоритмов и программ. Пример приведен на рис. 26б.
Дейкстра запретил подобные алгоритмы, объявив их неструктурными. Но такие алгоритмы часто встречаются в практическом производстве. Примерно так выглядит, например, контрольный набор стартовых готовностей.

:mrgreen: Конструкция на рис. 26б не считается «структурной управляющей конструкцией». Поэтому она запрещена. Что отсюда следует? Мой ответ таков: пусть структурные управляющие конструкции отправляются на заслуженную пенсию. Потому что во многих случаях (хотя и не всегда) они уродуют нормальный ход человеческой мысли.

Недопустимо запрещать правильный процесс мышления. Его надо разрешить. И Дракон разрешает.

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

Info21 Четверг, 19 Июль, 2007

Насчет замены языка графикой — чушь. Просто чушь. Человечество бы руками махало вместо разговора, и рисовало вместо письма. Язык — самый мощный передатчик информации.

Ответ Паронджанова

Уважаемый Info21!

Я люблю острую критику. Так что Ваша реплика мне глубоко симпатична. Но ответить на Вашу критику сложно, так как я плохо понял Вашу мысль.
Мне кажется, что язык жестов («размахивание руками») и звуковой язык («разговор») не имеют отношения к теме, так как предметом обсуждения является, in my humble opinion, только письменный (а не жестовый и не звуковой) язык.
Но главную загадку для меня представляет Ваш лозунг «Язык — самый мощный передатчик информации». Что он означает? Об этом я могу только гадать.

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

:?: Гадание первое (первый вариант моего ответа на критику Info21).

О каком языке идет речь? Может быть, Вы имеете в виду естественный язык?
Если да, то я считаю тезис «Естественный язык — самый мощный передатчик информации» глубоко ошибочным. Впрочем, у Вас есть влиятельный союзник — знаменитый французский лингвист Андре Мартине (1908—1999). Вот его коронная фраза: «Язык — это способность сказать все».

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

Сошлюсь на мнение ученых. Знаменитый математик Николай Лобачевский, выступая на торжественном собрании Казанского Императорского университета 5 июля 1828 года в первую годовщину его пребывания на посту ректора, сказал:
«Чему… одолжены своими блистательными успехами… науки, слава нынешних веков, торжество ума человеческого? Без сомнения, искусственному языку своему».
Кстати сказать, речь Лобачевского очень любопытна. Захотите почитать, вот ссылка:
http://www.ksu.ru/infres/nikolaev/kniga/gl1.htm

:?: Гадание второе (второй вариант моего ответа на критику Info21).

Может быть, Вы имеете в виду, что язык — это широкое понятие, которое охватывает не только естественный язык, но и полную совокупность искусственных языков, включая язык математики, логико-математические исчисления, языки программирования и т.д.? Но тогда почему Вы исключаете из этого широкого понятия графические искусственные языки?
Может быть, Вы считаете, что графические языки не существуют?
Но это не так. Они существуют. И в большом количестве.
В.Н. Агафонов сообщает: «…языки делятся на два основных класса: графические и текстовые». См. Агафонов В.Н. Языки и средства спецификаций программ. В кн.: Требования и спецификации в разработке программ. Перевод с английского под ред. В.Н. Агафонова. М.: Мир, 1984. С. 292.
Возможно, Вы скажете, что это древняя и устаревшая книга.
Тогда наберите в Гугле запрос «Графический язык программирования». Вы получите море ответов. Возможно, Вы возразите: многие ответы не соответствуют теме. Это правда. Но некоторые соответствуют.

:?: Гадание третье (третий вариант моего ответа на критику Info21).

Может быть, Вы считаете, что термин «графика» подразумевает строгий запрет на использование текста? Но почему? Даже в конструкторских чертежах используются текстовые символы. Графика без текста не бывает. Вернее, бывает, например, на картинах художников. Но ведь мы сейчас дискутируем не о произведениях искусства.

Я утверждаю: термин «графика», используемый в научно-технической сфере, очень часто или даже преимущественно обозначает совместное использование графики и текста. Возможно, Вы возразите: дескать, в программировании так не говорят. Это тоже неверно. Вот Вам пример — статья Владимира Зюбина (zyubin@iae.nsk.su) — старшего научного сотрудника Института автоматики и электрометрии Сибирского отделения РАН (Новосибирск).
Статья называется: «Графика или текст: какой язык нужен программисту?». Вот ссылка http://www.osp.ru/os/2004/01/183824/

Уважаемый Info21! Вполне вероятно, что Вы со мной не согласитесь. В этих условиях единственное, что могу сделать — это рекомендовать Вам мою книгу «Паронджанов В.Д. Почему мудрец похож на обезьяну, или Парадоксальная энциклопедия современной мудрости». М.: РИПОЛ классик, 2007.
В этой книге я, в частности, очень подробно говорю о достоинствах и преимуществах эргономичной графики и привожу множество примеров. Кроме того, очень подробно доказываю, что широко распространенная вера в то, что естественный язык — самый мощный передатчик информации, является трагическим заблуждением, которое наносит человечеству огромный урон.

С большим уважением к Вашей позиции
Не согласный с Вами Владимир Паронджанов


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Февраль, 2008 21:04 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Да уж... придется много думать :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Февраль, 2008 15:10 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 7
Откуда: Зеленоград
Владимир Паронджанов писал(а):
:mrgreen: Конструкция на рис. 26б не считается «структурной управляющей конструкцией». Поэтому она запрещена.
А так ли это? :roll:
Насколько я понимаю, речь идет о рисунке справа на с.116.
Вот я пишу
Код:
if C or D or E or D or F or G or H then
  B
else
  A
end;
и получаю те же 2 ветки, что и на указанном рисунке.
Справедливости ради, здесь есть определенная тонкость: в "моем" варианте (на основе Оберона) при вычислении логического выражения используется правило "короткого замыкания", которым Дейкстра в 60-е годы воспользоваться, наверное, не мог.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Февраль, 2008 19:39 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 28
Откуда: Ленинград, Емельянов Алексей Николаевич
"Посмотрел" книгу "Как улучшить работу ума", - первые впечатления: видимо у меня принципиально сукцессивное восприятие. На этапе изучения какого-либо вопроса, текстовое представление для меня предпочтительнее. Вот когда разобрался, тогда, да, графическое представление дает мгновенное узнавание, в то время как текст нужно читать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Февраль, 2008 21:58 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 33
Axcel писал(а):
"Посмотрел" книгу "Как улучшить работу ума", - первые впечатления: видимо у меня принципиально сукцессивное восприятие. На этапе изучения какого-либо вопроса, текстовое представление для меня предпочтительнее. Вот когда разобрался, тогда, да, графическое представление дает мгновенное узнавание, в то время как текст нужно читать.

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


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

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


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

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


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

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