Re[10]: Почему ФЯ трудны для императивщиков - Философия программирования

Здравствуйте, Курилка, Вы писали:
К>Не согласен. Как раз в том и дело, что функциональщики в первую очередь рассмативают функциональные вещи, т.к. к этом больше приковано их внимание, а писать "хэллоу ворлд" им неинтересно.
Вопрос интересный.
Давайте рассмотрим Hello World с точки зрения обучения, а не с точки зрения программирования. Вот для чего эта программа?
Если отвлечься от "здравствуйте", эта программа запускается, выводит в консоль некоторый текст, и завершается. Во времена, когда С был новым крутым языком, основное, что делали программы — это запускались, выводили в консоль какой-то текст, и закрывались, вернув в ОС код завершения. Классическая hello world является замечательной иллюстрацией, которая показывает начинающим программерам насколько просто писать такие продвинутые приложения на новом языке.

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

Если начинать рассказывать об ФП с точки зрения высшей математики, то такой курс прекрасно отсеет неспособных к абстрактному мышлению. Вместе с теми, кому интересно некотрое практическое применение. Вот обучить человека Екселю очень-очень просто. Там никого не смущает двусмысленность оператора =. Главное — мы ставим простую иллюстративную задачу (например, Здравствуй, Налоговый Инспектор) и показываем, как она решается. Я бы вообще преподавал FP на основе Екселя. Показывая, как можно решить понятную неспециалисту задачу.
Книжки по императивному программированию для детей сначала преодолевают некоторый барьер в мышлении человека, обучая его концепции "ящичков с цифрами" и "стрелочек, показывающих на ящичек". Уже потом переходят к переменным, членам класса, областям видимости и т.п.
Я полагаю, если ФП представлять в виде "ячеек с формулами", как в Excel, то всё будет намного проще объяснить. Конечно, довольно быстро придется отказаться от спредшитов, потому что они всё таки чрезмерно убоги. Но в качестве основы для формирования правильных представлений это, имхо, намного более перспективно, чем все эти упражнения по выводу чисел Фибоначчи и факториалов. Как только начинается пример "допустим, нам нужно вычислить первые сто чисел фибоначчи", возникает искушение сказать "вам нужно — вы и вычисляйте. А я хочу заставить трёхмерный кубик крутиться или написать программу, которая прикольно искажает голос". Да всё, что угодно, только пусть это будет реалистичный пример. По крайней мере, настолько же реалистичный, как Hello World. Не в том смысле, что нужно сразу MineSweeper написать. Но функции, которые берут вход неизвестно откуда и отдают его неизвестно куда, сллишком далеки от народа. Hello World можно прямо запустить и увидеть замечательный эффект; многие реальные программы устроены вполне аналогичным образом.

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

1.2.0 alpha rev. 655

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

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

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

FDS>>Да нет, просто они не рассказывают некоторых вещей или рассказывают их непоследовательно, или плохо подают материал (например, только на примерах)

VD>На само деле и то, и другое. Это комплексная проблема.
VD>Люди не понимаю аудиторию к которой обращаются, люди не умеют выражать свои мысли просто и последовательно. В общем, люди просто не умеют писать.

лично я с удовольствием бы изучил функциональное программирование в сравнении с императивным. Чтобы все понятия ФП раскрывались так: вот на Си(C++,C#,Java etc.) такую -то задачу решают обычно так-то, а с использованием ФП ее можно решить вот так (и примеры исходных кодов на си и на функ.языке). Или: вот на Си очень часто хочется сделать что-то, но средства языка этого не позволяют (пример!) А на ФП это делается запросто (куча примеров!)
Все примеры должны быть из реальных проектов а не надуманные.
И так пройтись по всем понятиям функциональной парадигмы (причем желательно, чтобы давались примеры на нескольких функциональных языках сразу, чтобы каждый императивщик мог выбрать себе что-то по душе). ну а дальше люди уже будут знать где и что искать для более глубокого изучения.

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

Это все мифы

M>Бог его знает, какое мышление у человека. То ли это машина Тьюринга, то ли решающую роль в нем играет квантовая когерентность, то ли еще что. Но, как я понял, FDSC, утверждал только, что человеку проще описать последовательность действий, приводящих к решению задачи в терминах процедур и функций, чнежели в терминах лямбда-исчисления. Доказать строго это вряд ли возможно, но косвенное свидетельстватаковы: (1) название топика [как я понял, у апологетов ФЯ не возникает проблем с императивными языками, поэтому программирование на ФЯ представляется более сложным]

У большинства россиян с русским языком проблем не возникает, а вот на английском говорят далеко не все и с трудом. Следует ли из этого, что русский язык более естественный и простой для человека. Вряд ли. Так же и с императивными языками. У большинства (если не 100%)программистов императивный язык программирования был первым языком, который он изучил и использовал на практике. В психологии же известен факт, что первое мнение на какую-либо тему производит на человека на порядок большее воздействие и противоречащие первому впечатлению последующие мнения воспринимаются им с большим трудом.

(3) житейский опыт [объяснения, как приготовить гороховый суп, как пройти на пл. Незалежностi, как играть на гитаре и т. д. все-таки императивны]

Покажите пальцем, где там императивность. Например, есть рецепт приготовления супа. Кажется, что это последовательность указаний — типа императивный алгоритм. Но на самом деле, чтобы приготовить суп нужно выполнить большое количество других действий, которые явно в рецепте не указаны. Там не сказано, что нужно сделать, чтобы включить плиту, что значит помешивать ложкой, как выглядит кипение и т.п. Процесс реализации рецепта выглядит в итоге следующим образом — человеку необходимо выполнить шаг рецепта, это задает цель. Далее он пытается ее достичь, конкретизируя ее в более мелкие подцели, которые тоже разбиваются на подцели и т.д. Я бы не стал сравнивать этот процесс с выполнением императивной программы.

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

К>Хотел поделиться статьёй, где автор рассматривает (на примере Haskell), почему же путь "обычных" программеров в функциональное программирование несколько сложен. Ответ, наверное, довольно заметно пересекается с тем, что тут уже довольно много говорил VladD2: функциональщики, как правило, довольно сильно отходят от тех материй, которые занимают умы императивщиков, и занимаются всякими монадами и прочими "хитрыми" вещами. В результате чего для какого-нибудь сишника учебник по хаскелю или мл получается очень сложным, т.к. строится с точки зрения человека, мыслящего уже категориями хаскеля или мл.

У меня есть сомнение в основной предпосылке (что императивщикам плохо дается именно ФП).
По крайней мере, хотелось бы уточнить, что именно в ФП плохо дается императивщикам.

Насколько я понимаю, собственно ФП основывается на принципе "референциальной прозрачности" ("прозрачности по ссылкам").
В учебниках ФП этот принцип подается в виде "подстановочной" вычислительной модели (substitution model), в противоположность трассировке (прокрутке?) для "обычного" императивного программирования.
Как, ИМХО, справедливо указывают авторы известных учебников (Абельсон и Сассман, Бауэр и Гооз, и т.д.) подстановочная модель проще.
Можно было бы предположить, что какая-то трудность заключается в невозможности использовать привычную конструкцию цикла (из-за ее несовместимости с принципом "прозрачности по ссылкам").
Но, ИМХО, первое же знакомство с хвостовой рекурсией устраняет эту трудность.
Значит, дело не в самом базовом принципе.
А в чем? Может быть, в следствиях?
Из принципа "прозрачности по ссылкам" прямоо вытекает ряд приятных следствий: возможность (автоматического) распараллеливания программ и использования "ленивых" вычислений.
Может быть, их трудно понять?
Кто-нибудь конкретно считает, что это трудно?
Единственным минусом как основного принципа, так и этих следствий может быть некоторая усложненность системы программирования и рантайма по сравнению с простыми ИЯ, вроде Си или Оберона. Возможно, программисту становится несколько труднее предсказать, во что "выльется" его код.
Кого-то это отпугнет (например, меня, т.к. я пишу по "голому железу", и мне надо выжимать из процессора максимум), а кого-то и нет.
Вопрос становится все запутаннее.
Может быть, дело в каких-то иных следствиях? И есть ли они?
Да, какие-то есть.
Заглянем в раздел 3.1.2. ("Преимущества присваивания") книги Абельсона и Сассмана.
Там достаточно ясно сказано, что и (внимание!) у присваивания (т.е. у конструкции не совместимой с ФП) есть свои преимущества.
На простом примере демонстрируется, что чистое ФП плохо совместимо с модульностью и ООП.
Без присваиваний, оказывается, это не дается.
Не надо только говорить, что объекты реализуются в ФЯ с помощью "окружения" (closure = enclosuring enviroment).
Суть в том, что требуется присваивание, а substitution model замещается существенно более сложной (и в принципе не функциональной) enviroment model.
Т.е. в чистом виде ФП применимо в сравнительно узкой области, а за ее пределами разговоры о "простоте подстановочной модели" — это разговоры в пользу бедных.
Вот и приходится все время подменять тему обсуждения: вместо ФП мы уже говорим о ФЯ, а вместо ФЯ — о "отдельных функциональных конструкциях" в императивных языках, а заодно приписываем какую-то "функциональность" конструкциям, с ФП (прозрачностью по ссылкам) не связанным: паттерн-матчингу, разным видам типизации, делегатам и т.д.
Короче, как это все странно выглядит.
И сдается мне, дело не в тупых императивщиках, а в "консерватории" (т.е. в ФП) что-то не так.

Конечно, все высказанное — это субъективный взгляд на тему топика.
Хотелось бы выслушать людей, сведущих в ФП гораздо более меня.
Но только не на уровне трагических вздохов о снижении среднего уровня мастерства, а на уровне принципиальных вопросов.

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

L>Можно чуть больше конкретики? Каких именно вещей не рассказывают (т.е. может быть они что то должны рассказать перед чем то, а они этого не делают)? Плохо подают материал — как надо хорошо?
Добрый день, товарищи!
Считайте это пост воплем души ТУПОГО императивщика.
Периодически читаю топики подобные этому и статьи разных популяризаторов ФП. И у меня
все время возникает вопрос а как это можно реально применить? Примеры a->b->c->d->....->z
уже сидят в печенках. А слабо заменить это реальными goods,sales,employers и.т.д. И показать
преимущества ФП на РЕАЛЬНЫХ(многопотчных, с гуеей, с БД, с удаленными вызовами) задачах. А самое главное как можно выполнить декомпозицию такой реальной задачи (НЕ МАТЕМАТИЧЕСКОЙ!!!!) в терминах, абстракциях и паттернах ФП. И наглядно показать где здесь преимущества.
Проблемы всех этих статей в том что они сразу начинают грузить читателя терминологией
(а в худшем случае вышкой). Мне лично кажется что танцевать нужно от конкретной задачи.
По поводу терминиологии в ФП это еще одна проблемма, такого обилия терминов (которые имеет математические корни и поэтому слабо соотносятся с реальностью) при описании задачи в терминах ИП+ООП нет. В минимальном случае достаточно нарисовать диаграмму классов(понятий) и описать последовательность действий(в тех или иных случаях) своими словами (список прецедентов).
У меня как у ТУПОГО императивщика есть предчувствие что в процессе реализации такой задачи на ФЯ
Вы упретесь в эти самые побочные эффекты (посмотрел я тут на цирк с состояниями...).
ИЯ+ООП предлагают простой и понятный способ декомпозции задачи на:
1. Ряд последовательных шагов, объединенных в методы, которые вызывают другие методы.
2. Иерархию сущностей, хранящих данных + ассоциированные с ними методы.
ИЯ+процедуры тоже вроде бы все понятно, по крайней мере не возникает вопросов с порядком действий и хранением состояний.
Все просто понятно и замечатльно, и соответствует тому что мы видим в окружающем мире (та же
последовательнть действий+иерархия сущностей(понятий)).
ФП насколько я понял, предлагает использовать функции, которые вызывают другие функций и принимают в качестве аргументов третью (или данные), но чем это отличается от методов вызывающих другие методы?. А как организованы данные? А что делать с вещами, состояние которых в принципе надо хранить (сессии, соединения)? А как в терминах ФП разложить конкретную реальную задачу?
Вот они вопросы на которые ФП-шники почему-то не дают конкретных ответов, а вместо этого начинаются лекции про монады и т.п.. Потом прибегают другие ФП-шники и они благополучно начинают
общаться между собой.
Про книги и их авторов я вообще молчу — никакой обратной связи.

P.S. Уважаемые функциональщики я никого из Вас не хочу обидеть той глупостью которую я здесь
возможно написал, но хотелось бы увидеть реальные и конкретные примеры из которых видно
преимущество ФЯ над ИЯ (вышку не предлагать!!!).
P.P.S. Очень хочется разобраться в ФП с целью расширения кругозора (хотя его реального применения
в качестве альтернативы ИП я не вижу)...

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

FDS>Короче говоря, дело даже не в том, что кто-то что-то плохо понимает. Просто книги так написаны, что по ним нельзя научится программировать и нужно всё делать с нуля, как это было и для процедурного программирования. Причём дело не в мышлении, а именно в понимании и в правильном применении средств языка: т.е. я могу спокойно что-то "замыслить"

S>>Если начинать рассказывать об ФП с точки зрения высшей математики, то такой курс прекрасно отсеет неспособных к абстрактному мышлению.

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

Читаю сейчас по паре страниц в день Функциональное программирование на языке Haskell. Вою волком. У мнея математика закончилась лет пять тому назад, не успев начаться

Лямбда исчисление я ни сном ни духом

А там — только оно. Ыыыыы.

Один из примеров — представление чисел не помню кем не помню зачем

Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

А я еще до монад не добрался...

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

Следует отметить, что в рамках этой упрощённой интерпретации пока не видно инкапсуляции, с которой начался разговор. Помимо описанной здесь "структуры" состояний, нужно ещё задать императивную модель вычислений над ними. В ленивом языке, к которым относится Хаскелл нельзя написать последовательность вычислений в виде несвязанных инструкций

(положи 2 в а)
(вынь состояние из a, прибавь к нему 1, положи обратно)

поскольку порядок вычислений здесь не определен. В посте выше использовалось let-связывание, однако его тоже можно загнать внутрь монады. Фактически в Хаскелле используется перегрузка того, что в С-подобных языках используют в качестве разделителя инструкций, ";"

(положи 2 в а) ;
  (вынь состояние из a, прибавь к нему 1, положи обратно)

Только вместо ";" (которая, к сожалению, занята для других целей) пишут (>>=)

(положи 2 в а) >>=
  (вынь состояние из a, прибавь к нему 1, положи обратно)

Оператор (>>=) связывает два вычисления, позволяя неявно протаскивать всё что угодно из первого вычисления во второе (его поэтому и произносят как bind). Для монады состояния это будет состояние. Собственно реализация оператора (>>=) и есть главное в задании монады. Как его опишешь — такая монада и получится.

BZ>>новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

ANS>а как это выяснили?

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

зато могу сослаться на "Стратегии гениев" Дилтса: создали машинку для ориентации в пространстве слепых, действует с помощтю радиолокации наподобие летучей мыши. отражённый от окружающих объектов инфразвук преобразуется в слышимые звуки. маленькие дети — года два-три наверно — быстро эту штуку освоили и научились с её помощью быстро бегать по лестницам, к примеру. чем старше детям её давали, тем сложнее им было научиться ориентироваться в пространстве по звукам, а не изображениям, перестроить своё мышление

другой пример — знаете, что человек в силу устройства глаза воспринимает мир перевёрнутым? нацепили на глаза человеку очки, переворачивающие изображение обратно. первые две недели было трудно, затем привык и перестал замечать. после снятия две недели првиыкал обратно

третий — у человека нарушен вестибулярный аппарат. ему делают специальные очки с "уровнем". через некоторое время он настолько првиыкает по этому уровнб ориентироваться, что спокойно ходит прямо — автоматчисеки, интуитивно, без всяких сознатедльбных усилий

ну а то, что иностранные языки лучше учить в дошкольном возрасте — уж все знают

вот ещё — Милтон Эриксон, ставший впоследствии одним из известнейших в мире психологов, в 19 лет переболел полиомиелитм и не мог даже встать с кровати. он наблюдал за своей годовалой сестрёнкой — смотрел, как она училась ходить. повторил то же самое и научился — повторно — ходить сам. он и впоследствии в своей работе уконцентрирвоался на установлении контакта с подсознанием человека и обучении именно подсознания напрямую. проще говоря, гипнозе

Хотел поделиться статьёй, где автор рассматривает (на примере Haskell), почему же путь "обычных" программеров в функциональное программирование несколько сложен. Ответ, наверное, довольно заметно пересекается с тем, что тут уже довольно много говорил VladD2: функциональщики, как правило, довольно сильно отходят от тех материй, которые занимают умы императивщиков, и занимаются всякими монадами и прочими "хитрыми" вещами. В результате чего для какого-нибудь сишника учебник по хаскелю или мл получается очень сложным, т.к. строится с точки зрения человека, мыслящего уже категориями хаскеля или мл.

GlebZ,

GZ>Вообще это большая проблема учебников написанных математиками. Очень мало хороших учебников которые можно читать. Такое впечатление, что математики искренне верят что из формулы сразу понятен алгоритм действий.

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

1. Трёхтомник Фихтенгольца по математическому анализу — супер-пупер-мега-турбо! Благодаря этой книжке многие студенты если не полюбили матанализ, то по крайней мере не бросаются от него как чёрт от ладана.

2. Колмогоров, Фомин "Элементы теории функций и функционального анализа". Функциональный анализ и топология — это из разряда высшего пилотажа. Но как доступно эти вещи изложены в этой книжке! Лично я купил эту книжку просто на память, потому что её просто интересно листать, хотя функанализ мне сейчас не нужен.

3. Фоменко Ф.Т. "Наглядная геометрия и топология. Математические образы в реальном мире." — книга того самого Фоменко, ах какие там клёвые картинки! Их интересно разглядывать даже не врубаясь в топологию, но когда начинаешь понимать математическую подоплёку под этими картинками, то испытываешь просто восторг!

4. Н. Кристофидес "Теория графов. Алгоритмический подход" — немного устарела, но книжка замечательная.

5. Кормен, Ривест, Лейзерсон "Алгоритмы: построение и анализ" — никакие беллетристы и переливатели из пустого в порожнее не сравнятся с ними!

6. Пенроуз, "Тени разума. В поисках науки о сознании". Мегарулез! Я подозреваю, что (судя по отзывам) остальные книги этого автора тоже такого же высокого качества, так что они зашедулены с самым высоким приоритетом на свободное время, которого пока нет

Так что я не согласен с тобой, дескать математики не умеют писать книги. Умеют! Но разумеется далеко не все, и процент посредственных книжек примерно такой же как и везде. Вдобавок написать хорошую книгу по математике намного труднее, потому что излагать "в апельсинах" суть проблемы P=NP намного труднее, чем излагать как "типа братки ведут канкретные базары с типа банкиром".

А по Хаскелю когда-нибудь появятся достойные книжки (я верю во всяком случае). Собственно, есть места из различных статей, которые хоть сейчас распечатывай и на стенку вешай — особенно удачные аналогии или красивые решения. Нужно просто подождать, пока Муза навестит хорошего преподавателя по Хаскелю

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

Не соглашусь с тобой. Когда я изучал OOP — мне попалась одна книжка. Что за автор и что за книжка уже за давностью не помню. Автор точно помню русский. Там весь ООП был описан на одном (или двух) проектах. По крайней мере один я помню. Там описывался океан. Описывались объекты акулы, описывались жертвы и т.д. Вполне конкретный проект, с вполне конкретными решениями. Именно такие полные решения (а не фичи) мне показались интересными. Они мне дали не знания, а навыки композиции/декомпозиции объектного программирования. Это мне очень сильно помогло. Следующее решение я уже строил в чистом ООП. Я не удивлюсь, что паттерны GOF не были такими же популярными, если бы в первой части на конкретном решении не объяснялось применение в реальном(почти) проекте.
Если бы мне попалась книга с конкретным решением конкретного (почти реального) проекта, если бы там была информация о том как правильно применять ту или иную фичу функционального программирования, то эта книга была бы более полезна как учебник, чем полное описание данных фич. Существует достаточно много книг с рекомендациями для императивного программирования. Для функционального

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

M>>Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

К>Т.е. у тебя появляется убеждённость, что ты его всегда знал чтоли?

Нет, он забывает, зачем начал читать книгу

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

M>Читаю сейчас по паре страниц в день Функциональное программирование на языке Haskell. Вою волком. У мнея математика закончилась лет пять тому назад, не успев начаться

Лямбда исчисление я ни сном ни духом

А там — только оно. Ыыыыы.

M>Один из примеров — представление чисел не помню кем не помню зачем

Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

А я еще до монад не добрался...

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

L>"Как люди узнали, что думают головой?".
Немного жестоко, но...

Науку изучения головного мозга сильно продвинула русско-японская война

,
а именно трёхлинейная винтовка, впервые массово применённая на этой войне

Пули из этой винтовки пробивали голову насквозь, по прямой,
принося относительно незначительные повреждения головному мозгу.
И стало возможно изучить отклонения в поведении и особенности мышления человека,
у которого отсутствует часть мозга.
Раненых солдат было полно, повреждения у всех были разные — материал для изучения..
Ну и так далее. То есть думаем не просто головой, а даже какой частью и о чём.

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

NK>Но в чем, всеже, прелесть Функционального Программирования???

NK>А пример с сортировкой, который приводится (во многих статьях о ФП) в качестве превосходства над ИП, наверно, не удачен.
NK>Это просто другая реализация алгоритма, которую можно легко использовать и в ИП (может не во всех, конечно).
NK>Например Perl:

NK>

NK>sub qsort
NK>{
NK>  my $x = shift or return;
NK>  my @sx = @_;
NK>  return qsort( grep { $_<$x } @sx ), $x, qsort( grep { $_>=$x } @sx );
NK>}
NK>

NK>Или Perl это тоже ФЯ?

Ага. Perl — смешанный язык.

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

Скажем, характерная для целой группы ФЯ система типов Хиндли-Милнера подталкивает нас к тому, чтобы писать все функции максимально обобщёнными. (Фактически для этого и делать ничего не надо

, само получается). Или, в качестве другого примера — рекурсия, как один из основных инструментов работы. Рекурсивные типы данных прячут рекурсию внутрь определения типа, а сопоставление с образцом позволяет подобного рода типы разбирать.

То есть дизайн ФЯ направлен на удобство программирования функциями.

А так, большинство языков полны по Тьюрингу, и то что на одном написано, может быть на другом перевыражено.

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

GZ>Вобщем на обложке нужно написать — "Только для математиков" или "Нематиматикам читать запрещено" или "Теперь вы сможете сформулировать почему вы не любите функц. программирование".

Можно так "Экстремальное математическое порно для тех про проводит вечера в одиночестве".

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

FDS>>Да нет, просто они не рассказывают некоторых вещей или рассказывают их непоследовательно, или плохо подают материал (например, только на примерах)

L>Это интересная для меня тема, прошу не воспринимать как наезд.

L>Можно чуть больше конкретики? Каких именно вещей не рассказывают (т.е. может быть они что то должны рассказать перед чем то, а они этого не делают)? Плохо подают материал — как надо хорошо?

Не, уже забыл конкретику — я с лета ничем ФП-шным не занимался. А тогда даже на SICP постоянно ругался, потому что не так рассказывали, как надо. Да и это всё равно сложно объяснить, я, например, не видел ни одного хорошего учебника по C++, ну вот не видел...

, никто не даёт общего описания что и как надо делать. В ФП то же можно встретить какие-то частности, но общий подход к конструированию то же не излагается. Тот же SICP вообще жутко размытая книга, ну, правда, она совсем для начинающих, но читать её очень трудно из-за этой размытости. Примеры там слишком лёгкие: я сам некоторые смог написать на Scheme даже более сложные (но по тому же направлению) не заглядывая в учебник, а вот когда задумался над чем-то своим, оказалось, что просто не могу придумать как это нормально оформить. Вообще, очень мало рассказано именно, так сказать, не про сами стандартные приёмы, а про способы их применения.
В документации по Nemerle я вообще не способен разобраться. Я так и не понял, какие возможности есть у макросредств этого языка и где это описано. Хотя текста, опять же, много. Ну и т.п.

Я вообще не видел литературы, где нормально описываются значение и применение терминов типа "сопоставление с образцом" (SICP с метаязыковыми средствами не подойдёт) или, скажем, монад. Может кините ссылочку?

Короче говоря, дело даже не в том, что кто-то что-то плохо понимает. Просто книги так написаны, что по ним нельзя научится программировать и нужно всё делать с нуля, как это было и для процедурного программирования. Причём дело не в мышлении, а именно в понимании и в правильном применении средств языка: т.е. я могу спокойно что-то "замыслить"

D>Оператор (>>=) связывает два вычисления, позволяя неявно протаскивать всё что угодно из первого вычисления во второе (его поэтому и произносят как bind).

Я к выделенному придерусь (хотя в целом пост хороший, и я надеюсь, поможет народу разобраться).
bind, насколько я знаю, называется так по другой причине.

Конструкция

let x=expression1 in expression2

связывает (binds) переменную x с результатом вычисления выражения expression1 в контексте выражения expression2.

Конструкция

computation1 >>= \x -> computation2

, которая под сахаром выглядит как

do x <- computation1
   computation2

связывает (binds) переменную x с результатом вычисления computation1 в контексте computation2.

Из-за этой аналогии let и bind последний оператор так и называется.

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

F>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.
F>Вот пара примеров оттуда

F>

F>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
F>

Сложные типы (например, типы функций ну очень высокого порядка) всегда выглядят страшно, это не синтаксическая сложность, а семантическая, синтаксис лишь отражает структуру типа. Решается, как и в C/C++, введением синонимов. Типы вида int (*(*(*)())[3])() нравятся больше?

F>Имхо даже для исследовательских целей это явный перебор.
В принципе, начинать изучать ФП с сайта Олега Киселева — это перебор

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

F>Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"?

но и не настолько простой как, например, unlambda.

F>Лисп в виде scheme'ы уже, Nemerle не прелагать, пока мне рано. Купил книжку по хаскелю, теоретическая часть благодаря фак. "К" МИФИ прошла на ура, но часть, относящаяяся собственно к языку имхо не очень понятна.
F>Есть ли язык, имеющий столь же простой синтаксис, как, например, pascal/modula2? Но функциональный.

Можно попробовать Caml Light.

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

M>Один из примеров — представление чисел не помню кем не помню зачем

Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

А я еще до монад не добрался...

ИМХО целевой аудиторией этой книжки являются аспиранты в CS. Как учебник по Хаскеллу для программистов она явно не удалась.

Лямбда исчисление я ни сном ни духом

А там — только оно. Ыыыыы.
Мне кажется надо отдавать себе отчёт в том, что эта книга не ставит своей целью научить программировать на хаскеле, а донести что такое ФП на примере хаскеля, дать ообщую картину, исторический контекст. Я вот после неё писать на хаскеле не научился, но автор и соавторы работают над новой книгой, которая как раз имеет более практический уклон. Черновики можно получить, если написать ему (он в обмен на прочтение хочет замечания и здоровую критику). Так, что ты можешь реально повлиять на то, какой будет следующая книга о хаскеле на русском языке.
В его блоге есть все необходимые координаты для связи.

M>Один из примеров — представление чисел не помню кем не помню зачем

Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

А я еще до монад не добрался...
Нумералы Черча? Я тоже долго вкурить не мог.

Для общего развития, чтобы комфортнее было всякие умные блоги и статьи читать

BTW: У меня как раз песня играет, характеризующая моё состояние при первых прочтениях

now playing: Future Prophecies — Mentally Destroyed

frogkiller,

F>А если накладывать ограничения на типы (а без этого, я так понимаю, практически не бывает), то объявление разрастётся на несколько строк.
F>По-моему, это сильно затрудняет написание больших программ.

На мой взгляд, не стоит лезть в дебри не имея основ.

Примерно то же самое, что и изучать арифметику с решения десятой проблемы Гильберта,
Или там теорию сложности с PCP теоремы,
Или учиться водить с гонки Формула 1...

Вот пример довольно общих объявлений типов:

concat :: (Foldable t) => t [a] -> [a]
and :: (Foldable t) => t Bool -> Bool
or :: (Foldable t) => t Bool -> Bool 
any :: (Foldable t) => (a -> Bool) -> t a -> Bool
all :: (Foldable t) => (a -> Bool) -> t a -> Bool
sum :: (Foldable t, Num a) => t a -> a
product :: (Foldable t, Num a) => t a -> a
maximum :: (Foldable t, Ord a) => t a -> a 
minimum :: (Foldable t, Ord a) => t a -> a
notElem :: (Foldable t, Eq a) => a -> t a -> Bool
find :: (Foldable t) => (a -> Bool) -> t a -> Maybe a

где Foldable, Ord, Num и Eq — это классы типов. Скажем для concat тип можно прочитать так: "Из того что t является инстансом класса Foldable следует, что concat имеет тип concat :: t [a] -> [a]".

Список — это инстанс Foldable. А инстансами Foldable можно сделать что угодно, и если выписывать сигнатуру напрямую, то может получиться сколь угодно громоздкая запись. Вот меня и занимает вопрос: какой смысл усложнять себе жизнь, а потом, извини за мой корейский, рвать волосы на заднице?

Если же просто взять самый простой случай, когда t==список, то имеем concat :: [a]] -> [a] — самый обычный тип, берётся список списков чего-нибудь, а возвращается просто список.

