| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 672 12-08-2006 05:08 |   |
Ответ на »сообщение 671« (hugi)
___________________________
Верное замечание :)
| № 671 12-08-2006 05:04 | |
Ответ на »сообщение 624« (Jack Of Shadows)
___________________________
А разве N-ядерные процессоры не производят автоматического распараллеливания? Ведь, например, конвейеры работают на обычных процессорах, хотя это не что иное, как параллельное выполнение отдельных инструкций.
| № 670 12-08-2006 04:59 | |
Кто мне все-таки ответит? В Лиспе стек можно переполнить? Я в Прологе могу. :)
| № 669 12-08-2006 04:55 | |
Ответ на »сообщение 649« (Geniepro)
___________________________
Ответ на »сообщение 648« (Артем)
___________________________
И вообще, чтобы переполнить стек в Дельфи - надо постараться. К тому же я уже раньше говорил о настройке размера стека.
Чего там стараться? Выполните рекурсивный QuickSort над массивом из хотя бы 50 тысяч элементов, отсортированных в обратном порядке...
Что бы не произошло переполнения стека придётся увеличить его (стека) размер
Блин, ну вы заставляете меня заниматься всякой ерундой. Я вот взял и из 500000 элементов массив обработал. Размер стека пол умолчанию. Даже оптимизацию не включал и фреймы для стека. Никакого перепонения. Привожу свой код, если не трудно, приведите свой
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
ButtonTEST: TButton;
Memo1: TMemo;
ButtonSTOP: TButton;
procedure ButtonTESTClick(Sender: TObject);
procedure ButtonSTOPClick(Sender: TObject);
private
public
end;
var
Form1: TForm1;
implementation
var stopFlag:boolean;
procedure Sort(var A: array of Integer);
procedure QuickSort(var A: array of Integer; iLo, iHi: Integer);
var
Lo, Hi, Mid, T: Integer;
begin
Lo := iLo;
Hi := iHi;
Mid := A[(Lo + Hi) div 2];
repeat
while A[Lo] < Mid do Inc(Lo);
while A[Hi] > Mid do Dec(Hi);
if Lo <= Hi then
begin
T := A[Lo];
A[Lo] := A[Hi];
A[Hi] := T;
Inc(Lo);
Dec(Hi);
end;
until Lo > Hi;
if Hi > iLo then QuickSort(A, iLo, Hi);
if Lo < iHi then QuickSort(A, Lo, iHi);
end;
begin
QuickSort(A, Low(A), High(A));
end;
procedure TForm1.ButtonTESTClick(Sender: TObject);
var
A:array of integer;
i,k:integer;
begin
SetLength(A,500000);
k:=499999;
for i:=0 to High(A) do begin
A[i]:=k;
dec(k);
end;
Sort(A);
stopFlag:=False;
for i:=0 to High(A) do begin
Memo1.Lines.Add(IntToStr(A[i]));
Application.ProcessMessages;
if stopFlag then Break;
end;
ShowMessage('The End!')
end;
procedure TForm1.ButtonSTOPClick(Sender: TObject);
begin
stopFlag:=True;
end;
end.
| № 668 12-08-2006 04:50 | |
Ответ на »сообщение 621« (Jack Of Shadows)
___________________________
Императивные языки до сих пор ведут себя так как будто им доступно всего 640 кб. :))
Очень остроумно! А Вы не слышали про такой язык программирования, как Smalltalk?
| № 667 12-08-2006 04:37 | |
Ответ на »сообщение 578« (Jack Of Shadows)
___________________________
ООП это не просто "данные + методы". ООП это метод достижения некоторых целей, а именно инкапсуляции и полиморфизма.
Вот это да! Вдруг выяснилось, что инкапсуляция и полиморфизм -- ЦЕЛИ ООП! А я то, несведущий человек, всю жизнь думал, что инкапсуляция и полиморфизм -- это СРЕДСТВА ООП, а ни как не цели!!! Я, конечно, понимаю, что нынче модно критиковать Буча, но всё же не потрудитесь прочитать (или перечитать?), чтобы впредь не допускать подобных... эээ... будем называть это оговоркой.
В конце концов и в хаскеле нужно работать с состоянием и хранить его в переменных.
Не нужно, а можно. Но это уже будет не функциональное программирование, а императивное, ибо ФП провозгласило свободу от состояний.
Существуют и другие механизмы которые позволяют достичь тех же результатов.
Посмотрите например type classes и modules в хаскеле.
Совместно они дают вам все что только может дать вам ООП. При этом в гораздо более понятном, простом виде, и без проблем которые приносит ООП со своим наследованием.
Да, я так понимаю, наследование сейчас тоже модно критиковать. Только не увлекайтесь! Мода, ведь, изменчивая штука! Тем более, что наследование очень мощный механизм, и я не представляю, чем его можно было бы заменить. А приведённые средства Хаскеля очень смахивают на интерфейсы, которыми программисты на Java, Delphi, C# (а также программисты на С++ и Eiffel, под видом абстрактных классов) используют уже давным давно. И это всё равно не заменитель ООП, если только Вы правильно его понимаете (относительно чего у меня зародилось сомнение после Вашего перла про ЦЕЛИ ООП).
То есть функциональное Программирование дает вам ту же инкапсуляцию и тот же полиморфизм что и ООП.
Поэтому обьекты там лигние просто. Их нет смысла испольовать. Они ничего не приносят, только все осложняют.
См. Буча.
| № 666 12-08-2006 04:20 | |
Ответ на »сообщение 662« (Jack Of Shadows)
___________________________
Вообще то ругать ООП на сайте дельфи - это ересь.
Думаю щас мне не поздоровится :))
Вагиф, просто это у вас оскомина на ООП, потому что вы, наверное, слишком долго им занимались и вам хочется чего-то новенького. Если серьезно, то спор о преимуществе ООП или ФЯ сродни спору атеистов и религиозных фанатиков. И то и другое недоказуемо.
P.S. А почему бы вам не открыть сайт "Королевстов Лиспа"? :)))
| № 665 12-08-2006 04:18 | |
Ответ на »сообщение 561« (Jack Of Shadows)
___________________________
Новенькая статья Джоела Спольски : http://www.joelonsoftware.com/items/2006/08/01.html
Can Your Programming Language Do This?
О чем он там говорит ? Да о том же о чем мы здесь говорим :))
Сначала приводит примеры анонимных функций и передачу их как параметров.
Затем обьясняет почему анонимные классы в java, ну и соотвественно аналогичные механизмы в сишарп, не являются аналогичной заменой (это вам hugi, знаю что не убедит, просто пример еще одного человека думающего не так как вы.)
Только не нужно добавлять от себя про "аналогичные механизмы в сишарп", в статье про это ни слова! А объяснение, почему анонимные классы в Java не являются аналогичной заменой сводиться к тому, что они "ещё более безобразны, чем функции в С". Потрясающее объяснение! Вот уж точно begin/end VS {}!
| № 664 12-08-2006 04:13 | |
Ответ на »сообщение 661« (Jack Of Shadows)
___________________________
Ну у него еще все впереди. Все это сейчас весьма активно наращивается.
Все это весьма проблематично. Дело в том, как я уже говорил ранее, что количество ФЯ перевалило за всякие приличные рамки. Вот только что я посмотрел статью по Curry (безобразие, мне надо 3 проекта заканчивать, а я тут билиберду читаю всякую! ). В статье про Curry кричат, что это самое перспективное направление. Посмотрел примеры на Curry ( http://www.informatik.uni-kiel.de/~mh/curry/examples/ ). Да, тоже красиво. Там и логические возможности есть, неполный поиск и т.д. Только-вот боюсь, что закончится все это пшиком. Кому-то приходит в голову идея, но этот одиночка (двое, трое, пусть даже сто человек) не смогут реализовать эту идею так, чтобы из катящегося снежного шарика возникла снежная лавина. Слишком много "форков", слишком много языков. Пока какая-нибудь крупная фирма не выберет новый язык, чтобы сделать на его основе что-нибудь убойное - ничего не будет. А жаль...
| № 663 12-08-2006 04:08 | |
Мне кажется при разговоре о параллельности есть некоторое смешение понятий. Есть "распараллеливаие" преследующие цель повышения производительности, а есть синхронизация программ или их частей обусловленное логикой взаимдействия, например с "внешним миром", Так вот потоки, мне кажется предназначны для второго, то это средсто для реализации такой логики.
Что касается "распараллеливания", наверно у ФЯ есть преимущества. Хотя, насколько я помню в уже неднократно упоминавшемся Алголе 68 была конструкция, которая позволяла у казать, что некотрый набор "основ" (Алглол 68 состоит из "основ") может выполнятся параллельно (аснхронно).
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
