Статья про развитие идей ООП. Жду комментариев. - Архитектура программного обеспечения

Здравствуйте, vgrigor, Вы писали:

V>Да, правое ухо чесать через-под левое колено,
V>это на ваш вкус.

Извините за грубость, но если вы чего то не понимаете, лучше промолчать, чем выставлять свое невежество напоказ.
То что рекурсия слабо используется в Visual Basic'e от фирмы Microsoft, не значит, что она плоха, это значит
лишь, что ее там использовать не целесообразно. А существуют (удивительное дело) языки, где не целесообразно
использовать циклы, а есть языки где переменных нет, и есть языки, где порядок операторов не важен. Но все это,
конечно, поделки развлекающихся бездельников, ведь умные дяди из Microsoft эти языки не используют, а им ведь
виднее.
Короче, я привел ссылки. Кого интересует программирование, как наука и исскуство, а не только как не особо напряжный
способ заработать на жизнь лабая формы в VS, могут найти там что-нибудь интересное.

Моя точка зрения основана на эффективном программировании,
быстром написании и оптимизации жизненного цикла программы.

А у вас вкус другой,
не буду вам мешать.

кстати вы аноним для таких высказываний,
и это некорректно.

Здравствуйте, Voblin, Вы писали:

V>Может быть, кому-нибудь будет интересно.
V>http://voblin.nm.ru/objects_classes.dhtml
V>Сразу вопрос: стоит ли это опубликовать в RSDN?

Я извиняюсь за последующие ламерские вопросы но мне интересно разобраться с идеями автора.
1. На данном этапе понятие интерфейс является класс с абстрактными виртуальными методами которые давным давно реализуются в СОМ (возможность отказа от виртуальности проблема компилятора так как не нужно наследование делать их статическими)
2. Все последующие доводы опять же крутятся вокруг интерфейсов. Приведения объекта к определенному интерфейсу.
3. Почему то не увидел в С# директиву аналогичную в Delphi Implements.
Еще раз прошу меня извинить и напрвить на путь истинный.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Voblin, Вы писали:

V>>Может быть, кому-нибудь будет интересно.
V>>http://voblin.nm.ru/objects_classes.dhtml
V>>Сразу вопрос: стоит ли это опубликовать в RSDN?

S> Я извиняюсь за последующие ламерские вопросы но мне интересно разобраться с идеями автора.
S> 1. На данном этапе понятие интерфейс является класс с абстрактными виртуальными методами которые давным давно реализуются в СОМ (возможность отказа от виртуальности проблема компилятора так как не нужно наследование делать их статическими)
S> 2. Все последующие доводы опять же крутятся вокруг интерфейсов. Приведения объекта к определенному интерфейсу.
S> 3. Почему то не увидел в С# директиву аналогичную в Delphi Implements.
S> Еще раз прошу меня извинить и напрвить на путь истинный.

Не очень понял вопрос, ну и ладно, попробую ответить как понял.
1. Про абстрактные классы: абстрактный и виртуальный — не одно и то же.
2. Как объект соотносится с интерфейсом.
Сейчас делается так (сильно упрощённая схема):

 Интерфейс ------> Класс <------ Экземпляр
           *    1         1    *

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

Предлагается вот что:

 Интерфейс ------> Класс <------> Экземпляр
           *    1         *    *

Т.е. экземпляр может принадлежать нескольким классам и, соответственно, иметь присущие им наборы интерфейсов.

Здравствуйте, vgrigor, Вы писали:

V>Да, правое ухо чесать через-под левое колено,
V>это на ваш вкус.
Use the right tool.(c)

... << RSDN@Home 1.0 beta 7a >>

Здравствуйте, Voblin, Вы писали:

V>

V> Интерфейс ------> Класс <------ Экземпляр
V>           *    1         1    *
V>

V>Т.е. взяв объект, можем получить его класс и, следовательно, список интерфейсов.

А почему на стрелочке Интерфейс — Класс стоит *-1, а не *-*?

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, Voblin, Вы писали:

V>>>Может быть, кому-нибудь будет интересно.
V>>>http://voblin.nm.ru/objects_classes.dhtml
V>>>Сразу вопрос: стоит ли это опубликовать в RSDN?

