Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46647
Вчера рассеянно просматривал лекции Юрия Жлобы по Эрланг. Меня не столько язык итересовал
сколько брокер Rabbit-Mq и архитектура его устойчивости к сбоям. Поскольку он написан на Erlang
то я искал некоторые ответы на вопросы в самом языке. И вот что я заметил. Есть семейство языков
Erlang/Lisp/Prolog у которых очень много похожих свойств. Причем настолько похожих что кажется
что они концепции просто копировали. И похожести в них больше чем в С++/Java/C#. От пролога
- предикаты и нотация записи процедур запятая-запятая-точка. От Лиспа - списки.
13 май 20, 17:46    [22132291]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered
Я бы назвал столпами ФП: иммутабельность, ленивость и хвостовая рекурсия. Всякие операции с коллекциями, а-ля стримы, мапперы, редусеры ни в коем мере не является функциональной спецификой, ни с теоретической, ни с практической точки зрения. Операции с коллекциями есть чуть ли не во всех языках.

Ленивость и хвостовая рекурсия это следствия, а не причины(при чем первое вообще присутствует далеко не во всех ФП-языках).
Столпы ФП - pure, total, side-effects free функции + immutable data + high-order-functions(частным случаем которых как раз и являются стримы редьюсеры и т.п)
13 май 20, 17:46    [22132292]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
mayton
Вчера рассеянно просматривал лекции Юрия Жлобы по Эрланг. Меня не столько язык итересовал
сколько брокер Rabbit-Mq и архитектура его устойчивости к сбоям. Поскольку он написан на Erlang
то я искал некоторые ответы на вопросы в самом языке. И вот что я заметил. Есть семейство языков
Erlang/Lisp/Prolog у которых очень много похожих свойств. Причем настолько похожих что кажется
что они концепции просто копировали. И похожести в них больше чем в С++/Java/C#. От пролога
- предикаты и нотация записи процедур запятая-запятая-точка. От Лиспа - списки.

Так а что в этом удивительного? Закономерное развитие, когда новые языки вбирают в себя хорошо работающие идеи из старых.
13 май 20, 17:55    [22132300]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46647
Я-бы добавил вывод типов и генерики и паттерн-матчинг. 2 пункт вообще очень **ёво реализовано в Java.
То что в Java навзали Generics вообще не имело право так называться. Их можно было назвать compile-time-guards (CTG)
или что-то вроде этого. И поведение примитивных типов по отношению к CTG вообще не определено. Тоесть
вы старалить. Описывали обобщенный алгоритм но не можете применить его к целому числу. Хотя сам бох
велел скомпилировать хардкод для целого числа но ... компиллятор вставляет туда Object с RTTI Integer
семантикой. Какие накладные при этом несет код - сложно представить.

Я догадываюсь почему Одерский плюнул и стал делать свой язык. Хотя он ведь был коммитером самых первых
версий JDK в эпоху Sun.
13 май 20, 17:55    [22132301]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
mayton


Я догадываюсь почему Одерский плюнул и стал делать свой язык. Хотя он ведь был коммитером самых первых
версий JDK в эпоху Sun.

Так он прямо об этом говорит.
А сделали так коряво потому что backward-compatibility считали важнее чем теоретическая правильность
13 май 20, 17:57    [22132304]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46647
Так для JVM все равно. Эту механику можно было реализовать еще в эпоху JDK 1.1. Просто компиллятор
делал бы больше преобразований. Честное слово возьму ASM/CGlib и насетаплю свой Java-Kava с блекджеком
и женщинами.
13 май 20, 18:04    [22132312]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8557
unregestered

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

+++

unregestered

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

Статью прочитал - но не понял.

Пусть у меня есть необходимость задать некую операцию (например "оплата") над двумя классами объектов. Платеж и начисление. При этом может быть несколько типов платежа и несколько вариантов оплаты начисления. К примеру: обычная оплата, оплата из аванса и так далее. И разные классы начислений: обычное начисление, пени/штраф и так далее.

В данном примере, нужно реализовать 2x2=4 варианта. Система живет, появляется новый класс начисления, нужно новое поведение. Оп...ля... уже нужно 2x3=6 вариантов.... Система живет, появляется еще новый класс оплаты. Эквайрингу, сбербанк-бизнес-онлайн, оплата по QR-CODE. Оп... 5x3 = 15 вариантов Функции. Появились новые классы начислений, требуют разнести воду, канализацию, экологию раздельно. 5x6=30 вариантов.

