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

T>Вопрос об IDE мы оставим за кадром.

T>Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку.

T>IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.


Вот этот момент спорен. Я на собственном опыте могу судить, что java в notepad и java с IDE IDEA — это небо и земля. Скорость работы с кодом увеличивается не немного, а раза в 4 точно:
— автокомплит (название метода, краткая справка)
— навигация по коду (переход на определение, поиск использований)
— автоматические рефакторинги (ввести переменную, ввести метод, сделать inline и т.п.)

Разве наличие таких инструментов для haskell/lisp не сделало бы работу с ними проще?

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

Здравствуйте, 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/

Автор(ы): Крэг Ларман
Издательство: Вильямс
Цена: 533р.

Применение UML 2.0 и шаблонов проектирования — всемирно известное издание, с помощью которого можно начать "мыслить объектами" и проникнуть в самую суть объектно-ориентированного анализа и проектирования. Основываясь на двух предыдущих изданиях,

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

Здравствуйте, 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 сама по себе такая структура, что при создании нового листа этому самому листу понадобится старый лист.

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

T>Во-первых, эффект, он положительный или?

Раз максимальный, значит положительный.

T>Во-вторых, что за сам эффект, в чем проявляется.

В удобстве кодирования и сопровождения кода на уровне методов.

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

T>В-третьих, определи "степень," чтобы было понятно, что за максимальность.

Недавно у нас тут состоялся весьма любопытный флейм

Автор: VladD2
Дата: 01.06.07

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

T>После чего мы вернемся к применимости этого дела в программе в целом.

Ok.

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

NGG>>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?

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

IT>Мы здесь разве о производительности ведём речь?

Хороший вопрос.
Я высказал мысль о том, что реализация фич ф-языков посредством закадрового оо-муляжа не самое лучшее решение, поскольку она приводит к снижению производительности.
В качестве иллюстрации можно посмотреть на scala и java...

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

Здравствуйте, 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/

Автор(ы): Крэг Ларман
Издательство: Вильямс
Цена: 533р.

Применение UML 2.0 и шаблонов проектирования — всемирно известное издание, с помощью которого можно начать "мыслить объектами" и проникнуть в самую суть объектно-ориентированного анализа и проектирования. Основываясь на двух предыдущих изданиях,

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

Только для Эрланга. И, возможно, для Лиспа. Потому как, это единственные ФЯ, которые применялись не только академически.

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

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

Буквально постом выше я давал ссылку на топик

Автор: VladD2
Дата: 01.06.07

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

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

NGG>Почему меньше? За счёт чего? Не совсем понятно.
NGG>Только из-за декларативности конструкций? Но декларативно можно писать на любом языке, потратив какое-то время на создание соответствующей библиотеки...
Такую как в хорошем ФЯ — очень сложно и громоздко.

NGG>Или речь о том, что мат. постановка задачи легче ложится на функционнальный язык?
NGG>Но если сделать постановку в терминах объектов и отношений между ними, то она легче ляжет на императивный объектно-ориентированный язык, чем на функциональный...
Это, как раз, не так. Большая часть реальных описаний — как раз декларативна (достаточно посмотреть на УК РФ, например ). Поэтому переводить их в императивный вид — та еще задачка.

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

Хотя у ООП тоже есть плюсы — пока что не придумали более удобного способа создавать компонентные системы.

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

IT>Недавно у нас тут состоялся весьма любопытный флейм

Автор: VladD2
Дата: 01.06.07

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

Ты про то, что классы типов — это ООП? Так ничего он не показал, был типичный рсдновский флейм.

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

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

NGG>>Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?

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

Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation.

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

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

T>>Define максимальный эффект.

IT>Что именно тебе не понятно в этом выражении: максимальный или эффект?

из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^

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

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

Давай не будем. Мне хватило того топика для обсуждения этих проблем.

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

IT>Давай не будем. Мне хватило того топика для обсуждения этих проблем.

Ну, я к тому, что ничего тот флейм не показал, а если кто выводы и делал — то больше для себя

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

E>из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^

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

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

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

E>>из этого словосочетания понятно только, что для "эффекта" определена функция сравнения, но как "эффект" вычисляется — непонятно. ^____^

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

Всеравно непонятно ^__^
эффект — это уменьшение затрат на разработку/рефакторинг/понимание другим человеком?

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

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

L>Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation.

Если эта проблема специфична для читых ФЯ, то это в чистом виде сравнение тёплого с мягким.

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

L>>Видимо, речь идёт об оптимизациях в чистых ФЯ. Например, популярный deforestation.
IT>Если эта проблема специфична для читых ФЯ, то это в чистом виде сравнение тёплого с мягким.
Это не проблема. Это оптимизация которая становится возможной благодоря формализации операций.
Например:

listOfInts.Map(i => i.ToString()).Filter(s => s.Length > 3).Iter(s => WriteLine(s));

Сворачивается компилятором в

foreach (i in listOfInts)
{
    def s = i.ToString();
    when (s.Length > 3)
        WriteLine(s);
}

При этом не порождая 2 промежуточных списка которые ничего (кроме тормозов и отжирания памяти) не дают.