-- a = список интов
Prelude> concat [ [ [1], [2] ] , [ [3], [4] ] ]
  [[1],[2],[3],[4]]
    
-- a = строка
Prelude> concat ["a", "b", "c", "d"]
  "abcd"
    
-- а = инт
Prelude> concat [[1], [2], [3], [4]]
  [1,2,3,4]

Совсем не страшно, если начинать с последних строк, а о Foldable забыть до поры до времени.

Курилка,

FDS>>...Думаю, у всех по началу с процедурным программированием тоже возникали трудности, хотя мышление у человека такое, что можешь хоть прямо сесть и писать процедурами прямо из головы.

К>Согласно каким фактам ты утверждаешь выделенное?
К>То, что 99% программных решений сделаны императивно, не говорит о том, что само мышление человека обязательно императивно, имхо.

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

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

BZ>такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

D>А Вы с Купаевым вообще-то общаетесь?

Я 5 февраля послал. Может не дошло? Хотя я могу быть к этому тексту небеспристрастен — именно на нём я в своё время врубился в ФП.

Общаемся. Вот он про горные лыжи купленные жене рассказывал недвано.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Ты мозги то не пудри. Это ведь был всего лишь пример эмуляции перегрузки. В С++ перегрузка выражается просто и естественно. Никакой лишней косвенности там не будет.
Человек жаловался на синтаксис конкретно этой строчки:
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)

VD>Ты мозги то не пудри
Ну да, ну да. Что ты там говорил про Зверька? "Вот научится вести себя на людях...". Успехов, дорогой модератор.

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

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

Инкапсуляция — недоопределенное понятие. Инкапсуляция — это сокрытие деталей реализации, но грань между деталями реализации и важными архитектурными решениями расплывчата. Если, например, где-то глубоко в недрах библиотеки, которую планируется использовать в программе под Unix, вызываются функции Win32, это никак нельзя назвать деталью реализации (хотя в публичном интерфейсе зависимость внутренностей от Win32 никак не отражается).

В ФП наличие побочных эффектов точно так же нельзя назвать деталью реализации. Если язык не отличает чистые выражения от выражений с побочными эффектами, автоматически возникает требование фиксированного порядка вычислений.

В чистом языке можно выразить ввод-вывод, присваивания и другие побочные эффекты, но выражения с побочными эффектами будут иметь другой тип.
Оператор присваивания, например, может иметь тип (Memory, Address, Value) -> (Memory).
Вычисление с состоянием может иметь тип (State, Argument) -> (State, Result).
У такого подхода есть плюсы: зависимости между выражениями выражены явно, поэтому независимые выражения можно вычислять в каком угодно порядке. Это не теоретизирование, данный факт используется в 1) STM для Haskell, для которого важно отсутствие побочных эффектов в транзакции 2) Data.Bytestring, например, использует loop fusion — техника оптимизации циклов с помощью эквивалентных преобразований выражений (несколько проходов по строке склеивается в один и т.д.)
Минусы: состояние передавать явно руками неудобно, плюс для эффективной реализации необходима гарантия, что программа имеет доступ к единственной копии состояния, тогда функцию f : State -> State можно реализовать как прямую запись в память. Обе проблемы решаются при помощи функций высшего порядка, протаскивающих состояние за кулисами, некоторой порции синтаксического сахара и мощной системы типов.

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

AVC>Я "зацеплюсь" за этот пункт, наверное, далеко не самый важный.
AVC>Когда смотришь (как я) на ФП со стороны, идея "прозрачности по ссылкам" и ее потенциальных выгод усваивается очень легко.
AVC>А вот как может быть "чисто функциональным" аналог оператора ++i, как раз и непонятно.

Я, честно говоря, не совсем внимательно следил за тем, как вы пришли к оператору инкремента. Но я хочу показать пример, как код, похожий внешне на императивный, может быть чисто функциональным. Пример будет на С++, монад не будет (чудес тоже). Итак, представим, что у нас есть некий игрушечный процессор, имеющий один регистр, и поддерживающий операции:
inc/dec — инкремент/декремент регистра
set — установка нового значения регистра
rand — запись в регистр псевдо-случайного значения
print — печать текущего значения в регистре

#include <iostream>
#include <sstream>

using namespace std;

template <class Machine>
void imperative_program(Machine machine)
{
    cout << machine
    // here's imperative program for our VM
        .inc()
        .inc()        
        .print() // outputs 2

        .dec()        
        .print() // outputs 1
     
        .inc()
        .inc()
        .inc()
        .print() // outputs 4

        .set(75)
        .print() // outputs 75

        .rand()
        .print() // outputs random number
        .rand()
        .print() // outputs another random number

   /////////////////////////////////////////
        .output;
}

string to_string(int x)
{
    ostringstream oss;
    oss << x;
    return oss.str();
}

int rand(int seed)
{
    const int a = 1664525;
    const int b = 1013467;
    const int m = 65536;
    return (a * seed + b) % m;
}


// Implementation with destructive updates

struct StatefulMachine
{
    int counter;
    string output;

    StatefulMachine () : counter(0) {}

    StatefulMachine& inc() { ++counter; return *this; }
    StatefulMachine& dec() { --counter; return *this; }
    StatefulMachine& set(int x) { counter=x; return *this; }
    StatefulMachine& rand() { counter=::rand(counter); return *this; }
    

    StatefulMachine& print()
    {
        output += to_string(counter) + "\n";
        return *this;
    }
};


// Purely functional implementation

struct StatelessMachine
{
    const int counter;
    const string output;

    StatelessMachine(int a_counter=0, string a_output="") :
        counter(a_counter),
        output(a_output) {}

    StatelessMachine inc() const { return StatelessMachine(counter+1, output); }
    StatelessMachine dec() const { return StatelessMachine(counter-1, output); }
    StatelessMachine set(int x) const { return StatelessMachine(x, output); }
    StatelessMachine rand() const  { return StatelessMachine(::rand(counter), output); }
    StatelessMachine print() const { return StatelessMachine(counter, 
                                                             output+to_string(counter)+"\n"); }
};

int main()
{ 
    imperative_program(StatefulMachine());
    imperative_program(StatelessMachine());

    return 0;
}

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

F>Если бы я случайно и написал такое на С/С++, непременно бы переделал, скорее всего, это какая-то ошибка проектирования.

Ну, в C нечасто используют функции высшего порядка, но синтаксис для типов функций, принимающих указатели на функции и возвращающих указатели на функции гораздо страшнее, ИМХО.

В том примере ничего страшного не было. a -> b — это тип функции, принимающей a и возвращающей b.
Благодаря каррингу функции с несколькими аргументами выражаются как функции одного аргумента, возвращающие другую функцию.

Итак, для того примера имеем:
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
Функия возвращает t, принимает один аргумент типа
((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t
Это тоже функция, возвращает тоже t, принимает 2 аргумента:
2) t3 -> t1 -> t2 -> t3 — функция, на C ее тип выглядит как t3 (*)(t3,t1,t2)
1) (a -> b -> c) -> (a -> b) -> a -> c
функция, принимает 3 аргумента
1) a -> b -> c == c (*) (a,b)
2) a -> b — тривиально
3) a
и возвращает c

