В самой джаве как языке программирования я тоже ничего прекрасного не вижу. Но это прекрасная платформа.
И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это Clojure (для скобочников) и Scala (для любителей типизации).
А можно использовать Хаскель и какую-либо шину сообщений. Тогда вообще всё великолепно - "стабильность и надёжность джавы" и передний край функционального программирования.
Можно, кстати. Для внутренних коммуникаций хороший вариант (кстати, что принято в хаскеле использовать? ZeroMQ какой-нибудь?) Но клиенты-сволочи хотят стандартных протоколов иногда...
С первым утверждением полностью согласен, а со вторым - не полностью. :)
Во-первых, Clojure - при том, что он мне нравится и я на нём пишу - не передний край ФП, а скорее bottom line. Почти как сама Java для ООП в своё время.
Во-вторых, особенности JVM объективно мешают реализовывать на ней ФП языки.
В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
Но это уже пошла вкусовщина и личные оценки, а в видении объективной картины мы, как мне кажется, совпадаем.
А mutually recursive слабо? ;) Да фиг бы с ним - это просто всем понятные финтифлюшки. На JVM не получится сделать существенно более полезные оптимизации - thesz указал, что нельзя руками оптимизировать использование памяти и управлять боксингом, при всей гениальности сборщика мусора в (HotSpot) Java, для ФП лучше подходит несколько другой, проблемы с реализацией, а тем более - оптимизацией, ленивости... Но я не специалист, конечно.
Дело не в переднести края - переднесть сама по себе ни для чего не нужна. Относительно удачно Java и ФП сочетает Clojure - за счёт динамики и преимущественного отрицания ООП (оно там прикручено сбоку для совместимости, а писать в ООП стиле на Clojure - извращение). В Scala получился слишком навороченный синтаксис и слишком сложная система типов - на мой взгляд. И то, и другое естественное следствие концепции Scala, но от этого удобнее программировать не становится.
Да, в JVM нельзя руками управлять памятью. Она не для того. Если в задаче требуется ручное управление памятью (что на данный момент имеет смысл только в embedded-приложениях и массивно-параллельных задачах а-ля CUDA), то лучше взять что-нибудь другое.
Mutually recursive обычно слабо. Но там, где нужно mutually recursive, лучше подумать и сделать как-нибудь ещё. Кроме чисто математических генераторов последовательностей, ни разу взаимная рекурсия мне не пригождалась.
«Слишком навороченный синтаксис» при рассмотрении становится достаточно регулярным. Я бы сказал, он примерно на уровне самой джавы. Сложнее хаскеловского, конечно, но вполне сравним с синтаксисом какого-нибудь окамла. Я уж не говорю о ужасах вроде C++. Разумеется, скобочники вообще синтаксическое богатство и экспрессивность на дух не переносят, но на то они и скобочники. Я вырос на перле, меня синтаксисом не напугаешь. И ООП, кстати, тоже, потому что я в своё время писал персистентную объектную модель а-ля Gemstone/S на перле. Подумаешь, скала.
А система типов сложная, да. Но, во-первых, никто не заставляет активно пользоваться всем, что в ней есть (в том виде, в которой ей пользуюсь я, она точно не сложнее хаскелевской). А во-вторых, никогда не знаешь, когда тебе пригодятся навороты. Вот скоро type providers доделают, а они мне очень нужны. И dependent object types тоже.
>Если в задаче требуется ручное управление памятью (что на данный момент имеет смысл только в embedded-приложениях и массивно-параллельных задачах а-ля CUDA), то лучше взять что-нибудь другое.
Не ручное управление памятью, а оптимизация её использования. Я привёл пример с IntMap. Оперативной памяти всегда не хватает, во всех приложениях.
>Mutually recursive обычно слабо. Но там, где нужно mutually recursive, лучше подумать и сделать как-нибудь ещё. Кроме чисто математических генераторов последовательностей, ни разу взаимная рекурсия мне не пригождалась.
Взаимная рекурсия позволяет безопасно использовать несводимые циклы (irreducible loops). Они становятся столь же приятными, как и обычные структурные циклы. Таким образом, помимо лишения себя выразительной возможности, вы ещё и заставляете себя напрягаться.
Вот пример, где это может пригодиться, и не являющийся генератором последовательностей:
-- |Parse something zero or more times.
pMany p = pMany1 p !++ return []
pMany1 p = do
x <- p
xs <- pMany p
return $ x:xs
Как я и говорил, во взглядах на объективную действительность мы совпадаем, а во вкусах, предпочтениях и оценках расходимся. Так что спора не получается. :)
Свои тезисы относительно Scala и соображения в их поддержку я уже высказал, при этом так и написал, что ты со мной едва ли согласишься. ;) Ты высказал свой взгляд и свои аргументы, так что у singalen теперь есть более объёмная картина Scala и окрестностей. Спасибо что откликнулся и привнёс свою перспективу! :)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это Clojure (для скобочников) и Scala (для любителей типизации).
no subject
no subject
no subject
no subject
Во-первых, Clojure - при том, что он мне нравится и я на нём пишу - не передний край ФП, а скорее bottom line. Почти как сама Java для ООП в своё время.
Во-вторых, особенности JVM объективно мешают реализовывать на ней ФП языки.
В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
Но это уже пошла вкусовщина и личные оценки, а в видении объективной картины мы, как мне кажется, совпадаем.
no subject
Я много раз это слышал, но пока что @tailrec работало у меня где надо.
> В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
А что же тогда удачное сочетание? Это уж точно передний край, переднее только Agda2, Epigram2 и какие-нибудь CPL.
no subject
Дело не в переднести края - переднесть сама по себе ни для чего не нужна. Относительно удачно Java и ФП сочетает Clojure - за счёт динамики и преимущественного отрицания ООП (оно там прикручено сбоку для совместимости, а писать в ООП стиле на Clojure - извращение). В Scala получился слишком навороченный синтаксис и слишком сложная система типов - на мой взгляд. И то, и другое естественное следствие концепции Scala, но от этого удобнее программировать не становится.
no subject
Mutually recursive обычно слабо. Но там, где нужно mutually recursive, лучше подумать и сделать как-нибудь ещё. Кроме чисто математических генераторов последовательностей, ни разу взаимная рекурсия мне не пригождалась.
«Слишком навороченный синтаксис» при рассмотрении становится достаточно регулярным. Я бы сказал, он примерно на уровне самой джавы. Сложнее хаскеловского, конечно, но вполне сравним с синтаксисом какого-нибудь окамла. Я уж не говорю о ужасах вроде C++. Разумеется, скобочники вообще синтаксическое богатство и экспрессивность на дух не переносят, но на то они и скобочники. Я вырос на перле, меня синтаксисом не напугаешь. И ООП, кстати, тоже, потому что я в своё время писал персистентную объектную модель а-ля Gemstone/S на перле. Подумаешь, скала.
А система типов сложная, да. Но, во-первых, никто не заставляет активно пользоваться всем, что в ней есть (в том виде, в которой ей пользуюсь я, она точно не сложнее хаскелевской). А во-вторых, никогда не знаешь, когда тебе пригодятся навороты. Вот скоро type providers доделают, а они мне очень нужны. И dependent object types тоже.
no subject
Не ручное управление памятью, а оптимизация её использования. Я привёл пример с IntMap. Оперативной памяти всегда не хватает, во всех приложениях.
>Mutually recursive обычно слабо. Но там, где нужно mutually recursive, лучше подумать и сделать как-нибудь ещё. Кроме чисто математических генераторов последовательностей, ни разу взаимная рекурсия мне не пригождалась.
Взаимная рекурсия позволяет безопасно использовать несводимые циклы (irreducible loops). Они становятся столь же приятными, как и обычные структурные циклы. Таким образом, помимо лишения себя выразительной возможности, вы ещё и заставляете себя напрягаться.
Вот пример, где это может пригодиться, и не являющийся генератором последовательностей:
-- |Parse something zero or more times. pMany p = pMany1 p !++ return [] pMany1 p = do x <- p xs <- pMany p return $ x:xsno subject
Свои тезисы относительно Scala и соображения в их поддержку я уже высказал, при этом так и написал, что ты со мной едва ли согласишься. ;) Ты высказал свой взгляд и свои аргументы, так что у
no subject
Жаль, что совершенства в мире нет.