SOAP? Не надо вот этого вот. В крайнем случае SOAP-консьюмер, если некуда деваться, но если кто-то напишет SOAP-сервер на нормальном языке программирования, он будет неправ, потому что SOAP — это зло, и не надо его умножать.
Под «прекрасным» я понимаю в том числе и наличие приборов и материалов, позволяющих делать прекрасные вещи.
Например, в скале есть собственный фреймворк для гуёв, а можно и джавские использовать. Есть много средств для продуктивной работы с базами данных, с вебом, с сетью. Например, где в хаскеле аналог Netty и MINA? Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений? Ничего нет, только сырые сокеты. А как красиво можно было бы сделать... Но никто не сделал.
В скале, если чего-то нет (например, хороших средств для работы с датами), можно взять джавовские, и всё будет работать прекрасно. А тут — либо есть, либо нет. Самому всё не напишешь.
Я не знаю, что такое MINA, но я посмотрел, что такое Netty: "an asynchronous event-driven network application framework" (http://www.jboss.org/netty/)
Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить:
-- See Note: Order of constructors
data IntMap a = Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a)
| Tip {-# UNPACK #-} !Key a
| Nil
type Prefix = Int
type Mask = Int
type Key = Int
Какой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.
Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.
Моего уровня тяжёлой атлетики не хватает, чтобы понять эту сигнатуру. Хотя я понимаю, что там ну максимум 65 кило. Но видно, что там много низкоуровневых конструктов. И это для самого эффективного компилятора с наибольшим потенциалом для оптимизаций, коим безусловно является GHC (должна же быть какая-то польза от ленивости by default).
Что значит «какой размер будет у значения» — в смысле, в памяти? Вполне возможно, он будет астрономическим по сравнению с эффективной реализацией на C или на Haskell. Внутри JVM память устроена несколько специфически.
И — да, я вижу отличную функциональную структуру данных, который в хаскеле действительно больше, чем в скале. Это хорошо. Но это — весьма низкоуровневая библиотека, каковых энтузиасты немало понаписали и в скале. Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
Что касается того, как на хаскеле писать socket-код, то нужно посмотреть и попробовать. То, что я видел в real world haskell, напоминает IO-монаду, привинченную к юниксовому socket API. Может быть, этого достаточно. Было бы интересно сделать бенчмарк.
>Но это — весьма низкоуровневая библиотека, каковых энтузиасты немало понаписали и в скале.
Это высокоуровневая библиотека, позволяющая делать весьма производительные структуры данных.
Кстати, не затруднит ли вас привести аналог сей библиотеки для Скалы?
>Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
По-моему, весь "высокий уровень" всегда находится в ядре программы, в алгоритмах. А это означает, что чем проще написание библиотек, тем лучше. В частности, если можно спуститься на совершенно низкий уровень, как в примере с IntMap, то это лучше, чем если спуститься нельзя. Меньше необходимости в пересмотре подходов, алгоритмов и наборов языков.
>(должна же быть какая-то польза от ленивости by default).
Вот сейчас используем для моделирования аппаратуры.
«Высокоуровневая библиотека, позволяющая делать весьма производительные структуры данных» в скале называется Scala Collections, часть стандартной библиотеки. Там даже есть подобный IntMap: http://www.scala-lang.org/api/current/scala/collection/immutable/IntMap.html . Давайте забенчмарким по скорости, для разнообразия.
«Высокий уровень» это не только алгоритмы, но и коммуникации с внешним миром и кодом, написанным другими программистами. Помните шутку про Nonfunctional programming (http://mirror.uncyc.org/wiki/Nonfunctional_programming)? На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
>Там даже есть подобный IntMap: http://www.scala-lang.org/api/current/scala/collection/immutable/IntMap.html .
Там нет аналога adjust, update и alter, например. Зато в списке поддерживаемых функций есть композиция функций.
>Давайте забенчмарким по скорости, для разнообразия.
Давайте. Вариант http://Graph500.org с представлением на IntMap/IntSet устроит? Однопоточный вариант. На графах размера scale=16, edgeFactor=16. Это миллион ненаправленных дуг.
>«Высокий уровень» это не только алгоритмы, но и коммуникации с внешним миром и кодом, написанным другими программистами.
Коммуникации - это границы. Для объектов размерности больше 1 они много меньше самих объектов.
Вот мой пример. На прошлой работе транслятор VHDL был написан на Java, при этом среда на C# и симулятор на Хаскеле. Взаимодействие со средой и симулятором - порядка 500 строк. Транслятор - порядка 50000 строк.
Я подозреваю, что вы просто привыкли к тому, что взаимодействие с внешним миром протягивается через всю программу, как это часто случается в Java (я попрограммировал на ней, имею некое представление). Может быть, это норма в мире Java, но это не лучший вариант.
>На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
На этом уровне нет равных также C, C++, C#, Tcl, Perl, Python. Да и Хаскелю тоже.
Хочу пояснить: я не отрицаю сугубой юзабельности Java - напротив, очень уважаю её стабильность, качество и проработанность. С удовольствием пользуюсь в благоприятных случаях.
Но ничего прекрасного я в Java и окрестностях не вижу. В этом нет ничего плохого, это не мешает get things done.
В самой джаве как языке программирования я тоже ничего прекрасного не вижу. Но это прекрасная платформа.
И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это 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
no subject
Batteries included я никому не обещал, правда же? :)
GUI всё ещё слабое место ФП, поскольку не найдено подходящего формализма, впрочем Fudgets в чём-то прекрасны, хотя и не юзабельны.
А какая нужна работа с сетью не через сырые сокеты?
no subject
HTTP, REST/SOAP, SMTP со всеми прилежащими multipart-ами - для начала.
no subject
Ну и там как минимум 3 годных веб-фреймворка...
Но я сильно в Hackage не закапывался.
no subject
HTTP и SMTP нужны, увы.
no subject
Коннектиться к легаси бывает нужно. Хотя этот процесс никогда не бывает прекрасен.
no subject
Например, в скале есть собственный фреймворк для гуёв, а можно и джавские использовать. Есть много средств для продуктивной работы с базами данных, с вебом, с сетью. Например, где в хаскеле аналог Netty и MINA? Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений? Ничего нет, только сырые сокеты. А как красиво можно было бы сделать... Но никто не сделал.
В скале, если чего-то нет (например, хороших средств для работы с датами), можно взять джавовские, и всё будет работать прекрасно. А тут — либо есть, либо нет. Самому всё не напишешь.
no subject
Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
binary package: http://hackage.haskell.org/package/binary-0.5.0.1
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить:
-- See Note: Order of constructors data IntMap a = Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a) | Tip {-# UNPACK #-} !Key a | Nil type Prefix = Int type Mask = Int type Key = IntКакой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.
no subject
Что значит «какой размер будет у значения» — в смысле, в памяти? Вполне возможно, он будет астрономическим по сравнению с эффективной реализацией на C или на Haskell. Внутри JVM память устроена несколько специфически.
И — да, я вижу отличную функциональную структуру данных, который в хаскеле действительно больше, чем в скале. Это хорошо. Но это — весьма низкоуровневая библиотека, каковых энтузиасты немало понаписали и в скале. Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
Что касается того, как на хаскеле писать socket-код, то нужно посмотреть и попробовать. То, что я видел в real world haskell, напоминает IO-монаду, привинченную к юниксовому socket API. Может быть, этого достаточно. Было бы интересно сделать бенчмарк.
no subject
Это высокоуровневая библиотека, позволяющая делать весьма производительные структуры данных.
Кстати, не затруднит ли вас привести аналог сей библиотеки для Скалы?
>Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
По-моему, весь "высокий уровень" всегда находится в ядре программы, в алгоритмах. А это означает, что чем проще написание библиотек, тем лучше. В частности, если можно спуститься на совершенно низкий уровень, как в примере с IntMap, то это лучше, чем если спуститься нельзя. Меньше необходимости в пересмотре подходов, алгоритмов и наборов языков.
>(должна же быть какая-то польза от ленивости by default).
Вот сейчас используем для моделирования аппаратуры.
no subject
«Высокий уровень» это не только алгоритмы, но и коммуникации с внешним миром и кодом, написанным другими программистами. Помните шутку про Nonfunctional programming (http://mirror.uncyc.org/wiki/Nonfunctional_programming)? На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
no subject
Там нет аналога adjust, update и alter, например. Зато в списке поддерживаемых функций есть композиция функций.
>Давайте забенчмарким по скорости, для разнообразия.
Давайте. Вариант http://Graph500.org с представлением на IntMap/IntSet устроит? Однопоточный вариант. На графах размера scale=16, edgeFactor=16. Это миллион ненаправленных дуг.
no subject
Коммуникации - это границы. Для объектов размерности больше 1 они много меньше самих объектов.
Вот мой пример. На прошлой работе транслятор VHDL был написан на Java, при этом среда на C# и симулятор на Хаскеле. Взаимодействие со средой и симулятором - порядка 500 строк. Транслятор - порядка 50000 строк.
Я подозреваю, что вы просто привыкли к тому, что взаимодействие с внешним миром протягивается через всю программу, как это часто случается в Java (я попрограммировал на ней, имею некое представление). Может быть, это норма в мире Java, но это не лучший вариант.
>На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
На этом уровне нет равных также C, C++, C#, Tcl, Perl, Python. Да и Хаскелю тоже.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
http://singalen.livejournal.com/249003.html?thread=1682603#t1682603
Надеюсь, вы с ним ознакомились и мне бы хотелось услышать ваш ответ.
no subject
Но ничего прекрасного я в Java и окрестностях не вижу. В этом нет ничего плохого, это не мешает get things done.
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)