Лямбда исчисление я ни сном ни духом

А там — только оно. Ыыыыы.

M>Один из примеров — представление чисел не помню кем не помню зачем

Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

А я еще до монад не добрался...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

D>>скажем так: редкая птица долетит...

AVC>А потом все еще делают такие озабоченные лица и начинают разводить руками и спрашивать друг у друга: с чего это вдруг императивщикам трудно дается ФП?!

AVC>И потом, злые языки говорят, что монады (IO, списки и т.п.) — скрытый императив; но он, дескать, любит, чтобы его называли чистым ФП.
AVC>Вот и разберись...

Я попробую доступно разобрать

В объяснении будет использоваться псевдо-Хаскел. Все детали существенно упрощены.

В каком виде нам нужно состояние ?
Наверное в таком, чтобы можно было делать что-то наподобие такого

value <- getState   
putState (value + 1)   
value <- getState   
return value

Где функции getState и setState получают значение какой-то переменной и изменяют ее значение соответсвенно.

Представим нашу гипотетическую переменную как пару (переменная, значение)

Следовательно функции будут выглядеть следующим образом.

-- Ну понятно, да, плюем на переменную, нас интересует только состояние
getState (variable, state) = (_, state)

-- А здесь передаем пару, новое состояние, и возвращаем пару с той же переменной, но с новым состоянием.
putState (variable, state) newState = (variable, newState)

теперь попробуем переписать наш код с использованием функций

-- допустим это наша переменная а, со значением 2.
state = ("a",2)
-- получаем значение нашего состояние, то есть выполняем строчку
-- value <- getState   
let (initialVariable, initialState) = get state in
-- здесь мы изменяем значение нашей переменной на значение initialState + 1, то бишь 2+1 = 3
-- то есть выполняем строчку putState (value + 1)   
    let (initialVariable, changedState) = put (initialVariable, initialState) initialState + 1 in
-- это мы уже проходили, получаем измененное значение.
        let (initialVariable, finalState) = get (initialVariable, changedState) in
--     и возвращаем результат
           return finalState

Вуаля. Вот пример состояния в чисто функциональном стиле.
По сути ничего страшного. У нас есть пара (переменная, значение) на get мы возвращаем значение из этой пары, на set он же put — возвращаем новую пару (переменная, новое значение).
Синтаксис с let выражениями выглядит жутковато, и поэтому этот велосипед обсыпали сахаром и обозвали State.

Теперь по поводу IO. Там все не просто, а очень просто.

value <- readLine   
putState (value + 1)   
value <- getState   
writeLine value

Надеюсь идея понятна ?

Грубо говоря та же пара (variable, state)
только внутри variable находится служебная информация, типа хендлов открытых файлов, и тому подобных вещей, необходимых для реализации ввода-вывода. А в качестве state — строки, которые будут вводиться — выводиться, а также порядок их следования. Потому что очистить экран и написать строку, или написать строку и очистить экран это разные вещи

Такое ощущение что я что-то забыл. А ну да. Есть еще такая штука как Maybe.
Допустим появилось желание описать вычисления, каждое из которых может закончиться неудачей, причем если произошла неудача, то значение всего выражения считается тоже неудачей. Аналоги...
Ну допустим несколько транзакций в БД. Мы открываем их по очереди, и если где-то внутри произойдет ошибка, то все транзакции откатятся обратно.

Как это можно оформить. Опять же решение в лоб.

public enum TransctionState
{
    Success,
    Error
}
public class TransationResult
{
    public object Result;
    public TransationState State;
}
public class TransactionalCalculation
{
    public TransactionResult Combine(TransactionCalculation calculation)
    {
   // Выполняем свои дела
     TransactionResult res = this.Execute();
     // Если все завершилось успешно
                if(res.State == TransactionState.Success)
        //          вызываем следующее вычисление
                    res = calculation.Execute();
        return res;
    }
    // А это метод который будет выполняться в каждой транзакции.
    public TransactionResult Execute;
    // Предположим, что он инициализируется в конструкторе.
    public TransactionCalculation(MethodToExecute )
    {
        Execute = MethodToExecute;
    }
    
}

public void Main()
{
    // создаем три транзакции
    TransactionCalculation t1  = new TransactionCalculaction(doSomething);
    TransactionCalculation t2  = new TransactionCalculaction(doSomethingElse);
    TransactionCalculation t3  = new TransactionCalculaction(doYetAnotherThing);
    
  // комбинируем их в одну транзакцию.
    TransactionResult = t1.Combine(t2.Combine(t3));

 //Без метода Combine код выглядел бы примерно так
    TransactionResult res = t1.Execute()
    if(res == TransactionState.Success)
    {
        res = t2.Execute();
        if(res == TransactionState.Success)
        {
            res = t3.Execute();
        }
    }
}

[Сверхупрощение = ON]
Теперь прикинем, что же есть общего у State, IO, и TransactionCalculation ?
Ответ. У них есть методы
put и get
Для State это прямо таки put & get
Для IO это writeLine & readLine
Для TransactionCalculaction aka Maybe это Combine & Execute

Естественно прогарммитсы были бы не программисты, если бы не выделили такие повторяющиеся паттерны в интерфейс.

ICalculation
{
    put
    get
}

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

[Сверхупрощение = OFF]

Вопросы, пожелания, корректировки, и прочая приветсвуются.

Скорее всего в посте куча несоответсвий, и возможно даже ошибок. Но я старался изложить идею максимально просто, без привлечения жуткого слова на М.

... << RSDN@Home 1.2.0 alpha rev. 676>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, palm mute, Вы писали:

PM>>http://www.classes.cs.uchicago.edu/archive/2007/winter/51091-1/papers/Murthy-popl07.pdf

ANS>Прикольно. В качестве выгоды от функциональных языков приводится пример с заменой XSL на ML. Мне это кажется... э-э... алогичным.

Где здесь нарушение логики? Идея, которую я уже несколько раз встречал: сделать в Enterprise всю высокоуровневую склейку разнородных компонент на каком-либо функциональном языке. С одной стороны ФЯ для этого достаточно гибкие, с другой — идея функций как чёрных ящиков и отсутствие изменяемых состояний позволяет легко абстрагироваться от внутренней машинерии склеиваемых компонентов.

Ещё в ту же копилку:
Вроде где-то уже пробегала ссылка на статью Эрика Мейера.

Abstract

Programmers in the real world wrestle every day to overcome
the impedance mismatch between relational data, objects, and
XML. For the past ten years we have been working on solving
this problem by applying principles from functional programming,
in particular monads and comprehensions. By viewing
data as monads and formulating queries as comprehensions,
it becomes possible to unify the three data models and their
corresponding programming languages instead of considering
each as a separate special case.

To bring these theoretical ideas within the reach of mainstream
programmers, we have worked tirelessly on transferring
functional programming technology from pure Haskell, via Cw
to the upcoming versions of C# 3.0 and Visual Basic 9 and the
LINQ framework. Functional programming has finally reached
the masses, except that it is called Visual Basic instead of Lisp,
ML, or Haskell!

W>Науку изучения головного мозга сильно продвинула русско-японская война

,

и последующие тоже

почитайте "человек. который принял свою жену за шляпу" — это прост чума

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

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

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

BZ>>ну а то, что иностранные языки лучше учить в дошкольном возрасте — уж все знают

Q>Миф об обучаемости детей сильно преувеличен. Взрослый способен учиться намного быстрее и эффективнее. У него накоплен опыт обучения и пользуясь им, он способен тратить свои ресурсы более эффективно. Не говоря уже о том, что багаж знаний ему тоже очень сильно помогает.
Q>Взрослым людям вбили в голову, что иностранные языки трудно выучить. Дети об этом не знают, поэтому просто учаться, неторопливо, но постоянно. Тем более, что им и знать по сравнению со взрослым человеком почти ничего не надо. Грехем, кстати, упомянул об этом в своей очредной статье — у взрослых стандарты гораздо выше, поэтому им труднее начать что-то делать с 0.

в том-то и фишка, что детей меньше шаблонов мышления, меньше требования к себе, больше любознательность

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

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

"я знаю, что ничего не знаю"

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

VD>>Говорить о постепенном изучении просто не приходится.

F>А вот с этим не согласен. Со школы и института я привык к классическому подходу при обучении: от простого к сложному. Вся наша система образования построена на этом, а не только императивный стиль программирования. И переучиваться обучаться (на что я потратил 20 с лишним лет) мне кажется слишком высокой платой.

Речь не об этом. Речь о том, что ты не можешь изучать ФП на основе Хаскеля или Схемы инкрементально. Тебе надо снановиться на нулевой уровень и с него потихоничку шагать. Причем постоянно тебе будет мешать твой опыт в императивных языках.

VD>>Вот скажем с восприятем C#-кода у тебя большие проблемы?

F>Э... смотря какого. Я не так хорошо знаю шарп как плюсы, и его возможности в части ФП также мне ясны не на 100%. Речь ведь идёт, я так понимаю, не об использовании .Net'овских классов.

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

Так вот, это я все говорю к тому. что как раз Nemerle может серьезно облегчить вхождение в ФП. Ведь ты уже сможешь на нем программировать. ФП-фичи при этом можно будет изучать так же постепенно рассматривая их как некий сахар для упрошения некоторых приемов программирования.

... << RSDN@Home 1.2.0 alpha rev. 637>>

AVC,

AVC>А если серьезно, то как обойтись без goto мы знаем. Да и теорема Боэма-Джакопини есть.
AVC>А вот как обойтись вообще без побочных эффектов (ввод/вывод не в счет) — мы просто не знаем...

Вообще-то есть мнение, что

"State" is just a convenient concept for describing the set of parameters to a function. In imperative languages, that "state" is spread willy-nilly all around the program, and the history of the state has to be explicitly maintained. In a functional language, it is well specified.

Для ввода-вывода нужно лишь сохранение порядка вызова функций. Сохранение порядка — отнюдь не чуждая для ФП вещь, в частности то, что сформированный список будет [1,2,3], а не [3,2,1] и не [3,1,2] — вполне здравая и вполне формализуемая весчь. С вычислениями чуть сложнее, но из них тоже можно формировать последовательности и потом выполнять в заданной последовательности — продолжения, потоки, монады, или просто энергичная семантика — есть из чего выбрать.

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

A>ЗЫ: на правах оффтопика
A>Все таки мир у нас императивен.

Мир пассивен. Это воля императивна. А разум — декларативен.

A>Когда нам надо сесть в машину мы выполняем метод "открыть" над объектом
A>"машина", а не делаем копию машины рядом, но уже с открытой дверью...

А мы пишем функцию

открыть :: нечтоСРучкой a => a -> a
открыть = потянутьНаСебя . ручкуВверх

и пускай компилятор думает, сколько и чего там нужно копировать, и нужно ли вообще

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

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

FDS>Да нет, просто они не рассказывают некоторых вещей или рассказывают их непоследовательно, или плохо подают материал (например, только на примерах)

На само деле и то, и другое. Это комплексная проблема.
Люди не понимаю аудиторию к которой обращаются, люди не умеют выражать свои мысли просто и последовательно. В общем, люди просто не умеют писать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

M>>Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

К>Т.е. у тебя появляется убеждённость, что ты его всегда знал чтоли?

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

Особенно когда добрался до типов, классов типов и их экземпляров

Каждый раз пытаюсь мучительно вспомнить/заново понять, что это такое, не вдаряясь в рассуждения о том, насколько это правильно реализовано с точки зрения лямбда-исчисления

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

M>Бог его знает, какое мышление у человека. То ли это машина Тьюринга, то ли решающую роль в нем играет квантовая когерентность, то ли еще что. Но, как я понял, FDSC, утверждал только, что человеку проще описать последовательность действий, приводящих к решению задачи в терминах процедур и функций, чнежели в терминах лямбда-исчисления.

Как-то очень давно мне приходилось работать с людьми, для которых было проще создать массив байт, высчитать в нём все нужные смещения и каждый раз делать преобразования к тем типам, которые фактически хранились в этом массиве, например, к double. Это было проще, чем просто объявить структуру и работать непосредственно с ней. Объяснить что это сложнее и можно всё сделать не так у меня не получалось, т.к. те люди просто не хотели понять, не верили, что тоже самое может за тебя сделать компилятор.

Так и с ФЯ. Нужно просто понять что такое указатель на функцию. Всё. Этого понятия достаточно, чтобы оперируя им можно было понять всё остальное. А примеров указателей на функцию и императивщиков предостаточно. Взять хотя бы ту же виртуальную функцию.

Те же кто понимает что это такое, но не понимает ФЯ, либо всё же не понимают что такое указатель на функцию, либо им просто никто не объяснил ФП, либо, скорее всего как те ребята с массивами, они просто этого не хотят из-за собственной костности мышления и упёртости.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

VD>Можно так "Экстремальное математическое порно для тех про проводит вечера в одиночестве".

Да самое интересное, что книжка хорошая. Я собственно ее и купил из-за математики. Но из обложки можно сделать вывод, что книга является учебником по функциональному языку Haskell. А это уже сильно огорчает.

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

LCR>Неправда. Книг написанных математиками, которые читаются легко и приятно навалом, и хорошую книгу можно найти для многих областей. Вот несколько примеров:

Твои утверждения не противоречат исходным. "Можно найти" не означает "нет такой проблемы".
Проблема очевидно есть. Спорить с этим можно, но не разумно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>Вот я и поспешил сделать замечание, что доля хороших писателей-математиков среди писателей-математиков (имхо) такая же как и доля хороших писателей среди писателей вообще. Разумеется у меня нет расчётов, статистики и прочее, сужу просто по тому количеству книг, о которых лично у меня хорошие воспоминания

Многие "писатели вообще" специально учились писать. Или совршенствуют свое мастерсво в этом вопросе. Плю их мозг не обработан катком мат.формальностей.

Популярная статья написанная математиком явление довольно редкое.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>>>Все таки мир у нас императивен.

D>>Мир пассивен. Это воля императивна. А разум — декларативен.
A>+1 (это твое? или кто из древних?

)

Писал сам.

Думаю, что в одно ухо мне шептал дух Ницше, а в другое — Шопенгауэра

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

D>Вот у меня возник вопрос — императивную модель вычислений мы, понятно, сконструировать можем. А прологовскую, с бэктрэкингом? Я уверен, что можно, но
явных ссылок что-то не нашёл.

Самый простой пример — монада List, она же list comprehension. Есть более сложные логические монады в исполнении Олега Киселева и Кена Шана, но я с ними не разбирался:
http://okmij.org/ftp/papers/LogicT.pdf

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

FDS>>А в инете она есть где-нибудь?
EC>Одно время автор рассылал её всем желающим, пока не издали, сейчас нет — обязательства перед издательством.
EC>На самом деле книга достойная, но название не соответствует содержанию.
EC>Лучше попроси его выслать черновики новой книги — она более практически направленная.
Саму книгу, вроде нигде не видел. А вот лекции автора — здесь.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

BZ>ну а то, что иностранные языки лучше учить в дошкольном возрасте — уж все знают

Миф об обучаемости детей сильно преувеличен. Взрослый способен учиться намного быстрее и эффективнее. У него накоплен опыт обучения и пользуясь им, он способен тратить свои ресурсы более эффективно. Не говоря уже о том, что багаж знаний ему тоже очень сильно помогает.
Взрослым людям вбили в голову, что иностранные языки трудно выучить. Дети об этом не знают, поэтому просто учаться, неторопливо, но постоянно. Тем более, что им и знать по сравнению со взрослым человеком почти ничего не надо. Грехем, кстати, упомянул об этом в своей очредной статье — у взрослых стандарты гораздо выше, поэтому им труднее начать что-то делать с 0.

AVC wrote:

> Во-первых, требуется много копий StatelessMachine, чтобы исполнить
> императивную программу.
Заблуждение. Здесь описывается только что делать, а не как делать. Умный компилятор может просечь, что старая машина
нигде не используется и записать состояние новой в то же место "физической памяти".
По сути такая оптимизация даёт представление о сути оптимизации хвостовой рекурсии.

> Причем не совсем ясно, для чего такие ухищрения, ведь "новая" машина
> полностью заслоняет собой "старую", и, следовательно, "старая" машина
> уже не может быть использована.
В данном примере заслоняет. В принципе — не заслоняет. Можно хранить ссылки на промежуточные машины. Получается, что вся
история процесса изменения состояния — односвязный список значений. Последовательно идущие элементы списка могут
"схлопываться" для оптимизации, если они больше нигде не используются.
Это даёт очень интересный результат — при отладке "правильной" (чистой) функциональной программы можно не только делать
"step forward", но и "step backward"!

> Во-вторых, множественные StatelessMachine исполняются все же на
> одной-единственной (в данном случае) машине с состояниями.
Ты имеешь в виду машину тьюринга (или CPU)?

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

> А главное, в третьих, возникает впечатление (возможно, ошибочное), что
> машину без состояния надо каждый раз порождать целиком.
> А если там будет не один регистр?
Будут порождаться только изменённые регистры. Короче, это уже больше относится к оптимизации. Главное — сама идея такой
структуры вычислений

> Все это, конечно, могут быть просто мои глупости.
> Возможно, завтра, уже без стресса, посмотрю спокойно и все пойму.

Posted via RSDN NNTP Server 2.1 beta

BZ>>>новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

ANS>>а как это выяснили?

L>Меня всегда восхищают подобные вопросы. Напоминают малыша Стругацких: "Как люди узнали, что думают головой?".

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

ps: философия минус программирование

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

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

L>>"Как люди узнали, что думают головой?".
W>Немного жестоко, но...

ЗдОрово. Методы изучения человека в общем то с тех пор не сильно изменились.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

BZ>вот только не ставьте мне смайлики, а попробуйте ответить. вопрос весьма серьёзный. для философов это — основной вопрос философии. для психологов это вопрос о происхождении сознания. когда оно появилось, каким образом, что это вообще такое?

Пинг...

С практической позиции, такая постановка вопроса никуда не годится.
Оставьте заботы о том, "что" такое сознание "вообще" другим психологам и философам.
Ибо у любого вопроса есть причина, мотив, ради которого он задаётся. Обобщённый вопрос задаётся для того, чтобы загрузить ум.
Точный же вопрос — это половина ответа, и большую роль здесь как раз играет осознанный мотив.

