Подробности описаны в этой
статейке.
У меня три замечания.
1. Это не статейка, а статья. Причем очень серьезная. На 23 страницах.
2. Статья чрезвычайно интересная. Содержащая важные новые идеи. А может быть, даже революционная.
3. Степан Борисович, Вы дали ссылку
http://sourceforge.net/projects/drakon- ... f/downloadЭто косвенная ссылка. На моем быстром ноутбуке эта ссылка открывается медленно. Мне кажется, лучше давать не косвенную, а прямую ссылку:
http://ignum.dl.sourceforge.net/project ... Erlang.pdf
Прямая ссылка (через ignum.dl. и без download) открывается моментально. Как Вы считаете?
Всё вроде бы хорошо, но есть небольшая проблема.
Функциональные программы уж больно трудно читать.
Плохая формулировка. Слово "небольшая" вводит в заблуждение и портит всю обедню. Слово "небольшая" надо удалить. После этого формулировка становится приемлемой.
Повторю свои тезисы:
1. Функциональные языки не имеют принципиальный отличий от "обыкновенных" (кроме отсутствия циклов).
2. Трудность чтения функциональных программ вызвана исключительно традицией их записи.
3. ДРАКОН может быть успешно использован для улучшения понимаемости функциональных программ.
Приветствую тезисы Митькина. Обобщая их, предлагаю для обсуждения формулировку:
Цитата:
Тезис Степана Митькина
Основной недостаток функционального программирования (трудность чтения функциональных программ) можно значительно ослабить или даже полностью устранить с помощью языка ДРАКОН
Степан Митькин писал(а):
========================================
Я выделил из статьи отрывок. И перевел этот отрывок на русский язык.
Цитата:
Algorithm is the core of software. It is the algorithm that produces the desired output of a program. Therefore, if the algorithm is easy to understand, the whole program is easy to maintain, extend and document.
Unfortunately, the traditional way of recording algorithms is wrong. This is a major problem of programming in general, not only functional programming. Algorithms in most of the modern programs are written using text. This text is called "the source code".
Usually, source code is indented in a special way and highlighted with different colors in the editor. But it is plain text. Text is bad because humans are not very good at understanding text. Their eyes and brains have been optimized for seeing images during millions of years. Text is a recent invention. The human biological hardware is not natively compatible with text.
If the algorithm is presented as an picture instead of text, it can be easier to understand.
There are a lot of ways to draw an algorithm. Choosing the right one is critically important. A bad picture can be worse than text. A good picture will leverage the ability of the human being to perceive information simultaneously.
Flowcharts are a popular graphical notation for representing algorithms. Many developers do not like flowcharts. The reason is that complex algorithms tend to end up in badly cluttered flowcharts. Those can be harder to figure out than text-based programs. As a result, graphical programming is often dismissed as an unsuccessful experiment.
But the problem is not in graphical programming itself. The problem is that flowcharts as a graphical language are not good enough. The good news is, it is possible to improve this language.
DRAKON provides such improvement. It offers several simple, but effective rules that cardinally increase readability of a diagram. DRAKON is a visual language that can be described as flowcharts optimized for ergonomics. The creators of DRAKON paid great attention to human visual habits.
Every little detail of DRAKON is aimed at ensuring fast and easy understanding.
That is why DRAKON is an excellent candidate for visualization of a functional programming language. The clarity of DRAKON is something that functional programming can greatly benefit from.
Перевод на русский язык
Цитата:
Алгоритм является ядром программного обеспечения. Именно алгоритм определяет желаемый результат программы. Если алгоритм пригоден для легкого и быстрого понимания, то вся программа окажется удобной для сопровождения, внесения изменений, расширения функциональных возможностей и документирования.
К сожалению, традиционный способ записи алгоритмов не в полной мере пригоден для создания понятных алгоритмов. Это серьезная проблема. Проблема, характерная для программирования в целом, а не только для функционального программирования. Алгоритмы в подавляющем большинстве программ написаны с помощью текста, т.е. исходного кода.
Как правило, исходный код пишут с отступами (индентацией) и выделяют нужные слова разными цветами в редакторе. Эти приемы (отступы и цвет) полезны, но они не изменяют природы текста. Трудность в том, что люди далеко не всегда способны глубоко понять сложный текст. Человеческий глаз и мозг в течение миллионов лет, предшествовавших появлению текста, привыкли воспринимать зрительные образы окружающего мира. Мира, в котором текст полностью отсутствовал. Текст — недавнее изобретение. Электробиохимическая структура нервной системы человека (biological hardware) на начальном этапе эволюции была приспособлена к зрительным образам внешнего мира, но не знакома с текстом и не адаптирована к нему.
Если же алгоритм представить не в виде текста, а в виде картинки (изображения) ситуация меняется. Картинка ближе к зрительным образам окружающего мира, чем текст. Поэтому она проще для восприятия. И понятнее.
Существует несколько нотаций для проектирования и записи алгоритмов. Выбор наилучшей нотации очень важен. Плохая картинка может быть хуже, чем текст. И наоборот, хорошая картинка может спасти положение.
Какую же картинку можно признать хорошей? По-видимому, ту, что построена с учетом структурных особенностей человеческого глаза и мозга, сформированных в течение миллионов лет эволюции. То есть ту, в основе которой лежит способность человека к симультанному восприятию зрительной информации.
Блок-схемы — графическая нотация для представления алгоритмов. Подобные схемы считаются устаревшими и не пользуются популярностью. По мнению большинства, использование блок-схем не только не ускоряет, а наоборот, тормозит процесс программирования. В итоге графическое программирование часто называют неудачным экспериментом.
Но проблема отнюдь не в графическом программировании. А в том, что блок-схемы имеют существенные недостатки. К счастью, эти недостатки можно устранить.
Язык ДРАКОН позволяет решить проблему понимания с помощью простых, но эффективных правил, которые кардинально улучшают читаемость и понятность алгоритмов. ДРАКОН можно охарактеризовать как блок-схемы, оптимизированные с учетом требований когнитивной эргономики.
Создатели ДРАКОНа уделяют большое внимание особенностям зрительного восприятия человека. Правила ДРАКОНа учитывают то обстоятельство, что в поле чертежа необходимо оптимально расположить мелкие графические детали, которые в совокупности формируют целостный зрительный образ.
За счет повышенного внимания к мелким деталям графики ДРАКОН обеспечивает быстрое и легкое понимание сложного алгоритма.
Именно поэтому ДРАКОН является отличным кандидатом для визуализации функциональных языков. Кристальная ясность алгоритмов, которую обеспечивает ДРАКОН — вот та особенность, которая может добавить функциональному программированию дополнительное преимущество.
Примечания1. Мой перевод не дословный, а вольный, то есть отредактированный.
2. Причина редактирования в том, что, по моему мнению, в тексте Митькина есть резковатые, неосторожные выражения, которые могут вызвать возражения оппонентов.
3. Я стремился сделать русский текст более осторожным. С этой целью я ввел несколько пояснений (отсутствующих в исходном тексте).
4. Если Степан Борисович не согласен с моими правками, следует их (правки) игнорировать.
5. В этой статье Степан Борисович выдвигает новые идеи и делает смелые заявления. Я поддерживаю эти идеи и заявления. И хочу пожелать Степану Борисовичу успехов в продвижении этих идей.
6. Недостатком статьи является слишком короткий список литературы.
Желательно добавить дополнительные источники. Это объясняется тем, что необычные идеи нуждаются в дополнительном обосновании и привлечении большого количества дополнительной литературы.
Расширенный список литературы (не притянутой за уши, а только по делу) поможет убедить оппонентов, что автор знаком с современной литературой по предмету (и по смежным вопросам) и умеет тщательно обосновать свои утверждения, опираясь на авторитетные источники.
===================================
Уважаемые коллеги!
Желательно обсудить статью Степана Борисовича Митькина на нашем форуме.
Трудность в том, что статья на английском.
Я перевел только очень малый фрагмент статьи.
Вход
FAQ
Поиск
