Здравствуйте, IT, Вы писали:
WH>>Это не проблема. Это оптимизация которая становится возможной благодоря формализации операций.
IT>Тогда тем более проблем не вижу.
Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится.
Здравствуйте, lomeo, Вы писали:
IT>>Тогда тем более проблем не вижу.
L>Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится.
Какая разница?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>Проблема в том, что если использовать ФП в смешанных языках, то подобные оптимизации делать, скорее всего, не получится. IT>Какая разница?
Дело в том что тут происходит изменение алгоритма.
И доказать что результат будет тот же можно только если модель языка формализованна.
У гебридов с формализацией модели слабовато
Впрочем это не фатальный недостаток. Просто этим нужно заняться.
Хотя с немерлом/скалой скорей всего не получится. Ибо позорная модель CLR/Java на которую немерле/скала сильно подвязаны ставит палки в колеса.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Есть какой-нибудь туториал для тех, кто верит, что emacs это круто, но ни как не может это ощутить? Being Productive With Emacs
Здравствуйте, Константин Л., Вы писали:
КЛ>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>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
T>>Тогда зачем надо было его приводить?
IT>Чтобы не разводить подобный флейм ещё раз.
Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.
Создать "абстракцию" подразумевающие множество реализаций в ф-языках можно без всякого ооп. То, что этого нельзя сделать для встроенного в язык листа, не должно никого удивлять, ведь никого же не удивляет, что класс Int32 нельзя расширить...
Может я чего не понял из того флейма, что должно было помочь с ответом на мой вопрос?
NGG>Меня мучает вопрос о применимости функциональных языков. Охотно верю, что задачи связанные с голой математикой существенно проще делать на хаскел, чем на с++ или java, но будет ли выгода от использования хаскел при создании приложений уровня ентерпрайс? В них, обычно, нет зубодробильной алгоритмической сложности, а та что есть, подчиняется не столько красивым мат.теориям сколько не красивым workflow, которые от программиста мало зависят.
Зато нужно взаимодействие с базой данных, выборки и прочее. SQL по сути своей функционален, хотелось бы его более прямой интеграции в ЯП общего назначения. Например LINQ как говорит Майер это функциональные идеи реализованные для широкой публики.
NGG>Создать "абстракцию" подразумевающие множество реализаций в ф-языках можно без всякого ооп. То, что этого нельзя сделать для встроенного в язык листа, не должно никого удивлять, ведь никого же не удивляет, что класс Int32 нельзя расширить...
Здравствуйте, IT, Вы писали:
IT>Знаешь, у меня последнее время туго с телепатией. Ты бы сразу без наводящих вопросов сказал куда ты клонишь и мы бы не замусоривали базу RSDN лишними бессмысленными сообщениями.
Например, из фразы "В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект." можно вывести, что если использовать ФП шире уровня методов, то эффект падает.
Но мне кажется, что речь шла всего лишь о личных впечатлениях/предпочтениях/опыте, так что спорить не о чем, нес па?
Здравствуйте, IT, Вы писали:
WH>>Хотя с немерлом/скалой скорей всего не получится. Ибо позорная модель CLR/Java на которую немерле/скала сильно подвязаны ставит палки в колеса. IT>Какие именно палки?
Модели данных виртуальных машин не формализованы.
А способа строить строигие доказательства на основе неформальных моделей мне не известны.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Если нам не помогут, то мы тоже никого не пощадим.