Понг!

Кто задаёт вопрос о природе сознания?
И кстати, зачем?

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

GZ>Если с ООП еще можно сделать фигню которая будет работать, пуская проблемы и возникнут потом. С функциональщиной — это не пройдет. Рамки слишком жесткие. И как результат — человек бросают в бассейн, и он учится плавать согласно самоучителю. Многие тонут. Не смог сразу перестроить мозги — твое место на берегу. Лучшие — начинают плавать. Поэтому — мир программистов на функциональных языках — не такой уж большой.

На самом деле с ФП все точно так же как с ООП. Только надо выбирать язык который не отличается радикализмом. Например, точно не стоит начинать изучать ФП с использованием Хаскеля, Схемы или скажем Эрланга (т.е. языков близких чисто функциональным или ими и являющиеся).

Несмотря на то, что это может показаться предвзятым, на мой взгляд для императивщика надо начинать знакомство с ФП Nemerle (на крайня пойдут C# и даже С++, но тут могжет возникнуть недоумение, так как красотой ФП в них не отличается). Это позволит начать новый проект или подключиться к текущему и потихоничку перейти к изучению возможностей функционального стиля (ФС).

Если начитаться "умных" книг по ФП, то с огромной вероятностью будет перегрев мозка и снос крыши. По этому, лучше воспринимать ФС как набор фич расширяющих твои возможности. Те же лямбды и замыкания надо рассматривать не как что-то супер умное и математическое, а как возможность передать участок кода в другую фукнцию. Пусть даже ты будешь думать об этом как о макроподстановке. И не в коем случае не надо насиловать мозг изучением теоретических вещей вроде лямбда-исчислений Чёрча (достаточно знать, что такие есть).

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Hi Left2

BZ>>>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.
GZ>>Вааще-то — на запах. Проверено.
L>Слышал что запах титьки сильно похож на запах околоплодных вод. Потому это вообще самое знакомое для новорожденного Ну а сосать он учится тоже ещё в утробе — палец сосёт, тренирует мышцы Грамотно всё у природы придумано, блин

По этому поводу в фидошной эхе ru.linux говорят следующее: "единственный интуитивно понятный интерфейс — это материнская титька".

--
С Уважением

Posted via RSDN NNTP Server 2.0

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

FDS>Особенно это касается макросов. Всё, что я видел, лишь небольшие примочки, конечно облегчающие кодирование, но принципиально ничего нового не приносящие. Но ведь они не только на это способны?

Макросы.. Макросы хорошо учить по книжкам по лиспу. Допустим On Lisp. или Practical Common Lisp
Но как обычно есть нюансы. Лисповые макросы не совсем те, что в Немерле, да и сам Лисп далеко не всем нравится, да и времени такое обучение займет больше.. Такие вот пироги..

К чему выбирать такой сложный путь? В книгах по Лиспу собран опыт нескольких десятилетий применения макросов. Описаны ситуации когда макросы можно применять, а когда можно вполне обойтись и без них. Также как и грабли, которые могуть потенциально возникнуть при использовании макросов. Хотя опять же, абсолтно не факт что подоные грабил будут при использовании Немерловых макросов. Но на наддом этапе полноценного качественного описания немерловой макросистемы просто нет. поэтому для себя я вырал такую вот стратегию. Подглядывать откуда растут ноги у немерловых макросов, сравнивать различия и думать, почему это было сделано именно так..

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

XC>лично я с удовольствием бы изучил функциональное программирование в сравнении с императивным. Чтобы все понятия ФП раскрывались так: вот на Си(C++,C#,Java etc.) такую -то задачу решают обычно так-то, а с использованием ФП ее можно решить вот так (и примеры исходных кодов на си и на функ.языке). Или: вот на Си очень часто хочется сделать что-то, но средства языка этого не позволяют (пример!) А на ФП это делается запросто (куча примеров!)
XC>Все примеры должны быть из реальных проектов а не надуманные.
XC>И так пройтись по всем понятиям функциональной парадигмы (причем желательно, чтобы давались примеры на нескольких функциональных языках сразу, чтобы каждый императивщик мог выбрать себе что-то по душе). ну а дальше люди уже будут знать где и что искать для более глубокого изучения.

Если бы всё было так просто! Учебные примерчики (типа факториала, быстрой сортировки, чисел Фибоначчи) несложно реализавать и на императивных языках. А задачи более объёмные (типа построения компиллятора) отпугнут большую часть читающих. Хочешь — посмотри здесь, мне кажется, что это лучшее начальное введение в Хаскелл подобного типа (с примерами на С и Хаскелле). Я его даже перевёл, может Влад и K опубликуют в RSDN Magazine.

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

S>Если мы попробуем посмотреть на программу с позиции современных требований, то Hello World окажется не вполне удачным примером. К примеру, я с трудом могу представить, как мне построить минимальное или чуть менее минимальное веб-приложение.

А чем хуже хэло-ворлд для АСП.НЭТ где есть поле для ввода имени посетителя и кнопка сабмит при нажатии на которую выоводится сообщение "Дарова чавак Такойто"?
Или аналог в ГУИ?

S>Если начинать рассказывать об ФП с точки зрения высшей математики, то такой курс прекрасно отсеет неспособных к абстрактному мышлению.

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

S> Вместе с теми, кому интересно некотрое практическое применение. Вот обучить человека Екселю очень-очень просто. Там никого не смущает двусмысленность оператора =. Главное — мы ставим простую иллюстративную задачу (например, Здравствуй, Налоговый Инспектор) и показываем, как она решается. Я бы вообще преподавал FP на основе Екселя. Показывая, как можно решить понятную неспециалисту задачу.

Мне кажется программисту от такого обучения будет мало толка. К тому же они и так обчно легко осваивают ёксель, что не приводит к облегчению понимания ФП.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

К>Т.е. у тебя появляется убеждённость, что ты его всегда знал чтоли?

Не. Это другое. Просто в процессе увлекательного чтения подобной литературы многие начинают невольно спрашивать проходящих мимо людей — как пройти в библотеку — попутно помышляя чем бы их убить.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EC>>а донести что такое ФП на примере хаскеля

VD>Шутку понял. Ммешно!

А что именно? Хаскель недостаточно функциональный язык, чтобы на его примере о ФП рассказывать?

now playing: Future Prophecies — Dark matter

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

EC>А что с ней не так?

Бессистемное и очень поверхностное изложение, которые автор пытается замаскировать наукообразно-канцелярским языком.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

EC>Hardcore в общем, можно ещё на первой странице проверять достиг ли читатель 18 лет.

Ага. А на последней достиг ли он оргазма.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>Это не синтаксис, это конкретные примеры. И на С# можно наворотить непонятной хрени.

Мне кажется ты преувеличиваешь его возможности.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

F>Мне казалось, что одна из задач языка облегчить понимание, что на нём написано. А вот подобные записи с моей точки зрения не совсем интуитивно понятны.

Ну так эти записи сделаны не для того, чтобы их понимать

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

К>То, что 99% программных решений сделаны императивно, не говорит о том, что само мышление человека обязательно императивно, имхо.

Неужели это говорит об обратном?

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

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

ИМХО виной всему — привычка. Привычка смотреть на программу, как на последовательность инструкций, меняющих значения переменных. Такой подход в ФП работает плохо, если вообще работает. В итоге программист с приличным опытом оказывается в положении человека, которому нужно научится ходить заново, причём используя другие группы мышц. Вместо циклов и состояний — рекурсия и чистые первоклассные функции.

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

Похоже я тоже скатываюсь в "морализирование"

. Честно говоря, не знаю, что в ФП для императивщиков является самым трудным. Ау, императивщики!

Есть SICP для изучения LISP'а. Есть, скажем, YAHT для Хаскелла. Очень редко встретишь конкретные вопросы по ним в rsdn.declarative, чтобы выдать статистику по трудностям. Вроде всем, кто серьезно взялся изучать ФЯ и имеет более-менее приличный багаж в ИЯ эти курсы вполне по силам. А флейм типа: "А на хрен нужна фича X языка Y!? Это полный отстой, мы в своём ИЯ Z это не использовали и приклеить это в нашем Z некуда и незачем (с дальнейшим убедительны доказательством, что в Z фича X — пятое колесо)" — такой флейм трудностей в изучении ФЯ действительно не выявляет и, вообще, особого смысла не имеет.

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

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

Инкапсуляцией чего? Состояния? Нет в чистом ФП состояний. Нечего и инкапсулировать. LISP — не чистое ФП. Там состояния вводятся и оператор присваивания тоже.

Я мог бы описать, скажем, как работает монада состояния в Хаскелле, решающая в общем виде ту же проблему, что и введение присваивания локальным переменным для сокрытия состояния в SICP, но чисто функциональным способом. Но я думаю, что
(1) это только запутает тебя, потому что это строится на довольно сложной эквилибристике с монадическим типом (в след. номере RSDN Magazine Влад обещал перевод второй части GIH, там это будет, хотя этот раздел 9.3, хм..., скажем так: редкая птица долетит до его серидины

)
(2) это в 99% случаев совершенно не нужно, поскольку чистое ФП решает подобные задачи архитектурно по-другому. В Хаскелле грязные ботинки снимают в IO-прихожей, зато в остальном доме чисто.

А вот инкапсуляция функциональности в ФП очень даже присутствует. В функциях

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

Г>> Про параметризуемые модули и функторы в ML упоминать наверное и смысла нет.
A> Вопрос: откуда они параметризуются?
A> Если извне, то модульность ли это?

Примерно оттуда же, откуда параметризуются generic packages в Аде. Но Вы же не станете утверждать, что в Аде нет модульности?

A> В "обыкновенном" императивном программировании (в ООП особенно) именно
A> побочные эффекты зачастую являются источником значительной гибкости.

Оператор GOTO тоже даёт значительную гибкость, вот только Вы от него почему-то отказались вслед за Виртом и Хоаром...
Так почему бы не сделать следующий шаг и не отказаться от побочных эффектов? Ну хотя бы минимизировать их использование только до ввода/вывода...

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

AVC>- Вот Вы знаете?
AVC>- Нет!
AVC>- А Вы?
AVC>- Понятия не имею!!
AVC>- Императивщики? Боже, кто это?!
AVC>

Не, не так:
— Как сделать состояние?
— Есть способ, но это никому не нужно!
— Ну покажи!
— ... (показывает, используя монадическую артиллерию)
— Блин, как сложно. Плохой язык.

В соседней ветке хороший пример с goto. Представь — сделали императивный язык без него. Набегает народ: а как выходить из вложенных циклов? Ну описываешь им известные техники, в конце говоришь но можно и сэмулировать goto, правда сложно. О, покажи! Показываешь. Реакция с гордостью за свой язык: "Фу, как сложно, а у нас это goto прямо в языке есть! И писать ничего не надо."

AVC>Факт, архитектурно по-другому.
AVC>А как?

В какой задаче?

Например, в Монте-Карло, с неспецифицированным генератором случайных чисел, как в SICP?
Передаёшь в

randoms :: RandomGen g => g -> [a]

этот генератор, и пользуешься получившимся бесконечным ленивым списком случайных чисел в свое удовольствие. Как устроен randoms можно посмотреть в System.Random

randoms  g      = (\(x,g') -> x : randoms g') (random g)

Здесь

random  :: RandomGen g => g -> (a, g)

возвращает пару из случайной величины типа a и нового генератора.

Блин! Кажется, я понял одну из причин обсуждаемых трудностей! Понять как всё устроено и работает внутри — значит опускаться всё ниже и ниже по уровням абстракции. Для императивного мира — это путь, в конце которого биты, байты, регистры, ассемблер. Но для чистого функционального мира это вовсе не так! В конце этого пути в ФП лежат базовые комбинаторы, или лямбда-исчисление.

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

D>Оператор (>>=) связывает два вычисления, позволяя неявно протаскивать всё что угодно из первого вычисления во второе (его поэтому и произносят как bind). Для монады состояния это будет состояние. Собственно реализация оператора (>>=) и есть главное в задании монады. Как его опишешь — такая монада и получится.

Перегрузка точки с запятой — отличная метафора. Осталось от пугающего слова "монада" избавиться. На самом деле, определяя оператор >>=, мы конструируем виртуальную машину, которая умеет выполнять программы вида:

do { x <- foo;
     y <- bar x;
     return (baz (x, y)) }

1) Как работает этам виртуальная машина, определяем мы сами, перегружая оператор ";"
2) Определяем мы ее на чистом ФЯ, поэтому, несмотря на императивный вид, она остается чисто функциональной.

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

D>Где здесь нарушение логики?

В том, что один ФЯ меняют на другой.

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

FDS>Да нет, просто они не рассказывают некоторых вещей или рассказывают их непоследовательно, или плохо подают материал (например, только на примерах)

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

Можно чуть больше конкретики? Каких именно вещей не рассказывают (т.е. может быть они что то должны рассказать перед чем то, а они этого не делают)? Плохо подают материал — как надо хорошо?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Хотя бы IO на 36-й странице учебника как пример.

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

P.S. Т.е. я имею ввиду, что в приведённой ссылке всё сказано близко к истине, только вот Курилка её исказил до невозможности.
Дело в том, что никто последовательно не учит:
1. Абстракциям, применяемым в ФП
2. Применениям этих абстракций в РЕАЛЬНОМ коде

Люди на подобие VladD2 могут схватить что-то на лету, я, например, — нет. Мне нужно долго и упорно читать или вкладывать много сил в изучение соотв. языков — при том, что непонятно, даст это результат или нет. Поэтому в промышленном программировании ФП и не применяется: там в основном обычные люди сидят и не их дело выдумывать заново за разработчиков как же там эти монады использовать...

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

К>Ммм, ты статью смотрел?

К>Хотя бы IO на 36-й странице учебника как пример.

Да, смотрел, мне интересно мнение рсдн-щиков

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Более-менее понятно, спасибо за ответ.
Нужна именно связь понятий с реальными применениями, так? Где применять это, а где то..
А про очередность изложения есть мысли?

FDS>Я вообще не видел литературы, где нормально описываются значение и применение терминов типа "сопоставление с образцом" (SICP с метаязыковыми средствами не подойдёт) или, скажем, монад. Может кините ссылочку?

Ну, я как и все учился на многих источниках. Их тут приводили и вместе и слитно, увы, универсального учебника пока нет

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

FDS>P.S. Т.е. я имею ввиду, что в приведённой ссылке всё сказано близко к истине, только вот Курилка её исказил до невозможности.
FDS>Дело в том, что никто последовательно не учит:
FDS>1. Абстракциям, применяемым в ФП
FDS>2. Применениям этих абстракций в РЕАЛЬНОМ коде

Можешь конкретно показать, что я исказил?

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

LCR>Курилка,

FDS>>>...Думаю, у всех по началу с процедурным программированием тоже возникали трудности, хотя мышление у человека такое, что можешь хоть прямо сесть и писать процедурами прямо из головы.

К>>Согласно каким фактам ты утверждаешь выделенное?
К>>То, что 99% программных решений сделаны императивно, не говорит о том, что само мышление человека обязательно императивно, имхо.

LCR>Мышление человека вообще может быть очень гибким и привыкать к использованию самых разнообразных абстракций. Для примера можно привести математиков (скажем, в таких областях как топология и алгебра), которые с лёгкостью ворочают абстракциями, на изучение которых уходят годы.

немного информации с полей псизологии: всё, чем мы оперируем — абстрактные понятия, когда-то нами освоенные, включая и сам язык. такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

Bulat,

BZ>немного информации с полей псизологии: всё, чем мы оперируем — абстрактные понятия, когда-то нами освоенные, включая и сам язык. такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

Любопытно.

Ещё добавлю от себя, что есть существенная разница между абстрактным образом и синтетическими абстракциями. Чтобы построить первый, нужен вещественный опыт, а чтобы второй — нужно абстрактное мышление и воображение.

Попробуй ребёнку объяснить, что такое масса? Понятия "легче — тяжелее" схватываются легко, а вот понятие "5 кг" — никак. То есть вообще. Хоть башкой об стену бейся, но объяснить невозможно. (Аналогии с линейками и чёрточками на весах не канают — это замечание специально для скептиков).

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

BZ>новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

а как это выяснили?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

BZ>>новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

ANS>а как это выяснили?

Меня всегда восхищают подобные вопросы. Напоминают малыша Стругацких: "Как люди узнали, что думают головой?".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

LCR>Попробуй ребёнку объяснить, что такое масса? Понятия "легче — тяжелее" схватываются легко, а вот понятие "5 кг" — никак. То есть вообще. Хоть башкой об стену бейся, но объяснить невозможно. (Аналогии с линейками и чёрточками на весах не канают — это замечание специально для скептиков).

опыт — критерий истины

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

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

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

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

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

BZ>человечское обучение — искуственная система, основанная на искусственном языке, системе понятий, логике, позволяющая передавать знания в другой форме. и её неестественность делает эту систему плохо воспринимаемой большинством нормальных людей

А какая система тогда будет естественной?

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

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

BZ>>человечское обучение — искуственная система, основанная на искусственном языке, системе понятий, логике, позволяющая передавать знания в другой форме. и её неестественность делает эту систему плохо воспринимаемой большинством нормальных людей

К>А какая система тогда будет естественной?

когда детей заинтересовывают учиться и учат на опыте, на примерах

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

BZ>вот только не ставьте мне смайлики, а попробуйте ответить. вопрос весьма серьёзный. для философов это — основной вопрос философии. для психологов это вопрос о происхождении сознания. когда оно появилось, каким образом, что это вообще такое?

Да откуда ж я знаю? В частности, какой нибудь чистый солипсизм опровергнуть, как и доказать, невозможно. Посылок, кроме "Я есть" нет. Про более сложные модели говорить тяжело, да и (для меня) бестолку что ли... Так интеллектом о стенку постучать разве что...

Не, всяких Лемов, Пелевиных и прочая я, конечно, почитывать люблю

А почему я верю? Ну, наверное, потому что мне надо во что то верить, чтобы считать это посылками (аксиомами) в своих рассуждениях. Чисто практический мотив.

А что — у тебя не так?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

BZ>Здравствуйте, Курилка, Вы писали:

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

BZ>>>человечское обучение — искуственная система, основанная на искусственном языке, системе понятий, логике, позволяющая передавать знания в другой форме. и её неестественность делает эту систему плохо воспринимаемой большинством нормальных людей

К>>А какая система тогда будет естественной?

BZ>когда детей заинтересовывают учиться и учат на опыте, на примерах

Ммм, а что ты под "человеческим обучением" подразумевал тогда? Традиционные схемы обучения?
Если так, то согласен.
Но не только ими исчерпываются варианты.

BZ>>>>человечское обучение — искуственная система, основанная на искусственном языке, системе понятий, логике, позволяющая передавать знания в другой форме. и её неестественность делает эту систему плохо воспринимаемой большинством нормальных людей

К>>>А какая система тогда будет естественной?

BZ>>когда детей заинтересовывают учиться и учат на опыте, на примерах

К>Ммм, а что ты под "человеческим обучением" подразумевал тогда? Традиционные схемы обучения?

конечно

К>Если так, то согласен.
К>Но не только ими исчерпываются варианты.

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

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

BZ>и последующие тоже

почитайте "человек. который принял свою жену за шляпу" — это прост чума

Классная книжка. Присоединяюсь к рекомендациям.

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

FDS>В документации по Nemerle я вообще не способен разобраться. Я так и не понял, какие возможности есть у макросредств этого языка и где это описано. Хотя текста, опять же, много. Ну и т.п.

Проблема в том, что как таковой документации и нет.
Вот в моих статьях тебе многе непонятно?

... << RSDN@Home 1.2.0 alpha rev. 637>>

BZ>>такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

VD>Интересно, а как этот новорожденный об этом расказал?
VD>Я вот сам наблюдал как новоражденный с большим энтузиазмом выделял из окружающих предметов мамкину титьку и с радостью ее сосал.
VD>Видимо он не знал, что занимается лженаучной ересью.

состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.

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

BZ>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.

И как он осязает тику на растоянии 30 см.?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

L>Более-менее понятно, спасибо за ответ.
L>Нужна именно связь понятий с реальными применениями, так? Где применять это, а где то..
L>А про очередность изложения есть мысли?

FDS>>Я вообще не видел литературы, где нормально описываются значение и применение терминов типа "сопоставление с образцом" (SICP с метаязыковыми средствами не подойдёт) или, скажем, монад. Может кините ссылочку?

L>Ну, я как и все учился на многих источниках. Их тут приводили и вместе и слитно, увы, универсального учебника пока нет

Вот именно. Это — самое сложное, что можно вообще придумать

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

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

FDS>>P.S. Т.е. я имею ввиду, что в приведённой ссылке всё сказано близко к истине, только вот Курилка её исказил до невозможности.
FDS>>Дело в том, что никто последовательно не учит:
FDS>>1. Абстракциям, применяемым в ФП
FDS>>2. Применениям этих абстракций в РЕАЛЬНОМ коде

К>Можешь конкретно показать, что я исказил?

Могу. Автор статьи сказал, что учебные курсы так построены, что они не ориентированы на практическое применение, они сразу дают какие-то непонятные концепции, которые непонятно зачем нужны. Я понял его именно так. Т.е. всё дело в курсах по ФП, которые прост откровенно скверно написаны.
В то же время, ты написал, что императивщики мыслят по другому, а авторы уже мыслят функциональными концепциями, и, следовательно, поэтому им и сложно изучать ФП.
Т.е. я считаю, что автор говорит просто о плохом качестве курсов, которые неправильно построены, не адаптированы под практические нужды. А ты говоришь, что автор говорит о том, что авторы курсов написали плохие пособия, потому что уже мыслят ФП-шными концепциями. Но они написали плохие пособия не по этому.

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

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

FDS>>Короче говоря, дело даже не в том, что кто-то что-то плохо понимает. Просто книги так написаны, что по ним нельзя научится программировать и нужно всё делать с нуля, как это было и для процедурного программирования. Причём дело не в мышлении, а именно в понимании и в правильном применении средств языка: т.е. я могу спокойно что-то "замыслить"

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

К>Согласно каким фактам ты утверждаешь выделенное?
К>То, что 99% программных решений сделаны императивно, не говорит о том, что само мышление человека обязательно императивно, имхо.

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

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

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

W>>Науку изучения головного мозга сильно продвинула русско-японская война

,

BZ>и последующие тоже

почитайте "человек. который принял свою жену за шляпу" — это прост чума

BZ>например, человек, у которого осталось толлко логическое мышление (правое полушарие), но начисто исчезло образное (левое). ему дают перчатку, он на неё смотрит и говорит — "это мешочек с 5-ю кармашками... может, кошелёк?"

Ты не перепутал полушария?

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

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

FDS>>В документации по Nemerle я вообще не способен разобраться. Я так и не понял, какие возможности есть у макросредств этого языка и где это описано. Хотя текста, опять же, много. Ну и т.п.

VD>Проблема в том, что как таковой документации и нет.
VD>Вот в моих статьях тебе многе непонятно?

Твои статьи я просто невнимательно читаю, ты же сам это доказал

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

Здравствуйте, FDSC, Вы писали:
FDS>И указанные мной трудности подчёркивают, что мышление в соотв. концепциях не есть умение в них программировать. Так как концепции надо научится правильно технически применять.

P.S. Это, в том числе, обобщение моего небогатого опыта преподавания в ВУЗе

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

BZ>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.
Вааще-то — на запах. Проверено.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

VD>Проблема в том, что как таковой документации и нет.
VD>Вот в моих статьях тебе многе непонятно?
Хорошие статьи. Вполне понятно что там написано. Но только вопрос в применении. Это как сделать хороший ООП дизайн. После некоторого процедурного опыта мне пришлось немного подвертеть в мозгах чтобы делать ООП программы. А то когда и что применить — пришло только с опытом. В данном случае несколько хуже. У человека совсем другой инструментарий о котором он прочитал, но ни разу не применял. Если с ООП еще можно сделать фигню которая будет работать, пуская проблемы и возникнут потом. С функциональщиной — это не пройдет. Рамки слишком жесткие. И как результат — человек бросают в бассейн, и он учится плавать согласно самоучителю. Многие тонут. Не смог сразу перестроить мозги — твое место на берегу. Лучшие — начинают плавать. Поэтому — мир программистов на функциональных языках — не такой уж большой.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

Значит моя следующая статься как раз для тебя.

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

FDS>Особенно это касается макросов. Всё, что я видел, лишь небольшие примочки, конечно облегчающие кодирование, но принципиально ничего нового не приносящие. Но ведь они не только на это способны?

Макросы к ФЯ прямого отношения не имеют. Но до них тоже время дойдет. Имеющиеся сегодня описания конечно мало на что годятся.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>>>такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

VD>>Интересно, а как этот новорожденный об этом расказал?
VD>>Я вот сам наблюдал как новоражденный с большим энтузиазмом выделял из окружающих предметов мамкину титьку и с радостью ее сосал.
VD>>Видимо он не знал, что занимается лженаучной ересью.

BZ>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.

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

BZ>>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.
GZ>Вааще-то — на запах. Проверено.
Слышал что запах титьки сильно похож на запах околоплодных вод. Потому это вообще самое знакомое для новорожденного

Ну а сосать он учится тоже ещё в утробе — палец сосёт, тренирует мышцы

Грамотно всё у природы придумано, блин

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Слышал что запах титьки сильно похож на запах околоплодных вод. Потому это вообще самое знакомое для новорожденного

Ну а сосать он учится тоже ещё в утробе — палец сосёт, тренирует мышцы

Грамотно всё у природы придумано, блин

Ага. У животных именно так. После рождения — сразу идентифицируют титьку по запаху. Аначе бы сразу передохли с голоду.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

BZ>>>>такой простой пример — новорожденный не способен выделить в воспринимаемой им картинке даже отдельные предметы (!)

VD>>>Интересно, а как этот новорожденный об этом расказал?
VD>>>Я вот сам наблюдал как новоражденный с большим энтузиазмом выделял из окружающих предметов мамкину титьку и с радостью ее сосал.
VD>>>Видимо он не знал, что занимается лженаучной ересью.

BZ>>состаельный рефлекс ориентируются на осязание, а не зрительные образы. не удивлюсь, если он вообще глах не октрывал.

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

А кто сказал, что именно "не интересуется"?

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

AV>По этому поводу в фидошной эхе ru.linux говорят следующее: "единственный интуитивно понятный интерфейс — это материнская титька".

Это из-за интуитивности к ней всегда админ прилагается?

Hi Andrei N.Sobchuck

AV>>По этому поводу в фидошной эхе ru.linux говорят следующее: "единственный интуитивно понятный интерфейс — это материнская титька".

ANS>Это из-за интуитивности к ней всегда админ прилагается?

Какой такой админ? Максимум — поставщик.

--
С Уважением

Posted via RSDN NNTP Server 2.0

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

AV>Какой такой админ? Максимум — поставщик.

Провайдер. Отключает от сети по своим внутренним рассуждениями. Сам видел.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Сделаем.

В моих планах следующая статья как раз продвинутый курс макросостроения. О! Воти и название придумалось.

Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD> О! Воти и название придумалось.

VD>Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.
Вот я допустим не против таких экспериментов

Мыло в профиле. Так что вот..

"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери

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

FDS>Т.е. я считаю, что автор говорит просто о плохом качестве курсов, которые неправильно построены, не адаптированы под практические нужды. А ты говоришь, что автор говорит о том, что авторы курсов написали плохие пособия, потому что уже мыслят ФП-шными концепциями. Но они написали плохие пособия не по этому.

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

Hi VladD2

AV>>Какой такой админ? Максимум — поставщик.

V>Провайдер. Отключает от сети по своим внутренним рассуждениями. Сам видел.

Повбывав бы за такое.

--
С Уважением

Posted via RSDN NNTP Server 2.0

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

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

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

VD>Сделаем.

VD>В моих планах следующая статья как раз продвинутый курс макросостроения. О! Воти и название придумалось.

VD>Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.

Я могу... В плане функциональщины — чист и невинен как младенец

... << RSDN@Home 1.2.0 alpha rev. 668>>

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

VD>В моих планах следующая статья как раз продвинутый курс макросостроения. О! Воти и название придумалось.

Опс, очень интересно

Ждем-с...

VD>Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.

Хм, лиспо-макро-фил подойдёт?

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

AM>Я могу... В плане функциональщины — чист и невинен как младенец

Речь о макросах.

ЗЫ

И оверквотить так не надо, плиз.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CU>Хм, лиспо-макро-фил подойдёт?

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.
M>Вот я допустим не против таких экспериментов

Мыло в профиле. Так что вот..

Ну, кому интересно, пишите мне на мыло запрос. Когда статья будет в бета-версии пришлю для критики.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

D>Если бы всё было так просто! Учебные примерчики (типа факториала, быстрой сортировки, чисел Фибоначчи) несложно реализавать и на императивных языках. А задачи более объёмные (типа построения компиллятора) отпугнут большую часть читающих. Хочешь — посмотри здесь, мне кажется, что это лучшее начальное введение в Хаскелл подобного типа (с примерами на С и Хаскелле). Я его даже перевёл, может Влад и K опубликуют в RSDN Magazine.

С удовольствием. Прислыай в нашем шаблоне.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Речь о макросах.

Ведь речь идет/будет идти не столько о макросах "вообще", сколько о макросах конкретного языка, ведь так?

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

... << RSDN@Home 1.2.0 alpha rev. 668>>

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

VD>С удовольствием. Прислыай в нашем шаблоне.

А Вы с Купаевым вообще-то общаетесь?

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

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

FDS>>Т.е. я считаю, что автор говорит просто о плохом качестве курсов, которые неправильно построены, не адаптированы под практические нужды. А ты говоришь, что автор говорит о том, что авторы курсов написали плохие пособия, потому что уже мыслят ФП-шными концепциями. Но они написали плохие пособия не по этому.

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

Ну а причём тут программисты? Естественно, если авторы не умеют писать книг, то никто ничего и не поймёт. А вы говорите именно о таких авторах.

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

AM>Так уж вышло что развитые средства макросостроения имеются прежде всего в ФЯ. И императивщики, в массе своей, занют о них значительно меньше.

Если учесть, что в С макросы были с самого рождения (да кривые, но ведь были!)...

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Если учесть, что в С макросы были с самого рождения (да кривые, но ведь были!)...

Согласен, но если судить по вашей статье, то С-шные макросы рядом не стоят с N-скими

Впрочем, это всё пустая болтовня

Будем ждать новую статью

... << RSDN@Home 1.2.0 alpha rev. 668>>

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

M>Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель

Т.е. у тебя появляется убеждённость, что ты его всегда знал чтоли?

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

EC>а донести что такое ФП на примере хаскеля

Шутку понял. Ммешно!

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EC>А что именно? Хаскель недостаточно функциональный язык, чтобы на его примере о ФП рассказывать?

Знаешь, временами,говоря с тобой, у менся складывается ощущение полнейшего абсурда.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Знаешь, временами,говоря с тобой, у менся складывается ощущение полнейшего абсурда.

Это всё от недосказанности

, я тебя тоже часто не понимаю.
Если не лень разверни мысль подробнее — обсудим.
Я действительно не понял, что тебя так развеселило.

now playing: Future Prophecies — Dark matter

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

админы. откусите этот кусок

а то прочитал и на полчаса янус надо закрывать. все равно дальше ничего не понимаешь

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

VD>Вот только нужно бы найти добровольцев на которых поэсперементировать с доступностью материала.
я первый. туупой блин. если меня научишь — каждый поймет

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

FDS>>Думаю, у всех по началу с процедурным программированием тоже возникали трудности, хотя мышление у человека такое, что можешь хоть прямо сесть и писать процедурами прямо из головы.

К>Согласно каким фактам ты утверждаешь выделенное?
К>То, что 99% программных решений сделаны императивно, не говорит о том, что само мышление человека обязательно императивно, имхо.

Бог его знает, какое мышление у человека. То ли это машина Тьюринга, то ли решающую роль в нем играет квантовая когерентность, то ли еще что. Но, как я понял, FDSC, утверждал только, что человеку проще описать последовательность действий, приводящих к решению задачи в терминах процедур и функций, чнежели в терминах лямбда-исчисления. Доказать строго это вряд ли возможно, но косвенное свидетельстватаковы: (1) название топика [как я понял, у апологетов ФЯ не возникает проблем с императивными языками, поэтому программирование на ФЯ представляется более сложным] (2) значение 99% [человек для решения задачи использует те средства, которые позволяют ему проще получить результат] (3) житейский опыт [объяснения, как приготовить гороховый суп, как пройти на пл. Незалежностi, как играть на гитаре и т. д. все-таки императивны]

M>>Читаю сейчас по паре страниц в день Функциональное программирование на языке Haskell. Вою волком. У мнея математика закончилась лет пять тому назад, не успев начаться

Лямбда исчисление я ни сном ни духом

А там — только оно. Ыыыыы.

AF>Ты еще наверно вот эту книгу не читал Городняя, Основы функционального программирования. Вот уж кого хочется убить об стену, чтобы больше не загрязняла ноосферу своими "творениями"

Спасибо. Буду знать на будущее

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

AF>Ты еще наверно вот эту книгу не читал Городняя, Основы функционального программирования. Вот уж кого хочется убить об стену, чтобы больше не загрязняла ноосферу своими "творениями"

А что с ней не так?

now playing: Teebee & Noisia — Moon Palace

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

Q>Покажите пальцем, где там императивность. Например, есть рецепт приготовления супа. Кажется, что это последовательность указаний — типа императивный алгоритм. Но на самом деле, чтобы приготовить суп нужно выполнить большое количество других действий, которые явно в рецепте не указаны.

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

Q>Там не сказано, что нужно сделать, чтобы включить плиту, что значит помешивать ложкой, как выглядит кипение и т.п.

Как же это? Часто написано "поставить на медленный (круто, кстати, звучит

) огонь и варить (внимание!) до готовности 10-15 минут (

) помешивая...". Так что вполне себе императивная спецификация.

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

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

