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

DC>ЗЫ Вспомнились языки APL, K, J. Я на них никогда, ничего не писал, и даже не вникал в концепции заложенные в них. Интересно их синтаксис помогает?

Пробовал пару их раз, но вот серьёзно в векторные языки так и не въехал по-моему.
По поводу твоего вопроса: у Иверсона есть тьюринговская лекция под говорящим названием "Notation as a Tool of Thought" (всё ешё лежит у меня в папочке "к прочтению" ).

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

T>>Поскольку любая попытка внести в разговор необходимые для смены точки зрения изменения наталкиваются на "как и что перепроектировать", я заключаю, что вам неинтересна моя точка зрения.
E>Обычно, когда в обсуждении всплывает реальная история и ситуация из нее упрощается до такой степени, чтобы история могла быть изложена неподготовленному слушателю, слушатели делятся на две категории. И первые, которых гораздо больше, говорят, что все изначально нужно было делать не так.
E>Мне не интересно разговаривать про то, что нужно было делать не так с самого начала.

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

T>>Насчёт языков — см. Sing#. Там можно задавать изменения типов объектов после изменения состояния. Например, объект типа Connection перейдёт в объект типа Cinnection:Connected после вызова метода connect. И только тогда станет доступен метод close().

E>Функциональное программирование как-нибудь решает эту проблему?

1. В ФП mailslot не изменится, это точно
2. По сути вопрос сводится (как я понял, к следующему)

Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть! Если не считать queryState = undefined, само собой.

Здравствуйте, thesz, Вы писали:
T>Вот и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например.
И чего там выяснять нужно?
Вполне элементарно пишется из общих соображений.
Особливо удобно было в С++ от borland 5.02, т.к. там допускалось параметризация шаблонов вложенными классами. Я их вовсю тогда применял.
В современных компиляторах так нельзя — стандарт не велит, но сложнее сама конструкция от этого не стала.

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

VE>

VE>Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.

VE>Я правильно понимаю, что если Сергей сейчас не спляшет...

Насколько бы я не ошибался и какие бы глупости я не говорил (намеренно или искрене в это веря), обсуждать имеет смысл мои слова, мои глупости или мои умственные способности. Не знаю, ради чего сюда приплетать половую зрелось и "теплое чувство внутри".

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

E>>Мне не интересно разговаривать про то, что нужно было делать не так с самого начала.

L>Т.е. ты предлагаешь задачу и просишь решить её так же, но функционально, и при этом право интерпретировать слова 'так же' оставляешь за собой?

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

L>Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть!

Если не сложно, тоже самое, только на русском.

Здравствуйте, dr.Chaos, Вы писали:
DC>

DC>struct Foo
DC>{
DC>\\...
DC>std::string name;
DC>\\...
DC>}

DC>struct Bar
DC>{
DC>\\...
DC>long val;
DC>\\...
DC>}
DC>//Есть ассоциативный контейнер:
DC>std::map<std::string,Bar> barMap;
DC>

DC>Всё вроде просто. А теперь усложнение у нас есть список Foo, надо получить список Bar, используя std::transform и boost::bind.
А можно без boost::bind?

typedef std::map<std::string, Bar> bar_map_t;

struct foo2bar_t {
  const Bar operator()(const Foo& f) const {
    return *barMap.find(f.name);
  }
  foo2bar_t(const bar_map_t& barMap) : barMap(barMap) {}
  private:
    const bar_map_t& barMap;
};

template <class IterF, class IterB>
void foo2bar(condt bar_map_t& barMap, IterF first, IterF last, IterB result) {
  std::transform(first, last, result, foo2bar_t(barMap));
}

DC>Ну как монстрик обрисовывается?
Несколько длинно, но вполне шаблонно и читаемо.
В некоторых старых реализациях (borland c++ 5.0.2) структуру foo2bar_t можео было сделать локальной в функции foo2bar — что часто удобно.

DC>В Хаскелле будет что-то вроде (сорри если где слажал):
DC>

DC>let bars = map ((\ arr (_,name,_) -> arr!name ) arr) foos
DC>in 
DC>-- ...
DC>

Может так:

let bars = map (barMap!) . map foo_name
in bars foos

T>>Теперь я жду ответа насчёт нелокальности изменений систем, написанных на ФП.
E>Вы сами уже дали этот ответ:
E>

E>>Но, мой второй пример с импортом данных в РСУБД совершенно безразличен к языку программирования, на котором реализованы компоненты системы.
E>Ну, безразличен. Так он одинаково плохо будет решаться на всём, чём угодно.

А! Понял!

Если это безразлично, на чем делать потому, что будет плохо, то и на ФЯ будет плохо.

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