Плохо я себе это представляю, на уровне компилятора.

В классической программе, от такой мешанины получится спагетти код из if'ов, где кол-во if'ов будет __значительно__ меньше полного набора вариантов M x N

В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste
13 май 20, 18:44    [22132344]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
fixxer
Member

Откуда:
Сообщений: 791
mayton
Есть семейство языков
Erlang/Lisp/Prolog у которых очень много похожих свойств.


Первая версия Эрланга была написана на Прологе, оттуда и заимствование синтаксических конструкций.
13 май 20, 19:13    [22132366]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
mayton
Есть семейство языков
Erlang/Lisp/Prolog у которых очень много похожих свойств.

Между Erlang-ом и нет вообще ничего общего, ибо пролог это логическое программирование с недетерминированным (в общем случае) поведением програм
13 май 20, 19:32    [22132376]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
Leonid Kudryavtsev


В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste


Необязательно. Реализуй только те что тебе конкретно нужны, речь не идет о cartesian product
13 май 20, 19:36    [22132379]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
забыл ник

Ленивость и хвостовая рекурсия это следствия, а не причины(при чем первое вообще присутствует далеко не во всех ФП-языках).
Столпы ФП - pure, total, side-effects free функции + immutable data + high-order-functions(частным случаем которых как раз и являются стримы редьюсеры и т.п)


High-order functions это указатели на функции что ли? Так вызов функции с колбаком в С и ассемблере -это и есть high-order.

Основная идея ФП - это неизменяемость состояний и чистота функций.
Lazy присваивания и определения заменяют обычное присваивание, изменяющее состояние.
Без хвостовой рекурсии нам придётся использовать циклы, которые тоже изменяют состояние.
Если так "ФП" не имеет ленивости, то вряд ли его можно назвать ФП. Просто этот термин щас лепят куда не попадя.
Кроме того, ленивость нужна для динамического программирования (в качестве аналога кэширования), если язык не меняет состояние то динамического программирование надо делать через кэширование.
13 май 20, 19:42    [22132384]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
mayton
Я-бы добавил вывод типов и генерики и паттерн-матчинг. 2 пункт вообще очень **ёво реализовано в Java.


Паттерн-матчинг это 3-яя парадигма наряду с функциональным программированием и процедурным.

В Computer Science машина тьюринга - это процедурный подход, ламбда исчисление - это функциональный, а pattern-matching-у соответствуют нормальные алгорифмы Маркова.

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

Сообщение было отредактировано: 13 май 20, 19:58
13 май 20, 19:50    [22132386]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
Leonid Kudryavtsev

Статью прочитал - но не понял.

Пусть у меня есть необходимость задать некую операцию (например "оплата") над двумя классами объектов. Платеж и начисление. При этом может быть несколько типов платежа и несколько вариантов оплаты начисления. К примеру: обычная оплата, оплата из аванса и так далее. И разные классы начислений: обычное начисление, пени/штраф и так далее.

В данном примере, нужно реализовать 2x2=4 варианта. Система живет, появляется новый класс начисления, нужно новое поведение. Оп...ля... уже нужно 2x3=6 вариантов.... Система живет, появляется еще новый класс оплаты. Эквайрингу, сбербанк-бизнес-онлайн, оплата по QR-CODE. Оп... 5x3 = 15 вариантов Функции. Появились новые классы начислений, требуют разнести воду, канализацию, экологию раздельно. 5x6=30 вариантов.

Плохо я себе это представляю, на уровне компилятора.

В классической программе, от такой мешанины получится спагетти код из if'ов, где кол-во if'ов будет __значительно__ меньше полного набора вариантов M x N

В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste


Не нужно реализовывать 4 варианта, достаточно реализовать функции для базовых классов.
Если вы напишете ещё одну функцию с более специфическим типом, то этот вариант будет "перекрывать" более универсальный.
Это что-то типа полиморфизма, но по нескольким типам.
Такая фича есть в груви
13 май 20, 19:54    [22132387]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered

High-order functions это указатели на функции что ли? Так вызов функции с колбаком в С и ассемблере -это и есть high-order.

По смыслу правильно, но вернее будет сказать что hof - это функции, которые могут принимать длругие функции как параметр либо возвращать функции(currying, closures).

unregestered

