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

А>Да, спасибо, я уже понял все это на примере приведенном выше. Но у меня есть пара замечаний, которые я привел в том числе и к тому примеру.
А>Не рекомендовал бы изучать ФП на примере шаблонов. Уж больно там запутанный синтаксис, корявые средства построения программ, да и язык сам по себе уж больно примитивный.

Язык действительно примитивный (в части ФЯ), синтаксис, на мой взгляд, вполне приемлемый, а вот насчет корявых средств построения программ — это ты о чем вообще? Язык — он и есть средство построения программ, так?

А>Шаблоны по сути довесок к С++ и может сложиться мнение, что ФП в целом малопонятно и нежизнеспособно само по себе.

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

А>Кроме того, возникает ощущение, что функциональность шаблонов это side effect, а не главная цель. Хотя я не знаю, какая была мотивация у разработчиков, может и ошибаюсь.

Мне тоже кажется, что ФЯ в шаблонах самозародился

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

Ну это у тебя по VC 6 или более ранним, наверное, воспоминания. А насчет огромного количества писанины — никто ж не запрещает библиотеками пользоваться. Кроме того, длинные-предлинные типы, часто возникающие при работе с шаблонами, обычно нигде в тексте программы не фигурируют и нужны только компилятору

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

А чем отличается от такого:

void f(int a, float b, long c)
{
   ...
}

void f(int a, long c)
{
   f(a, 1.5, c);
}

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

boost::bind(f, _1, 1.5, _2);  // возвращает функцию от двух переменных (a, b), вызывающую f(a, 1.5, b)

Можно даже аргументы при необходимости переставить:

boost::bind(f, _2, 1.5, _1);  // возвращает функцию от двух переменных (a, b), вызывающую f(b, 1.5, a)

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

S>Вот несчет применимости чистых функциональных языков в качестве полноценных средств коммерческого программирования у меня, например, сильные сомнения...
Чистых может быть. Но call-by-value языки я думаю задвинут С++ по быстродействию при символьных вычислениях. Во всяком случае в сегодняшнем мире джав и си шарпов смешно говорить о каком то существенном преимуществе императивных языков. Естественно, драйвер на них писать не стоит, но делать то, что делают на Джаве, скажем, вполне реально. А то что они широко не используются в разработке, так на то я думаю есть объективные причины, типа консервативности тех, кто мог бы изменить ситуацию. Если бы Микрософт вдруг решил сделать ставку на ML, все виндовые программисты завтра бы писали на ML.

S>А чем отличается от такого:

S>

S>void f(int a, float b, long c)
S>{
S>   ...
S>}

S>void f(int a, long c)
S>{
S>   f(a, 1.5, c);
S>}

S>

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

S>

S>boost::bind(f, _1, 1.5, _2);  // возвращает функцию от двух переменных (a, b), вызывающую f(a, 1.5, b)
S>

S>Можно даже аргументы при необходимости переставить:

S>

S>boost::bind(f, _2, 1.5, _1);  // возвращает функцию от двух переменных (a, b), вызывающую f(b, 1.5, a)
S>

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

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

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

Все смелости не хватало прочесть ветку.

А не бесполезны ли виртуальные классы?
Заметим, что в примере они используются в локальных методах. Т.е. как одноразовое средство. А в этом случае можно обойтись просто двумя классами, ведь мы знаем их конкретные типы. Если же использовать долгоживущие виртуальные классы, то скорее всего у разработчика появится жедание оформить их "официально", чтобы не писать параметром методу нечно вроде (IFruit, IGoods, IMoneraryUnit, IReusabe, IStorable...). Я это к чему — использование mixin есть четкая последовательная процедура. Дело не в C++, а в том, что примесь проектируется с таким учетом, что просто добавляет функциональности, а не пытается обмануть кого-то полиморфным поведением.

На самом-то деле все упирается в контекст использования человеком понятий. Это только кажется, что систему с PlasticApple можно так легко разрулить. Под одним и тем же Plastic человеком используются десятки разных классов.
Просто это все разные Plastic, разные "млекопитающее" и все остальное.

Все просто. Пластмасса — значит чаще всего плавает, мягкая, горит (даже тут оговорки). Если анализировать ассоциации, т.е. как раз то, что "можно с этим делать", то вот:

1. Клавиатура пластмассовая (вроде) — почему-то не приходит в голову, что она плавает.
2. Начинаешь смотреть вокруг и кажется, что ни одна из пластмассовых вещей не плавает,
хотя опыт показывает обратное — еще как плавает, если не налить в корпус воды (как в случае с пластиковой
бутылкой).
3. Про мягкую тоже поторопились.
4. Быть может, неотемлемое свойство пластмассы, которое можно как-то использовать, — это ее долговечность?
Нет. Полезная долговечность не заключается в том, но на мусорке она не будет гнить тысячу лет. Надо, чтоб
родукт не ломался, тут-то и облом.
5. Пожалуй так, пластмассовый — значит дешевое говно, которое быстро и внезапно ломается. Чинить — дохлый номер.
6. А как же пластиковые лодки и яхты?
7. Тогда скажем так — пластмассовый, это состоящий из длинных повторяющихся цепочек углеводородов с небольшим числом
примесей, которые придают "этому" желаемые свойства. Это уже из области бесполезных книжных определений. Или нет?
8. Обратимся к спецу по "пластмассовый" — о говорит: "Какой еще пластмассовый! Ты мне сделай, чтоб по марке
выводился справочник производителей и цены. А порошек мы на глаз кладем. От температуры зависит." Так от
температуры или на глаз? "Уйди на фиг."
9. Пластмассовый, значит дешевый, поддельный, яркий, красивый, но непременно ядовитый и несьедобный,
противоположность всему живому, что бы там ни говорили про органические соединения.

Это говорит о том, что классификация, обычно вводимая человеком — просто чущь собачья. Именно поэтому любой простой вопрос к опытному прикладному специалисту по чему_бы_там_ни_было выявляет у него на лбу складки тяжелого размышления : "Как бы ему, дурню, рассказать, чтобы коротенько, часа на два, и не запутать вконец". А Быстрые Ответы даются на корректно и четко поставленные узкие вопросы. Потому и код шаблонов такой. Поэтому единственный путь сокрашения издержек, размера кода, времени размышления и т.д. — выявление, документирование, унификация и стандартизация всех неявных предположений о процессе планирования, работе компилятора, работе с типами и т.д.

После тысяч провальных и почти не провальных проектов по всему миру такие предположения уточняются, объединяются, и согласно этому выпускается большая и сложная библиотека. Организованная весьма однообразно, на простом, не допускающем разночтений языке, с подробной документацией на каждый "пук", для идиотов. Это то, чем занимается Microsoft, за что его все любят, и то, за что ненавидят.

Язык, это не только код, но и средство модификации этого кода. Любой программист отдаст мизинец за среду, в которой 1.4 Mb исходников ворочаются, словно 1.4 Kb. И не суть важно что это — autocomletiotion или метаклассы с контекстами.

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