Моего уровня тяжёлой атлетики не хватает, чтобы понять эту сигнатуру. Хотя я понимаю, что там ну максимум 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)
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)