Возьмите другой пример. Там, где изменения в случае написания системы на ФЯ всё равно приведут к неконтролируемому распространению изменения инвариантов. Типа, "поменяли мы тут, а вылезло вон там".

В принципе, это возможно при изменении широко используемой (библиотечной) функции. Но это решается изменением типа функции, либо копированием функции, изменением типа копии и использовании копии функции. В сравнении с нарушением негласного инварианта в наследнике широкой и глубокой иерархии с количеством методов за сотню штук это всё мелочи жизни.

T>>Если в паре сообщений этого ответа не будет, запишу вас в мелкие трепачи и подожду полового созревания.
T>>Вам интересно почувствовать себя умным. То самое "тёплое приятное чувство внутри".
E>Я вот не понимаю, если вы настолько уверены в собственной правоте, то зачем подобные выпады в сторону собеседника?

Ровно за одним: он должен прекратить говорить явные глупости. Мне это не нравится, я с этим борюсь.

Вот, например, над этим ответом я думал десять минут. Это третья редакция ответа.

T>>Есть у меня обоснованное подозрение, что вы оперируете двумя выводами "трудно в учении => легко в бою" и "легко в учении => трудно в бою", необоснованно их считая их эквивалентными (ну, считая, что так бывает наиболее часто).
E>Да, так бывает наиболее часто.

Это не означает, что это хорошо, и что так бывает всегда.

T>>Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно.
E>Под Apple что понимается: MacOS или iPhone? Про iPhone не могу судить, про MacOS неоднократно слышал от опытных людей, что на MacOS сложность решения нестандартных задач (вроде настроек хитрых устройств) очень резко растет вплоть до полной невозможности. В отличии от Windows или Unix-ов.

Всё вместе.

Это же всё Apple.

Настройки простых устройств — вроде сети, что гораздо важней, потому, что чаще, — настолько просты, что незаметны. Я со своим iMac переезжал четыре раза. Обычно, достаточно его подоткнуть к сети и ты уже в интернете.

А уж про установку/удаление программ вообще нет слов.

T>>Ну, безразличен. Так он одинаково плохо будет решаться на всём, чём угодно.
T>>Что это доказывает?
E>Что на определенном этапе организационные вопросы гораздо важнее технических. И опытный программист должен в поставленных перед ним задачах разделять технические и организационные составляющие.

Отлично.

Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок?

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

L>Итак мы программируем с ФП стиле. Как Haskell помогает нам в этом?

L>1. Очень простое описание ФВП.

L>2. Карринг.

L>3. Секции, инфиксная запись

L>4. Вывод типов или раздельное описание типа и определения.

Чем оно принципиально лучше других ML'ей (ну там OCaml и производный от него F#) или Nemerle?

L>5. Ленивость — ура!

L>Ленивость by default в чистом языке очень сильно помогает писать в ФП стиле. Но это большая (больная) тема.

Возможно. (Не будем вспоминать тред с обсуждением утечек невычисленных цепочек :) К слову, работа с коллекциями в C# по сути тоже ленива по умолчанию.)

Q>>По прежнему не вижу оснований считать синтаксис Хаскеля «помогающим».
L>Теперь ты скажи — а чем же Haskell мешает писать в ФП стиле?

Во-первых, синтаксисом. «Ты не забывай, что у меня в голове опилки и длинные слова меня только огорчают» © (В данном случае не «длинные слова», а «невнятные значки» типа восклицательного знака для индексации, тысячи их). Почти всё перечисленное выше есть в F# и Nemerle, без особой мозголомности (которая визитная карточка Хаскеля).

Во-вторых, не совсем понятно, что там с real world Haskell (выкопанные откуда-то сомнительные success stories как-то не очень убеждают). Большинству не нужно писать компиляторы или «моделировать какую-то там систему знаний с теоретико-множественным подходом»

Автор: thesz
Дата: 10.02.09

. Часто приходится, например, делать клиент-серверные приложения. На сервере общение с БД, на клиенте rich GUI, коммуникация, O/RM, работа с сетью, безопасность, криптография, etc, etc, etc.

Итак, F# и Nemerle: 1) вменяемый синтаксис, 2) интероп с .NET, 3) мультипарадигменность. Пока не вижу никаких убийственных доводов, чтобы предпочесть им Хаскель.

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

Q>Итак, F# и Nemerle: 1) вменяемый синтаксис, 2) интероп с .NET, 3) мультипарадигменность. Пока не вижу никаких убийственных доводов, чтобы предпочесть им Хаскель.
1) так же субъективно, как и нелюбовь к закорючкам
2) видимо как-то к синтаксису относится? я просто всю ветвь перечитал, а не понял, причём тут переход к .NET, F#, Nemerle и выбору языка
3) это плюс или минус?

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