S>> Я извиняюсь за последующие ламерские вопросы но мне интересно разобраться с идеями автора.
S>> 1. На данном этапе понятие интерфейс является класс с абстрактными виртуальными методами которые давным давно реализуются в СОМ (возможность отказа от виртуальности проблема компилятора так как не нужно наследование делать их статическими)
S>> 2. Все последующие доводы опять же крутятся вокруг интерфейсов. Приведения объекта к определенному интерфейсу.
S>> 3. Почему то не увидел в С# директиву аналогичную в Delphi Implements.
S>> Еще раз прошу меня извинить и напрвить на путь истинный.

V>Не очень понял вопрос, ну и ладно, попробую ответить как понял.
V>1. Про абстрактные классы: абстрактный и виртуальный — не одно и то же.
V>2. Как объект соотносится с интерфейсом.
V>Сейчас делается так (сильно упрощённая схема):

V>

V> Интерфейс ------> Класс <------ Экземпляр
V>           *    1         1    *
V>

V>Т.е. взяв объект, можем получить его класс и, следовательно, список интерфейсов.

V>Предлагается вот что:

V>

V> Интерфейс ------> Класс <------> Экземпляр
V>           *    1         *    *
V>

V>Т.е. экземпляр может принадлежать нескольким классам и, соответственно, иметь присущие им наборы интерфейсов.

В классическом Delphi интерфейсы определены как классы с абстрактными виртуальными методами и доступ к ним идет через VMT где прописаны реальные адреса процедур.

То есть
Интерфейс это класс
Interface= class
procedure P1; Virtual; abstract; stdcall;
procedure P2; Virtual; abstract; stdcall;
end;

В моем понимании ссылку на интерфейс можно прописать таким способом аналогичным TMethod.

TInterfase= Record
data:Pointer;// Сылка на данные класса
Code:Pointer;// Ссылка на VMT
end;

Implements в Delphi имеет замечательную возможность использовать класс реализующий уже набор интерфейсов например

type
IMyInterface = interface
procedure P1;
procedure P2;
end;
TMyImplClass = class
procedure P1;
procedure P2;
end;
TMyClass = class(TInterfacedObject, IMyInterface)
FMyImplClass: TMyImplClass;
property MyImplClass: TMyImplClass read FMyImplClass implements IMyInterface;
procedure IMyInterface.P1 = MyP1;
procedure MyP1;

end;
procedure TMyImplClass.P1;
...
procedure TMyImplClass.P2;
...
procedure TMyClass.MyP1;
...
var
MyClass: TMyClass;
MyInterface: IMyInterface;
begin
MyClass := TMyClass.Create;
MyClass.FMyImplClass := TMyImplClass.Create;
MyInterface := MyClass;
MyInterface.P1; // calls TMyClass.MyP1;
MyInterface.P2; // calls TImplClass.P2;
end;

В Delphi как и в Net и Java отказались от множественного наследования (огромное количество общих методов из-за наследовния от Object)

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Voblin, Вы писали:

V>>

V>> Интерфейс ------> Класс <------ Экземпляр
V>>           *    1         1    *
V>>

V>>Т.е. взяв объект, можем получить его класс и, следовательно, список интерфейсов.

L>А почему на стрелочке Интерфейс — Класс стоит *-1, а не *-*?

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

Здравствуйте, Serginio1, Вы писали:

S>В классическом Delphi интерфейсы определены как классы с абстрактными виртуальными методами и доступ к ним идет через VMT где прописаны реальные адреса процедур.

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

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

Как отписаться от темы не подскажете?

Здравствуйте, Voblin, Вы писали:

L>>А почему на стрелочке Интерфейс — Класс стоит *-1, а не *-*?

V>Потому что "сильно упрощённая схема". Конечно, если подрисовать наследование и делегирование, то получится что-то вроде *-*, но сути это не сильно поменяет, т.к. основные различия, которые и хотелось проиллюстрировать находятся в правой части схемки.

Какое нафик наследование и делегирование?!

*-* означает:

1 класс может реализованть несколько (*) интерфейсов.
1 инетерфейс может быть реалтзован несколькими (*) классами.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

V>В статье специально я оговорился о том, что понятие "интерфейс" у меня будет означать именно свойство или метод, тогда как в интерфейсном проектировании под этим понятием подразумевается то, что у меня обозначено как "набор интерфейсов".

