DRAKON.SU

Текущее время: Четверг, 18 Апрель, 2024 09:55

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Среда, 10 Октябрь, 2012 16:45 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Степан Митькин писал(а):
TAU писал(а):
У чистых функциональных программ, вообще говоря, нет ни последовательности, ни состояния.

Нельзя говорить, что в функциональных программах совсем нет последовательности

Да, согласен ) я поэтому и написал "вообще говоря" ;)
Есть последовательность выполнения функций - но нет единого глобального состояния выч.прочесса, что и обуславливает возможность его распараллеливания на разные процессоры.

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

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

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


Последний раз редактировалось TAU Среда, 10 Октябрь, 2012 16:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Октябрь, 2012 16:56 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Владимир Паронджанов писал(а):
В сообщении viewtopic.php?p=75245#p75245 Степан Митькин писал(а):
Подробности описаны в этой статейке.
У меня три замечания.
1. Это не статейка, а статья. Причем очень серьезная. На 23 страницах.
Я выделил из статьи отрывок. И перевел этот отрывок на русский язык.
Цитата:
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.


Владимир Даниелович,
Присоединяюсь к Вашей высокой оценке СТАТЬИ Степана Борисовича Митькина.

Браво!

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

Степан, Вы научные статьи пишете? Вы вообще по основному профилю деятельности и образованию кто? Вам самое место в науке!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2012 23:30 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Рекомендую статью по функциональному программированию:

http://www.cs.kent.ac.uk/people/staff/d ... hyfp90.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 03 Ноябрь, 2012 10:36 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5848
Откуда: Москва
usr345 писал(а):
Рекомендую статью по функциональному программированию:

http://www.cs.kent.ac.uk/people/staff/d ... hyfp90.pdf


Выкладываю Заключение из статьи
Цитата:
Why Functional Programming Matters
John Hughes
The University, Glasgow


Цитата:
6 Conclusion

In this paper, we’ve argued that modularity is the key to successful programming.
Languages that aim to improve productivity must support modular programming well.
But new scope rules and mechanisms for separate compilation are not enough — modularity means more than modules.

Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To support modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue — higher-order functions and lazy evaluation.

Using these glues one can modularize programs in new and useful ways, and we’ve shown several examples of this.

Smaller and more general modules can be reused more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at.

If any part of a program is messy or complicated, the programmer should attempt to modularize it and to generalize the parts. He or she should expect to use higher-order functions and lazy evaluation as the tools for doing this.

Of course, we are not the first to point out the power and elegance of higherorder functions and lazy evaluation.

For example, Turner shows how both can be used to great advantage in a program for generating chemical structures [3].

Abelson and Sussman stress that streams (lazy lists) are a powerful tool for structuring programs [1]. Henderson has used streams to structure functional operating systems [2]. But perhaps we place more stress on functional programs’ modularity than previous authors.

This paper is also relevant to the present controversy over lazy evaluation.

Some believe that functional languages should be lazy; others believe they should not. Some compromise and provide only lazy lists, with a special syntax for constructing them (as, for example, in Scheme [1]).

This paper provides further evidence that lazy evaluation is too important to be relegated to secondclass citizenship. It is perhaps the most powerful glue functional programmers possess. One should not obstruct access to such a vital tool.


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

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


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

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


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

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