Чесно говоря декларативный стиль в ФП всегда мне казался маленьким обманом. Ведь по сути цикл, проверки и т.п. никуда не деваются. Они просто записываются по другому. Вот Пролог это уже ближе к реальной декларативности, так как там именно что идет постановка задачи.

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

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

Но главное в программах это грамотный выбор абстракции. Тот же ООП позовляет создать хорошую абстрацию на уровне всех программы, но практически не имеет сахара для реализации на урове тел методов. Вот лямбды с замыканиями и функциями высшего порядка позволяют асбрагировать код. И это дает отличный результат. Но декларативность ли это? Как посмотреть... Можно сказать — да. А можно сказтать, что это грамотная декомпозиция кода.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Вот если бы там было сказано сварить кортофельный суп, тогда да...

Тогда это была бы бесконечная рекурсия

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

И стоит ещё напомнить, что физика и математика, используют декларативный подход для формального описания действительности.

Hardcore в общем, можно ещё на первой странице проверять достиг ли читатель 18 лет.

now playing: Quinoline Yellow — Sealed

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

EC>>Hardcore в общем, можно ещё на первой странице проверять достиг ли читатель 18 лет.

VD>Ага. А на последней достиг ли он оргазма.

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

now playing: Team Doyobi — 87c5875ucpro

Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.
Вот пара примеров оттуда

(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)

pz = (((. head . uncurry zip . splitAt 1 . repeat) . uncurry) .) . (.) . flip

