"LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.01.09 12:33
Оценка: 9 (4) +13 -7
Здравствуйте, VladD2, Вы писали:

E>>PS. Из статьи можно было бы смело выкинуть, как минимум, 1/3 текста при сохранении той же информативности.


VD>Будешь писать сам — выклинишь.


Обязательно.

VD>А это моя статья, мой стиль и мой подход к изложению.


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

E>>PPS. По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".


VD>Больше конкретики, плиз. Если какие-то места задевают, можно подумать об их замене. А так... это не критика, а наезд.


Конкретика? Их есть у меня (у тебя).

Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.

Там же:

"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."

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

Еще:

"Я понимаю, что это очень непривычно и непонятно (на первый взгляд), но поверьте, что есть целая теория обосновывающая это (теория «лямбда-исчислений» Чёрча)."

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

Или:

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

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

Еще:

"Приводить их реализации я не буду, так как они нетривиальны (уйдет много времени на их reverse engineering), да и занимают довольно много место. Для нас важен сам факт понимания их работы."

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

Далее:

"Кстати, используя расширение синтаксиса, в конце запроса обязательно нужно писать ключевое слово select. Как говорилось в одном анекдоте – «Объясныт это нэлза! Это можьно толко запомныт!!!»."

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

Это только то, что сразу бросилось в глаза и запомнилось.


16.01.09 19:40: Ветка выделена из темы LINQ как шаг к функциональному программированию
Автор: Чистяков Влад (VladD2)
Дата: 28.08.08
— IT
19.01.09 07:51: Перенесено модератором из '.NET' — TK
13.02.09 15:14: Перенесено из 'Философия программирования'
16.02.09 07:39: Перенесено модератором из 'Священные войны' — Хитрик Денис
16.02.09 07:39: Перенесено модератором из 'Священные войны' — Хитрик Денис


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 27.01.09 12:48
Оценка: 15 (1) :))) :))) :))) :))) :)
T>>В смысле? Который день я уже "тусущеся" в этой теме?
VD>Ага.

Please reconsider.

Ни на один мой вопрос ответ "ага" не имеет смысла.

T>>О чем мои комментарии здесь?

VD>А ни о чем. Тупо рекламируешь Хаскель в теме где ему совсем не место и попутно откровенно наезжаешь на окружающих.

Ну, тебе одному меня не окружить, окружающий ты наш.

Я рекламирую Хаскель невероятно удачно подобранными примерами, смелым искромётным юмором и очарованием моей притягательной личности. Назвать этот блестящий комплекс тупым можно только из черной зависти.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 21.01.09 19:17
Оценка: 3 (1) +9 :))
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ


VD>А вообще забавнешая ситуация получается. Когда я спорю с представителями разных лагерей, то все они моментально записывают меня в радикалов, маргиналов и т.п. Но вот что странно! Каждый раз меня записывают в другой лагерь. Говоришь с опупевшим императивщиком который всюду видит операции над битами и ты вдруг злостный функциональщик/декларативщик не понимающий ток в написании реально быстрых программ. Говоришь с фнункциональщиком и ты вдруг чудесным образом переносишся в другую сторону спектра. И те и другие называют меня фанатиком и т.п.


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

В общем-то в спорах это удобно — гипертрофировать слова оппонента, так как крайности проще опровергаются, а ответная реакция людей — либо каждый раз пояснять, что ты не то опровергаешь, либо ответить тебе взаимностью и гипертрофировать твои слова, посему все для тебя фанатики, а ты — фанатик для всех. Более мирный путь (пояснить, что ты не о том) к сожалению менее результативен в споре, ощущение, что оппонент оправдывается и потому неправ, поэтому чаще всего ответная реакция взаимна. Так что в таких спорах не истина рождается, а срач, что мы регулярно и наблюдаем.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 26.01.09 17:13
Оценка: +1 :))) :))) :)
Здравствуйте, VoidEx, Вы писали:

VE>Мне действительно хотелось бы посмотреть на язык с записью короче, чем у Хаскеля.


Не пойму я вас. То меряетесь у кого длиннее, то у кого короче
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 15:24
Оценка: 14 (2) :))) :))
Здравствуйте, LaPerouse, Вы писали:

LP>Более того, на чистом ФЯ нужно программировать императивно (нужно == приходится). Вопрос — нахрена тогда чистый ФЯ.


Угу, и код при этом получается ужасный
Вот понадобилось мне тут числа от 1 до 5 вывести...


{-# LANGUAGE PostfixOperators, NewQualifiedOperators #-}

import Prelude hiding ((++), init, (<=))
import qualified Prelude as P

import Data.IORef (IORef, newIORef, readIORef, writeIORef)
import Control.Monad (when)
import qualified Text.Printf as Pf (printf)

printf s r = readIORef r >>= Pf.printf s

newInt = newIORef 0

infixr 1 =:
(=:) = writeIORef

rx <= y = do
    x <- readIORef rx
    return (P.(<=) x y)

(++) :: IORef Int -> IO ()
(++) = \r -> do
    i <- readIORef r
    r =: i + 1
    
for (init, cond, post) act = do
        init
        loop
    where
        loop = do
            b <- cond
            when b $ act >> post >> loop

main = do
    i <- newInt
    for (i =: 1, i <= 5, (i++)) $
        printf "%i\n" i


А ещё говорят, что на Haskell код меньше, чем на С получается!
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.01.09 16:08
Оценка: +4 -2 :)
Здравствуйте, eao197, Вы писали:

E>Хорошо, пойдет дальше. Про императивных программистов.


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


E>Откуда информация о том, о чем привык думать императивный программист?


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

Но цикл остается центральной идеей императивного программирования — просто потому, что никаких других способов обработки "последовательностей" нету. Точнее, есть рекурсия, но
а) у наивных программистов при ней доступ к глобальным переменным ведет себя как-то странно
б) у продвинутых программистов быстро переполняется стек, "поэтому для больших объемов данных рекурсия неприменима".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 16.01.09 03:28
Оценка: 33 (2) +3
Слушайте, может уже сделаем ветку "Разборки"?
Чтоп не мучаться с придумыванием повода для наезда? Кому скучно — постит новую ветку и его валят всем миром. Пустые понты достали уже... статью вроде обсуждали, не автора.

По собсно статье (больше пустые придирки, не воспринимайте серьёзно):

В примере

var ary = new int[]{ 1, 2, 3, 4, 5 };

int sum = 0;
Array.ForEach(ary, delegate(int elem) { sum += elem; });

foreach (var elem in ary)
  Console.WriteLine(elem);

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

Функциональное вычисление – функция (или если быть точнее – «чистая функция», pure function) – должна принимать некоторые аргументы (входящие данные) на входе, производить вычисление и возвращать некоторый результат. При этом функция не должна создавать никаких побочных эффектов. Под побочными эффектами понимается:

Я-то конеш понимаю, что замыкания и pure functions — разные вещи, может стоило на принципиальной разнице остановиться подробней?

Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел.

Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях.

Ещё стоило бы завести подраздел про то, что любая технология — не панацея и привести ситуации, когда лучше применять конкретные подходы. Привести микротесты, рассказать что вызов _одиночного_ делегата (без списка вызываемых методов) по стоимости сопоставим с virtual call, и что в худшем случае падение производительности будет в 2-5 раз (и что с каждым сп к рантайму соотношение улучшается) в лучшем — будет незаметно из-за стоимости исполнения метода.

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

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

Удачи!
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.01.09 09:25
Оценка: 14 (5)
Здравствуйте, VladD2, Вы писали:

VD>Ты просто не понимаешь. Он идейный несогласный. Его вообще все в моих подходах не устраивает. Мы с ним представители разных мировоззрений. Скажем я не понимаю как можно читать большой проект с бумаги, а он не пнимает зачем нужна навороченная IDE с интеллисенсом, рефакторингом и прочими излишествами вроде навигации по коду.

VD>Он считает, что С++ отличный язык программирования, а меня от него тошнит. Он считает, что средство повышения производительности программиста — это скрипты вроде Руби, а я не уважаю динамически-типизированные языки. И так далее, и тому подобное. В общем, практически нет вещей в программировании на которые у нас были бы похожие взгляды. Ну, разве что на необходимость автоматизированного тестирования. В прочем, и тут у нас разная степень радикализма. Например, я не считаю юнит-тесты панацеей.

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.01.09 13:34
Оценка: +5
Здравствуйте, hugo, Вы писали:

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


H>Любое произведение предполагает чисто субъективный взгляд автора на тему. Говорить автору, что он не правильно выразил свой субъективный взгляд, представляется мне не объективным , ибо произведение написано именно потому, что он, автор, хотел поделиться этим своим субъективным именно так, а не иначе.


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

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

3. Мне казалось, что автор должен быть готов к получению различных отзывов, в том числе и критических. Любые критические отзывы так же субъективны, как и взгляд автора на тему.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 19.01.09 12:06
Оценка: +3 -1
Здравствуйте, VladD2, Вы писали:

VD>А за указание на орфографические ошибки вообще баня положена. Читай внимательно правила.


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

Кстати, что там насчёт "ставить под сомнение профессиональную квалификацию" написано? А то любят некоторые про Блаба писать в обращении к другим программистам. Это типа у них обоснование такое своей правоты
Re: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 20.01.09 09:33
Оценка: :))) :)
E>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.


Вот выделенное шрифтом — это VladD2 написал? Да?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Трурль  
Дата: 22.01.09 07:02
Оценка: :))) :)
Здравствуйте, eao197, Вы писали:

E>1. Мне казалось, что статья в техническом журнале на техническую тему должна по стилю отличаться от форумных постов.


Ну нельзя же выдвигать одинаковые требования к "Успехам Теологических Наук" и "Московскому богомольцу".
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.09 05:14
Оценка: +4
Здравствуйте, eao197, Вы писали:

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


Скажем так. Если программа написана грамотно и при ее реализации использовался преимущественно ФП, то внести изменение будет проще. ФП действительно упрощает отладку. Но накосячить можно на чем угодно. Если в коде бардак, то действительно никакие ФП не помогут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: Vamp Россия  
Дата: 19.02.09 21:02
Оценка: :))) :)
I>Для кого не сложен, для новичка или топа ?
Вообще ни для кого не сложен. Мне стало интересно, что это за ЭЛИТА такая, ФП — прочел статью и понял за 10 минут. Как всегда, много шума из ничего. Стандартный алгоритмы над последовательностями в С++ живут уже больше 10 лет. И лямбды есть, тоже давно уже.
Да здравствует мыло душистое и веревка пушистая.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: hugo Австрия  
Дата: 16.01.09 13:18
Оценка: 41 (1) +2
Здравствуйте, eao197, Вы писали:

Любое произведение предполагает чисто субъективный взгляд автора на тему. Говорить автору, что он не правильно выразил свой субъективный взгляд, представляется мне не объективным , ибо произведение написано именно потому, что он, автор, хотел поделиться этим своим субъективным именно так, а не иначе.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 10:15
Оценка: 15 (3)
Здравствуйте, LaPerouse, Вы писали:

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


В общем, написал.

Мне показалось, что здесь удобно использовать Map

> import qualified Data.Map as M


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

> type Node = Int


Элемент у меня хранит ссылки на узлы, в реальной программе будут скорее всего типы Element и ElementEntry. Для нас это неважно, т.к. на алгоритм не влияет. Также для функционального алгоритма не важно конечный ли это тип с полем isLinear или это функция класса типов Element — аналог твоих интерфейсов. Чтобы было покрасивее (паттерн матчинг) я выбрал тип

> data Element = Element { isLinear :: Bool, leftNode :: Node, rightNode :: Node }


Схема — это просто мап.

> type Scheme = M.Map Node [Element]


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

Во первых, аналог SchemeHelper.getOtherNode. Думаю, у тебя не сильно отличается.

> otherNode :: Element -> Node -> Node
> otherNode (Element _ l r) n
>     | l == n    = r
>     | otherwise = l


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

> mergeElement :: Element -> Element -> Node -> Element
> mergeElement e1 e2 n = Element True (otherNode e1 n) (otherNode e2 n)


Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.

> removeNode :: Node -> Scheme -> Scheme
> removeNode = M.delete


Добавляем элемент. Поскольку добавляется он к уже имеющимся в схеме узлам, то здесь тоже ничего сложного.

> attachElement :: Element -> (Node, Node) -> Scheme -> Scheme
> attachElement el (ln, rn) = go ln . go rn
>     where
>         go = M.adjust (el:)


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

> isEntrantPoint :: Node -> Scheme -> Bool
> isEntrantPoint _ _ = False


И вот только сейчас аналог твоего кода. Можно сравнивать — страшно или нет.

Во-первых, трансформация по одному узлу (то, что у тебя в цикле). Здесь паттерн матчинг (по Element) помогает, но не сильно.
В случае, если мы используем класс Element, будут функции getLeftNode, getRightNode и т.д. Строчка будет чуть длиннее.

> transformWithNode :: Node -> Scheme -> Scheme
> transformWithNode node s
>     | length els /= 2 || isEntrantPoint node s = s
>     | isLinear el1 && isLinear el2 =
>         let el@(Element _ ln rn) = mergeElement el1 el2 node
>          in attachElement el (ln, rn) s
>     where
>         els@(~[el1, el2]) = s M.! node


И собственно функция.

> transform :: Scheme -> Scheme
> transform s = foldr transformWithNode s nodes
>     where
>         nodes = M.keys s


Никаких наворотов не использовано. Код декларативнее.
Отличие — отсутствие булевого результата легко решается — просто тип функций у нас будет Scheme -> (Bool, Scheme).
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 19.01.09 02:48
Оценка: 9 (2) +1
Всем трямс!

Кажись eao197 подумал, что я тоже пытаюсь покритиковать Влада и наставил мне плюсов. Аж 21.

Eao! "Пустые понты достали уже..." относились больше к тебе. Теперь минусуй

Теперь чуть-чуть ответов.

S>>Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел.

VD>С какой целью? Чтобы было проще искать? Или чтобы ссылаться можно было?

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

S>>Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях.

VD>На то есть оглавление. Да и статья не такая большая чтобы ее резать.
VD>Или речь об переупорядочивании разделов?

Да, смысл именно в том, чтобы структура отражала твой замысел и служила костяком. Типа так: Мы плавно подходим к теме А, но говорить о ней можно только после раскрытия тем Б,В, ну и чуть-чуть Г. Если вы в них сечёте — переходите дальше. Если нет — то можете кончно пролистать, но в любом случае вы ничего не поймёте. И по-хорошему идите учите матчасть.

Чтобы не было иллюзий. Оглавление, которое не висит постоянно перед глазами, не очень-то и помогает. Для меня быстрее прокрутить вниз, по ходу быстро сканируя текст, чем искать оглавление, искать в нём раздел и переходить туда. Для небольших статей, естественно.

S>>Ещё стоило бы завести подраздел про то, что любая технология — не панацея и привести ситуации, когда лучше применять конкретные подходы. Привести микротесты, рассказать что вызов _одиночного_ делегата (без списка вызываемых методов) по стоимости сопоставим с virtual call, и что в худшем случае падение производительности будет в 2-5 раз (и что с каждым сп к рантайму соотношение улучшается) в лучшем — будет незаметно из-за стоимости исполнения метода.


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


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

Ну и важны не попугаи, а соотношение в этих попугаях в каждом конкретном случае.

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


VD>1. Это не серьезная статья. Она так задумывалась.

VD>2. Опять же больше конкретики.

1. Так бы и сказали
2. Конкретик хотите? Их есть у меня!

Про анонимные делегаты (кстати, мс и так и так их называет и в принципе раскрывает суть — создаётся делегат на метод; другого доступа к методу нет. Так что вполне нормальный термин):

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

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

Следующая цитата — вообще наезд на эмоциях:

При этом в Microsoft не придумали ровным счетом ничего нового. Примерно так выглядят лямбды почти во всех ФЯ. Так что совершенно непонятно, зачем было лепить в C# 2.0 этот безобразный, длинный и сбивающий с толку синтаксис. Понятно, что вывод типов был сделан только в C# 3.0, но, по крайней мере, все остальное-то точно можно было бы сделать сразу как в лямбда-выражениях!


После

Однако при проектировании .NET-делегатов был сделан ряд ошибок, которые сказались при развитии C# в сторону ФП.
...
Данное решение не создает особых проблем на практике, за исключением того, что вызов делегата медленнее, чем мог бы быть.

возникает желание предложить почитать Абрамса. Допустим, пост от февраля 2004 года. У Абрамса сотоварищи есть много статей, где описывается дизайн рантайма/BCL/шарпа. Перед дальнейшими наездами рекомендую ознакомиться. О производительности:

For those performance oriented among you, please note that if you have a MulticastDelegate that hasn’t been combined with any other delegates the CLR can optimizes for this case during dispatch and in how the JIT compiles the callsite….


Продолжаем.

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

Мнение Джефри Рихтера вас устроит?

In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.

Делегаты проектировались как типизированая реализация callback-ов.

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

Дальше.

Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.

Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше.
Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...

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

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

VD>Другими словами я пытался на пальцах, простыми словами показать людям которые еще не плавают в ФП как рыбы те приемы и подходы которые предлагает ФП.

Ну на самом деле внутри себя оно довольно-таки императивное. И объясняя, что здесь нет чёрной магии, а только все те же методы и делегаты, вы привлечёте куда больше императивщиков. И если честно, мне не совсем нравится попытка использования SQL-синтаксиса. Потому что SQL — декларативный язык. Там вольности частично компенсирует оптимизатор. В случае Linq2Objects — что напишешь, то и получишь. И если ты сам сделал жойн коллекциям из тысячи элементов и добавил туда гроуп да ещё и сортировку — сам себе грабли. Аккуратней надо. Особенно в рабочих проектах.

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


Поддерживаю. Дерзай дальше

P.S. Только заметил:

string Function(int x, string y);

Можно описать как:

int * string -> string

или как:
int -> string -> string


Если я ничего не путаю, в нотации хаскелля/фшарпа первое — это функция, которая принимает тюпл int * string и возвращает string. Второе — carrying функция. Не стоит сразу смущать людей.

P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.01.09 21:30
Оценка: 4 (1) +1 -1
Здравствуйте, IO, Вы писали:

IO>Вообще такие популяризирующие предмет статьи надо писать:

IO>- доходчиво и пространно (пусть лучше тот кто понял скипнет часть текста, чем тот кто не понял забьет читать дальше)
IO>- живим язиком (что б не уснул читатель), шутки в тему приветствуются

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


IO>Вобщем автору зачет. Прочитал статью на одном дихании.


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

Собственно, мне кажется, по этому ФП так плохо доходило до масс. Те кто питались рассказывать про ФП просто не могут рассказывать о нем доходчиво и просто. У них уже мозг перестроился так, что понять проблем других они не могут. Зато могут долго охать и ахать — почему же нас не понимают...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: Klapaucius  
Дата: 19.01.09 13:37
Оценка: 4 (1) +2
Здравствуйте, EvilChild, Вы писали:

EC>А что, здесь где-то ссылочная прозрачность нарушается или есть какие-то вещи противоречащие чистому ФП?


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

EC>SELECT * FROM mytable это тоже императивщина?


Нет. Никакого явного описания последовательности действий здесь нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.09 14:21
Оценка: +2 -1
Здравствуйте, eao197, Вы писали:

VD>>А это моя статья, мой стиль и мой подход к изложению.


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


Еще раз. Все что тебе кажется со стороны или спереди высказывай мне в личной переписке. А то может мне кажется что-то не хорошее про тебя. Представляешь как неприятно будет если я это все в форуме вывалю? Да и офтоп это. Так что давай по делу. А все что не по дулу можешь мне в личку написать. У меня предубеждений нет.

E>>>PPS. По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".


VD>>Больше конкретики, плиз. Если какие-то места задевают, можно подумать об их замене. А так... это не критика, а наезд.


E>Конкретика? Их есть у меня (у тебя).


E>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.


Я говорю то что вижу. И не считаю это каким-то там снобизмом. Если тебя это задевает, то я тут не причем. Борись со своими комплексами. Как видишь те на кого статья была рассчитана восприняли это нормально.

E>Там же:

"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."

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


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

E>Еще:

"Я понимаю, что это очень непривычно и непонятно (на первый взгляд), но поверьте, что есть целая теория обосновывающая это (теория «лямбда-исчислений» Чёрча)."

-- почему лямбда-исчисления в кавычках (это типа сарказм или опечатка)?


Черт его знает. Возможно мой ляп. Возможно редактор добавил. Поправим...

E>Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.


Если кому-то будет интересно изучить теорию Чёрча, то ему не составит труда сделать запрос в Гугле. Статья предназначалась для бумажного журнала где толк от ссылок практически нулевой. Можно было бы конечно все о наукообразить добавив список литературы в конце, но смысла в этом не вижу. Статья писалась в расчете на определенный круг и на определенное восприятие. На научную работу я не претендовал.

E>Или:

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

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


Ну, так получилось, что об однонаправленном тексте сказано и выше, и ниже. Неужели — это так существенно?

E>Еще:

"Приводить их реализации я не буду, так как они нетривиальны (уйдет много времени на их reverse engineering), да и занимают довольно много место. Для нас важен сам факт понимания их работы."

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


Что до моего времени, то уж извини не тебе о нем судить. Если бы его потребовалось больше, то статьи не было бы в принципе. А так многие уже сказали спасибо. Значит статья все же была им нужна. И скрип одного критика, вечно не довольного всеми моими высказываниями, меня и тех кому статься помогла не трогает.

E>Далее:

"Кстати, используя расширение синтаксиса, в конце запроса обязательно нужно писать ключевое слово select. Как говорилось в одном анекдоте – «Объясныт это нэлза! Это можьно толко запомныт!!!»."

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


Еще раз. Не лезь в чужой стиль. Я считаю, что именно такой стиль самый подходящий для доходчивого и простого объяснения. Люди могут расслабиться и спокойно воспринимать информацию.
Кстати, самая удачная твоя статья о Руби:
http://rsdn.ru/article/ruby/ruby_edges.xml
Автор(ы): Евгений Охотников
Дата: 03.03.2007
Данный материал рассчитан на более-менее опытных программистов, уже использующих другие языки про-граммирования, но желающих понять, что же такого особенного в языке Ruby, а тех, кому вольно или неволь-но приходится изучать Ruby  — в качестве еще одного русскоязычного источника информации о Ruby. Несколь-кими словами данную статью можно охарактеризо-вать как «глубокое погружение в Ruby для тех, кто не прочитал Programming Ruby».

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

E>Это только то, что сразу бросилось в глаза и запомнилось.


Это все очень похоже на слабо обоснованные наезды. Ты ведь что сказал в своем первом пассаже?

По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

Что же за наезды ты продемонстрировал? Большая часть цитат вообще не имеет отношения к твоему высказыванию.
За наезды видимо были приняты высказывания о том, что мало кто реально освоил ФП (что является стопроцентной правдой).
Ну, и как после этого воспринимать такую критику? Это батенька попытка состроить хорошую мину при плохой игре.
То что тебе не нравится мой стиль изложения — это одно. Меня это никак не задевает. Даже наоборот. Меня наверно задело бы обратное. А наездов ты так продемонстрировать и не смог. Так зачем было воздух сотрясать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: "LINQ как шаг к ФП". Стиль изложения.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.09 09:50
Оценка: :)))
Здравствуйте, eao197, Вы писали:

E>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.


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

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

E>Там же:

"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."

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


Почему сразу тупой ? Не нужно этих проекций. Тем не менее объяснять нужно очень просто. Что бы даже самый тупой мог понять. Иначе эффекта не будет.

Если тупой не поймет — то удешевления разработки не произойдет, секюрность работы девелопера не уменьшится а стало быть подход останется фенькой для ограниченого топов.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.01.09 17:09
Оценка: +2 :)
Здравствуйте, VoidEx, Вы писали:

VE>Мне действительно хотелось бы посмотреть на язык с записью короче, чем у Хаскеля.


Если просто "у кого короче", то J переплюнет хаскель
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 12:59
Оценка: :)))
FR>>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен
VD>Ага примерно так же как поклонники Питона пишущие на С++.

Два моих рабочих языка на данный момент — Java и Haskell. Мне за код на Хаскеле деньги платят, прикинь!

Поэтому я индивидуум, удовлетворённый программистски.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[44]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 04:22
Оценка: :)))
Здравствуйте, thesz, Вы писали:

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


А еще штангой мозги пудрил, я уже присматриватся начал какую купить, тем более раньше много ТФТ занимался, думал в изучении хаскеля поможет, но теперь ясно грибы рулят
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 21:22
Оценка: 16 (2)
Здравствуйте, lomeo, Вы писали:

VD>>Тогда нужно было просто говорить о заблуждениях.

VD>>Как примеры, тем более мелкие, помогут развенчать заблуждение?

L>Я уже думал о том, что нужен какой нибудь небольшой проект и серия статей о его реализации.


Я вот попытался сделать такой проект и описал его здесь
Автор(ы): Владислав Чистяков aka VladD2
Дата: 17.07.2008
Статья демонстрирует разработку реального приложения на Nemerle на примере создания простого генератора отчетов. Кроме того, в статье показана работа
с XML средствами LINQ to XML.
.
Проект не большой (по крайней мере для языка поддерживающего ФП), но при этом вполне себе реальный.
В нем затрагиваются важные для людей вещи вроде обработки ХМЛ-я, создания простенького интерпретатора выражений и даже взаимодействия с MS Office.
Было бы интересно поглядеть на реализацию этого же проекта средствами того же Хаскеля.

L>Ну, зачем так грубо? LaPerouse не блаб, все мы заблуждаемся.


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

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


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

L>Что касается самого замечания о том, что бороться надо с причиной — как ты предлагаешь это сделать?


На мой взгляд есть только два подхода. Оба я попытался воплотить в статях. Одну в обсуждаемой здесь, в которой попытался на пальцах и в непринужденной обстановке объяснить людям как можно мыслить функционально и писать функциональный код на привычном им языке (C# в данном случае). О том как можно извлечь выгоду из ФП в реальной жизни.
Второй описание более менее реальных приложений. Это я попытался сделать в статье Разработка простого генератора отчетов с помощью Nemerle и System.Xml.Linq
Автор(ы): Владислав Чистяков aka VladD2
Дата: 17.07.2008
Статья демонстрирует разработку реального приложения на Nemerle на примере создания простого генератора отчетов. Кроме того, в статье показана работа
с XML средствами LINQ to XML.
.
Насколько попытки удачны, я судить не могу в виду пристрастности. Но мне кажется, что именно это верный подход.

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

L>Т.е. чем плохи маленькие примеры?


Просто бессмысленны. Особенно если при этом не объясняется как надо мыслить, чтобы решать эту задачу.

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


Проблема в том, что люди которые хотят удивить преимущества в таких примерах ровным счетом ничего не видят. Для объяснения того что такое map нужен совсем простой пример. Один цикл. Вот вам Сишный for, а вот как его можно записать с использованием функции. А чтобы продемонстрировать преимущества надо взять какую-то не синтетическую идею и рассказать о том как ее спроектировать и реализовать. При этом надо делать по меньше финтов ушами. ДСЛ-и и прочие выпендрежей — это продвинутый курс.

L>Главный вопрос, конечно, как ты предлагаешь это сделать?


Как раз это я и описал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Klapaucius  
Дата: 20.01.09 09:37
Оценка: 6 (1) +1
Здравствуйте, IT, Вы писали:

IT>Это не так. Если условие будет в where, то да, получим O(n*m) и определённые тормоза. А если использовать join, то работает на порядок быстрее. Подробностей не знаю, выводы сделаны исключительно основываясь на практике применения linq с большими объёмами данных. Впрочем, можно предположить, что для where никуда не денешься, приходится сравнивать каждую запись с каждой, а в случае join строиться словарь.


Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 27.01.09 18:50
Оценка: 6 (2)
Здравствуйте, LaPerouse, Вы писали:

FR>>То есть ты пишешь на Ocaml?


LP>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы


http://cafesterol.x9c.fr/
?
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.01.09 05:00
Оценка: 3 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.


Хитрость в том, что перейти от Linq2objects к чему-нибудь более интересному можно лёгким манием руки. Именно благодаря тому, что запросы заданы таки в декларативной форме, а то, о чем ты рассказываешь — всего лишь одна из возможных ее интерпретаций. На досуге ознакомься с http://www.codeplex.com/i4o .
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 10:29
Оценка: 3 (2)
EC>>>>>А на них разве пишут "обычные" программы?
T>>>>define "обычные". Why should I ask in first place?
EC>>>Для более-менее конечного пользователя, а не для computer scienetist'ов.
T>>CompCert подойдёт?
EC>Вполне.
EC>Этот компилятор используется для решения практических задач или это чисто исследовательский проект?

Наверняка им пользуется кто-то из французских военных и/или космических товарищей.

При разработке Бурана был этап верификации ПО на Фортране. Программа обратно восстанавливалась до исходного кода на Фортране путём дизассемблирования и два текста сверялись. Так были выявлены ошибки в компиляторе, которые, потом, обходили.

Здесь этого этапа не нужно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.02.09 22:57
Оценка: 1 (1) :)
Здравствуйте, Sinclair, Вы писали:

E>>Откуда информация о том, о чем привык думать императивный программист?


S>Вообще-то — из определения "императивного программиста".

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

S>Но цикл остается центральной идеей императивного программирования — просто потому, что никаких других способов обработки "последовательностей" нету. Точнее, есть рекурсия, но

S>а) у наивных программистов при ней доступ к глобальным переменным ведет себя как-то странно
S>б) у продвинутых программистов быстро переполняется стек, "поэтому для больших объемов данных рекурсия неприменима".

Антон, где такая трава растёт?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.02.09 03:46
Оценка: 1 (1) +1
Здравствуйте, Sinclair, Вы писали:

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


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


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

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


Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом? Не забываем, да, что процессы мышления и методы реализации алгоритмов — не одно и то же, хотя и некоторым образом они влияют друг на друга. Отсюда пока получается, что вводный тезис сформулирован через отрицание мнимых характеристик. Крутое колдунство.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.09 16:31
Оценка: +1 -1
Здравствуйте, eao197, Вы писали:

VD>>Еще раз. Все что тебе кажется со стороны или спереди высказывай мне в личной переписке.


E>Почему твоя статья доступна публична, а критика к ней должна быть приватна?


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

E>Тебе здесь уже не раз указали как на орфографические ошибки, так и на ошибку в примерах кода. Если это не показатель недостаточного рецензирования, тогда что это?


А за указание на орфографические ошибки вообще баня положена. Читай внимательно правила.

Я только рад тому, что ты нашел и указал на ошибку. Но обсуждение стилистики и тем более высказывания в духе "Из статьи можно было бы смело выкинуть, как минимум, 1/3 текста" и "сильно напрягает стиль изложения ... с наездами на ..." — это уже само по себе откровенные наезды. К тематике форума они отношения не имеют. Ничего полезного для посетителей форума не несут. Являются оскорбительными. В общем, офтоп и наезды. Зачем это нужно в форуме по дотнету?

Если тебе хочется что-то написать, то лучше еще одну статью написал бы. Люди тебе спасибо сказали бы. Уверяю тебя, что статья написанная в любом стиле, если она несет что-то интересное будет воспринята людьми хорошо.

VD>>А то может мне кажется что-то не хорошее про тебя. Представляешь как неприятно будет если я это все в форуме вывалю?


E>Валяй.


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

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


E>То, в чем ты не видишь смысла, является экономией времени читателя.


Не разделяю твою точку зрения. Все кто не забанены в Гугле и Википедии найдут при желании все что захотят.

VD>>Ну, так получилось, что об однонаправленном тексте сказано и выше, и ниже. Неужели — это так существенно?


E>Да. Цени время читателя.


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

VD>>Что до моего времени, то уж извини не тебе о нем судить.


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


Я не жалуюсь, а объясняю. Все кто хотел меня понять — поняли. Просто разные люди подходят к чтению с разных позиций. Кто-то, как ты пытается докопаться до не важных мелочей и найти обоснование тому, что ему не нравится статья. А кто-то просто читает и получает информацию, эмоции и т.п.

E>>>Это только то, что сразу бросилось в глаза и запомнилось.


VD>>Это все очень похоже на слабо обоснованные наезды. Ты ведь что сказал в своем первом пассаже?

VD>>

VD>>По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

VD>>Что же за наезды ты продемонстрировал? Большая часть цитат вообще не имеет отношения к твоему высказыванию.

E>Хорошо, пойдет дальше. Про императивных программистов.

E>

E>ПРЕДУПРЕЖДЕНИЕ

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

E>Откуда информация о том, что большое количество императивных программистов везде видят цикл?

Из практики. Сам так мыслил каких-то 2 года назад.
Если к тебе это не относится, то это всего лишь значит, что ты не совсем императивный программист. Или не только императивный.

E>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?


Из практики чтения чужого кода. Поверь, не малой практики.

E> Я, например, такое наблюдал крайне редко и, если это было в моих силах, способствовал увольнению подобных деятелей, как неспособных к программированию.


На счет первого, просто не поверю. На счет втого — ну, молодец. Я не так радикален. Если я вижу, что кто-то рядом лепит циклы на право и на лево, то я просто пытаюсь продемонстрировать насколько понятнее и проще можно записать тоже самое.
К тому же циклы — это не единственный пример. Жизнь сложнее. Часто можно видеть как человек с большим императивным прошлым с трудом перестраивает мышление и не использует более хитрые, но при этом и более выразительные средства языка. Опять же пример и помощь тут очень кстати.
Эта статья и рассчитана на людей которые или вообще пока не освоились в функциональном мире, или делают первые шаги на этом пути.
Заметь, есть не мало людей которые не только не нашли статью оскорбительной, но и наоборот сказали спасибо в той или иной форме.

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

E>

E>Это сильно упростит восприятие функционального кода на начальном этапе. Данное мысленное преобразование требуется потому, что императивный программист за долгие годы привык думать низкоуровневыми понятиями (паттернами кодирования) циклов и простейших операций. ФП же предлагает думать бее крупными операциями, такими как отображение, фильтрация и свертка/агрегация.

E>Откуда информация о том, о чем привык думать императивный программист?

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

E>Кстати, здесь еще одна опечатка -- "бее" вместо "более".


Сенкс. Поправил.

E>

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

E>Из той же оперы.

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

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

E>Теперь по поводу изложения от первого лица...

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

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

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

VD>>За наезды видимо были приняты высказывания о том, что мало кто реально освоил ФП (что является стопроцентной правдой).


E>Откуда такая статистика?


Из твоего списка. Там только одна цитата была по делу. В прочем и она в общем-то не по делу.

VD>>Ну, и как после этого воспринимать такую критику?


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


Я твое творчество воспринимаю как желание публично подгадить. Ты не пропускаешь ни одного моего сообщения, чтобы подгадить где-то. Видимо это радость вызывает. Я этой радости не понимаю.
Меня всегда радовали люди включающие на телевизоре программу и начинающие ее критиковать. Я всегда просто переключаю канал в такой ситуации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.01.09 17:48
Оценка: +2
Здравствуйте, VladD2, Вы писали:

E>>>>Откуда информация о том, о чем привык думать императивный программист?


VD>>>От себя. Я сам так думал 3 года назад.


E>>Тогда следовало бы говорить в статье "я", а не "императивный программист".


VD>Я уже так не думаю. И задача статьи помочь думать по-другому остальным.


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

E>>Я спрашивал откуда статистика о том, что мало кто реально освоил ФП?


VD>А зачем мне статистика?


Затем, чтобы оправдать утверждение о том, что:

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

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

VD>Мне важно аудитория.


Ну типа "пипл хавает"

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


Я нигде не говорил, что статья плохая. Я перечислил причины, по которым она мне не кажется такой хорошей, как, например, это кажется Qbit86
Автор: Qbit86
Дата: 15.01.09
. И я говорю о том, что в ней можно было бы улучшить.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.01.09 10:24
Оценка: :))
Здравствуйте, Qbit86, Вы писали:

Q>Я не совсем по теме хочу высказаться, просто пару слов в поддержку Влада. Имхо eao197 некорректно и некрасиво наезжает. Можно было и полегче выразиться, не теряя сути претензий.


Q>Статья же отличная (несмотря на опечатки и орфошибки). Как раз собирался в понедельник среди коллег семинар по LINQ и ФП провести, теперь же достаточно просто вручить им статью 


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

В общем, разные мы люди. Не ясно только почему это должно приводить к вот такому вот маниакальному преследованию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: IO Украина  
Дата: 18.01.09 12:47
Оценка: +2
Здравствуйте, VladD2, Вы писали:

E>>Там же:

"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."

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


VD>Я тупым себя не считаю, но предпочитаю максимально простое и доходчивое изложение. Особенно это касается вещей которые затрагивают концептуальные вещи вроде парадигм программирования. В отличии от закоренелых фунциональщиков я еще прекрасно помню то недоумение и полное не понимание возникающее от формальный но на сквозь косноязычных объяснений которые я находил. Так что опять мимо кассы. Это не проблемы изложения или какой-то моей надменности, а проблемы твоей озлобленности.


Я тупой, мне подробно плиз.

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

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

Вобщем автору зачет. Прочитал статью на одном дихании.
В таком же духе надо и про Немерл и прочее ФП.

И для теста можно сначала давать читать статью слабо подготовленому читателю не в теме — ето ж для них пишется. Он и скажет — где непонятно.

Вообще же мало кто анализировал по каким причинам люди начинают читать и бросают. А жаль. Вот Влад молоток, вроде спрашивает у тех кто неосилил "на каком месте уснул?".
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:49
Оценка: :))
Здравствуйте, thesz, Вы писали:

E>>>>

...уж совсем немногие действительно разобрались...

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

T>Если палец указует на меня, то я открещусь — я не разбирался, и даже не пытался. Я просто использую Хаскель, по прямым моим обязанностям вот уже пятый год, а так — с конца 1998 года.


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

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

ЗЫ

А вообще забавнешая ситуация получается. Когда я спорю с представителями разных лагерей, то все они моментально записывают меня в радикалов, маргиналов и т.п. Но вот что странно! Каждый раз меня записывают в другой лагерь. Говоришь с опупевшим императивщиком который всюду видит операции над битами и ты вдруг злостный функциональщик/декларативщик не понимающий ток в написании реально быстрых программ. Говоришь с фнункциональщиком и ты вдруг чудесным образом переносишся в другую сторону спектра. И те и другие называют меня фанатиком и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.01.09 09:28
Оценка: +2
Здравствуйте, kochetkov.vladimir, Вы писали:

E>> -- снобизм и попытка закосить под элитарность.


KV>Скорее, суровая правда жизни.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 10:24
Оценка: +2
T>>Если палец указует на меня, то я открещусь — я не разбирался, и даже не пытался. Я просто использую Хаскель, по прямым моим обязанностям вот уже пятый год, а так — с конца 1998 года.
VD>Молодец. Но прямо вот этими словами ты доказал, что можно зная русский язык не понимать что тебе на нем пишут.
VD>Понимаешь ли в чем дело? Может ты и лучше разобрался "в теме", но при этом ты зазнался и напрочь перестал понимать тех кто еще "не в теме". Отсюда такую же статью ты написать в принципе не в силах. Ну, по крайней мере без чужой помощи.

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

VD>А вообще забавнешая ситуация получается. Когда я спорю с представителями разных лагерей, то все они моментально записывают меня в радикалов, маргиналов и т.п. Но вот что странно! Каждый раз меня записывают в другой лагерь. Говоришь с опупевшим императивщиком который всюду видит операции над битами и ты вдруг злостный функциональщик/декларативщик не понимающий ток в написании реально быстрых программ. Говоришь с фнункциональщиком и ты вдруг чудесным образом переносишся в другую сторону спектра. И те и другие называют меня фанатиком и т.п.


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

И я разговариваю с тобой, как с таковым человеком.

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

Ты всем стараешься навязать важность твоих проблем и их решений. Да чуть выше — "написать статью ты в принципе не в силах". А оно мне надо, писать статью? Мне пост в ЖЖ важнее статьи, поскольку чаще. Про важность для других, то мой короткий рассказ про лямбда исчисления использовали при подготовке к экзамену. Мне достаточно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 13:38
Оценка: :))
Здравствуйте, lomeo, Вы писали:

L>Ну, хорошо, скажем так: "Хаскель даёт следующие преимущества — бла-бла-бла, при этом он обладает следующими недостатками — бла-бла-бла. В большом количестве задач, которые я решаю, преимущества перевешивают недостатки значительнее, чем, скажем у Немерле/Скала".


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

L>Это IMHO — о чём тут спорить?


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

L>Про ленивость отдельная песня. Смысл в том, что не конкретно ленивость, а набор нескольких свойств (система типов, ФВП, безскобочная запись, даже do-нотацию) делают из Хаскеля Хаскель.


Все это компромиссные решения имеющие как достоинства так и недостатки. Большинству кто хочет писать софт для современных корпораций скорее будет нужно чтобы язык поддерживал систему типов Явы или дотнета. Потом есть такие фишки как компонентность о которой при разработке Хаскеля просто не задумывались.

L>Ленивость есть не только в Хаскеле, как и любое из других свойств, но именно этот набор формирует такой язык и поощряет такое написание программ. Как и в любом другом языке.


Только, не только. Других хоть немного популярных языков с ленивостью по умолчанию я не знаю. А ленивость конечно есть много где. Даже, как не странно, в C# и С++.

L>Какой набор подходит для твоей задачи — выбирать тебе. Примерно так.


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

Мне тут не редко орлы вроде еао197 или АВК говорили, что я мол слишком сильно толкаю Немерле. Но ёлы-палы! Где я предлагал его использовать без оглядки на задачи и условия? Я сразу говорю, что если вы седите на Яве, то ваш билет в мир ФП — это Скала. Если в дотнете, то Nemerle, F# и даже C# с LINQ. Если вам нужны компилируемые в нэйтив модули, то выбор совсем другой. Тут уже нужно выбирать между Хаскелем, ОКамлом, Лиспом и т.п. Причем Хаскель сразу не проходит если речь идет высокопроизводительных вычислений, но может быть предпочтительнее если нужно получить более высокоуровневые абстракции. Кстати, Хаскель идет лесом и в случае если людям нужен классический ООП. Тут ОКамл будет куда приемлемее.

А посмотри что вы вытворяете?... Парень спрашивает как ему С на C# перевести, а ему отвечают, что есть такая замечательная штука как экстер-си в С++ и Хасклевый экспорт. Это вообще вменяемый ответ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 02.02.09 10:21
Оценка: :))
Здравствуйте, EvilChild, Вы писали:

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


LP>>Только ссылки потому то и нужны, чтобы адресовать изменяющиеся объекты c identity. Иначе их никто и ссылками не называл (то есть это название отражало бы лишь только способ размещения в памяти).

EC>А почему они обязательно должны быть изменяющимися?

Если объект неизменяющийся, тогда само понятие уникальности данного объекта исчезает и он становится неотличим от просто значения.
Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.02.09 10:37
Оценка: +2
Здравствуйте, eao197, Вы писали:

T>>Тут мы сделали перенос строки из-за длинной строки, там мы его сделали... Перед компиляцией не всю (под)программу просмотрели — на запуск ушёл неправильный код. Начали искать ошибку — надо больше текста просмотреть. И тд, и тп.


E>Детский сад.


Это так кажется. Я вот листаю ява код с кучей геттеров и сеттеров. Каждый — 5 строк — объявление, открывающаяся-закрывающаяся скобки, собственно код, да строка между методами. Экран весь забит, и я вынужден пользоваться навигацией, которую мне предлагает IDE постоянно. Такого неприятного ощущения при работе с более лаконичными языками нет.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 13:08
Оценка: +1 :)
VD>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.

We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.

Уж коли ты так хорошо во всём разобрался.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 09.02.09 05:53
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

VD>Причем тут сложность? База OCaml — это ML. И он не то что бы сложный. Он совсем другой! Чтобы понять его нужно не просто составить мысленное отображение синтаксических элементов одного языка в синтаксические элементы другого. Для понимания этой базы прийдется менять сознание. По другому смотреть на вещи.


Сложность при том что синтаксис можно быстро и легко изучить. Конечно некторый психологический тормоз может помешать. Но ML образные гораздо ближе к Си/паскалю чем например lisp, forth или smalltalk.

VD>>>Мои наблюдения за людьми которые изучали F# и Немерле показали, что Немерле ими воспринимался намного проще и быстрее. Более того после знакомства с Немерле F# воспринимался уже намного проще, так как разница действительно оказывалась же почти в одном синтаксисе.


FR>>Угу и потом эти люди пишут страшный код на Немерли функциональщины в котором свершенно не наблюдается.


VD>Откуда ты это взял? У меня как раз обратная статистика.


Да прямо с RSDN помню год или два назад тут были перлы.

FR>>Здравствуй Влад, я уже давно пишу небольшие свои проектики на Ocaml'е, единственное не использую объекты за ненадобностью. Я легко могу писать на Хаскеле как на фортране, тьфу как на Ocaml'е но смысла в этом не вижу.


VD>Тогда странно, что ты находишь огромную разницу между ним и Хаскелем.


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

FR>>Угу с тобой все ясно, блабишь


VD>Ну, типа сделал выпад. Молодец.


Да не серъезно, Влад ты просто не разбирался в Хаскеле, так мельком проглядел, да с такой точки
окамл и хаскель похожи, а чуть глубже и оказывается что это акула и дельфин.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 12:48
Оценка: +2
Здравствуйте, thesz, Вы писали:

T>Для этого человека нет ничего невозможного в написании программы, но всё равно остаются сложности с предметной областью.


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


Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?

<offtopic>
Когда-то давно была такая поговорка: настоящий программист должен написать собственный текстовый редактор, компилятор и операционную систему. Поэтому не нужно апелировать к написанию компиляторов, пониманию AST и кодогенерации. Это вещи, которые очень многие программисты считают весьма интересными и готовы заниматься ими ради собственного удовольствия. Гораздо сложнее, на мой взгляд, ответственное отношение к работе, которая не так увлекательна, как создание собственного компилятора. Например, есть необходимость внести за короткое время важные изменения в большую систему, эволюционировавщую в течении восьми лет. И так, чтобы эти изменения заработали сразу, без ошибок. Здесь уже не столь важно ни знание предметной области, ни знание языков и внутренностей, ни даже знание самой модифицируемой системы. А некий баланс всех этих знаний + четкое понимание целей + четкое видение пути их достижения + спокойное отношение к оставшемуся до часа "Ч" времени. Сильно сомневаюсь, что ФП здесь имеет какое-то преимущество перед ИП, и что стиль программирование здесь вообще имеет хоть какое-то значение.
</offtopic>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 14:45
Оценка: :))
Здравствуйте, lomeo, Вы писали:

L>Как думаешь, стоит показывать начинающему в ФП, или примем за факт, что он и то и другое поймёт?


То, что он код на Хаскеле не поймёт — это факт. А вот код типа
var bars = foos.Select(foo => map[foo.Name]);

поймёт с большой вероятностью.

L>Чего ты к линку привязался?


Это не я к Линку привязался, могу и без SQL-like синтаксиса прожить.

L>Честно, не пойму, чем from foo in foos select map[foo.Name] отличается от...


Слова человеческие.

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


По прежнему не вижу оснований считать синтаксис Хаскеля «помогающим».
Глаза у меня добрые, но рубашка — смирительная!
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 11:20
Оценка: +1 :)
Здравствуйте, thesz, Вы писали:

T>Если вам мало, то я умываю руки.


Пусть будет так. Никто никого ни в чем не убедил.

T>Их разрабатывает нереальное число людей.


Осталось подождать, пока на Haskell-е небольшие команды сделают что-нибудь типа Intellij IDEA.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 12.02.09 11:26
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

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

EC>>Требование к глобальности состояния обязательное?
S>Да.
EC>>Если да, то почему?
S>Потому, что контекстов, в которых состояние могло бы быть локально, еще нету. Любая операция в программе может воспользоваться результатами любой другой. См. Машина Тьюринга, Машина Поста.

S>Для того, чтобы у понятия "локальное состояние" появился смысл, нужно вводить некие контексты. Чем, в частности, занимается процедурное программирование (как развитие императивного).

Ты, как-то неожиданно для меня узко трактуешь понятие императивного программирования.
Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 12:11
Оценка: +2
Здравствуйте, LaPerouse, Вы писали:

LP>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.


Вообще то обе функции чистые, а вторая вообще полная фукциональщина даже локального сосотояния не использует, так что императивщины тут уже нет.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 12:13
Оценка: +2
Здравствуйте, LaPerouse, Вы писали:

LP>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.


Кстати стека не будет, там хвостовая рекурсия.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 13:37
Оценка: -1 :)
Здравствуйте, EvilChild, Вы писали:

EC>Конструкция, описанная тобой какая-то совершенно искуственная.

EC>Какая от неё польза?
Не понимаю вопроса. Польза от чего? От этой убогой программы? Ну, она умеет возводить числа в пятую степень.

S>>А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.

EC>Глобального состояния (в традиционном его понимании) там нет.

Достаточно того, что есть состояние, изменяющееся во времени. Даже если написать эту же программу в виде
return x*x*x*x*x;

Всё равно будет состояние, хоть и неявное. Потому, что спецификация императивного ЯП подразумевает вот такую семантику:
temp1 = x;
temp2 = temp1*x;
temp3 = temp2*x;
temp4 = temp3*x;
temp5 = temp4*x;
return temp5;

И никуда ты от этого не денешься, пока не начнешь искать не способ представить алгоритм в виде последовательных трансформаций некоего состояния, а как способ описания зависимостей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: Gajdalager Украина  
Дата: 12.02.09 14:15
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

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


EC>>Конструкция, описанная тобой какая-то совершенно искуственная.

EC>>Какая от неё польза?
S>Не понимаю вопроса. Польза от чего? От этой убогой программы? Ну, она умеет возводить числа в пятую степень.

S>>>А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.

EC>>Глобального состояния (в традиционном его понимании) там нет.

S>Достаточно того, что есть состояние, изменяющееся во времени. Даже если написать эту же программу в виде

S>
S>return x*x*x*x*x;
S>

S>Всё равно будет состояние, хоть и неявное. Потому, что спецификация императивного ЯП подразумевает вот такую семантику:
S>
S>temp1 = x;
S>temp2 = temp1*x;
S>temp3 = temp2*x;
S>temp4 = temp3*x;
S>temp5 = temp4*x;
S>return temp5;
S>

S>И никуда ты от этого не денешься, пока не начнешь искать не способ представить алгоритм в виде последовательных трансформаций некоего состояния, а как способ описания зависимостей.
Подожди-подожди... Почему это вдруг эти переменные стали состоянием, да ещё и глобальным? Давай напишем так:
[c#]
return x * (\x -> x * x (x)); // Упростили к кубу
[c#]
Умножаем х на результат вычисления лямбды. Где состояние? В регистрах? А они здесь при чём? Это детали реализации.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Оргия праведников — С.М.С.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 13.02.09 04:57
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Введением императивной лямбды ты ничего не добьешься — это по-прежнему тот же самый пример с x*x*x*x. Такая лямбда — всего лишь еще один, более компактный способ описания процедур. Ровно с тем же успехом ты мог ее описать заранее, как Power2(x) и вызвать по месту. По-прежнему связь результата power5 и аргумента выражена неявно, через цепочку трансформаций.


По моему ты зря нажимаешь на реализацию. Тот код на Ocaml который я выше привел тоже транслируется в очень даже императивное:

_camlKjljl__aux_60:
L101:
    cmp    ebx, 1
    jne    L100
    ret
L100:
    add    ebx, -2
    mov    edx, DWORD PTR [ecx+12]
    sar    edx, 1
    dec    eax
    imul    eax, edx
    inc    eax
    jmp    L101
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.09 09:35
Оценка: -1 :)
Здравствуйте, Sinclair, Вы писали:

E>>От концепции return не отказываются даже в функциональных языках, там просто отказываются от ключевого слова return. В том же примере FR:

E>>
E>>let rec power5 x =
E>>    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;
E>>

E>>уши этой концепции торчат наружу.
S>Не вижу никаких ушей. Это не return, это тождество.

Ага, тождество.
В OCaml, на котором FR привел пример, значением функции будет значение последнего выражения, которое было выполнено в этой функции. И тип этого выражения должен совпадать с типом функции. А это означает, что в обоих ветках if-а нужно заботиться о выражениях, которые должны иметь одинаковый тип. Поэтому в OCaml запись:
if n=0 then acc ...

полностью соответствует аналогу в императивных языках:
if(n=0) return acc; ...


S>Вот в учебнике математики за пятый класс, когда мы говорим "пусть x равно y+z", мы что, что-то куда-то вернули?


Программирование -- это не математика. Если бы было по другому, то запись 'a=b' разражала бы всех программистов, а не только Вирта с Мейром.

E>>Состояние просто перенесно из изменяемых переменных на стек, но оно все равно в явном виде присутствует -- при организации рекурсивного вызова sum_impl программист должен явно его определять (вычисляя аргументы рекурсивного вызова).

S>Не вижу никаких вычислений. Вижу определение функции aux, которая совершенно неизменна, хоть и ссылается сама на себя.
aux (acc * x) (n - 1)

Посмотри внимательнее. И стоит только переписать вычисление вот так:
acc * (aux x (n-1))

как все очень и очень серьезно меняется. Хотя смысл остается тем же самым.

А на счет изменности функций:
int sum( int[] a ) {
  int r = 0;
  for( int i = 0; i != a.length; ++i )
    r += a[ i ];
  return r;
}

Чем эта функция изменна?

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

S>Это артефакты конкретных реализаций.

Еще раз, программирование -- это не математика. Нет никакого толка от функции sum, если она не может вычислить сумму элементов массива из 10M элементов из-за нехватки стека.

Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность. В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.

E>>Ерунда. На любом произвольном шаге исполнения функциональной версии sum (с рекурсивными вызовами sum_impl) есть только текущее значение, которое станет результатом (т.е. истинным фактом) только после завершения всего вычисления.

S>О каком еще "шаге" мы говорим?

Например, об очередном вызове sum_impl.

S>С учетом того, что у функций нет побочных эффектов


Какие побочные эффекты у приведенной выше императивной функции sum?

S>компилятор имеет полное право вообще отказаться от шагов вычисления и брать результат напрямую из таблицы.


Из какой таблицы? Из какой таблицы компилятор может подставить значение функции sum для произвольного массива?

S>"Шаг" может появиться только после преобразования декларативной программы в императивную.


Ну да, конечно. Шаг рекурсии в ФП -- это, определенно, совсем другое дело, чем шаг цикла в ИП.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: Gajdalager Украина  
Дата: 13.02.09 11:16
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

E>>А на счет изменности функций:

E>>
E>>int sum( int[] a ) {
E>>  int r = 0;
E>>  for( int i = 0; i != a.length; ++i )
E>>    r += a[ i ];
E>>  return r;
E>>}
E>>

E>>Чем эта функция изменна?
S>Не понял вопрос. Вам непонятно, что r является изменчивым состоянием? что i является изменчивым состоянием, и даже банальное доказательство того факта, что ни одно из обращений не выходит за пределы границ массива является нетривиальным?

Не знаю, что такое изменная-неизменная функция; однако думаю, что данную функцию можно назвать чистой, ведь она возвращает одно и то же значение для того самого аргумента и не имеет побочных эффектов. Если эффекты есть — укажите мне их. А то, что функция записана в императивном стиле — это уже детали.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Оргия праведников — Сицилийский виноград
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: Константин Б. Россия  
Дата: 16.02.09 12:24
Оценка: +2
Здравствуйте, LaPerouse, Вы писали:

LP>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.


Если они написаны на императивном языке — то да. А если на функциональном — то нет ни рекурсии, ни вызовов функций, ни стека. Есть только рекурентно записаное соотношение. И вычисление этого соотношения компилятор может реализовать как угодно. Естественно у этого соотношения нет ни состояния, ни побочных эффектов. Поэтому говорить, что ФП — это ИП с изменением состояния на стеке — неверно.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: Константин Б. Россия  
Дата: 16.02.09 13:20
Оценка: +2
Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, Константин Б., Вы писали:


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


LP>>>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.


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


LP>Это просто фантастика какая-то. "Компилятор может реализовать как угодно" — возможно, через тридцать лет и будет такое, но пока компилятор делает именно то, что указывает программист. Он может сделать оптимизации по типу сворачивания хвостовой рекурсии, но изменить тип вычислительного процесса он не может.


Вы просто не понимаете что именно указывает программист когда он пишет на окамле let rec sum = ...
Эта запись не содержит рекурсивного вызова и не содержит указаний "положить аргументы на стек". Она только задает рекурентное соотношение.
Re: "LINQ как шаг к ФП". Стиль изложения.
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 22.01.09 08:42
Оценка: 43 (1)
Здравствуйте, eao197, Вы писали:

VD>>Будешь писать сам — выклинишь.

E>Обязательно.

Я даже специально статью прочитал, хотя и откладывал ее до лучших времен со свободным временем

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

1. Сэкономил бы себе кучу времени
2. Наглядно показал всем как круто выглядит нормально написанная техническая статья.

VD>>А это моя статья, мой стиль и мой подход к изложению.

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

Стиль. Статья написана легким в восприятии, разговорным языком. Как если бы Влад выступал с докладом, или на встрече участников RSDN, например.

E> -- снобизм и попытка закосить под элитарность.


Скорее, суровая правда жизни.

E>-- императивный программист такой тупой, что ему нужно объяснять все максимально просто.


Ипмеративный программист скорее рационален (как и любой другой). И предпочтет простое объяснение сложному.

E>Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.


См. выше про доклад и встречу участников.

E>-- выше и ниже где? Обычно пишут "об этом речь пойдет ниже" или "об этом было сказано выше". А когда "выше и ниже", это как?


Вполне уместный вопрос, в принципе

E>Лень было дать нумерацию разделов и указать пару нужных номеров?


И тут же наезд и личные домыслы

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

E>Далее:

"Кстати, используя расширение синтаксиса, в конце запроса обязательно нужно писать ключевое слово select. Как говорилось в одном анекдоте – «Объясныт это нэлза! Это можьно толко запомныт!!!»."

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


См. выше про доклад и встречу участников. Статья легко читается, понятна, интересна и была востребована. Это следует хотя бы из проставленных участниками оценок. Это — важно. А все о чем говоришь ты, хоть местами и справедливо, но второстепенно. Если ты можешь осветить тему статьи лучше/понятнее/короче чем Влад, то просто сделай это. Тут думаю, будут только рады

P.S: Да, да — это тоже трындеж

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 12:10
Оценка: 42 (1)
Здравствуйте, eao197, Вы писали:

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


Как я понял, произошло следующее. thesz показал, где ФП выигрывает. Затем ты показываешь ситуацию и спрашиваешь — а как здесь ФП выигрывает? Даже не разбираясь в том, что за ситуацию ты предлагаешь, можно сказать, что

1. Возможно здесь никак
2. Это никак не опровергает того, что ФП выигрывает так, как показал thesz.

Если же слова thesz и твоё предложение рассмотреть эту ситуацию никак не связаны, то я извиняюсь — недопонял.

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


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


Смысл такой — с помощью системы типов можно ограничить возможные реализации функции для данного типа (существование единственного доказательства для данной теоремы).

Я показал примитивный пример, для подробностей можно посмотреть

Curry-Howard изоморфизм
Theorems for free!

Пример вывода

Djinn — программка, выводящая реализацию функции по её типу.

Практические применения ограничений с помощью системы типов

Lazy Functional State Threads. Наверное, одна из самых лучших статей на тему. Как rank-2 полиморфизм (логика второго порядка) помогает вставлять императивный кусок в функциональный код безопасно.

Beautiful Concurrency. Преимущество этой статьи — необязательно знать синтаксис Хаскеля.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 20.01.09 03:07
Оценка: 6 (1)
Влад! У нас тут по ходу целое несовпадение мировоззрений, посему продолжение быстро перерастёт в разборки

Чтобу не тратить время.
а) Во многом с вами согласен.
б) Очень не люблю когда критикуют людей, которые хоть что-то делают за то, чего они не сделали. Особенно не изучая перед этим матчасть. Лично к вам не относится.
в) Не люблю подход "да будет шмагия!". Лично к вам не относится.

Офтоп про декларативыность linq:

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

Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.

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

Сам по себе LINQ не тру декларативен. Декларативность подразумевает произвольную реализацию алгоритма в зависимости от ситуации. С некоторой натяжкой можно обозвать декларативным сам язык — эдакий DSL вокруг набора методов. Вы ж не будете обзывать декларативным это:
new StringBuilder.Append("A").Append("B");

А вот это — декларативный код?
new int[] {1,2,3}.Where(i=>i>2).Select(i=>"#" + i.ToString());

А вот это — уже похоже, да?
from i in new int[] {1,2,3} where i>2 select "#" + i.ToString());


Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.

В принципе, о декларативных запросах к графам — неважно, объектным, XML, иерархическим БД — писал ещё Дейт начиная с 8 издания. Точной цитаты не приведу — книги на руках нет, быстрый поиск не помог, но суть там была такая, что из-за захардкоденной структуры возможность произвольного доступа невелика, различных путей выполнения не так уж и много, а использование этих путей в запросах в принципе лишает смысла использование оптимизатора. Посему те же XQuery/XSLT так и пребудут императивными во веки веков до скончания оных

VD>Нет в природе никаких анонимных делегатов. Если кто-то так называет анонимные методы, то он просто ошибается.


Может ты скушал не ту пилюлю, нео?

Не всё так просто. Если посмотреть что происходит в реальности:

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

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

Так что зависит от контекста — если говорим о языке в чистом виде, то анонимных делегатов нет. Если опускаемся до реализации — то они как суслик. Хоть не видишь, а есть, родимые

S>>Почему без шапки?!!

VD>Что? Что значит "шапка"?

Несмешной армейский анекдот. Не обращайте внимания.

VD>Ты сам-то внимательно прочем то, что написано в приведенной статье? Если отбросить громкие заявления о высокой производительности и поглядеть описание процесса вызова, то становится отчетливо видно, что вызов дико не оптимален. Перед ним делается масса проверок которые снижают производительность. Решение без ошибок дизайна привело бы к одному виртуальному вызову который в общем-то и виртуальным можно назвать с натяжкой, так как конкретные реализации могли бы быть sealed. В итоге во многих случаях JIT мог бы после устранения виртуальности устранять и сам вызов встраивая его по месту.


Читаем http://blogs.msdn.com/zifengh/archive/2008/01/21/from-c-to-clr-jitted-code-call-delegate.aspx. Не запутайтесь — там подряд идёт создание и вызов делегата. JIT работает так, как вы и хотели. Если можем предложить более оптимальный вариант — предлагаем. Нет — не холиварим или учим матчасть.

VD>Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.


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

S>>Дальше.

S>>

S>>Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.

S>>Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше.
S>>Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...

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


Придётся править. Реально вопринимается как наезд. Или предвзятость. Ибо "90% императивных программистов" пишет код аккуратней. Да! Я себя к императивщикам не отношу. Вообще ни к кому не отношу. Не люблю таскаться

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


Свою точку зрения разжёвал выше. Почему "вопрос "как" перекладывается на реализацию библиотеки" — особенность ФП? Это принципиально невозможно в императивных языках?

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


VD>Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.


Я ж говорю — несовпадение мировоззрений. Не будем.


S>>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.


VD>Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.


Ну, если для вас маркетинг-отдел Сана достоверней Рихтера... Не могу найти точной цитаты, но делегаты как каллбэки в рантайме были заложены ещё до событий и собсно фреймворка — ещё когда было только "common object runtime". Отсюда и делегат/мультикаст делегат. Одно для калбэков, другое для событий. Потом пришло осознание, что в принципе сценарии пересекаются и вполне себе оптимизируются в рантайме. Но было уже поздно(с). Принципиально нет ограничений для кастинга делегатов по сигнатуре. Оно просто не реализовано. Если у вас есть идеи, какими должны быть делегаты — озвучьте
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 13:35
Оценка: 4 (1)
Здравствуйте, LaPerouse, Вы писали:

LP>То есть хотело спросить, ты в самом деле так считаешь или пошутил?


Считаю. На Яве императивные конструкции выражаются хорошо, функциональные плохо.
Хотя вот, рекомендую: http://antilamer.livejournal.com/253917.html
Re[50]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.02.09 16:22
Оценка: 4 (1)
Здравствуйте, FR, Вы писали:


G>>Причем вы можете свой аналогичный сахар в F# делать в любых количествах.

FR>Интересно как?

Вот так http://www.infoq.com/articles/pickering-fsharp-workflow
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 16:09
Оценка: 2 (1)
Здравствуйте, LaPerouse, Вы писали:

>>>main = do

>>> i <- newInt
>>> for (i =: 1, i <= 5, (i++)) $
>>> printf "%i\n" i

LP>Все равно неестественно и не натурально


А я о чём! Хрень какая то...

Если серьёзно, то программировать императивно иногда приходится. Ничего в этом страшного нет, а самое главное, происходит это не так часто, как думают. Причина этого в том, что на ФЯ легко оперировать акциями, т.к. они являются первоклассной сущностью.

Например, представим, что нам надо выйти из программы, как только пользователь нажал q

qPressed = do
    mb <- getUserInput
    return (mb == Just 'q') -- представим, что getUserInput неблокирующее чтение, для этого Maybe Char

main = loop
  where
    loop = do
      quitCond <- qPressed
      unless quitCond loop


Далее, представим, что нам надо выходить также, если пришло соответстувющее сообщение по сети

netQuit = do
  mb <- readFromNet
  return (mb == CmdQuit)

main = loop
  where
    loop = do
      q1 <- qPressed
      unless q1 $ do
         q2 <- netQuit
         unless q2 loop


Вспомнив, что наши акции первоклассны определим над ними операцию:

-- если первая акция не прошла, применяем вторую.
orM act1 act2 = do
  b <- act1
  unless b q2

main = loop
  where
    loop = do
      q <- qPressed `orM` netQuit
      unless q loop


Тут нам понадобилось ещё третье условие выхода. Мы написали

q <- qPressed `orM` netQuit `orM` someQuitCond


Затем четвёртое, пятое...

q <- foldr orM [qPressed, netQuit, someQuitCond, ...]


В общем не всё так плохо в императивном программировании на чистях ФЯ.
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 15:26
Оценка: 2 (1)
L>>Как думаешь, стоит показывать начинающему в ФП, или примем за факт, что он и то и другое поймёт?
Q>То, что он код на Хаскеле не поймёт — это факт. А вот код типа
Q>
Q>var bars = foos.Select(foo => map[foo.Name]);
Q>

Q>поймёт с большой вероятностью.

Хаскельные "понимания списков" представляют собой кальку с синтаксиса теории множеств.

B={x|x∈B, P(x)}

(почему RSDN не понял &isin;?..)

Мой знакомый, увидев пример "понимания списков", взвизгнул от восторга и убежал моделировать какую-то там систему знаний с теоретико-множественным подходом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 16:24
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

LP>>Если я могу получить все, что мне требуется получить от хаскеля,


T>А что требуется?


Ну, теперь мне требуется LINQ

Если серьезно, то не так уж и много (для java):

1. Какой-то сахар на уровне языка, чтобы можно было легко оперировать с соотв. структурами данных (кортежи, односвязные списки)
2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
3. Templates как в С++
4. Сопоставление с образцом

Удобный и естественный способ работать с мутабельными данными, но это уже есть.

Дополнительные требования: компилятор должен оптимизировать хвостовую рекурсию. В javac все печально
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 29.01.09 20:54
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>>>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.


L>>Сравнивал. Если ты про Скала/Немерле, то не улетучивалось.


VD>Да его просто нет. Вот когда начнете Хаскель хотя бы с ОКамлом сравнивать (которому до перечисленных языков довольно долеко), тогда можно будет о чем-то поговорить. А то ваши рассуждения по жизни строятся на базе демонстрации преимущества Хаскеля перед С++, а потом все остальные языки тупо принимаются за равные С++.


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


Ты сейчас вот на ноль поделил или просто сказал, что Немерле, Скала и Хаскель абсолютно идентичны?
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 10.02.09 13:17
Оценка: 1 (1)
Здравствуйте, Qbit86, Вы писали:

Q>Я не об этом. Я о том, что человек начинает въезжать в ФП, и объяснить через C++ проще, чем через Карри, Чёрча и Россера 


Даже если у человека большой бекграунд на С++, объяснять приёмы ФП лучше не на С++, т.к. постоянно будешь слышать: "Ну здесь ще проще цикл...?!".

DC>>Я вообще не об этом, я о том, что проще изучать приёмы программирования используя синтаксис, который упрощает его понимание человеком, а не машиной.


Q>Я б не сказал, что синтаксис Хаскеля чего-то там упрощает.


Ну тогда тебе задачка:
есть структуры

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

struct Bar
{
\\...
long val;
\\...
}


Есть ассоциативный контейнер:

std::map<std::string,Bar> barMap;


Задача по name получить bar.

Foo s;
\\...
s.name = "blabla";
\\..
Bar b = barMap[s.name];


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

В Хаскелле будет что-то вроде (сорри если где слажал):
let bars = map ((\ arr (_,name,_) -> arr!name ) arr) foos
in 
-- ...
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.02.09 13:22
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

L>>>4) грязные

G>>Это хорошо, можно писать императивный код там где он уместен.

T>Мультипарадигменный подход контрпродуктивен с точки зрения программиста.

С точки зрения какого программиста?

T>http://thesz.livejournal.com/509595.html

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

L>>>5) энергичные

G>>Лучше энергичность по-умолчанию, чем ленивость.
T>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
Как ленивость связана с модульностью?

T>http://thesz.livejournal.com/906786.html

Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.
ИМХО для не-списков ленивость поумолчанию не нужна.
Re[46]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.02.09 07:41
Оценка: 1 (1)
Здравствуйте, FR, Вы писали:

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


T>>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?

G>>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
G>>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.

FR>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.

FR>А F# похоже не только функторы по пути растерял
Дык у него вообще ленивости на уровне языка нету.

Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 15:44
Оценка: 1 (1)
Здравствуйте, Sinclair, Вы писали:

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


S>А вот эта "неуловимость" ФП связана как раз с ФП/ИП дуализмом: если избегать деструктивных присваиваний в процедурной программе, то она будет совпадать с некоторой функциональной программой с точностью до синтаксиса. А если ввести компонент "состояние" в результаты, над которыми оперируют функции в ФП программе, получим императивный алгоритм.


Состояние — она такая хитрая штука, что даже когда его типа нет, на самом деле оно вполне себе есть.
Вот например, возьмем все тот же пример, — в обеих случаях, приведенных eao, состояние присутствует. В первом случае оно нагло торчит в переменной r и не заметить его, мягко говоря, тяжело:

int sum( int[] a ) {
int r = 0;
for( int i = 0; i != a.length; ++i )
r += a[ i ];
return r;
}

Во-втором случае состояние не присутствует в явном виде, но хранится на стеке. Но тем не менее оно есть, просто замаскировано.

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}


result отличается от r только тем, что обновление значения не происходит путем деструктивного присваивания
r+=a[i]
, но происходит запись нового значения в стек: например, в стек первого рекурсивного вызова записывается a[0], второго вызова — a[0] + a[1] и т. д. Да, нет присваивания, однако суть процесса не меняется. Он останется итеративным и ему присуще состояние как описатель вычислительного процесса в данный момент времени.

Наконец, третий случай, это когда состояние в принципе отсутствует.

int sum( int[] a ) {
    int sum_impl( int[] a, int index ) {
            if( index != a.length )
                return a[ index ] + sum_impl( a, i + 1);
            else
                return a[ index ];
    }
    return sum_impl( a, 0);
}


Здесь на очередном витке рекурсии алгоритм не знает, на каком уровне он находится и действует так, будто ему надо посчитать сумму чисел от n от a.length, где n — номер рекурсивного вызова. Здесь состояния в принципе нет, это чисто рекурсивный процесс (линейная рекурсия)!

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

А теперь, внимание, вернемся к твоему

S>А если ввести компонент "состояние" в результаты, над которыми оперируют функции в ФП программе, получим императивный алгоритм.


То, что первый вариант — чистый ИП, а третий — чистый ФП, сомнений, наверное, ни у кого нет. А вот со вторым посложнее.

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

Некоторые размышления привели меня к мысли о том, что все таки справедливо второе устверждение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: CreatorCray  
Дата: 21.02.09 12:16
Оценка: 1 (1)
Здравствуйте, criosray, Вы писали:

CC>>Да уже и C++0x подтянулся с лямбдами

C>Уже есть компилляторы?
Да
GCC ICC
Поддержка фич не 100% по кол-ву, но постепенно вводятся
Например в ICC лямбды уже есть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.01.09 21:08
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>По этому поводу тебе отлично ответил Синклер:

VD>http://rsdn.ru/forum/message/3250584.1.aspx
Автор: Sinclair
Дата: 15.01.09


Я не согласен ни с ним, ни с тобой.

E>>Затем, чтобы оправдать утверждение о том, что:

E>>

E>>Однако только немногие решились реально разобраться в нем, и уж совсем немногие действительно разобрались и освоили функциональный подход.


VD>Я кажется не в суде, чтобы что-то там оправдывать.


Т.е., за свои слова ты ответить не хочешь?

VD>Я как раз не заметил разговора о том, что в ней можно было бы улучшить.


Как минимум, выбросить из нее 1/3 налитой в нее "воды". Перестать говорить о гипотетическом "императивном программисте" и, раз уж начал, говорить о себе. Приводить примеры императивного кода не хуже примеров функционального кода.

VD>Ну, кроме найденных двух опечаток.


Да, и дать кому-нибудь на корректуру и вычитку.

VD>ОК. Предположим, что ты конструктивен и хочешь помочь. Но объясни мне, что за статья получится если вместо своих мыслей я буду писать что-то, что удовлетворит твоим возрения на мир? Я думаю получится ахинея.


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

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

можно было бы переписать как:

Аналога FoldRight нет, но требуется он довольно редко, и его нетрудно написать самостоятельно:

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

Или же:

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

записывается как:

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

ну и продолжить как-то так:

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


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


Нет, мне это не интересно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.01.09 07:38
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>О. А мы думали ты к нам подъедешь. Ты где?

Да я на метро Отрадная. Но че-то закрутился тут по работе
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.01.09 10:13
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>По собсно статье (больше пустые придирки, не воспринимайте серьёзно):


S>В примере

S>

S>

S>var ary = new int[]{ 1, 2, 3, 4, 5 };

S>int sum = 0;
S>Array.ForEach(ary, delegate(int elem) { sum += elem; });

S>foreach (var elem in ary)
S>  Console.WriteLine(elem);
S>

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

Согласен. Глупо получилось. Поправим.

S>Слегка некорректно выглядит пример с замыканиями после

S>

S> Функциональное вычисление – функция (или если быть точнее – «чистая функция», pure function) – должна принимать некоторые аргументы (входящие данные) на входе, производить вычисление и возвращать некоторый результат. При этом функция не должна создавать никаких побочных эффектов. Под побочными эффектами понимается:

S>Я-то конеш понимаю, что замыкания и pure functions — разные вещи, может стоило на принципиальной разнице остановиться подробней?

Возможно. Но приведенная цитата — это разговор о чистом ФП. В Шарпе же мы имеем смесь ФП и ИП. Замыкания же хотя и появились в мире ФП неплохо выглядят и во вполне императивном мире.
В общем, подумаю... может быть добавлю кое-какие комментарии.
На меня давит еще и то, что я писал до этого. Все время кажется, что я уже что-то говорил, но это было в другой статье.

S>Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел.


С какой целью? Чтобы было проще искать? Или чтобы ссылаться можно было?

S>Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях.


На то есть оглавление. Да и статья не такая большая чтобы ее резать.
Или речь об переупорядочивании разделов?

S>Ещё стоило бы завести подраздел про то, что любая технология — не панацея и привести ситуации, когда лучше применять конкретные подходы. Привести микротесты, рассказать что вызов _одиночного_ делегата (без списка вызываемых методов) по стоимости сопоставим с virtual call, и что в худшем случае падение производительности будет в 2-5 раз (и что с каждым сп к рантайму соотношение улучшается) в лучшем — будет незаметно из-за стоимости исполнения метода.


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

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


1. Это не серьезная статья. Она так задумывалась.
2. Опять же больше конкретики.

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


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

А взгляд ФП-шника на LINQ на самом деле мало кому интересен.

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

S>Удачи!


Спасибо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: yumi  
Дата: 21.01.09 01:04
Оценка: +1
Здравствуйте, thesz, Вы писали:

E>>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.


T>Вот выделенное шрифтом — это VladD2 написал? Да?


Да. С моей колокольни кажется, что он очень хорошо разобрался и что самое важное, без всяких перекосов в какую-либо из сторон. Не то, что некоторые, не будем показывать пальцами
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.01.09 05:04
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>По ходу у нас обычная путаница в терминологии. Если под linq понимать только сам dsl/представление в expression trees — то он декларативен, тут спорить не о чем.


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


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

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

Далее, не вполне понятно, что такое "чудовищно страшный мегагитлеримперативный код". Вот, к примеру, как ты думаешь, что мы увидим, вскрыв дебаггером MS SQL Server во время работы? Скорее всего, в окрестностях EIP там будет такой код, по сравнению с которым исходники Link2objects покажутся детской песенкой.
Ну и что в том плохого? Этот код был выбран оптимизатором запросов, с учетом большого объема информации, и порвать его по производительности, соблюдая все ограничения, затруднительно.

Так что это нормальная для декларативных языков практика. Более того, я приветствую наличие "суперстрашного" кода в конвеере исполнения — в том смысле, что как правило его устрашнения связаны с оптимизацией. К примеру, в исходных кодах goto и copy/paste — однозначное зло. А во время исполнения это здорово — они превращаются в shortcut evaluation и inlining.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 09:20
Оценка: :)
E>>>

...уж совсем немногие действительно разобрались...

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

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

Это даёт мне время присмотреться, например, к зависимым типам данных. Которые в Хаскеле появились года три назад и в урезанном виде (GADT). И которые в C# если и появятся, то года через три-четыре.

Я намерен их использовать в ближайшем будущем. А разбираться с зависимыми типами данных мы, опять же, попросим VladD2. Коль у него так хорошо получается.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.01.09 09:57
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Гм... может у нас просто взаимонедоперенепонимание?

Есть такое.
S>Я никаким обраом не собираюсь агитировать против или за LINQ. Просто сказал, что надо быть аккуратнее и привёл примеры, когда надо понимать что ты пишешь, ибо декларативное описание может тебя обмануть.
Гм. Продолжаю непонимать:
1. А есть какие-то примеры, когда можно не понимать, что пишешь? В принципе, пока ты не задумываешься о производительности, либо "побочных эффектах" то любая абстракция хороша в том смысле, что ты не обязан разбираться, во что она там унутре выливается. Простой пример: 99% современных программистов имеют весьма отдаленное представление о том, в какие процессорные инструкции превращается их код (сюда входит и значительная доля тех, кто думает, что понимает). Никаких особенных проблем это не вызывает: производительность 90% приложений на рынке вполне достаточна.
2. Каким именно образом декларативное описание может "обмануть"? Вот в соседнем форуме оказалось, что одного товарища всю жизнь обманывал Соломон, обещая корректную алфавитную сортировку для FindFirstFile/FindNextFile на NTFS. И никак этот товарищ не хочет поверить, что никаких обещаний никто ему не делал, что он это додумал самостоятельно, интерпретируя непонятные слова неверным образом. А теперь испытывает те же эмоции, что и ПТУшница, обнаружив, что её интерпретация вечерних обещаний оказалась далека от авторской.

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

А то, что ты ожидаешь каких-то волшебных performance характеристик — это болезнь молодости. Почитай Хайнлайна по ключевым словам "беспристрастный свидетель":

- какого цвета вон тот дом на холме?
те две стены, которые я вижу отсюда, светло-голубые.



S>Да. Тут наверно всё дело в том, что у меня по дефолту под Linq понимается именно linq2Objects с реализацией через итераторы и т.п.

Опять же, лучше уточнять. У очень многих людей по дефолту под Linq понимается именно Linq2Sql.

S>Угу-угу. Имелось в виду то, что в тру декларативном описании ты не определяешь алгоритм, а только описываешь граничные условия. Проблема только в том, что не всегда очевидно — ты описываешь запрос или пишеь как он будет выполняться. Ну дык внимательно надо.

А можно мне показать пример описания "как он будет выполняться" в декларативном стиле?

S>ЗЫ. Может уже закончим переуточнять? По-моему, тема исчерпана.

Нет уж, давай порисуем.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 11:35
Оценка: :)
E>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?
VD>Из практики чтения чужого кода. Поверь, не малой практики.

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

Всё нормально у императивщиков при переходе на ФЯ.

VD>Скажу больше. Я сам бы очень хотел бы наткнуться на подобную статью году эдак в 2005-ом или 2006. А лучше еще раньше. Вместо этого я нарывался на трехколенные выпендрежи, понты и замуности которые мало что давали с точки зрения понимания принципов ФП. По сути только попытка разобраться с Немерле позволила мне понять принципы ФП. И, о чудо, все оказалось совсем просто. Оказывается проблемы были не в моем скудном уме, а в неумении других объяснять весьма простые вещи. Вот эта статья и есть попытка объяснить эти простые вещи для таких же простых парней как я.


Перевод этой сентенции на русский язык настолько ярок, "it can blind you by pure awesomness".

Если я его опубликую, то меня забанят, да.

Этот параграф очень, очень показателен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 14:51
Оценка: :)
EC>>>А на них разве пишут "обычные" программы?
T>>define "обычные". Why should I ask in first place?
EC>Для более-менее конечного пользователя, а не для computer scienetist'ов.

CompCert подойдёт?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: yumi  
Дата: 22.01.09 00:41
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

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


Слушай, я смотрел эту тему. Там Влад писал, что задачки слишком простые, чтобы продемонстировать пользу ФП и что эти задачки можно решить и императивно. Явного выигрыша использования ФП в которых не видно. Все. Это основная его мысль была, насколько я этого понял. Но пришел один товарищ, не будем показывать пальцем и начал прикапываться к деталям. Видимо тут просто какая-то личная неприязнь Постоянно наблюдаю.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 22.01.09 15:34
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

EC>>Как здесь недавно совершенно верно заметили на чистом ФЯ вполне можно программировать императивно.


LP>Более того, на чистом ФЯ нужно программировать императивно (нужно == приходится). Вопрос — нахрена тогда чистый ФЯ.


Ты перед словом "нужно" забыл поставить иногда.
now playing: Frank Martiniq — Adriano (Michael Mayer Remix)
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 15:42
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

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


EC>>>Как здесь недавно совершенно верно заметили на чистом ФЯ вполне можно программировать императивно.


LP>>Более того, на чистом ФЯ нужно программировать императивно (нужно == приходится). Вопрос — нахрена тогда чистый ФЯ.


EC>Ты перед словом "нужно" забыл поставить иногда.


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

PS Впрочем, я не против Хаскеля. Хаскель — идеальный язык. Жалко, на нем нельзя писать программы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 22.01.09 15:54
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

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


А "требуется" как правило определяется мышлением, привязанным к тому самому другому языку.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 24.01.09 18:30
Оценка: :)
Здравствуйте, LaPerouse, Вы писали:

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


То есть ты пишешь на Ocaml?
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 16:50
Оценка: -1
Здравствуйте, lomeo, Вы писали:

L>Императивное — это значит последовательное, разве нет? Ну и плюс отсюда вытекает состояние. Т.е. я не имел в виду именно GUI, интерактивность и т.д. Надо было придумать какой-то пример, вот я его и взял. На самом деле, как мне кажется, нет разницы что именно мы программируем. Если мы можем удобно запрограммировать императивно на Haskell одну вещь, то, наверное, сможем и другую. Т.е. я не вижу, почему твой императивный алгоритм на Haskell запишется хуже, чем на Яве (раз уж ты её приводил в пример). Можно как нибудь раскрыть этот момент?


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

Меж тем заметное приемущество в объеме кода и в его понятности Хаскель дает только по сравнению с Явой или С++. С последним вообще очень удобно мериться если речь идет о выскокуровневых конструкциях. Там отсутствие GC и замыканий, плюс наличие небезопасного кода приводит к необходимости таких приседаний, что все что угодно на его фоне выглядит хорошо. Даже Ява, не то что Хаскель.

Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 17:20
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>Если серьезно, то не так уж и много (для java):


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

LP>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>3. Templates как в С++
LP>4. Сопоставление с образцом

Это называется Scala.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 07:57
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>В смысле? Который день я уже "тусущеся" в этой теме?


Ага.

T>О чем мои комментарии здесь?


А ни о чем. Тупо рекламируешь Хаскель в теме где ему совсем не место и попутно откровенно наезжаешь на окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:23
Оценка: -1
Здравствуйте, LaPerouse, Вы писали:

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


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


LP>>>Если серьезно, то не так уж и много (для java):


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

LP>>>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>>>3. Templates как в С++
LP>>>4. Сопоставление с образцом

VD>>Это называется Scala.


LP>в принципе, это мелочи, доменную модель можно и на java сделать


Хотя это бред, лучше использовать xml-маппинги
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:32
Оценка: +1
Здравствуйте, lomeo, Вы писали:

L>Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных


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

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

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

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

С другой стороны иногда императивное изменение является единственным выходом к достижению приемлемой производительности. И с этим ничего не поделаешь. Потому каждый случай рассматривать отдельно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:36
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

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


Поверь. Любой алгоритм можно переписать в функциональном стиле и он от этого в 90% случаев станет короче и яснее.

Проблема только в том, что зачастую скоростная характеристика алгоритма изменится в худшую сторону. Плюс ухудшится и общая производительность, так как в ФЯ-коде используется множество абстракций за который приходится платить. Чисто теоретически последнее могут устранить разные де-деревизаторы и супер-компиляторы, но на практике все равно платить за абстракцию придется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 19:14
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

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


VD>>Не не могу, а не хочу и вижу в этом смысла.


VE>А в сыпаньи голословными утверждениями ты видишь смысл? Кому ты хочешь что-то доказать?


Разверни свои слова на 180". Они к тебе применимы на 100%.

VE>Главное вот влез в разговор с провокацией "главный вопрос, зачем нужен чистый ленивый язык".


А я вам не очень мешаю разводить офтоп в этой теме?
Вообще у вас все темы в разговоры о хаскеле превращаются. Это уже натруальный пунктик.
Парень спросит как переписать код на С в код на C#, а ему про Хаскель расскажут.
eao197 заведет разговор о стилистике чужой статьи и тут про Хаскель 5 копеек вставят. И ни дай бог сменить тему. А уж если спросишь зачем он нужен, так вообще врагом народа обзовут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 19:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тогда в теме вообще чушь обсуждается. Вместо этого надо говорить, что те кто говорит "я знаком с ФП" просто не знакомы с ним.


"Знаком с ФП" == "Реально разобрался"?
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 19:25
Оценка: :)
Здравствуйте, lomeo, Вы писали:

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


L>Влад, захочешь пообщаться — прекращай троллить.


Боюсь, что он не тролль.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 19:33
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

VE>Не успел задать вопрос, как оказался причислен к неким "у вас".

VE>Однако. "Он меня бросил, все мужыки козлы!". Где _я_ про Хаскель тут говорил кроме ответа на твоё утверждение и на вопрос о Хаскеле? Ты бы к лагерям не причислял, и тебя не будут.
VE>Так что ты перечитывай, когда ответы пишешь.

Он про меня говорил. Мы с LaPerouse говорили о IO монаде в хаскеле.

И вообще. Много мусорных сообщений в теме. Например, это ;-) Пора завязывать.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 29.01.09 08:46
Оценка: :)
Здравствуйте, thesz, Вы писали:

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


T>Теперь представь, что тебе надо оценивать изменения. Алгоритм преобразования такой, что не всегда даёт оптимизирующее преобразование. Ну, так случилось.


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

PS: На остальные вопросы в данной теме отвечать пока времени нет, скажу лишь, что по поводу монады IO у меня мнение не изменилось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 20:45
Оценка: :)
Здравствуйте, lomeo, Вы писали:

VD>>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.


L>Сравнивал. Если ты про Скала/Немерле, то не улетучивалось.


Да его просто нет. Вот когда начнете Хаскель хотя бы с ОКамлом сравнивать (которому до перечисленных языков довольно долеко), тогда можно будет о чем-то поговорить. А то ваши рассуждения по жизни строятся на базе демонстрации преимущества Хаскеля перед С++, а потом все остальные языки тупо принимаются за равные С++.

Конечно у Хаскеля не может не быть своих преимуществ, как у любого хоть что-то стоящего языка. Но и у других языков они тоже есть. Выигрывая в одном проигрываешь в другом. Это неизбежно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 20:50
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>Честно говоря я имею о Ocaml лишь отдаленное представление (смотрел где-то год назад F#), какое-то определенное мнение не смог составить. Не думаю, что для него существует поддержка платформы java, сравнимая со Scala, которая только для jvm и разрабоатывается. Так что если выбирать между ними, то конечно, выберу Scala — уже только из практических соображений.


ОКамл и Скалу нужно не "посмотреть", а изучить, осознать и научиться эффективно применять. Это другой взгляд на написания кода, как минимум внутри методов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.01.09 14:58
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Это IMHO — о чём тут спорить?

VD>Казалось бы не к чему. Но вы же постоянно спорите. У меня не было бы претензий если бы вы говорили, что Хачкель один из лучших ФЯ. Что он чистый и т.п. Но вы же все время просто таки втираете, что он лучший, что он на голову лучше всего окружающего и т.п. По крайней мере у меня складывается такое впечатление.

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

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


Чем модули не устраивают, поясни.

VD>С такой постановкой я в жизни бы не поспорил. Но ты почитай свои же, и другие рассуждения о Хаскеле. Вы же не говорите, что это вам нравится или вам подходит для ваших задач? У вас получается просто таки безальтернативный выбор. Некоторые заходят настолько далеко, что начинают приписывать ленивость к обязательным свойствам ФП.


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

Ленивость нет, но non-strictness — обязательное свойство безкомпромисного ФП, ага. Лямбда исчисление и "функция в математическом смысле", никуда не денешься!

VD>Мне тут не редко орлы вроде еао197 или АВК говорили, что я мол слишком сильно толкаю Немерле. Но ёлы-палы! Где я предлагал его использовать без оглядки на задачи и условия? Я сразу говорю, что если вы седите на Яве, то ваш билет в мир ФП — это Скала. Если в дотнете, то Nemerle, F# и даже C# с LINQ. Если вам нужны компилируемые в нэйтив модули, то выбор совсем другой. Тут уже нужно выбирать между Хаскелем, ОКамлом, Лиспом и т.п. Причем Хаскель сразу не проходит если речь идет высокопроизводительных вычислений, но может быть предпочтительнее если нужно получить более высокоуровневые абстракции. Кстати, Хаскель идет лесом и в случае если людям нужен классический ООП. Тут ОКамл будет куда приемлемее.


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

VD>А посмотри что вы вытворяете?... Парень спрашивает как ему С на C# перевести, а ему отвечают, что есть такая замечательная штука как экстер-си в С++ и Хасклевый экспорт. Это вообще вменяемый ответ?


Где я такое писал??
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 17:12
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

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


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

Что если на любое твое утверждение потребовать с тебя доказательства?

VE>Верующие во что?


Это ты лепишь мне ярлык. Ты и объясняй во что. И главное не забывай доказывать. А то ты возомнил себя правым в последней инстанции и разговариваешь тоном ментора. Смешно право.

VE>Я, в отличие от тебя, знаю, что Хаскель не идеален


В отличии от меня? Ну, вот и обоснуй свое голословное утверждение о том, что я считаю Хаскель идеальным.
А то, на мой взгляд, оно даже не то чтобы голословное, а очевидно ложное.

VE>(ну по крайней мере чаще всего именно ты говоришь, что ФП панацея),


Да? Примеры в студию!

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


Где заговорил? В каком контексте?

VE>Вот на Немерле код — как спагетти по сравнению с Хаскелем.


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

VE> Я правда доказывать ничего не буду. Это просто факт.


Ты и так ни одного своего слова не то что бы не доказал, даже обосновать не потрудился. Так что о чем ты тыут ведешь речь я не пойму.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 30.01.09 18:42
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>Что лично меня раздражает в Хаскеле, так это лексика и синтаксис. Хоть убей не пойму, как его можно назвать простым? Все эти лексемы типа «::», «:l», «++» (для бинарного оператора), «@», «$» и тому подобный мусор совсем не способствуют восприятию неофитами кода на Хаскеле. Я понимаю код на Схеме, Немерле, ОКамле, вполне воспринимаю математическую нотацию (лямбда-исчисление, основы теории категорий). Но как только вижу статью про Хаскель (да вот хотя бы твои посты на Хабре) — так сразу глаза и мозг возмущаются, глядя на это синтаксическое недоразумение. Сколько раз открывал книжки Душкина, чтоб таки проникнуться — раз за разом неодолимое отторжение.

Книжки Душкина просто написаны очень странным языком (особенно первая), это проблема книги, а не Haskell.
now playing: Squarepusher — Zounds Perspex
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 30.01.09 20:12
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VE>>"ФП (Хаскель) не панацея" слышно только от тебя. И несмотря на то, что каждый раз тебе отвечают "ну... да, а это к чему?", всё равно ты никак себя не убедишь. И всё-то тебе кажется, что остальные говорят обратное. Чудной ты человек.


VD>Как раз таки нет. Не то что отвечают. Переодически заявляют, что самая, что ни на есть панацея.

VD>Понятно, что не все. Но есть товарищи...

Ну не знаю. Я лично слышал "ФП — серебряная пуля" только от thesz. Только знаешь в каком смысле (не с потолка смысл пишу, у него есть пояснение)? Что по совокупности всех факторов Хаскель предпочтительнее всего остального. Ты говоришь абсолютно то же самое, разница только в языке.
Я, правда, с Вами обоими не согласен, так как серебряность не определяется в отрыве от: человека, задачи, внешних условий.
Поэтому можно сказать разве что так: для меня при моих задачах и условиях, язык <имярек> является серебряной пулей.
Если же начинать рассуждать, что "естественно я подразумевал себя и свои задачи", то так можно до чего угодно договориться.
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 09:35
Оценка: +1
Здравствуйте, FR, Вы писали:

Q>>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.


FR>Если под NET используется F# или Nemerle конечно сомнительно. Если же Шарп то по моему все таки Хаскель намного более выразительный язык.


Да, в том-то и дело, на производительность программиста влияет не только язык, а вся связка язык + библиотеки + рантайм, то есть в моём случае .NET-языки + FCL + CLR.
1) ЯП. Я не ограничен одним языком, могу один проект писать на C# (привычнее), соседний проект на F# (немного мощнее), тривиальный интероп (а не всякие адские байндинги через Си). Со следующей версии Студии F# будет иметь поддержку инфраструктуры: визарды, code-behind для GUI- и веб-проектов, etc.
2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».
3) Рантайм. В этот пункт можно включить производительность, переносимость, особенности сборки мусора, утечки ленивых цепочек, etc.

Ну и плюс некоторые другие параметры: документация, IDE, организованность сообщества, поддержка от производителя, etc.

По совокупности имеющейся информации о Хаскеле пока что я не могу сделать вывод о «вдвое и больше». Разве что так: «возможно, существует узкий круг задач, для которых производительность программиста на Хаскеле вдвое выше, чем .NET-программиста». Но никак не «для большинства задач Хаскель предоставляет прирост в производительности вдвое и больше».
Глаза у меня добрые, но рубашка — смирительная!
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 02.02.09 10:46
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале.


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

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


По обрывку приведенного алгоритма lomeo совершенно правильно восстановил суть задачи и привел правильную реализацию алгоритма. Я без проблем понял его код, и не отрицаю, ошибался по поводу конкретного примера. См. выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 02.02.09 12:20
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

T>>В конечном счёте все определяется количеством строк, которые необходимо написать


Q>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?


Нет код на Brainfuck не компактный, хотя сам язык очень даже.
Вот J да Хаскелю много форы может дать

Вообще на простых компактных языках, например на обероне или яве часто получается некомпактный код.
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 02.02.09 18:00
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.


Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 02.02.09 23:07
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>>>Всё это подводит нас к интересной проблеме.

VE>>Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.

T>Я не понял тезиса.


Для записи решения задачи язык почти не важен. Однако умение думать на некоем языке полезно, так как даёт простор, записать само решение можно почти на чём угодно, поэтому на первый план зачастую выходит именно удобство интеграции.
Новая задача, она новая везде, решить я её могу на "Хаскеле", а её решение записать потом на C#.
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 03.02.09 07:27
Оценка: +1
Здравствуйте, thesz, Вы писали:

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

VD>>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.

T>Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками.


Тут есть большая разница. Буква ять не несет никакой смысловой нагрузки и не способствует более быстрому пониманию текста, к тому же требует типографской краски. А скобочки помогают воспринимать текст программы, что же касается "типографской краски", то есть в нашем случае скорости набора, то современные IDE, которыми оснащены эти самые языки со скобочками, расставляют скобочки автоматом.

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


Вот это совершенно непонятно. Каким образом это скобочки увеличат количество ошибок? По мне — они и количество ошибок при написании не увеличивают, и допущенные ошибки исправлять помогают, так как увеличивается читаемость.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.02.09 08:23
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>Тут мы сделали перенос строки из-за длинной строки, там мы его сделали... Перед компиляцией не всю (под)программу просмотрели — на запуск ушёл неправильный код. Начали искать ошибку — надо больше текста просмотреть. И тд, и тп.


Детский сад.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.02.09 08:28
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>Зачем, вообще, такое количество ЯП?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.02.09 12:05
Оценка: +1
Здравствуйте, thesz, Вы писали:

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


T>Что это, как не мощность?


E>>Языки C, C++, Perl, Ruby, Java вряд ли были самыми мощными (с точки зрения языковых возможностей на тот момент), тем не менее, точком к их созданию явилось желание иметь удобный инструмент, необходимый авторам здесь и сейчас.


T>А это разве не мощность?


Имхо, в контексте данного обсуждения, не мощность. Мощность -- это, например, поддержка вывода типов, ленивых вычислений, алгебраических типов, сопоставления с образцом и, сюда же можно включить симпатичные тебе зависимые типы. Удобство -- это когда кто-то предпочитает begin/end фигурным скобочкам или наоборот


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 13:05
Оценка: :)
E>>>Языки C, C++, Perl, Ruby, Java вряд ли были самыми мощными (с точки зрения языковых возможностей на тот момент), тем не менее, точком к их созданию явилось желание иметь удобный инструмент, необходимый авторам здесь и сейчас.
T>>А это разве не мощность?
E>Имхо, в контексте данного обсуждения, не мощность. Мощность -- это, например, поддержка вывода типов, ленивых вычислений, алгебраических типов, сопоставления с образцом и, сюда же можно включить симпатичные тебе зависимые типы. Удобство -- это когда кто-то предпочитает begin/end фигурным скобочкам или наоборот

I beg to differ.

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

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

Оно смешно, конечно, но более или менее верно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 05:08
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:

MZ>VladD2 пишет:


>> Дык разница между синтаксисом и семантикой С и Паскаля очень

>> незначительная.

MZ>Влад, ты ГЛУБОКО неправ. Паскаль — очень строго типизированный язык.


Это без разницы. Тем не мене языки близки. Их можно изучать составив отображение фич одного в фичи другого.
Скобки меняем на begin/end, function/procedure на синтаксис функции в С и так далее...

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

MZ>С — модульный язык, Паскаль — нет.


Гы-гы. Реальные реализации Паскаля (Турбо Паскаль) были реально модульными. А С как раз пользовался убогим инклюдом. Но это опять же не имеет никакого отношения к восприятию языка.

MZ>Синтаксис — в общем пофигу, но в паскале строго всё разложено

MZ>по секциям, в С — где что напишешь,то и будет.

Синтаксис и семантика — это то что делают язык языком. А мелкие детали вроде модульности... это и есть детали которые не вызывают проблем с пониманием.

Любой кто изучал С после Паскаля и ОКамл после С поймет о чем я говорю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 09.02.09 07:45
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:

MZ>С — модульный язык, Паскаль — нет.


Глаза у меня добрые, но рубашка — смирительная!
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 10:25
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:

MZ>VladD2 wrote:


>> К тому же строготипизированным был виртовский паскаль, который

>> практически не применим для программирования. Даже две строки нельзя
>> сравниь если у них разная длинна. Ну, что это такое?

MZ>А я другого не знаю. Есть язык, называется "паскаль", его придумал вирт.


О чем это говорит?
Или о уровня твоего развития, или о том, что ты ради флэйма готов кривить душой.

На практике использовался Турбо паскаль/Объхект паскаль/Дельфи. Когда кто-то говорит сегодня "Паскаль", то большинству программистов впоминаются именно они.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.02.09 12:29
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А я говорю, что не меньшую чем другие факторы.


Может опять — причина в разном опыте?

VD>Ну, это же просто как дважды два и очевидно! Если изучать нужно меньше, то и процесс обучения идет проще.


Согласен. Однако возьмём два совершенно непохожих синтаксически языка — схема и хаскель. У меня переход был именно такой — от схемы я пришёл к хаскелю. Языки совершенно различны в плане синтаксиса, однако синтаксис совершенно не был для меня проблемой — по крайне мере на фоне всего остального я даже не припомню какие то трудности восприятия. У меня там совсем другие трудности были.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.02.09 13:12
Оценка: +1
VD>>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.
T>>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.
T>>Уж коли ты так хорошо во всём разобрался.
VD>Мы говорили о близости языков. Не о знании глубин, а о возможности понимать текст одного языка зная другой и синтаксические различия между ними.
VD>Ты хочешь сказать, что зная Хаскель и различие его с ОКамлом по синтаксису я не смогу читать код который не использует ООП ОКамла (который и правда сильно отличается от хаскелевского подхода)?

Ты как-то в одну сторону всё повернул. Зная Хаскель, я смогу читать код на ОКамле с меньшим количеством ошибок, чем наоборот. Вот наоборот ты не рассмотрел.

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

В Хаскеле есть классы типов, есть kinds, есть GADT (практически, зависимые типы данных — я про них не зря намекнул).

Разница между OCaml и Хаскелем такая же, как между Си первых Юниксов и современным C++. Ну, или как между ТурбоПаскалем 5.0 и Ада.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 07:15
Оценка: :)
Здравствуйте, thesz, Вы писали:

LP>>>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.

T>>>Наличие выбора порождает трату времени на разрешение его проблемы.
LP>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

T>Да, именно так.


Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 12:23
Оценка: +1
Здравствуйте, thesz, Вы писали:

Q>>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного :)


T>Это очень неправильное О.


T>Для этого человека нет ничего невозможного в написании программы...


Я как раз таки имел в виду не возможность (или невозможность) написания программ, а лёгкость в понимании других языков и подходов. Взять, например, ФП на C# (наверное, для хаскельщиков это смешно звучит). Вот новичок видит описание новых фич: замыкания, итераторы (CPS aka «yield return»), LINQ. Но начав использовать, натыкается на грабли: сохранённая лямбда вдруг начинает возвращать разные результаты, некоторые функции легко обрабатывают бесконечные последовательности, а некоторые на них падают со StackOverflow, OrderBy почему-то не сортирует последовательность. Человек без C++-бэкграунда пойдёт копать документацию или спрашивать на форум. А C++-программисту это в большинстве случаев не надо, ведь он знает, как устроено «мясо». Он может вывести ранее неизвестные неочевидные фичи языковых конструкций, просто прогоняя в уме их потенциальную реализацию. Т. о. он получает новые по сути знания, и может предсказать поведение неопробованных конструкций языка, просто с помощью анализа своего предыдущего опыта программирования на C++. Это прекрасно!
Глаза у меня добрые, но рубашка — смирительная!
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 10.02.09 12:29
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>По мне так это весьма полезно — научиться писать в функциональном стиле на C++. После того, как набъёшь руку с boost::bind, никакой карринг уже не испугает 


После того как увидел карринг в Хаскеле, от boost:bind тошнить начинает . А, вообще, полезно, только язык тебе не помогает, а мешает выражать свои мысли.

DC>>(меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" ).


Q>А в чём проблема ответить? 1) захват контекста (обычно передача окружения в ктор функтора), 2) возможность комбинировать операции (на указателях-на-функцию суперпозиции не сделаешь), 3) возможность

манипулирования ФВП (например, сфабриковать внутри функции другую функцию и вернуть её в качестве результата).

"...А теперь попробуй объяснить им (средневековым монахам) что ты муж ведьмы, не используя обороты типа : Толерантное отношение к магическим меньшинствам..."
© Белянин С.
Человек только начал въезжать в С++ с его ООП и прочей фигнёй. Объяснить не трудно, важно дать понять зачем это надо и как использовать.

Q>В функциональных языках всё готовенькое, меньше пищи для размышлений — прозрачные замыкания, халявный карринг, etc. А C++-программисту волей-неволей приходится врубаться в потроха таких вычислений. Перечисленные выше пункты дают понимание (соответственно): 1) лексических замыканий, 2) деревьев выражений, 3) отложенных вычислений.


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

Q>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного 


Я вообще не об этом, я о том, что проще изучать приёмы программирования используя синтаксис, который упрощает его понимание человеком, а не машиной.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 13:26
Оценка: +1
Здравствуйте, dr.Chaos, Вы писали:

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

DC>Ну как монстрик обрисовывается?

Отсюда вывод — цикл рулит.

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

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


[ arr!name | (_,name,_) <- foos ]
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 13:26
Оценка: -1
LP>>>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
T>>>>Тебе гибкость иметь или программу писать?
LP>>>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.
T>>Кого не устраивает?
LP>Пока — меня. Потом будет не устраивать пользователей.

Ladies and gentleman!

Here we have an extremely revealing case of premature optimization!

You often find it in the wild under the 'perfectionism' disguise.

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

И эти люди запрещают нам ковырять (строка вычеркнута)

И этим людям требуется гибкость.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 10.02.09 14:51
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>Синтаксис C++ страшен, но опыт вынужденного написания своих замыканий или комбинаторов упрощает понимание реализации «этих концепций». Это позволяет делать правдоподобные априорные заключения о скорости и асимптотической сложности вычислений, о специфике взаимодействия с GC и ресурсами системы, и многих других вещей.


Ты помнишь, вообще, о чём был мой первый пост в этой теме? Прочти его пожалуйста снова. Я там говорил явно не о реализации концепций. Мало того есть серьёзные сомнения, что реализация замыканий и комбинаторов на С++, поможет определить сложность вычислений и потребление ресурсов в языке с GC. А то как устроены замыкания хорошо сказано в SICP причём в описании вычислительной модели.

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

ЗЫ Вспомнились языки APL, K, J. Я на них никогда, ничего не писал, и даже не вникал в концепции заложенные в них. Интересно их синтаксис помогает?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 15:45
Оценка: -1
Здравствуйте, thesz, Вы писали:

T>Мой "вывод" такой: настоящий опыт даёт разнообразие предметных областей. Чем больше их перебрано за карьеру, тем лучше. Наиболее выразительный язык даёт возможность справляться с очередной областью быстрее всего. Далее — ваш выбор.


Приходилось ли вам писать программы для бухгалтерии или для складского учета?

T>А зачем тогда это писать?


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


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


Очень просто: одним из стимулов для разработчика является его собственная увлеченность в том, чем он занимается. Поэтому если одного и того же человека посадить писать компилятор или GUI формы для системы складского учета, то очень легко можно получить существенно результаты работы (в скорости разработки и качестве продукта) даже при ответственном отношении к делу. И, к сожалению, степень ответственности разработчика так же сильно зависит от того, нравится ли ему его текущее задание или нет.

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

T>>>Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?

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

T>Любой выбор программиста может быть оценён. Это и есть критерий проверки.


Можете продемострировать, как оценить, например, выбор имен переменных/методов? В Ruby, например, есть метод to_a для преобразования значения в массив. В других языках аналогичный метод было бы принятно называть toArray или ToArray. Как оценить, какое из них является лучшим?

E>>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?


T>Псевдодилемма подсунута довольно ловко. Я оценил.


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

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


T>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.


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

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


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

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


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


Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?

Или еще одна ситуация. Прикладная система состоит из нескольких частей. Первая часть генерирует большие текстовые файлы (например, в csv-формате). Вторая часть импортирует их в РСУБД. Обе части написаны на разных языках и работают на разном железе. Некоторые из столбцов в РСУБД имеют ограничения на размер. В первую часть вносятся изменения, при которых значения в текстовых файлах могут оказаться на один-два символа длинее, чем соотвествующие столбцы в РСУБД. Чем здесь поможет ФП?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 16:51
Оценка: +1
T>>Мой "вывод" такой: настоящий опыт даёт разнообразие предметных областей. Чем больше их перебрано за карьеру, тем лучше. Наиболее выразительный язык даёт возможность справляться с очередной областью быстрее всего. Далее — ваш выбор.
E>Приходилось ли вам писать программы для бухгалтерии или для складского учета?

Да. Два раза, полгода и год я на это потратил. dBaseIV и тикль.

T>>А зачем тогда это писать?

T>>Мы, вроде, люди все взрослые, все умеем относиться к работе ответственно, нам об этом напоминать не надо.
T>>Поэтому единственный вариант, когда вот так, без подталкивания со стороны собеседника начинают говорить об ответственности, это вариант с приятным тёплым внутренним чувством.
E>Очень просто: одним из стимулов для разработчика является его собственная увлеченность в том, чем он занимается. Поэтому если одного и того же человека посадить писать компилятор или GUI формы для системы складского учета, то очень легко можно получить существенно результаты работы (в скорости разработки и качестве продукта) даже при ответственном отношении к делу. И, к сожалению, степень ответственности разработчика так же сильно зависит от того, нравится ли ему его текущее задание или нет.
E>Поэтому не нужно приводить в пример такие задачи, как разработка компиляторов. Многие из здесь присутствующих, наверное, хотело бы заниматься разработкой компляторов. Только это все равно невозможно, т.к. нафиг никому не нужно такое количество разработчиков компиляторов.

О!.. Я понял. Переформулируем.

Один может два месяца возиться с реализацией замыканий на C++, тогда как выгодней сделать за те же два месяца всю программу складского учёта. И получить полезные знания, как то — динамическое программирование при планировании загрузки стеллажей. Может, что-то ещё. Но уж точно — отточить своё мышление в ФП стиле, вместо MPD стиля "ФП на C++".

И удачно завершив проект, приступить, наконец, к разработке компилятора!

E>>>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?

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

Я приверженец "поменьше работать". Детерминизм вы за меня придумали.

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

T>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.
E>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.

Ваш логический вывод "в моей логике" мне недоступен, надо отметить.

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

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

Напомню, что я первый высказал просьбу.

Тем не менее — fudgets. Точнее, их stream processors.

Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.

Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.

Вот ваш вариант:
    +-+ +-+
----|B|-|M|----> куда-то на
    | | +-+  +-> мультиплексор
    | |      |
    | |------+
    +-+



Вот вариант с чисто функциональной прокладкой:
    +-+ +-+ +-+
----|B|-|M|-| |---> куда-то на...
    | | +-+ | |
    | |     | |
    | +-----+ |
    |         |
    +---------+

То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.

E>Или еще одна ситуация. Прикладная система состоит из нескольких частей. Первая часть генерирует большие текстовые файлы (например, в csv-формате). Вторая часть импортирует их в РСУБД. Обе части написаны на разных языках и работают на разном железе. Некоторые из столбцов в РСУБД имеют ограничения на размер. В первую часть вносятся изменения, при которых значения в текстовых файлах могут оказаться на один-два символа длинее, чем соотвествующие столбцы в РСУБД. Чем здесь поможет ФП?


Оба-на! Вторая просьба.

Я оценил перевод стрелок, да.

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

С напоминаниями всё, надеюсь, они не пропадут втуне. Перейду к вашему примеру. И скажу ровно одно слово: КОДОГЕНЕРАЦИЯ. По единой спецификации.

Подойдёт?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 17:01
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.

E>>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.

T>Ваш логический вывод "в моей логике" мне недоступен, надо отметить.


Если интерфейс настолько прост, что позволяет быстро приступить к работе, то это вовсе не означает что он будет настолько же хорошо экономить время в дальнейшем. Доказательством чего служат редакторы ViM и Emacs (а так же LaTeX) -- где нужно потратить изрядное время на первые шаги (т.е. длительное время без полезной работы вообще), зато потом это компенсируется более эффективной работой.

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

E>>Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?

T>Напомню, что я первый высказал просьбу.


Для того, чтобы показывать системы на ФЯ их нужно видеть, а еще лучше иметь в своем распоряжении. Я таковых в своем распоряжении не имею. Но, мой второй пример с импортом данных в РСУБД совершенно безразличен к языку программирования, на котором реализованы компоненты системы.

T>С напоминаниями всё, надеюсь, они не пропадут втуне. Перейду к вашему примеру. И скажу ровно одно слово: КОДОГЕНЕРАЦИЯ. По единой спецификации.


T>Подойдёт?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 10.02.09 20:22
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


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


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


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


E>Это все не из той оперы. Ситуация, выраженная на объектно-ориентированном языке такова:

E>skipped...
E>Здесь заложено поведение, что в методе S.queryState() _всегда_ вызывается метод sendStateNotification и объекта mailslot, который объект S получает в конструкторе и не может изменить в течении всей жизни. Изменение этого поведения (например, не вызов метода sendStateNotification() или вызов его для другого объекта Mailslot) должно приводить к тому, что остальные модули системы, обращаются к S, не должны даже скомпилироваться. Функциональное программирование как-нибудь решает эту проблему?

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


E>Я вот не понимаю, если вы настолько уверены в собственной правоте, то зачем подобные выпады в сторону собеседника?


Так, стоп.

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


Я правильно понимаю, что если Сергей сейчас не спляшет, и не изменит одну строку (Вами же и указанную (я утрировал)) в императивной системе так, чтобы всё заработало, то Вы типа показали, как "внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений"?
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 10.02.09 22:27
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

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

1) так же субъективно, как и нелюбовь к закорючкам
2) видимо как-то к синтаксису относится? я просто всю ветвь перечитал, а не понял, причём тут переход к .NET, F#, Nemerle и выбору языка
3) это плюс или минус?
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 23:07
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

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


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

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

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


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

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


Это плюс.
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 11.02.09 05:52
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

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

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

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

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

Я, конечно, не буду говорить, что сам бы везде предпочёл Хаскель, но именно из-за отсутствия .NET или каких-либо библиотек, и в некоторой неуверенности, что если мне, например, придётся делать кастомный контрол, да руками его рисовать, что я вообще осилю это на каком-нибудь wxHaskell, а вот на C#/C++ — точно сделаю. Т.е. банально проверенные миллионами (уж тем более мной лично) технологии как-то надёжнее, вдруг какая библиотека на Haskell развалится в середине проекта, а спросить почти некого, а по .NET'у тому же пол интернета форумов, кто-нибудь да сталкивался, и проект по крайней мере не встанет.
А чисто как язык он очень удобен, но в двух примерах этого не покажешь (тем более если убедиться хотят в обратном), это понимание само приходит.
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.02.09 07:35
Оценка: -1
Здравствуйте, lomeo, Вы писали:

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


L>4) грязные

Это хорошо, можно писать императивный код там где он уместен.

L>5) энергичные

Лучше энергичность по-умолчанию, чем ленивость.
Хотя остсутствие возможности задать ленивость декларативно — это плохо.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 09:42
Оценка: :)
T>>We all yet to see your article named "Обобщённые алгебраические типы, как шаг к зависимым типам данных", ага.
VD>У тебя проблемы с общением на русском?

Мне так интересней выражаться.

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


А ты знаешь, зачем нужны GADT?

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

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

We all yet to see... и далее по тексту.

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

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

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

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

За одним исключением — если можно сравнивать с наиболее чистым вариантом.

Но зачем мучиться и сравнивать, если можно использовать сразу?

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


Вопросы мотивации шерифа волнуют весьма умеренно.

Второе. Такое отношение к людям, как у тебя — их, бедненьких, надо защищать от вьюг и морозов ФП, от палящего зноя систем типов, — унижает твоих же коллег.

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

Поэтому надо бить в лоб. Вот тебе Хаскель. Ты программист. Справишься.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 09:59
Оценка: +1
T>>Возьмите другой пример. Там, где изменения в случае написания системы на ФЯ всё равно приведут к неконтролируемому распространению изменения инвариантов. Типа, "поменяли мы тут, а вылезло вон там".
E>Был у меня когда-то такой случай. На web-форме запрашивался пароль пользователя, затем строился хеш пароля и хэш сохранялся в куках. Через какое-то время выяснилось, что используемая хэш-функция генерирует символы, которые не могут сохраняться в куках без специального экранирования.

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


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

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

Сделать проблематичный внутренний интерфейс на ФЯ достаточно тяжёлая задача.

Собственно, все ваши попытки изобрести пример это и доказывают.

Если вам мало, то я умываю руки.

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


BTW, было show и read, стало (show . show) и (read . read). Это, практически, все требуемые изменения. Но примерно то же и в императивном ЯП.

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

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

Их разрабатывает нереальное число людей.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 12:16
Оценка: :)
LP>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
T>>Хороший доступней, плохой невозможней. Переход к лучшему проще.
LP>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.

Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?

Уж больно тон уверенный.

Назови хотя бы парочку.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 12:44
Оценка: +1
Q>>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
T>>Хаскель помогает авторам самих Nemerle и F#.
Q>Это да. Это правильный подход — взять из языка лучшее, оставив синтаксический шлак фанатам.

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

См. Halstead metric:

# The central claim of (*) is that the program's actual Halstead length may be computed using the n1 and n2 parameters (the sum of which Halstead defines as the program's vocabulary), even though the program has not been written yet.
# For example : if a program is written using 20 keywords and uses a total of 30 data objects, its Halstead length equals 233.6, and it has been empirically observed that this estimates compares with the actual length quite closely. This even happens to hold when the program is subdivided into modules (subroutines).


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

Q>>>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.

T>>Ещё один сторонник преждевременной оптимизации.
Q>Это уже не смешно. Ты в любом сообщении готов увидеть преждевременную оптимизацию. Дело в том, что всё это время я абсолютно осознанно следил за тем, чтобы в мои комментарии не просочились аргументы о производительности. Просто задал себе ограничивающее правило: не тыкать в лицо производительностью, не обсуждать кроссплатформеность. Во-первых, как раз для того, чтобы не дать тебе повода придраться. Во-вторых, в данный момент (в пространстве текущих задач) производительность программиста для меня важнее, чем производительность программы. Просто потому что интересны вещи, которые в основном не требовательны к процессорным ресурсам. (С другой стороны, в вопросах памяти я более ограничен, стараюсь избегать утечек.) Плюс нет требования переносимости, и платформу можно выбирать самому. Это очень сильные допущения, далеко не все программисты имеют подобную степень свободы, поэтому не согласятся с моим пренебрежением вопросами производительности.
Q>Но каким-то образом я таки дал повод обвинить себя в преждевременной оптимизации. У тебя должно быть запасён целый вагон заблаговременно распечатанных ярлычков «преждевременный оптимизатор», чтоб обильно навешивать на окружающих.

Энергичность по умолчанию предпочитают из-за производительности. Потому, что ленивость по умолчанию более подходит для записи более модульных программ.

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

То, что ты говоришь о том, что тебе важна производительность программиста, это, ну, преувеличение. В противном случае ты бы мыслил по-другому. Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов.

Где это всё в твоих рассуждениях?

То, что ты не касался вопросов производительности в общении, не мешает тебе подсознательно о ней всё время думать и выдавать себя неосторожными комментариями, совсем чуток забыв о контроле.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 11.02.09 14:37
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>Пока что я прихожу к выводу, что на Nemerle удобнее писать код вообще. В том числе и функциональный, и объектно-ориентированный, и мета.


Я пришел к такому же выводу для Ocaml'а. И есть очень большое подозрение что Хаскель для функциональнальщины еще удобнее.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:47
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Я пришел к такому же выводу для Ocaml'а. И есть очень большое подозрение что Хаскель для функциональнальщины еще удобнее.


Ух-ты!
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 15:36
Оценка: :)
T>>"Необходимость в метапрограммировании означает необходимость в языке более высокого уровня" Фред Брукс, "Мифический человеко-месяц", второе издание.
L>О! Золотые слова! Тут, кстати, уже проскальзывала эта тема.
L>Называется "Являются ли макросы свидетельством недостаточной выр". Да, именно так, выр.

По-моему, макросы являются свидетельством излишней выр.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.02.09 16:08
Оценка: +1
Здравствуйте, thesz, Вы писали:

G>>>>Лучше энергичность по-умолчанию, чем ленивость.

T>>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>>Как ленивость связана с модульностью?

T>Да это же, вроде, известная тема.


T>Например, в переборных алгоритмах я могу просто породить бесконечное дерево вариантов, а потом натравить на него отсекатель. Создатель дерева ничего не знает о его получателе, получатель ничего не знает о создателе — последний может быть результатом какого-то отсечения.


T>После ознакомления с этим вариантом решения он начинает возникать то тут, то там.


Ну для этого ленивость по-умолчанию не нужна. Вполне хватит ленивости на уровне библиотеки.

T>>>http://thesz.livejournal.com/906786.html

G>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

T>И как понять, какой он когда? А не станет ли он энергичным раньше времени?

А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.

T>Примеры в статье очень простые для простоты изложения и рассмотрения.

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

G>>ИМХО для не-списков ленивость поумолчанию не нужна.

T>Это ХО, наверное, поддержано каким-то практическим опытом? Каким же, если не секрет?
Ага, это поддержано опытом неиспользования ленивости не для списков\деревьев\подобных_структур.
Re[44]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 20:44
Оценка: -1
Здравствуйте, thesz, Вы писали:

T>>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.

Q>>И к сорока годам остеопороз с остеохондрозом.

T>Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.


T>ЗЫ

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

http://thesz.livejournal.com/757133.html:

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

Вес-то был небольшой, всего 52,5 кг. Но отказной, аж на цыпочки поднимался.

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

Буду восстанавливаться.

Вот же ж.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 10:22
Оценка: :)
T>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.
FR>А еще штангой мозги пудрил, я уже присматриватся начал какую купить, тем более раньше много ТФТ занимался, думал в изучении хаскеля поможет, но теперь ясно грибы рулят

Без грибов с Хаскелем никак. Точнее, либо без штанги, либо без грибов.

Ну, ещё бегать можно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 12.02.09 11:52
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

Нельзя ли конкретизировать эти конструкции? Хотя бы пару ключевых. И указать роль глобального состояния в нём.
А то получается, что оно вроде как тоже императивное, но из твоего определения совершенно неясно в какой степени к нему применимы рассуждения справедливые для императивного.
Мне вот неочевидно почему в нём обязательно должно быть глобальное состояние.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 13.02.09 10:59
Оценка: -1
Здравствуйте, eao197, Вы писали:

E>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность. В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.


a и b — логические предикаты (или ещё лучше прямые на плоскости), объясни математический смысл выражения a-b
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.09 11:40
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>А на счет изменности функций:

E>>
E>>int sum( int[] a ) {
E>>  int r = 0;
E>>  for( int i = 0; i != a.length; ++i )
E>>    r += a[ i ];
E>>  return r;
E>>}
E>>

E>>Чем эта функция изменна?
S>Не понял вопрос.

По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?

S>Вам непонятно, что r является изменчивым состоянием?


Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.

S>что i является изменчивым состоянием, и даже банальное доказательство того факта, что ни одно из обращений не выходит за пределы границ массива является нетривиальным?


Ok. Имеем чистую функциональную функцию:
int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, index + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}

Или ее аналог в OCaml (навскидку):
let rec sum a =
  let rec sum_impl a index size acc =
    if index = size then acc
    else sum_impl a (index+1) size (acc+a[index])
  in
    sum_impl a 0 a.length 0

Проверка выхода за границы массива стала тривиальнее?

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


Хорошо, что позволит компилятору свести потребление памяти к минимуму вот в такой реализации:
let rec sum a =
  let rec sum_impl a index size =
    if index = (size-1) then a[index]
    else a[index] + (sum_impl a (index+1) size)
  in
    sum_impl a 0 a.length

?

E>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность.

E>>В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
S>Вот этого не понял.

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

E>>Какие побочные эффекты у приведенной выше императивной функции sum?

S>У приведенной выше — никаких.

Здорово -- побочных эффектов нет, зато состояние есть.

S>Поэтому хороший компилятор избавляется от излишней императивности в меру своих возможностей.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 10:56
Оценка: +1
Здравствуйте, FR, Вы писали:

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


LP>>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.


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


Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: Vamp Россия  
Дата: 19.02.09 21:16
Оценка: :)
IT>Ты лямбды с указателями на функции случайно не путаешь?
А как их можно спутать? Под лямбдами я имею в виду бюстовские.
Да здравствует мыло душистое и веревка пушистая.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: Vamp Россия  
Дата: 19.02.09 21:31
Оценка: :)
IT>А как они реализованы в плюсах? В частности как реализован захват контекста?
Я сам, честно говоря, не пользовался. Наверняка замыкания там как-то сделаны, но как?
Вот тут все есть:
http://www.boost.org/doc/libs/1_38_0/doc/html/lambda.html
Да здравствует мыло душистое и веревка пушистая.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 19.02.09 22:35
Оценка: +1
Здравствуйте, Vamp, Вы писали:

V>>>И лямбды есть, тоже давно уже.

V>Вот тут все есть:
V>http://www.boost.org/doc/libs/1_38_0/doc/html/lambda.html

Ты что, шутишь? Бустовские лямбды — это жалкое подобие никчемной пародии на нормальные лямбды.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.01.09 15:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Еще раз. Все что тебе кажется со стороны или спереди высказывай мне в личной переписке.


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

VD>А то может мне кажется что-то не хорошее про тебя. Представляешь как неприятно будет если я это все в форуме вывалю?


Валяй.

E>>Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.


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


То, в чем ты не видишь смысла, является экономией времени читателя.

VD>Ну, так получилось, что об однонаправленном тексте сказано и выше, и ниже. Неужели — это так существенно?


Да. Цени время читателя.

VD>Что до моего времени, то уж извини не тебе о нем судить.


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

E>>Это только то, что сразу бросилось в глаза и запомнилось.


VD>Это все очень похоже на слабо обоснованные наезды. Ты ведь что сказал в своем первом пассаже?

VD>

VD>По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

VD>Что же за наезды ты продемонстрировал? Большая часть цитат вообще не имеет отношения к твоему высказыванию.

Хорошо, пойдет дальше. Про императивных программистов.

ПРЕДУПРЕЖДЕНИЕ

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

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

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

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

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

Из той же оперы.

Теперь по поводу изложения от первого лица.

Например, фразы вида:

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

Она использует Reverse из LINQ. Метод Reverse написан довольно хитро, что делает его весьма эффективным. Но об этом вы узнаете, когда дочитаете до описания этого метода. В принципе, можно было бы реализовать специализированную версию данного метода для IList<T>, но у меня есть большие подозрения, что от этого будет мало толку.

На мой взгляд, это не очень полезный вариант метода Aggregate, так как того же самого эффекта можно добиться последовательным вызовом обычного Aggregate() и Select() (о Select см. ниже). Возможно, такой вариант потребовался для реализации «LINQ to SQL», а возможно, просто кто-то перестарался.

Понятное дело, что «так» императивные программисты не пишут. Не делают они это по двум причинам.

Во-первых, из соображений производительности (хотя в 99% случаев она вряд ли пострадает). Ведь создается промежуточная последовательность (в данном случае динамический массив типа List<string>()), а это не оптимально!

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


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

VD>За наезды видимо были приняты высказывания о том, что мало кто реально освоил ФП (что является стопроцентной правдой).


Откуда такая статистика?

VD>Ну, и как после этого воспринимать такую критику?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.01.09 16:46
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?


VD>Из практики чтения чужого кода. Поверь, не малой практики.


Не поверю.

E>>Откуда информация о том, о чем привык думать императивный программист?


VD>От себя. Я сам так думал 3 года назад.


Тогда следовало бы говорить в статье "я", а не "императивный программист".

VD>>>За наезды видимо были приняты высказывания о том, что мало кто реально освоил ФП (что является стопроцентной правдой).


E>>Откуда такая статистика?


VD>Из твоего списка. Там только одна цитата была по делу. В прочем и она в общем-то не по делу.


Я спрашивал откуда статистика о том, что мало кто реально освоил ФП? Где какие-то наблюдения о том, что, к примеру, 100 человек начали изучение ФП и только у 10 из них это получилось? Ты, вот, например, начал программировать на Nemerle и сейчас считаешь, что достаточно понимаешь ФП. Это было архисложно? У 90% посетителей RSDN, надо полагать, не хватит на это мозгов? Или может пока подавляющему большинству программистов просто не нужно было по работе сталкиваться с ФП и поэтому мало кто из них в нем разбирается -- просто по ненадобности?

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


Что не удивительно, ведь я пытался говорить о том, как написана статья, а ты -- обо мне.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 15.01.09 16:52
Оценка:
Я не совсем по теме хочу высказаться, просто пару слов в поддержку Влада. Имхо eao197 некорректно и некрасиво наезжает. Можно было и полегче выразиться, не теряя сути претензий.

Статья же отличная (несмотря на опечатки и орфошибки). Как раз собирался в понедельник среди коллег семинар по LINQ и ФП провести, теперь же достаточно просто вручить им статью :)
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.09 17:00
Оценка:
О. А мы думали ты к нам подъедешь. Ты где?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.09 17:31
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Из практики чтения чужого кода. Поверь, не малой практики.


E>Не поверю.


Твои проблемы. Я тоже не верю половине твоих слов. Ну, и что?

E>>>Откуда информация о том, о чем привык думать императивный программист?


VD>>От себя. Я сам так думал 3 года назад.


E>Тогда следовало бы говорить в статье "я", а не "императивный программист".


Я уже так не думаю. И задача статьи помочь думать по-другому остальным.

E>Я спрашивал откуда статистика о том, что мало кто реально освоил ФП?


А зачем мне статистика? Мне важно аудитория. Если есть люди которые еще не совсем хорошо освоились с ФП или вообще его не освоили, то аудитория есть и я не зря писал статью.

Судя по оценкам и благодарностям аудитория есть. И этим людям совсем не стыдно, что они еще не являются гуру ФП.

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

E>Где какие-то наблюдения о том, что, к примеру, 100 человек начали изучение ФП и только у 10 из них это получилось?


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

E>Ты, вот, например, начал программировать на Nemerle и сейчас считаешь, что достаточно понимаешь ФП. Это было архисложно? У 90% посетителей RSDN, надо полагать, не хватит на это мозгов? Или может пока подавляющему большинству программистов просто не нужно было по работе сталкиваться с ФП и поэтому мало кто из них в нем разбирается -- просто по ненадобности?


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

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


E>Что не удивительно, ведь я пытался говорить о том, как написана статья, а ты -- обо мне.


Что из тебя льется, о том я и говорю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.09 18:35
Оценка:
Здравствуйте, eao197, Вы писали:

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


По этому поводу тебе отлично ответил Синклер:
http://rsdn.ru/forum/message/3250584.1.aspx
Автор: Sinclair
Дата: 15.01.09


E>>>Я спрашивал откуда статистика о том, что мало кто реально освоил ФП?


VD>>А зачем мне статистика?


E>Затем, чтобы оправдать утверждение о том, что:

E>

E>Однако только немногие решились реально разобраться в нем, и уж совсем немногие действительно разобрались и освоили функциональный подход.


Я кажется не в суде, чтобы что-то там оправдывать.

E>Это твои фантазии, что уж совсем немногим из тех кто решился разобраться в ФП его освоили. Пока я вижу на том же RSDN, что кто не берется за ФП, те его осваивают. Вот ты, к примеру.


Это твои фантазии про мои фантазии .

VD>>Мне важно аудитория.


E>Ну типа "пипл хавает"


Ну, типа людям нравится .

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


E>Я нигде не говорил, что статья плохая. Я перечислил причины, по которым она мне не кажется такой хорошей, как, например, это кажется Qbit86
Автор: Qbit86
Дата: 15.01.09
. И я говорю о том, что в ней можно было бы улучшить.


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

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


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

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

Если уж ты действительно настроен на конструктив, то вместо того чтобы критиковать мой стиль и подходы, возьми и напиши аналогичную статью, но так как видишь ее ты. Может из этого получится что-то полезное и те кто не найдут мою статью полезной прочтут твою и тем самым будут удовлетворены. Или твоего порыва хватает только на критику в мой адрес?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.01.09 09:52
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>По этому поводу тебе отлично ответил Синклер:

VD>>http://rsdn.ru/forum/message/3250584.1.aspx
Автор: Sinclair
Дата: 15.01.09


E>Я не согласен ни с ним, ни с тобой.


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

VD>>Я кажется не в суде, чтобы что-то там оправдывать.


E>Т.е., за свои слова ты ответить не хочешь?


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

VD>>Я как раз не заметил разговора о том, что в ней можно было бы улучшить.


E>Как минимум, выбросить из нее 1/3 налитой в нее "воды". Перестать говорить о гипотетическом "императивном программисте" и, раз уж начал, говорить о себе. Приводить примеры императивного кода не хуже примеров функционального кода.


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

VD>>Ну, кроме найденных двух опечаток.


E>Да, и дать кому-нибудь на корректуру и вычитку.


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

VD>>ОК. Предположим, что ты конструктивен и хочешь помочь. Но объясни мне, что за статья получится если вместо своих мыслей я буду писать что-то, что удовлетворит твоим возрения на мир? Я думаю получится ахинея.


E>Еще раз: статья производит впечатление написанной "в один присест", без повторных вычиток.


Я бы задумался над этим если бы не два небольших факта:
1. Ты единственный кто высказывает эту претензию.
2. Ты докапывашся до всех моих статей, заметок и сообщений в чем явно просматривается личная неприязнь. Короче, не объективен.

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


Месье мозговед?
Расстрою тебя твои телепатические опыты дали осечку. Статью вычитывал сначала я, а потом редактор (Купаев).
Правда получилось так, что я действительно вписал пару строк впопыхах. Их то и заметил McSim здесь
Автор: McSim
Дата: 01.09.08
.

E> Например:

E>

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

E>можно было бы переписать как:
E>

E>Аналога FoldRight нет, но требуется он довольно редко, и его нетрудно написать самостоятельно:


Ну, ты еще пойди Толстого и Пушкина покритикуй. Они тоже порой имели весьма развесистый слог.
Это мой стиль. Как хочу так и пишу.

Если бы мне было не чем заняться, я бы провел эксперимент лингвистического сжатия с вот этой
Автор(ы): Евгений Охотников
Дата: 03.03.2007
Данный материал рассчитан на более-менее опытных программистов, уже использующих другие языки про-граммирования, но желающих понять, что же такого особенного в языке Ruby, а тех, кому вольно или неволь-но приходится изучать Ruby  — в качестве еще одного русскоязычного источника информации о Ruby. Несколь-кими словами данную статью можно охарактеризо-вать как «глубокое погружение в Ruby для тех, кто не прочитал Programming Ruby».
твоей статьей. Там во вводных частях можно большую часть абзацев сжать если не в двое, то по крайней мере на треть.

Так что кончай докапываться до чужой работы. Лучше сделай что-то сам. Хотя тебе ясно слабо. Ведь ты столько времени тратишь на злопыхания в чужой адрес.

E>Абсолютно та же самая мысль, но выраженная меньшим количеством слов, без лишнего выражения собственного отношения к факту отсутствия FoldRight. (Почему-то сокращение текста программы ты считаешь благом, а вот сокращение объема собственного словесного выхлопа -- нет).


А зачем нужно "...без выражения собственного отношения к факту..."? И почему ты пытаешся нагло и беспардонно навязать мне сухой безличностный стиль и в то же время в твоих статях мы видим ровно обратное:

Возможно, столь много времени потребовалось еще из-за того, что Programming Ruby [2] — это очень большая книга, которая посвящает читателя во все тонкости языка, но не расставляет акцентов. Однако при переходе с C++ на Ruby (как в моем случае) не столь важны конкретные особенности синтаксиса языка. Гораздо важнее осознать, как именно должно измениться мышление, чтобы при программировании на Ruby думать именно на Ruby, а не на C++. И, по-моему, мне еще не попадалась книга о Ruby, в которой делался бы акцент именно на этом.


Все те претензии, что ты в демогогичной манере высказваешь тут мне можно применить и к тебе. Зачем нужны размышления о изменении мышления? Зачем нужно было гадать о причинах размера временных затрад? Зачем эти личностные откровения про собственный случай? Можно же было сухо и коротко написать "Особенностью данной статьи является упор на переходе на Руби с С++". Или что-то вроде того. Коротко, по-сути, сухо, безличностно.

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


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

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


E>Нет, мне это не интересно.


То-то и оно. Ну, и кто ты после этого?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.01.09 12:51
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Еще раз: статья производит впечатление написанной "в один присест", без повторных вычиток.


VD>Я бы задумался над этим если бы не два небольших факта:

VD>1. Ты единственный кто высказывает эту претензию.

Так что тебя больше беспокоит: то, что я единственный это тебе сказал, или то, что это правда?

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


Пруфлинк, пожалуйста.

VD>Ну, ты еще пойди Толстого и Пушкина покритикуй. Они тоже порой имели весьма развесистый слог.

VD>Это мой стиль. Как хочу так и пишу.

Пушкин, Толстой, Чистяков. Никакого снобизма и элитарности.

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

VD>Если бы мне было не чем заняться, я бы провел эксперимент лингвистического сжатия с вот этой
Автор(ы): Евгений Охотников
Дата: 03.03.2007
Данный материал рассчитан на более-менее опытных программистов, уже использующих другие языки про-граммирования, но желающих понять, что же такого особенного в языке Ruby, а тех, кому вольно или неволь-но приходится изучать Ruby  — в качестве еще одного русскоязычного источника информации о Ruby. Несколь-кими словами данную статью можно охарактеризо-вать как «глубокое погружение в Ruby для тех, кто не прочитал Programming Ruby».
твоей статьей. Там во вводных частях можно большую часть абзацев сжать если не в двое, то по крайней мере на треть.


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

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


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

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


E>>Нет, мне это не интересно.


VD>То-то и оно. Ну, и кто ты после этого?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.01.09 16:30
Оценка:
Здравствуйте, eao197, Вы писали:

Знаешь ты надоел. Будут новые и интересные мысли пиши. А там нечего сотрясать пикселы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.01.09 07:47
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Кажись eao197 подумал, что я тоже пытаюсь покритиковать Влада и наставил мне плюсов. Аж 21.


Пруфлинк по поводу плюсов в студию. 21 -- это оценка "Интересно", но не "Согласен".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: "LINQ как шаг к ФП". Стиль изложения.
От: yumi  
Дата: 19.01.09 08:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>Еще:

"Я понимаю, что это очень непривычно и непонятно (на первый взгляд), но поверьте, что есть целая теория обосновывающая это (теория «лямбда-исчислений» Чёрча)."

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


Читатель может и не верить, но может и должен независимо верифицировать, данную информацию.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 11:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Откуда информация о том, о чем привык думать императивный программист?


S>Вообще-то — из определения "императивного программиста".


C++ программист использующий std::transform, std::accumulate etc является императивным?
now playing: Redshape — Blood Into Dust
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 11:43
Оценка:
Здравствуйте, Sinix, Вы писали:

S>In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.


Кто-нибудь может объяснить почему здесь противопоставление?
И чем они type-safe'нее C/C++'ных указателей на функции?
now playing: Redshape — Slow Monday
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.09 11:53
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>C++ программист использующий std::transform, std::accumulate etc является императивным?

Смотря как он их использует
Вообще, скорее всего — да.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 11:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

EC>>C++ программист использующий std::transform, std::accumulate etc является императивным?

S>Смотря как он их использует
Ну, очевидно, он передаёт им исключительно чистые функции
S>Вообще, скорее всего — да.
now playing: Redshape — Battery
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.09 12:26
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Ну, очевидно, он передаёт им исключительно чистые функции
Ну, тогда это шаг из плена императивных иллюзий.

В принципе, комбинирование ИП и ДП — достаточно нормальная штука. Точно так же, как совмещение автоматического вывода с аннотацией типов.
Чрезмерная "гибкость", имхо, может быть даже вредна. А так — вон, программисты БД-приложений уже много лет включают декларативный SQL в свои чисто императивные программы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.01.09 12:26
Оценка:
Здравствуйте, Sinix, Вы писали:

S>>>Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел.

VD>>С какой целью? Чтобы было проще искать? Или чтобы ссылаться можно было?

S>Не угадал . Хорошо структурированную статью легче читать. Мозг автоматом учитывает переключение контекста.


ОК, попробую.

S>>>Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях.

VD>>На то есть оглавление. Да и статья не такая большая чтобы ее резать.
VD>>Или речь об переупорядочивании разделов?

S>Да, смысл именно в том, чтобы структура отражала твой замысел и служила костяком. Типа так: Мы плавно подходим к теме А, но говорить о ней можно только после раскрытия тем Б,В, ну и чуть-чуть Г. Если вы в них сечёте — переходите дальше. Если нет — то можете кончно пролистать, но в любом случае вы ничего не поймёте. И по-хорошему идите учите матчасть.


Разбивать статью никто не будет. Она уже опубликована. Переупорядочить конечно можно. Но вопрос что, зачем и ради чего переупорядочивть?

S>Чтобы не было иллюзий. Оглавление, которое не висит постоянно перед глазами, не очень-то и помогает. Для меня быстрее прокрутить вниз, по ходу быстро сканируя текст, чем искать оглавление, искать в нём раздел и переходить туда. Для небольших статей, естественно.


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

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


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


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

Кстати, вопрос производительности — это еще разговор об оптимизациях. LINQ to objects без проблем может быть оптимизирован буквально до циклов. Это не так сложно. Но и это сложная и большая тема по которой народ защищает дисеры.

S>Но когда стал вопрорс "как делать будем" прокрутили микротесты и выяснилось что по накладным расходам делегаты и итераторы сопоставимы со стоимостью виртуального вызова.


Микро-тесты никогда ничего не показывали. Тут надо рассуждать о двух вопросах.
1. Стоимость абстракции (лямбды и замыкания не бесплатны).
2. Критичность кода к скорости выполнения (далеко не весь код критичен, но выявить и заменить критичный код не просто).

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

S>1. Так бы и сказали

S>2. Конкретик хотите? Их есть у меня!

S>Про анонимные делегаты (кстати, мс и так и так их называет и в принципе раскрывает суть — создаётся делегат на метод; другого доступа к методу нет. Так что вполне нормальный термин):


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

S>

S>Зачем их было называть методами, и почему им сделали столь неуклюжий синтаксис, остается загадкой.
S>...
S>Откровенно говоря, лямбда-выражения – это просто доведенные до ума анонимные методы.
S>...
S>очень часто можно было услышать, как анонимные методы называют «анонимными делегатами», хотя это в корне неверно

S>Вы уж придирайтесь предметно — то вам непонятно, почему называть методами, то называть делегатами в корне неверно.

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

S>Почему без шапки?!!


Что? Что значит "шапка"?

S>Следующая цитата — вообще наезд на эмоциях:

S>

S>При этом в Microsoft не придумали ровным счетом ничего нового. Примерно так выглядят лямбды почти во всех ФЯ. Так что совершенно непонятно, зачем было лепить в C# 2.0 этот безобразный, длинный и сбивающий с толку синтаксис. Понятно, что вывод типов был сделан только в C# 3.0, но, по крайней мере, все остальное-то точно можно было бы сделать сразу как в лямбда-выражениях!


Это называется критика. Многим, кто уже понимает что-то в ФП как раз такие вещи в статье и интересны.

S>После

S>

S>Однако при проектировании .NET-делегатов был сделан ряд ошибок, которые сказались при развитии C# в сторону ФП.
S>...
S>Данное решение не создает особых проблем на практике, за исключением того, что вызов делегата медленнее, чем мог бы быть.

S>возникает желание предложить почитать Абрамса. Допустим, пост от февраля 2004 года. У Абрамса сотоварищи есть много статей, где описывается дизайн рантайма/BCL/шарпа. Перед дальнейшими наездами рекомендую ознакомиться. О производительности:
S>

S>For those performance oriented among you, please note that if you have a MulticastDelegate that hasn’t been combined with any other delegates the CLR can optimizes for this case during dispatch and in how the JIT compiles the callsite….


Ты сам-то внимательно прочем то, что написано в приведенной статье? Если отбросить громкие заявления о высокой производительности и поглядеть описание процесса вызова, то становится отчетливо видно, что вызов дико не оптимален. Перед ним делается масса проверок которые снижают производительность. Решение без ошибок дизайна привело бы к одному виртуальному вызову который в общем-то и виртуальным можно назвать с натяжкой, так как конкретные реализации могли бы быть sealed. В итоге во многих случаях JIT мог бы после устранения виртуальности устранять и сам вызов встраивая его по месту.

S>Продолжаем.


S>

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

S>Мнение Джефри Рихтера вас устроит?
S>

S>In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.

S>Делегаты проектировались как типизированая реализация callback-ов.

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


Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.

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


S>Дальше.

S>

S>Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.

S>Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше.
S>Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...

Раз нашлись двое людей которые не только не восприняли основной посыл написанного (что императивный программист использует цикл перемешивая логику), но еще и нашли обидные для себя моменты, то видимо прийдется действительно изменить этот кусок статьи. Хотя, лично для меня, подобные претензии выглядят как паранойя.

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

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

S>Причём к остальной части статьи, где описывается собсно linq глазами ФП я придраться могу только совсем по мелочам. Оставили бы только её — вообщзе конфетка была бы. Продолжайте


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

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

VD>>Другими словами я пытался на пальцах, простыми словами показать людям которые еще не плавают в ФП как рыбы те приемы и подходы которые предлагает ФП.

S>Ну на самом деле внутри себя оно довольно-таки императивное.


Ты не верно понимаешь понятие "идеологию лежащую за". Я не говорю о реализации методов. Я говорю о идеологии.
Конечно можно было бы уподобиться многим авторам и толкнуть теорию ламбда-исчислений. Но это с вероятностью 100% не было бы воспринято целевой аудиторией.

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


Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.

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

S> И если честно, мне не совсем нравится попытка использования SQL-синтаксиса. Потому что SQL — декларативный язык. Там вольности частично компенсирует оптимизатор. В случае Linq2Objects — что напишешь, то и получишь. И если ты сам сделал жойн коллекциям из тысячи элементов и добавил туда гроуп да ещё и сортировку — сам себе грабли. Аккуратней надо. Особенно в рабочих проектах.


Ну, и что мне теперь в стать рассказать, что есть вот на свете Иванов, Петров и Сидров которые не согласны с подходом МС? Я сказал, что думаю по этому поводу в статье.

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


S>Поддерживаю. Дерзай дальше


S>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.


Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.09 12:43
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Кто-нибудь может объяснить почему здесь противопоставление?
EC>И чем они type-safe'нее C/C++'ных указателей на функции?
Тем, что тебе не удастся закастить произвольный интегер к указателю на функцию и попробовать его выполнить, на радость злоумышленникам.
Type-safety в .NET контролируется строго.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 12:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.

Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.
S>Точно так же, как совмещение автоматического вывода с аннотацией типов.
S>Чрезмерная "гибкость", имхо, может быть даже вредна.
Гибкость в чём?
S>А так — вон, программисты БД-приложений уже много лет включают декларативный SQL в свои чисто императивные программы.
Программист БД-приложений — сушество не менее загадочное, чем иперативный программист .
now playing: Gui Boratto & Anderson Noise — Triads (Andre Sobota Remix)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 12:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

EC>>Кто-нибудь может объяснить почему здесь противопоставление?

EC>>И чем они type-safe'нее C/C++'ных указателей на функции?
S>Тем, что тебе не удастся закастить произвольный интегер к указателю на функцию и попробовать его выполнить, на радость злоумышленникам.
Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит.
S>Type-safety в .NET контролируется строго.
В C++ можно при желании закастить что угодно к чему угодно.
Поэтому мне странно слышать когда указатели на функции и делегаты выделяют отдельно.
Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.
now playing: Gui Boratto & Anderson Noise — Triads (Andre Sobota Remix)
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Klapaucius  
Дата: 19.01.09 13:05
Оценка:
Здравствуйте, EvilChild, Вы писали:

S>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.

EC>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.

Т.е. вот это:
module Main (main) where

-- Pink Floyd - Goodbye Cruel World

main :: IO()

main = do 
    putStrLn "Goodbye, cruel world," 
    putStrLn "I'm leaving you today."
    putStrLn "Goodbye, goodbye, goodbye."
    putStrLn "Goodbye all you people,"
    putStrLn "There's nothing you can say,"
    putStrLn "To make me change my mind."
    putStrLn "Goodbye."

по-вашему не императивная программа?
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 13:15
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Т.е. вот это:

K>
K>module Main (main) where

K>-- Pink Floyd - Goodbye Cruel World

K>main :: IO()

K>main = do 
K>    putStrLn "Goodbye, cruel world," 
K>    putStrLn "I'm leaving you today."
K>    putStrLn "Goodbye, goodbye, goodbye."
K>    putStrLn "Goodbye all you people,"
K>    putStrLn "There's nothing you can say,"
K>    putStrLn "To make me change my mind."
K>    putStrLn "Goodbye."
K>

K>по-вашему не императивная программа?
А что, здесь где-то ссылочная прозрачность нарушается или есть какие-то вещи противоречащие чистому ФП?
SELECT * FROM mytable это тоже императивщина?
now playing: Radio Slave — Ego Trippin'
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.09 13:17
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Гибкость в чём?
Гибкость в выборе императивного алгоритма исполнения декларативно сформулированной программы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.09 13:17
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит.
Да ладно!
Из-за отсутствия стандарта бинарной совместимости, компоненты вынуждены общаться между собой при помощи даункастов. Стандартнейшая штука "выполнить данный метод в GUI-потоке" обрабатывается через передачу адреса в виде целых полей плоской структуры оконного сообшения Windows.
Все карты сообщений построены на даункастах. Добро пожаловать в реальный мир, за пределами hello world.

S>>Type-safety в .NET контролируется строго.

EC>В C++ можно при желании закастить что угодно к чему угодно.
EC>Поэтому мне странно слышать когда указатели на функции и делегаты выделяют отдельно.
И очень зря. Потому, что не так страшно реинтерпретировать строку во флоат, как начать исполнение неизвестного мусора под привилегиями текущего пользователя.

EC>Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.

Акцентируют, и еще как. Type-safety в дотнете вообще рассматривается с позиции именно строготипизированности любых ссылок. Просто конкретный пример обсуждал именно pointer to method.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 19.01.09 13:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

EC>>Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит.

S>Да ладно!
S>Из-за отсутствия стандарта бинарной совместимости, компоненты вынуждены общаться между собой при помощи даункастов.
S>Стандартнейшая штука "выполнить данный метод в GUI-потоке" обрабатывается через передачу адреса в виде целых полей плоской структуры оконного сообшения Windows.
Вышеописанное и есть действие в обход системы типов.
Только я не понимаю почему ты это называешь даункастом. Где там иерархия наследования?

EC>>Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.

S>Акцентируют, и еще как. Type-safety в дотнете вообще рассматривается с позиции именно строготипизированности любых ссылок. Просто конкретный пример обсуждал именно pointer to method.
В контексте безопасности с этим трудно не согласиться, но с позиций системы типов делегаты не более типизированны, чем всё остальное.
Но замечение хорошее — теперь вопросов больше нет.
now playing: Radio Slave — Rj
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 20.01.09 01:33
Оценка:
Здравствуйте, eao197, Вы писали:

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


S>>Кажись eao197 подумал, что я тоже пытаюсь покритиковать Влада и наставил мне плюсов. Аж 21.


E>Пруфлинк по поводу плюсов в студию. 21 -- это оценка "Интересно", но не "Согласен".


Ёпть, что тут за крышесносящая система рейтингов. Проще надо, ближе к народу Ушёл в аут... заочно приношу извинения eao. Ну думал, что моно собирать по плюсику с ответа, а можно одним махом — аж 21. Карма треснет.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 20.01.09 05:27
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m).


Это не так. Если условие будет в where, то да, получим O(n*m) и определённые тормоза. А если использовать join, то работает на порядок быстрее. Подробностей не знаю, выводы сделаны исключительно основываясь на практике применения linq с большими объёмами данных. Впрочем, можно предположить, что для where никуда не денешься, приходится сравнивать каждую запись с каждой, а в случае join строиться словарь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: swimmers  
Дата: 20.01.09 07:14
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.


Рефлектором я смотрел давненько, но тем не менее в пямяти у меня осталось обратное, вроде ExpressionTree там таки переписывается.
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.01.09 14:41
Оценка:
Здравствуйте, thesz, Вы писали:

E>>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.


T>Вот выделенное шрифтом — это VladD2 написал? Да?


Да.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: yumi  
Дата: 21.01.09 01:01
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.


Ну для меня лично, для объектов в памяти, это не критично. А вот в Linq2SQL как раз, где критично, за дело берется оптимизатор.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 21.01.09 01:28
Оценка:
Мона я сразу скопом всем отвечу?

Абсолютно согласен с самой идеей Linq, мне очень нравится, как там работает всё вместе — делегаты, итераторы и ExpressionTrees. То что linq работает как dsl для запросов к различным провайдерам — это вообще одна из главных киллфич. Та же идея насчёт индексов давно витала в воздухе, стоило упомянуть — Sinclair привёл ссылку. Спасибо, не знал, что есть реализации.

По ходу у нас обычная путаница в терминологии. Если под linq понимать только сам dsl/представление в expression trees — то он декларативен, тут спорить не о чем.

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

IT, я микротестами совсем давно занимался, де-то в сентябре 2007-го. И тогда у меня жойн и where работали примерно одинаково. Linq к большим массивам — заинтересовался после какой-то маркетинговой статьи про революционную мощь декларативного мегаязыка и ничего не стоящие запросы из коробки. Может поменяли чего?

-------
Чуть офтопа (спрашиваю больше из интереса, до парсинга expression trees ешё не дошёл):
Может кто подскажет, как определяется тип ExpressionNode? только по имени extension-метода? Потому как у того же Linq2Entities или у Linq2DataSet свои extension methods. Или это дело QueryProvider'a — ему скармливается структура запроса с полными именами методов, а тот уже рзбирается что/где/куда?

Просто чую я скрытую попу с возможным перекрытием этих самых ExtensionMethods...
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 21.01.09 02:50
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>


Ага, спасибо. Не знал.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 21.01.09 09:35
Оценка:
Гм... может у нас просто взаимонедоперенепонимание?

Я никаким обраом не собираюсь агитировать против или за LINQ. Просто сказал, что надо быть аккуратнее и привёл примеры, когда надо понимать что ты пишешь, ибо декларативное описание может тебя обмануть. С одним даже почти угадал — жойн работает быстрее чем предикат в where. Вот и всё.

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

S>Вообще-то, имхо, имеет смысл только первое. Потому, что если смотреть совсем уж педантично, то мы в любом случае собираемся исполнять программу на совершенно определенной архитектуре, которая 100% императивна в худшем смысле этого слова.


Да. Тут наверно всё дело в том, что у меня по дефолту под Linq понимается именно linq2Objects с реализацией через итераторы и т.п.

S>Вся декларативность — в том, что конкретный способ исполнения выбирает именно фреймворк, а не программист.

Угу. именно.

S>Далее, не вполне понятно, что такое "чудовищно страшный мегагитлеримперативный код". Вот, к примеру, как ты думаешь, что мы увидим, вскрыв дебаггером MS SQL Server во время работы? Скорее всего, в окрестностях EIP там будет такой код, по сравнению с которым исходники Link2objects покажутся детской песенкой.

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

Угу-угу. Имелось в виду то, что в тру декларативном описании ты не определяешь алгоритм, а только описываешь граничные условия. Проблема только в том, что не всегда очевидно — ты описываешь запрос или пишеь как он будет выполняться. Ну дык внимательно надо.

S>Так что это нормальная для декларативных языков практика. Более того, я приветствую наличие "суперстрашного" кода в конвеере исполнения — в том смысле, что как правило его устрашнения связаны с оптимизацией. К примеру, в исходных кодах goto и copy/paste — однозначное зло. А во время исполнения это здорово — они превращаются в shortcut evaluation и inlining.


Аналогично.

ЗЫ. Может уже закончим переуточнять? По-моему, тема исчерпана.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 11:11
Оценка:
S>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.
EC>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.

А если на Agda2 или Coq? Не пойдёт?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 11:17
Оценка:
K>Нет. Мне кажется, вы путааете возможность программировать декларативно и невозможность программировать императивно.

Lambda: the Ultimate Imperative, в конце концов! (правда, исходная статья по ссылке второго рода не доступна, но это, может быть, только мой глюк)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 11:39
Оценка:
Здравствуйте, thesz, Вы писали:

S>>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.

EC>>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.

T>А если на Agda2 или Coq? Не пойдёт?

А на них разве пишут "обычные" программы?
now playing: Redshape — Slow Monday
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 13:02
Оценка:
S>>>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.
EC>>>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.
T>>А если на Agda2 или Coq? Не пойдёт?
EC>А на них разве пишут "обычные" программы?

define "обычные". Why should I ask in first place?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 14:02
Оценка:
Здравствуйте, thesz, Вы писали:

EC>>А на них разве пишут "обычные" программы?

T>define "обычные". Why should I ask in first place?
Для более-менее конечного пользователя, а не для computer scienetist'ов.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 16:10
Оценка:
Здравствуйте, thesz, Вы писали:

EC>>>>А на них разве пишут "обычные" программы?

T>>>define "обычные". Why should I ask in first place?
EC>>Для более-менее конечного пользователя, а не для computer scienetist'ов.

T>CompCert подойдёт?

Вполне.
Этот компилятор используется для решения практических задач или это чисто исследовательский проект?
now playing: Gui Boratto & Anderson Noise — Triads
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 17:57
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Офтоп про декларативыность linq:


S>Как вы воспринимаете декларативность?


Как определение того "что делать", а не того "как делать".

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


Интерфейсы и есть интерфейсы. Их нужно реализовывать. И тут в Яве есть только один путь. Императивно описать что нужно сделать при вызове каждого метода интерфейса.

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.


Это и есть мышление императивного программиста. Мыслим не о том, "что делается", а о том "как". Меж тем реализация может быть весьма разно. Вот ты предположил, что Join сделать тупым перебором. Меж тем это не так. Он реализован на лукап-таблицах которые в свою очередь реализованы на хэш-таблицах. Таким образом скоростные характеристики Join близки к линейным. К тому же Join требуется только при обработке реляционных данных коих не много в программах.

S>Без похожего функционала Linq2Objects годится только для примитивных запросов, или ситуаций, где оптимизировать исходные структуры нельзя. То, что к таким ситуациям относится большинство типичных сценариев, ещё не говорит о революционном LINQ — убийце императивщиков


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

S>Сам по себе LINQ не тру декларативен. Декларативность подразумевает произвольную реализацию алгоритма в зависимости от ситуации.


Декларативность вообще не подразумевает реализации. Декларативность — это способ описания потребностей без описания реализации. Вот это LINQ обеспечивает, так что он вполне себе декларативный.

В прочем размышления о произвольной реализации так же не верны. Скажем LINQ to SQL преобразует код полностью аналогичный тому что можно написать на LINQ to object в SQL, а LINQ to DataSet во вполне эффективные операции над DataSet-ами (так как в них поддерживаются индексы). При этом нет каких-то разных LINQ-ов. LINQ один. Вместо этого есть разные реализации так называемого LINQ Pattern, что как раз и является реализацией алгоритма в зависимости от ситуации. Ведь то какая библиотека используется определяется исключительно обрабатываемыми данными.

С некоторой натяжкой можно обозвать декларативным сам язык — эдакий DSL вокруг набора методов. Вы ж не будете обзывать декларативным это:
S>
S>new StringBuilder.Append("A").Append("B");
S>

S>А вот это — декларативный код?
S>
S>new int[] {1,2,3}.Where(i=>i>2).Select(i=>"#" + i.ToString());
S>

S>А вот это — уже похоже, да?
S>
S>from i in new int[] {1,2,3} where i>2 select "#" + i.ToString());
S>


S>Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.


ДСЛ-ем является уже сам LINQ Pattern. Синтаксис действительно всего лишь простая трансформация.

S>В принципе, о декларативных запросах к графам — неважно, объектным, XML, иерархическим БД — писал ещё Дейт начиная с 8 издания. Точной цитаты не приведу — книги на руках нет, быстрый поиск не помог, но суть там была такая, что из-за захардкоденной структуры возможность произвольного доступа невелика, различных путей выполнения не так уж и много, а использование этих путей в запросах в принципе лишает смысла использование оптимизатора. Посему те же XQuery/XSLT так и пребудут императивными во веки веков до скончания оных


Ты просто не понимаешь термин "императивный".

VD>>Нет в природе никаких анонимных делегатов. Если кто-то так называет анонимные методы, то он просто ошибается.


S>Может ты скушал не ту пилюлю, нео?


S>Не всё так просто. Если посмотреть что происходит в реальности:...


Есть терминология определяемая стандартом. Не надо ее пытаться корежить и выдумывать что-то свое.
Кстати, в МС обсуждалась идея ввести в дотнет именно анонимные делегаты. Под этим понималось то, что в ФЯ называется функциональным типом. Логика была проста. Функциональный тип — это делегат без имени, т.е. анонимный делегат.
И как мы дальше будем разговаривать если каждый будет понимать свое под конкретным термином?
Так что забудь "анонимный делегат". То о чем ты говоришь в дотнете называется анонимным методом.

S>Если замыканий нет — компилятор создаёт приватный метод и приватную переменную — делегат, которую инициализирует при первом выполнении метода. Так что в каком-то смысле анонимный делегат существует.


"Приватный" (скрытый) не тоже самое что "анонимный" (безымянный). Плюс переменная — это всего лишь ссылка. Есть она или нет рояли не играет.

S>Читаем http://blogs.msdn.com/zifengh/archive/2008/01/21/from-c-to-clr-jitted-code-call-delegate.aspx. Не запутайтесь — там подряд идёт создание и вызов делегата. JIT работает так, как вы и хотели. Если можем предложить более оптимальный вариант — предлагаем. Нет — не холиварим или учим матчасть.


Улавливаешь разницу между понятиями "более оптимальный" и "оптимальный"?

В МС к настоящему моменту сделали не мало, чтобы разгнать делегаты. Но если бы они не валяли дурака в 1998-ом, то решение было бы простым, чистым и эффективным.

VD>>Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.


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


Уважаемый. За то что идет перед ... тут банят и на долго.

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

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


S>Придётся править. Реально вопринимается как наезд. Или предвзятость. Ибо "90% императивных программистов" пишет код аккуратней. Да! Я себя к императивщикам не отношу. Вообще ни к кому не отношу. Не люблю таскаться


Причем тут аккуратность?

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


S>Свою точку зрения разжёвал выше. Почему "вопрос "как" перекладывается на реализацию библиотеки" — особенность ФП? Это принципиально невозможно в императивных языках?


Какой еще библиотеки?

VD>>Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.


S>Я ж говорю — несовпадение мировоззрений. Не будем.


Именно.


S>>>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.


VD>>Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.


S>Ну, если для вас маркетинг-отдел Сана достоверней Рихтера... Не могу найти точной цитаты, но делегаты как каллбэки в рантайме были заложены ещё до событий и собсно фреймворка — ещё когда было только "common object runtime". Отсюда и делегат/мультикаст делегат. Одно для калбэков, другое для событий. Потом пришло осознание, что в принципе сценарии пересекаются и вполне себе оптимизируются в рантайме. Но было уже поздно(с). Принципиально нет ограничений для кастинга делегатов по сигнатуре. Оно просто не реализовано. Если у вас есть идеи, какими должны быть делегаты — озвучьте


Я читал тоже самое в письме Хейльсберга и в других местах. К сожалению не думал, что мне понадобятся ссылки на все источники. Рихтер же писал постфактум о дотнте. А делегаты действительно были предложены в J++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:30
Оценка:
Здравствуйте, Sinix, Вы писали:

K>>Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>


S>Ага, спасибо. Не знал.


Ну, и что ты теперь скажешь о императивной природе?

ЗЫ

Верным будет только утверждать, что реализация LINQ to object не самая эффективная и может быть сделана более эффективной если на то появится необходимость. Вот только появится она вряд ли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:35
Оценка:
Здравствуйте, thesz, Вы писали:

E>>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?

VD>>Из практики чтения чужого кода. Поверь, не малой практики.

T>Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.


Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный.

T>Всё нормально у императивщиков при переходе на ФЯ.


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

VD>>Скажу больше. Я сам бы очень хотел бы наткнуться на подобную статью году эдак в 2005-ом или 2006. А лучше еще раньше. Вместо этого я нарывался на трехколенные выпендрежи, понты и замуности которые мало что давали с точки зрения понимания принципов ФП. По сути только попытка разобраться с Немерле позволила мне понять принципы ФП. И, о чудо, все оказалось совсем просто. Оказывается проблемы были не в моем скудном уме, а в неумении других объяснять весьма простые вещи. Вот эта статья и есть попытка объяснить эти простые вещи для таких же простых парней как я.


T>Перевод этой сентенции на русский язык настолько ярок, "it can blind you by pure awesomness".


T>Если я его опубликую, то меня забанят, да.


T>Этот параграф очень, очень показателен.


Ничего не понял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 22.01.09 00:58
Оценка:
Здравствуйте, yumi, Вы писали:

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


Личная неприязнь одного человека не провоцирует все срачи, особенно те, в которых он даже не участвует. А если ты хочешь объяснить это личной неприязнью целой массы участников, то она уже неспроста
Ну и давай не будем обсуждать частности и оффтопить. Возможно, данный пример был не совсем удачен, но всё же разговор об императивности и непанацейности ФП завязался именно с его приходом.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 22.01.09 02:48
Оценка:
Да шо ж ко мне вы так пристали, Sinclair? Я ж не это ж, чтоб вот так вот, как оно есть, а оно совсем не так, да!

Чтобы не наводнять форум постами с километром оверквотинга:

Я не говорил и не собирался говорить, и совсем даже не имел в виду и не намекал и не подмигивал даже на тему "linq как таковой — декларативный отстой".

Все комменты относились к конкретным сценариям с linq2objects, когда товарищ может сам себе отстрелить ногу из-за того, что не понимает каким образом будут исполняться запросы, но их алгоритм выполнения определяется именно тем, что и как он написал. Другими словами: планы выполнения теоретически идентичных запросов для Linq2objects будет существенно отличаться. Последнее слегка неожиданно, если воспринимать linq как полноценную чёрную магию из коробки. Для товарищей, которые уже наигрались с предыдущим шарпом это не страшно. Для новичков это может привести к жестоким обломам и разочарованию в декларативном программировании вообще. Во! Наконец понял, что хотел сказать

Если коротко, то linq слегка нарушает тот самый принцип наименьшей неожиданности, о котором пафосно рассказывал Баллмер, после прыжков по сцене и "Developers, developers, developers!".
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 22.01.09 03:07
Оценка:
Влад! У нас не получается нормального разговора. Вы как-то неадекватно воспринимаете любые мои слова. Я всего лишь запостил комменты на вашу статью. Не ради того, чтобы как-то наехать на вас. Я написал, что конкретно мне в конкретной статье не понравилось. Процесс выяснения того, _почему_ мне что-то не понравилось перешёл в пустую свару. Давайте так. Я извиняюсь за намеренные и ненамеренные наезды в сторону Влада и остальных товарищей и прекращаю портить праздник в отдельно взятой ветке.

Щастья вам всем

ЗЫ Я никуда не ушёл. Просто молчу. Пока
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 07:52
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Влад! У нас не получается нормального разговора. Вы как-то неадекватно воспринимаете любые мои слова.


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

S>Процесс выяснения того, _почему_ мне что-то не понравилось перешёл в пустую свару. Давайте так. Я извиняюсь за намеренные и ненамеренные наезды в сторону Влада и остальных товарищей и прекращаю портить праздник в отдельно взятой ветке.


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

S>Щастья вам всем


Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 08:08
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


В "мастер-классе ФП" я высказал две мысли:
1. Что утверждение:

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

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

2. Примеры в этом "мастер-классе ФП" слишком примитивные.

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

В прочем, в некоторых случаях может быть так и происходит. Вот только не думаю, что в этом только моя вина. Крайности как раз присущи приверженцам одной "true мысли".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 08:15
Оценка:
Здравствуйте, VoidEx, Вы писали:

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

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

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

Что до массы участников, то она несомненно есть. Вот только она весьма мала. Возьмем скажем minorlogic (или как там его) который бегает и расставляет минусы на большую часть моих сообщений. Или того же eao197 который не может пройти мимо любого моего сообщения, чтобы не покритиковать меня и сообщение, а не мысль в нем высказанную.
Тут ничего не поделаешь. Есть люди с разными взглядами и с разной степенью неприятия чужих мыслей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 09:51
Оценка:
E>>>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?
VD>>>Из практики чтения чужого кода. Поверь, не малой практики.
T>>Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.
VD>Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный.

Программисты-то были — императивные! Хаскеля в глаза не видели.

T>>Всё нормально у императивщиков при переходе на ФЯ.

VD>У кого как. Но я еще не видел людей которым не пришлось бы перестраивать сознание и которые бы без изучения идей ФЯ сами бы писали функциональный код.

Вся перестройка сознания — это прекратить считать список односвязным, и начать думать, что список индуктивно определённый.

То же самое — про остальные структуры данных.

Это что касается перестройки мышления программиста-программиста.

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

VD>>>Скажу больше. Я сам бы очень хотел бы наткнуться на подобную статью году эдак в 2005-ом или 2006. А лучше еще раньше. Вместо этого я нарывался на трехколенные выпендрежи, понты и замуности которые мало что давали с точки зрения понимания принципов ФП. По сути только попытка разобраться с Немерле позволила мне понять принципы ФП. И, о чудо, все оказалось совсем просто. Оказывается проблемы были не в моем скудном уме, а в неумении других объяснять весьма простые вещи. Вот эта статья и есть попытка объяснить эти простые вещи для таких же простых парней как я.

T>>Перевод этой сентенции на русский язык настолько ярок, "it can blind you by pure awesomness".
T>>Если я его опубликую, то меня забанят, да.
T>>Этот параграф очень, очень показателен.
VD>Ничего не понял.

*рвёт на груди тельняшку*

Параграф этот переводится так: "я тупил и ничего не желал делать, считая, что мне должны всё преподнести так, чтобы я понял. Успехи других я считал выпендрёжем и понтами, а их объяснения — замутностью. А потом я взялся и попытался разобраться на интересной задаче самостоятельно и всё получилось!"

Вот.

Не надо считать свою лень недостатком других.

*срывает с мощного торса остатки тельняшки и принимается за брюки-клёш*
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.09 10:07
Оценка:
Здравствуйте, eao197, Вы писали:

E>

E>Это сильно упростит восприятие функционального кода на начальном этапе. Данное мысленное преобразование требуется потому, что императивный программист за долгие годы привык думать низкоуровневыми понятиями (паттернами кодирования) циклов и простейших операций. ФП же предлагает думать бее крупными операциями, такими как отображение, фильтрация и свертка/агрегация.

E>Откуда информация о том, о чем привык думать императивный программист?

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

На определенном уровне человек оперирует ч.з. "отображение, фильтрация и свертка/агрегация", вот тут ему можно и дать ФП. Вернее, он или сам его возьмет или изобретёт велосипед.

Как сократить время формирования вот такого мышления — неясно.

Эмпирическая оценка — 10 лет.

http://www.williamspublishing.com/21-days.html
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 10:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В "мастер-классе ФП" я высказал две мысли:

VD>1. Что утверждение:
VD>

VD>я часто сталкиваюсь с двумя точками зрения — первая "я знаком с ФП, но оно никакой выгоды в программировании не даёт", и вторая "я знаком с ФП, но так и не научился использовать его для повышения эффективности программирования".

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

Совершенно верно. Но это мнения людей, которые реально не разобрались в предмете.

VD>2. Примеры в этом "мастер-классе ФП" слишком примитивные.


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

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

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

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

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

В этом треде и так много перехода на личности, не хочу это обсуждать

P.S. Насчёт выразительности/гипертрофированности в обучающих примерах и их непрактичности (т.е. несоответствия реальным ситуациям) очень хорошо сказал А.И.Нимцович в "Моей системе". Это не к тебе, просто очень нравятся слова, а тут такой шанс их запостить

Приведенная жертва пешки (желающей в наступлении погибнуть) весьма типична, но при этом, конечно, необязательно, чтобы оживали сразу три фигуры. Нередко удается ввести таким образом в игру только одну фигуру, но и этого достаточно. Почему же мы приводим три фигуры? Да с тем же правом примерно, что и Ибсен, который в заключительной сцене своих "Привидений" сгущает медленное развитие болезнен-ного процесса в один драматический эпизод. И, подобно тому как критика ожесточенно нападала на бедного Ибсена за то, что он исказил картину болезни (!!), так же, вероятно, шахматные критики будут обвинять и нас в тяжком преувеличении.

Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: Andrei F.  
Дата: 22.01.09 13:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Выделеное означает, что сам VladD2 считает что ФП сложен и боится сам себе в этом признаться


ФП не сложен. Просто писатели книг по ФП слишком любят канцелярски-формальный язык, за что ФП и не любят
На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 22.01.09 13:42
Оценка:
Здравствуйте, VladD2, Вы писали:

T>>Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.


VD>Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный.


Как здесь недавно совершенно верно заметили на чистом ФЯ вполне можно программировать императивно.
now playing: Maximilian Skiba — Randez-Vous (Jens Zimmermann Remix)
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.09 14:52
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>ФП не сложен. Просто писатели книг по ФП слишком любят канцелярски-формальный язык, за что ФП и не любят

AF>На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем

Для кого не сложен, для новичка или топа ?
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 15:16
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


T>>>Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.


VD>>Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный.


EC>Как здесь недавно совершенно верно заметили на чистом ФЯ вполне можно программировать императивно.


Более того, на чистом ФЯ нужно программировать императивно (нужно == приходится). Вопрос — нахрена тогда чистый ФЯ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 15:38
Оценка:
Здравствуйте, lomeo, Вы писали:

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



L>А ещё говорят, что на Haskell код меньше, чем на С получается!


>>main = do

>> i <- newInt
>> for (i =: 1, i <= 5, (i++)) $
>> printf "%i\n" i

Все равно неестественно и не натурально
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 16:08
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


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


VE>А "требуется" как правило определяется мышлением, привязанным к тому самому другому языку.


Наверное, а разве это плохо? Например, я жалею, что в java нет чего-то навроде LINQ. Почитал статью, очень понравилось. Я уже вижу, насколько я мог бы сократить код,который пишу в данный момент.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 16:10
Оценка:
LP>Если я могу получить все, что мне требуется получить от хаскеля,

А что требуется?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 16:23
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Все равно неестественно и не натурально


Вдогонку. Отсюда.

So, in the end, has Haskell simply re-invented the imperative wheel?

In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds.


Перевод

Ну так что, Haskell просто-напросто изобрёл императивное колесо?

В некотором смысле да. Монада IO образует маленький императивный подъязычок внутри Haskell и, таким образом, компоненты ввода-вывода программы могут являться кодом, похожим на обычный императивный. Но есть одно важное отличие: нет никакой специальной семантики, которая необходима пользователю, чтобы работать с императивом. В частности equational reasoning не скомпрометирован. Императивный привкус монадического кода не преуменьшает функциональные особенности Haskell. Опытный ФП программист способен минимизировать императивную составляющую программы, используя монаду IO для минимального количества топ-левел последовательности действий (приношу ивзинения за корявый перевод). Монада явно разделяет функциональный и императивный код. Напротив, ИЯ с функциональным подмножеством в целом не имеют хорошо определённого барьера между чистым функциональным и императивным мирами.

Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 16:26
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Если серьезно, то не так уж и много (для java):


Эх.. Больная мозоль!..
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 16:30
Оценка:
Здравствуйте, lomeo, Вы писали:

L>В общем не всё так плохо в императивном программировании на чистях ФЯ.


Все, что ты привел, очень интересно. Но на самом деле GUI, всякая интерактивность и другие по определению императивные вещи — это далеко не единственные случае, когда требуется императивность. Вот я работаю в области энергетики, часто приходится писать алгоритмы по раскрутке/трансформации электроцепей. Очень часто наиболее разумное решение оказывается именно императивным (хотя и далеко не всегда). Я считаю, что язык должен предоставлять возможности для естественного императивного программирования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.01.09 16:40
Оценка:
Здравствуйте, LaPerouse, Вы писали:

L>>В общем не всё так плохо в императивном программировании на чистях ФЯ.


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


Императивное — это значит последовательное, разве нет? Ну и плюс отсюда вытекает состояние. Т.е. я не имел в виду именно GUI, интерактивность и т.д. Надо было придумать какой-то пример, вот я его и взял. На самом деле, как мне кажется, нет разницы что именно мы программируем. Если мы можем удобно запрограммировать императивно на Haskell одну вещь, то, наверное, сможем и другую. Т.е. я не вижу, почему твой императивный алгоритм на Haskell запишется хуже, чем на Яве (раз уж ты её приводил в пример). Можно как нибудь раскрыть этот момент?
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 22.01.09 16:55
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>В общем не всё так плохо в императивном программировании на чистях ФЯ.


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


L>Императивное — это значит последовательное, разве нет? Ну и плюс отсюда вытекает состояние. Т.е. я не имел в виду именно GUI, интерактивность и т.д. Надо было придумать какой-то пример, вот я его и взял. На самом деле, как мне кажется, нет разницы что именно мы программируем. Если мы можем удобно запрограммировать императивно на Haskell одну вещь, то, наверное, сможем и другую. Т.е. я не вижу, почему твой императивный алгоритм на Haskell запишется хуже, чем на Яве (раз уж ты её приводил в пример). Можно как нибудь раскрыть этот момент?


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

/**
     * Функция трансформации последовательных соединений
     * @param s - схема
     * @return true, если была произведена нормализация, false в противном случае
     * @throws Exception 
     */
    public static boolean transform(Scheme s) throws TransformException
    {
        boolean res = false;
        
        List<INode> nodes = new ArrayList<INode>();
        
        for (INode node : s.getNodes())
            nodes.add(node);
        
        int len = nodes.size();
        for (int i=0; i<len; i++)
        {
            INode node = nodes.get(i);
            if (SchemeHelper.getElementsCount(node) == 2 && !SchemeHelper.isEntrantPoint(s, node))
            {
                IElement element1 = SchemeHelper.getElements(node).get(0);
                IElement element2 = SchemeHelper.getElements(node).get(1);
                
                if (element1.isLinear() && element2.isLinear())
                {
                    INode node1 = SchemeHelper.getOtherNode((LinearElement) element1, node);
                    INode node2 = SchemeHelper.getOtherNode((LinearElement) element2, node);
                    
                    IElement newElem = merge((LinearElement)element1, (LinearElement)element2);
                    
                    s.detachElement(element1);
                    s.detachElement(element2);
                    s.removeNode(node);
                    len--;
                    s.attachElement(newElem, new INode[]{node1, node2});
                    res = true;
                }
            }
        }
        
        return res;
    }


как видишь, алгоритм чисто императивный, используется мутабельная Scheme. Наиболее разумно на каждом шаге рекурсии модифицировать именно существующую схему, это разумнее, чем собирать новую. На java это можно делать легко и естественно, спрятав изменение состояния за интерфейсами. Подозреваю, что на хаскель был бы дикий изврат с монадой State или Scheme, завернутой в IO. В общем, было бы тоже самое, но был бы оверхед по синтаксису,который мне совершенно не нужен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 17:13
Оценка:
LP>Вот я работаю в области энергетики, часто приходится писать алгоритмы по раскрутке/трансформации электроцепей. Очень часто наиболее разумное решение оказывается именно императивным (хотя и далеко не всегда). Я считаю, что язык должен предоставлять возможности для естественного императивного программирования.

<a href=http://thesz.livejournal.com/920509.html&gt;Ба</a>! Мне кажется совсем обратное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 17:28
Оценка:
LP>как видишь, алгоритм чисто императивный, используется мутабельная Scheme. Наиболее разумно на каждом шаге рекурсии модифицировать именно существующую схему, это разумнее, чем собирать новую.

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

При построении новой структуры старая остаётся доступной. Можно сравнить их по какому-либо параметру и оценить результаты.

LP>На java это можно делать легко и естественно, спрятав изменение состояния за интерфейсами. Подозреваю, что на хаскель был бы дикий изврат с монадой State или Scheme, завернутой в IO.


Нет. Обычная функция, Connect -> Connect.

Зачем здесь IO?

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

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

Такие, вот, дела.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 22.01.09 17:32
Оценка:
LP>>>Если я могу получить все, что мне требуется получить от хаскеля,
T>>А что требуется?
LP>1. Какой-то сахар на уровне языка, чтобы можно было легко оперировать с соотв. структурами данных (кортежи, односвязные списки)
LP>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>3. Templates как в С++

Отличный пункт.

LP>4. Сопоставление с образцом

LP>Удобный и естественный способ работать с мутабельными данными, но это уже есть.
LP>Дополнительные требования: компилятор должен оптимизировать хвостовую рекурсию. В javac все печально

Это можно получить много, где. В том же OCaml. Про использование OCaml и изменяемых графовых структур — см. ссылку на статью, что я дал чуть прежде.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.01.09 07:13
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


Почему наиболее разумно?

LP>На java это можно делать легко и естественно, спрятав изменение состояния за интерфейсами. Подозреваю, что на хаскель был бы дикий изврат с монадой State или Scheme, завернутой в IO. В общем, было бы тоже самое, но был бы оверхед по синтаксису,который мне совершенно не нужен.


Если писать на Scheme, завёрнутой в IO, то оверхед будет только при разыменовании примитивных переменных (i, len в нашем случае). И от этого оверхеда можно избавиться, определив свои функции над IORef Int. Т.е. сделать код один в один (и даже короче, за счёт того, что одинаковые участки легко выделять в Haskell и очень тяжело в Яве).

Однако, я бы этот алгоритм скорее всего записал чисто функционально. К сожалению, ничего не знаю о типе Scheme.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 23.01.09 20:44
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


L>Почему наиболее разумно?


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

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

LP>>На java это можно делать легко и естественно, спрятав изменение состояния за интерфейсами. Подозреваю, что на хаскель был бы дикий изврат с монадой State или Scheme, завернутой в IO. В общем, было бы тоже самое, но был бы оверхед по синтаксису,который мне совершенно не нужен.


L>Если писать на Scheme, завёрнутой в IO, то оверхед будет только при разыменовании примитивных переменных (i, len в нашем случае). И от этого оверхеда можно избавиться, определив свои функции над IORef Int. Т.е. сделать код один в один (и даже короче, за счёт того, что одинаковые участки легко выделять в Haskell и очень тяжело в Яве).




L>Однако, я бы этот алгоритм скорее всего записал чисто функционально.


А зря. Это как раз тот случай, когда лучше отодвинуть религию на второй план. На Хаскель надейся, но сам не плошай

>>К сожалению, ничего не знаю о типе Scheme.


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

addNode(INode node)
attachElement(IElement element, INode[] nodes)
detachElement(IElement element)
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 23.01.09 20:51
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>Теперь представь, что тебе надо оценивать изменения. Алгоритм преобразования такой, что не всегда даёт оптимизирующее преобразование. Ну, так случилось.


T>При построении новой структуры старая остаётся доступной. Можно сравнить их по какому-либо параметру и оценить результаты.


Ну можно сделать scheme.clone() перед тем, как скармливать ее алгоритму. Правда, при отсутствии прозрачности ссылок этим можно получить по почкам. Но тем не менее

LP>>На java это можно делать легко и естественно, спрятав изменение состояния за интерфейсами. Подозреваю, что на хаскель был бы дикий изврат с монадой State или Scheme, завернутой в IO.


T>Нет. Обычная функция, Connect -> Connect.


T>Зачем здесь IO?


В нее можно обернуть scheme и тем самым иметь состояние

T>Построение структуры вместо изменения уменьшает количество ошибок.


Мне это конечно же известно, но в некоторых случаях, когда изменения небольшие, а структура данных нетривиальная, то уместнее именно изменять. В примере выше как раз тот случай.
За ссылку спасибо, почитаю завтра.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 23.01.09 22:53
Оценка:
LP>Мне это конечно же известно, но в некоторых случаях, когда изменения небольшие, а структура данных нетривиальная, то уместнее именно изменять. В примере выше как раз тот случай.

Вот уж извини, но это не тот случай. Если бы изменения большие и тривиальные, то есть, строить долго, зато мало вероятности ошибиться — тогда, да, можно (но не надо, NB!) на месте изменять.

А если и построить быстро и ошибка вероятна — лучше перестраивать. Всегда можно откатиться назад, если не проходит проверка преобразований на сохранение смысла сети.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 23.01.09 22:55
Оценка:
L>>Почему наиболее разумно?
LP>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию.

Это не так. Дей1ствия ровно те же. Клонирования большей части нод нет.

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


Во-во. Выспишься и увидишь, в чём был неправ.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 26.01.09 17:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.

С чем например?

Ну и заодно приведи пример.
Я вот приведу пример на понятность:
take 20.randoms >>> print.maximum

И на краткость:
when True act = act >> return ()
when False _ = return ()


Только не надо про синтетичность примеров (when-то и в Немерле есть) и приводить свои примеры с использованием какой-нибудь штуки из .Net, которой нет на Хаскеле. Это не краткость языка.
Мне действительно хотелось бы посмотреть на язык с записью короче, чем у Хаскеля.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 26.01.09 17:10
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Если просто "у кого короче", то J переплюнет хаскель


Этот язык я видел, да
Хотелось бы, конечно, не жертвовать понятностью ради короткости.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 18:16
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

T>И я разговариваю с тобой, как с таковым человеком.


Дык и я с тобой не как с машиной или животным разговариваю.

T>Кстати, то, что ты записал меня в упёртые функциональщики, которые записывают тебя в императивщики, как раз говорит об узости классификации и нежелании разобраться в явлении. Да и другие люди тоже никуда тебя не записывают. Всё их сопротивление сводится к "не мешай мне учитывать проблемы, которые я считаю важными", вот они тебя и отпихивают "отойди и не мешай своим ФП/ИП", всё остальное происходит в твоём мозгу.


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

T>Ты всем стараешься навязать важность твоих проблем и их решений.


Да? Ну, тогда тебе не составит труда описать какие проблемы я тебе навязывал. Не говоря уже о решениях... Опишешь?

T>Да чуть выше — "написать статью ты в принципе не в силах". А оно мне надо, писать статью?


Видимо надо раз в этой теме уже который день тусушеся.

T>Мне пост в ЖЖ важнее статьи, поскольку чаще. Про важность для других, то мой короткий рассказ про лямбда исчисления использовали при подготовке к экзамену. Мне достаточно.


Хорошее начинание. Жаль только затеряется оно в куче других страниц.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 18:25
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем


А ссылка есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 26.01.09 20:53
Оценка:
T>>Кстати, то, что ты записал меня в упёртые функциональщики, которые записывают тебя в императивщики, как раз говорит об узости классификации и нежелании разобраться в явлении. Да и другие люди тоже никуда тебя не записывают. Всё их сопротивление сводится к "не мешай мне учитывать проблемы, которые я считаю важными", вот они тебя и отпихивают "отойди и не мешай своим ФП/ИП", всё остальное происходит в твоём мозгу.
VD>Я тебя никуда не записывал. Если ты себя сам записал, то апеллируй к себе.
VD>Я сказал, то что сказал. Не надо домысливать.

Kewl!

T>>Да чуть выше — "написать статью ты в принципе не в силах". А оно мне надо, писать статью?

VD>Видимо надо раз в этой теме уже который день тусушеся.

В смысле? Который день я уже "тусущеся" в этой теме?

О чем мои комментарии здесь?

T>>Мне пост в ЖЖ важнее статьи, поскольку чаще. Про важность для других, то мой короткий рассказ про лямбда исчисления использовали при подготовке к экзамену. Мне достаточно.

VD>Хорошее начинание. Жаль только затеряется оно в куче других страниц.

В оглавлении оно присутствует.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: yuriylsh  
Дата: 27.01.09 05:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AF>>На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем


VD>А ссылка есть?


Здесь. Ссылки на скачивание, я так понимаю, давать здесь запрещено...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 07:51
Оценка:
Здравствуйте, VoidEx, Вы писали:

VD>>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.

VE>С чем например?

С любым языком полноценно поддерживающим ФП.

VE>Только не надо про синтетичность примеров (when-то и в Немерле есть)


Пожалуйста, не буду. Мне бессмысленная пенисометрия уже давно надоела.

VE>и приводить свои примеры


А мне больше заняться не чем чем доказывать упертым очевидные прописные истины. Веришь в Хаскель? Ну, так молись и верь. Не буду мешать. А у меня своих дел навалом. Тут пенисометрии по форуму разбросано тонна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, thesz, Вы писали:

L>>>Почему наиболее разумно?

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

T>Это не так. Дей1ствия ровно те же. Клонирования большей части нод нет.


Есть, есть.

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


T>Во-во. Выспишься и увидишь, в чём был неправ.


Не вижу
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, FR, Вы писали:

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


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


FR>То есть ты пишешь на Ocaml?



а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


LP>>Если серьезно, то не так уж и много (для java):


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

LP>>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>>3. Templates как в С++
LP>>4. Сопоставление с образцом

VD>Это называется Scala.


Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы, вследствие чего например затрудняется описание jpa-маппингов (в принципе, это мелочи, доменную модель можно и на java сделать).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 08:43
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию. Потом для каждой ноды, удовлетворяющей условию, нужно добавить элемент, заменяющий прилегающие к ноде элементы. Я только с командировки вернулся и адски хочу спать, поэтому нет времени сделать набросок.


Я правильно понимаю? Тебя смущает, что мы не модифицируем саму структуру, а пользуемся Scheme -> Scheme? Но тогда непонятны твои замечания об оверхеде по синтаксису. Код как раз таки сократится.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 08:47
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы, вследствие чего например затрудняется описание jpa-маппингов (в принципе, это мелочи, доменную модель можно и на java сделать).


Сам ответил на свой вопрос. Плюс надо учесть, что разработчики открыты для контактов и скорее всего исправят те проблемы которые мешают использовать язык на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:48
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию. Потом для каждой ноды, удовлетворяющей условию, нужно добавить элемент, заменяющий прилегающие к ноде элементы. Я только с командировки вернулся и адски хочу спать, поэтому нет времени сделать набросок.


L>Я правильно понимаю? Тебя смущает, что мы не модифицируем саму структуру, а пользуемся Scheme -> Scheme? Но тогда непонятны твои замечания об оверхеде по синтаксису. Код как раз таки сократится.


Меня не радует, что Scheme -> Scheme намного более накладна в данном случае (по реализации), чем простая модификация Scheme. Я написал, почему. Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 08:49
Оценка:
Здравствуйте, LaPerouse, Вы писали:

FR>>То есть ты пишешь на Ocaml?


LP>

LP>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы

Ocaml не имеет серьезных приемуществ по сравнению с той же Скалой. Фактически Скала — это перенос идей МЛ-я на Яву. А Ocaml перенос (причем плохой) идей ООП в МЛ.

Так что выбирая Скалу вы можно сказать выбираете близкого родственника ОКамла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 09:02
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Императивное — это значит последовательное, разве нет? Ну и плюс отсюда вытекает состояние. Т.е. я не имел в виду именно GUI, интерактивность и т.д. Надо было придумать какой-то пример, вот я его и взял. На самом деле, как мне кажется, нет разницы что именно мы программируем. Если мы можем удобно запрограммировать императивно на Haskell одну вещь, то, наверное, сможем и другую. Т.е. я не вижу, почему твой императивный алгоритм на Haskell запишется хуже, чем на Яве (раз уж ты её приводил в пример). Можно как нибудь раскрыть этот момент?


VD>Да потому что нужны лишние приседания. Даже от твоих примеров (простеньких) уже в сон клонет.


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

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


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

VD>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.


Сравнивал. Если ты про Скала/Немерле, то не улетучивалось.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 09:37
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Меня не радует, что Scheme -> Scheme намного более накладна в данном случае (по реализации), чем простая модификация Scheme. Я написал, почему. Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.


Хорошо, обязательно попробую.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 10:31
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.


Наврал, detachElement всё таки нужен. Поэтому сначала

> import Data.List


Затем

> detachElement :: Element -> Node -> Scheme -> Scheme
> detachElement el n = M.adjust (delete el) n


Чтобы пример компилировался, добавить deriving Eq к Element.

Ну и строчка преобразования схемы меняется на

>  in attachElement el (ln, rn) $ detach el1 $ detach el2 $ s
> ...
> where
>     detach el = detachElement el (otherNode el)


Извиняюсь за невнимательность, очень быстро всё писал.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 11:46
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


L>В общем, написал.


L>Мне показалось, что здесь удобно использовать Map


L>
>> import qualified Data.Map as M
L>


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


L>
>> type Node = Int
L>


L>Элемент у меня хранит ссылки на узлы, в реальной программе будут скорее всего типы Element и ElementEntry. Для нас это неважно, т.к. на алгоритм не влияет. Также для функционального алгоритма не важно конечный ли это тип с полем isLinear или это функция класса типов Element — аналог твоих интерфейсов. Чтобы было покрасивее (паттерн матчинг) я выбрал тип


Ага, ElementEntry (у меня это называется Pin), это "ножка" элемента, с помощью которой он присоединяется к ноде.

L>
>> data Element = Element { isLinear :: Bool, leftNode :: Node, rightNode :: Node }
L>


Соответственно, LinearElement — это элемент, имеющий только два Pin-a. LinearElement, вместе с другими типами элементов, реализует интерфейс IElement (например, есть еще трансформаторы Transformer и т. д.). Для данного алгоритма это неважно, твой Element вполне сойдет.

L>Схема — это просто мап.


L>
>> type Scheme = M.Map Node [Element]
L>


Хорошо.

L>Определим вспомогательные функции, которые у тебя не показаны.


L>Во первых, аналог SchemeHelper.getOtherNode. Думаю, у тебя не сильно отличается.


L>
>> otherNode :: Element -> Node -> Node
>> otherNode (Element _ l r) n
>>     | l == n    = r
>>     | otherwise = l
L>


В общем, верно. У меня немного сложнее — элементы могут иметь более двух пинов и данная функция реализуется как частный случай для LinearElement (см. у меня в коде приведение к типу LinearElement), но это непринципиально.

L>Как именно мёрджить элемент я, к сожалению, не знаю — думаю, вопрос предметной области.


Да, это неважно. На самом деле считается сопротивления элемента, токопередача и пр.

L>Есть отличие — мы мёржим не сам элемент, а его обёртку (ElementEntry), таким образом мёрджим относительно какого то узла. Здесь у нас отличие.


L>
>> mergeElement :: Element -> Element -> Node -> Element
>> mergeElement e1 e2 n = Element True (otherNode e1 n) (otherNode e2 n)
L>


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

L>Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.


Ок, исправление я видел.

L>Добавляем элемент. Поскольку добавляется он к уже имеющимся в схеме узлам, то здесь тоже ничего сложного.


L>
>> attachElement :: Element -> (Node, Node) -> Scheme -> Scheme
>> attachElement el (ln, rn) = go ln . go rn
>>     where
>>         go = M.adjust (el:)
L>


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


L>
>> isEntrantPoint :: Node -> Scheme -> Bool
>> isEntrantPoint _ _ = False
L>


Это точка входа в схему. Непринципиально.

L>И вот только сейчас аналог твоего кода. Можно сравнивать — страшно или нет.


L>Во-первых, трансформация по одному узлу (то, что у тебя в цикле). Здесь паттерн матчинг (по Element) помогает, но не сильно.

L>В случае, если мы используем класс Element, будут функции getLeftNode, getRightNode и т.д. Строчка будет чуть длиннее.

То есть будут if-ы, как у меня. Ладно, это непринципиально.

L>
>> transformWithNode :: Node -> Scheme -> Scheme
>> transformWithNode node s
>>     | length els /= 2 || isEntrantPoint node s = s
>>     | isLinear el1 && isLinear el2 =
>>         let el@(Element _ ln rn) = mergeElement el1 el2 node
>>          in attachElement el (ln, rn) s
>>     where
>>         els@(~[el1, el2]) = s M.! node
L>


L>И собственно функция.


Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?). Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 12:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>>То есть ты пишешь на Ocaml?


LP>>

LP>>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы

VD>Ocaml не имеет серьезных приемуществ по сравнению с той же Скалой. Фактически Скала — это перенос идей МЛ-я на Яву. А Ocaml перенос (причем плохой) идей ООП в МЛ.


VD>Так что выбирая Скалу вы можно сказать выбираете близкого родственника ОКамла.


Честно говоря я имею о Ocaml лишь отдаленное представление (смотрел где-то год назад F#), какое-то определенное мнение не смог составить. Не думаю, что для него существует поддержка платформы java, сравнимая со Scala, которая только для jvm и разрабоатывается. Так что если выбирать между ними, то конечно, выберу Scala — уже только из практических соображений.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 12:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А мне больше заняться не чем чем доказывать упертым очевидные прописные истины. Веришь в Хаскель? Ну, так молись и верь. Не буду мешать. А у меня своих дел навалом. Тут пенисометрии по форуму разбросано тонна.


Хватит проецировать свою религию на остальных. Я не фанат Хаскеля, но твои аргументы смешны. Не можешь привести примера, ну и не надо, а записывать всех в фанаты (а потом удивляться, почему фанатом считают тебя) — не надо.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 12:21
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).


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

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

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


Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 27.01.09 12:36
Оценка:
T>>Это не так. Дей1ствия ровно те же. Клонирования большей части нод нет.
LP>Есть, есть.

И где же они?

Вот у нас есть структура Map Int Component. Я удаляю компонент с каким-то индексом. Какое количество информации будет скопировано?

Правильный ответ: log(количество компонент). Но не самих компонент, а только дерево Map.

Теперь я добавляю компоненту. Ситуация ровно та же самая.

log(количество компонент) это никак не копирование большей части узлов.

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

T>>Во-во. Выспишься и увидишь, в чём был неправ.
LP>Не вижу

Гляди снова.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 12:39
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).


L>Согласен, конечно, извращения!


Это шутка

L>Собственно, у нас была дискуссия по поводу "императивных алгоритмов", мол, в функциональном виде это выльется во что-то страшное.


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

L>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?


Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.

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


L>Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных


Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 12:40
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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


LP>>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).


L>>Согласен, конечно, извращения!


LP>Это шутка


То есть хотело спросить, ты в самом деле так считаешь или пошутил?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 27.01.09 12:43
Оценка:
LP>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).

Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.

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


Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме.

Скорость выполнения вторична по отношению к функциональности, по крайней мере, в первой версии.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 12:51
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).


T>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.


Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.

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


T>Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме.


Даже не знаю, сложней ли. Может, и сложней.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 27.01.09 12:54
Оценка:
T>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.
LP>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.

Так — это перестраивать структуру.

Я, если честно, не вижу, чем ссылки отличаются от значений, если ссылки на read-only объекты.

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

T>>Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме.
LP>Даже не знаю, сложней ли. Может, и сложней.

Если привык менять на месте, то проще, конечно. Но если умеешь делать и так, и так, то уже сложней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: nikov США http://www.linkedin.com/in/nikov
Дата: 27.01.09 12:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы,


Можно пример того, что там не реализовано?
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 13:02
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.

LP>>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.

T>Так — это перестраивать структуру.


T>Я, если честно, не вижу, чем ссылки отличаются от значений, если ссылки на read-only объекты.


Это понятно, что ничем. Только ссылки потому то и нужны, чтобы адресовать изменяющиеся объекты c identity. Иначе их никто и ссылками не называл (то есть это название отражало бы лишь только способ размещения в памяти).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 13:44
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.

LP>>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.

T>Так — это перестраивать структуру.


Интересно, как это ты себе представляешь на java. Тогда придется программировать, нарушая чуть ли не все принципы и паттерны объектно-ориентированного программирования. Например, абстрактную фабрику как реализовать? Передавать подряд все параметры, которые нужны объекту фабрике, чтобы она забила намертво эти данные в конструкторе?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 13:55
Оценка:
Здравствуйте, LaPerouse, Вы писали:

L>>Собственно, у нас была дискуссия по поводу "императивных алгоритмов", мол, в функциональном виде это выльется во что-то страшное.


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


Да, но обрати внимание, это был твой аргумент и он не прошёл

Если говорить откровенно, то я не знаю, есть ли задачи, для которых императивные алгоритмы имеют лучшую сложность. Я что-то такое слышал, как слышал и обратное. Не разбирался, поэтому не могу сделать никаких заявлений. Но вот то, что для большинства встречающихся мне задач фп подходит лучше — могу. Но это уже будет ИМХО, так что спора опять не получится

L>>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?


LP>Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.


Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?

LP>Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?


В случае уникального типа модификация должна быть по месту. Надо посмотреть Clean и Mercury.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 27.01.09 14:09
Оценка:
T>>Так — это перестраивать структуру.
LP>Интересно, как это ты себе представляешь на java. Тогда придется программировать, нарушая чуть ли не все принципы и паттерны объектно-ориентированного программирования.

"Хороша ложка к обеду".

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

LP>Например, абстрактную фабрику как реализовать? Передавать подряд все параметры, которые нужны объекту фабрике, чтобы она забила намертво эти данные в конструкторе?


Я не предлагаю так программировать везде. Я предлагаю так программировать в сложных местах, где легко ошибиться.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 14:31
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?


LP>>Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.


L>Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?


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

LP>>Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?


L>В случае уникального типа модификация должна быть по месту. Надо посмотреть Clean и Mercury.


Я на досуге посмотрел Prolog, сложилось такое ощущение, что для трансформации-преобразования схем оно самое то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 14:59
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Извращение в том, что это выглядит искуственно. Зачем вообще отделять императивное от фукционального, да еще подобным костылем? Программист сам прекрасно может это делать без всяких проверок со стороны компилятора.


1. Зачем отделять императивное от функционального? Затем, что если не отделять, то всё будет императивное. Если же отделять, то мы будем иметь много-много чистого кода и чуть-чуть грязного. Преимущества чистого кода расписывать не буду.
2. Зачем отделять именно таким способом? Ну, это один из возможных способов. Предложи лучше для чистого ленивого языка.

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

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

LP>Я на досуге посмотрел Prolog, сложилось такое ощущение, что для трансформации-преобразования схем оно самое то.


Чем лучше какого нибудь ML-ного варианта?
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 15:09
Оценка:
Здравствуйте, LaPerouse, Вы писали:

L>>Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?


Как где. Какое-то IO непонятное, do ещё... А ещё эти, чёрт их побери... А! Монады! Непонятная штука вообще.

LP>Извращение в том, что это выглядит искуственно. Зачем вообще отделять императивное от фукционального, да еще подобным костылем? Программист сам прекрасно может это делать без всяких проверок со стороны компилятора.


Искуственно выглядит ключевое слово pure.
Как программист, проекрасно могущий это сделать, расскажи мне всё, что ты можешь, об этой функции:
[float] foo(int x, [float] f)

А что ты можешь сказать о такой (псевдокод):
foo int (n :[float]) : [float], IO, Complexity O(log n)

Когда для определения свойств функции надо лезть в её реализацию, вот извращение. Можно, конечно, плётками заставлять документацию писать, но лучше, когда это заставляет делать компилятор. Да и то, не заставляет, а сам выносит на уровень декларации свойства функции.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:40
Оценка:
Здравствуйте, lomeo, Вы писали:

L>1. Зачем отделять императивное от функционального? Затем, что если не отделять, то всё будет императивное. Если же отделять, то мы будем иметь много-много чистого кода и чуть-чуть грязного. Преимущества чистого кода расписывать не буду.

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

Главный вопрос тут скорее зачем нужен чисто ленивый язык? Ну, и может быть еще: Что дает отделение императива от функционального кода в не ленивом по умолчанию языке?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:42
Оценка:
Здравствуйте, thesz, Вы писали:

T>Скорость выполнения вторична по отношению к функциональности, по крайней мере, в первой версии.


Скорость — это такое же требование как и все другие. Если она не приемлема, то первая, вторая... да любая версия пойдет в помойку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:44
Оценка:
Здравствуйте, VoidEx, Вы писали:

VD>>А мне больше заняться не чем чем доказывать упертым очевидные прописные истины. Веришь в Хаскель? Ну, так молись и верь. Не буду мешать. А у меня своих дел навалом. Тут пенисометрии по форуму разбросано тонна.


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


Нем у меня религии. Это верующие ее узревают. Для них и атеизм — религия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 17:45
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Не можешь привести примера, ну и не надо,


Не не могу, а не хочу и вижу в этом смысла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 18:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Главный вопрос тут скорее зачем нужен чисто ленивый язык? Ну, и может быть еще: Что дает отделение императива от функционального кода в не ленивом по умолчанию языке?


Ты задаёшь вопрос, не относящийся к нашему разговору. Мы говорим о Haskell.

Ну а на первый вопрос я тебе уже отвечал неоднократно. Или хочется пофлеймить?
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 18:19
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Нем у меня религии. Это верующие ее узревают. Для них и атеизм — религия.


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

Вот на Немерле код — как спагетти по сравнению с Хаскелем. Я правда доказывать ничего не буду. Это просто факт.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 18:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не не могу, а не хочу и вижу в этом смысла.


А в сыпаньи голословными утверждениями ты видишь смысл? Кому ты хочешь что-то доказать?

— I have a ball
— Prove
— You can't prove that I have not!!!!!!11

Главное вот влез в разговор с провокацией "главный вопрос, зачем нужен чистый ленивый язык". Наверняка расскажешь про то, что ФП не панацея и что нужно брать сочетание императива, ну и т.п. Только доказывать ты ничего никому не собираешься, просто так пофлеймить. "Штирлиц пришёл, сейчас будет драка".
Вот кстати сочетание ФП и императива — не панацея. Если хочешь скорости — бери императив, если высокоуровневости и простоты — ФП, серебряной пули не существует, посему мутант ни то, ни сё толком не умеет.
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 19:09
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Главный вопрос тут скорее зачем нужен чисто ленивый язык? Ну, и может быть еще: Что дает отделение императива от функционального кода в не ленивом по умолчанию языке?


L>Ты задаёшь вопрос, не относящийся к нашему разговору. Мы говорим о Haskell.


Серьзно? А название темы читали?

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


Ответ не то что бы не внятный. Он просто никакой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 19:18
Оценка:
Здравствуйте, VladD2, Вы писали:

Влад, захочешь пообщаться — прекращай троллить.

L>>Ты задаёшь вопрос, не относящийся к нашему разговору. Мы говорим о Haskell.


VD>Серьзно? А название темы читали?


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


VD>Ответ не то что бы не внятный. Он просто никакой.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 19:18
Оценка:
Здравствуйте, lomeo, Вы писали:

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


VD>>В "мастер-классе ФП" я высказал две мысли:

VD>>1. Что утверждение:
VD>>

VD>>я часто сталкиваюсь с двумя точками зрения — первая "я знаком с ФП, но оно никакой выгоды в программировании не даёт", и вторая "я знаком с ФП, но так и не научился использовать его для повышения эффективности программирования".

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

L>Совершенно верно. Но это мнения людей, которые реально не разобрались в предмете.


VD>>2. Примеры в этом "мастер-классе ФП" слишком примитивные.


Дык первый постулат был "я знаком с ФП".

Тогда в теме вообще чушь обсуждается. Вместо этого надо говорить, что те кто говорит "я знаком с ФП" просто не знакомы с ним.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 27.01.09 19:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А я вам не очень мешаю разводить офтоп в этой теме?

VD>Вообще у вас все темы в разговоры о хаскеле превращаются. Это уже натруальный пунктик.
VD>Парень спросит как переписать код на С в код на C#, а ему про Хаскель расскажут.
VD>eao197 заведет разговор о стилистике чужой статьи и тут про Хаскель 5 копеек вставят. И ни дай бог сменить тему. А уж если спросишь зачем он нужен, так вообще врагом народа обзовут.

Не успел задать вопрос, как оказался причислен к неким "у вас".
Однако. "Он меня бросил, все мужыки козлы!". Где _я_ про Хаскель тут говорил кроме ответа на твоё утверждение и на вопрос о Хаскеле? Ты бы к лагерям не причислял, и тебя не будут.
Так что ты перечитывай, когда ответы пишешь.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 27.01.09 20:59
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Только ссылки потому то и нужны, чтобы адресовать изменяющиеся объекты c identity. Иначе их никто и ссылками не называл (то есть это название отражало бы лишь только способ размещения в памяти).

А почему они обязательно должны быть изменяющимися?
now playing: Squarepusher — Heliacal Torch
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 03:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>"Знаком с ФП" == "Реально разобрался"?


Тогда нужно было просто говорить о заблуждениях.

Как примеры, тем более мелкие, помогут развенчать заблуждение?

Результат будет только хуже. Вместо того чтобы бороться с причиной (заблуждением) мы начинаем дискутировать с людьми чего-то себе вообразившими. Результат будет предсказуем. Вот тут где-то человек демонстрировал тебе пример обработки дерева на Яве и заявлял, что императивный алгоритм в его случае будет компактнее. Это явное заблуждение. Но спорить с ним трудно, так как без той самой базы ты разговариваешь с блабом который просто не понимает (не видит) другого подхода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 29.01.09 05:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А я вам не очень мешаю разводить офтоп в этой теме?

VD>Вообще у вас все темы в разговоры о хаскеле превращаются. Это уже натруальный пунктик.
VD>Парень спросит как переписать код на С в код на C#, а ему про Хаскель расскажут.
VD>eao197 заведет разговор о стилистике чужой статьи и тут про Хаскель 5 копеек вставят. И ни дай бог сменить тему. А уж если спросишь зачем он нужен, так вообще врагом народа обзовут.

Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 29.01.09 08:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Тогда нужно было просто говорить о заблуждениях.

VD>Как примеры, тем более мелкие, помогут развенчать заблуждение?

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

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


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

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

Главный вопрос, конечно, как ты предлагаешь это сделать?
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 20:47
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>А "требуется" как правило определяется мышлением, привязанным к тому самому другому языку.


Ну, еще такими мелочами как производительностью и необходимостью писать много кода большими коллективами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 20:52
Оценка:
Здравствуйте, D. Mon, Вы писали:

LP>>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы


DM>http://cafesterol.x9c.fr/

DM>?

Думаю, что у этого чуда будут те же проблемы, что у F#-а. Системы типов ОКамла больно не совместима с Явовской. Поэтому Скала будет намного удобнее, и что немаловажно, проще в освоении.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 29.01.09 23:10
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Сравнивал. Если ты про Скала/Немерле, то не улетучивалось.


VD>Да его просто нет.


А зачем тогда нижевыделенное написал?

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


Поэтому и не улетучивалось.

Больше флудить и письками меряться не хочется.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 23:35
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А зачем тогда нижевыделенное написал?


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


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

L>Поэтому и не улетучивалось.

L>Больше флудить и письками меряться не хочется.

Ну, так и не надо это делать. Просто признайте, что преимущество дает не Хаскель а функциональный подход и удобство его применения в некоторых языках. Единственное реальное отличие Хаскля — это ленивость по умолчанию. Вот только это где-то преимущество, где-то недостаток. В общем, весьма спорный дизайнерский ход.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.09 23:38
Оценка:
Здравствуйте, VoidEx, Вы писали:

L>>Влад, захочешь пообщаться — прекращай троллить.


VE>Боюсь, что он не тролль.


А что в этом страшного?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.01.09 09:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вот попытался сделать такой проект и описал его здесь
Автор(ы): Владислав Чистяков aka VladD2
Дата: 17.07.2008
Статья демонстрирует разработку реального приложения на Nemerle на примере создания простого генератора отчетов. Кроме того, в статье показана работа
с XML средствами LINQ to XML.
.

VD>Проект не большой (по крайней мере для языка поддерживающего ФП), но при этом вполне себе реальный.
VD>В нем затрагиваются важные для людей вещи вроде обработки ХМЛ-я, создания простенького интерпретатора выражений и даже взаимодействия с MS Office.

Интересно, спасибо, обязательно почитаю.

VD>Было бы интересно поглядеть на реализацию этого же проекта средствами того же Хаскеля.


Чуть позже отпишу, сначала прочту

VD>В общем, да. Но в результате он все равно остался на своих позициях.


Ну, не совсем так, но в целом ты прав, наверное.

L>>Что касается самого замечания о том, что бороться надо с причиной — как ты предлагаешь это сделать?


VD>На мой взгляд есть только два подхода.

VD>Насколько попытки удачны, я судить не могу в виду пристрастности. Но мне кажется, что именно это верный подход.

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

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


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

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

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


Мой опыт говорит, что это не так. Знакомые мне ФП программисты вовсе не впечатлительные и доверчивые — это умные и интересные люди.

VD>Просто бессмысленны. Особенно если при этом не объясняется как надо мыслить, чтобы решать эту задачу.


Насчёт того, что надо объяснять как мыслить — полностью согласен.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.01.09 09:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, так и не надо это делать. Просто признайте, что преимущество дает не Хаскель а функциональный подход и удобство его применения в некоторых языках. Единственное реальное отличие Хаскля — это ленивость по умолчанию. Вот только это где-то преимущество, где-то недостаток. В общем, весьма спорный дизайнерский ход.


Ну, хорошо, скажем так: "Хаскель даёт следующие преимущества — бла-бла-бла, при этом он обладает следующими недостатками — бла-бла-бла. В большом количестве задач, которые я решаю, преимущества перевешивают недостатки значительнее, чем, скажем у Немерле/Скала". Это IMHO — о чём тут спорить?

Про ленивость отдельная песня. Смысл в том, что не конкретно ленивость, а набор нескольких свойств (система типов, ФВП, безскобочная запись, даже do-нотацию) делают из Хаскеля Хаскель. Ленивость есть не только в Хаскеле, как и любое из других свойств, но именно этот набор формирует такой язык и поощряет такое написание программ. Как и в любом другом языке. Какой набор подходит для твоей задачи — выбирать тебе. Примерно так.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 30.01.09 09:24
Оценка:
VD>>>Конечно у Хаскеля не может не быть своих преимуществ, как у любого хоть что-то стоящего языка. Но и у других языков они тоже есть. Выигрывая в одном проигрываешь в другом. Это неизбежно.
VD>А что не ясно разве? Нет какого-то глобального приемущества позволяющего делать что-то, что нельзя делать на другом языке. На каждый выпендреж найдется другой. Оценить что круче очень не просто да и бессмысленно.

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

L>>Поэтому и не улетучивалось.

L>>Больше флудить и письками меряться не хочется.
VD>Ну, так и не надо это делать. Просто признайте, что преимущество дает не Хаскель а функциональный подход и удобство его применения в некоторых языках.

Увы, именно Хаскель. С его ленивостью, чистотой и практически уникальной системой типов.

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


Синтаксис, система типов. Нигде нет такой удобной. Последняя вынуждена была стать такой из-за ленивости.

Ограничения, они полезны.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 13:56
Оценка:
Здравствуйте, thesz, Вы писали:

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


Тет никакой кучи. 1-2 приемущества при рассмотрении конкретной задачи. А в другой 2-5 недостатков.


L>>>Поэтому и не улетучивалось.

L>>>Больше флудить и письками меряться не хочется.
VD>>Ну, так и не надо это делать. Просто признайте, что преимущество дает не Хаскель а функциональный подход и удобство его применения в некоторых языках.

T>Увы, именно Хаскель. С его ленивостью, чистотой и практически уникальной системой типов.


Верь в свою религию сколько тебе влезет. Это не более чем фанатизм.

T>Синтаксис, система типов. Нигде нет такой удобной. Последняя вынуждена была стать такой из-за ленивости.


Опять же очень спорное решение сильно осложняющее использование компонентного подхода.

T>Ограничения, они полезны.


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

Программа на всех перечисленных языках и при одинаково высоком уровне разработчика (в бласти выбранного язык) будет приблизительно сходного объема и понятности. Просто подходы будут кое где разные. Хаскелист где-то будет вынужден прибегнуть к кодированию на С/С++. Лиспер будет использовать макры. Хаскелист ленивость вычислений...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 14:15
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Было бы интересно поглядеть на реализацию этого же проекта средствами того же Хаскеля.


L>Чуть позже отпишу, сначала прочту


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

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


Если не хочет, то конечно. Но я вот вспоминаю как я пытался въехать в ФП и с чем я сталкивался. Воспоминания не из приятных.
ФП хорошо осваивают люди с сильной математической подготовкой. Но таких в наше время еденицы.
Изложение тематики ФП очень часто бывает очень косноязычное и заумное. Как в математики "ля-ля-ля из чего очевидно следует..." и 20 страниц суровых формул.

С чего скажем начинается изучение того же Хасклеля? С примера паттерн-матчинга на списках. Типа ща мы удивим блаба супер короткой быстрой сортировкой. А он тупо смотрит и нихрена не понимает. Ведь ему не объяснили, что такое паттерн-матчинг. Как на него смотреть. Как это работает...
В общем, обучение плавания путем сталкивания с корабля в воду.

L>Мы все проходили этап "непонимания ФП". Я не помню, чтобы у меня было ощущение развода. Помню, что я пожимал плечами и говорил, что прекрасно без всего этого обхожусь и в дальнейшем обойдусь замечательно. Ява (нужное подставить) не самый лучший язык, но лучше пока не придумали — и всё в таком духе. Потом я познакомился со Смолтолком. Мне стали неприятны ситуации, когда, например, надо выбирать между boilerplate и использованием анонимных классов и пр. Я почитал Хьюза и схожие статьи, где показывалось избавление от подобных проблем с помощью ФВП. Я подсел на Схему и даже несколько раз мне удалось применить её в работе. Она рулила неимоверно по сравнению с Явой. Дальше — больше.


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

Вот если бы ФП можно было легко использовать в Шарпе или Яве, то они может и попробовали бы при наличии внятного объяснения. А так... Не ужели не ясно, что Хаскель и Схема совершенно "враждебын" человеку писавшему до этого только на С++ или Паскале?

Лично я считаю, что огромная заслуга авторов Скалы и Немерла именно в том, что они смогли поместить полноценные ФЯ в облик ООЯ с привычным синтаксисом. О ЛИНК-е вообще даже говорить не чего. Это просто кусок ФП прямо во вдоску императивном языке.

L>Т.е. общий смысл такой — чтобы понять, что тебе нужно что-то новое, тебе надо почувствовать сначала, что старого не хватает. Так вот примеры Булата для людей, которые почувствовали что старого не хватает, понюхали ФП, но освоиться с ним ещё не успели. Это — закрепление материала. Те, кому всего хвата и читать то этот тред не будут. Но это только следствие моего опыта, обобщение, так что я могу и ошибаться.


Ну, ты не видишь, что ли, что ты один из тысячи кто дошел к вершине этого, казалось бы, не высокого холмика? Или ты как еао187 считашь, что проблем с пониманием ФП нет как класс?

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


L>Мой опыт говорит, что это не так. Знакомые мне ФП программисты вовсе не впечатлительные и доверчивые — это умные и интересные люди.


Это разные люди. Но многие прагматичные и весьма не глупые люди так и не освоили ФП. Хотя многие из них и хотели этого всей душой.

VD>>Просто бессмысленны. Особенно если при этом не объясняется как надо мыслить, чтобы решать эту задачу.


L>Насчёт того, что надо объяснять как мыслить — полностью согласен.


Ну, а где это можно найти в материалах об ФП? Большая их часть пишется людьми уже утратившими воспоминания о том, как они мыслили до знакомства с ФП или даже людьми которые всю жизнь так мыслили и никогда не мыслили императивно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 30.01.09 15:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Казалось бы не к чему. Но вы же постоянно спорите. У меня не было бы претензий если бы вы говорили, что Хачкель один из лучших ФЯ. Что он чистый и т.п. Но вы же все время просто таки втираете, что он лучший, что он на голову лучше всего окружающего и т.п. По крайней мере у меня складывается такое впечатление.


"ФП (Хаскель) не панацея" слышно только от тебя. И несмотря на то, что каждый раз тебе отвечают "ну... да, а это к чему?", всё равно ты никак себя не убедишь. И всё-то тебе кажется, что остальные говорят обратное. Чудной ты человек.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 30.01.09 16:10
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>"ФП (Хаскель) не панацея" слышно только от тебя.


Не только от Влада, я тоже подпишусь, так что нас уже двое :)

Что лично меня раздражает в Хаскеле, так это лексика и синтаксис. Хоть убей не пойму, как его можно назвать простым? Все эти лексемы типа «::», «:l», «++» (для бинарного оператора), «@», «$» и тому подобный мусор совсем не способствуют восприятию неофитами кода на Хаскеле. Я понимаю код на Схеме, Немерле, ОКамле, вполне воспринимаю математическую нотацию (лямбда-исчисление, основы теории категорий). Но как только вижу статью про Хаскель (да вот хотя бы твои посты на Хабре) — так сразу глаза и мозг возмущаются, глядя на это синтаксическое недоразумение. Сколько раз открывал книжки Душкина, чтоб таки проникнуться — раз за разом неодолимое отторжение.

Извините. Не удержался. Минусуем.
Глаза у меня добрые, но рубашка — смирительная!
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 30.01.09 16:27
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


VE>>"ФП (Хаскель) не панацея" слышно только от тебя.


Q>Не только от Влада, я тоже подпишусь, так что нас уже двое 


Ты бы моё сообщение до конца дочитал что ли.

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

— Вот вы говорите ФП панацея
— Простите, я говорю?
— Хорошо, не говорите, думаете. А между тем...

Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 30.01.09 16:42
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>кто тут говорит, что ФП панацея?


Thesz. Я несколько раз слышал (в смысле, читал) от него фразу, которая однозначно может трактоваться как «Хаскель — серебряная пуля».
Например, здесь есть ссылка на пост «Серебряная пуля есть» (правда, это не совсем та ссылка, что я искал, т. к. по ней не только Хаскель, но ещё и Ырланг серебряная пуля).

Хотя, возможно, ты скажешь, что «серебрянная пуля» и «панацея» в данном контексте два совершенно различных понятия.
Глаза у меня добрые, но рубашка — смирительная!
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 16:54
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Я могу говорить только за себя. Так вот, впечатление обманчивое. У меня, например, впечатление, что когда я говорю о преимуществах Хаскеля, то ты воспринимаешь это как замечания об отсутствии преимуществ у других языков. Возможно это особенности интернет-общения — или говоришь долго, чтобы точнее передать мысль и тогда все докапываются до отдельных её кусков, или говоришь кратко, но это выглядит категорично.


Может быть...

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


L>Чем модули не устраивают, поясни.


А причем тут модули? Я говорю о компонентном подходе. Когда можно в работающем приложении подгружать разные компоненты и получать разное поведение. Когда можно иметь дизайнер аналогичный дизайнеру WPF и т.п.

L>Ленивость нет, но non-strictness — обязательное свойство безкомпромисного ФП, ага. Лямбда исчисление и "функция в математическом смысле", никуда не денешься!


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

L>Кстати, я тоже не предлагал использовать Haskell без оглядки на задачи и условия,


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

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


А откуда тогда разговоры о Хаскеле взялись в этой теме? А как он появился в теме переписывания кода с С на Шарп?
Я что это все придумал?

VD>>А посмотри что вы вытворяете?... Парень спрашивает как ему С на C# перевести, а ему отвечают, что есть такая замечательная штука как экстер-си в С++ и Хасклевый экспорт. Это вообще вменяемый ответ?


L>Где я такое писал??


Ты очень часто оказываешся рядом с теми кто это начинает и вольно или не вольно поддерживаешь почин. Вот эта тема отличный тому пример. Не ты, наверно, свернул ее к Хаскелю, но ведь кто-то свернул?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.09 16:55
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>"ФП (Хаскель) не панацея" слышно только от тебя. И несмотря на то, что каждый раз тебе отвечают "ну... да, а это к чему?", всё равно ты никак себя не убедишь. И всё-то тебе кажется, что остальные говорят обратное. Чудной ты человек.


Как раз таки нет. Не то что отвечают. Переодически заявляют, что самая, что ни на есть панацея.
Понятно, что не все. Но есть товарищи...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 30.01.09 20:04
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


VE>>кто тут говорит, что ФП панацея?


Q>Thesz. Я несколько раз слышал (в смысле, читал) от него фразу, которая однозначно может трактоваться как «Хаскель — серебряная пуля».


Вот, от него я тоже такое слышал. Осталось понять, почему всех остальных тоже под одну гребёнку.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.02.09 10:33
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Чем модули не устраивают, поясни.

VD>А причем тут модули? Я говорю о компонентном подходе. Когда можно в работающем приложении подгружать разные компоненты и получать разное поведение.

Всё таки я не понимаю, где здесь проблемы. Есть возможность подгружать код, есть возможность использовать разные типы данных, получая разную функциональность. Раскроешь?

VD>Когда можно иметь дизайнер аналогичный дизайнеру WPF и т.п.


Я совершенно не в теме насчёт WPF. Если ты про ad-hoc полиморфизм, то он есть в Haskell.

L>>Ленивость нет, но non-strictness — обязательное свойство безкомпромисного ФП, ага. Лямбда исчисление и "функция в математическом смысле", никуда не денешься!

VD>Не бывает ничего бескомпромиссного. Хаскелевская бескомпромиссность — это компромиссы в других местах.

Само собой, я говорю о бескомпромиссности в смысле сияюще чистого ФП

VD>Лично по мне так чем дальше инструмент от математического смысла, тем лучше.


Это вопрос культуры. Они у нас разные, скорее всего из-за инструментов. Я пользуюсь несколько другими паттернами при написании кода на Haskell. Например, твоя функция fillDic — скорее всего, она у меня была бы написана по другому из-за близости инструмента к математике. Объяснить быстро не получится, а долго — много писать. В общем, это тема отдельного поста.

L>>Кстати, я тоже не предлагал использовать Haskell без оглядки на задачи и условия,

VD>Возможно такое ощущение складывается когда "слышишь какофонию" получающуюся в результате всех высказываний. Но иногда ощущение, что Хаскель предлагают использовать для всего.

Я понимаю, но быть черезчур корректным в своих высказываниях, постоянно подчёркивая граничные условия, субъективность высказывания и прочие ограничения не хочется. Получится не коммент, а одни оправдания. Я, например, надеюсь, что sapienti sat.

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

VD>А откуда тогда разговоры о Хаскеле взялись в этой теме? А как он появился в теме переписывания кода с С на Шарп?
VD>Я что это все придумал?

Насколько я понимаю из сути статьи — ФП для императивщиков (переписывание с С на Шарп я не нашёл ).
Вот как это получилось:

eao197: "Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?"
Ты: "Из практики чтения чужого кода. Поверь, не малой практики."
thesz: "Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых."
Ты: "Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный."
EvilChild: "Как здесь недавно совершенно верно заметили на чистом ФЯ вполне можно программировать императивно."
LaPerouse: "Более того, на чистом ФЯ нужно программировать императивно (нужно == приходится). Вопрос — нахрена тогда чистый ФЯ."
Тут я (первое упоминание Haskell) с дурацкой шуточкой.
Затем мы с LaPerouse обсуждаем императив на чистых ФЯ.

Вот такая игра в ассоциации

VD>>>А посмотри что вы вытворяете?... Парень спрашивает как ему С на C# перевести, а ему отвечают, что есть такая замечательная штука как экстер-си в С++ и Хасклевый экспорт. Это вообще вменяемый ответ?

L>>Где я такое писал??
VD>Ты очень часто оказываешся рядом с теми кто это начинает и вольно или не вольно поддерживаешь почин. Вот эта тема отличный тому пример. Не ты, наверно, свернул ее к Хаскелю, но ведь кто-то свернул?

Все мы люди-человеки.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.02.09 11:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Почитал. Действительно, хорошая задача для демонстрации ФП подхода, но я пока не уверен, что хочу её делать. Скорее всего я буду писать что то своё.

VD>Вот если бы ФП можно было легко использовать в Шарпе или Яве, то они может и попробовали бы при наличии внятного объяснения. А так... Не ужели не ясно, что Хаскель и Схема совершенно "враждебын" человеку писавшему до этого только на С++ или Паскале?


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

VD>Лично я считаю, что огромная заслуга авторов Скалы и Немерла именно в том, что они смогли поместить полноценные ФЯ в облик ООЯ с привычным синтаксисом. О ЛИНК-е вообще даже говорить не чего. Это просто кусок ФП прямо во вдоску императивном языке.


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

VD>Ну, ты не видишь, что ли, что ты один из тысячи кто дошел к вершине этого, казалось бы, не высокого холмика? Или ты как еао187 считашь, что проблем с пониманием ФП нет как класс?


Я во-первых только иду Во-вторых, насчёт тысячи. Я аналогию не очень понял — я один дошёл, а тысяча осталась позади, или всего тысяча дошла?

Мы же говорим о тысячах, интересующихся ФП? Тех, что пришли к Булату понять насколько он им нужен и как его применять?

Они потому и пришли, что проблемы с пониманием ФП есть, именно их я и пытаюсь понять в этой дискуссии. Мне интересно, как помочь этим тысячам и себе в их числе.

А! Ещё вот что подумал (в конце концов мы же в философии!). Обычно как идёт получение нового знания? Сначала мы чего то не знаем, потом это узнаём, начинаем применять, затем формализуем. Затем эту формализацию даём, а нам говорят: сухо, мутно, наукообразно. Люди (предположительно, большинство) не хотят получать формализованные знания. Твой подход: сначала нужно дать среднее между этапами "узнаём-применяем", чтобы они "въехали". Этап Булата — "применяем" (минус: скачок с этапа "не знаем", плюс: полезно, для тех, кто уже знает и им надо набить руку). Затем, наверное, они сами будут искать формализацию полученных знаний, пытаться их систематизировать. Это предположение сделано на основе моего опыта. Как-то так.

L>>Мой опыт говорит, что это не так. Знакомые мне ФП программисты вовсе не впечатлительные и доверчивые — это умные и интересные люди.

VD>Это разные люди. Но многие прагматичные и весьма не глупые люди так и не освоили ФП. Хотя многие из них и хотели этого всей душой.

Причины могут быть разные — время, например, даже элементарное не осилил". Но, вполне возможно, что материалы по ФП вызвали отвращение. Это надо их спрашивать.

L>>Насчёт того, что надо объяснять как мыслить — полностью согласен.

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

Ну как же! Я когда ФП учил массу таких статей, постов читал. Возьми, например, Functional Pearls Ричарда Бёрда. Из русского — на софткрафте была статья про декларативное программирование. Частично тот же Why FP matters. У Вадлера читал пару таких статей. Там, по большому счёту надо понять, что не фиг писать "сначала это, потом то". Надо сразу объявлять что есть что. У меня этот переход занял около двух недель. Но я тугодум.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.02.09 22:28
Оценка:
Здравствуйте, VoidEx, Вы писали:

Q>>Thesz. Я несколько раз слышал (в смысле, читал) от него фразу, которая однозначно может трактоваться как «Хаскель — серебряная пуля».


VE>Вот, от него я тоже такое слышал. Осталось понять, почему всех остальных тоже под одну гребёнку.


Потому что вы обычно выступаете как единая команда. Вот ты найдешь хотя бы одну ссылку когда бы ты возразил на подобные заявления поклонников хаскеля?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.02.09 22:39
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Ну не знаю. Я лично слышал "ФП — серебряная пуля" только от thesz. Только знаешь в каком смысле (не с потолка смысл пишу, у него есть пояснение)? Что по совокупности всех факторов Хаскель предпочтительнее всего остального. Ты говоришь абсолютно то же самое, разница только в языке.


Где я такое говорил? Не надо мне приписывать того что я не говорил.

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


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

Немерле лучше окружающий только в конкретных условиях и при конкретных предпочтениях. Точно так же как Хаскель, ОКамл, ФШарп и т.п. Лично для меня Немерле оптимальный выбор. Я сто раз описывал причины этого. Могу описать в 101-ый раз, если это интересно. Тот же Хаскель для меня вообще не средство разработки по причины медленности и отсуствия интеграции с дотнетом. Но это для меня. И я никогда не говорил о полном и тотальном превосходстве.

VE>Поэтому можно сказать разве что так: для меня при моих задачах и условиях, язык <имярек> является серебряной пулей.


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

VE>Если же начинать рассуждать, что "естественно я подразумевал себя и свои задачи", то так можно до чего угодно договориться.


Ну, пока кто-то не говорит, что Х лучше при любых условиях (пример мы тут все видели), то это его предпочтения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.02.09 22:57
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Почитал. Действительно, хорошая задача для демонстрации ФП подхода, но я пока не уверен, что хочу её делать. Скорее всего я буду писать что то своё.


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

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


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

VD>>Лично я считаю, что огромная заслуга авторов Скалы и Немерла именно в том, что они смогли поместить полноценные ФЯ в облик ООЯ с привычным синтаксисом. О ЛИНК-е вообще даже говорить не чего. Это просто кусок ФП прямо во вдоску императивном языке.


L>Вот уж насчёт синтаксиса я совершенно не согласен. Думаю, заслуга именно в гибридности языка.


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

Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.

VD>>Ну, ты не видишь, что ли, что ты один из тысячи кто дошел к вершине этого, казалось бы, не высокого холмика? Или ты как еао187 считашь, что проблем с пониманием ФП нет как класс?


L>Во-вторых, насчёт тысячи. Я аналогию не очень понял — я один дошёл, а тысяча осталась позади, или всего тысяча дошла?


Первое. Плюс — это гипербола. Не надо понимать мои слова буквально.

L>Мы же говорим о тысячах, интересующихся ФП? Тех, что пришли к Булату понять насколько он им нужен и как его применять?


L>Они потому и пришли, что проблемы с пониманием ФП есть, именно их я и пытаюсь понять в этой дискуссии. Мне интересно, как помочь этим тысячам и себе в их числе.


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

L>А! Ещё вот что подумал (в конце концов мы же в философии!). Обычно как идёт получение нового знания? Сначала мы чего то не знаем, потом это узнаём, начинаем применять, затем формализуем. Затем эту формализацию даём, а нам говорят: сухо, мутно, наукообразно. Люди (предположительно, большинство) не хотят получать формализованные знания. Твой подход: сначала нужно дать среднее между этапами "узнаём-применяем", чтобы они "въехали". Этап Булата — "применяем" (минус: скачок с этапа "не знаем", плюс: полезно, для тех, кто уже знает и им надо набить руку). Затем, наверное, они сами будут искать формализацию полученных знаний, пытаться их систематизировать. Это предположение сделано на основе моего опыта. Как-то так.


Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?

VD>>Это разные люди. Но многие прагматичные и весьма не глупые люди так и не освоили ФП. Хотя многие из них и хотели этого всей душой.


L>Причины могут быть разные — время, например, даже элементарное не осилил". Но, вполне возможно, что материалы по ФП вызвали отвращение. Это надо их спрашивать.


Надо.

L>>>Насчёт того, что надо объяснять как мыслить — полностью согласен.

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

L>Ну как же! Я когда ФП учил массу таких статей, постов читал. Возьми, например, Functional Pearls Ричарда Бёрда. Из русского — на софткрафте была статья про декларативное программирование. Частично тот же Why FP matters. У Вадлера читал пару таких статей. Там, по большому счёту надо понять, что не фиг писать "сначала это, потом то". Надо сразу объявлять что есть что. У меня этот переход занял около двух недель. Но я тугодум.


Why FP matters я пробовал читать когда пытался въехать в ФП. Результат был — скепсис и непонимание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 01.02.09 23:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Q>>>Thesz. Я несколько раз слышал (в смысле, читал) от него фразу, которая однозначно может трактоваться как «Хаскель — серебряная пуля».


VE>>Вот, от него я тоже такое слышал. Осталось понять, почему всех остальных тоже под одну гребёнку.


VD>Потому что вы обычно выступаете как единая команда.


Пусть тебя это не вводит в заблуждение.

VD>Вот ты найдешь хотя бы одну ссылку когда бы ты возразил на подобные заявления поклонников хаскеля?


Ну ежели ты думаешь, что человек должен возражать каждый раз, когда он не согласен, то тогда твой вывод обоснован. Заодно можно понять и твоё рвение в спорах
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 02.02.09 04:33
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

VD>В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.


В случае OCaml'а сознание практически не ломается, а хаскель как я понимаю требует такой ломки, например я в нем "все понимаю но разговаривать не могу"
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 05:14
Оценка:
VE>>кто тут говорит, что ФП панацея?
Q>Thesz. Я несколько раз слышал (в смысле, читал) от него фразу, которая однозначно может трактоваться как «Хаскель — серебряная пуля».
Q>Например, здесь есть ссылка на пост «Серебряная пуля есть» (правда, это не совсем та ссылка, что я искал, т. к. по ней не только Хаскель, но ещё и Ырланг серебряная пуля).
Q>Хотя, возможно, ты скажешь, что «серебрянная пуля» и «панацея» в данном контексте два совершенно различных понятия.

Именно. "Серебряная пуля" — это средство, сокращающее труд программистов вдвое и больше. "Панацея" — это средство от всего.

См. определения.

Поэтому я никогда не говорил, что Хаскель — панацея.

А вот весело и с шиком провести программистское время с помощью Хаскеля можно. Поскольку он "серебряная пуля", его можно заложить в ломбард.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 02.02.09 05:31
Оценка:
Здравствуйте, thesz, Вы писали:

T>Именно. "Серебряная пуля" — это средство, сокращающее труд программистов вдвое и больше. "Панацея" — это средство от всего.


То есть смена стиля программирования и использование правильных библиотек это тоже серебряная пуля?
Например я на C++ или тем более питоне используя разные стили могу спокойно в два или даже более раз
сократить свой труд.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.02.09 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?


Ммм, ты вот про это
Автор: LaPerouse
Дата: 29.01.09
:

Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.

Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 08:22
Оценка:
Здравствуйте, thesz, Вы писали:

T>Именно. "Серебряная пуля" — это средство, сокращающее труд программистов вдвое и больше.


Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.
Глаза у меня добрые, но рубашка — смирительная!
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 02.02.09 08:41
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.


Если под NET используется F# или Nemerle конечно сомнительно. Если же Шарп то по моему все таки Хаскель намного более выразительный язык.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 02.02.09 10:06
Оценка:
Здравствуйте, Курилка, Вы писали:

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


VD>>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?


К>Ммм, ты вот про это
Автор: LaPerouse
Дата: 29.01.09
:


К>

К>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.


Ну сделать ее чисто иммутабельной я и не пытался, да и делать такое в условиях java было бы безумием. Я просто внес в схему такие изменения, которые позволили бы создать иммутабельные интерфейсы к ней. С сохранением прежних мутабельных. В результате я теперь могу с ней работать двояко: иммутабельно и мутабельно. Иммутабельных алгоритмов у меня немного, ибо они адски дороги на java, ну нет здесь чудесных функциональных мапов с логарифмическим временем добавления. Но изменения, которые я внес в схему, сделали более прозрачными и императивные алгоритмы.

Таким образом, что я сделал:

1. Снес понятие идентити для нод. Теперь ноды (INode) — это только значения (с идентификатором). До этого нода имела обратную ссылку на Pin элемента, а пин элемента — ссылку на ноду. Теперь ссылка только в одну сторону от пина к ноде, которая, повторюсь, является значением без identity. Правда, пришлось учесть это в алгоритмах, которые полагались на instance ноды, например, оперировали с hashCode экземпляра ноды, теперь это заменено на node.isEqual по идентификтору.
2. Благодаря пункту 1 достаточно легко делается копирование схемы и участков схем.
3. Иммутабельные интерфейсы реализованы через getCopy() для схемы. То есть бекэндом идут те же самые императивные интерфейсы, которые создают копию, изменяют ее и возвращают. Они адски дороги, поэтому используются только в одном месте, где изменение на месте выливается совсем в хреновую кашу.

P.S. Почему-то VladD2 считает меня эдаким прожженным императивщиком, адептом императивного хардкода. Почему он так считает и из каким моих постов в этой теме можно сделать такой вывод абсолютно не понятно. Таким я был, возможно, два года назад, но вот уже больше года я признаю большие преимущества функционального подхода. Другое дело, я считаю, что все хорошо в меру.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 11:13
Оценка:
LP>Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.

И они правы. Яйцо с надломленным кончиком нельзя высидеть.

Нарушен, практически, базовый иинвариант яйца.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 11:20
Оценка:
T>>Именно. "Серебряная пуля" — это средство, сокращающее труд программистов вдвое и больше.
Q>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.

По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.

Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.

Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 11:29
Оценка:
Q>>>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.
FR>>Если под NET используется F# или Nemerle конечно сомнительно. Если же Шарп то по моему все таки Хаскель намного более выразительный язык.
Q>Да, в том-то и дело, на производительность программиста влияет не только язык, а вся связка язык + библиотеки + рантайм, то есть в моём случае .NET-языки + FCL + CLR.

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

Q>1) ЯП. Я не ограничен одним языком, могу один проект писать на C# (привычнее), соседний проект на F# (немного мощнее), тривиальный интероп (а не всякие адские байндинги через Си). Со следующей версии Студии F# будет иметь поддержку инфраструктуры: визарды, code-behind для GUI- и веб-проектов, etc.


Процент кода в твоем проекте, написанный на F# конкретно каков?


Q>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».


Юниксы предоставляют, всё же, не меньше, а как бы и не больше всего.

Q>3) Рантайм. В этот пункт можно включить производительность, переносимость, особенности сборки мусора, утечки ленивых цепочек, etc.


Q>Ну и плюс некоторые другие параметры: документация, IDE, организованность сообщества, поддержка от производителя, etc.


Haskell поддерживается Майкрософтом, не забывай.

Q>По совокупности имеющейся информации о Хаскеле пока что я не могу сделать вывод о «вдвое и больше». Разве что так: «возможно, существует узкий круг задач, для которых производительность программиста на Хаскеле вдвое выше, чем .NET-программиста». Но никак не «для большинства задач Хаскель предоставляет прирост в производительности вдвое и больше».


Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств. Более того, в общем и целом количество пользы для конечного пользователя от использования Хаскеля возрастает — можно реализовать больше фич.

Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 11:39
Оценка:
Здравствуйте, thesz, Вы писали:

T>По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.


В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки. Кстати, опиши вкратце методологию получения результата «скорость разработки у них такая же, как у программистов на Java». Т. е. что значит «по общению»? Или иначе: по каким признакам в общении можно сравнить эффективность разработчиков?

T>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.


T>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?


Скажи я про «долю в современных проектах» в отношении Хаскеля, ведь немедленно бы поднялся хай в духе «ну и что, мы не из миллиона мух, которые не ошиблись!» Так что давай про долю не надо. Эта доля, кстати, заметно повысится (прогноз, ага) с добавлением F# «в коробку».
Глаза у меня добрые, но рубашка — смирительная!
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 12:07
Оценка:
Здравствуйте, thesz, Вы писали:

T>В конечном счёте все определяется количеством строк, которые необходимо написать


Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

Q>>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».


T>Юниксы предоставляют, всё же, не меньше, а как бы и не больше всего.


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

T>Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств.


Заливать файлы на FTP приходится, как ты эту задачу не переформулируй. И общаться с базой данных, и создавать GUI, etc. У меня создаётся впечатление, что когда говорят об «абстрактной усреднённой задаче», у тебя в голове возникает какой-нибудь компилятор, который ты можешь показательно накидать на Хаскеле за пару минут. Ну переформулируй задачу «написать файловый менеджер» или «создать клиент для Джаббера» так, чтобы «производительность программиста на Хаскеле будет максимальной по сравнению с использованием других формулировок и средств». Должно быть, под «задачей» ты имеешь в виду что-то другое, тогда уточни.

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


Больше фич по сравнению с чем? Почему — больше? Обоснуй.
Глаза у меня добрые, но рубашка — смирительная!
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 02.02.09 12:12
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.


T>И они правы. Яйцо с надломленным кончиком нельзя высидеть.


T>Нарушен, практически, базовый иинвариант яйца.


Может быть, но тут соль не в инвариантах. Речь о том, может ли считаться измененный объект, пусть и остающийся в пределах своих инвариант, новым объектом, или это суть старый объект. Различие между ФП и ИП уходят корнями в этот вопрос, а все остальное — следствие.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 15:36
Оценка:
T>>И они правы. Яйцо с надломленным кончиком нельзя высидеть.
T>>Нарушен, практически, базовый иинвариант яйца.
LP>Может быть, но тут соль не в инвариантах. Речь о том, может ли считаться измененный объект, пусть и остающийся в пределах своих инвариант, новым объектом, или это суть старый объект. Различие между ФП и ИП уходят корнями в этот вопрос, а все остальное — следствие.

Объект можно менять функционально, если он линеен (уникален в смысле "uniqueness types" Clean — на него одна ссылка).

И вообще, Lambda — the ultimate imperative!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 16:42
Оценка:
T>>В конечном счёте все определяется количеством строк, которые необходимо написать
Q>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

Ты что-то с чем-то путаешь, по-моему.

Если я попытаюсь угадать твою мысль и ответить на неё, то да, запись
bracketed open close parser = rule id <* open <*> parser <* close

короче, чем
bracketed open close parser = do
   open
   x <- parser
   close
   return x


Да и наглядней, надо сказать.

Q>>>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».

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

Нет. Есть куча специальных программ, по одной на каждое действие.

T>>Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств.

Q>Заливать файлы на FTP приходится, как ты эту задачу не переформулируй. И общаться с базой данных, и создавать GUI, etc. У меня создаётся впечатление, что когда говорят об «абстрактной усреднённой задаче», у тебя в голове возникает какой-нибудь компилятор, который ты можешь показательно накидать на Хаскеле за пару минут.

As I used to explain students on the first lecture of my old (IBM/360-oriented) "Compiler construction" course, this topic of computer science has much wider practical significance than one can expect just from the name of course. Actually compiler design is a pretty powerful programming paradigm (i.e. structuring the programming system as if it were a compiler for some new language) and more widespread usage of this paradigm might have substantial benefits. <b>To say it in other words this is programming technology applicable to a wide range of programming tasks.</b>

Выделено автором.

Q>Ну переформулируй задачу «написать файловый менеджер» или «создать клиент для Джаббера» так, чтобы «производительность программиста на Хаскеле будет максимальной по сравнению с использованием других формулировок и средств». Должно быть, под «задачей» ты имеешь в виду что-то другое, тогда уточни.


Я могу заливать файлы с помощью библиотеки, а могу с помощью ftp через скрипт. Последнее ещё и проще в отладке, поскольку создание скрипта достаточно декларативно.

Файловый менеджер у Булата Зиганшина во FreeArc, практически. На Хаскеле.

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

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

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

Q>Больше фич по сравнению с чем?

С Java. С C#.

Q>Почему — больше?


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

Q>Обоснуй.


Вот.

Я сейчас скажу совсем страшную вещь. Её мало, кто понимает вообще.

Все могут использовать закачку файлов на ftp. Все могут использовать клиент к Джабберу. Все имеют доступ к необходимому для реализации файлового менеджера API.

У одних это проще, у других это сложней. Разница не настолько принципиальна, я виндовый GUI с drag-n-drop писал на ассемблере.

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

(в случае клиента Джаббера — что мой клиент будет давать сверх того, что дают остальные?)

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

А вот быстрота достижения цели стоит на повестке дня. Высказанная вслух убедительная идея может быть неверна, её обязательно надо проверить экспериментально. Заодно будет проработана теория предметной области, которая практически всегда известно недостаточно полно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 16:52
Оценка:
T>>По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.
Q>В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки.

Нет, это "попало в .Net недавно и не успело стать ещё широко используемым."

Q>Кстати, опиши вкратце методологию получения результата «скорость разработки у них такая же, как у программистов на Java».


Я не проводил измерения. Но скорость работы программистов не отличается даже в полтора раза.

Q>Т. е. что значит «по общению»?


Так, поговорили. Мне рассказали, я рассказал.

Q>Или иначе: по каким признакам в общении можно сравнить эффективность разработчиков?


Когда тебе рассказывают про конкурентов, например: "У конкурентов Java, и вот они писали столько-то. Мы справились быстрее, но у нас нет десяти их фич, но есть одна наша."

T>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.

T>>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?
Q>Скажи я про «долю в современных проектах» в отношении Хаскеля, ведь немедленно бы поднялся хай в духе «ну и что, мы не из миллиона мух, которые не ошиблись!» Так что давай про долю не надо. Эта доля, кстати, заметно повысится (прогноз, ага) с добавлением F# «в коробку».

Почему не надо?

Ты рассматриваешь .Net, как набор языков. Из которых F# самый мощный и активно продвигается поставщиком платформы. Я на это дело смотрю ровно так же.

Haskell это отдельный продукт, его никто не продаёт в нагрузку. До него ещё дорасти надо. Надеюсь, теперь ты на Хаскель смотришь так же.

Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?

А планируешь ли ты на нём писать? А что планируешь писать?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 17:55
Оценка:
Здравствуйте, VoidEx, Вы писали:

VD>>Вот ты найдешь хотя бы одну ссылку когда бы ты возразил на подобные заявления поклонников хаскеля?


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


Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 18:08
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

Вот количество ошибок и правда влияет на скорость создания законченного решения. Так как на их исправление может уйти больше время чем на написание кода. Именно по этому С++ серьезно проигрывает даже Яве (явно более ограниченной в выразительных возможностях по сравнению с С++). Причем загадки никакой тут нет. Просто Ява обеспечивает типобезопасность и сборку мусора. Этого достаточно чтобы сильно обогнать С++ по скорости получения рабочего решения.

T>Процент кода в твоем проекте, написанный на F# конкретно каков?


В моих современных проектах 98% кода пишется на... ну вы сами знаете на чем .

T>Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп.


Ну, так и на других языках можно делать точно так же. Причем в Лиспе и Немерле (как в прочем в Темплэйт Хаскеле) есть боле мощьные средства ДСЛ-естроения, которые позволяют создавать ДСЛи практически любой сложности и не иметь ограничений в области производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 18:29
Оценка:
Здравствуйте, thesz, Вы писали:

T>Ты рассматриваешь .Net, как набор языков. Из которых F# самый мощный и активно продвигается поставщиком платформы. Я на это дело смотрю ровно так же.

T>Haskell это отдельный продукт, его никто не продаёт в нагрузку. До него ещё дорасти надо. Надеюсь, теперь ты на Хаскель смотришь так же.
T>Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?
T>А планируешь ли ты на нём писать? А что планируешь писать?

Ты прав в том что кода на F# катастрофически мало. Но с чем то связано? Мой список (по возрастанию значимости):
1. До сих пор интеграция F# со студией ниже плинтуса.
2. Язык, как и Хаскель, совсем не похож на привычные массам императивные языки. Намного проще выучить Яву после Дельфи или наоборот нежели выучить F# или Хаскель после Явы, Шарпа, С++, Дельфи и т.п.
3. F# очень плохо интегрируется с основой платформой так как его система типов (основанная на Хидли-Милере) сильно отличается от системы типов дотнета.

При этом F# не является самым мощным языком дотнета. Скажем его средства ДСЛ-естроения примитивны. А поддержка того же LINQ-а ниже плинтуса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 18:40
Оценка:
Здравствуйте, FR, Вы писали:

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


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

FR>Вот то что нужно "доучить" как раз и сложно.

Дык разница между синтаксисом и семантикой С и Паскаля очень незначительная. Разница фактически описывается примитивными подстановками. А вот разница с ОКамлом получается очень значительная.

Мои наблюдения за людьми которые изучали F# и Немерле показали, что Немерле ими воспринимался намного проще и быстрее. Более того после знакомства с Немерле F# воспринимался уже намного проще, так как разница действительно оказывалась же почти в одном синтаксисе.

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

VD>>В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.


FR>В случае OCaml'а сознание практически не ломается, а хаскель как я понимаю требует такой ломки, например я в нем "все понимаю но разговаривать не могу"


Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 18:43
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Ммм, ты вот про это
Автор: LaPerouse
Дата: 29.01.09
:


К>

К>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.


Ты почитай все что вокруг. По-моему все очевидно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.09 18:44
Оценка:
Здравствуйте, FR, Вы писали:

FR>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен


Ага примерно так же как поклонники Питона пишущие на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: "LINQ как шаг к ФП". Стиль изложения.
От: MasterZiv СССР  
Дата: 02.02.09 19:48
Оценка:
eao197 пишет:

О чем тут спорите, ещё вообще помнит кто-то ?

> E>>PS. Из статьи можно было бы смело выкинуть, как минимум, 1/3 текста

> при сохранении той же информативности.

Ну кстати да. Экскурсы в недостатки делегатов и историю развития C# можно
было бы выкинуть смело, без потерь для основной цели статьи. Хотя конечно
было интересно.

Если ещё не позно, и нужно, я бы сказал ещё, что хорошо бы после введения
в чистые функции упомянуть, что весь функциональный мир делится на
две категории: кто ЗА чистые функции, и кто НЕ ЗА (а даже наоборот, против),
и, что главное, нечистота функций ничуть не мешает применять те достоинства ФП,
о которых идёт речь в статье, а мешает лишь только произвольному
распараллеливанию вычислений в произвольном месте.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: MasterZiv СССР  
Дата: 02.02.09 19:55
Оценка:
VladD2 пишет:

> Дык разница между синтаксисом и семантикой С и Паскаля очень

> незначительная.

Влад, ты ГЛУБОКО неправ. Паскаль — очень строго типизированный язык.
С — в С переменная того типа, о котором думает программист в процессе
написания программы.

С — модульный язык, Паскаль — нет.
Синтаксис — в общем пофигу, но в паскале строго всё разложено
по секциям, в С — где что напишешь,то и будет.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.02.09 19:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


К>>Ммм, ты вот про это
Автор: LaPerouse
Дата: 29.01.09
:


К>>

К>>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.


VD>Ты почитай все что вокруг. По-моему все очевидно.


Т.е. то, что он сам не считает твоё мнение о себе верным на тебя никак не влияет? Забавно
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 20:20
Оценка:
VD>>Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.

FR>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен


Это вы про меня, что ли? Я нить утерял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 20:27
Оценка:
T>>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения.
VD>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.

Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками.

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

VD>Вот количество ошибок и правда влияет на скорость создания законченного решения. Так как на их исправление может уйти больше время чем на написание кода. Именно по этому С++ серьезно проигрывает даже Яве (явно более ограниченной в выразительных возможностях по сравнению с С++). Причем загадки никакой тут нет. Просто Ява обеспечивает типобезопасность и сборку мусора. Этого достаточно чтобы сильно обогнать С++ по скорости получения рабочего решения.


Не могу не согласиться.

T>>Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп.

VD>Ну, так и на других языках можно делать точно так же. Причем в Лиспе и Немерле (как в прочем в Темплэйт Хаскеле) есть боле мощьные средства ДСЛ-естроения, которые позволяют создавать ДСЛи практически любой сложности и не иметь ограничений в области производительности.

Да-да.

Единственное, что скорость создания этого самого DSEL будет для Хаскеля повыше. Поэтому им и пользуются умные люди. Не все, но умные.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 20:31
Оценка:
VD>При этом F# не является самым мощным языком дотнета. Скажем его средства ДСЛ-естроения примитивны. А поддержка того же LINQ-а ниже плинтуса.

Всё это подводит нас к интересной проблеме.

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

Поэтому принято советовать F#/Nemerle для .Net, Scala для Java, OCaml для обычного кода.

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

Потому, что связку разнородных компонент делали уже не раз и риск низок, а вот что-то новое делают всегда впервые — и риск высок.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 20:32
Оценка:
Здравствуйте, thesz, Вы писали:

Q>>В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки.


T>Нет, это "попало в .Net недавно и не успело стать ещё широко используемым."


Да уж три года как появилось в C# 2.0, и уже используется большинством C#-программистов. Нормальный синтаксис лямбда-выражений и LINQ появились больше года назад.

T>Я не проводил измерения...

T>Так, поговорили. Мне рассказали, я рассказал.

Ага, понятно. Спроси ещё этих ребят, как они относятся к программированию на Хаскеле. Они ответят: «Э-э-э... На чём?»

T>>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.


Всё самое полезное попало в Хаскель уже давно и... ещё не успело стать широко используемым.

T>>>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?


Уже через год после выхода в составе Студии его доля будет превышать долю Хаскеля, неторопливо формировавшуюся последние 20 лет (или сколько там лет Хаскелю?)

T>Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?


Я не пишу в данный момент на F#. Не в последнюю очередь из-за того, что он ещё не так «легко доступен», как хотелось бы.

T>А планируешь ли ты на нём писать? А что планируешь писать?


Да, планирую. Всякие второстепенные вещи (прототипы, внутрикорпоративные тулзы), с целью попрактиковаться «на кошках».
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 02.02.09 20:45
Оценка:
Здравствуйте, thesz, Вы писали:

T>Всё это подводит нас к интересной проблеме.


Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 02.02.09 21:17
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>В конечном счёте все определяется количеством строк, которые необходимо написать

Q>>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

T>Ты что-то с чем-то путаешь, по-моему.


T>Если я попытаюсь угадать твою мысль и ответить на неё...


Моя мысль была такой. В качестве «псевдокода» в книжках по программированию можно использовать практически любой современный ЯП, потому что они спроектированы так, что их может понять не знакомый с синтаксисом читатель. «Практически любой», но только не Хаскель. Потому что у него из всех боков торчат коленки и локти типа «:%» или «$!»

T>Да и наглядней, надо сказать.


Вот это у меня и не получается понять. Да и не только у меня. По твоим словам, Хаскель простой и понятный язык. Но я открываю книжку Ромы Душкина и что я там вижу? Откровенно стрёмный синтаксис.

T>Нет. Есть куча специальных программ, по одной на каждое действие.


Ну да, юникс вэй. А как коллбэки передавать в «специальную программу», как исключения из неё перехватывать?

T><b>To say it in other words this is programming technology applicable to a wide range of programming tasks.</b>


T>Выделено автором.


Так что, на Хаскеле можно писать не только парсеры? Вау!

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


Мне известно, что ты занимался VHDL ещё минимум полтора года назад, т. к. неоднократно упоминал об этом в разных ЖЖ уже давно. Недавно это ещё и на RSDN упоминалось, когда некто gaperton выражал (не впервые) эм-м... некоторый скепсис в отношении целесообразности твоих VHDL-прототипов на Хаскель, ну да ладно. Я к тому, что много недель утекло с тех пор, должно быть целая уйма парсеров VHDL тобой уже написана.

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


А как это связано с Хаскелем — умение придумать причину, по которой закачка не нужна пользователям?

T>А вот быстрота достижения цели стоит на повестке дня.


Понимаешь, я никак не могу взять в толк, за счёт чего цель на Хаскеле достигается быстрее, чем, скажем, на Немерле? Тут такой замкнутый круг получается: чтобы проникнуться Хаскелем, надо вначале проникнуться Хаскелем. Но в действительности, чтобы проникнуться Хаскелем, нужна изначально какая-то мотивация. Что может служить мотивацией? Сейчас мне мотивацией служит исключительно любознательность, но даже она приходит в уныние, глядя на этот синтаксис...
Глаза у меня добрые, но рубашка — смирительная!
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.02.09 21:21
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Я пока не могу сказать "договорились", хотя и очень подмывает. Проблема в том, что сейчас у меня не очень много времени, а написать так быстро как ты я не смогу — мне надо разобраться с деталями, я не знаком с работой с XML на Haskell, у меня нет Windows, чтобы проверить результат, да и элементарно я медленнее думаю.

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


Тогда больше вероятности, что твоё мнение ближе к истине. Так как моя выборка нерепрезентативна — это народ с ru_lambda и т.д.

VD>Не понял твоего посыла про синтаксис, но синтаксис очень даже причем. Когда людям не приходится ломать привычки в области синтаксиса и семантики базовой части языка (или приходится, но не много), то им намного проще освоить сам ФП, так как для них ФП становится всего лишь новыми фичами которые нужно "доучить". В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.


Возможно, но ломка привычки в отношении синтаксиса — копейки.

VD>Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.


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

VD>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?


Ну, немного не так было, но смысл верный, да. Но! По своему опыту знаю, что я многого добился, если у LaPerouse зародилась хоть тень сомнения в своей правоте. А мне кажется, что так и есть.

VD>Why FP matters я пробовал читать когда пытался въехать в ФП. Результат был — скепсис и непонимание.


Из-за приведённых примеров? Или сам тезис о разбивании сложности с помощью ФВП?
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 22:49
Оценка:
T>>>>В конечном счёте все определяется количеством строк, которые необходимо написать
Q>>>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?
T>>Ты что-то с чем-то путаешь, по-моему.
T>>Если я попытаюсь угадать твою мысль и ответить на неё...
Q>Моя мысль была такой. В качестве «псевдокода» в книжках по программированию можно использовать практически любой современный ЯП, потому что они спроектированы так, что их может понять не знакомый с синтаксисом читатель. «Практически любой», но только не Хаскель. Потому что у него из всех боков торчат коленки и локти типа «:%» или «$!»

J, K, OCaml, you name it.

But I will return to the discussion when you grow up.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 22:50
Оценка:
T>>>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.
Q>Всё самое полезное попало в Хаскель уже давно и... ещё не успело стать широко используемым.

Okay, "grow up" check failed.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 02.02.09 22:51
Оценка:
T>>Всё это подводит нас к интересной проблеме.
VE>Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.

Я не понял тезиса.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 00:38
Оценка:
T>>Я не понял тезиса.
VE>Для записи решения задачи язык почти не важен.

Тогда почему математики постоянно изобретают языки? Зачем, вообще, такое количество ЯП?

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

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

VE>Новая задача, она новая везде, решить я её могу на "Хаскеле", а её решение записать потом на C#.

Ну, попробуй написать библиотеку работы с ленивыми степенными рядами. Чтобы памяти отъедалось не больше ленивого варианта, чтобы семантика была ленивой — вычислений было не больше, чем нужно.

Народ пишет, обычно, на массивах. Тоже вариант, но не самый лучший. Памяти расходуется больше, количество вычислений труднее проконтролировать да и просто — больше кода.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 03.02.09 06:13
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Я не понял тезиса.

VE>>Для записи решения задачи язык почти не важен.

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


Аналогия некорректна в виду того, что эта задача ни к чему не привязана. А когда тебе ставят задачу написать библиотеку для работы с ленивыми степенными рядами для платформы .NET, да ещё и классы описывают, которые ты должен предоставить, то, боюсь, выбор языка будет ограничен, хотя прототип можно будет написать на том, на чём удобнее.
Или ставят задачу написать некий алгоритм, входные данные для которого в виде объектов определённых классов из некоей библиотеки Си++ в исходниках. Можно, конечно, конвертать туда-обратно и в длл-ку заворачивать, но редко это стоит того.
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 08:04
Оценка:
T>>>>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения.
VD>>>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.
T>>Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками.
LP>Тут есть большая разница. Буква ять не несет никакой смысловой нагрузки и не способствует более быстрому пониманию текста, к тому же требует типографской краски.

Вопрос предпочтений.

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

То же самое и с буквой ять. У неё тоже были сторонники.

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

LP>А скобочки помогают воспринимать текст программы, что же касается "типографской краски", то есть в нашем случае скорости набора, то современные IDE, которыми оснащены эти самые языки со скобочками, расставляют скобочки автоматом.


"Ять способствует восприятию текста, а современные спеллчекеры вставляют ять автоматически," ага.

Я тебе снова дам ссылку про то, как Хаскель выигрывает (у меня все ссылки такие), но там, во-первых, общие мысли интересные и, во-вторых, кроме Хаскеля, есть сравнение и других ЯП между собой: Are Ours Really Smaller Than Theirs?

Там прямо на первой странице показан сравнительный "уровень" языков программирования по метрике Хальстеда, в которую входит учёт влияния лексем и всего такого ("синтаксический оверхед", насколько я понимаю). Assembler — 0,88, English prose — 2,16, PL/1 — 1,53. А у Хаскеля — 5,13. В частности, из-за отсутствия лишних скобочек, запятых и точек с запятой.

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

LP>Вот это совершенно непонятно. Каким образом это скобочки увеличат количество ошибок? По мне — они и количество ошибок при написании не увеличивают, и допущенные ошибки исправлять помогают, так как увеличивается читаемость.

Да они место занимают. Мог бы стоять пробел, а стоит скобка+пробел или запятая+пробел. А то и вовсе пустая строка под {}.

Тут мы сделали перенос строки из-за длинной строки, там мы его сделали... Перед компиляцией не всю (под)программу просмотрели — на запуск ушёл неправильный код. Начали искать ошибку — надо больше текста просмотреть. И тд, и тп.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 08:11
Оценка:
T>>Ну, попробуй написать библиотеку работы с ленивыми степенными рядами. Чтобы памяти отъедалось не больше ленивого варианта, чтобы семантика была ленивой — вычислений было не больше, чем нужно.
VE>Аналогия некорректна в виду того, что эта задача ни к чему не привязана. А когда тебе ставят задачу написать библиотеку для работы с ленивыми степенными рядами для платформы .NET, да ещё и классы описывают, которые ты должен предоставить, то, боюсь, выбор языка будет ограничен, хотя прототип можно будет написать на том, на чём удобнее.
VE>Или ставят задачу написать некий алгоритм, входные данные для которого в виде объектов определённых классов из некоей библиотеки Си++ в исходниках. Можно, конечно, конвертать туда-обратно и в длл-ку заворачивать, но редко это стоит того.

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

Например, я две недели буду писать классы для .Net, тщательно их проектируя — там одно умножение стоит многого. А могу за день написать это дело на Хаскеле и ещё четыре дня прикручивать через FFI с обеих сторон это дело к .Net. И справится за неделю, в сумме.

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

И чем думают начальники и архитекторы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 10:27
Оценка:
T>>Тут мы сделали перенос строки из-за длинной строки, там мы его сделали... Перед компиляцией не всю (под)программу просмотрели — на запуск ушёл неправильный код. Начали искать ошибку — надо больше текста просмотреть. И тд, и тп.
E>Детский сад.

Японцы именно так и улучшают свои автомобили — тут процент, там процент, ещё процент в этом месте...

Работает.

И называется это не только "детский сад", а ещё "крохоборство", "перфекционизм" или "интравертность" — на выбор.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 10:28
Оценка:
T>>Зачем, вообще, такое количество ЯП?
E>У всех существующих языков есть один фатальный недостаток: их делали не мы.
E>Со всеми вытекающими разнообразными последствиями от невозможности встроить фичу, которая нужна именно нам, до невозможности зарабатывания денег на средствах разработки и невозможности привязывания изрядной доли программистов к конкретной платформе.

Это как-то отменяет тезис о неравномощности ЯП?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.02.09 10:37
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Зачем, вообще, такое количество ЯП?

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

T>Это как-то отменяет тезис о неравномощности ЯП?


Тезиз о неравномощности ЯП очень косвенно соотносится с причинами возникновения и исчезновения большого количества ЯП. Поэтому неправомочно привлекать этот вопрос к обоснованию данного тезиса.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 10:54
Оценка:
E>>>Со всеми вытекающими разнообразными последствиями от невозможности встроить фичу, которая нужна именно нам, до невозможности зарабатывания денег на средствах разработки и невозможности привязывания изрядной доли программистов к конкретной платформе.
T>>Это как-то отменяет тезис о неравномощности ЯП?
E>Тезиз о неравномощности ЯП очень косвенно соотносится с причинами возникновения и исчезновения большого количества ЯП. Поэтому неправомочно привлекать этот вопрос к обоснованию данного тезиса.

Я настолько удивился, что у меня даже уши к макушке подтянулись.

Вот почему именно "Тезиз о неравномощности ЯП очень косвенно соотносится с причинами возникновения и исчезновения большого количества ЯП"? Ведь даже твоё высказывание его подтверждает, хоть и всего в одном из трёх твоих тезисов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: nikov США http://www.linkedin.com/in/nikov
Дата: 03.02.09 11:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>3. F# очень плохо интегрируется с основой платформой так как его система типов (основанная на Хидли-Милере) сильно отличается от системы типов дотнета.


Можно примеры плохой интеграции? А то мне что-то не встречалось такое.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 03.02.09 11:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык разница между синтаксисом и семантикой С и Паскаля очень незначительная. Разница фактически описывается примитивными подстановками. А вот разница с ОКамлом получается очень значительная.


Угу приличная, но база того же Ocaml'а (без объектов) по сути простой не сложнее паскаля язык.

VD>Мои наблюдения за людьми которые изучали F# и Немерле показали, что Немерле ими воспринимался намного проще и быстрее. Более того после знакомства с Немерле F# воспринимался уже намного проще, так как разница действительно оказывалась же почти в одном синтаксисе.


Угу и потом эти люди пишут страшный код на Немерли функциональщины в котором свершенно не наблюдается.

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


Не так уж резко.

VD>>>В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.


FR>>В случае OCaml'а сознание практически не ломается, а хаскель как я понимаю требует такой ломки, например я в нем "все понимаю но разговаривать не могу"


VD>Сдается мне, что ОКамл ты знаешь так же как и Хаскель.


Здравствуй Влад, я уже давно пишу небольшие свои проектики на Ocaml'е, единственное не использую объекты за ненадобностью. Я легко могу писать на Хаскеле как на фортране, тьфу как на Ocaml'е но смысла в этом не вижу.

VD>Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.


Угу с тобой все ясно, блабишь
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.02.09 11:14
Оценка:
Здравствуйте, thesz, Вы писали:

T>Я настолько удивился, что у меня даже уши к макушке подтянулись.


Ну я не настолько развит физически, как ты, поэтому так у меня не получается

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


Потому, что причин, толкающих людей на создание своих языков очень много. И вопрос мощности языка там всего лишь один из. Имхо, далеко не самый важный. Например, вопрос удобства для решения задач автора языка мне представляется гораздо более серьезным. Языки C, C++, Perl, Ruby, Java вряд ли были самыми мощными (с точки зрения языковых возможностей на тот момент), тем не менее, точком к их созданию явилось желание иметь удобный инструмент, необходимый авторам здесь и сейчас.

Если я не ошибаюсь, то история появления самого Haskell-я как раз является показателем того, как личные амбиции и коммерческие интересы явились точком к появлению Haskell-я. Если бы людей интересовало только мощность ЯП, то развитие получила бы Miranda.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 03.02.09 11:15
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен


VD>Ага примерно так же как поклонники Питона пишущие на С++.


Не питонщики они злые и агресивные
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 03.02.09 11:28
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>>Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.


FR>>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен


T>Это вы про меня, что ли? Я нить утерял.


Угу, пока высоким стандартам не удовлетворяешь
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 11:56
Оценка:
T>>Я настолько удивился, что у меня даже уши к макушке подтянулись.
E>Ну я не настолько развит физически, как ты, поэтому так у меня не получается

Мышцы-стабилизаторы ушей, развиваются приседаниями на ушах.

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

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

Сейчас проверим.

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


Что это, как не мощность?

E>Языки C, C++, Perl, Ruby, Java вряд ли были самыми мощными (с точки зрения языковых возможностей на тот момент), тем не менее, точком к их созданию явилось желание иметь удобный инструмент, необходимый авторам здесь и сейчас.


А это разве не мощность?

E>Если я не ошибаюсь, то история появления самого Haskell-я как раз является показателем того, как личные амбиции и коммерческие интересы явились точком к появлению Haskell-я. Если бы людей интересовало только мощность ЯП, то развитие получила бы Miranda.


Просто Миранда оказалась недостаточно мощной.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.02.09 13:17
Оценка:
MZ>Если ещё не позно, и нужно, я бы сказал ещё, что хорошо бы после введения
MZ>в чистые функции упомянуть, что весь функциональный мир делится на
MZ>две категории: кто ЗА чистые функции, и кто НЕ ЗА (а даже наоборот, против),
MZ>и, что главное, нечистота функций ничуть не мешает применять те достоинства ФП,
MZ>о которых идёт речь в статье, а мешает лишь только произвольному
MZ>распараллеливанию вычислений в произвольном месте.

А ещё мешают поддержке программ и создают проблемы с типизацией. Доказательство правильности алгоритма вывода типов ML со ссылками проводится отдельно, если что.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: Klapaucius  
Дата: 03.02.09 14:21
Оценка:
Здравствуйте, nikov, Вы писали:

VD>>F# очень плохо интегрируется с основой платформой так как его система типов (основанная на Хидли-Милере) сильно отличается от системы типов дотнета.

N>Можно примеры плохой интеграции? А то мне что-то не встречалось такое.

System.Console.WriteLine("--> {0} duplicate words", box(nDups))


В f# есть автобоксинг?
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: MasterZiv СССР  
Дата: 03.02.09 15:13
Оценка:
thesz пишет:

> А ещё мешают поддержке программ и создают проблемы с типизацией.

> Доказательство правильности алгоритма вывода типов ML со ссылками
> проводится отдельно, если что.

Я это к тому, что C# — далеко не чистый функциональный язык, и
вообще-то странно расписать достоинства ЧФП, а потом излагать
что-то про ФП на C#. Надо было написать, что это не очень и страшно.
Т.е. страшно или нет — дело десятое, а есть два подхода.
Posted via RSDN NNTP Server 2.1 beta
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.09 03:31
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>
K>System.Console.WriteLine("--> {0} duplicate words", box(nDups))
K>


K>В f# есть автобоксинг?


Еще интересно поглядеть на поддержку неявных приведений типов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 05:15
Оценка:
Здравствуйте, FR, Вы писали:

FR>Угу приличная, но база того же Ocaml'а (без объектов) по сути простой не сложнее паскаля язык.


Причем тут сложность? База OCaml — это ML. И он не то что бы сложный. Он совсем другой! Чтобы понять его нужно не просто составить мысленное отображение синтаксических элементов одного языка в синтаксические элементы другого. Для понимания этой базы прийдется менять сознание. По другому смотреть на вещи.

VD>>Мои наблюдения за людьми которые изучали F# и Немерле показали, что Немерле ими воспринимался намного проще и быстрее. Более того после знакомства с Немерле F# воспринимался уже намного проще, так как разница действительно оказывалась же почти в одном синтаксисе.


FR>Угу и потом эти люди пишут страшный код на Немерли функциональщины в котором свершенно не наблюдается.


Откуда ты это взял? У меня как раз обратная статистика.

FR>Здравствуй Влад, я уже давно пишу небольшие свои проектики на Ocaml'е, единственное не использую объекты за ненадобностью. Я легко могу писать на Хаскеле как на фортране, тьфу как на Ocaml'е но смысла в этом не вижу.


Тогда странно, что ты находишь огромную разницу между ним и Хаскелем.

VD>>Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.


FR>Угу с тобой все ясно, блабишь


Ну, типа сделал выпад. Молодец.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 05:18
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.


T>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.


T>Уж коли ты так хорошо во всём разобрался.


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

Ты хочешь сказать, что зная Хаскель и различие его с ОКамлом по синтаксису я не смогу читать код который не использует ООП ОКамла (который и правда сильно отличается от хаскелевского подхода)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 05:19
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.


T>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.


T>Уж коли ты так хорошо во всём разобрался.


Кстати, я не понял, чего ты радуешься? Человек высказал мысль о том, что Хаскель значительно сложнее ОКамла и что последний ему понятен, а первый нет. Ты по идее с ним должен спорить, а не со мной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 05:32
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Не понял твоего посыла про синтаксис, но синтаксис очень даже причем. Когда людям не приходится ломать привычки в области синтаксиса и семантики базовой части языка (или приходится, но не много), то им намного проще освоить сам ФП, так как для них ФП становится всего лишь новыми фичами которые нужно "доучить". В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.


L>Возможно, но ломка привычки в отношении синтаксиса — копейки.


Отнюдь не копейки. Есть масса людей которые программировали на Дельфи в 90-тые. Сейчас Дельфи не в фаворе. Разумно было бы перейти на C#, ведь язык очень близок по духу. Разница только в синтаксисе. Однако многие так и остаются на клонах Дельфи, так как учить эту разницу и нюансы сложно, а работать надо сейчас.

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

Собственно это факт. Не понимаю почему многие очень хотят его оспорить.


VD>>Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.


L>Думал об этом. Паттерн-матчинг не такая уж сложная часть — её понимают практически все, кому я его объяснял. Ещё не встречал проблемы с пониманием, один даже сходу предложил реализацию этого подхода.


А кому не объяснял?
И что тогда не понимают?

Или все понимают, но не могут прочесть программу на языке?

L>Ну, немного не так было, но смысл верный, да. Но! По своему опыту знаю, что я многого добился, если у LaPerouse зародилась хоть тень сомнения в своей правоте. А мне кажется, что так и есть.


Согласен, что это тоже достижение. Но все же этого не достаточно. К тому же убеждать каждого по отдельности задача бесполезная.

VD>>Why FP matters я пробовал читать когда пытался въехать в ФП. Результат был — скепсис и непонимание.


L>Из-за приведённых примеров? Или сам тезис о разбивании сложности с помощью ФВП?


Не помню подробностей. Помню ощущения.

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

С удовольствием послушал бы (в отдельной теме) аргументы которые меня разубедили бы. Но пока меня просто пытаются "закричать", а по делу никто так ничего и не сказал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 09.02.09 05:57
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Кстати, я не понял, чего ты радуешься? Человек высказал мысль о том, что Хаскель значительно сложнее ОКамла и что последний ему понятен, а первый нет. Ты по идее с ним должен спорить, а не со мной.


Почему, хаскель мне вполне понятен в теории, вот на практике он у меня не идет. Может как раз психологический тормоз
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.02.09 08:12
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Возможно, но ломка привычки в отношении синтаксиса — копейки.


VD>Отнюдь не копейки. Есть масса людей которые программировали на Дельфи в 90-тые. Сейчас Дельфи не в фаворе. Разумно было бы перейти на C#, ведь язык очень близок по духу. Разница только в синтаксисе. Однако многие так и остаются на клонах Дельфи, так как учить эту разницу и нюансы сложно, а работать надо сейчас.


Да не в синтаксисе разница. Иначе бы они перешли очень быстро. Разница в тех самых нюансах
Либо мы с тобой очень по разному понимаем синтаксис.

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

VD>Собственно это факт. Не понимаю почему многие очень хотят его оспорить.

С этим я не спорю. Я говорю о том, что в этой сумме синтаксические различия не играют значительной роли.

L>>Думал об этом. Паттерн-матчинг не такая уж сложная часть — её понимают практически все, кому я его объяснял. Ещё не встречал проблемы с пониманием, один даже сходу предложил реализацию этого подхода.


VD>А кому не объяснял?


Не понял вопроса.

VD>И что тогда не понимают?


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

VD>Или все понимают, но не могут прочесть программу на языке?


Могут-могут.

VD>Согласен, что это тоже достижение. Но все же этого не достаточно. К тому же убеждать каждого по отдельности задача бесполезная.


Так другие читают. Вот мы сейчас говорим, а за спиной стоят анонимусы
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: MasterZiv СССР  
Дата: 09.02.09 08:32
Оценка:
VladD2 wrote:

> К тому же строготипизированным был виртовский паскаль, который

> практически не применим для программирования. Даже две строки нельзя
> сравниь если у них разная длинна. Ну, что это такое?

А я другого не знаю. Есть язык, называется "паскаль", его придумал вирт.

> Гы-гы. Реальные реализации Паскаля (Турбо Паскаль) были реально


Так это не паскаль.

Ну ладно. Всё понятно.
Posted via RSDN NNTP Server 2.1 beta
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 09.02.09 08:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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



Императивно менять можно тоже по-разному. Если делать умеючи, все может оказаться не таким страшным (хотя внимательности, в самом деле, нужно больше, чем фп-реализации). Главное правило здесь следующее — если изменения дерева/графа сложные, то должен быть отдельные instance для изменения итерации, то есть перед изменениями нужно сделать копию дерева\графа. В принципе, в чем-то это может оказаться схожим с фп-подходом. Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 09.02.09 08:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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



LP>Главное правило здесь следующее — если изменения дерева/графа сложные, то должен быть отдельные instance для изменения итерации


Следует читать как "для изменения и итерации"
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.09 10:42
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Да не в синтаксисе разница. Иначе бы они перешли очень быстро. Разница в тех самых нюансах


Я как-то недавно загружал новую версию дельфей. Разницы с шарпом почти нет. Ну, разве что некоторые недоработки. Д

L>Либо мы с тобой очень по разному понимаем синтаксис.


Незнаю. Семантика очень близка. В дотнет-версиях даже библиотеки одни и те же.

Кстати, знание библиотек — это тоже важный фактор для изучения. Перейти с Шарпа на Дельфи.Нэт или Васик.Нэт (и наоборот) значительно проще нежели на/с их неуправляемых аналогов.

L>С этим я не спорю. Я говорю о том, что в этой сумме синтаксические различия не играют значительной роли.


А я говорю, что не меньшую чем другие факторы.

Ну, это же просто как дважды два и очевидно! Если изучать нужно меньше, то и процесс обучения идет проще.

В том же Шарпе учить надо не так мало. Если ты все это знаешь, то язык аналогичный по парадигме и подходу (Васик, Дельфи) и даже язык с большими возможностями (Немерле) изучаются проще. Для Васика и Дельфи достаточно наладить в голове таблицу соответствия [скобки => бегинэнд блоки, синтаксис функции => синтаксис процедур и функций, присвоение знаком '=' => присвоедие знаком ':='].
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 09.02.09 11:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


L>>Либо мы с тобой очень по разному понимаем синтаксис.


VD>Незнаю. Семантика очень близка. В дотнет-версиях даже библиотеки одни и те же.


Может я заблуждаюсь, но синтаксис != семантика
И уж библиотеки точно к синтаксису не относятся.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: Denom Украина  
Дата: 09.02.09 11:45
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Я как-то недавно загружал новую версию дельфей. Разницы с шарпом почти нет. Ну, разве что некоторые недоработки.


Ты случайно не Delphi Prism имеешь ввиду?
... << RSDN@Home 1.2.0 alpha 4 rev. 1125>>
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 09.02.09 11:53
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>И они правы. Яйцо с надломленным кончиком нельзя высидеть.

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

T>Объект можно менять функционально, если он линеен (уникален в смысле "uniqueness types" Clean — на него одна ссылка).


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

Например:

newObject = setProperty(object, "name", "somename")

Если object используется только в одном месте, тогда само-собой вместо порождения нового newObject логичнее изменить object.

Но если скажем строчкой ниже делается что-то типа:

transformedObject = transform(object)

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

То есть компилятор сам как бы следит за уникальностью объектов. Поскольку задача это архисложнейшая (по крайней мере мне так кажется), то поэтому видимо в ghc нормально проблему не решили, вот и потребляют программы на haskell столько памяти (правда, там есть еще ленивость, которая тоже ох как сказывается в плане памяти).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.02.09 12:23
Оценка:
LP>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.

Наличие выбора порождает трату времени на разрешение его проблемы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.02.09 13:13
Оценка:
VD>>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.
T>>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.
T>>Уж коли ты так хорошо во всём разобрался.
VD>Кстати, я не понял, чего ты радуешься? Человек высказал мысль о том, что Хаскель значительно сложнее ОКамла и что последний ему понятен, а первый нет. Ты по идее с ним должен спорить, а не со мной.

Я с тобой и не спорю. Я тебя подкалываю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.02.09 13:31
Оценка:
L>>Возможно, но ломка привычки в отношении синтаксиса — копейки.
VD>Отнюдь не копейки. Есть масса людей которые программировали на Дельфи в 90-тые. Сейчас Дельфи не в фаворе. Разумно было бы перейти на C#, ведь язык очень близок по духу. Разница только в синтаксисе. Однако многие так и остаются на клонах Дельфи, так как учить эту разницу и нюансы сложно, а работать надо сейчас.

Это значительно более сложный вопрос, чем твоё его изложение.

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

VD>Собственно это факт. Не понимаю почему многие очень хотят его оспорить.

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

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

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

Следующий шаг — выбор языка для реализации каждой из частей.

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

VD>>>Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.


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

Именно поэтому я не сторонник IDE. Они мешают использовать ЯП точно по его месту, которое отличается от представления о нём авторов IDE.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 09.02.09 14:08
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.


T>Наличие выбора порождает трату времени на разрешение его проблемы.


Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.02.09 14:10
Оценка:
LP>>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.
T>>Наличие выбора порождает трату времени на разрешение его проблемы.
LP>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

Да, именно так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: MasterZiv СССР  
Дата: 09.02.09 19:12
Оценка:
VladD2 пишет:

> На практике использовался Турбо паскаль/Объхект паскаль/Дельфи. Когда

> кто-то говорит сегодня "Паскаль", то большинству программистов
> впоминаются именно они.

Да нет, просто языки это разные. Похожие, по мотивам, и т.д, но разные.
Ладно. Не важно.
Posted via RSDN NNTP Server 2.1 beta
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.02.09 00:17
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Согласен. Однако возьмём два совершенно непохожих синтаксически языка — схема и хаскель. У меня переход был именно такой — от схемы я пришёл к хаскелю. Языки совершенно различны в плане синтаксиса, однако синтаксис совершенно не был для меня проблемой — по крайне мере на фоне всего остального я даже не припомню какие то трудности восприятия. У меня там совсем другие трудности были.


Это потому-что тебе требовалось всего лишь освоить новый синтаксис. Концепция нового языка была для тебя и так знакома. А вот когда человек пытается изучить Схему или Хаскель после опыта работы, скажем, с С++, то для него незнакомыми являются и концепция, и синтаксис, и семантика. В общем, новый мир.

Короче говоря, пересесть со Схемы на CL просто потому, что ты всего лишь осваиваешь новые фичи. Для тебя это просто расширение знаний (не очень большое). Пересесть с ОКалма на Хаскель так же не трудно. Пересесть со Схемы на Хаскель труднее, но вся трудность (особенно учитывая опыт с Прологом) в освоении нового синтаксиса и небольшого количества новых фич. Пересесть же с С++ на Хаскель неимоверно сложно. В прочем как и наоборот, наверное. Хотя почему-то мне кажется (чисто интуитивно), что второе проще (на первых порах, по крайней мере).

В общем, сложность имеет тенденцию складываться (если не умножаться). И всегда проще освоить язык в котором минимум изменений нежели совершенно другой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.02.09 05:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Антон, где такая трава растёт?

А причем тут трава? Какие-то постулаты вызывают сомнения?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 09:58
Оценка:
LP>>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?
T>>Да, именно так.
LP>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

Тебе гибкость иметь или программу писать?

Лично мне — программу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 10:03
Оценка:
VD>Пересесть с ОКалма на Хаскель так же не трудно.

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

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

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


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

Значительно дольше.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 10.02.09 10:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Короче говоря, пересесть со Схемы на CL просто потому, что ты всего лишь осваиваешь новые фичи. Для тебя это просто расширение знаний (не очень большое). Пересесть с ОКалма на Хаскель так же не трудно. Пересесть со Схемы на Хаскель труднее, но вся трудность (особенно учитывая опыт с Прологом) в освоении нового синтаксиса и небольшого количества новых фич. Пересесть же с С++ на Хаскель неимоверно сложно. В прочем как и наоборот, наверное. Хотя почему-то мне кажется (чисто интуитивно), что второе проще (на первых порах, по крайней мере).


Осваивать Хаскель после С++ было не просто, но синтаксис Хаскеля не мешал изучению, а скорее помогал. Непривычнее всего было понять что по умолчанию пишется expression, а не statement, но это по началу. Непривычно было возвращать новую функцию, от каринга я вообще в восторге был (сейчас правда в С++ так иногда хочется лямбду куда-нибудь передать ). ИМХО, у Хаскеля очень лаконичный и понятный синтаксис. Да там есть операторы состоящие только из значков, значение которых вовсе неочевидно. Я это к тому говорю, что семантику мы воспринимаем через синтаксис и ситнаксис может как помогать нам в восприятии, так и мешать. Если говорить про Хаскель, то там синтаксис чаще помогает, особенно когда учишь основные концепции языка. А если пытаться учить приёмы ФП используя С++ синтаксис будет только мешать (меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" ).

Короче, ничего неимоверно сложного в этом я не заметил, и освоение синтаксиса было одной из самых простых вещей, тем более что этот синтаксис только способствует пониманию новых концепций.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 10:39
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>А если пытаться учить приёмы ФП используя С++ синтаксис будет только мешать


По мне так это весьма полезно — научиться писать в функциональном стиле на C++. После того, как набъёшь руку с boost::bind, никакой карринг уже не испугает :)

DC>(меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" :)) ).


А в чём проблема ответить? 1) захват контекста (обычно передача окружения в ктор функтора), 2) возможность комбинировать операции (на указателях-на-функцию суперпозиции не сделаешь), 3) возможность манипулирования ФВП (например, сфабриковать внутри функции другую функцию и вернуть её в качестве результата).

В функциональных языках всё готовенькое, меньше пищи для размышлений — прозрачные замыкания, халявный карринг, etc. А C++-программисту волей-неволей приходится врубаться в потроха таких вычислений. Перечисленные выше пункты дают понимание (соответственно): 1) лексических замыканий, 2) деревьев выражений, 3) отложенных вычислений.

Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного :)
Глаза у меня добрые, но рубашка — смирительная!
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 10:42
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

T>>>Да, именно так.
LP>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

T>Тебе гибкость иметь или программу писать?


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

T>Лично мне — программу.


А мне — программу, которая удовлеторяет предъявляемым требованиям, в том числе и по потребляемым вычислительным ресурсам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 11:37
Оценка:
LP>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
T>>Тебе гибкость иметь или программу писать?
LP>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.

Кого не устраивает?

T>>Лично мне — программу.

LP>А мне — программу, которая удовлеторяет предъявляемым требованиям, в том числе и по потребляемым вычислительным ресурсам.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 11:44
Оценка:
Q>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного 

Это очень неправильное О.

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

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

Вот и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например. Отточив мышление в функциональном стиле, в отличии от MPD стиля "ФП на C++". Не говоря уж про знание многих полезных вещей в самом конце — AST, кодогенерация и прочее.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 12:26
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

T>>>Тебе гибкость иметь или программу писать?
LP>>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.

T>Кого не устраивает?


Пока — меня. Потом будет не устраивать пользователей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 12:42
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

Q>>После того, как набъёшь руку с boost::bind, никакой карринг уже не испугает :)


DC>После того как увидел карринг в Хаскеле, от boost:bind тошнить начинает :).


Не без этого. Поэтому я на C# перешёл. Не хватает паттерн-матчинга и макросов, надо ещё куда-нибудь переходить.

DC>А, вообще, полезно, только язык тебе не помогает, а мешает выражать свои мысли.


Всё что нас не убивает, делает нас... страннее! © :)

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

DC>© Белянин С.
DC>Человек только начал въезжать в С++ с его ООП и прочей фигнёй. Объяснить не трудно, важно дать понять зачем это надо и как использовать.

Я не об этом. Я о том, что человек начинает въезжать в ФП, и объяснить через C++ проще, чем через Карри, Чёрча и Россера :)

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


Это так.

DC>Я вообще не об этом, я о том, что проще изучать приёмы программирования используя синтаксис, который упрощает его понимание человеком, а не машиной.


Я б не сказал, что синтаксис Хаскеля чего-то там упрощает.
Глаза у меня добрые, но рубашка — смирительная!
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 13:28
Оценка:
Здравствуйте, eao197, Вы писали:

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


T>>Для этого человека нет ничего невозможного в написании программы, но всё равно остаются сложности с предметной областью.


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


E>Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?


E><offtopic>

E>Например, есть необходимость внести за короткое время важные изменения в большую систему, эволюционировавщую в течении восьми лет. И так, чтобы эти изменения заработали сразу, без ошибок. Здесь уже не столь важно ни знание предметной области, ни знание языков и внутренностей, ни даже знание самой модифицируемой системы. А некий баланс всех этих знаний + четкое понимание целей + четкое видение пути их достижения + спокойное отношение к оставшемуся до часа "Ч" времени.

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


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

E></offtopic>

ФП здесь вообще не при чем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 13:29
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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

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


Вот об этом я и говорю. Сравни с C#:
var bars = from foo in foos select map[foo.Name];
Глаза у меня добрые, но рубашка — смирительная!
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 13:31
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Вот об этом я и говорю. Сравни с C#:

Q>
Q>var bars = from foo in foos select map[foo.Name];
Q>


Лукавишь. Ты вёл речь о с++.
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 13:37
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Лукавишь. Ты вёл речь о с++.


Не понял. Мне пытались показать, что C++ плохо пригоден для программирования в функциональном стиле? Так я это сам кому угодно могу продемонстрировать. Недавно в какой-то ветке (луркать по запросу «Рефакторинг „Повышение Декларативности“») я даже привёл здоровый коммент с объяснениями, почему на C++ программировать в функциональном стиле непросто.
Глаза у меня добрые, но рубашка — смирительная!
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 13:48
Оценка:
T>>Для этого человека нет ничего невозможного в написании программы, но всё равно остаются сложности с предметной областью.
T>>Для программиста знание языков и внутренностей важно, но не менее (а то и более) важно уметь программировать для разных предметных областей. И чем больше их будет, тем лучше.
E>Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?

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

E><offtopic>

E>Когда-то давно была такая поговорка: настоящий программист должен написать собственный текстовый редактор, компилятор и операционную систему. Поэтому не нужно апелировать к написанию компиляторов, пониманию AST и кодогенерации. Это вещи, которые очень многие программисты считают весьма интересными и готовы заниматься ими ради собственного удовольствия.
E>Гораздо сложнее, на мой взгляд, ответственное отношение к работе, которая не так увлекательна, как создание собственного компилятора.

Написание таких слов — оно ведь создаёт внутри такое тёплое приятное чувство, так?

E>Например, есть необходимость внести за короткое время важные изменения в большую систему, эволюционировавщую в течении восьми лет. И так, чтобы эти изменения заработали сразу, без ошибок. Здесь уже не столь важно ни знание предметной области, ни знание языков и внутренностей, ни даже знание самой модифицируемой системы. А некий баланс всех этих знаний + четкое понимание целей + четкое видение пути их достижения + спокойное отношение к оставшемуся до часа "Ч" времени.


Да! Да! ДДаа!!!

Ещё-о-о!

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

Если серьёзно, то всё, что вы написали, обсалютно (C) бессмысленно, ибо лишено критериев проверки.

Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?

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


Стиль программирования исходной системы, конечно же, имеет значение. В случае ФП нам гарантирован фиксированный объём изменений и фиксированный объём мест, где могут появиться внесённые ошибки. Nes pa?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 10.02.09 13:57
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Не понял. Мне пытались показать, что C++ плохо пригоден для программирования в функциональном стиле? Так я это сам кому угодно могу продемонстрировать. Недавно в какой-то ветке (луркать по запросу «Рефакторинг „Повышение Декларативности“») я даже привёл здоровый коммент с объяснениями, почему на C++ программировать в функциональном стиле непросто.


Q>Я б не сказал, что синтаксис Хаскеля чего-то там упрощает.


Я тебе привёл пример что упрощает синтаксис Хаскеля в сравнении с С++ для простой лямбды (можно было бы и просто скомбинировать доступ name и обращение по индексу). Для С#, я думаю, можно найти не меньше примеров когда синтаксис мешает, воспринимать какой либо приём(паттерн матчинг например), причём не только в сравнении с Хаскелом.

Короче: Размер... тьфу... Синтаксис таки имеет значение. И мало того синтаксис Хаскеля помогает понять концепции/парадигмы/приёмы заложенные в этот Язык. А синтаксис С++ хоть и позволяет нам работать с замыканиями или строить семейства типов, но понимание этих концепций человеком затрудняет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 10.02.09 14:09
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Вот об этом я и говорю. Сравни с C#:

Q>
Q>var bars = from foo in foos select map[foo.Name];
Q>

О чём?

Распечатать максимальное чётное из 25 рандомных чисел
print.maximum.filter even.take 25.randoms
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 14:09
Оценка:
Здравствуйте, Qbit86, Вы писали:

L>>Лукавишь. Ты вёл речь о с++.


Q>Не понял. Мне пытались показать, что C++ плохо пригоден для программирования в функциональном стиле? Так я это сам кому угодно могу продемонстрировать. Недавно в какой-то ветке (луркать по запросу «Рефакторинг „Повышение Декларативности“») я даже привёл здоровый коммент с объяснениями, почему на C++ программировать в функциональном стиле непросто.


А вы там намешали — объяснять надо на примере с++ и прочее. Сбили меня с толку. Приношу свои извинения.
Что касается синтаксиса, то map примитивный пример, на котором мощь синтаксиса Хаскеля для программирования в фп стиле незаметна.
Твой код на LINQ — это аналог list comprehension. Выглядеть будет практически так же. Уже есть везде
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 14:13
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Я тебе привёл пример что упрощает синтаксис Хаскеля в сравнении с С++.


Вот это достижение — сделать синтаксис проще, чем в C++!

DC>Я тебе привёл пример что упрощает синтаксис Хаскеля в сравнении с С++.


А я привёл пример синтаксиса C# 3.0 в сравнении с Хаскелем.

DC>Короче: Размер... тьфу... Синтаксис таки имеет значение.


Таки да.

DC>И мало того синтаксис Хаскеля помогает понять концепции/парадигмы/приёмы заложенные в этот Язык.


Синтаксис
var bars = from foo in foos select map[foo.Name];

Способен понять не то что начинающий в ФП — даже новичок в программировании вообще. В отличие от
let bars = map ((\ arr (_,name,_) -> arr!name ) arr) foos

или
[ arr!name | (_,name,_) <- foos ]


DC>А синтаксис С++ хоть и позволяет нам работать с замыканиями или строить семейства типов, но понимание этих концепций человеком затрудняет.


Синтаксис C++ страшен, но опыт вынужденного написания своих замыканий или комбинаторов упрощает понимание реализации «этих концепций». Это позволяет делать правдоподобные априорные заключения о скорости и асимптотической сложности вычислений, о специфике взаимодействия с GC и ресурсами системы, и многих других вещей.
Глаза у меня добрые, но рубашка — смирительная!
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 14:17
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Твой код на LINQ — это аналог list comprehension.


Можно без SQL-like синтаксиса:
var bars = foos.Select(foo => map[foo.Name]);


L>Уже есть везде :-)


Если так, то это здорово!
Глаза у меня добрые, но рубашка — смирительная!
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 14:18
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Для этого человека нет ничего невозможного в написании программы, но всё равно остаются сложности с предметной областью.

T>>>Для программиста знание языков и внутренностей важно, но не менее (а то и более) важно уметь программировать для разных предметных областей. И чем больше их будет, тем лучше.
E>>Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?

T>Не могу никак ограничивать ваше понимание моих слов.


Очень отрадно, что вы сторонник "свободы сновидений". Однако, очень бы хотелось узнать именно ваш вывод.

E>>Гораздо сложнее, на мой взгляд, ответственное отношение к работе, которая не так увлекательна, как создание собственного компилятора.


T>Написание таких слов — оно ведь создаёт внутри такое тёплое приятное чувство, так?


Нет.

T>Если серьёзно, то всё, что вы написали, обсалютно (C) бессмысленно, ибо лишено критериев проверки.


T>Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?


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

Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?

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


T>Стиль программирования исходной системы, конечно же, имеет значение. В случае ФП нам гарантирован фиксированный объём изменений и фиксированный объём мест, где могут появиться внесённые ошибки. Nes pa?


Очень наивная точка зрения, имхо.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 14:33
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Синтаксис

Q>
Q>var bars = from foo in foos select map[foo.Name];
Q>

Q>Способен понять не то что начинающий в ФП — даже новичок в программировании вообще. В отличие от
Q>
Q>let bars = map ((\ arr (_,name,_) -> arr!name ) arr) foos
Q>

Q>или
Q>
Q>[ arr!name | (_,name,_) <- foos ]
Q>


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

Чего ты к линку привязался? линк хороший DSL и хорошо делает свою маленькую работу, что же он теперь покрывает всё ФП программирование? Кстати, даже если коснутся потоков — он так же хорош как и хаскелевский LH?

Честно, не пойму, чем from foo in foos select map[foo.Name] отличается от [ arr ! name foo | foo <- foos] или даже, раз мы уж говорим о том, что синтаксис помогает писать в ФП стиле, map ((arr!) . name) foos. И не надо глупостей про новичков, синтаксис программистам помогать должен программы писать, а не язык учить.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 14:39
Оценка:
Здравствуйте, Qbit86, Вы писали:

L>>Твой код на LINQ — это аналог list comprehension.

Q>Можно без SQL-like синтаксиса:
Q>
Q>var bars = foos.Select(foo => map[foo.Name]);
Q>


Согласен — нечего здесь сравнивать, абсолютно аналогично

map (\foo -> bars ! name foo) foos


L>>Уже есть везде

Q>Если так, то это здорово!

Это далеко не весь ФП
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 10.02.09 14:42
Оценка:
Здравствуйте, thesz, Вы писали:

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


И как, интересно, знание разных предметных областей помогает в освоении того же ФП? Как мне в этом поможет, ну скажем, написанный отчёт по заработной плате?
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 14:57
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Согласен — нечего здесь сравнивать, абсолютно аналогично


L>
L>map (\foo -> bars ! name foo) foos
L>


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

L>Это далеко не весь ФП :)


Я знаю. Я отдаю себе отчёт в том, что как функциональный язык Хаскель мощнее Шарпа. Но этот синтаксис меня убивает...
Глаза у меня добрые, но рубашка — смирительная!
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 14:58
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>>>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

T>>>>>Тебе гибкость иметь или программу писать?
LP>>>>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.
T>>>Кого не устраивает?
LP>>Пока — меня. Потом будет не устраивать пользователей.

T>Ladies and gentleman!


T>Here we have an extremely revealing case of premature optimization!


В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 10.02.09 15:06
Оценка:
Здравствуйте, IT, Вы писали:

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


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


IT>И как, интересно, знание разных предметных областей помогает в освоении того же ФП? Как мне в этом поможет, ну скажем, написанный отчёт по заработной плате?


Предполагается, что написав отчет по своей заработной плате, ты ужаснешься ее размерами и срочно пойдешь учить ФП, чтобы увеличить производительность и зарабатывать больше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 15:15
Оценка:
E>>>Это как следует понимать? Как "владение разными языками облегчает вхождение в разные предметные области"? Или как "разные предметные области облегчают человеку изучение разных языков"?
T>>Не могу никак ограничивать ваше понимание моих слов.
E>Очень отрадно, что вы сторонник "свободы сновидений". Однако, очень бы хотелось узнать именно ваш вывод.

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

Хотя это не вывод, это тезис. Посылка.

E>>>Гораздо сложнее, на мой взгляд, ответственное отношение к работе, которая не так увлекательна, как создание собственного компилятора.

T>>Написание таких слов — оно ведь создаёт внутри такое тёплое приятное чувство, так?
E>Нет.

А зачем тогда это писать?

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

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

"Я скажу это потому, что мне нравится так говорить. Мне нравится, когда все знают, что я так думаю."

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

T>>Как, например, проверить "баланс знаний"? Или "чёткость понимания целей"?

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

Любой выбор программиста может быть оценён. Это и есть критерий проверки.

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

E>Или же вы разделяете философию Лапласа о том, что все в нашем мире детерминировано?


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

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

Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.

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

А за счёт чего? За счёт того, что он предусмотрел что-то для вашего использования ("здравый смысл", "чувство локтя"). За счёт того, что его решения стройны и легко расширяются ("вкус").

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

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

T>>Стиль программирования исходной системы, конечно же, имеет значение. В случае ФП нам гарантирован фиксированный объём изменений и фиксированный объём мест, где могут появиться внесённые ошибки. Nes pa?
E>Очень наивная точка зрения, имхо.

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

Покажите, как внесение изменений в систему на ФЯ может привести к нарушению инвариантов вне области внесения изменений. Сперва, если можно, для чистого ФЯ, поскольку это поинтересней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 15:17
Оценка:
T>>>>Кого не устраивает?
LP>>>Пока — меня. Потом будет не устраивать пользователей.
T>>Ladies and gentleman!
T>>Here we have an extremely revealing case of premature optimization!

LP>В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.


Да ты что!

Тебе о производительности ещё никто не сказал, а ты уж вовсю профайлером машешь!

Что это, как не преждевременная оптимизация?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[27]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 15:20
Оценка:
T>>Для программиста знание языков и внутренностей важно, но не менее (а то и более) важно уметь программировать для разных предметных областей. И чем больше их будет, тем лучше.
IT>И как, интересно, знание разных предметных областей помогает в освоении того же ФП? Как мне в этом поможет, ну скажем, написанный отчёт по заработной плате?

Там чуть дальше следующее:

от и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например.


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

Какой язык, какая проблема — меня, как шерифа, это не волнует.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 15:43
Оценка:
Здравствуйте, thesz, Вы писали:

T>Хаскельные "понимания списков" представляют собой кальку с синтаксиса теории множеств.


T>B={x|x∈B, P(x)}


О, такое мне нравится. Не распознал сразу в коде эти comprehensions.

T>(почему RSDN не понял &isin;?..)


HTML entities — зло. Коды, впрочем, тоже. Литералы предпочтительнее, имхо.
Глаза у меня добрые, но рубашка — смирительная!
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 17:17
Оценка:
Здравствуйте, thesz, Вы писали:

T>Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.


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

T>Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.


Вообще-то это не побочный эффект -- это ее цель.

T>Вот вариант с чисто функциональной прокладкой:

T>
T>    +-+ +-+ +-+
T>----|B|-|M|-| |---> куда-то на...
T>    | | +-+ | |
T>    | |     | |
T>    | +-----+ |
T>    |         |
T>    +---------+
T>

T>То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.

Этот вариант требует от B "протягивания" через себя большого количества сообщений, которые обрабатывает M, но о которых не имеет понятие B. Что создает лишнюю зависимость. Фактически, B должен поддерживать весь "внешний интерфейс" компонента M.

Тогда как идея была в том, что между компонентами системы настроены потоки сообщений. И заплатки ставятся только на те потоки, которые нужны. Что позволяет просто делать системы вида:
  --- D ---
 /          \
M ---- B --- S
 \          /
  -- T - Y -

Где D обрабатывает свой поток сообщений, B свой, T и Y -- свой. А компоненты M и S даже не подозревают, об их существовании.

Подход с параметризацией означал бы, что система приняла бы вид:
M - T - Y - D - B - S

где каждый следующий элемент бы предыдущим. И изменения потока данных между M и S по линии T-Y означала бы необходимость адаптации к этим изменениям еще и D, и B.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 17:19
Оценка:
Здравствуйте, eao197, Вы писали:

Ошибся:

E>где каждый следующий элемент бы предыдущим.


следует читать как "следующий элемент был бы связан с предыдущим".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 17:40
Оценка:
T>>>>Например, хорошая обувь позволяет меньше времени тратить в обувных магазинах. Компьютеры Apple позволяют меньше отвлекаться на интерфейс и быстрей приступать к работе. И тп.
E>>>Хорошая обувь нужна не для экономии времени в обувных магазинах, а для сохранения собственного здоровья. И, если бы ваша логика в отношении интерфейсов была бы абсолютно правильной, то такие редакторы, как ViM и Emacs умерли бы давным давно и про них сейчас знали бы только историки.
T>>Ваш логический вывод "в моей логике" мне недоступен, надо отметить.
E>Если интерфейс настолько прост, что позволяет быстро приступить к работе, то это вовсе не означает что он будет настолько же хорошо экономить время в дальнейшем. Доказательством чего служат редакторы ViM и Emacs (а так же LaTeX) -- где нужно потратить изрядное время на первые шаги (т.е. длительное время без полезной работы вообще), зато потом это компенсируется более эффективной работой.

Вам что, трудно вообразить интерфейс, который 1) позволяет быстро приступить к работе и 2) не мешает работе в дальнейшем?

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

Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно. Да вот, блин, Vertu с его одной универсальной кнопкой.

Как раз для экономии любого отрезка времени пользователя.

(тут дальше следуют интересные выводы, которые мы опустим)

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

E>>>Если у вас большой опыт и хорошие знания в области ФП, то может быть вы предложите вариант какой-нибудь схемы контрактов для сообщений?
T>>Напомню, что я первый высказал просьбу.
E>Для того, чтобы показывать системы на ФЯ их нужно видеть, а еще лучше иметь в своем распоряжении. Я таковых в своем распоряжении не имею. Но, мой второй пример с импортом данных в РСУБД совершенно безразличен к языку программирования, на котором реализованы компоненты системы.

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

Что это доказывает?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 18:22
Оценка:
T>>Вся проблема вашей системы в том, что у отдельных частей есть identity (sender address), а у других нет. Переформулировав решение в едином ключе, вы получите либо полностью рабочее решение полностью в императивном стиле, либо рабочее решение полностью в функциональном стиле.
E>Меня больше интересует вопрос о том, есть ли какие-то средства в каком-то языке, которые бы смогли описать существующий контракт. Как и что перепроектировать -- здесь вариантов туева хуча.

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

По-моему, это слегка по-детски, это раз, и ну совсем никак не связано с исходной темой.

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

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

Вам интересно почувствовать себя умным. То самое "тёплое приятное чувство внутри".

"Гляди-ка, Вань, кому я перепроектировать в функциональном стиле запретил!"

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

Не функционально, ну и ладно.

T>>Здесь что ещё интересно. В вашей задаче заплатка, несмотря на чисто функциональное преобразование (сообщение на входе — Maybe сообщение на выходе), имеет ещё и побочный эффект: умеет посылать сообщение самостоятельно.

E>Вообще-то это не побочный эффект -- это ее цель.

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

А если она стоит не на выходе, а обрабатывает двунаправленное соединение, то это ровно тот вариант, что ф предложил.

T>>То есть, она параметризуется компонентой M и может выступать полностью от её лица совершенно правомочно.

E>Этот вариант требует от B "протягивания" через себя большого количества сообщений, которые обрабатывает M, но о которых не имеет понятие B. Что создает лишнюю зависимость. Фактически, B должен поддерживать весь "внешний интерфейс" компонента M.

Не вижу проблем.

E>Подход с параметризацией означал бы, что система приняла бы вид:

E>
E>M - T - Y - D - B - S
E>

E>где каждый следующий элемент бы предыдущим. И изменения потока данных между M и S по линии T-Y означала бы необходимость адаптации к этим изменениям еще и D, и B.

Это как вы всё это построите. Комбинаторы потоков у Fudgets весьма развесисты.

Давайте попробуем.

Итак, у нас есть комбинатор U (SP i o — потоковый процессор из i в o):
uGateSP :: (SP (Either i o) (Either i o)) -> SP i o -> SP i o
uGateSP gateFunc componentM = ...


gateFunc заплатки B принимает на вход либо Left i — элемент на входе uGate, — либо Right o — элемент с выхода компоненты M. Порождает она либо Left i — вход для M, — либо Right o — выход для uGate.

Полдела у нас есть. Есть обобщённая функция, которая позволяет создавать перекрытия.

Теперь надо создать штуку, которая бы мультиплексировала потоки. Чтобы обработка потока для одной части схемы шло по одному пути, для другой — по другому. Это делается с помощью того же Either outLeft outRight, filterSP и joinSP (слияние потоков). Где есть мультиплексор 1->2, есть и мультиплексор 1->N.

Значение SP i o может быть получено путем частичного применения или соединения потоков "за сценой". Выглядит, как SP i o, а на самом деле работает ещё с каким-то потоком.

Вот пример:
something :: SP i a -> (a -> SP i o) -> SP i o
something input func = ... r ...
    where
        -- r :: SP i o
        r = concatMap func input


Всё вместе даст нам ровно ту схему, что вы описали.

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

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

Надоело мне что-то в одни ворота играть.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 19:56
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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

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


Это все не из той оперы. Ситуация, выраженная на объектно-ориентированном языке такова:
class Mailslot { public void sendStateNotification(); ... }
interface SIterface { public queryState(); }
class S implement SInterface {
  // Атрибут, который не меняется с течением жизни объекта.
  protected final Mailslot mailslot;

  S( Mailslot m ) { mailslot = m; }
  public virtual queryState() { mailslot.sendStateNotification(); }
};

Здесь заложено поведение, что в методе S.queryState() _всегда_ вызывается метод sendStateNotification и объекта mailslot, который объект S получает в конструкторе и не может изменить в течении всей жизни. Изменение этого поведения (например, не вызов метода sendStateNotification() или вызов его для другого объекта Mailslot) должно приводить к тому, что остальные модули системы, обращаются к S, не должны даже скомпилироваться. Функциональное программирование как-нибудь решает эту проблему?

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

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


Вы сами уже дали этот ответ:

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

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


T>Если в паре сообщений этого ответа не будет, запишу вас в мелкие трепачи и подожду полового созревания.

T>Вам интересно почувствовать себя умным. То самое "тёплое приятное чувство внутри".

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 20:04
Оценка:
Здравствуйте, thesz, Вы писали:

T>Вам что, трудно вообразить интерфейс, который 1) позволяет быстро приступить к работе и 2) не мешает работе в дальнейшем?


Да, это редкость.

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


Да, так бывает наиболее часто.

T>Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно.


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

T>Ну, безразличен. Так он одинаково плохо будет решаться на всём, чём угодно.


T>Что это доказывает?


Что на определенном этапе организационные вопросы гораздо важнее технических. И опытный программист должен в поставленных перед ним задачах разделять технические и организационные составляющие.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 20:19
Оценка:
Здравствуйте, Qbit86, Вы писали:

L>>Честно, не пойму, чем from foo in foos select map[foo.Name] отличается от...

Q>Слова человеческие.

Ясно.

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

Q>По прежнему не вижу оснований считать синтаксис Хаскеля «помогающим».

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

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

foo f x = g (f x)


или даже просто

foo x y = f x y


foo — уже ФВП, потому что по дефолту каррирована.

2. Карринг.

Можно смотреть пример выше, можно вот этот:

insertEverywhere x = map (insert x)


Здесь один карринг позволяет получить естественную запись (сравни с _.Map(_.Insert(x))) — "слова человеческие". Второй — записать определение кратко, не принимая во внимание куда именно мы вставляем x (можно сделать запись полностью point-free: insertEverywhere = map . insert, но я предпочитаю более явную запись), что ведёт нас к wholemeal programming и возможность естественно комбинировать функции, не задумываясь над тем, что мы через них пропускаем.

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

Обычно, когда пишешь на Haskell функцию, то последним параметром делаешь тот, который и будет теми данными, что пропускаются через цепочку функций. Например, при вставке в коллекцию это будет сама коллекция, а не элемент, который мы вставляем в неё. В большинстве случаев поэтому карринга вполне хватает. Однако иногда случается необходимость описать "вставить в что-то", а не "вставить что-то". В этом случае поможет инфиксная запись (`insert` coll). Сюда же секции — это частичное применение операторов, например, (^2) — возвести в квадрат.

Вариант _.Map(_.Insert(x)) более гибкий (см. случай, когда нам нужен третий с конца параметр), но и более многословный. А его гибкость нужна очень редко. В этом случае, в Haskell используют менее удобные лямбды или вложенные функции.

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

Тоже сильно помогает, но не знаю, стоит ли это относить к ФП.

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

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

6. Монады

В Haskell для программирования на монадах, которое используется очень часто, есть специальный синтаксис. Не скажу, что мне это нравится, но писать этот синтаксис помогает. Аналогично есть синтаксис для стрелок.

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

А также паттерн матчинг, ADT/GADT и многое, что я не вспомнил, потому что действительно очень многое подталкивает именно к ФП. Не понимаю, как это можно не видеть?

Теперь ты скажи — а чем же Haskell мешает писать в ФП стиле?
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.02.09 20:37
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


Пробовал пару их раз, но вот серьёзно в векторные языки так и не въехал по-моему.
По поводу твоего вопроса: у Иверсона есть тьюринговская лекция под говорящим названием "Notation as a Tool of Thought" (всё ешё лежит у меня в папочке "к прочтению" ).
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.02.09 20:50
Оценка:
Здравствуйте, eao197, Вы писали:

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

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

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

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


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


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

Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть! Если не считать queryState = undefined, само собой.
Re[26]: "LINQ как шаг к ФП". Стиль изложения.
От: Tonal- Россия www.promsoft.ru
Дата: 10.02.09 20:58
Оценка:
Здравствуйте, thesz, Вы писали:
T>Вот и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например.
И чего там выяснять нужно?
Вполне элементарно пишется из общих соображений.
Особливо удобно было в С++ от borland 5.02, т.к. там допускалось параметризация шаблонов вложенными классами. Я их вовсю тогда применял.
В современных компиляторах так нельзя — стандарт не велит, но сложнее сама конструкция от этого не стала.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 21:17
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>

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


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.09 21:26
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: "LINQ как шаг к ФП". Стиль изложения.
От: Tonal- Россия www.promsoft.ru
Дата: 10.02.09 21:26
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
DC>
DC>struct Foo
DC>{
DC>\\...
DC>std::string name;
DC>\\...
DC>}

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


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

А можно без boost::bind?
typedef std::map<std::string, Bar> bar_map_t;

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

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

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

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

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

Может так:
let bars = map (barMap!) . map foo_name
in bars foos
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 21:50
Оценка:
T>>Теперь я жду ответа насчёт нелокальности изменений систем, написанных на ФП.
E>Вы сами уже дали этот ответ:
E>

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


А! Понял!

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

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

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

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

T>>Если в паре сообщений этого ответа не будет, запишу вас в мелкие трепачи и подожду полового созревания.

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

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

Вот, например, над этим ответом я думал десять минут. Это третья редакция ответа.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.02.09 21:58
Оценка:
T>>Есть у меня обоснованное подозрение, что вы оперируете двумя выводами "трудно в учении => легко в бою" и "легко в учении => трудно в бою", необоснованно их считая их эквивалентными (ну, считая, что так бывает наиболее часто).
E>Да, так бывает наиболее часто.

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

T>>Дорогие вещи же делают исключительно в стиле "легко в учении => легко в бою", тому примеры: приснопамятный Apple, дорогие автомобили, что угодно.

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

Всё вместе.

Это же всё Apple.

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

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

T>>Ну, безразличен. Так он одинаково плохо будет решаться на всём, чём угодно.

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

Отлично.

Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 10.02.09 22:08
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


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


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


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


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

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


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


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

Q>>По прежнему не вижу оснований считать синтаксис Хаскеля «помогающим».

L>Теперь ты скажи — а чем же Haskell мешает писать в ФП стиле?

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

Во-вторых, не совсем понятно, что там с real world Haskell (выкопанные откуда-то сомнительные success stories как-то не очень убеждают). Большинству не нужно писать компиляторы или «моделировать какую-то там систему знаний с теоретико-множественным подходом»
Автор: thesz
Дата: 10.02.09
. Часто приходится, например, делать клиент-серверные приложения. На сервере общение с БД, на клиенте rich GUI, коммуникация, O/RM, работа с сетью, безопасность, криптография, etc, etc, etc.

Итак, F# и Nemerle: 1) вменяемый синтаксис, 2) интероп с .NET, 3) мультипарадигменность. Пока не вижу никаких убийственных доводов, чтобы предпочесть им Хаскель.
Глаза у меня добрые, но рубашка — смирительная!
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 01:34
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


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


VE>...

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

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

Сравни с аналогичным кодом на F#. С использованием синтаксиса пайплайна «|>» получается как на Хаскеле, только в прямом порядке, сообразно с представлением течения потока данных (за точность названий методов не ручаюсь):
// F#
randoms |> List.take 25 |> List.filter even |> List.max |> Console.WriteLine
Глаза у меня добрые, но рубашка — смирительная!
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 11.02.09 04:04
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


Немерле и Скала отдельно у них неудобный карринг. Сишный синтаксис тут мешает.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.02.09 05:00
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом?

Поясняю еще раз: "императивный программист" — это программист, который мыслит императивными конструкциями. Это определение.

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

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

Никакого колдунства.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.09 05:00
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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

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


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

T>Значительно дольше.

С чего бы это? К тому же, как показывает практика, многие кто пытался освоить совершенно незнакомый ФЯ попросту бросали это занятие еще на первых шагах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.09 05:05
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


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

Несомненно понять и выучить можно все что угодно. Ядерную физику, например. И несомненно учить ФП на языке его не поддерживающем путь тупиковый. Но причем тут эти, совершенно корректные, размышления?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 06:39
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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

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


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

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

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

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


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

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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 07:03
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Не не не, давай-ка на C#, для F# что-нибудь другое найти можно ;)


Ничего не понял. Я ж вроде привёл пример на C# в предыдущем коменте... Ещё раз повторю:
// C#
Console.WriteLine( randoms.Take(25).Where(Even).Max() );

Стандартной функции Even я не нашёл, так что пришлось определить самому:
Func<int, bool> Even = (x => 0 == x % 2);


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


Такого языка нет. Скажем, Хаскель — точно не такой язык.

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

VE>Да и мне этот код потом читать, зачем мне обратный порядок слов?

В том-то и дело, что на F# порядок прямой: данные (randoms) попадают в функцию List.take 25 (т. е. результат каррирования функции List.take при фиксации аргумента), затем результат применения передаётся по конвейеру дальше в функцию List.filter even, её результат в свою очередь... и так далее. А что, если конвеер будет длинным, и придётся перенести на несколько строчек? В Хаскеле придётся читать снизу вверх?

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


Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop.

VE>Что за упор на то, чтобы и баран смог прочитать и написать?


Не надо впадать в крайность. Речь не о баранах, а о людях. О «программистах-прагматиках» и «смиренных программистах».

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


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


Я об этом же. F# и Nemerle опираются на твёрдую почву .NET, при этом не проигрывая по большому счёту Хаскелю в выразительности. Так зачем платить больше?

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


Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?
Глаза у меня добрые, но рубашка — смирительная!
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 11.02.09 07:14
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?


Понятие "удобен" чисто субъективно.
Re[33]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 11.02.09 07:19
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Ничего не понял. Я ж вроде привёл пример на C# в предыдущем коменте... Ещё раз повторю:

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

Q>Стандартной функции Even я не нашёл, так что пришлось определить самому:
Q>
Q>Func<int, bool> Even = (x => 0 == x % 2);
Q>


Я видел. Я хотел сначала было усложнить пример, но потом передумал.
Хотя вот приведу из реального кода:
result <- modifyMVar someMap $ return.(Map.delete value &&& Map.lookup value)

MVar — синхронизированная переменная, этот код возвращает старое значение по ключу value в map'е, и удаляет его.
Наверняка и на C# это можно как-нибудь в одну строку уместить, но боюсь, что так никто не пишет, и я не буду.

Q>Такого языка нет. Скажем, Хаскель — точно не такой язык.

В Хаскеле что-то сложнее, чем в Хаскеле что ли? Поясните мысль

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

VE>>Да и мне этот код потом читать, зачем мне обратный порядок слов?

Q>В том-то и дело, что на F# порядок прямой:

Я про порядок слов, а не действий. Мне код читать, а не интерпретировать в голове.
Q> В Хаскеле придётся читать снизу вверх?
Слева направо же, как предложение.

Q>Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop.

А ссылка есть? Или она платная?

Q>Я об этом же. F# и Nemerle опираются на твёрдую почву .NET, при этом не проигрывая по большому счёту Хаскелю в выразительности. Так зачем платить больше?


Одинаково. Я вот пока серьёзного на Хаскеле не писал, так, не очень большие программки, но каждый раз замечаю, что тут получилось вместо 5 строк одна, и тут меньше, и там. Вот так понемногу код получается раза в 3 короче, а вносимые изменения влияют только на то место, где я их вношу. Это не объяснить словами.
Так что если у меня будет необходимость писать под .NET, разумеется, я не буду биндинги через одно место под Хаскель писать, я просто возьму F# или Nemerle. Но пока я не связан .NET'ом, я лично предпочту Haskell.

Q>Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?

Я уже ответил. Положа руку на что угодно, удобнее. Другое дело, что лично я не вижу под него надёжных хороших библиотек, а те, что есть, не вызывают у меня должного доверия. Так что если мы о языке, то Хаскель удобнее.
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 11.02.09 07:19
Оценка:
Здравствуйте, thesz, Вы писали:

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


Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 11.02.09 07:19
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>>>Кого не устраивает?

LP>>>>Пока — меня. Потом будет не устраивать пользователей.
T>>>Ladies and gentleman!
T>>>Here we have an extremely revealing case of premature optimization!

LP>>В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.


T>Да ты что!


T>Тебе о производительности ещё никто не сказал, а ты уж вовсю профайлером машешь!


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

T>Что это, как не преждевременная оптимизация?


Это не преждевременная оптимизация.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 07:26
Оценка:
Здравствуйте, Qbit86, Вы писали:

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

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

У Nemerle локальный вывод вроде.
Предположим, что у ML-ей и Haskell абсолютно одинаковый вывод типов. Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле?

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

L>>Ленивость by default в чистом языке очень сильно помогает писать в ФП стиле. Но это большая (больная) тема.
Q>Возможно. (Не будем вспоминать тред с обсуждением утечек невычисленных цепочек  К слову, работа с коллекциями в C# по сути тоже ленива по умолчанию.)

"А у меня вся тела такая!"

L>>Теперь ты скажи — а чем же Haskell мешает писать в ФП стиле?


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


Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака?

Q>Во-вторых, не совсем понятно, что там с real world Haskell (выкопанные откуда-то сомнительные success stories как-то не очень убеждают). Большинству не нужно писать компиляторы или «моделировать какую-то там систему знаний с теоретико-множественным подходом»
Автор: thesz
Дата: 10.02.09
. Часто приходится, например, делать клиент-серверные приложения. На сервере общение с БД, на клиенте rich GUI, коммуникация, O/RM, работа с сетью, безопасность, криптография, etc, etc, etc.


Э... Мы вроде говорим о том, помогает ли синтаксис конкретного языка в ФП.
Но если хочешь, можем поговорить о возможностях в real world. Всё перечисленное тобой есть, разве что кроме ОРМ, за отсутствием тех самых О. Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы. Тут уже плавно можно перейти к роли ФП в этом

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


4) грязные
5) энергичные

Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)?
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 11.02.09 08:52
Оценка:
Здравствуйте, VoidEx, Вы писали:

Q>>Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop.

VE>А ссылка есть? Или она платная?
Она платная, в сети есть версия довольно поганого качества, но для ознакомления сгодится.
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 09:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

L>>4) грязные

G>Это хорошо, можно писать императивный код там где он уместен.

Э-э-э! Мы вообще то говорим как синтаксис помогает писать функциональный код

L>>5) энергичные


G>Лучше энергичность по-умолчанию, чем ленивость.


Чем лучше? Чем ленивость?
Re[37]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 09:46
Оценка:
T>>Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок?
LP>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?

Хороший доступней, плохой невозможней. Переход к лучшему проще.

Мне "невозможен плохой дизайн" не нужно. Фортрановскую программу можно написать на любом ЯП. Мне нужно, чтобы фортрановские программы становилось писать все сложнее и сложнее.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[29]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 11.02.09 10:08
Оценка:
Здравствуйте, Tonal-, Вы писали:

T>А можно без boost::bind?

Не не не Девид Блэйн... Написание функтора это, довольно просто.

T>Несколько длинно, но вполне шаблонно и читаемо.

Ты, кстати, ошибку допустил std::map::find возвращает итератор. Ладно, мы возьмём такой случай, что в поиск в словарике не может закончится неудачей, чтоб не добавлять Maybe. Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как? На стандартных биндерах скомбинировать эти функции получается очень нетривиальная задача, которая не только усложняет понимение кода, но ещё и сильно усложняет его отладку. Я, конечно, тоже слукавил: функтор, в принципе, аналог именованной лямбды, но если определена функция доступа к соответствующему члену Foo, то лямбда, которую я написал, превращается в тривиальную комбинацию функций.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 10:09
Оценка:
L>>4) грязные
G>Это хорошо, можно писать императивный код там где он уместен.

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

http://thesz.livejournal.com/509595.html

L>>5) энергичные

G>Лучше энергичность по-умолчанию, чем ленивость.

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

http://thesz.livejournal.com/906786.html
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 11.02.09 10:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Синтаксис должен хорошо отражать семантику. В С++ нет конструкций которые хорошо отражают семантику приёмов ФП (лямбды, карринг, ФВП и т.п.), в С# возможно есть конструкции, которые лучше отражают некоторые из приёмов, а в Nemerle допустим их ещё больше. Т.е. следуя твоим рекоммендациям, мне надо сначала освоить C# (с кучей шелухи которая к ФП не имеет никакого отношения), а потом Nemerle, который похож уже не на С++, а на C# ( и кстати тянет из него в основном шелуху, которая к ФП отношения особого не имеет)?

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

Я говорю о том, что похожесть синтаксиса второстепенна (для меня так вообще особо не важна, мне синтаксис как Scheme, так и Хаскеля видятся довольно красивыми и логичными), главное чтоб синтаксис не отвлекал от новых концепций.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 10:46
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле?

L>...
L>Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)?

Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.

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

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

L>"А у меня вся тела такая!" :)


А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.

L>Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака?


Нет, не правильно. Выше встречались примеры кода на Хаскеле в сравнении с другими языками. Из этих примеров молчаливые анонимусы, читающие из-за спины спорщиков, могут сделать определённые выводы. И, боюсь, не в пользу Хаскеля.

L>Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы.


Должен же кто-то и горшки обжигать. GUI, кстати, вовсе не так скучно, если инструмент правильный.

L>4) грязные

L>5) энергичные

Ты так говоришь, будто это что-то плохое :)
Глаза у меня добрые, но рубашка — смирительная!
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 11.02.09 11:16
Оценка:
Здравствуйте, thesz, Вы писали:

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

LP>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?

T>Хороший доступней, плохой невозможней. Переход к лучшему проще.


На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[30]: "LINQ как шаг к ФП". Стиль изложения.
От: Tonal- Россия www.promsoft.ru
Дата: 11.02.09 11:24
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
T>>Несколько длинно, но вполне шаблонно и читаемо.
DC>Ты, кстати, ошибку допустил std::map::find возвращает итератор.
Я ж вроде там его разименовал.

DC>Ладно, мы возьмём такой случай, что в поиск в словарике не может закончится неудачей, чтоб не добавлять Maybe.

По твоей постоновке (transform) и реализации на haskell (map) вроде бы поиск всегда должен быть удачным. иначе нужен фильтр или Maybe

DC> Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как?

Вот этот код скомпилировался без проблем на g++ (GCC) 3.4.5 (mingw-vista special r3):
#include <string>
#include <map>
#include <algorithm>
#include <boost/bind.hpp>

struct Foo {
  std::string name;
};

struct Bar {
  long val;
};

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

template <class IterF, class IterB>
void foo2bar(bar_map_t barMap, IterF first, IterF last, IterB result) {
  using boost::bind;
  std::transform(
    first, last, result, 
    boost::bind(
      &bar_map_t::operator[], &barMap, boost::bind(&Foo::name, _1)));
}

Вчера было ленно проверять.
Хотя я согласен, что распознать в этом обращение по индексу довольно проблематично, а если ещё заметить, что barMap используется по значению а хочится по ссылке, поэтому нужно использовать find и разименовывать итератор или нужна таки композиция, то bind всяко сольёт функтору по понятливости. А вся конструкция тупому for-у.

В новом стандарте С++ насколько я понял лямбды будут реализовываться именно подобными функторами.
Вот тогда писать с использованием transform и компании будет приятно.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 11:27
Оценка:
L>>Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле?
L>>...
L>>Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)?
Q>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.

Хаскель помогает авторам самих Nemerle и F#. Если, вдруг, ты этого не заметил.

L>>"А у меня вся тела такая!"

Q>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.

Ещё один сторонник преждевременной оптимизации.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[31]: "LINQ как шаг к ФП". Стиль изложения.
От: dr.Chaos Россия Украшения HandMade
Дата: 11.02.09 11:51
Оценка:
Здравствуйте, Tonal-, Вы писали:

T>Я ж вроде там его разименовал.

Извини, видимо, не заметил.

DC>> Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как?

T>Вот этот код скомпилировался без проблем на g++ (GCC) 3.4.5 (mingw-vista special r3):

T>Вчера было ленно проверять.


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

T>Хотя я согласен, что распознать в этом обращение по индексу довольно проблематично, а если ещё заметить, что barMap используется по значению а хочится по ссылке, поэтому нужно использовать find и разименовывать итератор или нужна таки композиция, то bind всяко сольёт функтору по понятливости. А вся конструкция тупому for-у.


Да кто-бы спорил , просто у for-а переиспользуемость на уровне copy-paste.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 11.02.09 11:54
Оценка:
Здравствуйте, thesz, Вы писали:

Q>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.


T>Хаскель помогает авторам самих Nemerle и F#. Если, вдруг, ты этого не заметил.


Я заметил что им помогает не Хаскель а Окамл
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 12:03
Оценка:
Здравствуйте, thesz, Вы писали:

Q>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.


T>Хаскель помогает авторам самих Nemerle и F#.


Это да. Это правильный подход — взять из языка лучшее, оставив синтаксический шлак фанатам.

Q>>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.


T>Ещё один сторонник преждевременной оптимизации.


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

Но каким-то образом я таки дал повод обвинить себя в преждевременной оптимизации. У тебя должно быть запасён целый вагон заблаговременно распечатанных ярлычков «преждевременный оптимизатор», чтоб обильно навешивать на окружающих.
Глаза у меня добрые, но рубашка — смирительная!
Re[34]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 12:10
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Чего ты к линку привязался?


В названии топика фигурирует «LINQ как шаг к ФП».
Глаза у меня добрые, но рубашка — смирительная!
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 12:27
Оценка:
T>>Их разрабатывает нереальное число людей.
E>Осталось подождать, пока на Haskell-е небольшие команды сделают что-нибудь типа Intellij IDEA.

Thou shalt hold thy breath!

Там ещё есть редакторы.

А почему обязательно IDEA? Чем не подойдёт модель процессора или видеоконтроллера в сроки и даже раньше?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: Gajdalager Украина  
Дата: 11.02.09 12:33
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Их разрабатывает нереальное число людей.

E>>Осталось подождать, пока на Haskell-е небольшие команды сделают что-нибудь типа Intellij IDEA.

T>Thou shalt hold thy breath!


Вообще-то это клон Emacs-а, а не IDEA на хаскеле.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Василь Жданкін — Наливаймо, браття
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 12:45
Оценка:
Здравствуйте, thesz, Вы писали:

T>А почему обязательно IDEA? Чем не подойдёт модель процессора или видеоконтроллера


Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.

T> в сроки и даже раньше?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 11.02.09 13:16
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?

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

T>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?


T>Уж больно тон уверенный.


T>Назови хотя бы парочку.


Тон уверенный, потому что я в этом уверен.

<module>
    <name>Module</name>
    <version>1.9.0_snapshot</version>
    <bin>module_1.9.0.dll</bin>
    <Entrants>
        ...
    </Entrants>
</module>


Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?

При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.

Разработка программного обеспечения — это комплексный процесс, в котором парадигме программирования отведена определенная роль, и не стоит эту роль преувеличивать. Ты с фанатизмом ударяешься в крайность, придавая парадигме (ФП) прямо таки определяющую роль, соответственно считаешь, что ФП революционно меняет процесс разработки. А на самом деле парадигма — ни что иное, как один из винтиков в общем процессе, не более. Процесс разработки программ на ФЯ подчиняется все тем же общим законам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 13:48
Оценка:
LP>>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
T>>>>Хороший доступней, плохой невозможней. Переход к лучшему проще.
LP>>>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
T>>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?
T>>Уж больно тон уверенный.
T>>Назови хотя бы парочку.
LP>Тон уверенный, потому что я в этом уверен.
LP>
LP><module>
LP>    <name>Module</name>
LP>    <version>1.9.0_snapshot</version>
LP>    <bin>module_1.9.0.dll</bin>
LP>    <Entrants>
LP>        ...
LP>    </Entrants>
LP></module>
LP>

LP>Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?

XML?

Эту штуку ты написал в функциональном стиле, как ты его понимаешь. И это только часть системы.

Систему целиком в функциональном стиле ты не проектировал, на навязывающем функциональный стиль ЯП ты не писал.

В каких пунктах я не прав?

LP>При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.


ФЯ не даст тебе сделать некоторые виды интерфейсов.

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

LP>Разработка программного обеспечения — это комплексный процесс, в котором парадигме программирования отведена определенная роль, и не стоит эту роль преувеличивать. Ты с фанатизмом ударяешься в крайность, придавая парадигме (ФП) прямо таки определяющую роль, соответственно считаешь, что ФП революционно меняет процесс разработки. А на самом деле парадигма — ни что иное, как один из винтиков в общем процессе, не более. Процесс разработки программ на ФЯ подчиняется все тем же общим законам.


"В теории практика неотличима от теории".

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

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

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

Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[38]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 13:54
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


L>Смысл такой — с помощью системы типов можно ограничить возможные реализации функции для данного типа (существование единственного доказательства для данной теоремы).


Т.е., грубо говоря, все это дело можно на C++ выразить чем-то вроде:
class Mailslot { public: void sendStateNotification(); };
class NonchangeableMailslotUsedSignal {
  private:
    // Создавать этот объект может только один класс.
    friend class S::NonchangeableMailslotHolder;
    NonchangeableMailslotUsedSignal() {}
};
class SInterface {
  public:
    virtual void NonchangeableMailslotUsedSignal queryState() = 0;
};

class S : public SInterface {
  private :
    class NonchangeableMailslotHolder {
      Mailslot & mailslot_;
    public :
      MonchangeableMailslotHolder( Mailslot & m ) : mailslot_( m ) {}

      NonchangeableMailslotUsedSignal sendStateNotify() {
        // Только здесь можно создать объект, тип которого указывает,
        // что обращение к sendStateNotify произошло.
        mailslot_.sendStateNotify();
        return NonchangeableMailslotUsedSignal();
      };
    };

    NonchangeableMailslotHolder mailslot_;

  public :
    S( Mailslot & m ) : mailslot_( m ) {}

    virtual NonchangeableMailslotUsedSignal
    queryState() { return mailslot_.sendStateNotify(); }
};


Получается, что мы требуем от SInterface.queryState() возвращение объекта такого типа, который производит только операция sendStateNotify() для неизменяемого, лишь однажды проинициализированного объекта Mailslot.

L>Я показал примитивный пример, для подробностей можно посмотреть


За ссылочки спасибо. Но на первый взгляд для меня это overkill.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 13:56
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.


На Немерле удобнее писать ФП код?

L>>Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака?

Q>Нет, не правильно. Выше встречались примеры кода на Хаскеле в сравнении с другими языками. Из этих примеров молчаливые анонимусы, читающие из-за спины спорщиков, могут сделать определённые выводы. И, боюсь, не в пользу Хаскеля.

И сделают ложный вывод. Потому что "человеческие слова" не означают удобство в ФП.

L>>Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы.

Q>Должен же кто-то и горшки обжигать. GUI, кстати, вовсе не так скучно, если инструмент правильный.

Кому как.

L>>4) грязные

L>>5) энергичные
Q>Ты так говоришь, будто это что-то плохое :)

Не плохое. Менее ФП-шное.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 13:59
Оценка:
T>>А почему обязательно IDEA? Чем не подойдёт модель процессора или видеоконтроллера
E>Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.

Другие примеры не подойдут? Только IDEA? Galois, Inc не подойдёт? Bluespec?

T>> в сроки и даже раньше?

E>Интересно, вы поверите, если я скажу, что в сроки и даже раньше разрабатываются проекты и на C++? Особенно в небольших командах.

Поверим. Чудеса случаются.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 14:07
Оценка:
Здравствуйте, lomeo, Вы писали:

L>На Немерле удобнее писать ФП код?


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

L>И сделают ложный вывод. Потому что "человеческие слова" не означают удобство в ФП.


Вообще говоря, не означают.

Q>>Ты так говоришь, будто это что-то плохое :)


L>Не плохое. Менее ФП-шное.


Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.
Глаза у меня добрые, но рубашка — смирительная!
Re[39]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Т.е., грубо говоря, все это дело можно на C++ выразить чем-то вроде:


E>      NonchangeableMailslotUsedSignal sendStateNotify() {
E>        // Только здесь можно создать объект, тип которого указывает,
E>        // что обращение к sendStateNotify произошло.
E>        mailslot_.sendStateNotify();
E>        return NonchangeableMailslotUsedSignal();
E>      };
E>


Разве тут нельзя опустить строчку mailslot_.sendStateNotify();, чтобы по прежнему программа компилировалась?
Но идея такая, верно — чтобы не компилировался неверный код, надо описывать инварианты в типах. Зависимые типы в этом отношении наиболее близки к идеалу.

E>За ссылочки спасибо. Но на первый взгляд для меня это overkill.


У меня есть пара постов на эту тему, но там синтаксис Хаскеля
Может проблема в том, что мы говорим на разных языках?
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 14:20
Оценка:
L>>>>4) грязные
G>>>Это хорошо, можно писать императивный код там где он уместен.
T>>Мультипарадигменный подход контрпродуктивен с точки зрения программиста.
G>С точки зрения какого программиста?

Ценящего своё время.

T>>http://thesz.livejournal.com/509595.html

G>Не надо доказывать что любую программу можно написать плохо. Это очевидно.

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

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

Вот если избавляться, то от мультипарадигменности, по-моему.

G>>>Лучше энергичность по-умолчанию, чем ленивость.

T>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>Как ленивость связана с модульностью?

Да это же, вроде, известная тема.

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

После ознакомления с этим вариантом решения он начинает возникать то тут, то там.

T>>http://thesz.livejournal.com/906786.html

G>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

И как понять, какой он когда? А не станет ли он энергичным раньше времени?

Примеры в статье очень простые для простоты изложения и рассмотрения.

G>ИМХО для не-списков ленивость поумолчанию не нужна.


Это ХО, наверное, поддержано каким-то практическим опытом? Каким же, если не секрет?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:20
Оценка:
Здравствуйте, eao197, Вы писали:

E>Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.


Оффтопик: на Java сложно писать без IDE, на Haskell — просто. Как причина отсутствия IDE a la IDEA для Haskell пойдёт?

Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

T>>http://thesz.livejournal.com/509595.html

G>Не надо доказывать что любую программу можно написать плохо. Это очевидно.

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

L>>>>5) энергичные

G>>>Лучше энергичность по-умолчанию, чем ленивость.
T>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>Как ленивость связана с модульностью?

Нет кучи имплементаций.

T>>http://thesz.livejournal.com/906786.html

G>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

IEnumerable<T> — интерфейс. У него может быть много реализаций. Одна реализация ленивого мапа на месте может быть преобразована в энергичный. Наоборот — нет — везде надо будет явно thunk-и объявлять.

G>ИМХО для не-списков ленивость поумолчанию не нужна.


Это потому что тебе показали только ленивые списки.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 14:28
Оценка:
L>>На Немерле удобнее писать ФП код?
Q>Пока что я прихожу к выводу, что на Nemerle удобнее писать код вообще. В том числе и функциональный, и объектно-ориентированный, и мета.

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

Из чего мы напрямую выводим, что Nemerle низкоуровневый язык.

L>>Не плохое. Менее ФП-шное.

Q>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.

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

Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 14:34
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Оффтопик: на Java сложно писать без IDE, на Haskell — просто. Как причина отсутствия IDE a la IDEA для Haskell пойдёт?


L>Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.


Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 14:40
Оценка:
Здравствуйте, thesz, Вы писали:

T>Другие примеры не подойдут? Только IDEA?


Ну, IDEA весьма показательна. Я тут пару лет назад поднимал тему о том, что IDE для языка программирования, написанная на нем самом, является хорошим примером универсальности языка
Но можно еще взять что-нибудь типа Web-браузеров, текстовых процессоров, CAD-систем (т.е. вещей, в которых ООП хорошо себя чувствует).

T>Galois, Inc не подойдёт?


А это чем-то круче SPARKAda? SPARK Ada, конечно, VSDL не генерирует, но подлежащие верификации программы с ее помощью разрабатывают.

Bluespec?

Понятия не имею, это для меня слишком специфический продукт.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 14:40
Оценка:
Здравствуйте, thesz, Вы писали:

T>Из чего мы напрямую выводим, что Nemerle низкоуровневый язык. ;)


Отлично. Хоть ассемблером его назови, менее удобным он не станет.

Q>>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.


T>Первое время приседать со стокилограммовой штангой очень неудобно и сковывает, ага. ;)


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

T>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная. ;)


И к сорока годам остеопороз с остеохондрозом.
Глаза у меня добрые, но рубашка — смирительная!
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:43
Оценка:
Здравствуйте, thesz, Вы писали:

T>"Необходимость в метапрограммировании означает необходимость в языке более высокого уровня" Фред Брукс, "Мифический человеко-месяц", второе издание.


О! Золотые слова! Тут, кстати, уже проскальзывала эта тема.
Называется "Являются ли макросы свидетельством недостаточной выр". Да, именно так, выр.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 14:43
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я пришел к такому же выводу для Ocaml'а.


OCaml тоже неплохой язык.
Глаза у меня добрые, но рубашка — смирительная!
Re[40]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 14:44
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Разве тут нельзя опустить строчку mailslot_.sendStateNotify();, чтобы по прежнему программа компилировалась?


Я думаю, что и в Haskell-е при желании, можно будет сделать, чтобы queryState ничего не делал, но возвращал значение нужного типа

L>Может проблема в том, что мы говорим на разных языках?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 14:46
Оценка:
Здравствуйте, eao197, Вы писали:

E>Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас


Не, Ява — лучшее! Поэтому этот продукт и написан на ней.
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 14:48
Оценка:
T>>Другие примеры не подойдут? Только IDEA?
E>Ну, IDEA весьма показательна. Я тут пару лет назад поднимал тему о том, что IDE для языка программирования, написанная на нем самом, является хорошим примером универсальности языка

Java, AFAIK, это 1995+-1. IntelliJ IDEA — январь 2001. Время разработки не указано.

Ну, хрен его знает. Я думаю, что всё, входящее в первую версию IDEA, можно написать за считанные месяцы.

Разбор Java — месяц. Типизация — полмесяца. Редактор с подсветкой — месяц. Рефакторинги первой версии — месяц.

(тут меня посетила мысль — а деревянная структура проекта — это правильно ли?.. но поскольку это оффтопик, я её развивать не буду)

E>Но можно еще взять что-нибудь типа Web-браузеров, текстовых процессоров, CAD-систем (т.е. вещей, в которых ООП хорошо себя чувствует).


Точнее, куда вложили кучу времени разработчиков. Кстати, Bluespec — это CAD, своего рода. HDL.

T>>Galois, Inc не подойдёт?

E>А это чем-то круче SPARKAda? SPARK Ada, конечно, VSDL не генерирует, но подлежащие верификации программы с ее помощью разрабатывают.

У них много, чего есть. Cryptol только часть.

E>Bluespec?

E>Понятия не имею, это для меня слишком специфический продукт.

На ООП такого нет вообще.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 14:55
Оценка:
L>>Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.
E>Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас

Инерция разработчиков, объём кода.

IDEA разрабатывают те же товарищи, что и MPS.

По результату дискуссии в (моём) ЖЖ могу передать, что когда разработчикам MPS намекнули про OCaml, то они ответствовали, что смотрели, но не смогли быстро нарисовать окошко на экране, и поэтому забросили.

По-моему, это говорит о многом.

(это я отвечал на вопрос "почему IntelliJ IDEA, скорее всего, никогда не будет на Хаскеле".)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 15:01
Оценка:
T>>Из чего мы напрямую выводим, что Nemerle низкоуровневый язык.
Q>Отлично. Хоть ассемблером его назови, менее удобным он не станет.

И более удобным тем паче.

Q>>>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.

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

Люблю, потому, что

А ещё у меня, как у целостной натуры, всё друг с другом связано.

T>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.

Q>И к сорока годам остеопороз с остеохондрозом.

Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.

ЗЫ
Артрит, пока, мне встретился у человека, который ходил заниматься во время гриппа.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 15:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я думаю, что и в Haskell-е при желании, можно будет сделать, чтобы queryState ничего не делал, но возвращал значение нужного типа


Можно написать так, чтобы это было невозможно. Представь, что у тебя mailslot_.sendStateNotify() возвращает тип NonchangeableMailslotUsedSignal, а больше никак ты его создать не можешь в принципе. Это очень упрощённая схема, учти ещё, что можно сделать так, чтобы использовался только наш mailslot_ и что в функции только одно выражение (это же ФП)! Так мы получаем, что мы можем поиметь только одну реализацию этой функции.

Ограничения могут быть достаточно сложными. См. как пример Monad/ST
Вкратце, нельзя создать ST-ссылку в одном блоке, а использовать в другом. Это ограничено типом.

Есть гораздо более сложные ограничения, но это уже зависимые типы.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.09 15:23
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Представь, что у тебя mailslot_.sendStateNotify() возвращает тип NonchangeableMailslotUsedSignal, а больше никак ты его создать не можешь в принципе.


Ну как раз из-за того, что тип Mailslot "чужой" и не может подвергаться изменениям, мне и понадобился NonchangeableMailslotHolder, который и возвращает NonchangeableMailslotUsedSignal. А больше никак этот Signal получить нельзя.

L>Это очень упрощённая схема, учти ещё, что можно сделать так, чтобы использовался только наш mailslot_ и что в функции только одно выражение (это же ФП)!


А вот можно эту тему развить (только на пальцах, примеры на Haskell-е для меня как китайский язык)? Буду очень признателен. Особенно про то, как разделять отдельные mailslot-ы в программе.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 15:30
Оценка:
L>>Может проблема в том, что мы говорим на разных языках?
E>Имхо, это уже давно очевидно.
E>Собственно, как и то, что ОО языки и ФП языки применяют разные люди в совершенно разных условиях. И, может быть, thesz здесь единственный, кому за Haskell деньги платят.

Здесь — да.

А в на моей прежней работе за него платили деньги, по-моему, 4-м человекам точно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: Qbit86 Кипр
Дата: 11.02.09 15:46
Оценка:
Здравствуйте, thesz, Вы писали:

T>Энергичность по умолчанию предпочитают из-за производительности.


ЧСХ, ленивость по умолчанию многие тоже предпочитают из-за производительности. Дескать, она даёт возможность избежать ненужных вычислений.

T>Никаких других плюсов энергичность по умолчанию не даёт.


Даёт лучшую предсказуемость поведения (вспомни свои утечки невычисленных цепочек). (NB: Вот только не надо здесь поминать корень всех зол!)

T>В противном случае ты бы мыслил по-другому.


Т. е. не как прагматик, а как фанатик?

T>Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов.


И что, в этом плане Haskell впереди планеты всей, на два корпуса обгоняя F# и Nemerle? Нет убедительных оснований так считать.

T>То, что ты не касался вопросов производительности в общении, не мешает тебе подсознательно о ней всё время думать.


Подсознательно я думаю о недопущении преждевременной пессимизации. Об оптимизации я не думаю, разве что об алгоритмической, и то не всегда. Блин, да я вообще не помню, когда в последний раз держал в руках профилировщик.
Глаза у меня добрые, но рубашка — смирительная!
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.02.09 15:52
Оценка:
Здравствуйте, lomeo, Вы писали:

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


T>>>http://thesz.livejournal.com/509595.html

G>>Не надо доказывать что любую программу можно написать плохо. Это очевидно.

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

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

L>>>>>5) энергичные

G>>>>Лучше энергичность по-умолчанию, чем ленивость.
T>>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>>Как ленивость связана с модульностью?
L>Нет кучи имплементаций.
Ну для этого существует много других способов, в том числе обобщенное программирование (generics и автоматическая генерализация как в F#).

G>>ИМХО для не-списков ленивость поумолчанию не нужна.

L>Это потому что тебе показали только ленивые списки.
Ну так покажите пример ленивости по-умолчанию без списков, где в ней реально есть смысл.
Причем пример не надуманный.
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 16:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>А вот можно эту тему развить (только на пальцах, примеры на Haskell-е для меня как китайский язык)? Буду очень признателен. Особенно про то, как разделять отдельные mailslot-ы в программе.


Например, параметризовав их тип неким фиктивным типом. Или сделать сам S типом второго порядка, тогда использовать в нём можно будет только созданные там же мейлслоты. И т.д.

Без примеров на Haskell очень тяжело — для подобных вещей он наиболее выразителен.
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.02.09 16:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G>Хочется конечно, но кривой дизайн только средствами языка победить не получится.

Почему крайности? Почему обязательно "только"?

L>>Нет кучи имплементаций.

G>Ну для этого существует много других способов, в том числе обобщенное программирование (generics и автоматическая генерализация как в F#).

Возможно.
Можно пример, как можно сделать map с помощью generics чтобы его легко можно было использовать и лениво и энергично?

G>>>ИМХО для не-списков ленивость поумолчанию не нужна.

L>>Это потому что тебе показали только ленивые списки.
G>Ну так покажите пример ленивости по-умолчанию без списков, где в ней реально есть смысл.
G>Причем пример не надуманный.

Бесконечные структуры данных. Повышение переиспользования — за счёт склеивания — уже устал отсылать к Why FP matters.
Ну и потом с ленивостью по умолчанию элементарно писать надо меньше.
Да и вообще pure functional data structures как пример того, как может рулить ленивость по умолчанию.

Можно ещё это
Автор: lomeo
Дата: 17.12.08
почитать — там я гораздо больше написал.
Re[42]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 11.02.09 16:53
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?

T>>>>>Хороший доступней, плохой невозможней. Переход к лучшему проще.
LP>>>>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
T>>>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?
T>>>Уж больно тон уверенный.
T>>>Назови хотя бы парочку.
LP>>Тон уверенный, потому что я в этом уверен.
LP>>
LP>><module>
LP>>    <name>Module</name>
LP>>    <version>1.9.0_snapshot</version>
LP>>    <bin>module_1.9.0.dll</bin>
LP>>    <Entrants>
LP>>        ...
LP>>    </Entrants>
LP>></module>
LP>>

LP>>Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?

T>XML?


Я имел ввиду модуль, который описан данным XML-конфигом. Он может быть написан на чем угодно с применением чего угодно — это уровень реализации.

T>Эту штуку ты написал в функциональном стиле, как ты его понимаешь. И это только часть системы.


T>Систему целиком в функциональном стиле ты не проектировал, на навязывающем функциональный стиль ЯП ты не писал.


T>В каких пунктах я не прав?


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

LP>>При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.


T>ФЯ не даст тебе сделать некоторые виды интерфейсов.


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


Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.


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


T>С этого уровня, действительно, всё так и есть. Но этот уровень настолько тривиален, что пользоваться им нет особого смысла. Более того, он противопоказан в качестве обоснования каких-либо выводов насчёт системы.


T>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.


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

T>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.


Если реализация оказывает влияние, тогда проектирование неправильное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 21:46
Оценка:
T>>В каких пунктах я не прав?
LP>На хаскель я писал только простые примеры. И уж подавно ничего не проектировал. Но не нужно есть кашу, чтобы...

То есть, я прав по всем пунктам.

Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.

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

LP>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.

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

T>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.

LP>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.

Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?

T>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.

LP>Если реализация оказывает влияние, тогда проектирование неправильное.

Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.

Неужто твой контракт всегда может быть реализован в любой парадигме?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.02.09 21:58
Оценка:
T>>>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.
Q>>>И к сорока годам остеопороз с остеохондрозом.

T>>Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.


T>>ЗЫ

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

E>http://thesz.livejournal.com/757133.html:

E>

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


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

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

Вот уже два года, как.

И ещё: Дикуль.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 00:00
Оценка:
T>>Например, в переборных алгоритмах я могу просто породить бесконечное дерево вариантов, а потом натравить на него отсекатель. Создатель дерева ничего не знает о его получателе, получатель ничего не знает о создателе — последний может быть результатом какого-то отсечения.
T>>После ознакомления с этим вариантом решения он начинает возникать то тут, то там.
G>Ну для этого ленивость по-умолчанию не нужна. Вполне хватит ленивости на уровне библиотеки.

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

Кстати, один из критериев уровня ЯП — как сложно на нем писать библиотеки.

G>>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

T>>И как понять, какой он когда? А не станет ли он энергичным раньше времени?
G>А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.

То есть, он ленивый.

А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?

T>>Примеры в статье очень простые для простоты изложения и рассмотрения.

G>Менее надуманными они не становятся. Надуманными примерами можно много чего показать.

Это часть беседы с Gaperton. Он рассматривал отображение на списках, я продолжил эту тему.

Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить.

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

Буду признателен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 00:13
Оценка:
T>>Энергичность по умолчанию предпочитают из-за производительности.
Q>ЧСХ, ленивость по умолчанию многие тоже предпочитают из-за производительности. Дескать, она даёт возможность избежать ненужных вычислений.

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

T>>Никаких других плюсов энергичность по умолчанию не даёт.

Q>Даёт лучшую предсказуемость поведения (вспомни свои утечки невычисленных цепочек). (NB: Вот только не надо здесь поминать корень всех зол!)

Поведения программы — да. Поведения программиста — нет.

T>>В противном случае ты бы мыслил по-другому.

Q>Т. е. не как прагматик, а как фанатик?

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

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

T>>Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов.

Q>И что, в этом плане Haskell впереди планеты всей, на два корпуса обгоняя F# и Nemerle? Нет убедительных оснований так считать.

Синтаксис в Хаскеле наикратчайший (выразительность). Ленивая семантика и операторы позволяют создавать развесистые DSEL, наиболее близкие к самой проблеме. Высокая модульность вычислений. Система типов Хаскеля на десяток фич мощней системы типов F# или Nemerle.

Из последних назову GADT и общее направление движения в сторону зависимых типов.

Хотя и сейчас ты можешь сделать много мощного: например, проверять размеры массивов и прочее.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 04:25
Оценка:
Здравствуйте, eao197, Вы писали:

По штанге хоть и жуткий оффтоп, это такая штука и калечит и лечит
Re[44]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.02.09 05:51
Оценка:
Здравствуйте, thesz, Вы писали:


G>>>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

T>>>И как понять, какой он когда? А не станет ли он энергичным раньше времени?
G>>А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.

T>То есть, он ленивый.


T>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?

Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.

На C# так сделать не получится, нету оптимизации хвостовой рекурсии.
Хотя для бесконечной последовательности нулей в .NET есть более простые способы.

T>>>Примеры в статье очень простые для простоты изложения и рассмотрения.

G>>Менее надуманными они не становятся. Надуманными примерами можно много чего показать.

T>Это часть беседы с Gaperton. Он рассматривал отображение на списках, я продолжил эту тему.

T>Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить.
T>Одно условие — надо написать и в ленивом, и в энергичном стиле и хотя бы намекнуть, почему ленивый стиль будет хуже.
T>Буду признателен.
Я не говорил что будет хуже.
Я сомневаюсь что с ленивостью по умолчанию для не-списков будет лучше.
А учитывая приколы реализацией ленивости в хаскеле (утечки и прочее) может быть и гораздо хуже.
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 06:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

T>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?

G>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
G>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.

Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.
А F# похоже не только функторы по пути растерял
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.09 06:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом?

S>Поясняю еще раз: "императивный программист" — это программист, который мыслит императивными конструкциями. Это определение.

Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся? Нет? Тогда определение это не значит ровным счётом ничего. Пустышка. Нуль в знаменателе.

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

S>Это избыточные подробности. Ок, я могу расписать длиннее:

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

S>"императивное программирование" — применение императивных конструкций для записи программы


Допустим.

S>"императивный программист" — программист, у которого набор техник программирования ограничен императивными конструкциями.


Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то? И что такое "императивные конструкции", которыми, по идее, ограничен набор техник программирования у императивного программиста?

P.S.: И ещё не снята куча вопросов о способах мышления.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[46]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.02.09 07:22
Оценка:
Здравствуйте, FR, Вы писали:

FR>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.

FR>А F# похоже не только функторы по пути растерял

Да по моему любой язык с letrec должен нормально это кушать.
Re[44]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 12.02.09 07:32
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>В каких пунктах я не прав?

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

T>То есть, я прав по всем пунктам.


T>Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.


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

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

LP>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.

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


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

T>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.

LP>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.

T>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?


Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?

T>>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.

LP>>Если реализация оказывает влияние, тогда проектирование неправильное.

T>Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.


T>Неужто твой контракт всегда может быть реализован в любой парадигме?


Контракты, они конечно могут быть самыми разными. Например, некоторые предусловия императивного модуля в общем случае функциональнй модуль выполнить не сможет (в отличие от обратного случая). Но если сузить это понятие, скажем, до состояния структур данных, то да, практически при любой. К тому же я уже сказал, что "полностью функциональный модуль" — это сферический конь в вакууме. Для взаймодействия с остальными модулями разумнее использовать императивные интерфейсы и контракты. Это, конечно, мое мнение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 07:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся?

При чём тут миелофон?

ГВ>К сожалению, почти вся дискуссия показывает, что эти подробности не избыточны.

К сожалению, почти вся дискуссия показывает, что люди с заметным усердием занимаются terms misinterpretation. Причем цели этого намеренного непонимания лично мне остаются неясными.

ГВ>Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то?

Геннадий, не нужно включать дурака. Перечитай исходное сообщение, на которое ты столь невежливо ответил:

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

Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[47]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 07:50
Оценка:
Здравствуйте, gandjustas, Вы писали:


FR>>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.

FR>>А F# похоже не только функторы по пути растерял
G>Дык у него вообще ленивости на уровне языка нету.

Ключевое слово lazy тоже отсутствует?

G>Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.


В Ocaml это делается декларативно через Caml4p, например синтаксис потоков
http://shamil.free.fr/comp/ocaml/html/book004.html#htoc62 или даже ленивые списки
в Haskell стиле http://www.y-node.com/blog/2008/aug/04/ocamllazylists/
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 12.02.09 07:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>

S>Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию

Требование к глобальности состояния обязательное?
Если да, то почему?
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.09 09:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся?

S>При чём тут миелофон?

Про другие детекторы стиля мышления мне неизвестно.

ГВ>>К сожалению, почти вся дискуссия показывает, что эти подробности не избыточны.

S>К сожалению, почти вся дискуссия показывает, что люди с заметным усердием занимаются terms misinterpretation. Причем цели этого намеренного непонимания лично мне остаются неясными.

Ой, сколько колкостей по этому поводу вертится у меня на клавиатуре... Ладно, замнём для ясности.

ГВ>>Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то?

S>Геннадий, не нужно включать дурака. Перечитай исходное сообщение, на которое ты столь невежливо ответил:
S>

S>Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию


Не надо выдёргивать цитату из контекста:

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


Честно говоря, после "стиль мышления" я выпал в настолько плотный осадок, что остальное уже было несущественным. То есть "плавный" переход от субъекта к объекту остался незамеченным. То есть ты называешь способ декомпозиции стилем мышления. Эх, сила слова! Ух, полёт мысли!

Не дела ради, а курьёзу для, попробуем обсудить означенный тобой способ декомпозиции и возможность его существования. И здесь вопросов снова больше, чем ответов. Например, так ли уж любой алгоритм подвергается привязке только к глобальным данным? Кроме того, если набор императивных конструкций ограничен модификацией, переходом и ветвлением (условным переходом), то по логике вещей, и вся программа должна представлять собой сплошной спагетти из if/goto. Если это так, то напрашивается мысль о том, что "императивный программист" — это либо сферический конь в вакууме, либо, в крайнем случае, очень-очень начинающий, поскольку на практике такие программы хоть и бывают, но они либо весьма ограничены в размерах, либо встречаются крайне редко. Оба предполагаемых явления не слишком достойны того, чтобы с ними бороться. Либо я чего-то в твоих рассуждениях не понимаю.

P.S.: Вопрос о мышлении по-прежнему остаётся открытым.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 09:14
Оценка:
T>>То есть, я прав по всем пунктам.
T>>Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.
LP>Ты спрашиваешь у меня, проектировал ли я системы на Хаскеле, в том время как систем-то этих если и есть, то три штуки на всю планету.

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

Даже на RSDN найдётся десяток-другой товарищей, проектировавших такие системы.

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


С чего бы это? Возражать мне можно, но обоснованно возражать получится после того, как приобретёшь опыт.

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

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

Но ты можешь продолжать возражать.

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

LP>>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.

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


"Абсолютно бесполезна".

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

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


ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.

T>>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.

LP>>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
LP>Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?

Меня смущает состояние. Императивщина.

T>>>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.

LP>>>Если реализация оказывает влияние, тогда проектирование неправильное.
T>>Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.
T>>Неужто твой контракт всегда может быть реализован в любой парадигме?
LP>Контракты, они конечно могут быть самыми разными. Например, некоторые предусловия императивного модуля в общем случае функциональнй модуль выполнить не сможет (в отличие от обратного случая). Но если сузить это понятие, скажем, до состояния структур данных, то да, практически при любой. К тому же я уже сказал, что "полностью функциональный модуль" — это сферический конь в вакууме. Для взаймодействия с остальными модулями разумнее использовать императивные интерфейсы и контракты. Это, конечно, мое мнение.

Ну, вот и реализация вылезла.

Ура!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[48]: "LINQ как шаг к ФП". Стиль изложения.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.02.09 09:32
Оценка:
Здравствуйте, FR, Вы писали:

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



FR>>>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.

FR>>>А F# похоже не только функторы по пути растерял
G>>Дык у него вообще ленивости на уровне языка нету.

FR>Ключевое слово lazy тоже отсутствует?

lazy — сахар для Lazy<T>. Причем вы можете свой аналогичный сахар в F# делать в любых количествах.

G>>Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.


FR>В Ocaml это делается декларативно через Caml4p, например синтаксис потоков

FR>http://shamil.free.fr/comp/ocaml/html/book004.html#htoc62 или даже ленивые списки
FR>в Haskell стиле http://www.y-node.com/blog/2008/aug/04/ocamllazylists/
Круто, может когда-нибудь ркуи дойдут до изучения окамла.
Re[49]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 09:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

FR>>Ключевое слово lazy тоже отсутствует?

G>lazy — сахар для Lazy<T>.

Так и в окамле lazy сахар для lazy_t

G>Причем вы можете свой аналогичный сахар в F# делать в любых количествах.


Интересно как?
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 10:14
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Требование к глобальности состояния обязательное?
Да.
EC>Если да, то почему?
Потому, что контекстов, в которых состояние могло бы быть локально, еще нету. Любая операция в программе может воспользоваться результатами любой другой. См. Машина Тьюринга, Машина Поста.

Для того, чтобы у понятия "локальное состояние" появился смысл, нужно вводить некие контексты. Чем, в частности, занимается процедурное программирование (как развитие императивного).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 10:20
Оценка:
T>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?
G>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
G>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.
G>На C# так сделать не получится, нету оптимизации хвостовой рекурсии.
G>Хотя для бесконечной последовательности нулей в .NET есть более простые способы.

Это была прелюдия.

А вот основная тема: Generating power of lazy semantics

zeroes — это нулевой бесконечный степенной ряд.

Если нужна ленивость по умолчанию не для списков, то можешь попробовать multivariate higher-order automatic differentiation. Ноотропил стоит в районе 200-250 рублей за упаковку, однако, поэтому это может быть достаточно дорогое удовольствие.

T>>Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить.

T>>Одно условие — надо написать и в ленивом, и в энергичном стиле и хотя бы намекнуть, почему ленивый стиль будет хуже.
T>>Буду признателен.
G>Я не говорил что будет хуже.
G>Я сомневаюсь что с ленивостью по умолчанию для не-списков будет лучше.
G>А учитывая приколы реализацией ленивости в хаскеле (утечки и прочее) может быть и гораздо хуже.

Внимание, вопрос: как бывает наиболее часто? Хуже или лучше? Как изменяется пропорция "хуже-лучше" со временем?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 10:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Про другие детекторы стиля мышления мне неизвестно.

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

ГВ>Не надо выдёргивать цитату из контекста:


ГВ>

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


ГВ>Честно говоря, после "стиль мышления" я выпал в настолько плотный осадок, что остальное уже было несущественным.

Наличие осадка вижу. Причин считать остальное несущественным — не вижу.

ГВ>То есть "плавный" переход от субъекта к объекту остался незамеченным. То есть ты называешь способ декомпозиции стилем мышления.

Хорошо. Речь идет о стиле мышления, для которого типичен именно указанный способ декомпозиции.
Суть беседы пока что сводится к тому, что выражение "У Мэри есть ягненок" тебя не устраивает, а самостоятельно выполнить переход к "гражданка Мария Джонс осуществляет ограниченное право владения объектом животноводства, не достигшим репродуктивного возраста" ты не хочешь.

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

Отлично. Достаточно подробно вопрос существования такого способа декомпозиции программ освещен в работах Тьюринга, Поста, Чёрча, и многих других.

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

Данные, которыми оперирует машина Тьюринга, вполне себе глобальны. Есть какие-то вопросы о возможности реализации любого алгоритма машиной Тьюринга?

ГВ>Кроме того, если набор императивных конструкций ограничен модификацией, переходом и ветвлением (условным переходом), то по логике вещей, и вся программа должна представлять собой сплошной спагетти из if/goto.

Совершенно верно. См. например алгоритм Евклида. Есть какие-то сомнения в том, что он представляет собой сплошное спагетти из if/goto и присваиваний?

ГВ>Если это так, то напрашивается мысль о том, что "императивный программист" — это либо сферический конь в вакууме,

Ага, похоже начинаются проблески понимания.
ГВ>либо, в крайнем случае, очень-очень начинающий, поскольку на практике такие программы хоть и бывают, но они либо весьма ограничены в размерах, либо встречаются крайне редко.
Совершенно верно. Расширим модель "императивного программиста" до "процедурного программиста".
У него в арсенале появляются новые конструкции, в частности процедуры.
Это даёт ему более богатые возможности декомпозиции алгоритма, но принципиально ничего не меняется — по-прежнему есть разделяемое состояние, с которым идет работа. По-прежнему основным инструментом является if, иногда замаскированный под while/for/until. Даже итерация по массиву/списку выполняется при помощи явной модификации переменной.

ГВ>Оба предполагаемых явления не слишком достойны того, чтобы с ними бороться. Либо я чего-то в твоих рассуждениях не понимаю.

Не вижу ничего особенно редкого в императивном программировании. Вон по соседству Павел Дворкин постоянно съезжает на то, что декларативное программирование мешает ему точно указать, в каком порядке в какие регистры складывать данные.

ГВ>P.S.: Вопрос о мышлении по-прежнему остаётся открытым.

Многие вещи непонятны нам не оттого, что понятия наши слабы, а оттого, что они не входят в круг наших понятий. Это не о тебе, а об "императивных программистах". Влад пытается расширить круг понятий у тех людей, у которых он узкий. Не вижу причин считать это личным оскорблением.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 12.02.09 10:38
Оценка:
Здравствуйте, thesz, Вы писали:

T>Но ты можешь продолжать возражать.


Если вам угодно, воспользуюсь столь милостивым разрешением и продолжу спор.

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

LP>>>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.

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


T>"Абсолютно бесполезна".


T>К сведению. Подавляющее большинство программ может быть написана на не-Тьюринг-полных языках. То есть, на чистом тотальном ФЯ.


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


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


Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

T>>>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.

LP>>>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>>>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
LP>>Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?

T>Меня смущает состояние. Императивщина.


Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?

То есть будет висеть такое состояние:

State a;

И вместо того, чтобы каждая функция изменяла этот a, сделать изменение этого состояния через функции

State cleanFunction(State)

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

В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 11:39
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?
Я рассматриваю процедурное программирование как развитие императивного: то есть мы добавляем в императивное программирование пару конструкций, которые позволяют нам быстрее писать программы. Тем не менее, главное остаётся на месте: у нас по-прежнему есть неявное глобальное (с точки зрения операторов) состояние, которым мы манипулируем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.02.09 11:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

EC>>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?

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

Получается, что вот здесь у нас есть состояние:
int sum( int[] a ) {
  int r = 0;
  for( int i = 0; i != a.length; ++i )
    r += a[ i ];
  return r;
}

А вот здесь его уже нет?
int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 12.02.09 12:05
Оценка:
Здравствуйте, eao197, Вы писали:

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


EC>>>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?

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

E>Получается, что вот здесь у нас есть состояние:

E>
E>int sum( int[] a ) {
E>  int r = 0;
E>  for( int i = 0; i != a.length; ++i )
E>    r += a[ i ];
E>  return r;
E>}
E>

E>А вот здесь его уже нет?
E>
E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, i + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>


Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[47]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 12:17
Оценка:
T>>ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.
LP>Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

Вообще-то, это всё вычисления.

T>>Меня смущает состояние. Императивщина.

LP>Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?
LP>То есть будет висеть такое состояние:
LP>State a;
LP>И вместо того, чтобы каждая функция изменяла этот a, сделать изменение этого состояния через функции
LP>State cleanFunction(State)
LP>и потом собирать изменения в ограниченном числе императивных функции, тем более хаскель позволяет отделять такие функции по типу.
LP>В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?

Таким образом мы не сможем спроектировать дизайн на потоках. Ни на бесконечных списках, ни на потоковых процессорах.

Наличие состояния затрудняет масштабирование решения. В отличии от отсутствия состояния.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 13:02
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Нельзя ли конкретизировать эти конструкции? Хотя бы пару ключевых.

Какой-то повальный отказ от чтения сообщений. Я уже приводил эти конструкции.
Главные, естественно, это выбор, присванивание, и переход.

EC> И указать роль глобального состояния в нём.

Очень просто. Вот у нас простейшая процедурная программа по возведению числа в 5ю степень:
public int Power5(int x)
{
  int power5 = x;
  power5 = power11*x;
  power5 = power11*x;
  power5 = power11*x;
  power5 = power11*x;
  return power5;
}

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

EC>А то получается, что оно вроде как тоже императивное, но из твоего определения совершенно неясно в какой степени к нему применимы рассуждения справедливые для императивного.

В полной степени, в полной.
EC>Мне вот неочевидно почему в нём обязательно должно быть глобальное состояние.
А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 13:06
Оценка:
Здравствуйте, eao197, Вы писали:

E>Получается, что вот здесь у нас есть состояние:

E>
E>int sum( int[] a ) {
E>  int r = 0;
E>  for( int i = 0; i != a.length; ++i )
E>    r += a[ i ];
E>  return r;
E>}
E>

E>А вот здесь его уже нет?
E>
E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, i + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>

Совершенно верно. Ну, то есть если мы откажемся от концепции return как таковой, и станем трактовать конструкции как определение смысла функции, тогда получится в чистом виде FP. Никаких присваиваний нет; никакого состояния тоже нет — программа описывает только непреложные факты. Вроде того, что сумма всех чисел в массиве — это сумма одного числа с суммой всех остальных. Этот факт истинен всё время, а не только в момент выхода из подпрограммы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 13:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.


let rec power5 x =
    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.09 13:23
Оценка:
Здравствуйте, FR, Вы писали:
FR>
FR>let rec power5 x =
FR>    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;
FR>

Прекрасный пример выхода за пределы императивного мышления. Именно этим трюкам и пытается научить Влад в своей статье
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 12.02.09 13:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Очень просто. Вот у нас простейшая процедурная программа по возведению числа в 5ю степень:

S>
S>public int Power5(int x)
S>{
S>  int power5 = x;
S>  power5 = power11*x;
S>  power5 = power11*x;
S>  power5 = power11*x;
S>  power5 = power11*x;
S>  return power5;
S>}
S>

S>Обрати внимание, что у нас есть некая переменная power5, состояние которой последовательно меняется. Результат последнего оператора напрямую, но неявно, зависит от того, что положил в эту переменную первый оператор. Это и есть глобальное, с точки зрения отдельных операторов, состояние.
S>Вся локальность power5 сводится к тому, что мы запрещаем вмешиваться в ее состояние другим процедурам.
S>Стоит также отметить, что уже здесь мы пользуемся процедурой умножения, которая тоже может быть записана как определенная последовательность ветвлений и присваиваний. То, что в реальных архитектурах такая операция доступна "из коробки", для теории значения не имеет.
Глобальное, с точки зрения отдельных операторов, состояние — это весьма странный зверь.
Под глобальными переменными, обычно, понимают переменные доступные в любой области видимости.
Конструкция, описанная тобой какая-то совершенно искуственная.
Какая от неё польза?

EC>>Мне вот неочевидно почему в нём обязательно должно быть глобальное состояние.

S>А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.
Глобального состояния (в традиционном его понимании) там нет.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 12.02.09 13:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

EC>>Конструкция, описанная тобой какая-то совершенно искуственная.

EC>>Какая от неё польза?
S>Не понимаю вопроса. Польза от чего? От этой убогой программы? Ну, она умеет возводить числа в пятую степень.
Не прикидывайся, ты даже верно процитировал.
Имелось в виду твоё изобретение под названием глобальное, с точки зрения отдельных операторов, состояние.

S>Достаточно того, что есть состояние, изменяющееся во времени. Даже если написать эту же программу в виде

S>
S>return x*x*x*x*x;
S>

S>Всё равно будет состояние, хоть и неявное. Потому, что спецификация императивного ЯП подразумевает вот такую семантику:
S>
S>temp1 = x;
S>temp2 = temp1*x;
S>temp3 = temp2*x;
S>temp4 = temp3*x;
S>temp5 = temp4*x;
S>return temp5;
S>

S>И никуда ты от этого не денешься, пока не начнешь искать не способ представить алгоритм в виде последовательных трансформаций некоего состояния, а как способ описания зависимостей.
Совсем недавно ты настаивал на глобальности состояния, это меня и удивило.
Re[51]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.02.09 17:05
Оценка:
G>>>Причем вы можете свой аналогичный сахар в F# делать в любых количествах.
FR>>Интересно как?
G>Вот так http://www.infoq.com/articles/pickering-fsharp-workflow

"Не надо путать причину и следствие. Особенно не надо путать следствие." (C) Кнышев

Це ж описание монад. Как следствие, не надо его путать с ленивыми вычислениями.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[52]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 12.02.09 17:09
Оценка:
Здравствуйте, thesz, Вы писали:

T>"Не надо путать причину и следствие. Особенно не надо путать следствие." (C) Кнышев


T>Це ж описание монад. Как следствие, не надо его путать с ленивыми вычислениями.


Мы уже с ленивости на сахар переключились
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 04:26
Оценка:
Здравствуйте, Gajdalager, Вы писали:
G>Подожди-подожди... Почему это вдруг эти переменные стали состоянием, да ещё и глобальным?
Переменные == состояние. По определению.
G>Давай напишем так:
G>
G>return x * (\x -> x * x (x)); // Упростили к кубу
G>[c#]
Не понял, что это за синтаксис. Можно пояснить, где здесь что? Имеется в виду вот это:
[c#]
return x * ((int a) => a*a) (x);

Так что ли?
G>Умножаем х на результат вычисления лямбды. Где состояние? В регистрах? А они здесь при чём? Это детали реализации.
Ну давайте разберемся. Семантика C# такова, что мы получим примерно вот это:
var square = Func<int, int>(a => a*a);
var temp = square(x);
var temp2 = temp*x;
return x;

Введением императивной лямбды ты ничего не добьешься — это по-прежнему тот же самый пример с x*x*x*x. Такая лямбда — всего лишь еще один, более компактный способ описания процедур. Ровно с тем же успехом ты мог ее описать заранее, как Power2(x) и вызвать по месту. По-прежнему связь результата power5 и аргумента выражена неявно, через цепочку трансформаций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 07:46
Оценка:
Здравствуйте, FR, Вы писали:

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


S>>Введением императивной лямбды ты ничего не добьешься — это по-прежнему тот же самый пример с x*x*x*x. Такая лямбда — всего лишь еще один, более компактный способ описания процедур. Ровно с тем же успехом ты мог ее описать заранее, как Power2(x) и вызвать по месту. По-прежнему связь результата power5 и аргумента выражена неявно, через цепочку трансформаций.


FR>По моему ты зря нажимаешь на реализацию.

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

Тот код на Ocaml который я выше привел тоже транслируется в очень даже императивное:
Совершенно неважно, во что именно он транслируется. Понятно, что внутре у ней неонка... тьфу, то есть императивный процессор, у которого неизбежно есть состояние.
Но завтра ты скачаешь новый компилятор, и код будет транслироваться во что-то другое. Речь именно о семантике программы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 13.02.09 07:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

FR>>По моему ты зря нажимаешь на реализацию.

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

Вот этот код на D
int power5(int x) pure
{
    return x * x * x * x *x;
}


Уже непросто выглядит функциональным, но и семантически чистый.
В общем по моему грань слишком тонкая.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 08:17
Оценка:
Здравствуйте, FR, Вы писали:

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

FR>В общем по моему грань слишком тонкая.
Между чем и чем? Между декларативным и императивным? Не вижу никакой тонкости грани.
То, что существует полная эквивалентность туда и обратно — ну так это опять же еще Черч показал.
То, что можно внедрять в императивный в целом язык декларативные элементы — тоже нифига не новость.
Вот я на SQL пишу:

update employee set salary = salary +200 where lastname like 'D%'
update employee set salary = salary*1.2 where firstname like 'J%'

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

Поэтому мы возвращаемся к вопросу мышления — императивному программисту претит вот эта декларативная неопределенность; он инстинктивно стремится к переменным и циклам.
А декларативному программисту напротив, не нравится вот эта вот зависимость результата от порядка выполнения.
Ему комфортнее работать с
create view Salary2009 as select id, salary+200 as salary from employee where lastname like 'D%'
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.09 08:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, то есть если мы откажемся от концепции return как таковой


От концепции return не отказываются даже в функциональных языках, там просто отказываются от ключевого слова return. В том же примере FR:
let rec power5 x =
    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;

уши этой концепции торчат наружу.

S>Никаких присваиваний нет; никакого состояния тоже нет — программа описывает только непреложные факты.


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

S>Вроде того, что сумма всех чисел в массиве — это сумма одного числа с суммой всех остальных. Этот факт истинен всё время, а не только в момент выхода из подпрограммы.


Ерунда. На любом произвольном шаге исполнения функциональной версии sum (с рекурсивными вызовами sum_impl) есть только текущее значение, которое станет результатом (т.е. истинным фактом) только после завершения всего вычисления.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 08:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>От концепции return не отказываются даже в функциональных языках, там просто отказываются от ключевого слова return. В том же примере FR:

E>
E>let rec power5 x =
E>    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;
E>

E>уши этой концепции торчат наружу.
Не вижу никаких ушей. Это не return, это тождество. Вот в учебнике математики за пятый класс, когда мы говорим "пусть x равно y+z", мы что, что-то куда-то вернули?

E>Состояние просто перенесно из изменяемых переменных на стек, но оно все равно в явном виде присутствует -- при организации рекурсивного вызова sum_impl программист должен явно его определять (вычисляя аргументы рекурсивного вызова).

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

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

Это артефакты конкретных реализаций. С точки зрения частично вычислимых функций, совершенно неважно, является ли рекурсия хвостовой.

E>Ерунда. На любом произвольном шаге исполнения функциональной версии sum (с рекурсивными вызовами sum_impl) есть только текущее значение, которое станет результатом (т.е. истинным фактом) только после завершения всего вычисления.

О каком еще "шаге" мы говорим? С учетом того, что у функций нет побочных эффектов, компилятор имеет полное право вообще отказаться от шагов вычисления и брать результат напрямую из таблицы. "Шаг" может появиться только после преобразования декларативной программы в императивную. То, что тебе очевиден ровно один такой способ преобразования, не означает, что применяться будет именно он.
В частности, хитрый компилятор может раскрыть скобки и получить, что power 5 =1 * x * x * x * x * x, воспользоваться ассоциативностью умножения и получить эквивалент
let rec power5 x =
let rec aux a = a * a in x * aux aux x
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.02.09 09:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Честно говоря, после "стиль мышления" я выпал в настолько плотный осадок, что остальное уже было несущественным.

S>Наличие осадка вижу. Причин считать остальное несущественным — не вижу.

Да как тебе сказать, ИМХО, этот самый "стиль мышления" — причина настолько могучая, что встретив такое в околотехническом тексте остальное можно смело не читать.

ГВ>>То есть "плавный" переход от субъекта к объекту остался незамеченным. То есть ты называешь способ декомпозиции стилем мышления.

S>Хорошо. Речь идет о стиле мышления, для которого типичен именно указанный способ декомпозиции.

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

S>Суть беседы пока что сводится к тому, что выражение "У Мэри есть ягненок" тебя не устраивает, а самостоятельно выполнить переход к "гражданка Мария Джонс осуществляет ограниченное право владения объектом животноводства, не достигшим репродуктивного возраста" ты не хочешь.


Я против того, чтобы узнав о том, что у Мэри есть ягнёнок, в её адрес фыркали: "Глупая пастушка, фи!" А у Влада, в отличие от других авторов аналогичных пассажей, именно так и получается. Ты льёшь воду на ту же мельницу.

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

S>Отлично. Достаточно подробно вопрос существования такого способа декомпозиции программ освещен в работах Тьюринга, Поста, Чёрча, и многих других.

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

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

S>Данные, которыми оперирует машина Тьюринга, вполне себе глобальны. Есть какие-то вопросы о возможности реализации любого алгоритма машиной Тьюринга?

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

ГВ>>Кроме того, если набор императивных конструкций ограничен модификацией, переходом и ветвлением (условным переходом), то по логике вещей, и вся программа должна представлять собой сплошной спагетти из if/goto.

S>Совершенно верно. См. например алгоритм Евклида. Есть какие-то сомнения в том, что он представляет собой сплошное спагетти из if/goto и присваиваний?

Нет сомнний, но это же и есть та самая короткая программа, о которой я сказал.

ГВ>>Если это так, то напрашивается мысль о том, что "императивный программист" — это либо сферический конь в вакууме,

S>Ага, похоже начинаются проблески понимания.



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

S>Совершенно верно. Расширим модель "императивного программиста" до "процедурного программиста".

Зачем? Речь шла об императивном программисте.

S>У него в арсенале появляются новые конструкции, в частности процедуры.

S>Это даёт ему более богатые возможности декомпозиции алгоритма, но принципиально ничего не меняется — по-прежнему есть разделяемое состояние, с которым идет работа. По-прежнему основным инструментом является if, иногда замаскированный под while/for/until. Даже итерация по массиву/списку выполняется при помощи явной модификации переменной.

Сиречь, имеем комбинацию императивного и какого-то другого подхода.

ГВ>>Оба предполагаемых явления не слишком достойны того, чтобы с ними бороться. Либо я чего-то в твоих рассуждениях не понимаю.

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

Я тоже не вижу ничего редкого в императивном программировании самом по себе (то есть в использовании приёмов, классифицируемых как ИП). Если ты не понял, то я говорил о "чистом императивном программировании", которым, якобы, занимается пресловутый "императивный программист".

ГВ>>P.S.: Вопрос о мышлении по-прежнему остаётся открытым.

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

Мда. Чудесатее и чудесатее. Антон, ты хоть понимаешь, о чём я толкую?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 10:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>Программирование -- это не математика. Если бы было по другому, то запись 'a=b' разражала бы всех программистов, а не только Вирта с Мейром.

Есть разные виды программирования.

E>как все очень и очень серьезно меняется. Хотя смысл остается тем же самым.

Это артефакт поведения конкретного компилятора конкретного языка.

E>А на счет изменности функций:

E>
E>int sum( int[] a ) {
E>  int r = 0;
E>  for( int i = 0; i != a.length; ++i )
E>    r += a[ i ];
E>  return r;
E>}
E>

E>Чем эта функция изменна?
Не понял вопрос. Вам непонятно, что r является изменчивым состоянием? что i является изменчивым состоянием, и даже банальное доказательство того факта, что ни одно из обращений не выходит за пределы границ массива является нетривиальным?

E>Еще раз, программирование -- это не математика. Нет никакого толка от функции sum, если она не может вычислить сумму элементов массива из 10M элементов из-за нехватки стека.

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

E>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность.

Вот этого не понял.
E>В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
Смысл этого выражения существенно зависит от того, о какой именно математике мы говорим. Если a и b являются членами конечной группы размером 2^32, то в программировании и в математике выражение будет иметь совершенно одинаковый смысл.

E>Например, об очередном вызове sum_impl.

Вы путаете два различных мира. Концепция "вызова" — это процедурное программирование. От императивного программирования в нём есть понятие "instruction pointer" — инструкции, выполняемой в данный момент. Плюс паттерн "вызов с возвратом", который строится из запоминания текущего ip, последующего goto, и восстановления ip+1 в будущем.

E>Какие побочные эффекты у приведенной выше императивной функции sum?

У приведенной выше — никаких. Поэтому хороший компилятор избавляется от излишней императивности в меру своих возможностей.
E>Из какой таблицы? Из какой таблицы компилятор может подставить значение функции sum для произвольного массива?
В функции power5 никакого массива не было.

E>Ну да, конечно. Шаг рекурсии в ФП -- это, определенно, совсем другое дело, чем шаг цикла в ИП.

Воот. Начинаешь понимать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.09 11:22
Оценка:
Здравствуйте, Курилка, Вы писали:

К>a и b — логические предикаты (или ещё лучше прямые на плоскости), объясни математический смысл выражения a-b


Если не трындеть, то достаточно сказать, что при преобразовании многих алгоритмов в программы программистам в компании с математиками приходится заниматься тем, чтобы при вызове sqrt не возникала ошибка DOMAIN_ERROR и чтобы разность двух близких значений помещалась в double без каких-либо обращений в ноль.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 13.02.09 11:45
Оценка:
E>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность. В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
К>a и b — логические предикаты (или ещё лучше прямые на плоскости), объясни математический смысл выражения a-b

В геометрической алгебре есть смысл этого выражения, по-моему. Это пересечение дополнений (дуальных элементов, по-моему) a и b.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.09 12:25
Оценка:
Здравствуйте, eao197, Вы писали:
E>По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?
Функция aux ничего не говорит о каких-либо изменениях. Она задает отображение входных параметров на выходные, безо всяких промежуточных "шагов".

E>Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.

Ничего подобного. Аргументы в FP-подходе — это всего лишь обозначения. У них никакого "состояния нет"; они не изменяются во времени. В ФП все r и i — различные. Да, в некоторых частных случаях императивные программы ведут себя так же. Но это никак не отменяет всех остальных императивных программ.


E>Ok. Имеем чистую функциональную функцию:

E>
E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, index + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>

E>Или ее аналог в OCaml (навскидку):
E>
E>let rec sum a =
E>  let rec sum_impl a index size acc =
E>    if index = size then acc
E>    else sum_impl a (index+1) size (acc+a[index])
E>  in
E>    sum_impl a 0 a.length 0
E>

E>Проверка выхода за границы массива стала тривиальнее?
Конечно. Если компилятор вообще заботится о таких вещах, как корректность программы, то он должен сразу дать по рукам за такую программу. И заставить ее переписать так, чтобы требование на неотрицательность индекса было явно выражено в типе аргумента — или соответствующий guard появился в теле sum_impl. И заменить != a.length на < a.length
S>>Еще раз: для чистой функции никаких причин жрать стек такими объемами нету вообще. Если компилятор неспособен свести ее потребление памяти к двум регистрам — это проблемы компилятора, а не ФП.

E>Хорошо, что позволит компилятору свести потребление памяти к минимуму вот в такой реализации:

E>
E>let rec sum a =
E>  let rec sum_impl a index size =
E>    if index = (size-1) then a[index]
E>    else a[index] + (sum_impl a (index+1) size)
E>  in
E>    sum_impl a 0 a.length
E>

E>?

E>>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность.

E>>>В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
S>>Вот этого не понял.

E>Разность двух близких действительных чисел может не иметь представления в виде числа на компьютере.


E>>>Какие побочные эффекты у приведенной выше императивной функции sum?

S>>У приведенной выше — никаких.

E>Здорово -- побочных эффектов нет, зато состояние есть.


S>>Поэтому хороший компилятор избавляется от излишней императивности в меру своих возможностей.


E>Уж компилятор просто вынужден всю имеющуюся в программе функциональщину сводить к самой дебильной императивности в виде инструкций процессора. Это если мы еще не начали говорить о сферических конях в вакууме.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 10:46
Оценка:
Здравствуйте, FR, Вы писали:

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


LP>>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.


FR>Кстати стека не будет, там хвостовая рекурсия.


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

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}


итеративный.

Давай его перепишем, чтобы он стал рекурсивным:

int sum( int[] a ) {
    int sum_impl( int[] a, int index ) {
            if( index != a.length )
                return a[ index ] + sum_impl( a, i + 1);
            else
                return a[ index ];
    }
    return sum_impl( a, 0);
}


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

По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 11:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?
S>Функция aux ничего не говорит о каких-либо изменениях. Она задает отображение входных параметров на выходные, безо всяких промежуточных "шагов".

E>>Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.

S>Ничего подобного. Аргументы в FP-подходе — это всего лишь обозначения. У них никакого "состояния нет"; они не изменяются во времени. В ФП все r и i — различные. Да, в некоторых частных случаях императивные программы ведут себя так же. Но это никак не отменяет всех остальных императивных программ.


E>>Ok. Имеем чистую функциональную функцию:

E>>
E>>int sum( int[] a ) {
E>>  int sum_impl( int[] a, int index, int result ) {
E>>    if( index != a.length )
E>>      return sum_impl( a, index + 1, result + a[ index ] );
E>>    else
E>>      return result;
E>>  }
E>>  return sum_impl( a, 0, 0 );
E>>}
E>>

E>>Или ее аналог в OCaml (навскидку):
E>>
E>>let rec sum a =
E>>  let rec sum_impl a index size acc =
E>>    if index = size then acc
E>>    else sum_impl a (index+1) size (acc+a[index])
E>>  in
E>>    sum_impl a 0 a.length 0
E>>

E>>Проверка выхода за границы массива стала тривиальнее?
S>Конечно. Если компилятор вообще заботится о таких вещах, как корректность программы, то он должен сразу дать по рукам за такую программу. И заставить ее переписать так, чтобы требование на неотрицательность индекса было явно выражено в типе аргумента — или соответствующий guard появился в теле sum_impl. И заменить != a.length на < a.length
S>>>Еще раз: для чистой функции никаких причин жрать стек такими объемами нету вообще. Если компилятор неспособен свести ее потребление памяти к двум регистрам — это проблемы компилятора, а не ФП.

Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет. Например, во второй функции eao никакого ФП, на мой взгляд, и нет, поскольку единственное, чем отличается эта функция от первой — это закидывание изменяемого состояния в стек. Примерно 50 процентов чистых функций, которые с гордостью демонстрируют функциональщики — это беззастеничивая, едва прикрытая императивщина, как в данном случае.
Можно, конечно, сказать, что ФП — это когда изменение состояния происходит на стеке, а не с помощью деструктивного присваивания. Но тогда давайте честно говорить, что всякий итеративный процесс выглядит одинаково и в императивной реализации при помощи дестр. присваивания, и в случае реализации через рекурсию.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[48]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 11:38
Оценка:
Здравствуйте, thesz, Вы писали:

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

LP>>Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

T>Вообще-то, это всё вычисления.


С чего это?

T>>>Меня смущает состояние. Императивщина.

LP>>Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?
LP>>То есть будет висеть такое состояние:
LP>>State a;
LP>>И вместо того, чтобы каждая функция изменяла этот a, сделать изменение этого состояния через функции
LP>>State cleanFunction(State)
LP>>и потом собирать изменения в ограниченном числе императивных функции, тем более хаскель позволяет отделять такие функции по типу.
LP>>В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?

T>Таким образом мы не сможем спроектировать дизайн на потоках. Ни на бесконечных списках, ни на потоковых процессорах.


T>Наличие состояния затрудняет масштабирование решения. В отличии от отсутствия состояния.


Так я же не предлагаю его городить на каждом шаге. Вообще, и при ООП проектировании от лишнего состояния стараются избавиться, так как понятно, что состояние есть узкое место, затрудняющее масштабирование. Если модуль может быть реализован без состояния, он должен быть реализован без состояния. А в тех случаях, когда это невозможно, тогда и можно применять подход, который я привел.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 11:47
Оценка:
LP>Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет. Например, во второй функции eao никакого ФП, на мой взгляд, и нет, поскольку единственное, чем отличается эта функция от первой — это закидывание изменяемого состояния в стек. Примерно 50 процентов чистых функций, которые с гордостью демонстрируют функциональщики — это беззастеничивая, едва прикрытая императивщина, как в данном случае.

Не, все же, думаю, это слишком категоричное утверждение. ФП — это когда отсутствует деструктивное присваивание и вообще изменение состояния непосредственно. Когда оно присутствует на стеке, как в случае с result, думаю, можно называть ФП. Но при этом нужно помнить, что никакой разницы в вычислительном процессе, который описывается циклом и хвостовой рекурсией, нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 16.02.09 11:52
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


Мне кажется не стоит путать итеративное и императивное.
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 16.02.09 11:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


ФП вполне четко определенная вещь. Есть чистота есть ФП, нет чистоты нет ФП. Все обсалютно прозрачно и вполне уловимо.

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


От того что итеративный процесс можно реализовать как функционально так и императивно не делает функциональную реализацию императивной.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: criosray  
Дата: 16.02.09 11:59
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>Мне кажется не стоит путать итеративное и императивное.


Как их можно путать? Это понятия разных категорий.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 12:00
Оценка:
Здравствуйте, FR, Вы писали:

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


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


FR>Мне кажется не стоит путать итеративное и императивное.


Я даже не знаю. Интуитивно мне кажется, что итеративное суть императивное, ибо разница только в способе записи. Но с другой стороны, отсутствует явное деструктивное присваивание, первый признак императивщины.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 12:02
Оценка:
Здравствуйте, criosray, Вы писали:

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


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


FR>>Мне кажется не стоит путать итеративное и императивное.


C>Как их можно путать? Это понятия разных категорий.


Понятия совершенно разные, но при этом от функциональной реализации итеративного процесса отдает сильной императивщиной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 16.02.09 12:04
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Я даже не знаю. Интуитивно мне кажется, что итеративное суть императивное, ибо разница только в способе записи. Но с другой стороны, отсутствует явное деструктивное присваивание, первый признак императивщины.


По моему чистая психология, как например то, что некторые ООП программисты убеждены что инкапсуляцию и полиморфизм придумали в и только для ООП и без нее они не сущесттвуют
Re[23]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.02.09 12:48
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет.

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

x = 10;
x = x+2;

А тут — уже нету:

x = 10;
y = x+2;


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

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

А вот эта "неуловимость" ФП связана как раз с ФП/ИП дуализмом: если избегать деструктивных присваиваний в процедурной программе, то она будет совпадать с некоторой функциональной программой с точностью до синтаксиса. А если ввести компонент "состояние" в результаты, над которыми оперируют функции в ФП программе, получим императивный алгоритм.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 12:55
Оценка:
Здравствуйте, Константин Б., Вы писали:

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


LP>>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.


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


Это просто фантастика какая-то. "Компилятор может реализовать как угодно" — возможно, через тридцать лет и будет такое, но пока компилятор делает именно то, что указывает программист. Он может сделать оптимизации по типу сворачивания хвостовой рекурсии, но изменить тип вычислительного процесса он не может. Хотя и говорят что-то там про CPS, но имхо это хардкор, который работает в 1 проценте из всех случаев и вещь довольно ненадежная, чтобы на нее полагаться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[46]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 16.02.09 14:03
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>По штанге хоть и жуткий оффтоп, это такая штука и калечит и лечит


Все хорошо в меру. Если физические кондиции позволяют, можно и под 100 кг штангой полежать. Но если скажем вес у тебя 50 килограмм, то какого хрена пытаться это делать? А ведь некоторые пытаются. "Каждый сверчок знай свой шесток". Один знакомый грыжу себе так заработал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 16.02.09 16:16
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Некоторые размышления привели меня к мысли о том, что все таки справедливо второе устверждение.


Например мысли о fold (собственно второй вариант и есть)? Который суть заменяет конструкторы списка на константу и функцию и потому точно функционален. Это уж как смотреть
Re[47]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 16.02.09 16:17
Оценка:
Здравствуйте, LaPerouse, Вы писали:

FR>>По штанге хоть и жуткий оффтоп, это такая штука и калечит и лечит


LP>Все хорошо в меру. Если физические кондиции позволяют, можно и под 100 кг штангой полежать. Но если скажем вес у тебя 50 килограмм, то какого хрена пытаться это делать? А ведь некоторые пытаются. "Каждый сверчок знай свой шесток". Один знакомый грыжу себе так заработал.


Дело не в этом, я имел в виду что одним из самых эффективных способов лечения того же остехондроза как раз является лечебная физкультура в которой большая часть упражнений заимствована из тяжелой атлетики
Re[25]: "LINQ как шаг к ФП". Стиль изложения.
От: FR  
Дата: 16.02.09 16:22
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Возможны варианты

LP>1. Случай 2 — это уже не ФП, так как там есть состояние на стеке
LP>2. Случай 2 — это ФП, так как ФП отрицает не любое состояние, а лишь то, которое меняется путем деструктивного присваивания.

LP>Некоторые размышления привели меня к мысли о том, что все таки справедливо второе устверждение.


Вообще даже первая функция именно как функция чистая хотя и реализованна конечно нечисто. А так да, можно было вместо размышлений почитать хотя бы первую главу Филда — Харрисона
Кстати случай 2 это весьма распространенный паттерн в ФП, те же потоковые вычисления оно и есть.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 19.02.09 21:13
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Стандартный алгоритмы над последовательностями в С++ живут уже больше 10 лет. И лямбды есть, тоже давно уже.


Ты лямбды с указателями на функции случайно не путаешь?
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 19.02.09 21:20
Оценка:
Здравствуйте, Vamp, Вы писали:

IT>>Ты лямбды с указателями на функции случайно не путаешь?

V>А как их можно спутать? Под лямбдами я имею в виду бюстовские.

А как они реализованы в плюсах? В частности как реализован захват контекста?
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: CreatorCray  
Дата: 20.02.09 23:35
Оценка:
Здравствуйте, IT, Вы писали:

Да уже и C++0x подтянулся с лямбдами
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: criosray  
Дата: 21.02.09 11:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Да уже и C++0x подтянулся с лямбдами


Уже есть компилляторы?
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: criosray  
Дата: 21.02.09 12:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>>>Да уже и C++0x подтянулся с лямбдами

C>>Уже есть компилляторы?
CC>Да
CC>GCC ICC
CC>Поддержка фич не 100% по кол-ву, но постепенно вводятся
CC>Например в ICC лямбды уже есть.
Судя по всему новый Intel C++ Compiler 11.0 тоже поддерживает лямба-выражения.
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: nikov США http://www.linkedin.com/in/nikov
Дата: 21.02.09 15:30
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>Да уже и C++0x подтянулся с лямбдами


C>Уже есть компилляторы?


Насколько я понял из демонстрации на презентации, компилятор из Microsoft Visual Studio 2010 Beta их поддерживает.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 21.02.09 17:55
Оценка:
Здравствуйте, Vamp, Вы писали:

IT>>А как они реализованы в плюсах? В частности как реализован захват контекста?

V>Я сам, честно говоря, не пользовался. Наверняка замыкания там как-то сделаны, но как?

Не увидел ни одного. Да это и не удивительно. Без GC такие вещи не делаются. А без замыканий лямбды — это пародия, что мы и наблюдаем в бусте.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: IT Россия linq2db.com
Дата: 21.02.09 17:55
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Да уже и C++0x подтянулся с лямбдами


А как в нём реализован захват контекста?
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 21.02.09 18:07
Оценка:
Здравствуйте, IT, Вы писали:

IT>Не увидел ни одного. Да это и не удивительно. Без GC такие вещи не делаются. А без замыканий лямбды — это пародия, что мы и наблюдаем в бусте.


Замыкания там делаются ручками. Хочешь — копируй, хочешь — ссылку, хочешь — хоть shared_ptr, хочешь — весь стек. В общем, в стиле Си++.
Называть это полноценными лямбдами, конечно, нельзя. Но double = power 2 написать можно.
И уж гораздо удобнее, чем структурки временные воротить, чтобы в for_each передать.
Кстати.
Можно даже
function<int (int)> fact = [&fact] (int n) { if (n == 0) return 1; return n * fact(n - 1); }

Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: CreatorCray  
Дата: 21.02.09 21:44
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>Например в ICC лямбды уже есть.

C>Судя по всему новый Intel C++ Compiler 11.0 тоже поддерживает лямба-выражения.
C>http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm
Так про него и речь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: CreatorCray  
Дата: 21.02.09 21:44
Оценка:
Здравствуйте, IT, Вы писали:

IT>А как в нём реализован захват контекста?


Из документации к ICC 11.0

Understanding Lambda-Capture
A lambda expression can refer to identifiers declared outside the lambda expression. If the identifier is a local variable or a reference with automatic storage duration, it is an up-level reference and must be "captured" by the lambda expression. Such a lambda expression must be introduced by [lambda-captureopt], where lambda-captureopt specifies whether identifiers are captured by reference or by copy. The table below summarizes forms of lambda-captureopt.

Symbol
Indicates

[]
Nothing to capture: an up-level reference is an error

[&x, y, ...]
Capture as specified: identifiers prefixed by & are captured by reference; other identifiers are captured by copy. An up-level reference to any variable not explicitly listed is an error

[&]
Capture by reference: an up-level reference implicitly captures the variable by reference

[=]
Capture by copy: an up-level reference implicitly captures the variable by copy

[&, x, y, ...]
Capture by reference with exceptions: listed variables are captured by value/copy (no listed variable may be prefixed by &)

[=, &x, &y, ...]
Capture by copy with exceptions: listed variables are captured by reference only (every listed variable must be prefixed by &)


No identifier may appear twice in the list. In the following code that sets area to the sum of the areas of four circles, the notation [&area,pi] specifies that area is captured by reference and pi by copy.

float radius[] = {2,3,5,7};
float area=0;
float pi = 3.14f;
for_each(radius, radius+4, [&area,pi](float r) {
    return area+=pi*r*r;)
}


Specifying Default Capture
When a default capture is specified, the list must specify only the other kind of capture. In other words, if you specify that the default capture is by reference, then you must list (and only list) the variables that should be captured by copy. For example, if your intent is to capture x by reference and y by copy, and both x and y appear in the function body, the following code illustrates what is correct and incorrect code:

[&,&x,y] // ERROR - default is capture-by-reference; you must list only capture by copy
[&,y]  // CORRECT
[=,&x,y]  // ERROR - default is capture-by-copy; you must list only capture by reference
[=,&x]  // CORRECT - default capture is by copy and so you must list x to be captured by reference
[&x]   // ERROR - since there is no default capture, you must list y
[y]    // ERROR - again no default capture is specified, so you must list &x
[&x,y]   // CORRECT - since no default is specified, every variable is listed with its capture mode.


Default Binding Modes
The following lambda expressions demonstrate default binding modes. All three expressions are semantically equivalent. Each captures x and y by reference, and captures a and b by copy.

[&x,&y,a,b](float r) {x=a; y=b;}
[&,a,b](float r) {x=a; y=b;}
[=,&x,&y](float r) {x=a; y=b;}


Referring to this
If a lambda expression occurs inside a member function, it can refer to this. Because this is not a variable, it cannot be captured by reference. Even when it is captured implicitly in a lambda expression introduced by [&], it is captured by copy.

Formal Grammar for Lambda Expressions in "Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 4)" available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2550.pdf

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[43]: "LINQ как шаг к ФП". Стиль изложения.
От: Gaperton http://gaperton.livejournal.com
Дата: 26.02.09 10:51
Оценка:
Здравствуйте, thesz, Вы писали:

E>>>>Языки C, C++, Perl, Ruby, Java вряд ли были самыми мощными (с точки зрения языковых возможностей на тот момент), тем не менее, точком к их созданию явилось желание иметь удобный инструмент, необходимый авторам здесь и сейчас.

T>>>А это разве не мощность?
E>>Имхо, в контексте данного обсуждения, не мощность. Мощность -- это, например, поддержка вывода типов, ленивых вычислений, алгебраических типов, сопоставления с образцом и, сюда же можно включить симпатичные тебе зависимые типы. Удобство -- это когда кто-то предпочитает begin/end фигурным скобочкам или наоборот

T>I beg to differ.


T>Мощность языка по Гапертону — у него в ЖЖ это было, — это возведённое в квадрат мозговое напряжение, необходимое при работе с языком, делённое на сопротивление языка.


Это вообще-то шутка была. Я отвечал Клапауцию в РСДН, который жог, всерьез оценивая "мощность" языка по его "сопротивлению". Ну как тут удержаться от "божественной массы" деленной на "божественного ускорения", вспомнив старый анекдот .
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: NikeByNike Россия  
Дата: 26.02.09 11:31
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Можно даже

VE>
VE>function<int (int)> fact = [&fact] (int n) { if (n == 0) return 1; return n * fact(n - 1); }
VE>

Это где? В С++? А что нужно чтобы это скомпилилось?
Нужно разобрать угил.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 26.02.09 15:11
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


VE>>Можно даже

VE>>
VE>>function<int (int)> fact = [&fact] (int n) { if (n == 0) return 1; return n * fact(n - 1); }
VE>>

NBN>Это где? В С++? А что нужно чтобы это скомпилилось?
VS2010 например
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.09 17:53
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Для кого не сложен, для новичка или топа ?

V>Вообще ни для кого не сложен. Мне стало интересно, что это за ЭЛИТА такая, ФП — прочел статью и понял за 10 минут. Как всегда, много шума из ничего. Стандартный алгоритмы над последовательностями в С++ живут уже больше 10 лет. И лямбды есть, тоже давно уже.

Алгоритмы над последовательностями это не фп. И лямбды это тоже не фп.
Re[35]: "LINQ как шаг к ФП". Стиль изложения.
От: vdimas Россия  
Дата: 23.03.09 14:44
Оценка:
Здравствуйте, thesz, Вы писали:


T>И называется это не только "детский сад", а ещё "крохоборство", "перфекционизм" или "интравертность" — на выбор.


В другом месте форумы ты клеймишь тот самый перфекционизм.
Re[36]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.04.09 14:11
Оценка:
T>>И называется это не только "детский сад", а ещё "крохоборство", "перфекционизм" или "интравертность" — на выбор.
V>В другом месте форумы ты клеймишь тот самый перфекционизм.

Я и хотел усилить негативность высказывания eao.

Чего останавливаться на тривиальном "детский сад".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.