Честно говоря туповат я немного никак не могу понять разницу между клаасическим понятием интерфейса и твоим. Implements в Delphi дает возможность не агрегировать реализацию интерфейса в классе а использовать уже существующий итд. Как бы там нибыло в моем понятии интерфейс это структура ссылок на методы. Ну да ладно. С другой стороны в Net возможно динамическое создание объектов реализующих дополнительные возможности этого класса которые могут быть делегированы в класс например через ArrayList или однонаправленный список. Плюс развитая система рефлексии которая позволяет по типу свойств итд.

Здравствуйте, <Аноним>, Вы писали:

А>Короче, я привел ссылки. Кого интересует программирование, как наука и исскуство, а не только как не особо напряжный способ заработать на жизнь лабая формы в VS, могут найти там что-нибудь интересное.
Есть такой язык называется С++ там есть такое слово template. Его виртуозное использование это функциональное программирование чистой воды. Целью которого служит генерация кода. Что позволяет писать в несколько раз меньше кода. Зная об этом разработчики VC++7.1 сделали просто потряающий оптимизатор который генерирует код по эффективности почти равный ручной работе на asm'е. К стати, а как обстаят дела со скоростью выполнения на этих навороченых функциональных языках?

ЗЫ Прочитай Александреску возможно поймешь что с С++ далеко не все так просто.
ЗЗЫ Кто знает функциональную сортировку O(N*log(N)) дайте линк.
ЗЗЗЫ Для некоторых типов данных возможна сортировка O(N) ищи Radix sort, а на функциональном слабо?

... << RSDN@Home 1.0 beta 6a >>

Здравствуйте, WolfHound, Вы писали:

WH>Есть такой язык называется С++ там есть такое слово template. Его виртуозное использование это функциональное программирование чистой воды. Целью которого служит генерация кода. Что позволяет писать в несколько раз меньше кода. Зная об этом разработчики VC++7.1 сделали просто потряающий оптимизатор который генерирует код по эффективности почти равный ручной работе на asm'е. К стати, а как обстаят дела со скоростью выполнения на этих навороченых функциональных языках?

Не надо путать людей. Шаблоны в С++ не имеют прямого отношения к ФП. Может быть они слегка похожи, но если присмотреться то разница будет очевидной. Полиморфизм в ФЯ работает совсем не так, как шаблоны, никакой дополнительной генерации кода для каждого нового типа не нужно. Тип может иметь сколь угодно сложную структуру и при этом определяется автоматически. Если вы попробуете, что-то подобное реализовать с помощью шаблонов, то получите геморой с огромными описаниями типов с уродливыми <>.
Чтобы было понятнее я приведу функцию mmap, которая применяет функцию ко всем элементам списка

let mmap list func =
     match list with
        tail::head => (func tail)::(mmap head func)
     |  [] => []

Вот и все определение для функции, которая принимает на вход список из элементов любого типа и применяет к ним функцию, которая возвращает какой угодно тип. Для использования этой функции нужно просто вызвать ее с соответсвующими аргументами. Сравните теперь это с тем, что пришлось бы написать на С++, почуствуйте разницу. Не говоря уже о том, что шаблоны не позволяют использовать частичные функции, ленивые вычисления, pattern matching для быстрого разбора сложных по структуре типов и т.п. А если вспомнить как реализованы шаблоны в разных компиляторах...

ФЯ как раз не навороченные. Я в одиночку напишу за пару месяцев компилятор такого простого языка, где будут все основные полезные возможности, а вот компилятор С++ боюсь и за пару лет одному человеку не написать. А со скоростью дела обстоят нормально. Если для языка есть компилятор и он не чисто функциональный, то на некоторых задачах (связанных, например, с ИИ), я уверен, он сделает даже С. Я не хочу здесь распространяться на эту тему, почитайте статью Why functional programming matters. Она есть в инете и там все объяснено гораздо лучше, чем мог бы объяснить я. Зайдите на сайт ocaml'a и поищите в новостях, там было сообщение о том, что они в каком-то сравнении компиляторов заняли высокое место.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, WolfHound, Вы писали:

