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

L>>Но мне кажется, что речь шла всего лишь о личных впечатлениях/предпочтениях/опыте, так что спорить не о чем, нес па?

IT>Ну и о чём тогда спор? Тебе кажется, что спорить не о чем, но поспорить очень хочется. Я понимаю.

А-а-а! Ты тоже из всепонимающих, сразу разгадал мою жалкую попытку вынудить тебя ввязаться в спор?

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

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

NGG>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.

Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.

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

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

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

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

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

Ты можешь вернуться к тому флейму и перечитать ответы. Зачем мне повторяться?

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

NGG>>Я прочитал ту баталию и из неё совсем не видно, что сторона в лице vlada что-то смогла доказать, кому-то кроме себя.

IT>Сторона Влада ничего и не доказывала. Она спрашивала как средствами ФП выразить абстракцию. Оказалось, что средствами ФП никак.

Э-э-э... Где это оказалось? У меня такое впечатление, что ты ответы не читал совсем.

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

L>Ты можешь вернуться к тому флейму и перечитать ответы. Зачем мне повторяться?

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

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

L>>Ты можешь вернуться к тому флейму и перечитать ответы. Зачем мне повторяться?

IT>Зачем возвращаться. Твои ответы меня не убедили тогда, не думаю, что убедят и теперь.

Хм. Кроме как пожать плечами ничего не остаётся. Не убедили в чём?

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

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

L>Ты об этом что ли?

Нет, я совсем не об этом. Я о том, что ФП лучше всего себя проявляет на уровне методов.

Здравствуйте, 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 (тоже одна декларативщина).
Что есть в ф-языках для этих нужд сильно удобное выше перечисленного?

L>>Ты об этом что ли?
IT>Нет, я совсем не об этом. Я о том, что ФП лучше всего себя проявляет на уровне методов.

Почему именно на уровне методов?

Почему не шире/уже?

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). У тебя?

"NotGonnaGetUs" writes:

[...]

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

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

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

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

[...]

> "Ловушки", конечно, есть, но они довольно хорошо описаны в различных
> источниках и через какое-то время изучения ооп перестают казаться
> ловушками

Но от того не перестают быть ловушками (и срабатывать)

[...]

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

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

T>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?

T>В случае Хаскеля O(n).

Не всегда. Иногда и O(n^2).

Здравствуйте, 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 инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.

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