Так, и хочется воскликнуть: и эти люди запрещают нам ковыряться в носу! (и этим людям не нравятся скобки в LISP'е!)
Имхо даже для исследовательских целей это явный перебор.

И насколько я понимаю, (почти?) все ФЯ страдают подобной ненаглядностью. Понятно, что это дело вкуса/привычки, но меня лично подобный синтаксис — серьёзное препятствие для изучения/применения.

Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"?

но и не настолько простой как, например, unlambda.

Лисп в виде scheme'ы уже, Nemerle не прелагать, пока мне рано. Купил книжку по хаскелю, теоретическая часть благодаря фак. "К" МИФИ прошла на ура, но часть, относящаяяся собственно к языку имхо не очень понятна.
Есть ли язык, имеющий столь же простой синтаксис, как, например, pascal/modula2? Но функциональный.

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

F>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.

Ключевое слово выделено

F>Вот пара примеров оттуда

F>

F>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
F>

F>pz = (((. head . uncurry zip . splitAt 1 . repeat) . uncurry) .) . (.) . flip
F>

Так не пишут. Эти примеры взяты с одной целью — показать конвертацию из типа в определение, и из пойнтфри стиля в пойнтфул. У автора наверняка были причины выбрать именно такие сложные и непонятные выражения

А в целом — да, для того, чтобы понять что написано на языке Х надо как минимум знать язык Х.

F>Так, и хочется воскликнуть: и эти люди запрещают нам ковыряться в носу! (и этим людям не нравятся скобки в LISP'е!)

F>И насколько я понимаю, (почти?) все ФЯ страдают подобной ненаглядностью. Понятно, что это дело вкуса/привычки, но меня лично подобный синтаксис — серьёзное препятствие для изучения/применения.

Это не синтаксис, это конкретные примеры. И на С# можно наворотить непонятной хрени.

F>Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"?

но и не настолько простой как, например, unlambda.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PM>Сложные типы (например, типы функций ну очень высокого порядка) всегда выглядят страшно, это не синтаксическая сложность, а семантическая, синтаксис лишь отражает структуру типа. Решается, как и в C/C++, введением синонимов. Типы вида int (*(*(*)())[3])() нравятся больше?

Ты мозги то не пудри. Это ведь был всего лишь пример эмуляции перегрузки. В С++ перегрузка выражается просто и естественно. Никакой лишней косвенности там не будет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

F>Лисп в виде scheme'ы уже,

Ну, и чем тебя это введение не устраивает?

F> Nemerle не прелагать, пока мне рано.

Что рано? Если ты знаком с императивным программированием и теболее с ООП, то это будет самый простой путь.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

F>>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.
L>Ключевое слово выделено

Ага. Но точнее я объяснить не смог

L>А в целом — да, для того, чтобы понять что написано на языке Х надо как минимум знать язык Х.

Мне казалось, что одна из задач языка облегчить понимание, что на нём написано. А вот подобные записи с моей точки зрения не совсем интуитивно понятны.
Что особенно смущает, что в императивных языках традиционно переменным, типам и тд даются осмысленные наименования. В ФЯ в большинстве примеров, что я видел, всё именуется одно-двухбуквенно. Поэтому запись (a -> b) -> c в принципе понятна, но "что конкретно ты имела в виду"?

L>Я бы всё таки начал со Scheme, очень простой язык. Ну, а так Ocaml, наверное.

Со Scheme я уже познакомился, действительно, просто и понятно. Наверное, да, буду смотреть Ocaml.

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

PM>Можно попробовать Caml Light.

Спасибо.

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

F>>Лисп в виде scheme'ы уже,
VD>Ну, и чем тебя это введение не устраивает?

Устраивает. Потихоньку продолжаю "играться" с ним, но вряд ли стану использовать в работе.

F>> Nemerle не прелагать, пока мне рано.
VD>Что рано? Если ты знаком с императивным программированием и теболее с ООП, то это будет самый простой путь.

Знаком, и, наверное, неплохо (7+ лет на cpp — как раз тут это скорее минус — сложнее перестроить мышление). Но в данном случае Nemerle будет как тем самым микроскопом орехи колоть. Меня смущает обилие различных механизмов, которых я пока не понимаю, для по сути одного и того же. Хотелось бы понять весь этот "синтаксической сахар" в каком-то систематизированном порядке, и лучше бы от простого к сложному.

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

PM>В том примере ничего страшного не было. a -> b — это тип функции, принимающей a и возвращающей b.
PM>Благодаря каррингу функции с несколькими аргументами выражаются как функции одного аргумента, возвращающие другую функцию.

PM>Итак, для того примера имеем:
PM>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
PM>Функия возвращает t, принимает один аргумент типа
PM>((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t
PM>Это тоже функция, возвращает тоже t, принимает 2 аргумента:
PM>2) t3 -> t1 -> t2 -> t3 — функция, на C ее тип выглядит как t3 (*)(t3,t1,t2)
PM>1) (a -> b -> c) -> (a -> b) -> a -> c
PM> функция, принимает 3 аргумента
PM> 1) a -> b -> c == c (*) (a,b)
PM> 2) a -> b — тривиально
PM> 3) a
PM> и возвращает c