WH>>Есть такой язык называется С++ там есть такое слово template. Его виртуозное использование это функциональное программирование чистой воды. Целью которого служит генерация кода. Что позволяет писать в несколько раз меньше кода. Зная об этом разработчики VC++7.1 сделали просто потряающий оптимизатор который генерирует код по эффективности почти равный ручной работе на asm'е. К стати, а как обстаят дела со скоростью выполнения на этих навороченых функциональных языках?

А>Не надо путать людей. Шаблоны в С++ не имеют прямого отношения к ФП.

Эт ты зря. Просто не знаешь, о чем идет речь.

А>Может быть они слегка похожи, но если присмотреться то разница будет очевидной. Полиморфизм в ФЯ работает совсем не так, как шаблоны, никакой дополнительной генерации кода для каждого нового типа не нужно.

Ты не понял, про что тебе говорят. Шаблоны в C++ сами по себе — ФЯ для управления кодогенерацией (хотя и довольно убогий). И говорить про дополнительную генерацию кода в этом контексте не имеет смысла, так как функциональная программа на С++'ных шаблонах исполняется в момент компиляции и сама генерирует код.

А>Тип может иметь сколь угодно сложную структуру и при этом определяется автоматически.

Мимо кассы

А>Если вы попробуете, что-то подобное реализовать с помощью шаблонов, то получите геморой с огромными описаниями типов с уродливыми <>.

Хе, в том ФЯ, что скрывается в шаблонах С++ значением переменной является тип

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

А>Не говоря уже о том, что шаблоны не позволяют использовать частичные функции, ленивые вычисления, pattern matching для быстрого разбора сложных по структуре типов и т.п.

Вот как раз pattern matching там есть, вместе с ленивыми вычислениями. А что ты имешь в виду под частичными функциями, я просто не в курсе.

А>А если вспомнить как реализованы шаблоны в разных компиляторах...

В современных компиляторах — более-менее нормально, в старых — отвратно.

Здравствуйте, Sergey, Вы писали:

S>Ты не понял, про что тебе говорят. Шаблоны в C++ сами по себе — ФЯ для управления кодогенерацией (хотя и довольно убогий). И говорить про дополнительную генерацию кода в этом контексте не имеет смысла, так как функциональная программа на С++'ных шаблонах исполняется в момент компиляции и сама генерирует код.

Да, не заметил, что речь идет о генерации кода, но тогда собственно о чем речь? Приведите ваши доказательства, что шаблоны ФЯ. На мой взгляд они имеют мало общего. Чтобы была хоть какая-то общая база приведу определение из comp.functional, если не ошибаюсь.

Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.

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

S>Хе, в том ФЯ, что скрывается в шаблонах С++ значением переменной является тип

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

S>Вот как раз pattern matching там есть, вместе с ленивыми вычислениями. А что ты имешь в виду под частичными функциями, я просто не в курсе.

Хотелось бы знать, что вы имеете ввиду под pm и ленивыми вычислениями относительно шаблонов. Частичными функциями (я просто забыл, как они по научному называются) я имеею ввиду возможность оставить функцию недовычисленной, т.е. типа add x y = x + y; part_add x = add x 10;

Здравствуйте, <Аноним>, Вы писали:

А>Может наука ушла вперед, но насколько я помню шаблон по своей сути функция, которой дают названия типов или значения констант и она возвращает текст класса, метода, функции и т.п. Мы не можем комбинировать такие функции, поскольку бессмысленно подставлять текст программы вместо переменной. И в этом заключается главная разница между шаблонами и ФЯ, в ФЯ можно подставить вместо переменной значение другой функции, если угодно можно подставить даже саму эту функцию, заменив ее вызовы на ее тело.
http://www.rsdn.ru/forum/Message.aspx?mid=303515
Практически весь код это функциональная программа на шаблонах. Согласен?

А>Хотелось бы знать, что вы имеете ввиду под pm и ленивыми вычислениями относительно шаблонов. Частичными функциями (я просто забыл, как они по научному называются) я имеею ввиду возможность оставить функцию недовычисленной, т.е. типа add x y = x + y; part_add x = add x 10;

