__>>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки. I>зачем?
T>>Замечательно — это как? NGG>Это значит решаются и кодирование не приносит головной боли. Естественно, я говорил не о задачах вообще, а о задачах, с которыми сталкиваюсь я лично.
T>>Например, библиотеку комбинаторов разборщиков (parser combinators). T>>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. NGG>parser combinators — похожая библиотека, кажется, есть на haskell? Да, на java это будет страшновато Но, опять-таки, хочется увидеть преимущества на задаче близкой к "реальной" жизни. Если задача хорошо формулируется на языке математики, то преписав формулировку почти в 1 к 1 на тот же хаскел можно "быстро" получить решение — здесь плюсы "очевидны". NGG>А если такой формулировки нет? Если постановка задачи меняется на этапе кодирования?
Нормалек.
У меня такое было.
Я в модель процессора добавлял штуку под названием bypass. Про нее вспомнили уже в середине.
Справились, именно кодирование заняло около двух недель с сохранением всех предыдущих фич (их было уже довольно много).
Но это то, что буржуи называют anecdotical experience. Вернемся к теории.
Если ты умеешь переводить предметную область в область математики, то тогда Хаскель и ничто другое.
А математика умеет описывать уже очень много интересных областей.
NGG>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
Вопрос об IDE мы оставим за кадром.
Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку.
perser combinators я использовал в реальной задаче — надо было сделать инструмент для оценки трудоемкости создания узлов инженерами-электронщиками.
Есть аналоги на VHDL и (или) Verilog (на opencores), надо оценить трудозатраты инженера на написание своего такого же по количеству строк кода в доступном исходнике.
Стиль оформления меняется сильно, штуки наподобие indent нет, я решил написать свой разборщик (после того, как в скрипте на тикле получилось более десятка регулярных выражений).
Написал разбор Verilog и VHDL за две недели. Если что, он ругался и пытался продолжить подсчет, пропуская непонятное.
Ошибка подсчета составляла <5%.
Что у меня было.
У меня был лексер с одним вариантом комбинаторов. Из этого набора комбинаторов я собрал вариант для парсера, с произвольным откатом (копирование + изменения первого варианта). Еще через некоторое время я добавил ко второму варианту указание точного места ошибки путем небольшого изменения данных внутри монады. Внешне интерфейс общения с библиотекой остался прежним. Это показывает высокий уровень абстракции.
Разбор кусков синтаксиса языка я тестировал с помощью REPL. Поэтому юнит-тестов у меня, практически, не было, поскольку изменения часто были объемными, было подобие regression tests (просто набор исходников на двух V и в них каждый раз должно было быть все меньше ошибок. Соответственно, 99% кода пошло в готовый продукт, а не на проверку отсутствия ошибок.
Делал я это все в Far commander + mingw + ghci.
IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
L>>Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится. IT>Какая разница?
Дело в том что тут происходит изменение алгоритма.
И доказать что результат будет тот же можно только если модель языка формализованна.
У гебридов с формализацией модели слабовато
Впрочем это не фатальный недостаток. Просто этим нужно заняться.
Хотя с немерлом/скалой скорей всего не получится. Ибо позорная модель CLR/Java на которую немерле/скала сильно подвязаны ставит палки в колеса.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Последние полтора — два года тихо фанатею от возможностей функциональных языков.
Бывает приятно посидеть вечерком на работе, поделать простенькие программки, почитать баталии ООП vs ФЯ. Достаточно продолжительное время пробовал использовать фвп в коде на c#, но, как бы это сказать, запал стал проподать.
Причин две:
1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
Призадумался над этим и решил, что я, наверное, не правильные задачи пытаюсь решить на функциональных языках и потому не вижу стратегического выйгрыша от их использания.
Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
[...]
> Меня мучает вопрос о применимости функциональных языков. Охотно > верю, что задачи связанные с голой математикой существенно проще > делать на хаскел, чем на с++ или java, но будет ли выгода от > использования хаскел при создании приложений уровня ентерпрайс?
Для того, чтобы получить ответ на подобный вопрос, бессмысленно
вопрошать на форуме, лучше решить (не попробовать, а именно решить)
заинтересовавшими средствами реальную задачу, под которую не страшно
выделить достаточно много времени на исследования. Сопровождая свои
изыскания вопросами в соотв. местах.
Как показывает мой опыт обсуждения лиспа, пока человек не реализует
кривой лисп (в данном случае это надо понимать как "не станет ходить
гордым весь из себя своим изобретением"), и кто-нибудь не покажет ему
это явно (с демонстрацией кода) -- любые доводы и демонстрации
малоэффективны, если не сказать бессмысленны. Тем более, когда
человек заведомо намерен отстоять любимые средства.
То же относится и к функциональным языкам. Недавно был свидетелем
изобретения велосипеда коллегой. Для решения стоящей перед ним задачи
он спроектровал систему, в которой каждый компонент был stateless, и
гордо излагал преимущества этого решения (и в самом деле крайне
удачного). После того, как мы его поздравили с изобретением чистых
функций, он после недолгого раздумья просто попросил напомнить как
называются те ФЯ, о которых мы не раз упоминали в разговорах с ним, и
где о них почитать. Замечу, что до тех пор его чрезмерный скепсис
и любовь к ОО совершенно не позволяли ему воспринимать наши рассказы
об ФП всерьез.
[...]
> "Ловушки", конечно, есть, но они довольно хорошо описаны в различных > источниках и через какое-то время изучения ооп перестают казаться > ловушками
Но от того не перестают быть ловушками (и срабатывать)
Здравствуйте, thesz, Вы писали:
VD>>Это или логические ошибки, или откровенная и довольно наглая лож. Про ФЯ речь в общем-то не шла. Речь шало про ФП.
T>А как их отличить?
А вот когда ты говоришь про ФП (т.е. про парадигму), а тебе в ответ про конкретный ФЯ, то это называется подмена понятий.
Если еще будут проблемы с логикой, то не стесняйся, обращайся.
T>PS T>Ложь пишется с мягким знаком. Уже третий раз встречаю.
Ну, извини, опечатался. На будущее, за обсуждение правописания вместо темы тут банят. Так что если хочешь что-то рассказать о правописании, то пиши в приват.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
T>>>Что такое ООП? Определи его без языка. IT>>Думаю, что твои попытки сделать из дискуссии банальный терминологический трёп, в лучшем случае для тебя будут проигнорированы.
T>Я думал помочь Владу в переводе дискуссии в указанное им (и тобой) русло.
Не видно, чтобы ты действительно реально этого хотел. По крайней мере, судя по форме твоих сообщений. А от формы напрямую зависит желание людей с тобой общаться.
T>А вообще интересно получается: ФП без языка должно быть, ООП без языка — нет.
Ты же ведь сам так не думаешь, правда?
T>Double standards. Tell me about it.
Just take it easy.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, Gaperton, Вы писали:
G>>Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки.
NGG>Почему меньше? За счёт чего? Не совсем понятно. NGG>Только из-за декларативности конструкций? Но декларативно можно писать на любом языке, потратив какое-то время на создание соответствующей библиотеки...
Да, из-за декларативной семантики языка. Чтобы сравнимым с Хаскелем образом писать на С++, вы в своей библиотеке реализуете кривым образом Хаскель. "Любая сложная программа на С обязательно содержит внутри кривую реализацию LISP". Слышали эту шутку? В ней есть доля шутки. Некоторая. В конце концов, можно ООП на макросах в С изобразить, раньше так и делали. Из этой возможности следует ненужность специализированных ООП языков? Каким именно образом?
NGG>Или речь о том, что мат. постановка задачи легче ложится на функционнальный язык? NGG>Но если сделать постановку в терминах объектов и отношений между ними, то она легче ляжет на императивный объектно-ориентированный язык, чем на функциональный...
Это сделать тяжелее. Речь о том, что сам язык более высокоуровнев, заложенные в него концепции позволяют приблизить код к постановке задачи, снизив сложность дизайна. Был хороший пример — у thesz должна быть ссылка. Он взял нашу задачу на ОО дизайн (реализовать сильно укоцанное подмножество Excel), и сделал ее на Хаскель. Так вот, дизайн для этой задачи в случае Хаскель относительно прямолинеен — более очевидные ходы будут более правильными. В случае ОО декомпозиции — эта задача содержит несколько ловушек. Причина в том, что в ФЯ на порядок более гибкая схема полиморфизма, как рантайм, так и статического. В случае ОО вы вынуждены для обеспечения динамического полиморфизма городить иерархии классов, и тут же вылезают разного рода проблемы дизайна, которые не лежат на поверхности. "Паттерны" разные появляются.
NGG>Причём мне кажется, что всё просто и красиво остаётся только в простых и красивых задачах, даже в мире ф-языков. "Прогрессивное" человечество давно воет, что переходить от постановки и анализа задачи к написанию решения на конкретном языке — это как-то не хорошо и предлагает снижать уровень абстракции постепенно, через использование моделей, dsl и т.п.
Парадигма ФЯ это и дает — ФЯ несколько ближе к предметной области, чем императивные языки.
G>>Вот возьмем скажем квиксорт. На С мне надо задизайнить технику управления памятью, а на хаскеле я просто дам рекурсивное определение отсортированному массиву, и все.
NGG>А разве такой метод не тоже самое, что определение отсортированного массива? NGG>
NGG> public static int[] sort(int[] a) {
NGG> if (a.length <= 1) {
NGG> return a;
NGG> }
NGG> int x = a[0];
NGG> return ArrayUtils.concat(sort(ArrayUtils.less(a, x)),
NGG> ArrayUtils.equal(a, x),
NGG> sort(ArrayUtils.greater(a, x)));
NGG> }
NGG>
Определение отсортированного массива можно дать по разному. Попробуйте дать определение сортировки вставкой и сортироваки слиянием. Во вторых, делает ваш код примерно то же, но выглядит существенно угребищнее Хаскельного варианта. Третье — в вашем случае компилятор не имеет возможностей провернуть ряд ацких оптимизаций, что в состоянии сделать компилятор Хаскеля — у него будет больше информации.
G>> Кстати, читал мою статью "что такое ФЯ" — скомбинированную из переводов плюс приправленную авторскими добавками?
NGG>Прочитал, но вопрос остался открытым. Возможно, чтобы получить на него ответ, мне нужно "честно" поработать с тем же haskell пару месяцев. NGG>Кстати, существует литература по разработке на ф-языках? Что-то вроде такой книги http://www.ozon.ru/context/detail/id/3105480/
NGG>Почему меньше? За счёт чего? Не совсем понятно. NGG>Только из-за декларативности конструкций? Но декларативно можно писать на любом языке, потратив какое-то время на создание соответствующей библиотеки...
Придется разрабатывать библиотеку на каждый чих, каждый раз новую.
NGG>Или речь о том, что мат. постановка задачи легче ложится на функционнальный язык? NGG>Но если сделать постановку в терминах объектов и отношений между ними, то она легче ляжет на императивный объектно-ориентированный язык, чем на функциональный...
Изначально наша задача описана на естественном языке.
Логично его перевести на самый удобный формальный язык, язык математики.
Оттуда один шаг до ФЯ.
G>>Вот возьмем скажем квиксорт. На С мне надо задизайнить технику управления памятью, а на хаскеле я просто дам рекурсивное определение отсортированному массиву, и все.
NGG>А разве такой метод не тоже самое, что определение отсортированного массива? NGG>
NGG> public static int[] sort(int[] a) {
NGG> if (a.length <= 1) {
NGG> return a;
NGG> }
NGG> int x = a[0];
NGG> return ArrayUtils.concat(sort(ArrayUtils.less(a, x)),
NGG> ArrayUtils.equal(a, x),
NGG> sort(ArrayUtils.greater(a, x)));
NGG> }
NGG>
Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?
В случае Хаскеля O(n). У тебя?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Вопрос об IDE мы оставим за кадром.
T>Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку.
T>IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.
Вот этот момент спорен. Я на собственном опыте могу судить, что java в notepad и java с IDE IDEA — это небо и земля. Скорость работы с кодом увеличивается не немного, а раза в 4 точно:
— автокомплит (название метода, краткая справка)
— навигация по коду (переход на определение, поиск использований)
— автоматические рефакторинги (ввести переменную, ввести метод, сделать inline и т.п.)
Разве наличие таких инструментов для haskell/lisp не сделало бы работу с ними проще?
Естественно, из-за наличия IDE в языке не появляются новые фичи, но работа с кодом ведь существенно упрощается...
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Почему меньше? За счёт чего? Не совсем понятно. NGG>Только из-за декларативности конструкций? Но декларативно можно писать на любом языке, потратив какое-то время на создание соответствующей библиотеки...
Такую как в хорошем ФЯ — очень сложно и громоздко.
NGG>Или речь о том, что мат. постановка задачи легче ложится на функционнальный язык? NGG>Но если сделать постановку в терминах объектов и отношений между ними, то она легче ляжет на императивный объектно-ориентированный язык, чем на функциональный...
Это, как раз, не так. Большая часть реальных описаний — как раз декларативна (достаточно посмотреть на УК РФ, например ). Поэтому переводить их в императивный вид — та еще задачка.
NGG>Причём мне кажется, что всё просто и красиво остаётся только в простых и красивых задачах, даже в мире ф-языков. "Прогрессивное" человечество давно воет, что переходить от постановки и анализа задачи к написанию решения на конкретном языке — это как-то не хорошо и предлагает снижать уровень абстракции постепенно, через использование моделей, dsl и т.п.
Так писать-то все равно нужно будет, вот в чем загвоздка. И ФЯ позволяют очень неплохо это делать.
Хотя у ООП тоже есть плюсы — пока что не придумали более удобного способа создавать компонентные системы.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
Здравствуйте, IT, Вы писали:
L>>Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation. IT>Если эта проблема специфична для читых ФЯ, то это в чистом виде сравнение тёплого с мягким.
Это не проблема. Это оптимизация которая становится возможной благодоря формализации операций.
Например:
NGG>Создать "абстракцию" подразумевающие множество реализаций в ф-языках можно без всякого ооп. То, что этого нельзя сделать для встроенного в язык листа, не должно никого удивлять, ведь никого же не удивляет, что класс Int32 нельзя расширить...
[]
T>ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Определение отсортированного массива можно дать по разному. Попробуйте дать определение сортировки вставкой и сортироваки слиянием. Во вторых, делает ваш код примерно то же, но выглядит существенно угребищнее Хаскельного варианта. Третье — в вашем случае компилятор не имеет возможностей провернуть ряд ацких оптимизаций, что в состоянии сделать компилятор Хаскеля — у него будет больше информации.
VD>Давай, чтобы не быть голословными, сравним производительность сортировки классического QuickSort написанного на Яве/дотнете в тупом императивном стиле и Хаскелевскую "красоту"? А в качестве входных данных пустим еще отсортированные по убыванию и по возрастанию списки... чтобы выбор точки разделения из начала списка привел бы к квадратичному падению скорости сортировки...
Давай ты не будешь разводить флейм, а почитаешь пост, на который я отвечаю, и в котором автор выписал чисто функциональную реализацию Хаскелевского варианта квиксорта на С#. И если тебе очень хочется — сравним производительность Хаскелевского кода и С# для сортировки, записанной в таком стиле — т.е. одного и того же алгоритма. Специально для тебя цитирую этот дотнетовский квиксорт, о котором идет речь — ты ведь не читаешь ветку нифига.
public static int[] sort(int[] a) {
if (a.length <= 1) {
return a;
}
int x = a[0];
return ArrayUtils.concat(sort(ArrayUtils.less(a, x)),
ArrayUtils.equal(a, x),
sort(ArrayUtils.greater(a, x)));
}
VD>Что не хочшь?
Разумеется, зачем мне в беспредметных спорах участвовать.
VD>Так что не надо этих инсунуаций. Тебе правлиьно показали, что тут приемущество не в некой крутости ФЯ, а в наличии готовых высокуровневых фуцний или конструкций языка и в том, что сортировка получается несолько другим алгоритмом.
Ты сейчас с воображаемым каким-то собеседником споришь. Не буду мешать.
T>>Беда с этими универсальными интерфейсами. LCR>Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...
T>>Итак, зачем использовать классы? VD>Для декомпозиции (и соответственно, проектирования) на уровне приложения (которое может быть не млым). VD>В ООП оные средсва имеются. В ФП — нет.
Как-то раз наткнулся в одном произведении Рафаэля Сабатини на замечательный диалог:
— Мадемуазель, вы дура!
— Вы говорите так, мадам, только потому, что я думаю иначе, чем вы.
Так вот, по поводу декомпозиции и средств для этого: я думаю иначе, чем ты.
Этому средству декомпозиции и формальной спецификации лет поболе, чем любой ОО методологии.
Он переносится в ФП один-к-одному.
Более того, как выясняется, он отлично подходит и для ООП языков!
Например, товарищи из Tektronix использовали его в паре с языком Smalltalk с большой для себя выгодой.
VD>Данная парадигма попросту осталась на уровне структурного программирования. В ОКамл были введены самые что не на есть ОО-классы. В Хаскель предмет их заменяющий. Но так или иначе рамки классического ФП подобные концепции не описаны.
"Предмет, их заменяющий," был введен для перегрузки, а не для декомпозиции.
Продолжим.
Итак, зачем использовать классы?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Есть какой-нибудь туториал для тех, кто верит, что emacs это круто, но ни как не может это ощутить? Being Productive With Emacs
Здравствуйте, IT, Вы писали:
IT>В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
Да, безусловно, использование функциональных фич на уровне методов даёт свои плюсы. Но, как мне кажется, эти плюсы скорее синтаксический сахар. С ними приятнее, но их использование быстрее программу не сделают, скорее наоборот (из-за неявного создания классов обёрток для методов).
Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
Здравствуйте, lomeo, Вы писали:
L>VladD2 спросил, как решаются вопросы абстракции в ФП. Ему показали как на примере конкретных языков. А вот после этого — ага, был флейм, мол эти средства неродные для ФП и вообще, если ФЯ решает вопросы абстракции и модульности, то это уже добавки, а ни фига ни ФП, и родом они с ООП, ну и прочие повороты к языкам, похожим на швейцарский нож.
Давай не будем. Мне хватило того топика для обсуждения этих проблем.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
T>>Тогда зачем надо было его приводить?
IT>Чтобы не разводить подобный флейм ещё раз.
Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.
Создать "абстракцию" подразумевающие множество реализаций в ф-языках можно без всякого ооп. То, что этого нельзя сделать для встроенного в язык листа, не должно никого удивлять, ведь никого же не удивляет, что класс Int32 нельзя расширить...
Может я чего не понял из того флейма, что должно было помочь с ответом на мой вопрос?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.
Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Дабы не теоризировать на пустом месте, попробую написать на хаскел игру реверси и сравнить ощущения.
вот из сегодняшнего cafe:
For example, yesterday I rewrote and extended a program that I wanted to develop in Haskell in just 3 hours using dotnet, while I spend weeks trying do this in Haskell. Of course, I'm a Haskell newbie and a dotnet expert, so this is not a fair comparison. However, I got a strange feeling, which I want to share with you First of all, it was a *horrible* experience to program C# again; I needed to type at least 3 times the amount of code, much of which was boilerplate code, and the code is not elegant. Haskell really changed my point of view on this; before I knew Haskell, I found C# (I'm talking C# 3.0 here) a really neat and nice language. On the other hand, the great Visual Studio IDE and Resharper addin made it at least 3 times faster to type, navigate, refactor, and debug the code... Somehow, I get things done really really really fast in C#, albeit in an "ugly" way. Once again, I just wish Haskell had such an IDE... And yes, I know of the existance of Visual Haskell, EclipseFP, Haskell Mode for Emacs (which I'm using), VIM, YI, but still, these do not compare with the experience I have when using Visual Studio/Resharper (or Eclipse or IntelliJ/IDEA for Java). But that might just be me of course...
T>>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива? S>а последний?
Первый и последний — экстремальные в некотором смысле (это минимальный и максимальный). Поэтому если стоит задача получить M экстремальных, мне не надо ничего менять, взял сортировку и получил то же быстродействие.
S>задача была отсортировать, поэтому не стоит из неё пытаться выдумать другие задачи, которые лягут под своё решение.
А что выдумывать-то?
Я это уже неоднократно использовал.
Такие, вот, дела.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Совершенно точно. И вообще когда подходишь к вопросу с заранее готовой упертостью, то ничего новго для себя никгда не откроешь. Вообще люди которые уперлись в "одну самую правильную иделогию" потеряны для общества. Они выдают эмоции и нарушают правила логики только чтобы остаться при своем исходном мнении.
О, да, ты это отлично демонстрируешь!
Ты постоянно твердишь, что ты практик, а интересуют тебя сферические вопросы: "Сам ФП не позволяет выразить абстракцию". Ну так "сам ООП" не позволяет даже сложить два числа, кого это интересует вообще? Что нового тут можно открыть?
Здравствуйте, Константин Л., Вы писали:
VD>>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане. Создание нового объекта в дотнете не так дорого. Это вам не С++. GC делает эту операцию относительно дешеовй.
КЛ>зато удаление
Ага. Создание не так дорого, зато удаление вообще ничего не стоит.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'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
Здравствуйте, thesz, Вы писали:
T>Читывал ли ты про Z notation? T>Этому средству декомпозиции и формальной спецификации лет поболе, чем любой ОО методологии.
Возраст не является достоинством. Каменному топору лет поболее, чем бензопиле.
Здравствуйте, thesz, Вы писали:
T>Его отсутствие тем более. Про старые вещи мы знаем больше.
Он не является в общем случае ни достоинством, ни недостатком, поэтому о нём тут вообще не стоит говорить.
А кроме него ты других достоинств Z notation ты не привел.
Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Кё>>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр. T>>Рекомендую попробовать. E>Пробовал, 13 лет назад
(про невозможность применить метод Гаусса понравилось даже мне, не полностью прочитавшему Вычислительную Линейную Алгебру уже забыл, какого автора)
T>>Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих. T>>Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime. E>Извините, юмора не понял. E>Я сам делал обращения к полуленточной матрице в виде обычной записи a[i][j] -- в точности как к обычной. Что дало существенное упрощение реализации пусть и учебной, но все-таки задачи. Не показалось ни много, ни мало.
Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась?
Не из-за этого ли все тормозило?
E>>>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций. T>>Indexless algebra? E>И что я должен был увидеть в куче устаревших ссылок типа: http://www.numeric-quest.com/haskell/Orthogonals.html E>
В тех же самых cache oblivious вариантах перемножения матриц применяется, практически, indexless представление. Там такой рекурсивный алгоритм блочного перемножения.
Смотри, сколько я умных слов знаю! Это из-за использования ФЯ, вот так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
. Вполне нормально получилось. T>>Это же явно не сегодняшний день. E>ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
Я про другое.
С тех пор ландшафт языков изменился.
Например, ФЯ перестали быть уделом избранных.
T>>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась? E>Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
djgpp? watcom?
Или какая-то религия не позволяла?
T>>Не из-за этого ли все тормозило? E>У кого тормозило?
Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.
Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).
T>>ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения. С>а это всегда хорошо?
Зависит от проблемы.
Можно балансировать.
Главное, у нас есть выбор — скрывать или открывать, сколько открывать...
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
__>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
зачем?
Здравствуйте, mini_root_2, Вы писали: __>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
Получится сильно проще, чем сделать тот же самый интерпретатор на java?
У меня была мысль сделать плагин для редактирования java байткода, но проблемы с интеграцией полученного кода с IDE делают эту задачу черезмерно усложнённой.
NGG>Причин две: NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
Замечательно — это как?
NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. С первой тоже не все так плохо: http://en.wikipedia.org/wiki/Z_notation
Из Z растут ноги алгебраических типов.
NGG>Призадумался над этим и решил, что я, наверное, не правильные задачи пытаюсь решить на функциональных языках и потому не вижу стратегического выйгрыша от их использания.
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Например, библиотеку комбинаторов разборщиков (parser combinators).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Замечательно — это как?
Это значит решаются и кодирование не приносит головной боли. Естественно, я говорил не о задачах вообще, а о задачах, с которыми сталкиваюсь я лично.
T>Например, библиотеку комбинаторов разборщиков (parser combinators).
T>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних.
parser combinators — похожая библиотека, кажется, есть на haskell? Да, на java это будет страшновато Но, опять-таки, хочется увидеть преимущества на задаче близкой к "реальной" жизни. Если задача хорошо формулируется на языке математики, то преписав формулировку почти в 1 к 1 на тот же хаскел можно "быстро" получить решение — здесь плюсы "очевидны".
А если такой формулировки нет? Если постановка задачи меняется на этапе кодирования?
Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
NGG>>Причин две: NGG>>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
T>Замечательно — это как?
NGG>>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
T>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. С первой тоже не все так плохо: http://en.wikipedia.org/wiki/Z_notation
Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки. Кодирование + отладка строго кореллируют по времени с объемом кода — но суммарно могут занимать около трети всего времени разработки у опытного программера. Или даже меньше.
Вот возьмем скажем квиксорт. На С мне надо задизайнить технику управления памятью, а на хаскеле я просто дам рекурсивное определение отсортированному массиву, и все. Кстати, читал мою статью "что такое ФЯ" — скомбинированную из переводов плюс приправленную авторскими добавками?
NGG>>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
IT>В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
Define максимальный эффект.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Define максимальный эффект.
По сути ФП — это программирование в выражениях. То есть программа есть одно большое выражение производящее вычисление без побочных эффектов (форумала).
Языки вроде Немерле или Скалы позволяют использовать все рпиемущества ФП внтури методов, но при этом сама программа является ОО.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
T> Вопрос об IDE мы оставим за кадром. T> Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку. T> ... T> IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.
Не согласен. Когда я изучал F# (правда, я его уже почти забыл , то очень хорошо прочувствовал, как F#-плагин к студии помогает экономить время. Не надо было тратить время на поиски и вспоминания, где какие типы, у кого какие методы и допустимые параметры...
Другое дело, что сам F# неудобен по сравнению с Хаскеллем... Приходилось тратить время на рефакторинги, которые в Хаскелле просто не возникли бы...
T>>Define максимальный эффект. VD>По сути ФП — это программирование в выражениях. То есть программа есть одно большое выражение производящее вычисление без побочных эффектов (форумала). VD>Языки вроде Немерле или Скалы позволяют использовать все рпиемущества ФП внтури методов, но при этом сама программа является ОО.
Хорошо.
Слабо логически связать "преимущества ФП" и тот факт, что "сама программа является ОО?"
(третья версия ответа. Две первых были очень грубы)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
G>Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки. Кодирование + отладка строго кореллируют по времени с объемом кода — но суммарно могут занимать около трети всего времени разработки у опытного программера. Или даже меньше.
Пожалуй, я понял, что можно добавить.
Кодирование — это получение готового продукта.
Дизайн — подготовка (preproduction).
Отладка — доводка (postproduction).
Уменьшая время на дизайн и отладку, мы улучшаем общее использование времени, у нас больше времени (относительно) уходит на получение этих самых deliverables.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Define максимальный эффект. IT>Что именно тебе не понятно в этом выражении: максимальный или эффект?
Словосочетание.
Во-первых, эффект, он положительный или?
Во-вторых, что за сам эффект, в чем проявляется.
В-третьих, определи "степень," чтобы было понятно, что за максимальность.
После чего мы вернемся к применимости этого дела в программе в целом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Разве наличие таких инструментов для haskell/lisp не сделало бы работу с ними проще?
У меня для хаскеля emacs делает аналог outline, показывает доку и типы функций, подсветка есть разумеется, ещё я прикрутил туда рефакторинг. Достаточно часто пользуюсь только переходом на определение и автодополнением имени (а на что ещё в Хаскеле можно подвестить автодополнение?) Рефакторинг не нужен практически никогда (чтобы не придирались, скажу, что речь идёт обо мне), типы функций выражений всегда смотрятся в GHCi ну и т.д. — большАя часть времени проводится в интерпретаторе, использующимся как repl-тулза. Когда я работаю в FAR-е то больших отличий не вижу. Ну кроме того, что у емакс хороший редактор
NGG>Естественно, из-за наличия IDE в языке не появляются новые фичи, но работа с кодом ведь существенно упрощается...
Не буду утверждать наверняка, сужу только по своему опыту — видимо, всё же зависит от языка. А может быть просто для Хаскеля нет мощного IDE, ведь то, что мне хотелось бы в Хаскеле как автоматический тул, в какой нибудь IDEA я бы и не подумал о таком. С другой стороны, я не пользуюсь всякими тулзами типа drHaskell и прочие аналоги инспекций.
Здравствуйте, Gaperton, Вы писали:
G>Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки.
Почему меньше? За счёт чего? Не совсем понятно.
Только из-за декларативности конструкций? Но декларативно можно писать на любом языке, потратив какое-то время на создание соответствующей библиотеки...
Или речь о том, что мат. постановка задачи легче ложится на функционнальный язык?
Но если сделать постановку в терминах объектов и отношений между ними, то она легче ляжет на императивный объектно-ориентированный язык, чем на функциональный...
Причём мне кажется, что всё просто и красиво остаётся только в простых и красивых задачах, даже в мире ф-языков. "Прогрессивное" человечество давно воет, что переходить от постановки и анализа задачи к написанию решения на конкретном языке — это как-то не хорошо и предлагает снижать уровень абстракции постепенно, через использование моделей, dsl и т.п.
G>Вот возьмем скажем квиксорт. На С мне надо задизайнить технику управления памятью, а на хаскеле я просто дам рекурсивное определение отсортированному массиву, и все.
А разве такой метод не тоже самое, что определение отсортированного массива?
public static int[] sort(int[] a) {
if (a.length <= 1) {
return a;
}
int x = a[0];
return ArrayUtils.concat(sort(ArrayUtils.less(a, x)),
ArrayUtils.equal(a, x),
sort(ArrayUtils.greater(a, x)));
}
G> Кстати, читал мою статью "что такое ФЯ" — скомбинированную из переводов плюс приправленную авторскими добавками?
Прочитал, но вопрос остался открытым. Возможно, чтобы получить на него ответ, мне нужно "честно" поработать с тем же haskell пару месяцев.
Кстати, существует литература по разработке на ф-языках? Что-то вроде такой книги http://www.ozon.ru/context/detail/id/3105480/
Здравствуйте, lomeo, Вы писали:
L>У меня для хаскеля emacs делает аналог outline, показывает доку и типы функций, подсветка есть разумеется, ещё я прикрутил туда рефакторинг. Достаточно часто пользуюсь только переходом на определение и автодополнением имени (а на что ещё в Хаскеле можно подвестить автодополнение?) Рефакторинг не нужен практически никогда (чтобы не придирались, скажу, что речь идёт обо мне), типы функций выражений всегда смотрятся в GHCi ну и т.д. — большАя часть времени проводится в интерпретаторе, использующимся как repl-тулза. Когда я работаю в FAR-е то больших отличий не вижу. Ну кроме того, что у емакс хороший редактор
Кстати, о emacs. Я как-то пытался для лиспа использовать emacs. Скачал, установил и понял, что пользоваться им не смогу — слишком всё дико выглядело. Стал пользоватся другими средставами.
Есть какой-нибудь туториал для тех, кто верит, что emacs это круто, но ни как не может это ощутить?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Кстати, о emacs. Я как-то пытался для лиспа использовать emacs. Скачал, установил и понял, что пользоваться им не смогу — слишком всё дико выглядело. Стал пользоватся другими средставами.
NGG>Есть какой-нибудь туториал для тех, кто верит, что emacs это круто, но ни как не может это ощутить?
Это надо к емаксоводам. Для меня это просто удобный редактор, мне он нравится больше, чем vim, но почту я на нём не читаю и в IRC-е тоже не сижу.
А туториалов в нете полно, я уже и не помню какой читал, поэтому лучше не буду ничего советовать
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Да, безусловно, использование функциональных фич на уровне методов даёт свои плюсы. Но, как мне кажется, эти плюсы скорее синтаксический сахар.
Абсолютно. Точно такой же сахар, как и прокидывание this в качестве первого параметра, необходимого для реализации некоторых паттернов ООП.
NGG>С ними приятнее, но их использование быстрее программу не сделают, скорее наоборот (из-за неявного создания классов обёрток для методов).
Мы здесь разве о производительности ведём речь?
NGG>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
Насколько мне известно, list сама по себе такая структура, что при создании нового листа этому самому листу понадобится старый лист.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Во-первых, эффект, он положительный или?
Раз максимальный, значит положительный.
T>Во-вторых, что за сам эффект, в чем проявляется.
В удобстве кодирования и сопровождения кода на уровне методов.
Локальные функции позволяют инкапсулировать код в рамках метода и не замусоривать класс статическими методами. Неизменяемые переменные дисциплинируют. Другие фичи также добавляют своего понемногу.
T>В-третьих, определи "степень," чтобы было понятно, что за максимальность.
, который показал, что с помощью ФП либо никак, либо совсем плохо решаются вопросы, которые хорошо решаются с помощью ООП. А именно абстракция, модульность, высокоуровневый дизайн приложения. Фактически ФП проявляет себя только на уровне кода, т.е. на уровне методов. И надо признать, делает это хорошо.
T>После чего мы вернемся к применимости этого дела в программе в целом.
Ok.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
NGG>>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
IT>Насколько мне известно, list сама по себе такая структура, что при создании нового листа этому самому листу понадобится старый лист.
IT>Мы здесь разве о производительности ведём речь?
Хороший вопрос.
Я высказал мысль о том, что реализация фич ф-языков посредством закадрового оо-муляжа не самое лучшее решение, поскольку она приводит к снижению производительности.
В качестве иллюстрации можно посмотреть на scala и java...
Но забудем о производительности и вернёмся к исходному вопросу. Правильно ли я понял, что ваша точка зрения заключается в том, что никакой выгоды в использовании функциональных языков нет (за исключением возможности использовать более компактный синтаксис в телах методов)?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Правильно ли я понял, что ваша точка зрения заключается в том, что никакой выгоды в использовании функциональных языков нет (за исключением возможности использовать более компактный синтаксис в телах методов)?
, где эти вопросы разбирались весьма подробно. С выводами я согласен. Сам с удовольствием использую ФП там где это уместно. И вообще, предпочитаю делить техники программирования не на подходы и парадигмы, а на более мелкие составляющие, которые можно легко перемешивать и использовать как угодно без оглядки на общепринятые догмы.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
, который показал, что с помощью ФП либо никак, либо совсем плохо решаются вопросы, которые хорошо решаются с помощью ООП. А именно абстракция, модульность, высокоуровневый дизайн приложения.
Ты про то, что классы типов — это ООП? Так ничего он не показал, был типичный рсдновский флейм.
VladD2 спросил, как решаются вопросы абстракции в ФП. Ему показали как на примере конкретных языков. А вот после этого — ага, был флейм, мол эти средства неродные для ФП и вообще, если ФЯ решает вопросы абстракции и модульности, то это уже добавки, а ни фига ни ФП, и родом они с ООП, ну и прочие повороты к языкам, похожим на швейцарский нож.
Здравствуйте, IT, Вы писали:
NGG>>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
IT>Насколько мне известно, list сама по себе такая структура, что при создании нового листа этому самому листу понадобится старый лист.
Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Define максимальный эффект.
IT>Что именно тебе не понятно в этом выражении: максимальный или эффект?
из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^
Здравствуйте, elephantum, Вы писали:
E>из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^
Тут это неоднократно уже обсуждалось, подразумевается, что ООП рулит на верхнем уровне (построение компонентов), а ФП на нижнем (реализация методов). Из этого делается вывод, что использование их на соответствующих уровнях в пределах одной системы возмёт лучшее от обоих техник (парадигм?!).
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, elephantum, Вы писали:
E>>из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^
L>Тут это неоднократно уже обсуждалось, подразумевается, что ООП рулит на верхнем уровне (построение компонентов), а ФП на нижнем (реализация методов). Из этого делается вывод, что использование их на соответствующих уровнях в пределах одной системы возмёт лучшее от обоих техник (парадигм?!).
Всеравно непонятно ^__^
эффект — это уменьшение затрат на разработку/рефакторинг/понимание другим человеком?
Здравствуйте, lomeo, Вы писали:
IT>>Насколько мне известно, list сама по себе такая структура, что при создании нового листа этому самому листу понадобится старый лист.
L>Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation.
Если эта проблема специфична для читых ФЯ, то это в чистом виде сравнение тёплого с мягким.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
WH>>Это не проблема. Это оптимизация которая становится возможной благодоря формализации операций.
IT>Тогда тем более проблем не вижу.
Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится.
Здравствуйте, lomeo, Вы писали:
IT>>Тогда тем более проблем не вижу.
L>Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится.
Какая разница?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Константин Л., Вы писали:
КЛ>ncc это умеет?
На сколько я знаю нет.
И сомневаюсь что научится.
Разве что в некоторых сильно ограниченных частных случаях.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
T>>Во-первых, эффект, он положительный или? IT>Раз максимальный, значит положительный.
На этом, в принципе, можно было бы прекратить беседу.
Но мне, все же, немного интересно.
T>>Во-вторых, что за сам эффект, в чем проявляется. IT>В удобстве кодирования и сопровождения кода на уровне методов. IT>Локальные функции позволяют инкапсулировать код в рамках метода и не замусоривать класс статическими методами. Неизменяемые переменные дисциплинируют. Другие фичи также добавляют своего понемногу.
Вопросы:
Multiple parameter dispatch? Как его сделать на Nemerle или Scala? Как его сделать на сравнении с образцом в Хаскеле?
Если подобный подход распространить вне методов классов, будет ли он полезен? Какие есть статистики за и против?
T>>В-третьих, определи "степень," чтобы было понятно, что за максимальность. IT>Недавно у нас тут состоялся весьма любопытный флейм
, который показал, что с помощью ФП либо никак, либо совсем плохо решаются вопросы, которые хорошо решаются с помощью ООП. А именно абстракция, модульность, высокоуровневый дизайн приложения. Фактически ФП проявляет себя только на уровне кода, т.е. на уровне методов. И надо признать, делает это хорошо.
Это не определение степени.
Про флейм не скажу ни слова.
T>>После чего мы вернемся к применимости этого дела в программе в целом. IT>Ok.
Продолжим же работу над ошибками!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
L>>VladD2 спросил, как решаются вопросы абстракции в ФП. Ему показали как на примере конкретных языков. А вот после этого — ага, был флейм, мол эти средства неродные для ФП и вообще, если ФЯ решает вопросы абстракции и модульности, то это уже добавки, а ни фига ни ФП, и родом они с ООП, ну и прочие повороты к языкам, похожим на швейцарский нож. IT>Давай не будем. Мне хватило того топика для обсуждения этих проблем.
Тогда зачем надо было его приводить?
Да, и с lomeo я согласен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Да, из-за декларативной семантики языка. Чтобы сравнимым с Хаскелем образом писать на С++, вы в своей библиотеке реализуете кривым образом Хаскель. "Любая сложная программа на С обязательно содержит внутри кривую реализацию LISP". Слышали эту шутку? В ней есть доля шутки. Некоторая. В конце концов, можно ООП на макросах в С изобразить, раньше так и делали. Из этой возможности следует ненужность специализированных ООП языков? Каким именно образом?
Если попытаться один в один переписать решение с хаскел на с++, то скорее всего так и получится. Тоже самое можно было бы сказать о попытке переписать решение с с++ на хаскел. Разве нет?
Меня мучает вопрос о применимости функциональных языков. Охотно верю, что задачи связанные с голой математикой существенно проще делать на хаскел, чем на с++ или java, но будет ли выгода от использования хаскел при создании приложений уровня ентерпрайс? В них, обычно, нет зубодробильной алгоритмической сложности, а та что есть, подчиняется не столько красивым мат.теориям сколько не красивым workflow, которые от программиста мало зависят.
G>... и сделал ее на Хаскель. Так вот, дизайн для этой задачи в случае Хаскель относительно прямолинеен — более очевидные ходы будут более правильными. В случае ОО декомпозиции — эта задача содержит несколько ловушек. Причина в том, что в ФЯ на порядок более гибкая схема полиморфизма, как рантайм, так и статического. В случае ОО вы вынуждены для обеспечения динамического полиморфизма городить иерархии классов, и тут же вылезают разного рода проблемы дизайна, которые не лежат на поверхности. "Паттерны" разные появляются.
"Ловушки", конечно, есть, но они довольно хорошо описаны в различных источниках и через какое-то время изучения ооп перестают казаться ловушками Дабы не теоризировать на пустом месте, попробую написать на хаскел игру реверси и сравнить ощущения.
G>Определение отсортированного массива можно дать по разному. Попробуйте дать определение сортировки вставкой и сортироваки слиянием. Во вторых, делает ваш код примерно то же, но выглядит существенно угребищнее Хаскельного варианта. Третье — в вашем случае компилятор не имеет возможностей провернуть ряд ацких оптимизаций, что в состоянии сделать компилятор Хаскеля — у него будет больше информации.
Угу, ограниченность компляторов меня и расстраивает, когда заходит речь о оо языках с функциональными расширениями.
Здравствуйте, thesz, Вы писали:
T>На этом, в принципе, можно было бы прекратить беседу.
Думаю, это хорошая идея.
T>Multiple parameter dispatch? Как его сделать на Nemerle или Scala? Как его сделать на сравнении с образцом в Хаскеле?
Мне абсолютно по барабану как его сделать и на Немерле со Скалой и на Хаскеле. Тебе наверное в это трудно поверить, но это так
T>Это не определение степени.
Знаешь, у меня последнее время туго с телепатией. Ты бы сразу без наводящих вопросов сказал куда ты клонишь и мы бы не замусоривали базу RSDN лишними бессмысленными сообщениями.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>Хотя с немерлом/скалой скорей всего не получится. Ибо позорная модель CLR/Java на которую немерле/скала сильно подвязаны ставит палки в колеса.
Какие именно палки?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
NGG>Меня мучает вопрос о применимости функциональных языков. Охотно верю, что задачи связанные с голой математикой существенно проще делать на хаскел, чем на с++ или java, но будет ли выгода от использования хаскел при создании приложений уровня ентерпрайс? В них, обычно, нет зубодробильной алгоритмической сложности, а та что есть, подчиняется не столько красивым мат.теориям сколько не красивым workflow, которые от программиста мало зависят.
Зато нужно взаимодействие с базой данных, выборки и прочее. SQL по сути своей функционален, хотелось бы его более прямой интеграции в ЯП общего назначения. Например LINQ как говорит Майер это функциональные идеи реализованные для широкой публики.
Здравствуйте, IT, Вы писали:
IT>Знаешь, у меня последнее время туго с телепатией. Ты бы сразу без наводящих вопросов сказал куда ты клонишь и мы бы не замусоривали базу RSDN лишними бессмысленными сообщениями.
Например, из фразы "В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект." можно вывести, что если использовать ФП шире уровня методов, то эффект падает.
Но мне кажется, что речь шла всего лишь о личных впечатлениях/предпочтениях/опыте, так что спорить не о чем, нес па?
Здравствуйте, IT, Вы писали:
WH>>Хотя с немерлом/скалой скорей всего не получится. Ибо позорная модель CLR/Java на которую немерле/скала сильно подвязаны ставит палки в колеса. IT>Какие именно палки?
Модели данных виртуальных машин не формализованы.
А способа строить строигие доказательства на основе неформальных моделей мне не известны.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
L>>Но мне кажется, что речь шла всего лишь о личных впечатлениях/предпочтениях/опыте, так что спорить не о чем, нес па?
IT>Ну и о чём тогда спор? Тебе кажется, что спорить не о чем, но поспорить очень хочется. Я понимаю.
А-а-а! Ты тоже из всепонимающих, сразу разгадал мою жалкую попытку вынудить тебя ввязаться в спор?
Если серьёзно, я всего лишь поправил тебя, когда ты апеллировал к флейму. Не хотел, чтобы читатели подумали, что у ФЯ нет средств для абстракции и модульности.
Здравствуйте, lomeo, Вы писали:
L>Если серьёзно, я всего лишь поправил тебя, когда ты апеллировал к флейму. Не хотел, чтобы читатели подумали, что у ФЯ нет средств для абстракции и модульности.
Ты можешь вернуться к тому флейму и продемонстрировать эти возможности во всей красе. Если у тебя получится это не только на словах, то тебе скажут спасибо все, включая меня и Влада
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ты можешь вернуться к тому флейму и продемонстрировать эти возможности во всей красе. Если у тебя получится это не только на словах, то тебе скажут спасибо все, включая меня и Влада
Ты можешь вернуться к тому флейму и перечитать ответы. Зачем мне повторяться?
Здравствуйте, IT, Вы писали:
NGG>>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.
IT>Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.
Э-э-э... Где это оказалось? У меня такое впечатление, что ты ответы не читал совсем.
Здравствуйте, IT, Вы писали:
L>>Ты можешь вернуться к тому флейму и перечитать ответы. Зачем мне повторяться?
IT>Зачем возвращаться. Твои ответы меня не убедили тогда, не думаю, что убедят и теперь.
Хм. Кроме как пожать плечами ничего не остаётся. Не убедили в чём?
Был задан вопрос, как в ФЯ работают с абстракциями, были показаны варианты как. В чём тут можно убедиться или не убедиться? А флейм там был большей частью не о том, что ФЯ нет таких средств (потому что они есть), а о том, что эти средства ни разу ни функциональные, а ОО-шные. Ты об этом что ли?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.
IT>Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.
Может я совсем глупый..., но всё-таки.
Простой случай, когда абстракция суть интерфейс с одним методом, элементарно представляется ввиде функции.
Н-р,
interface X {
void foo(String s);
}
f x = print ("f: " ++ x)
g x = print ("g: " ++ x)
test :: ([Char] -> IO()) -> IO()
test h = h "test" -- тут h - это абстракция, а не конкретная функция
Если интерфейс определяет несколько методов, тоже не беда:
interface X {
void foo(String s);
void foo(String a, String b);
}
-- abstraction
type Abstraction = (([Char] -> IO()), ([Char] -> [Char] -> IO()))
-- impl N1
f1 :: [Char] -> IO()
f1 x = print ("f1: " ++ x)
g1 :: [Char] -> [Char] -> IO()
g1 x y = print ("x1: " ++ x ++ " y1: " ++ y)
a1 :: Abstraction
a1 = (f1, g1)
-- impl N2
f2 :: [Char] -> IO()
f2 x = print ("f2: " ++ x)
g2 :: [Char] -> [Char] -> IO()
g2 x y = print ("x2: " ++ x ++ " y2: " ++ y)
a2 :: Abstraction
a2 = (f2, g2)
-- usage
test :: Abstraction -> IO()
test a =
do
(fst a) "1"
(snd a) "2" "3"
Я так понял, что речь у влада шла не об абстракциях как таковых, а о возможности "абстрагироваться" от реализации листа в конкретном языке, с целью подсунуть ему свой лист.
Здравствуйте, no4, Вы писали:
no4>Зато нужно взаимодействие с базой данных, выборки и прочее. SQL по сути своей функционален, хотелось бы его более прямой интеграции в ЯП общего назначения. Например LINQ как говорит Майер это функциональные идеи реализованные для широкой публики.
Почему-то взаимодействие с базой проблем не вызывало никогда. Хочешь пиши голый sql, хочешь через ORM (тоже одна декларативщина).
Что есть в ф-языках для этих нужд сильно удобное выше перечисленного?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, no4, Вы писали:
no4>>Зато нужно взаимодействие с базой данных, выборки и прочее. SQL по сути своей функционален, хотелось бы его более прямой интеграции в ЯП общего назначения. Например LINQ как говорит Майер это функциональные идеи реализованные для широкой публики.
NGG>Почему-то взаимодействие с базой проблем не вызывало никогда. Хочешь пиши голый sql, хочешь через ORM (тоже одна декларативщина). NGG>Что есть в ф-языках для этих нужд сильно удобное выше перечисленного?
sql и ORM как раз и есть, грубо говоря, функциональные языки. Хочется интеграции их в ЯП общего назначения, чтобы можно было написать.
employee.where(e => e.currentSalary > 1000)
причем сначала currentSalary это было поле в таблице employee, а потом currentSalary это свойство, которое вычисляется так: currentSalary = this.salaryHistory.where(x => x.startDate <= today() && x.endDate >=today())
Здравствуйте, no4, Вы писали:
NGG>>Что есть в ф-языках для этих нужд сильно удобнее выше перечисленного?
no4>Хочется интеграции их в ЯП общего назначения, чтобы можно было написать. no4>employee.where(e => e.currentSalary > 1000) no4>причем сначала currentSalary это было поле в таблице employee, а потом currentSalary это свойство, которое вычисляется так: currentSalary = this.salaryHistory.where(x => x.startDate <= today() && x.endDate >=today())
И есть ф-языки со статической типизацией, которые позволяют такие фокусы делать?
Здравствуйте, NotGonnaGetUs, Вы писали:
no4>>Хочется интеграции их в ЯП общего назначения, чтобы можно было написать. no4>>employee.where(e => e.currentSalary > 1000) no4>>причем сначала currentSalary это было поле в таблице employee, а потом currentSalary это свойство, которое вычисляется так: currentSalary = this.salaryHistory.where(x => x.startDate <= today() && x.endDate >=today())
NGG>И есть ф-языки со статической типизацией, которые позволяют такие фокусы делать?
проблемы с стат. типизацией это вызывает если исходить из традиионной модели — запрос имеет некий динамический тип, какой тип будет иметь поле Salary и будет ли оно вообще — заранее неизвестно
если исходить из другого подхода — что такая запись означает некое ограничение на опрашиваемый источник данных ("в нём есть поле Salary типа Int") и это ограничение проверяется при получении данных — проблем со статической типизацией не будет
Здравствуйте, BulatZiganshin, Вы писали:
BZ>проблемы с стат. типизацией это вызывает если исходить из традиионной модели — запрос имеет некий динамический тип, какой тип будет иметь поле Salary и будет ли оно вообще — заранее неизвестно
BZ>если исходить из другого подхода — что такая запись означает некое ограничение на опрашиваемый источник данных ("в нём есть поле Salary типа Int") и это ограничение проверяется при получении данных — проблем со статической типизацией не будет
Т.е. компилятор по рукам не отшлёпает, если ошибёшься в названии поля или его типе (решив сложить строку с числом)?
В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>>>Что есть в ф-языках для этих нужд сильно удобнее выше перечисленного?
no4>>Хочется интеграции их в ЯП общего назначения, чтобы можно было написать. no4>>employee.where(e => e.currentSalary > 1000) no4>>причем сначала currentSalary это было поле в таблице employee, а потом currentSalary это свойство, которое вычисляется так: currentSalary = this.salaryHistory.where(x => x.startDate <= today() && x.endDate >=today())
NGG>И есть ф-языки со статической типизацией, которые позволяют такие фокусы делать?
Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.
Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>проблемы с стат. типизацией это вызывает если исходить из традиионной модели — запрос имеет некий динамический тип, какой тип будет иметь поле Salary и будет ли оно вообще — заранее неизвестно
BZ>>если исходить из другого подхода — что такая запись означает некое ограничение на опрашиваемый источник данных ("в нём есть поле Salary типа Int") и это ограничение проверяется при получении данных — проблем со статической типизацией не будет
NGG>Т.е. компилятор по рукам не отшлёпает, если ошибёшься в названии поля или его типе (решив сложить строку с числом)?
если ты хочешь чтоб тебя отшлёпали — то надо описывать структуру базы в программе. кажеся, есть подобный инструмент на основе HList
NGG>В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.
я полагаю, что они делают то же самое, только средствами внешними по отношению к языку?
Здравствуйте, no4, Вы писали:
no4>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, no4, Вы писали:
no4>>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.
D>Почему нет транслятора?
Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.
Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.
Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.
Здравствуйте, BulatZiganshin, Вы писали:
NGG>>В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.
BZ>я полагаю, что они делают то же самое, только средствами внешними по отношению к языку?
В общем да. Инспектор это "отдельная программа" для анализа исходников.
Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных. Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?
no4>Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.
no4>Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.
liftM sqr?
Бесшовно не получится, поскольку одновременно скрещиваются разные типы вычислений.
no4>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.
Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...
А так получится? Оно потом транслируется?
D>Бесшовно не получится, поскольку одновременно скрещиваются разные типы вычислений.
Вот. А собственно хочется именно этого.
no4>>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.
D>Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...
currentSalary это функция, которая возвращает текущую зарплату сотрудника по этой структуре. Как она это делает, это ее дело. Допустим в версии 1 она возвращала поле структуры, в версии 2 она возвращает последнее значение из истории изменения зарплаты.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, BulatZiganshin, Вы писали:
NGG>>>В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.
BZ>>я полагаю, что они делают то же самое, только средствами внешними по отношению к языку?
NGG>В общем да. Инспектор это "отдельная программа" для анализа исходников.
NGG>Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных. Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?
Никакого специального волшебства. Есть DBDirect, который подключается к БД и генерит модули (на Хаскеле) с описанием метаданных. Поставленная тобой проблема не решается инспекцией при компиляции: если структура БД может меняться, то она, знаешь ли, может меняться после компиляции программы с тем же успехом, что и до.
Здравствуйте, no4, Вы писали:
no4>Здравствуйте, deniok, Вы писали:
D>>liftM sqr?
no4>А так получится? Оно потом транслируется?
Я с HaskellDB играл довольно давно, и уже не помню, как там упакованы выражения. Но принципиальных проблем не вижу — в монадическое вычисление можно через liftM поднять любую обычную функцию. Сборка SQL происходит в рантайме, по ходу дела в момент, когда значение sqr потребуется, оно и вычислится.
D>>Бесшовно не получится, поскольку одновременно скрещиваются разные типы вычислений.
no4>Вот. А собственно хочется именно этого.
no4>>>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.
D>>Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...
no4>currentSalary это функция, которая возвращает текущую зарплату сотрудника по этой структуре. Как она это делает, это ее дело. Допустим в версии 1 она возвращала поле структуры, в версии 2 она возвращает последнее значение из истории изменения зарплаты.
Так это же совершенно неважно! В Хаскелле главное, чтобы тип был тот же. Если тип
currentSalary::Employee -> Float
то пихай её в любое место, где ожидается Employee -> Float.
D>Так это же совершенно неважно! В Хаскелле главное, чтобы тип был тот же. Если тип
D>currentSalary::Employee -> Float
D>то пихай её в любое место, где ожидается Employee -> Float.
Ну то есть Float она, конечно, не вернёт, IO Float — может.
Здравствуйте, no4, Вы писали:
no4>>>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.
D>>Почему нет транслятора?
no4>Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.
наверно, не list comprehension, а monad comprehension. ибо первый по определению может работать только с готовыми списками, возвращёнными из БД, а тебе нужна генерация sql-запроса в соответствии с заданными критериями
no4>Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.
как-то в cafe публиковали пример, где определялась структура для символьных вычислений, и давалось определение (*) и прочего, работающее с этой структурой. после чего ты мог писать что-ниьбудь типа 2*3+4 и в зависимости от типа результата он возвразался в числовом или сивольном виде
можно попытаьься определить '*' и прочие элементарные функции так, чтобы их испольщования транслировались в sql-код
no4>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.
поскольку это всё же совершенно разные языки, само по себе это не заработает — надо делать. и тут вопрос скорее в том, какие хаскел предоставляет средства для создания DSEL. средства эти имхо мощнее чем в С* языках: монады, lazy evaluation, type inference
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных.
думаю, для описания маппинга нужно делать отдельные декларации
>Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?
во-первых, в хаскеле нет элементов ОО. во-вторых, иерархии объектов (не классов) — обычное дело для любых языков с динамическим распределением памяти, начиная с паскаля, но они легко ложатся на связь таюблиц ключеыыми полями. так что я просто не в курсе — какие проблемы вы имеете в виду?
Здравствуйте, no4, Вы писали:
no4>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...
Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам. Они это назвали qlc — query list comprehensions. Это есть в составе стандартной либы Эрланга. Легко прикручивается к абсолютно любому источнику данных — надо реализовать один простой абстрактный интерфейс.
Ну и конечно — база данных Эрланга (mnesia), разумеется, поддерживает qlc.
Здравствуйте, Gaperton, Вы писали:
no4>>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...
G>Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>во-первых, в хаскеле нет элементов ОО. во-вторых, иерархии объектов (не классов) — обычное дело для любых языков с динамическим распределением памяти, начиная с паскаля, но они легко ложатся на связь таюблиц ключеыыми полями. так что я просто не в курсе — какие проблемы вы имеете в виду?
Допустим, у нас есть такая "модель" предметной области:
Сразу встаёт вопрос: как будем хранить в базе Instructor'ов и Student'ов?
Можно создать общую таблицу, можно создать по отдельной, можно общие поля хранить в общей таблице, а различные в разных.
Отношение Course *->*Student тоже не радует. Для его представления придётся создать доп. таблицу, т.к. одними только fkeys тут не обойтись.
Допустим, что все решения были приняты и база создана и, средствами какой-нибудь утлиты, созданы соответствующие им типы данных.
Как они связаны с теми типами данных, что были использованны на входе? Отдалённо, т.к. полученные типы зависимы от выбора проектировщика бд. Их использование приведёт к связыванию логики предметной области (бизнес логики) со способом хранения данных и к усложнению кода (засчёт снижения абстракции).
Опять же, чтобы не обращаться за каждым объектом в базу, придётся писать кеши, заботиться о транзакциях, а всё это опять превращается в код, который нужно поддерживать и который, в сущности, одинаков для всех приложений работающих с базами данных. В ОО мире этот код выносится в ORM библиотеки и позволяет писать бизнес логику оперирующую с объектами определёнными в пердметной области, а не с полями всяко-разных таблиц.
T>>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?
S>а последний? S>задача была отсортировать, поэтому не стоит из неё пытаться выдумать другие задачи, которые лягут под своё решение.
нет, речь здесь идёт о том, что lazy алгоритмы более реюзабельны, чем строгие — в данном случае нет нужды писать отдельную процедуру поиска миним. элемента, она реализуется просто как head.sort
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Gaperton, Вы писали:
no4>>>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...
G>>Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам.
BZ>+ http://rsdn.ru/Forum/message/2341360.1.aspx
G>Отличный пост. Слушай, мне вот что подумалось. В С++ можно перекрывать оператор "запятая" . Можно там, пользуясь этим, изобразить злые монады?
Если бы даже нельзя было перегружать запятую, можно перегружать кучу других операторов — для монад подошел бы, например, оператор сдвига. Проблема в другом, в типе оператора bind:
(>>=) :: (Monad m) => m a -> (a -> m b) -> m b
Второй аргумент — функция, причем практически всегда это лямбда-выражение. Без замыканий монадный стиль будет практически бесполезен.
Здравствуйте, lomeo, Вы писали:
L>Ну, я к тому, что ничего тот флейм не показал, а если кто выводы и делал — то больше для себя
Он ничего не показал только упертым фанатикам. Ежу понятно, что в ФП просто нет средст декомпозиции сравнимых по мощьности с классами. То что один из языков расширен хитрой концепцией предоставляющей подобный механизм ни как не меняет дела с самим ФП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, IT, Вы писали:
T>>>Тогда зачем надо было его приводить?
IT>>Чтобы не разводить подобный флейм ещё раз.
NGG>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать,
Во-первых, почему имя с маленькой буквы?
Во-вторых, я ничего не доказывал. Я справшивал. Ответ был лично для меня очевиден. ФП сам по себе не предоставляет средств декомпозиции. Собственно это и подтвердило мое предположение.
NGG>Может я чего не понял из того флейма,
Совершенно точно. И вообще когда подходишь к вопросу с заранее готовой упертостью, то ничего новго для себя никгда не откроешь. Вообще люди которые уперлись в "одну самую правильную иделогию" потеряны для общества. Они выдают эмоции и нарушают правила логики только чтобы остаться при своем исходном мнении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
IT>>Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.
L>Э-э-э... Где это оказалось? У меня такое впечатление, что ты ответы не читал совсем.
Это оказалось когода вместо демонстрации оных начался процесс развешивания лапши на уши.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Например, из фразы "В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект." можно вывести, что если использовать ФП шире уровня методов, то эффект падает.
Вообще-то на то они и гибридные. Использовать ФП для работы с классами довольно бессмысленно если не не возможно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Был задан вопрос, как в ФЯ работают с абстракциями, были показаны варианты как. В чём тут можно убедиться или не убедиться?
Это или логические ошибки, или откровенная и довольно наглая лож. Про ФЯ речь в общем-то не шла. Речь шало про ФП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>>Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.
L>>Э-э-э... Где это оказалось? У меня такое впечатление, что ты ответы не читал совсем.
VD>Это оказалось когода вместо демонстрации оных начался процесс развешивания лапши на уши.
Лично тебе я продемонстрировал возможности классов типов для выражения абстракции, приведя в пример класс Foldable. О чём я здесь вешал тебе лапшу на уши?
Здравствуйте, VladD2, Вы писали:
VD>Он ничего не показал только упертым фанатикам. Ежу понятно, что в ФП просто нет средст декомпозиции сравнимых по мощьности с классами. То что один из языков расширен хитрой концепцией предоставляющей подобный механизм ни как не меняет дела с самим ФП.
А модульность — это, конечно, встроенный в ОО механизм по определению.
Речь идёт о том, что в ФЯ нет механизмов для выражения абстракции, поэтому создаются гибридные языки. Ну или о том, что лучше ОО для верхнего уровня ничего не придумано. Спор идёт об этом, а не "самом ФП".
Так вот, такие механизмы есть, поэтому надобность в ОО отпадает, ну не нужен он, прикинь?
T>>Слабо логически связать "преимущества ФП" и тот факт, что "сама программа является ОО?" VD>Я вообще не понял, что ты хочешь.
Почему нельзя, чтобы и методы были ОО?
Почему нельзя, чтобы и программа была ФП?
Почему программа должна быть ОО, а методы — чистыми (ФР)? Почему выгодно именно так, а не иначе?
T>>(третья версия ответа. Две первых были очень грубы) VD>Что было грубо? Опять ничего не понимаю.
Это плохо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Да, безусловно, использование функциональных фич на уровне методов даёт свои плюсы. Но, как мне кажется, эти плюсы скорее синтаксический сахар. С ними приятнее, но их использование быстрее программу не сделают, скорее наоборот (из-за неявного создания классов обёрток для методов).
А надо быстрее? Тут даже доказывать ничего не надо. Возьми самый чистый в мире ФЯ Хаскель и сравни его с тем же Немреле. Последний рвет Хаскель по производительности как тузик грулку и это при том что ты таки прав и оптимизаций фунционального плана в Немерле почти нет.
NGG>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане. Создание нового объекта в дотнете не так дорого. Это вам не С++. GC делает эту операцию относительно дешеовй. Конечно если подобные вещи делать в узком месте программы, то можно получить кучу проблем с производительностью. Но гибриды на то и гибриды чтобы давать выбор программисту, что и как применять.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>В качестве иллюстрации можно посмотреть на scala и java...
ОК. Где цирф и тесты?
В прочем, если они будут, и будут не в пользу Скалы, то это все равно ничего не даст, так как у того же C# и Nemerle производительность просто отменная.
NGG>Но забудем о производительности и вернёмся к исходному вопросу. Правильно ли я понял, что ваша точка зрения заключается в том, что никакой выгоды в использовании функциональных языков нет (за исключением возможности использовать более компактный синтаксис в телах методов)?
Это, уважаемый, гнусные примемы софистики. Где и кто такое утверждал? Nemerle, Scala, или скажем, OCaml ни чем не меньшие ФЯ нежели Хаскель или Схема. А разговор было о том, что именно в методах ФП смотрится очень к месту и по делу. ООП дает средства декомпозиции уровня системы, обеспечивает производительность за счет императивности (где надо), а ФП и его сахар позволяет записывать алгоритмы (которые в ООП и сосредоточены в методах) в более компактной и декларитивной форме.
Что касается классов типов Хаскеля, то они тоже хорошо подходят для декомпозиции уровня приложения, но по стути они являются развитием тех же идей, что и в ООП (астрактных типов данных) и к самому ФП отношения не имеют (как, скажем, классы в ОКамле).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
[]
VD>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане. Создание нового объекта в дотнете не так дорого. Это вам не С++. GC делает эту операцию относительно дешеовй.
L>>Был задан вопрос, как в ФЯ работают с абстракциями, были показаны варианты как. В чём тут можно убедиться или не убедиться? VD>Это или логические ошибки, или откровенная и довольно наглая лож. Про ФЯ речь в общем-то не шла. Речь шало про ФП.
А как их отличить?
PS
Ложь пишется с мягким знаком. Уже третий раз встречаю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Например, из фразы "В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект." можно вывести, что если использовать ФП шире уровня методов, то эффект падает.
VD>Вообще-то на то они и гибридные. Использовать ФП для работы с классами довольно бессмысленно если не не возможно.
Поскольку продолжается, повторение этого тезиса, продолжу повторение моего вопроса.
Итак, зачем использовать классы?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Определение отсортированного массива можно дать по разному. Попробуйте дать определение сортировки вставкой и сортироваки слиянием. Во вторых, делает ваш код примерно то же, но выглядит существенно угребищнее Хаскельного варианта. Третье — в вашем случае компилятор не имеет возможностей провернуть ряд ацких оптимизаций, что в состоянии сделать компилятор Хаскеля — у него будет больше информации.
Давай, чтобы не быть голословными, сравним производительность сортировки классического QuickSort написанного на Яве/дотнете в тупом императивном стиле и Хаскелевскую "красоту"? А в качестве входных данных пустим еще отсортированные по убыванию и по возрастанию списки... чтобы выбор точки разделения из начала списка привел бы к квадратичному падению скорости сортировки...
Что не хочшь?
Знаешь, что Хаскель сольет в черную при всех оптимизациях?
А тогда что мы тут обсуждаем. Это разные алгоритмы и компиляторы их сравнят не смогут. Они и структуры данных разные сортируют массив и список (а массив еще и сильно компактнее в памяти пердставлен).
Так что не надо этих инсунуаций. Тебе правлиьно показали, что тут приемущество не в некой крутости ФЯ, а в наличии готовых высокуровневых фуцний или конструкций языка и в том, что сортировка получается несолько другим алгоритмом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане.
Серьёзно? Не подскажешь сслыки, где можно почитать про такое сравнение?
Здравствуйте, VladD2, Вы писали:
VD>Во-первых, почему имя с маленькой буквы?
Потому же, почему у тебя по три не законченных слова на сообщение Опечатки...
VD>Во-вторых, я ничего не доказывал. Я справшивал. Ответ был лично для меня очевиден. ФП сам по себе не предоставляет средств декомпозиции. Собственно это и подтвердило мое предположение.
Разве это не пример того, когда "подходишь к вопросу с заранее готовой упёртостью"(с) ?
NGG>>Может я чего не понял из того флейма,
VD>Совершенно точно. И вообще когда подходишь к вопросу с заранее готовой упертостью, то ничего новго для себя никгда не откроешь. Вообще люди которые уперлись в "одну самую правильную иделогию" потеряны для общества. Они выдают эмоции и нарушают правила логики только чтобы остаться при своем исходном мнении.
Если всё так точно и ты следуешь исключительно правилам логики, может быть разъяснишь мне чего я там не понял?
Я, право, эмоции не источаю на лево и на право и логику люблю
Здравствуйте, thesz, Вы писали:
T>>>Почему именно на уровне методов? VD>>А что ему вообще делать на уровне классов если они есть?
T>Действительно, зачем классы?
Для тех кто в танке — человек сказал "в гибридах...".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Это потому что ты думаешь, что на верхнем уровне могут быть только классы.
Я даже не думаю. Я знаю, что не только. Вот толко в ФП мне не показали концепций их заменяющий. На против показали концепции аналогичные классам в конкретном ФЯ, что только укрепило мои догадки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
T>Итак, зачем использовать классы?
Для декомпозиции (и соответственно, проектирования) на уровне приложения (которое может быть не млым).
В ООП оные средсва имеются. В ФП — нет. Данная парадигма попросту осталась на уровне структурного программирования. В ОКамл были введены самые что не на есть ОО-классы. В Хаскель предмет их заменяющий. Но так или иначе рамки классического ФП подобные концепции не описаны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NotGonnaGetUs, Вы писали:
VD>>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане.
NGG>Серьёзно?
Ага.
NGG>Не подскажешь сслыки, где можно почитать про такое сравнение?
Из собственных тестов и многочисленных огворок его пользователей.
В прочем, что трепаться то? Вот тут как-то пробегал АльфаБлэндинг. Реализуй его на Хаскеле. Поглядим. Можно еще Быструю сортировку померить...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Это или логические ошибки, или откровенная и довольно наглая лож. Про ФЯ речь в общем-то не шла. Речь шало про ФП. T>>А как их отличить? VD>А вот когда ты говоришь про ФП (т.е. про парадигму), а тебе в ответ про конкретный ФЯ, то это называется подмена понятий.
Тот же Хаскель — синтаксический сахар над лямбда-исчислением с нормальным порядком упрощений. Буквально. Почему его в пример и приводят.
Что такое ООП? Определи его без языка.
VD>Если еще будут проблемы с логикой, то не стесняйся, обращайся.
Всенепременнейше.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Что такое ООП? Определи его без языка. IT>Думаю, что твои попытки сделать из дискуссии банальный терминологический трёп, в лучшем случае для тебя будут проигнорированы.
Я думал помочь Владу в переводе дискуссии в указанное им (и тобой) русло.
А вообще интересно получается: ФП без языка должно быть, ООП без языка — нет.
Double standards. Tell me about it.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Читывал ли ты про Z notation? T>>Этому средству декомпозиции и формальной спецификации лет поболе, чем любой ОО методологии. Кё>Возраст не является достоинством.
Его отсутствие тем более. Про старые вещи мы знаем больше.
Кё>Каменному топору лет поболее, чем бензопиле.
Почему же сразу каменному?
Обычному топору тоже больше лет, чем бензопиле.
И что [b]сейчас[b] чаще используется?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Что такое ООП? Определи его без языка. IT>>>Думаю, что твои попытки сделать из дискуссии банальный терминологический трёп, в лучшем случае для тебя будут проигнорированы. T>>Я думал помочь Владу в переводе дискуссии в указанное им (и тобой) русло. IT>Не видно, чтобы ты действительно реально этого хотел. По крайней мере, судя по форме твоих сообщений. А от формы напрямую зависит желание людей с тобой общаться.
Со стороны виднее.
Возьмем в качестве наблюдателя тебя.
Ты, например, увидел попытки сделать из дискуссии банальный терминологический трёп.
Я же честно пытался вести дискуссию в русле, заданном Владом. Он придирается ("вместо ФП подсовывают ФЯ"), почему нельзя мне?
Поэтому, я реально этого хотел. Того, что ты увидел.
Боюсь, правда, что я запутал тебя еще сильнее.
T>>А вообще интересно получается: ФП без языка должно быть, ООП без языка — нет. IT>Ты же ведь сам так не думаешь, правда?
Не думаю.
ФП — это язык программирования, если кто не знал. Лямбда-исчисление называется. ФЯ ограничивают порядок упрощения и навешивают синтаксический сахар, оставаясь все тем же ЛИ (читай — ФП) внутри.
ОО — метод классификации.
T>>Double standards. Tell me about it. IT>Just take it easy.
Why should I?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Кё>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
Рекомендую попробовать.
Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих.
Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime.
E>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
T>>Его отсутствие тем более. Про старые вещи мы знаем больше. Кё>Он не является в общем случае ни достоинством, ни недостатком, поэтому о нём тут вообще не стоит говорить. Кё>А кроме него ты других достоинств Z notation ты не привел.
Я пост про формальные методы вообще написал.
Там в обозрении их применения есть про плюсы и минусы на примерах многих компаний.
Небольшое чтение про Z notation выявляет, что она основана на Zermelo-Frenkel set theory, одной из наиболее полных и непротиворечивых теорий множеств.
Соответственно, с ее помощью можно отклассифицировать практически все, что встречается в жизни, не получив противоречия. И не получив затруднений наподобие "что от чего должно наследоваться — Квадрат от Прямоугольника или наоборот?"
Кё>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
Это ты привык все делать как можно абстрактней.
Достаточно не зацикливаться на "сокрытии реализации," как оно пойдет со страшной силой. Да еще и компилятором поддержано.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
Кё>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
T>Рекомендую попробовать.
. Вполне нормально получилось.
T>Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих.
T>Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime.
Извините, юмора не понял.
Я сам делал обращения к полуленточной матрице в виде обычной записи a[i][j] -- в точности как к обычной. Что дало существенное упрощение реализации пусть и учебной, но все-таки задачи. Не показалось ни много, ни мало.
E>>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
T>Indexless algebra?
Здравствуйте, thesz, Вы писали:
Кё>>>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр. T>>>Рекомендую попробовать. E>>Пробовал, 13 лет назад
. Вполне нормально получилось.
T>Это же явно не сегодняшний день.
ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
T>(про невозможность применить метод Гаусса понравилось даже мне, не полностью прочитавшему Вычислительную Линейную Алгебру уже забыл, какого автора)
Да, мне нравиться веселить людей. Особенно хорошо это получается с теми, кто уверен в своей интеллектуальной непогрешимости и черезвычайно широкой эрудиции.
T>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась?
Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
T>Не из-за этого ли все тормозило?
У кого тормозило?
T>>>Indexless algebra? E>>И что я должен был увидеть в куче устаревших ссылок типа: http://www.numeric-quest.com/haskell/Orthogonals.html E>>
T>Wayback Machine to the rescue!
T>Да и просто в качестве идеи.
T>В тех же самых cache oblivious вариантах перемножения матриц применяется, практически, indexless представление. Там такой рекурсивный алгоритм блочного перемножения.
T>Смотри, сколько я умных слов знаю! Это из-за использования ФЯ, вот так.
Наверное, освоившие ФЯ люди по фразе google:indexless+algebra способны найти все, что им нужно.
Завидую вам, но с гораздо большим уважением отношусь к тем, которые ради экономии времени собеседника дают точные URL. К счастью, они встречаются даже среди приверженцев ФП.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодёнок, Вы писали:
IT>>Что именно тебе не понятно в этом выражении: максимальный или эффект?
Кё>Какая ловкая демагогия Что именно тебе не понятно в выражении «треугольный звук» — «треугольный» или «звук»?
Ну, а если закочить упражнения, то ты можешь объяснить, что непонятного в словах ИТ?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Вполне нормально получилось. T>>>Это же явно не сегодняшний день. E>>ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
T>Я про другое.
T>С тех пор ландшафт языков изменился.
T>Например, ФЯ перестали быть уделом избранных.
Сильно сомневаюсь. Может быть количественно приверженцев ФЯ и стало больше, но в процентном соотношении ко всем остальным программистам ситуация могла и не измениться.
T>>>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась? E>>Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
T>djgpp? watcom?
T>Или какая-то религия не позволяла?
Железо. На наших 86-х было всего 640Kb памяти. На 286-х 1Mb, но с использованием himem.sys под DOS-овские программы удавалось выкраивать что-то около 600-610Kb.
В распоряжении был только Borland C++ 2.0.
Да и в любом случае удалось бы втиснуть в 1Mb СЛАУ для 300КУ, обломились бы на 350.
T>>>Не из-за этого ли все тормозило? E>>У кого тормозило?
T>Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.
Насколько я понимаю, я использовал метод простой итерации (вроде бы он называется методом Якоби), где на каждом шаге вычислялось очередное приближение вектора неизвестных. При увеличении точности количество итераций значительно возрастало. Это же итерации, а не точный метод (вроде метода квадратных корней, Гаусса или Халецкого).
T>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).
T>http://www.ddj.com/cpp/184403264
T>Беда с этими универсальными интерфейсами.
Да, здесь идет плата скоростью исполнения за скорость разработки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты). T>>http://www.ddj.com/cpp/184403264 T>>Беда с этими универсальными интерфейсами. E>Да, здесь идет плата скоростью исполнения за скорость разработки.
Ну, я о чем и говорю. Точнее, о чем и говорили в самом начале.
ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Ну, я к тому, что ничего тот флейм не показал, а если кто выводы и делал — то больше для себя
VD>Он ничего не показал только упертым фанатикам. Ежу понятно, что в ФП просто нет средст декомпозиции сравнимых по мощьности с классами. То что один из языков расширен хитрой концепцией предоставляющей подобный механизм ни как не меняет дела с самим ФП.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, VladD2, Вы писали:
VD>>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане.
NGG>Серьёзно? Не подскажешь сслыки, где можно почитать про такое сравнение?
Здравствуйте, thesz, Вы писали:
T>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?
T>В случае Хаскеля O(n). У тебя?
И эти люди тут рассуждают о высших материях...
Это с каких пор у нас алгоритм быстрой сортировки Хора давал результаот O(n)?
И какие к черту первые элементы при сортировке? Пока все не отсортируешь, ни одного элемента не получишь.
Если QuickSort будет написан по человечески в стиле С, то ты в лучшем случае получишь логарифмическую зависимость, а написав его таким вот образом ты получишь полную задницу. Именно по этому в реальной жизни в ФЯ для сортировки списков используют алгоритм сливания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
T>>В случае Хаскеля O(n). У тебя?
VD>Это с каких пор у нас алгоритм быстрой сортировки Хора давал результаот O(n)?
VD>И какие к черту первые элементы при сортировке? Пока все не отсортируешь, ни одного элемента не получишь.
кстати, на дняз было сообщение о библиотеке lazy quick check. если я правильно понял, она быстро проверяет все возможные варианты списка/дерева/.. вплоть до определённого размера именно за счёт ленивости — если результат вычислений не зависит от некоторых значений (они остаются невычисленными), то какой смысл генерировать раличные их варианты?
Announcing Lazy SmallCheck 0.1, a library for exhaustive,
demand-driven testing of Haskell programs.
Lazy SmallCheck is based on the idea that if a property holds for a
partially-defined input then it must also hold for all fully-defined
instantiations of that input. Compared to `eager' input generation
in SmallCheck, Lazy SmallCheck may require significantly fewer
test-cases to verify a property for all inputs up to a given depth.
There you'll find a more detailed description, a worked example, a
comparison with SmallCheck on a number of benchmarks, and link to
download the library.
The library was developed together with Fredrik Lindblad during his
recent visits to York.
Suggestions, experiences and bug reports are welcome!
Вапще-то в этом случае (даже в случае Хаскелла) лучше всё-таки воспользоваться стандартными функциям min/max. Даже если сортировка нестандартных объектов специализированной функцией сорт, всё равно min/max лучше... :о))
Здравствуйте, BulatZiganshin, Вы писали:
BZ>кстати, на дняз было сообщение о библиотеке lazy quick check. если я правильно понял, она быстро проверяет все возможные варианты списка/дерева/.. вплоть до определённого размера именно за счёт ленивости — если результат вычислений не зависит от некоторых значений (они остаются невычисленными), то какой смысл генерировать раличные их варианты?
Я не понял, причем тут какието "lazy quick check" и банальная быстрая сортировка?
Орлы вы уже так перефанатели, что ради прославления бох вест чего начинаете оспаривать законы логики и физики.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
thesz,
T>>>Не из-за этого ли все тормозило? E>>У кого тормозило?
T>Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.
T>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).
T>http://www.ddj.com/cpp/184403264
T>Беда с этими универсальными интерфейсами.
Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Причин две: NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп. NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Я лично использую ocaml для некоторой разновидности задачи символьных вычислений и переписывания термов. Проект не коммерческий, а, скажем, научно-эксперементальный. Проверяю свои теоретизирования для научной работы. Лучше ocaml-а для этой задачи пока не нашел. Он, имхо, наиболее оптимально сочетает высокоуровневые возможности ФП, что очень удобно для быстрого прототипирования, когда надо срочно поверить новую идейку, и производительность, что также очень важно, ибо размерности задачи иногда огромные и решения приходится ждать по нескольку часов. Моя практика показывает что ocaml (ну и наверное в меньшей степени scala) хорошо подходят для задач обработки всевозможных рекурсивных структур данных. Типичное приложение — разработка трансляторов. Ковыряй в эту сторону. Насчет lisp-а ничего путного сказать не могу.
Здравствуйте, thesz, Вы писали:
T>>>Беда с этими универсальными интерфейсами. LCR>>Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...
T>http://thesz.livejournal.com/807522.html
Неточность:
Для ленточной матрицы формула для вычисления индексов была очень сложной и если ее выписывать напрямую в умножении, то получалось сложно и с ошибками. Товарищи сделали абстрактный интерфейс матрицы, где выборка коэффициентов скрывалась, и умножение записывалось очень просто.
Решение скрыть реализацию матрицы за интерфейсом было принятно не из-за сложности записывания операции перемножения матрицы, а из-за сложности записи формул апроксимации конечных элементов. На каждый узел четырех-угольного элемента приходилось уравнение в две строки длиной, в котором задействовались как остальные узлы элемента, так и узлы соседних элементов. Ошибиться в индексах в такой формуле гораздо страшнее, чем в операции перемножения.
То, что в методе итераций я не додумался использовать только L элементов, входящих в полуленту -- да, есть такой грех. Начало четвертого курса, как-никак, да и не ВМиК МГУ К тому же в любом случае метод итераций дает приближенное значение, а методы Гауса и Халецкого -- точные за один проход.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>То, что в методе итераций я не додумался использовать только L элементов, входящих в полуленту -- да, есть такой грех. Начало четвертого курса, как-никак, да и не ВМиК МГУ К тому же в любом случае метод итераций дает приближенное значение, а методы Гауса и Халецкого -- точные за один проход.
Да и еще одна штука. Насколько я помню, при N=100 ширина полуленты была где-то 10-15.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: В чём выгода от функциональных языков?
От:
Аноним
Дата:
19.07.08 17:16
Оценка:
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Бывает приятно посидеть вечерком на работе, поделать простенькие программки, почитать баталии ООП vs ФЯ. Достаточно продолжительное время пробовал использовать фвп в коде на c#, но, как бы это сказать, запал стал проподать.
Там это как-то коряво сделано. Типы писать задалбывает, нормального type inference нет и не будет. Я пробовал написать библиотеку, аналогичную parsec, но на C#... С тех пор в функциональном стиле на C# писать зарёкся.
NGG>Причин две: NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
У меня другие, значит, насущные задачи. Мои задача на Java решаются долго, криво, и муторно. А на Лиспе или Хаскелле — в десяток строк и без использования мозгов вообще.
NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
Они дают более адекватный набор примитивов для формулировки решения задачи. Соотвественно, думать надо гораздо меньше.
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Ну, например, любая задача, которая требует реализации маленького проблемно-ориентированного языка.
Если нам не помогут, то мы тоже никого не пощадим.
Автор(ы): Крэг Ларман
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
