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. Да и Хаскелю тоже.
Я так понимаю, эмулятор железки - вещь в себе, и имеет интерфейсы шириной с игольное ушко. Хуже, когда нужно общаться с десятью системами, передавать данные туда-сюда и поддерживать их целостность не только по своим правилам, но и по правилам оных систем. И невалидные данные ни в коем случае нельзя отбросить, о них обязательно надо просигналить. Тогда вся логика программы, и правда, прямо или опосредованно, состоит из оного взаимодействия... для программиста это, может, и "не лучший вариант", но это essential complexity.
Я привёл конкретный пример. Приведите, пожалуйста, конкретный пример общения с десятью системами.
Мой опыт говорит, что очень часто можно сделать формальную модель взаимодействия. Более того, Хаскель для этого не нужен.
Среди всего прочего, я участвовал в разработке ПО для банкоматов на Tcl. Так в этой разработке каждый участник проекта сочинил как минимум один встроенный проблемно-ориентированный язык.
Одним из них был язык описания сообщений между Центром и банкоматом. На тикле к нему был собран визуальный конструктор сообщений и протоколов. Ответственный за эту часть товарищ модифицировал и проверял функциональность Центра настолько быстро, выдавая конкретные проблемы в реализации протокола Центром, что наши коллеги из Центра попросили его конструктор и использовали для своих внутренних целей.
Может быть, я просто не понял, что значит "взаимодействие со внешним миром протягивается через всю программу". Но вот пример: Медицинский лабораторный центр, который обрабатывает анализы.
Одни и те же пробирки обрабатываются в химических, микробиологических, радиологических, генетических лабораториях, каждой из оных несколько видов и в каждой несколько систем автоматизации. Данные о пробирках (и пациентах) поступают по нескольким шинам и ещё, бывает, вводятся вручную.
Интерфейсы, конечно, стандартизированы, но каждой системе нужно своё подмножество полей. То, что валидно в одном поддомене или реализации, не обязательно валидно в других. Есть ещё и правила преобразования из одной в другую. Для этого, кстати, есть свой DSL.
А потом идут в собственно больницу, где с ними может произойти ещё черт-те-что - например, их могут вернуть на повторное обследование. Или исправить демографические данные пациента, из-за чего результат анализа превратится из нормального в абнормальный (для распознавания результатов тоже есть DSL).
Но это всё бэк-энд, который и правда хорошо формализуется. А потом у лабораторной системы появляется фронт-энд, GUI, который должен всем этим правилам соответствовать. Структура GUI совершенно нетривиальна, как и модель данных, только хуже, потому что человеческий фактор. И пожалуйста, нужно врезаться в любой момент воркфлоу (время дорого! Пациент может коньки отбросить!) и поправить руками произвольный элемент данных.
Дошло, наконец - речь о языке-glue для коммуникации между компонентами, а не о коммуникации между предметными областями. Тут и правда мне в голову не приходит хорошего примера, где Ява была бы хорошим glue. Разве что вот Grails, но там работает многопарадигменный гибрид - Groovy.
![[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)
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)
10/7/12 20:14 (UTC)Хуже, когда нужно общаться с десятью системами, передавать данные туда-сюда и поддерживать их целостность не только по своим правилам, но и по правилам оных систем. И невалидные данные ни в коем случае нельзя отбросить, о них обязательно надо просигналить.
Тогда вся логика программы, и правда, прямо или опосредованно, состоит из оного взаимодействия... для программиста это, может, и "не лучший вариант", но это essential complexity.
(no subject)
10/7/12 20:44 (UTC)Мой опыт говорит, что очень часто можно сделать формальную модель взаимодействия. Более того, Хаскель для этого не нужен.
Среди всего прочего, я участвовал в разработке ПО для банкоматов на Tcl. Так в этой разработке каждый участник проекта сочинил как минимум один встроенный проблемно-ориентированный язык.
Одним из них был язык описания сообщений между Центром и банкоматом. На тикле к нему был собран визуальный конструктор сообщений и протоколов. Ответственный за эту часть товарищ модифицировал и проверял функциональность Центра настолько быстро, выдавая конкретные проблемы в реализации протокола Центром, что наши коллеги из Центра попросили его конструктор и использовали для своих внутренних целей.
Это хороший пример формализации подхода.
(no subject)
10/7/12 21:16 (UTC)Одни и те же пробирки обрабатываются в химических, микробиологических, радиологических, генетических лабораториях, каждой из оных несколько видов и в каждой несколько систем автоматизации.
Данные о пробирках (и пациентах) поступают по нескольким шинам и ещё, бывает, вводятся вручную.
Интерфейсы, конечно, стандартизированы, но каждой системе нужно своё подмножество полей. То, что валидно в одном поддомене или реализации, не обязательно валидно в других. Есть ещё и правила преобразования из одной в другую. Для этого, кстати, есть свой DSL.
А потом идут в собственно больницу, где с ними может произойти ещё черт-те-что - например, их могут вернуть на повторное обследование. Или исправить демографические данные пациента, из-за чего результат анализа превратится из нормального в абнормальный (для распознавания результатов тоже есть DSL).
Но это всё бэк-энд, который и правда хорошо формализуется.
А потом у лабораторной системы появляется фронт-энд, GUI, который должен всем этим правилам соответствовать.
Структура GUI совершенно нетривиальна, как и модель данных, только хуже, потому что человеческий фактор. И пожалуйста, нужно врезаться в любой момент воркфлоу (время дорого! Пациент может коньки отбросить!) и поправить руками произвольный элемент данных.
(no subject)
10/7/12 21:22 (UTC)Проблемное место всего одно - GUI. При этом оно настолько проблемно, что я не смог бы рекомендовать Джава даже в клиники, где лечатся мои враги.
(no subject)
11/7/12 20:18 (UTC)(no subject)
11/7/12 21:34 (UTC)(no subject)
10/7/12 13:46 (UTC)http://singalen.livejournal.com/249003.html?thread=1682603#t1682603
Надеюсь, вы с ним ознакомились и мне бы хотелось услышать ваш ответ.