void add(int a, int b)
{
    std::cout<<"a="<<a<<";b="<<b<<";a+b="<<a+b<<"\n";
}
int main()
{
    std::vector<int> vec;
    vec.push_back(1);
    vec.push_back(2);
    vec.push_back(3);
    vec.push_back(4);
    std::for_each(vec.begin(), vec.end(), boost::bind(&add, _1, 10));
}

Ы?

... << RSDN@Home 1.0 beta 6a >>

Здравствуйте, WolfHound, Вы писали:

WH>http://www.rsdn.ru/forum/Message.aspx?mid=303515
WH>Практически весь код это функциональная программа на шаблонах. Согласен?

Согласен. Действительно наука ушла вперед. Только применимость подобных методов под вопросом. Представьте, что константы достаточно
большие, сколько тогда функций придется сгенерировать компилятору? Пусть он поймет, что функции одноразовые, но тогда встает вопрос о понятности такого кода. А если граница интервалов 10000, а самих интервалов всего 10. Из-за ограничений шаблонов вы будете вынуждены хранить массив из 10000 элементов, чтобы иметь возможность создавать классы runtime. А если бы классы создавались по номеру возвращаемому функцией (т.е. создаем класс X<f(n)>)?
Кроме того, я и без шаблонов могу прекрасно писать в функциональном стиле на С++, просто это не имеет никакого смысла, поскольку делать это гораздо сложнее, чем на специализированном языке. Вот для примера, как могла бы выглядеть аналогичная вашей программа на ФЯ. Только вместо класса — функция.

let OptimizedList = [(65,95); (-10,20); (22,35); (60,70);
        (600,700); (630,670); (21,21)];

let Print_func x () = print x;
let Empty_print_func ()  = ();


let sort_func (n1,m1) (n2,m2)  = if (n1 > n2) and (m1 > m2) then 1
                                                else 0;
let sorted_list = sort OptList sort_func;

let optimize_list OptList =
        match OptList with
                (n1,m1)::(n2,m2)::tail => if (m1+1 < n2) or (m2+1 < n1)
                                        then (if (n1 < n2) then n1 else n2, if (m1 > m2) then m1 else m2)::(optimize_list tail)
        |       (n,m)::null => [(n,m)]
        |       null => null;

let PrintTypeList OptList =
        match OptList with
                (n,m) => (print "Interval ", print n, print ",", print m)
        |       null => ();

let CreateFuncByIntervalList OptList Num =
        match OptList with
                (n,m)::tail => if ((Num <= m) and (Num >= n)) then Print_func Num
                                else CreateFuncByIntervalList tail Num
        |       null => Empty_print_func;

let Main () =
        let OptList = optimize_list sorted_list in
        let PrintTypeList OptList in
        let print_1 = CreateFuncByIntervalList OptList 0 in
        let print_2 =  CreateFuncByIntervalList OptList 650 in
        ....
         (print_1 (), print_2 (), ... );

А>>Хотелось бы знать, что вы имеете ввиду под pm и ленивыми вычислениями относительно шаблонов. Частичными функциями (я просто забыл, как они по научному называются) я имеею ввиду возможность оставить функцию недовычисленной, т.е. типа add x y = x + y; part_add x = add x 10;

    std::for_each(vec.begin(), vec.end(), boost::bind(&add, _1, 10));

WH>Ы?

Напишите, что такое bind и _1. Я не знаком с этой библиотекой.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Sergey, Вы писали:

S>>Ты не понял, про что тебе говорят. Шаблоны в C++ сами по себе — ФЯ для управления кодогенерацией (хотя и довольно убогий). И говорить про дополнительную генерацию кода в этом контексте не имеет смысла, так как функциональная программа на С++'ных шаблонах исполняется в момент компиляции и сама генерирует код.

А>Да, не заметил, что речь идет о генерации кода, но тогда собственно о чем речь? Приведите ваши доказательства, что шаблоны ФЯ. На мой взгляд они имеют мало общего. Чтобы была хоть какая-то общая база приведу определение из comp.functional, если не ошибаюсь.

А>Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands.

Именно. При раскрытии шаблонной функции как раз идет проверка совпадений типов и при необходимости — дальнейшее раскрытие шаблонов в нужных "ветках" алгоритмы.

А>The expressions in these language are formed by using functions to combine basic values.

А у нас: values — только для целочисленных констант, но наравне с values добавляются типы.