VE>1) так же субъективно, как и нелюбовь к закорючкам

Во-первых, так ли уж субъективна нелюбовь к закорючкам? Мы не можем ответить на этот вопрос, потому что сложно оценить число тех, кто пытался, и не дошёл. Как правило, люди не очень охотно признаются в фейлах (подсознательно опасаясь «Тю-ю-ю, ты не осилил Хаскель? А я думал, ты мужчина!»)

Во-вторых, не то чтобы мне так уж сильно не нравились закорючки :) (Те, кто использовал C++ и TeX, иногда могут испытывать абсолютно иррациональную приязнь к закорючкам.)

VE>2) видимо как-то к синтаксису относится? я просто всю ветвь перечитал, а не понял, причём тут переход к .NET, F#, Nemerle и выбору языка

Эта ветка не только о синтаксисе, но и о серебряных пулях.

VE>3) это плюс или минус?

Это плюс.

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

VE>Распечатать максимальное чётное из 25 рандомных чисел

// C#
Console.WriteLine( randoms.Take(25).Where(Even).Max() );

VE>...

-- Haskell
print.maximum.filter even.take 25.randoms

Глаза неподготовленного читателя привычно сплитуют строку по пробелам («print.maximum.filter», «even.take», «25.randoms»), чуть позже доходит, что сплитовать надо по точкам. Впрочем, такой пакости от Хаскеля стоило ожидать :-b

Сравни с аналогичным кодом на F#. С использованием синтаксиса пайплайна «|>» получается как на Хаскеле, только в прямом порядке, сообразно с представлением течения потока данных (за точность названий методов не ручаюсь):

// F#
randoms |> List.take 25 |> List.filter even |> List.max |> Console.WriteLine

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

ГВ>>Антон, где такая трава растёт?

S>А причем тут трава? Какие-то постулаты вызывают сомнения?

Изначальный:

S>Вообще-то — из определения "императивного программиста".
S>Как только программист перестаёт думать императивными конструкциями, он перестает быть императивным программистом.

Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом? Не забываем, да, что процессы мышления и методы реализации алгоритмов — не одно и то же, хотя и некоторым образом они влияют друг на друга. Отсюда пока получается, что вводный тезис сформулирован через отрицание мнимых характеристик. Крутое колдунство.

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

Q>Чем оно принципиально лучше других ML'ей (ну там OCaml и производный от него F#) или Nemerle?

Немерле и Скала отдельно у них неудобный карринг. Сишный синтаксис тут мешает.

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

ГВ>Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом?
Поясняю еще раз: "императивный программист" — это программист, который мыслит императивными конструкциями. Это определение.

ГВ>Не забываем, да, что процессы мышления и методы реализации алгоритмов — не одно и то же, хотя и некоторым образом они влияют друг на друга.
Это избыточные подробности. Ок, я могу расписать длиннее:
"императивное программирование" — применение императивных конструкций для записи программы
"императивный программист" — программист, у которого набор техник программирования ограничен императивными конструкциями.

Никакого колдунства.

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

T>We all yet to see your article named "Обобщённые алгебраические типы, как шаг к зависимым типам данных", ага.

У тебя проблемы с общением на русском?
Что до обоебщенных АлгТД, то меня вполне устраивают не обобщенные в купе с ООП.

T>Поскольку пересесть с Nemerle на Хаскель не будет составлять труда, по-твоему.

Это значительно проще чем пересесть с Явы на Хаскель.

VD>>В общем, сложность имеет тенденцию складываться (если не умножаться). И всегда проще освоить язык в котором минимум изменений нежели совершенно другой.

T>Но и дольше будет путь достижения того же уровня владения предметом, здесь — функциональным программированием.
T>Значительно дольше.

С чего бы это? К тому же, как показывает практика, многие кто пытался освоить совершенно незнакомый ФЯ попросту бросали это занятие еще на первых шагах.

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

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

Видимо я плохо изъясняюсь на русском. Скажу еще раз, последний. Проще осваивать ФП на языке синтаксис которого близок к синтаксису знакомого языка. При этом на освоение синтаксиса (и больше части семантики) тратить время не прийдется. Стало быть изучение будет связано с меньшим количеством непонимания (ломки мозгов) и пройдет проще.

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

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

E>...Сильно сомневаюсь, что ФП здесь имеет какое-то преимущество перед ИП, и что стиль программирование здесь вообще имеет хоть какое-то значение.

Скажем так. Если программа написана грамотно и при ее реализации использовался преимущественно ФП, то внести изменение будет проще. ФП действительно упрощает отладку. Но накосячить можно на чем угодно. Если в коде бардак, то действительно никакие ФП не помогут.

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

Q>Сравни с аналогичным кодом на F#. С использованием синтаксиса пайплайна «|>» получается как на Хаскеле, только в прямом порядке, сообразно с представлением течения потока данных (за точность названий методов не ручаюсь):
Q>

Q>// F#
Q>randoms |> List.take 25 |> List.filter even |> List.max |> Console.WriteLine
Q>

Не не не, давай-ка на C#, для F# что-нибудь другое найти можно
А то это, конечно, хорошо, когда на каждое упрощение находится какой-то язык, где это же самое сделано сравнимо просто, но я же на всех этих языках одновременно писать не буду, верно? Так что дайте мне тот, где всё либо так же, либо лучше.
Да и мне этот код потом читать, зачем мне обратный порядок слов? Я бы вообще написал даже так:

-- Взять 20 рандомных, оставить чётные, распечатать максимальный
take 20 . randoms >>> filter even >>> print.maximum

А про "глаза непривычного читателя" опустим, так как незнакомых с языком сажать за него никто не будет. Что за упор на то, чтобы и баран смог прочитать и написать? (Хотя, кстати, показывал код другу, который в программировании не разбирается вообще, ну так он слева направо без всяких разделений пробелами прочёл и спросил, правильно ли он понял? )

Я, конечно, не буду говорить, что сам бы везде предпочёл Хаскель, но именно из-за отсутствия .NET или каких-либо библиотек, и в некоторой неуверенности, что если мне, например, придётся делать кастомный контрол, да руками его рисовать, что я вообще осилю это на каком-нибудь wxHaskell, а вот на C#/C++ — точно сделаю. Т.е. банально проверенные миллионами (уж тем более мной лично) технологии как-то надёжнее, вдруг какая библиотека на Haskell развалится в середине проекта, а спросить почти некого, а по .NET'у тому же пол интернета форумов, кто-нибудь да сталкивался, и проект по крайней мере не встанет.
А чисто как язык он очень удобен, но в двух примерах этого не покажешь (тем более если убедиться хотят в обратном), это понимание само приходит.

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

T>Если это безразлично, на чем делать потому, что будет плохо, то и на ФЯ будет плохо.

T>Ну, нет. Опровергается легко. Берем кодогенерацию и получается умеренно хорошо в любом случае. Это и вы признали тоже, не так уж и далеко выше. По крайней мере, не отбросили сразу и совсем.

Ладно, я понял. Если существует возможность изменить ситуацию, изменив подход в принципе (т.е. переделав все в основе), то такой пример не катит. Контрагрументы о том, что изменить подход не получится в расчет не идут.

T>Возьмите другой пример. Там, где изменения в случае написания системы на ФЯ всё равно приведут к неконтролируемому распространению изменения инвариантов. Типа, "поменяли мы тут, а вылезло вон там".

Был у меня когда-то такой случай. На web-форме запрашивался пароль пользователя, затем строился хеш пароля и хэш сохранялся в куках. Через какое-то время выяснилось, что используемая хэш-функция генерирует символы, которые не могут сохраняться в куках без специального экранирования.

Пусть будет такая ситуация: система на ФЯ, использует функцию хеширования A, результатом которой является набор символов из диапазона [0..255]. Результат ее работы начали сохранять в текстовом файле, забыв, что символы из диапазона [0..31] в текстовый файл записывать нельзя. На первом этапе тестирования и функционирования системы ошибок не было выявлено, т.к. не попадалось случаев, когда A генерировала бы символ из [0..31]. Затем A заменили на B. Через какое-то время сломалась функция загрузки данных из файла. Или даже так: сначала использовали A и запись в двоичный файл (в котором ограничений не было), потом двоичный файл заменили текстовым, затем A заменили на B.

Дополнение: если бы все программы писали идеальные программисты, то подобная ситуация и в любом нормальном императивном языке исключается на раз.

T>В принципе, это возможно при изменении широко используемой (библиотечной) функции. Но это решается изменением типа функции, либо копированием функции, изменением типа копии и использовании копии функции. В сравнении с нарушением негласного инварианта в наследнике широкой и глубокой иерархии с количеством методов за сотню штук это всё мелочи жизни.

Наличие больших и реально работающих ОО программ показывает, что все эти страшилки несколько преувеличены.

T>Ровно за одним: он должен прекратить говорить явные глупости. Мне это не нравится, я с этим борюсь.

Не интересная форма борьбы.

T>Вот, например, над этим ответом я думал десять минут. Это третья редакция ответа.

Вы быстры, у меня обычно уходит раза в 1.5-3 больше времени.