Основная идея ФП - это неизменяемость состояний и чистота функций.

Именно об этом я и сказал

unregestered

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

Именно поэтому они и являются следствием, а не причиной(immutability, не устану повторять "как я и сказал")

unregestered

Если так "ФП" не имеет ленивости, то вряд ли его можно назвать ФП.
Кроме того, ленивость нужна для динамического программирования (в качестве аналога кэширования), если язык не меняет состояние то динамического программирование надо делать через кэширование.

Lazy спокойно эмулируется в обычной Java с помощью паттерна Command, к теории ФП это не имеет отношения.

unregestered

Просто этот термин щас лепят куда не попадя.

Это да.
13 май 20, 19:56    [22132389]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered

Такая фича есть в груви

В Clojure тоже. В динамически-типизированных языках реализовать мультиметоды проще
13 май 20, 19:58    [22132391]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered


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

Чем Scala не угодила? Не говоря о Haskell
13 май 20, 20:00    [22132393]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
забыл ник
unregestered


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

Чем Scala не угодила? Не говоря о Haskell


В хаскеле тоже есть, но не уверен насколько полноценный, ибо не являюсь спецом по хаскелю. А в скале он вообще какой-то кривой - какие-то case-ы надо писать и пр. Или как, например, сматчить по полю дочернего объекта? Есть такое в Скале? В друлсах есть.
13 май 20, 20:09    [22132399]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
забыл ник

Lazy спокойно эмулируется в обычной Java с помощью паттерна Command, к теории ФП это не имеет отношения.


А как съэмулировать лези лист? А если надо мне надо lazy A прибавить к lazy B, это значит мне надо ещё один класс сделать вместо A+B? В общем, за такие фокусы в джаве надо руки отрывать )
13 май 20, 20:14    [22132402]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered
забыл ник
пропущено...

Чем Scala не угодила? Не говоря о Haskell


В хаскеле тоже есть, но не уверен насколько полноценный, ибо не являюсь спецом по хаскелю. А в скале он вообще какой-то кривой - какие-то case-ы надо писать и пр. Или как, например, сматчить по полю дочернего объекта? Есть такое в Скале? В друлсах есть.

Да, насчет синтаксиса соглашусь. Тем не менее, сматчить по полю дочернего объекта можно. А вот сматчить List[String] vs List[Int] все же не получится, из-за erasure.
Насчет Haskel - там классический паттерн-матчинг в моем понимании(каждый матчинг - отдельная функция, которая в зависимости от аргументов переадресует на свою ветку кода)
13 май 20, 20:27    [22132406]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46647
В топике генерации кривой Гильберта я пытался создать ленивый список
на Java. Ничего не вышло. Но мне помогли с созданием аналогичного функционала
на Scala.
13 май 20, 20:30    [22132408]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered


А как съэмулировать лези лист?

Так list.stream() же..

unregestered

А если надо мне надо lazy A прибавить к lazy B, это значит мне надо ещё один класс сделать вместо A+B?

Ну с этим беда

unregestered

В общем, за такие фокусы в джаве надо руки отрывать )

Согласен, но тем не менее мой поинт в том что lazy это все-таки далеко не основное и необходимое в ФП, это скорее интересное следствие при попытке реализовать ФП
13 май 20, 20:30    [22132409]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
mayton
В топике генерации кривой Гильберта я пытался создать ленивый список
на Java. Ничего не вышло. Но мне помогли с созданием аналогичного функционала
на Scala.

Ну тут надо еще определиться что есть lazy list.
А то ведь есть и такие реализации - https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/list/LazyList.html
13 май 20, 20:34    [22132412]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
забыл ник

Согласен, но тем не менее мой поинт в том что lazy это все-таки далеко не основное и необходимое в ФП, это скорее интересное следствие при попытке реализовать ФП


Ну все 4 парадигмы (процедурное, логическое, функциональное и паттерн-матчинг) могут эмулировать друг-друга ибо все turing-complete.

Другое дело - насколько это удобно. То мы пару читабельных строчек напишем, а то кучу команд, с абстрактными классами, third-party библиотеками, кодогенераторами и портянкой кода
13 май 20, 20:55    [22132419]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10178
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит.
Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся.
13 май 20, 23:25    [22132492]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
Basil A. Sidorov
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит.
Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся.


Истину глаголишь!
14 май 20, 04:15    [22132548]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Java Ответить