А>A functional language is a language that supports and encourages programming in a functional style.

Ну это уже масло маслянное

А>Может наука ушла вперед, но насколько я помню шаблон по своей сути функция, которой дают названия типов или значения констант и она возвращает текст класса, метода, функции и т.п.

Угу. Только текст этот в общем случае опять шаблонный будет. Что позволяет писать программы для компилятора.

А>Мы не можем комбинировать такие функции, поскольку бессмысленно подставлять текст программы вместо переменной.

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

А>И в этом заключается главная разница между шаблонами и ФЯ, в ФЯ можно подставить вместо переменной значение другой функции, если угодно можно подставить даже саму эту функцию, заменив ее вызовы на ее тело.

Функция сама является типом и может быть передана в качестве аргумента в другую (шаблонную) функцию.

S>>Хе, в том ФЯ, что скрывается в шаблонах С++ значением переменной является тип

А>Уродливо будет выглядеть вся запись, если в ней несколько типов да еще вложенных.

На вкус и на цвет...

Мне примеры на ocaml'е с непривычки тоже уродливыми кажутся.

А>Я понимаю, что это издержки явного указания типов, но тем не менее.

Это издержки исчисления типов, а вовсе не их избыточного указания.

S>>Вот как раз pattern matching там есть, вместе с ленивыми вычислениями. А что ты имешь в виду под частичными функциями, я просто не в курсе.

А>Хотелось бы знать, что вы имеете ввиду под pm и ленивыми вычислениями относительно шаблонов.

Компилятор не раскрывает шаблоны там, где это не требуется — ограничивается (нестрогой) проверкой синтаксиса.

А>Частичными функциями (я просто забыл, как они по научному называются) я имеею ввиду возможность оставить функцию недовычисленной, т.е. типа add x y = x + y; part_add x = add x 10;

Это уже я не понял. Че оно делает-то и в чем тут "частичность"?

Здравствуйте, Sergey, Вы писали:

Да, спасибо, я уже понял все это на примере приведенном выше. Но у меня есть пара замечаний, которые я привел в том числе и к тому примеру.
Не рекомендовал бы изучать ФП на примере шаблонов. Уж больно там запутанный синтаксис, корявые средства построения программ, да и язык сам по себе уж больно примитивный. Шаблоны по сути довесок к С++ и может сложиться мнение, что ФП в целом малопонятно и нежизнеспособно само по себе. Уж лучше изучить нормальный язык, а потом разбираться с шаблонами, как мне кажется. Кроме того, возникает ощущение, что функциональность шаблонов это side effect, а не главная цель. Хотя я не знаю, какая была мотивация у разработчиков, может и ошибаюсь.

S>На вкус и на цвет...

Мне примеры на ocaml'е с непривычки тоже уродливыми кажутся.
Здесь дело не во внешней красоте, а в том, что для шаблонов нужно огромное количество писанины, в которой еще потом и ошибки искать придется, а я помню насколько понятные бывают сообщения об ошибках, когда речь идет о шаблонах.

S>Это издержки исчисления типов, а вовсе не их избыточного указания.
Ну я всего лишь имел ввиду, что могут быть такие исчисления, где их вообще почти ненужно указывать, все само выводится.

S>Это уже я не понял. Че оно делает-то и в чем тут "частичность"?
По научному curring. Одно из главных отличий от императивных языков, мы можем писать f x1 x2 x3 вместо f(x1,x2,x3), а потом явно указать, например x3 и использовать уже функцию от 2-х аргументов. Крайне полезное свойство.

	От:	Аноним
	Дата:	19.06.03 10:36
	Оценка:

	От:	vgrigor
	Дата:	19.06.03 10:40
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	19.06.03 13:33
Оценка:

От:	Voblin	http://maslyaew.narod.ru/
Дата:	19.06.03 14:32
Оценка:

	От:	PeterZT
	Дата:	19.06.03 17:54
	Оценка:

	От:	Lloyd
	Дата:	20.06.03 08:28
	Оценка:

	От:	WolfHound
	Дата:	22.06.03 06:30
	Оценка:	+2

	От:	Sergey
	Дата:	23.06.03 15:54
	Оценка:

	От:	WolfHound
	Дата:	23.06.03 18:50
	Оценка: