Моего уровня тяжёлой атлетики не хватает, чтобы понять эту сигнатуру. Хотя я понимаю, что там ну максимум 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}
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
Хуже, когда нужно общаться с десятью системами, передавать данные туда-сюда и поддерживать их целостность не только по своим правилам, но и по правилам оных систем. И невалидные данные ни в коем случае нельзя отбросить, о них обязательно надо просигналить.
Тогда вся логика программы, и правда, прямо или опосредованно, состоит из оного взаимодействия... для программиста это, может, и "не лучший вариант", но это essential complexity.
no subject
Мой опыт говорит, что очень часто можно сделать формальную модель взаимодействия. Более того, Хаскель для этого не нужен.
Среди всего прочего, я участвовал в разработке ПО для банкоматов на Tcl. Так в этой разработке каждый участник проекта сочинил как минимум один встроенный проблемно-ориентированный язык.
Одним из них был язык описания сообщений между Центром и банкоматом. На тикле к нему был собран визуальный конструктор сообщений и протоколов. Ответственный за эту часть товарищ модифицировал и проверял функциональность Центра настолько быстро, выдавая конкретные проблемы в реализации протокола Центром, что наши коллеги из Центра попросили его конструктор и использовали для своих внутренних целей.
Это хороший пример формализации подхода.
no subject
Одни и те же пробирки обрабатываются в химических, микробиологических, радиологических, генетических лабораториях, каждой из оных несколько видов и в каждой несколько систем автоматизации.
Данные о пробирках (и пациентах) поступают по нескольким шинам и ещё, бывает, вводятся вручную.
Интерфейсы, конечно, стандартизированы, но каждой системе нужно своё подмножество полей. То, что валидно в одном поддомене или реализации, не обязательно валидно в других. Есть ещё и правила преобразования из одной в другую. Для этого, кстати, есть свой DSL.
А потом идут в собственно больницу, где с ними может произойти ещё черт-те-что - например, их могут вернуть на повторное обследование. Или исправить демографические данные пациента, из-за чего результат анализа превратится из нормального в абнормальный (для распознавания результатов тоже есть DSL).
Но это всё бэк-энд, который и правда хорошо формализуется.
А потом у лабораторной системы появляется фронт-энд, GUI, который должен всем этим правилам соответствовать.
Структура GUI совершенно нетривиальна, как и модель данных, только хуже, потому что человеческий фактор. И пожалуйста, нужно врезаться в любой момент воркфлоу (время дорого! Пациент может коньки отбросить!) и поправить руками произвольный элемент данных.
no subject
Проблемное место всего одно - GUI. При этом оно настолько проблемно, что я не смог бы рекомендовать Джава даже в клиники, где лечатся мои враги.
no subject
no subject