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}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
8/7/12 17:11 (UTC)(no subject)
9/7/12 07:36 (UTC)Batteries included я никому не обещал, правда же? :)
GUI всё ещё слабое место ФП, поскольку не найдено подходящего формализма, впрочем Fudgets в чём-то прекрасны, хотя и не юзабельны.
А какая нужна работа с сетью не через сырые сокеты?
(no subject)
9/7/12 07:39 (UTC)HTTP, REST/SOAP, SMTP со всеми прилежащими multipart-ами - для начала.
(no subject)
9/7/12 08:17 (UTC)Ну и там как минимум 3 годных веб-фреймворка...
Но я сильно в Hackage не закапывался.
(no subject)
9/7/12 09:44 (UTC)HTTP и SMTP нужны, увы.
(no subject)
9/7/12 10:03 (UTC)Коннектиться к легаси бывает нужно. Хотя этот процесс никогда не бывает прекрасен.
(no subject)
9/7/12 09:41 (UTC)Например, в скале есть собственный фреймворк для гуёв, а можно и джавские использовать. Есть много средств для продуктивной работы с базами данных, с вебом, с сетью. Например, где в хаскеле аналог Netty и MINA? Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений? Ничего нет, только сырые сокеты. А как красиво можно было бы сделать... Но никто не сделал.
В скале, если чего-то нет (например, хороших средств для работы с датами), можно взять джавовские, и всё будет работать прекрасно. А тут — либо есть, либо нет. Самому всё не напишешь.
(no subject)
9/7/12 10:53 (UTC)Прошу прощения, но это натурально не имеет смысла в случае 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)
10/7/12 13:57 (UTC)Что значит «какой размер будет у значения» — в смысле, в памяти? Вполне возможно, он будет астрономическим по сравнению с эффективной реализацией на C или на Haskell. Внутри JVM память устроена несколько специфически.
И — да, я вижу отличную функциональную структуру данных, который в хаскеле действительно больше, чем в скале. Это хорошо. Но это — весьма низкоуровневая библиотека, каковых энтузиасты немало понаписали и в скале. Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
Что касается того, как на хаскеле писать socket-код, то нужно посмотреть и попробовать. То, что я видел в real world haskell, напоминает IO-монаду, привинченную к юниксовому socket API. Может быть, этого достаточно. Было бы интересно сделать бенчмарк.
(no subject)
10/7/12 14:10 (UTC)Это высокоуровневая библиотека, позволяющая делать весьма производительные структуры данных.
Кстати, не затруднит ли вас привести аналог сей библиотеки для Скалы?
>Я говорил скорее о библиотеках, позволяющих общаться с внешним миром и делать высокоуровневую работу.
По-моему, весь "высокий уровень" всегда находится в ядре программы, в алгоритмах. А это означает, что чем проще написание библиотек, тем лучше. В частности, если можно спуститься на совершенно низкий уровень, как в примере с IntMap, то это лучше, чем если спуститься нельзя. Меньше необходимости в пересмотре подходов, алгоритмов и наборов языков.
>(должна же быть какая-то польза от ленивости by default).
Вот сейчас используем для моделирования аппаратуры.
(no subject)
10/7/12 14:24 (UTC)«Высокий уровень» это не только алгоритмы, но и коммуникации с внешним миром и кодом, написанным другими программистами. Помните шутку про Nonfunctional programming (http://mirror.uncyc.org/wiki/Nonfunctional_programming)? На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
(no subject)
10/7/12 17:01 (UTC)Там нет аналога adjust, update и alter, например. Зато в списке поддерживаемых функций есть композиция функций.
>Давайте забенчмарким по скорости, для разнообразия.
Давайте. Вариант http://Graph500.org с представлением на IntMap/IntSet устроит? Однопоточный вариант. На графах размера scale=16, edgeFactor=16. Это миллион ненаправленных дуг.
(no subject)
10/7/12 17:10 (UTC)Коммуникации - это границы. Для объектов размерности больше 1 они много меньше самих объектов.
Вот мой пример. На прошлой работе транслятор VHDL был написан на Java, при этом среда на C# и симулятор на Хаскеле. Взаимодействие со средой и симулятором - порядка 500 строк. Транслятор - порядка 50000 строк.
Я подозреваю, что вы просто привыкли к тому, что взаимодействие с внешним миром протягивается через всю программу, как это часто случается в Java (я попрограммировал на ней, имею некое представление). Может быть, это норма в мире Java, но это не лучший вариант.
>На этом уровне джаве нет равных, она — универсальный интегратор, как раньше был Perl.
На этом уровне нет равных также C, C++, C#, Tcl, Perl, Python. Да и Хаскелю тоже.
(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
10/7/12 13:46 (UTC)http://singalen.livejournal.com/249003.html?thread=1682603#t1682603
Надеюсь, вы с ним ознакомились и мне бы хотелось услышать ваш ответ.
(no subject)
9/7/12 07:44 (UTC)Но ничего прекрасного я в Java и окрестностях не вижу. В этом нет ничего плохого, это не мешает get things done.
(no subject)
9/7/12 09:42 (UTC)И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это Clojure (для скобочников) и Scala (для любителей типизации).
(no subject)
9/7/12 10:55 (UTC)(no subject)
9/7/12 10:58 (UTC)(no subject)
9/7/12 19:27 (UTC)(no subject)
11/7/12 06:42 (UTC)Во-первых, Clojure - при том, что он мне нравится и я на нём пишу - не передний край ФП, а скорее bottom line. Почти как сама Java для ООП в своё время.
Во-вторых, особенности JVM объективно мешают реализовывать на ней ФП языки.
В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
Но это уже пошла вкусовщина и личные оценки, а в видении объективной картины мы, как мне кажется, совпадаем.
(no subject)
11/7/12 06:52 (UTC)Я много раз это слышал, но пока что @tailrec работало у меня где надо.
> В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
А что же тогда удачное сочетание? Это уж точно передний край, переднее только Agda2, Epigram2 и какие-нибудь CPL.
(no subject)
11/7/12 07:12 (UTC)Дело не в переднести края - переднесть сама по себе ни для чего не нужна. Относительно удачно Java и ФП сочетает Clojure - за счёт динамики и преимущественного отрицания ООП (оно там прикручено сбоку для совместимости, а писать в ООП стиле на Clojure - извращение). В Scala получился слишком навороченный синтаксис и слишком сложная система типов - на мой взгляд. И то, и другое естественное следствие концепции Scala, но от этого удобнее программировать не становится.
(no subject)
11/7/12 07:24 (UTC)Mutually recursive обычно слабо. Но там, где нужно mutually recursive, лучше подумать и сделать как-нибудь ещё. Кроме чисто математических генераторов последовательностей, ни разу взаимная рекурсия мне не пригождалась.
«Слишком навороченный синтаксис» при рассмотрении становится достаточно регулярным. Я бы сказал, он примерно на уровне самой джавы. Сложнее хаскеловского, конечно, но вполне сравним с синтаксисом какого-нибудь окамла. Я уж не говорю о ужасах вроде C++. Разумеется, скобочники вообще синтаксическое богатство и экспрессивность на дух не переносят, но на то они и скобочники. Я вырос на перле, меня синтаксисом не напугаешь. И ООП, кстати, тоже, потому что я в своё время писал персистентную объектную модель а-ля Gemstone/S на перле. Подумаешь, скала.
А система типов сложная, да. Но, во-первых, никто не заставляет активно пользоваться всем, что в ней есть (в том виде, в которой ей пользуюсь я, она точно не сложнее хаскелевской). А во-вторых, никогда не знаешь, когда тебе пригодятся навороты. Вот скоро type providers доделают, а они мне очень нужны. И dependent object types тоже.
(no subject)
11/7/12 10:26 (UTC)Не ручное управление памятью, а оптимизация её использования. Я привёл пример с 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(no subject)
12/7/12 14:30 (UTC)Свои тезисы относительно Scala и соображения в их поддержку я уже высказал, при этом так и написал, что ты со мной едва ли согласишься. ;) Ты высказал свой взгляд и свои аргументы, так что у
(no subject)
Posted by