Это всё как раз понятно. Процесс аналогичен разбору типа в С, с чего обычно и начинается обучение. Но имхо очень не наглядно. Пусть даже с практикой разбор такого выражения будет занимать пару секунд. Но в нескольких страницах подобного кода найти отличия, например, между
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
и
(((a -> b -> c) -> (a -> d) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
очень сложно.

А если накладывать ограничения на типы (а без этого, я так понимаю, практически не бывает), то объявление разрастётся на несколько строк.
По-моему, это сильно затрудняет написание больших программ.

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

F>Знаком, и, наверное, неплохо (7+ лет на cpp — как раз тут это скорее минус — сложнее перестроить мышление). Но в данном случае Nemerle будет как тем самым микроскопом орехи колоть. Меня смущает обилие различных механизмов, которых я пока не понимаю, для по сути одного и того же. Хотелось бы понять весь этот "синтаксической сахар" в каком-то систематизированном порядке, и лучше бы от простого к сложному.

Дак, чудак ты человек.
У тебя основная проблема — это то что ты попадаешь в полностью другой мир. Тот же Хаскель или Схема на С++ ну соврешенно не похожи. Говорить о постепенном изучении просто не приходится.

Вот скажем с восприятем C#-кода у тебя большие проблемы?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

VD>>Можно так "Экстремальное математическое порно для тех про проводит вечера в одиночестве".

EC>Hardcore в общем, можно ещё на первой странице проверять достиг ли читатель 18 лет.

А в инете она есть где-нибудь?
Хочется посмотреть на это порно...

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

F>Мне казалось, что одна из задач языка облегчить понимание, что на нём написано. А вот подобные записи с моей точки зрения не совсем интуитивно понятны.

Подобные впечатления от Хаскеля мне знакомы не понаслышке

Re[30]: Goto's are evil?
Но подобных выражений на самом деле очень немного встречается на практике, можно сказать, что их почти нет. Бывают, конечно, забористые типы, вот например, из последнего (высокоуровневый GUI Phooye) — определение основного типа (с раскрытыми алиасами type):

newtype UI i o = UI (AmA (Kleisli (CallBackT (ReaderT (Panel ()) (TagT Layout IO)))) IO i o)

Каждый из типов, используемых в определении, является либо монадой, либо стрелкой. Моя попытка самостоятельно разобраться, что же тут происходит, успешно накрылась. Решил подождать обещанной статьи автора, ибо библиотека очень интересная.
Но это действительно наивысший возможный пилотаж, в основном же все намного проще, тем более никто не запрещает овладевать возможностями языка от простого к сложному.

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

VD>Дак, чудак ты человек.
VD>У тебя основная проблема — это то что ты попадаешь в полностью другой мир. Тот же Хаскель или Схема на С++ ну соврешенно не похожи.

Это я уже понял.

VD>Говорить о постепенном изучении просто не приходится.

А вот с этим не согласен. Со школы и института я привык к классическому подходу при обучении: от простого к сложному. Вся наша система образования построена на этом, а не только императивный стиль программирования. И переучиваться обучаться (на что я потратил 20 с лишним лет) мне кажется слишком высокой платой.

VD>Вот скажем с восприятем C#-кода у тебя большие проблемы?

Э... смотря какого. Я не так хорошо знаю шарп как плюсы, и его возможности в части ФП также мне ясны не на 100%. Речь ведь идёт, я так понимаю, не об использовании .Net'овских классов.

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

RK>Но подобных выражений на самом деле очень немного встречается на практике, можно сказать, что их почти нет. Бывают, конечно, забористые типы, вот например, из последнего (высокоуровневый GUI Phooye) — определение основного типа (с раскрытыми алиасами type):
RK>

RK>newtype UI i o = UI (AmA (Kleisli (CallBackT (ReaderT (Panel ()) (TagT Layout IO)))) IO i o)
RK>

RK>Каждый из типов, используемых в определении, является либо монадой, либо стрелкой. Моя попытка самостоятельно разобраться, что же тут происходит, успешно накрылась. Решил подождать обещанной статьи автора, ибо библиотека очень интересная.

Мда... Зато как красиво в использовании:

    ui1 :: UI () ()
    ui1 = title "Shopping List" $
          proc () -> do
            a <- title "apples"  (islider 3) -< (0,10)
            b <- title "bananas" (islider 7) -< (0,10)
            title "total" showDisplay        -< a+b

Ещё бы посмотреть на скорость работы с чуть более сложными контролами типа ListView.

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

Вот, кажется, с этим проблемы. Согласен с автором исходного поста, я не нашёл ни одного нормального учебника, где простым и понятным языком объяснили бы что и как. При том, что вроде и образование и природные склонности подходящие. Вспоминаю, как я изучал что basic, что pascal, что c++ — гораздо проще было выйти на уровень, пусть не мастера, но с которого можно было самостоятельно что-то делать.

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

FDS>А в инете она есть где-нибудь?
Одно время автор рассылал её всем желающим, пока не издали, сейчас нет — обязательства перед издательством.
На самом деле книга достойная, но название не соответствует содержанию.
Лучше попроси его выслать черновики новой книги — она более практически направленная.

now playing: Team Doyobi — 87c5875ucpro

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

FDS>Люди на подобие VladD2 могут схватить что-то на лету, я, например, — нет. Мне нужно долго и упорно читать или вкладывать много сил в изучение соотв. языков — при том, что непонятно, даст это результат или нет. Поэтому в промышленном программировании ФП и не применяется: там в основном обычные люди сидят и не их дело выдумывать заново за разработчиков как же там эти монады использовать...

вообще- то, учат и есть промышленное применение

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

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

FDS>>А в инете она есть где-нибудь?
EC>Одно время автор рассылал её всем желающим, пока не издали, сейчас нет — обязательства перед издательством.
EC>На самом деле книга достойная, но название не соответствует содержанию.
EC>Лучше попроси его выслать черновики новой книги — она более практически направленная.

Меня как раз интересует "непрактичность"

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

LCR>2. Колмогоров, Фомин "Элементы теории функций и функционального анализа". Функциональный анализ и топология — это из разряда высшего пилотажа. Но как доступно эти вещи изложены в этой книжке! Лично я купил эту книжку просто на память, потому что её просто интересно листать, хотя функанализ мне сейчас не нужен.
Данную книгу не читал, но Колмогоровские учебники всегда отличались хорошими понятиями. Это называется, человек гениален во всем.

LCR>5. Кормен, Ривест, Лейзерсон "Алгоритмы: построение и анализ" — никакие беллетристы и переливатели из пустого в порожнее не сравнятся с ними!
+5
Классная книга.

Но сейчас у меня есть книга: "Графы в программировании: обработка, визуализация и применение". Замечательный набор материала, но написано... Без дополнительного гугления и просмотра по ссылкам на исходные материалы ничего не понять. Жуть. Несмотря на то, что пытаются дать не только формулы, но и алгоритмы это плохо у них получается.
Точно так же большинство учебников которые мне попадались когда-то в универе.

LCR>Так что я не согласен с тобой, дескать математики не умеют писать книги. Умеют!
Некоторые умеют. Абсолютно согласен.
LCR>Но разумеется далеко не все, и процент посредственных книжек примерно такой же как и везде. Вдобавок написать хорошую книгу по математике намного труднее, потому что излагать "в апельсинах" суть проблемы P=NP намного труднее, чем излагать как "типа братки ведут канкретные базары с типа банкиром".
Эти два утверждения противоречат друг другу. Хотя бы статистически.

LCR>А по Хаскелю когда-нибудь появятся достойные книжки (я верю во всяком случае). Собственно, есть места из различных статей, которые хоть сейчас распечатывай и на стенку вешай — особенно удачные аналогии или красивые решения. Нужно просто подождать, пока Муза навестит хорошего преподавателя по Хаскелю

Немножко не так. По какой дисциплине преподают у нас Хаскель (или что чаще Лисп)? Предмет не помню, но в курс функц. языков входит математика. Так что лучше чтобы муза навестила хорошего публициста, а не преподавателя. Для пропогандирования Хаскеля это более полезно

... << RSDN@Home 1.2.0 alpha rev. 0>>

Хм,

GZ>Эти два утверждения противоречат друг другу. Хотя бы статистически.
Да не, Глеб, мне просто не понравилась фраза

GZ>>Вообще это большая проблема учебников написанных математиками.

Вот я и поспешил сделать замечание, что доля хороших писателей-математиков среди писателей-математиков (имхо) такая же как и доля хороших писателей среди писателей вообще. Разумеется у меня нет расчётов, статистики и прочее, сужу просто по тому количеству книг, о которых лично у меня хорошие воспоминания

GZ>Немножко не так. По какой дисциплине преподают у нас Хаскель (или что чаще Лисп)? Предмет не помню, но в курс функц. языков входит математика. Так что лучше чтобы муза навестила хорошего публициста, а не преподавателя. Для пропогандирования Хаскеля это более полезно

Ну или так.

VladD2,

VD>Популярная статья написанная математиком явление довольно редкое.

Ибо ты не в курсе.

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

LCR>Ибо ты не в курсе.

Ну, просвети.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

GZ>Не соглашусь с тобой. Когда я изучал OOP — мне попалась одна книжка. Что за автор и что за книжка уже за давностью не помню. Автор точно помню русский. Там весь ООП был описан на одном (или двух) проектах. По крайней мере один я помню. Там описывался океан. Описывались объекты акулы, описывались жертвы и т.д.

Часом, не книга двух "русских парней" Вайнера и Пинсона "С++ изнутри"?

(В оригинале Wiener, Pinson "The C++ Workbook".)
Там как раз одна глава была посвящена этому "экологическому моделированию" (океан, хищники, жертвы).

А основная мысль, ИМХО, верная: меньше (поначалу) абстрактных слов, дайте (хоть какой) примерный проект.

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

VD>На самом деле с ФП все точно так же как с ООП. Только надо выбирать язык который не отличается радикализмом. Например, точно не стоит начинать изучать ФП с использованием Хаскеля, Схемы или скажем Эрланга (т.е. языков близких чисто функциональным или ими и являющиеся).

Схему зря "обидел", ИМХО.
Но мысль понятна: учить базовым понятиям ФП можно и на языках, не считающихся функциональными.
Так и поступают Бауэр и Гооз в своей классической "Информатике": во 2-й главе ограничиваются строго функциональной (подстановочной) вычислительной моделью (хотя такого имени и не дают), но примеры дают на Алголе-68 и даже модифицированном Паскале.
(Вообще, интересно иногда заглянуть в старые книги: можно увидеть довольно ясные "намеки" на более поздние идеи.)
Только хотелось бы все-таки определиться: либо ФП — это "прозрачность по ссылкам", либо "сборная солянка".
В последнем случае не удивительно, что это "плохо дается императивщикам"...

VD>Несмотря на то, что это может показаться предвзятым...

Ну что ты...

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

AVC>Часом, не книга двух "русских парней" Вайнера и Пинсона "С++ изнутри"?

AVC>(В оригинале Wiener, Pinson "The C++ Workbook".)
AVC>Там как раз одна глава была посвящена этому "экологическому моделированию" (океан, хищники, жертвы).
Может автор перепечатал главу, но я точно помню что автор был русский.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

AVC>>Часом, не книга двух "русских парней" Вайнера и Пинсона "С++ изнутри"?

AVC>>(В оригинале Wiener, Pinson "The C++ Workbook".)
AVC>>Там как раз одна глава была посвящена этому "экологическому моделированию" (океан, хищники, жертвы).
GZ>Может автор перепечатал главу, но я точно помню что автор был русский.

Ну, не суть важно.
Главное — учебный пример и правда неплохой.

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

Это ж надо было так все с головы на ноги перевернуть.

AVC>На простом примере демонстрируется, что чистое ФП плохо совместимо с модульностью и ООП.

А модульность-то с какого бока с "чистым ФП" не совместима? С каких пор для нее присваивание нужно?

AVC>Без присваиваний, оказывается, это не дается.

AVC>Т.е. в чистом виде ФП применимо в сравнительно узкой области, а за ее пределами разговоры о "простоте подстановочной модели" — это разговоры в пользу бедных.

О как, нет ООП, значит, и не годится. Сурово.

AVC>Вот и приходится все время подменять тему обсуждения: вместо ФП мы уже говорим о ФЯ, а вместо ФЯ — о "отдельных функциональных конструкциях" в императивных языках, а заодно приписываем какую-то "функциональность" конструкциям, с ФП (прозрачностью по ссылкам) не связанным: паттерн-матчингу, разным видам типизации, делегатам и т.д.
AVC>Короче, как это все странно выглядит.
AVC>И сдается мне, дело не в тупых императивщиках, а в "консерватории" (т.е. в ФП) что-то не так.

То есть отсутсвие ООП в чистых ФЯ мешает императивным программистам понимать ФП; в том числе и O'Caml со Scheme, в которых и присваивание и ООП есть?
Логично.

*Шепотом*
Даже в Haskell есть на самом деле присваивание и даже ООП.

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

Г>Это ж надо было так все с головы на ноги перевернуть.

Переверни обратно.

И с этой удобной позиции объясни, почему ФП плохо дается императивщикам.

AVC>>На простом примере демонстрируется, что чистое ФП плохо совместимо с модульностью и ООП.
Г>А модульность-то с какого бока с "чистым ФП" не совместима? С каких пор для нее присваивание нужно?

Напомню, что речь шла о примере из 3.1.2 The Benefits of Introducing Assignment.
"Модульность" я здесь использую в смысле coupling/cohesion, information hiding etc.

AVC>>Без присваиваний, оказывается, это не дается.
AVC>>Т.е. в чистом виде ФП применимо в сравнительно узкой области, а за ее пределами разговоры о "простоте подстановочной модели" — это разговоры в пользу бедных.

Г>О как, нет ООП, значит, и не годится. Сурово.

Мне и правда следовало бы сказать не "ООП", а "объекты" (главное, что они обладают состоянием).

Г>То есть отсутсвие ООП в чистых ФЯ мешает императивным программистам понимать ФП; в том числе и O'Caml со Scheme, в которых и присваивание и ООП есть?
Г>Логично.

Не так.

Мне (как тупому императивщику) непонятно, что такое ФП с присваиваниями.

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

AVC>Переверни обратно.

AVC>И с этой удобной позиции объясни, почему ФП плохо дается императивщикам.

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

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

AVC>"Модульность" я здесь использую в смысле coupling/cohesion, information hiding etc.

Да нет проблем, это как раз даже в Haskell идет все в комплекте. См., например, как там ATD реализуются через ограничение экспорта в отдельных модулях.
Про параметризуемые модули и функторы в ML упоминать наверное и смысла нет.

AVC>Не так.

AVC>Мне (как тупому императивщику) непонятно, что такое ФП с присваиваниями.

Абсолютно то же самое, что и ФП с вводом-выводом. Совершенно одного порядка вещи.

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

Г>Да там выше объяснили уже. Потому же, почему на иностранный язык всегда сложнее учить, чем "родной". В общем случае, потому что новые идеи всегда хуже даются чем старые и уже усвоенные.
Г>В психологии это называется ригидность. С возрастом только усугубляется.
Г>Справиться с этим можно только если заранее сознательно стараться держать open mind.

Это, скорее, моральная проповедь (с содержанием которой я согласен), а не разбор конкретных трудностей усвоения ФП императивщиками.

Г>Если не держать, то одинаково сложно будет учить что Haskell, что Oberon (который вообще что-то никто выучить "не может").

Кто-нибудь жаловался на сложность Оберона?
Мол, Марья Ивановна, честное слово, учил-учил, учил-учил, ну никак не могу выучить этот проклятый Оберон!
Мой личный опыт говорит, что Оберон очень простой язык (я даже не могу сказать, что "учил" его; свободно писать на нем начал сразу; справедливости ради, то же можно сказать и про Scheme), а Оберон-система основана на нескольких простых принципах, немногим более сложных, чем язык.
А вот про Хаскель говорят иное. (Правда, кто освоил, хвалит, что тоже важно.)
Интересно, что в Оксфорде языки программирования изучают в такой последовательности: (1) Хаскель, (2) Оберон, (3) все остальное.

AVC>>"Модульность" я здесь использую в смысле coupling/cohesion, information hiding etc.

Г>Да нет проблем, это как раз даже в Haskell идет все в комплекте. См., например, как там ATD реализуются через ограничение экспорта в отдельных модулях.
Г>Про параметризуемые модули и функторы в ML упоминать наверное и смысла нет.

Вопрос: откуда они параметризуются?
Если извне, то модульность ли это?
Меня вот что интересует.
В "обыкновенном" императивном программировании (в ООП особенно) именно побочные эффекты зачастую являются источником значительной гибкости.
Возможно, это связано с косвенностью (вызовов).
Мы обращаемся к переменной (не в математическом смысле) — это может быть процедурная переменная или указатель на объект.
Короче, я не стану распространяться на тему ООП (и косвенности, как способа решать те или иные проблемы ПО). Все это, скорее всего, ты лучше меня знаешь.
Главное, что это мощное средство управления "настройками" ПО. Чтобы модифицировать (например, подстроить под конкретного заказчика) поведение/вид программы достаточно поменять совсем чуть-чуть.
Я сильно подозреваю, что такой гибкости мы добиваемся именно за счет "нефункциональности" наших программ.

AVC>>Мне (как тупому императивщику) непонятно, что такое ФП с присваиваниями.
Г>Абсолютно то же самое, что и ФП с вводом-выводом. Совершенно одного порядка вещи.

Если это то же самое, то переформулирую вопрос: что такое ФП с вводом-выводом?
Я вот слышал, что ввод-вывод по своей природе императивен.

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

AVC>Если это то же самое, то переформулирую вопрос: что такое ФП с вводом-выводом?
AVC>Я вот слышал, что ввод-вывод по своей природе императивен.

Да ничего там особенного с ним нет. С ленивыми языками проблемы, это да, но далеко не все ФЯ ленивые.
Ввод-вывод не столько императивен, сколько детерминирован, важно, чтобы порядок операций сохранялся. Поэтому проблемы только в тех языках, которые этот порядок меняют.

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

AVC>>Я вот слышал, что ввод-вывод по своей природе императивен.

Q>Да ничего там особенного с ним нет. С ленивыми языками проблемы, это да, но далеко не все ФЯ ленивые.

Действительно, не все ФЯ ленивые.
Но, IMHO, важно то, что "лень" основана на "функциональности" aka "референциальной прозрачности".
Если есть проблемы с ленивыми языками, то именно потому, что есть проблемы с ФП как таковым.

Q>Ввод-вывод не столько императивен, сколько детерминирован, важно, чтобы порядок операций сохранялся. Поэтому проблемы только в тех языках, которые этот порядок меняют.

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

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

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

D> Честно говоря, не знаю, что в ФП для императивщиков является самым трудным. Ау, императивщики!

Ломка мышления. Как ты правильно сказал начинают работать совсем другие мышцы.
С чем бы это сравнить. Допустим гребля на каноэ и езда не велосипеде.
Как ? Тут нет весел ? И работать надо ногами ? Вы наверное шутите.. Ах, оно еще в базовом варианте и плавать не умеет, а необходимо делать изврат в виде водного велосипеда ??
И так далее... Кто-то ломает мышление. Кто-то нет.
Такие дела (с)

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

D>Вместо циклов и состояний — рекурсия и чистые первоклассные функции.

Если использование хвостовой рекурсии вместо циклов не вызывает проблем (по крайней мере, в Scheme), то использование чистых функций вместо состояний — вызывает.
По первому впечатлению, это приводит к перекосам в структуре программы.
Вот отрывок из вышеупомянутого раздела SICP (3.1.2):

(define rand
  (let ((x random-init))
    (lambda ()
      (set! x (rand-update x))
  x)))
Разумеется, ту же последовательность случайных чисел мы могли бы получить без
использования присваивания, просто напрямую вызывая rand-update. Однако это
означало бы, что всякая часть программы, которая использует случайные числа, должна
явно запоминать текущее значение x, чтобы передать его как аргумент rand-update.
Чтобы понять, насколько это было бы неприятно, рассмотрим использование случай-
ных чисел для реализации т. н. моделирования методом Монте-Карло (Monte Carlo
simulation).

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

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

D>скажем так: редкая птица долетит...

А потом все еще делают такие озабоченные лица и начинают разводить руками и спрашивать друг у друга: с чего это вдруг императивщикам трудно дается ФП?!
— Вот Вы знаете?
— Нет!
— А Вы?
— Понятия не имею!!
— Императивщики? Боже, кто это?!

D>(2) это в 99% случаев совершенно не нужно, поскольку чистое ФП решает подобные задачи архитектурно по-другому. В Хаскелле грязные ботинки снимают в IO-прихожей, зато в остальном доме чисто.

Факт, архитектурно по-другому.
А как?

И потом, злые языки говорят, что монады (IO, списки и т.п.) — скрытый императив; но он, дескать, любит, чтобы его называли чистым ФП.
Вот и разберись...

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

AVC>И потом, злые языки говорят, что монады (IO, списки и т.п.) — скрытый императив; но он, дескать, любит, чтобы его называли чистым ФП.

Ничего скрытого. Монады позволяют моделировать императивную модель вычислений. Оставаясь при этом чистым ФП. Можно на компьютере во всех деталях смоделировать работу гидравлического пресса. От этого компьютер не станет гидравлическим прессом.

Есть одна монада (IO), которая отвечает за работу с окружающим миром. Работа с окружающим миром сделана в Хаскелле через монаду именно из-за того, что монады способны чисто функционально описывать императивную модель вычислений. Были и другие предложения для IO, но в Хаскелле был выбран такой способ.

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

Привет delphiнам!

Г>>> Про параметризуемые модули и функторы в ML упоминать наверное и смысла нет.
A>> Вопрос: откуда они параметризуются?
A>> Если извне, то модульность ли это?
G>Примерно оттуда же, откуда параметризуются generic packages в Аде. Но Вы же не станете утверждать, что в Аде нет модульности?

Конечно, не стану.
Но для меня важно, что модуль может иметь собственные переменные (и собственнически инкапсулировать их), а в ФП это невозможно (?).
До меня потихоньку доходит, что мы, императивщики, не так уж рвемся расставаться с побочными эффектами.

A>> В "обыкновенном" императивном программировании (в ООП особенно) именно
A>> побочные эффекты зачастую являются источником значительной гибкости.

G>Оператор GOTO тоже даёт значительную гибкость, вот только Вы от него почему-то отказались вслед за Виртом и Хоаром...
G>Так почему бы не сделать следующий шаг и не отказаться от побочных эффектов? Ну хотя бы минимизировать их использование только до ввода/вывода...

У самих, между прочим, тоже рыльце в пушку: монады-то не только для ввода/вывода...

А если серьезно, то как обойтись без goto мы знаем. Да и теорема Боэма-Джакопини есть.
А вот как обойтись вообще без побочных эффектов (ввод/вывод не в счет) — мы просто не знаем...

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

AVC>У самих, между прочим, тоже рыльце в пушку: монады-то не только для ввода/вывода...

Да монады — это обычный класс типа; интерфейс и не более того. Правда весьма полезный. Нет там никакого волшебства и железячных хаков. Ввод-вывод, ясный пень, должен общаться с внешним миром, но выбор монадического интерфейса для него — просто дизайнерское решение (одно из рассматривавшихся в своё время). Для чистого и ленивого языка — то что доктор прописал.

AVC>А вот как обойтись вообще без побочных эффектов (ввод/вывод не в счет) — мы просто не знаем...

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

-- identity function

id               :: a -> a
id x             =  x

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

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

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

MODULE M;
  TYPE
    Object* = POINTER TO RECORD ... END;
    ConcreteObject = POINTER TO RECORD (Object) ... END;
    FabrProc* = PROCEDURE () : Object;
  ...
  VAR
    fabrique*: FabrProc;
  ...
  PROCEDURE DefaultFabrique () : Object;
    VAR p: ConcreteObject;
  BEGIN
    NEW(p);
    ... (* инициализация *)
    RETURN p
  END DefaultFabrique;

BEGIN
  fabrique := DefaultFabrique
END M.

Код a-la Oberon, но это совершенно неважно. Речь идет об обычном "порождающем" паттерне.
Главное, объекты какого-то типа создаются через фабричную процедуру.
Мы хотим ее поменять (прямо или косвенно переприсвоив значение fabrique), чтобы обращение к fabrique из произвольных мест программы приводило к созданию объектов иного конкретного типа, отличного от типа по умолчанию.
Как это делается в ФП?

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

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

AVC>Код a-la Oberon, но это совершенно неважно. Речь идет об обычном "порождающем" паттерне.
AVC>Главное, объекты какого-то типа создаются через фабричную процедуру.
AVC>Мы хотим ее поменять (прямо или косвенно переприсвоив значение fabrique), чтобы обращение к fabrique из произвольных мест программы приводило к созданию объектов иного конкретного типа, отличного от типа по умолчанию.
AVC>Как это делается в ФП?

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

-- Типа фабрика, генерирующая функции - прибавлятели числа n (на самом деле это обычное сложение (+) )
mkAdder n = \m -> n + m

-- Генерируем конкретный прибавлятель (семёрки) (на самом деле это сечение (7+) )
add7 = mkAdder 7
-- Другой конкретный прибавлятель (восьмёрки) (на самом деле это сечение (8+) )
add8 = mkAdder 8

-- сессия Hugs:
--   Main> add7 1
--   8 :: Int
--   Main> add7 2
--   9 :: Int
--   Main> add8 1
--   9 :: Int

Техника зовётся частичное применение. В общем виде

-- (1) "Фабрика"
--      Любая функция двух (или более) произвольных аргументов (типы аргументов t1 и t2, возвращаемое значение t3)
f::t1->t2->t3 

-- (2) нуль-арная функция (или более сложное выражение) подходящего типа
v1::t1


-- порождают в результате частичного применения 
g = f v1 -- унарную функцию типа g :: t2->t3 


-- которую потом можно применить к какому-нибудь 
v2::t2
g v2 --  получив результат типа t3

У функции всё что есть, так это сколько-то аргументов со своими типами и возвращаемое значение со своим.

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

D>Э, понимаешь, беда в том, что в чистом ФП ввиду отсутствия состояний с объектами тоже как-то не очень. Нету их. Поэтому фабрика может генерировать только функции. А это можно делать в любом количестве без всяких "порождающих" паттернов

Так весь фокус в том, что их есть! Точнее, можно сделать, если хочется. С сексуальными типами можно сделать хоть черта лысого.

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

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

D>>Э, понимаешь, беда в том, что в чистом ФП ввиду отсутствия состояний с объектами тоже как-то не очень. Нету их. Поэтому фабрика может генерировать только функции. А это можно делать в любом количестве без всяких "порождающих" паттернов

PM>Так весь фокус в том, что их есть! Точнее, можно сделать, если хочется. С сексуальными типами можно сделать хоть черта лысого.

Дык о чём я выше писал здесь. Просто прежде чем вступать в интимные отношения с sexy types, нужно чётко понимать, что всё есть комбинатор, и SKI — исток его (ну или, что всё сводится к лямбде).

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

M>

M>-- Ну понятно, да, плюем на переменную, нас интересует только состояние
M>getState (variable, state) = (_, state)

M>-- А здесь передаем пару, новое состояние, и возвращаем пару с той же переменной, но с новым состоянием.
M>putState (variable, state) newState = (variable, newState)
M>

M>теперь попробуем переписать наш код с использованием функций
M>

M>-- допустим это наша переменная а, со значением 2.
M>state = ("a",2)
M>-- получаем значение нашего состояние, то есть выполняем строчку
M>-- value <- getState   
M>let (initialVariable, initialState) = get state in
M>-- здесь мы изменяем значение нашей переменной на значение initialState + 1, то бишь 2+1 = 3
M>-- то есть выполняем строчку putState (value + 1)   
M>    let (initialVariable, changedState) = put (initialVariable, initialState) initialState + 1 in
M>-- это мы уже проходили, получаем измененное значение.
M>        let (initialVariable, finalState) = get (initialVariable, changedState) in
M>--     и возвращаем результат
M>           return finalState
M>

M>Вуаля. Вот пример состояния в чисто функциональном стиле.
M>По сути ничего страшного. У нас есть пара (переменная, значение) на get мы возвращаем значение из этой пары, на set он же put — возвращаем новую пару (переменная, новое значение).
M>Синтаксис с let выражениями выглядит жутковато, и поэтому этот велосипед обсыпали сахаром и обозвали State.

Во-первых, спасибо за попытку объяснить суть дела простым человеческим языком.
Правда, я сильно туплю (может быть, час такой).
Насколько я понял, вложенность let существенна, иначе порядок действий (чисто императивное понятие) не будет соблюдаться.
Видимо, важно и то, что используется пара (переменная, значение), хотя и не вполне понял — почему.
Если бы не пара, я пожалуй брякнул бы что-нибудь вроде: ба! да это же старый добрый преинкремент ++state.
В смысле:

int state = 2;
...
++state;

Ведь, правда же, как иногда "работает" ++state:
1. загрузить значение переменной state в регистр;
2. увеличить это значение на единицу;
3. запомнить его обратно в state;
4. "вернуть" (т.е. использовать в выражении) новое значение.
Последовательность шагов, кажется, совпадает полностью.

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

Вопрос вдогонку.

Чем это принципиально отличается от

(define someOperation
  (let ((state 2))
    (lambda ()
      (set! state (+ state 1))
  state)))

в смысле функциональной "чистоты"?

AVC>Насколько я понял, вложенность let существенна, иначе порядок действий (чисто императивное понятие) не будет соблюдаться.
Естественно. Мы же эмулируем императивность. Было бы странно если бы наша эмуляция не выполняла этого свойства

AVC>Если бы не пара, я пожалуй брякнул бы что-нибудь вроде: ба! да это же старый добрый преинкремент ++state.
Угумс. Ты все правильно понял это действительно аналог инкремента

AVC>Последовательность шагов, кажется, совпадает полностью.

"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери

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

AVC>Чем это принципиально отличается от
AVC>

AVC>(define someOperation
AVC>  (let ((state 2))
AVC>    (lambda ()
AVC>      (set! state (+ state 1))
AVC>  state)))
AVC>

AVC>в смысле функциональной "чистоты"?
Хороший вопрос. Я сильно все упростил в первом посте, в основном потому что спать хотелось

Здесь у тебя побочный эффект спрятан внутри функции.
В Хаскеле же все побочные эффекты спрятаны внутри монады.
То бишь у нас есть наш любимый интерфейс и пара классов его реализующих.

interface ICalculation
{
    // Обрати особое внимание на то, что возвращает гет. 
    ICalculation get
    set
}

class Maybe : ICalculation
class State : ICalculation

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

Еще одна аналогия. Процессы Эрланга. Внутри процесса можно использовать побочные эффекты (через process dictionary) но на другие процессы это никак не повлияет, потому что они общаются исключительно сообщениями.

Такие дела.

"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери

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

PM>1) Как работает этам виртуальная машина, определяем мы сами, перегружая оператор ";"
PM>2) Определяем мы ее на чистом ФЯ, поэтому, несмотря на императивный вид, она остается чисто функциональной.

Вот у меня возник вопрос — императивную модель вычислений мы, понятно, сконструировать можем. А прологовскую, с бэктрэкингом? Я уверен, что можно, но явных ссылок что-то не нашёл.

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

D> императивную модель вычислений мы, понятно, сконструировать можем. А прологовскую, с бэктрэкингом?

Ну это, через жо... в смысле через императивную модель. Как вариант

А по сути мне кажется что это будет нечто похожее на монаду Maybe...

"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери

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

AVC>>Если бы не пара, я пожалуй брякнул бы что-нибудь вроде: ба! да это же старый добрый преинкремент ++state.
M>Угумс. Ты все правильно понял это действительно аналог инкремента

Я "зацеплюсь" за этот пункт, наверное, далеко не самый важный.
Когда смотришь (как я) на ФП со стороны, идея "прозрачности по ссылкам" и ее потенциальных выгод усваивается очень легко.
А вот как может быть "чисто функциональным" аналог оператора ++i, как раз и непонятно.
Возможно, это смешные трудности. Но я, как императивщик, вижу их именно здесь.

Что-то вроде: "Какое же это чистое ФП?! Это же xxx!"

Т.е. трудности могут быть как раз там, где функциональщики думают, что уж тут-то императивщикам должно быть все ясно.
А бедный императивщик смотрит на конструкцию, которую ему предлагают в качестве функциональной, и думает, что такую же засадил вчера в собственную программу, где ФП и не ночевало.

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

Ага BRules Олега Киселёва в действии

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

AVC> А вот как может быть "чисто функциональным" аналог оператора ++i, как раз и непонятно.
AVC> Возможно, это смешные трудности. Но я, как императивщик, вижу их именно здесь.
AVC> Что-то вроде: "Какое же это чистое ФП?! Это же xxx!"

Как говорят итальянцы, приветствуя друг друга: "Чао!"

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

main = do x <- return 1
          print x
          x <- return 2
          print x
          x <- return (x + 3)
          print x

выведет, конечно же, 1, затем 2, датем 5 (2+3).
Это выглядит императивно, так почему же это на самом деле функционально чистый код?
А вот почему: конструкция do раскручивается в несколько вложенных друг в друга безымянных функций, у каждой из которых есть параметр x. Почти буквально это будет так:

main = let unnamed1 x =
              (print x) >>
              let unnamed2 x = 
                     (print x) >>
                     let unnamed3 x =
                            print x
                     in  return (x + 3) >>= unnamed3
              in  return 2 >>= unnamed2
       in  return 1 >>= unnamed1

Раскрытие do-выражения получилось страшным. Упрощённо в Scheme можно представить так:

(define (main)
  (define (unnamed1 x)
    (define (unnamed2 x)
      (define (unnamed3 x)
        (printf "~a~n" x))
      (printf "~a~n" x)
      (unnamed3 (+ x 3)))
    (printf "~a~n" x)
    (unnamed2 2))
  (unnamed1 1))

Состояние переменной x постоянно протаскивается через параметр x от одной функции к другой и меняется, но при этом никаких деструктивных операций не происходит, в отличие от ++x. Присваивание везде однократное!

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

Ах да, так как тут имеется вывод, то есть и императивная операция — print. Но тут уж ничего не попишешь, состояние изображения на мониторе меняется императивно... :о)

Как говорят те же итальянцы, прощаясь друг с другом: "Чао!" :о))

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

PM>Я, честно говоря, не совсем внимательно следил за тем, как вы пришли к оператору инкремента.

value <- getState   
putState (value + 1)   
value <- getState   
return value

вот этот кусочек кода который я разбирал в самом первом примере очень сильно смахивает на

return ++value

"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери

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

AVC>Мы хотим ее поменять (прямо или косвенно переприсвоив значение fabrique), чтобы обращение к fabrique из произвольных мест программы приводило к созданию объектов иного конкретного типа, отличного от типа по умолчанию.
AVC>Как это делается в ФП?

В данном случае (в твоем примере) — это работа с глобальной переменной. Помимо подхода "найти функцию fabrique по имени", есть ещё возможность не использовать глобальную переменную, а передавать переменную в контексте, либо получать из глобальной переменной (примеров туча — вот под рукой JNDI, например). С передачей переменной в контексте вызова, наверное, всё ясно и тут нечего обсуждать, а вот использование глобальной переменной в чистом языке можно только с помощью хаков: в Haskell это, например, unsafePerformIO, либо ImplicitParameters. Так что для совсем-совсем чистого языка остается только передача в контексте имхо. Параметром, например, или вшить в монаду

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PM>

PM>struct StatelessMachine
PM>{
PM>    const int counter;
PM>    const string output;

PM>    StatelessMachine(int a_counter=0, string a_output="") :
PM>        counter(a_counter),
PM>        output(a_output) {}

PM>    StatelessMachine inc() const { return StatelessMachine(counter+1, output); }
PM>    StatelessMachine dec() const { return StatelessMachine(counter-1, output); }
PM>    StatelessMachine set(int x) const { return StatelessMachine(x, output); }
PM>    StatelessMachine rand() const  { return StatelessMachine(::rand(counter), output); }
PM>    StatelessMachine print() const { return StatelessMachine(counter, 
PM>                                                             output+to_string(counter)+"\n"); }
PM>};
PM>

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

).
Примерно то же пытаются объяснить мне и geniepro, и др. функциональщики.
Ребята, я очень ценю ваши усилия, и очень вам благодарен.

Но то ли сказывается влияние стресса (завтра у меня сдача программы), то ли еще что-то, но я до конца "не въезжаю".

А может быть, мы вплотную подобрались к тому самому "слепому пятну", который мешает одному конкретному императивщику (мне

) понять ФП.
Да, я вижу, что в одном случае (StatefulMachine) мы используем многократное присваивание, а в другом (StatelessMachine) — однократное.
Я вижу, что императивную программу можно исполнить как бы функциональным способом.
Т.е. сам "трюк", его технику я понимаю.
Но здесь есть какая-то загвоздка для моего сознания.

Во-первых, требуется много копий StatelessMachine, чтобы исполнить императивную программу.
Причем не совсем ясно, для чего такие ухищрения, ведь "новая" машина полностью заслоняет собой "старую", и, следовательно, "старая" машина уже не может быть использована.

Во-вторых, множественные StatelessMachine исполняются все же на одной-единственной (в данном случае) машине с состояниями.
Это оставляет ощущение какого-то "надувательства", что-то вроде того, что если машины без состояния "расползутся", то "запечатать" их можно только в машине с состояниями большего размера.

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

Все это, конечно, могут быть просто мои глупости.
Возможно, завтра, уже без стресса, посмотрю спокойно и все пойму.

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

A>> В "обыкновенном" императивном программировании (в ООП особенно) именно
A>> побочные эффекты зачастую являются источником значительной гибкости.

G>Оператор GOTO тоже даёт значительную гибкость, вот только Вы от него почему-то отказались вслед за Виртом и Хоаром...

Здесь, IMHO, есть одна важная тонкость.
Действительно, от оператора goto мы отказались (и об этом не жалеем).
Но это не значит, что мы отказались от переходов вообще.
Мы просто следуем определенной дисциплине.
В конце концов, разве IF ... THEN ... ELSIF ... END, WHILE ... DO ... END и т.д. не включают в себя переходы?
Но только подчиненные дисциплине структурного программирования.

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

AVC>Здесь, IMHO, есть одна важная тонкость.
AVC>Действительно, от оператора goto мы отказались (и об этом не жалеем).
AVC>Но это не значит, что мы отказались от переходов вообще.
AVC>Мы просто следуем определенной дисциплине.

Золотые слова! Смотри: goto плох, потому что превращает программу в вермишель, запутывая логику. Мы вынужденны параллельно поддерживать инфраструктуру меток или нумерацию строк программы.

Переменные, в каком-то смысле, те же метки, и их избыток тоже ведёт к запутыванию логики. В ИЯ мы вводим их не задумываясь, неоднократно меняем их значение; реализуя сложный алгоритм, мы вынуждены держать в голове все пути к данной точке программы, для того чтобы проиграв в голове все допустимые изменения переменных, осуществить требуемые в этой точке проверки. В Хаскелле "переменные" просто сокращают запись:

let x = expr1 in expr2

Выражение expr1 может быть весьма сложным и тип его тоже может быть далёким от тривиального (например, это может быть функция). Мы вводим такие "переменные", когда обнаруживаем, что в выражении expr2 одно и то же подвыражение (expr1) встретилось несколько раз.

В ИЯ мы строим программу снизу вверх: соединяем детальки конструктора (переменные) в большом количестве, в надежде, что получившаяся конструкция будет работать как надо. В ФЯ мы программируем сверху вниз: берём задачу и начинаем нарезать её на логические части, пытаясь свести её к известным комбинаторам. И тот и другой подход непрост, и каждый требует специфических сноровок. (этот абзац написан в контексте оператора ИМХО )

__> Периодически читаю топики подобные этому и статьи разных популяризаторов ФП. И у меня
__>все время возникает вопрос а как это можно реально применить? Примеры a->b->c->d->....->z
__>уже сидят в печенках. А слабо заменить это реальными goods,sales,employers и.т.д. И показать
__>преимущества ФП на РЕАЛЬНЫХ(многопотчных, с гуеей, с БД, с удаленными вызовами) задачах. А самое главное как можно выполнить декомпозицию такой реальной задачи (НЕ МАТЕМАТИЧЕСКОЙ!!!!) в терминах, абстракциях и паттернах ФП. И наглядно показать где здесь преимущества.

Согласен. Вот в этой статье Функциональное программирование в Nemerle я попытался донести функциональные вещи в наиболее поплярном виде (ну, насколько смог). К сожалению, она пока доступна только в бумажной версии RSDN Magazine, но через некоторое время появися и на сайте.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

__>уже сидят в печенках. А слабо заменить это реальными goods,sales,employers и.т.д. И показать
__>преимущества ФП на РЕАЛЬНЫХ(многопотчных, с гуеей, с БД, с удаленными вызовами) задачах.
http://www.classes.cs.uchicago.edu/archive/2007/winter/51091-1/papers/Murthy-popl07.pdf

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

PM>http://www.classes.cs.uchicago.edu/archive/2007/winter/51091-1/papers/Murthy-popl07.pdf

Прикольно. В качестве выгоды от функциональных языков приводится пример с заменой XSL на ML. Мне это кажется... э-э... алогичным.

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

__>Считайте это пост воплем души ТУПОГО императивщика.
__> Периодически читаю топики подобные этому и статьи разных популяризаторов ФП. И у меня
__>все время возникает вопрос а как это можно реально применить? Примеры a->b->c->d->....->z
__>уже сидят в печенках. А слабо заменить это реальными goods,sales,employers и.т.д. И показать
__>преимущества ФП на РЕАЛЬНЫХ(многопотчных, с гуеей, с БД, с удаленными вызовами) задачах. А самое главное как можно выполнить декомпозицию такой реальной задачи (НЕ МАТЕМАТИЧЕСКОЙ!!!!) в терминах, абстракциях и паттернах ФП. И наглядно показать где здесь преимущества.

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

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

Но большинство идей ФЯ (матчинг, функции высшего порядка, guards, tail recursion, макросы) как наркотик,
единожды попробывал, и уже в обычные языки выглядят убогими и очень многословными. И тогда обратил свой
взгляд на смешанные языки, в моем случае это Scala.
Использование таких языков позволяет не зацикливаться на решении какой-то проблемы в функциональном
стиле, а просто написать ее в императивном и по мере необходимости (или нахождения решения для
функционального стиля) это можно отрефакторить.

Пример из Scala By Example:

Т.е. сначала пишем императивно:

def sort(xs: Array[int]) {
  def swap(i: int, j: int) {
    val t = xs(i); xs(i) = xs(j); xs(j) = t
  }
  def sort1(l: int, r: int) {
    val pivot = xs((l + r) / 2)
    var i = l; var j = r
    while (i <= j) {
      while (xs(i) < pivot) { i = i + 1 }
      while (xs(j) > pivot) { j = j - 1 }
      if (i <= j) {
        swap(i, j)
        i = i + 1
        j = j 1
      }
    }
    if (l < j) sort1(l, j)
    if (j < r) sort1(i, r)
  }
  sort1(0, xs.length 1)
}

Потом легко переделываем на функциональный (правда тут изменилась семантика,
т.к. вернется копия массива, в отличии от императивной, которая работает
inplace, но это не важно, важно видеть, что один и тот же язык позволяет
использовать оба подхода):

 def sort(xs: Array[int]): Array[int] =
  if (xs.length <= 1) xs
  else {
    val pivot = xs(xs.length / 2)
    Array.concat(
      sort(xs filter (pivot >)),
           xs filter (pivot ==),
      sort(xs filter (pivot <)))
  }

Так что может и не надо сразу лезть в пекло, а можно войти в этот мир постепенно

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

D>>Где здесь нарушение логики?

ANS>В том, что один ФЯ меняют на другой.

Ну они там какие-то выигрыши декларируют. Столбики чем правее, тем ниже

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

D>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Прикольно. В качестве выгоды от функциональных языков приводится пример с заменой XSL на ML. Мне это кажется... э-э... алогичным.

D>Где здесь нарушение логики? Идея, которую я уже несколько раз встречал: сделать в Enterprise всю высокоуровневую склейку разнородных компонент на каком-либо функциональном языке. С одной стороны ФЯ для этого достаточно гибкие, с другой — идея функций как чёрных ящиков и отсутствие изменяемых состояний позволяет легко абстрагироваться от внутренней машинерии склеиваемых компонентов.

Все привыкли, что Enterprise — это такая многокомпонентная штука, позволяющая подключать необходимое число
независимых компонентов даже на разных машинах (они сами картинки банков приводят), и как итог предлагается
отказаться от такой многокомпонентности (они в выводах пишуть что как де хорошо, что все в одной vm вертиться)
и сделать по сути standalone приложение... Но вопрос, а когда нехватит производительности одного компутера,
тогда получается будет выбор: растить дальше (что не всегда возможно) или разбивать на куски. Вот тут то
и вылезет то, что нагородили в ентерпрайзе за годы его существования. Да и замена xsl на ml — суть замена
одного фя на другой. Но только еще предлагается вместо использования кубиков захардкодить это все
на ml-е... Но если захардкодить логику в программе с которой они сравнивали, думаю производительность
уже не будет так сильно разниться...

По этому и возник вопрос, к чему они все это написали? И у имепративщиков (а многие приходят с большим
бакграундом java или DCOM + Базы данных) и возникают вопросы, как те решения, что они премняли раньше
решать в ФЯ. И ответов действительно нет. Хотя части из функциональщины действительно недурно помогают.
Но полностью отказаться от императива в пользу ФЯ — думаю это не совсем разумно (по факту весь придыдущий
опыт идет на свалку) ...

ЗЫ: на правах оффтопика
Все таки мир у нас императивен. Когда нам надо сесть в машину мы выполняем метод "открыть" над объектом
"машина", а не делаем копию машины рядом, но уже с открытой дверью...

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

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

A>>ЗЫ: на правах оффтопика
A>>Все таки мир у нас императивен.

D>Мир пассивен. Это воля императивна. А разум — декларативен.
+1 (это твое? или кто из древних?

)

A>>Когда нам надо сесть в машину мы выполняем метод "открыть" над объектом
A>>"машина", а не делаем копию машины рядом, но уже с открытой дверью...

D>А мы пишем функцию
D>

D>открыть :: нечтоСРучкой a => a -> a
D>открыть = потянутьНаСебя . ручкуВверх  
D>

D>и пускай компилятор думает, сколько и чего там нужно копировать, и нужно ли вообще

Но ведь он может и скопировать... хотя если рассмотреть открывание ручки на прямой
времени, то конечно получается копия

(машина то в момент времени t1 так и осталась
с закрытой дверью , а в t2 — уже с открытой)

ЗЫ: а вообще очередной раз убеждаюсь, что мозги >10 лет работавшие с императивом
нереально сложно переделать на фстиль... (для меня во всяком случае)... остается
только идти в обход

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

A>Потом легко переделываем на функциональный (правда тут изменилась семантика,
A>т.к. вернется копия массива, в отличии от императивной, которая работает
A>inplace, но это не важно, важно видеть, что один и тот же язык позволяет
A>использовать оба подхода):

A>

A> def sort(xs: Array[int]): Array[int] =
A>  if (xs.length <= 1) xs
A>  else {
A>    val pivot = xs(xs.length / 2)
A>    Array.concat(
A>      sort(xs filter (pivot >)),
A>           xs filter (pivot ==),
A>      sort(xs filter (pivot <)))
A>  }
A>

A>Так что может и не надо сразу лезть в пекло, а можно войти в этот мир постепенно

Но в чем, всеже, прелесть Функционального Программирования???

А пример с сортировкой, который приводится (во многих статьях о ФП) в качестве превосходства над ИП, наверно, не удачен.
Это просто другая реализация алгоритма, которую можно легко использовать и в ИП (может не во всех, конечно).
Например Perl:

sub qsort
{
  my $x = shift or return;
  my @sx = @_;
  return qsort( grep { $_<$x } @sx ), $x, qsort( grep { $_>=$x } @sx );
}

Или Perl это тоже ФЯ?

От:	lomeo	http://lomeo.livejournal.com/
Дата:	16.02.07 19:21
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	19.02.07 11:05
Оценка:	23 (7) +4

	От:	x-code
	Дата:	18.02.07 09:06
	Оценка:	+9

	От:	Quintanar
	Дата:	27.02.07 09:34
	Оценка:	+9

	От:	AVC
	Дата:	11.03.07 12:45
	Оценка:	35 (4) +3

	От:	mini_root_2
	Дата:	25.03.07 09:36
	Оценка:	13 (2) +3 -1

От:	Курилка	http://kirya.narod.ru/
Дата:	16.02.07 07:38
Оценка:	1 (1) +4 -1

От:	Mamut	http://dmitriid.com
Дата:	21.02.07 07:58
Оценка:	1 (1) +2

	От:	deniok
	Дата:	20.03.07 10:07
	Оценка:	27 (3) +2

	От:	BulatZiganshin
	Дата:	16.02.07 09:51
	Оценка:	25 (5)

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	03.03.07 08:38
Оценка:	9 (1) +3 -1

От:	FDSC	consp11.github.io блог
Дата:	21.02.07 10:13
Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	01.03.07 09:42
Оценка:

	От:	palm mute
	Дата:	20.03.07 10:40
	Оценка:	15 (2) +1

	От:	EvilChild
	Дата:	21.02.07 18:33
	Оценка:	1 (1) +1

	От:	AndreiF
	Дата:	27.02.07 05:13
	Оценка:	12 (1) +1

От:	IT	linq2db.com
Дата:	27.02.07 05:17
Оценка:	+2

От:	geniepro	http://geniepro.livejournal.com/
Дата:	19.03.07 06:20
Оценка:	+1

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	26.03.07 08:39
Оценка:	+1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	27.02.07 02:54
Оценка:

	От:	Алексей П
	Дата:	28.02.07 03:56
	Оценка:

От:	tchingiz	http://i.com.ua/~agp1/ru/
Дата:	02.03.07 07:18
Оценка:

	От:	граммофон
	Дата:	15.03.07 13:44
	Оценка: