![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Scala
Читаю книжку Одерского, до основной шизы еще не добрался, но такое ощущение, что в скале чрезмерно много синтаксического сахара. Типа "тут вы можете скобки опустить, а тут вместо скобок использовать фигурные скобки, а тут мы прямо в параметрах класса сделаем их полями, а в multiline string literal вы можете сделать отступ и stripMargin" и прочая и прочая в том же духе.
Основное из этого, видимо - function literals и вызов методов в стиле a methodName b, без точек и скобок, что делает код более лаконичным, одновременно позволяя при желании превратить код в нечитабельный ад.
Заодно по наводке![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
jdevelop глянул на http://spray.io/ https://github.com/spray/spray/wiki
Примеры там, конечно, знатный abuse возможностей языка и вычислений на типах, типа extraction-директив с HList в качестве параметра типа.
Clojure по сравнению с этим выглядит более простой и логичной, хотя я не уверен, можно ли сравнивать совершенно разные языки, общего у которых только функциональщина и иммутабельность иногда.
PS: Вот, к примеру:
https://github.com/spray/spray/blob/master/docs/documentation/spray-routing/code/docs/HttpServiceExamplesSpec.scala
В SimpleService HttpResponse реализован как html-код написанный прямо внутри скала-кода.Сижу уже 30 минут ищу, где это преобразование реализовано и как. Т.е. не видя отдельных литералов и их типов (которые без загрузки всего оного кода с зависимостями в IDE/интерпретатор еще и не увидишь), с ходу догадаться, что происходит, достаточно сложно. XML literals, встроенные в язык и где-то implicit для конверсии.
PPS: implicit evidence:
http://jim-mcbeath.blogspot.com/2008/11/scala-type-infix-operators.html
http://stackoverflow.com/questions/3427345/what-do-and-mean-in-scala-2-8-and-where-are-they-documented
По-моему, это уже достаточно сложно, чтобы увлечь психов и стать новыми крестиками. Вотxeno_by еще приделает макросы - и совсем хорошо станет.
Основное из этого, видимо - function literals и вызов методов в стиле a methodName b, без точек и скобок, что делает код более лаконичным, одновременно позволяя при желании превратить код в нечитабельный ад.
Заодно по наводке
jdevelop глянул на http://spray.io/ https://github.com/spray/spray/wiki Примеры там, конечно, знатный abuse возможностей языка и вычислений на типах, типа extraction-директив с HList в качестве параметра типа.
Clojure по сравнению с этим выглядит более простой и логичной, хотя я не уверен, можно ли сравнивать совершенно разные языки, общего у которых только функциональщина и иммутабельность иногда.
PS: Вот, к примеру:
https://github.com/spray/spray/blob/master/docs/documentation/spray-routing/code/docs/HttpServiceExamplesSpec.scala
В SimpleService HttpResponse реализован как html-код написанный прямо внутри скала-кода.
PPS: implicit evidence:
http://jim-mcbeath.blogspot.com/2008/11/scala-type-infix-operators.html
http://stackoverflow.com/questions/3427345/what-do-and-mean-in-scala-2-8-and-where-are-they-documented
По-моему, это уже достаточно сложно, чтобы увлечь психов и стать новыми крестиками. Вот
xeno_by еще приделает макросы - и совсем хорошо станет.
no subject
Что-то такое, но я подразумевал только systems-design/architecture-часть, безотносительно менеджмента.
@ Могут ли модули быть заменены записями?
Иногда могут, иногда нет - в зависимости от того, о каких модулях и каких записях речь.
На фундаментальном уровне все эти концепции крутятся вокруг типов-произведений, экзистенциальных типов, и сабтайпинга.
Для первого приближения я себе выработал такие соответствия:
непараметризуемые модули - это приблизительно то же самое (~), что и неймспейсы;
параметризуемые модули ~ записи, умеющие содержать те же виды деклараций, что и нечто, соответствующее обычным модулям в данном языке (где сами эти записи декларируются, например);
параметризуемые модули с сабтайпингом ~ классы в ООП.
Такие аналогии классов и записей с модулями лучше чувствуются в языках, где можно импортировать начинку экземпляров записей (Agda, Cayenne) и классов (Scala) в текущий скоуп.
no subject
А. Разбиение на компоненты и архитектура.
Архитектура (на высоком уровне) не зависит от языка программирования. Название и назначение блоков без их детализации не меняются при смене ЯП.
Организация взаимодействия между компонентами от языка зависит и здесь Хаскель выигрывает. Ибо подключение компонент к архитектуре является (!) programming in the small. Это просто очередная библиотека.
>Записи
Добавьте к записи один параметр типа и одно поле, и получите всё, что угодно, вплоть до перегрузки и подтипизации.
no subject
Ну, я не про настолько высокий уровень, где не зависит, а про такой, на котором уже видна параметризация подсистем, их взаимодействия и т.д.
@ Организация взаимодействия между компонентами от языка зависит и здесь Хаскель выигрывает.
А мне кажется, существенно проигрывает, причём даже всяким Java. И проблема как-раз в том, что в хаскеле самый большой вещественный компонент - запись, но они неудобные, неоткрываемые, не могут содержать внутри объявления типов и т.д. А в java самый большой вещественный компонент - параметризуемый модуль (класс) с операцией обратно-совместимого расширения (наследование). Вот взаимодействие между маленькими компонентами - это (по-моему) самая сильная сторона хаскеля, для таких вещей в нём поддерживается огромное количество клея (от обычной функциональной композиции до стрелочной, от функций высшего порядка до категорных паттернов структурно-констекстуального взаимодействия). Но эти маленькие компоненты - это внутренности подсистем, а большие компоненты - сами подсистемы, и их взаимодействия, в хаскеле напрочь неовеществлены.
@ Добавьте к записи один параметр типа и одно поле
Можно и без записей обойтись - одними туплами. Вместо имён компонент - функции-селекторы.
Если не хочется структурного сабтайпинга - ньютайп-врапперы для номинативности.
no subject
Expression problem, идеализированная проблема расширения программы. Сравните решения на Хаскеле и других ЯП.
>Но эти маленькие компоненты - это внутренности подсистем, а большие компоненты - сами подсистемы, и их взаимодействия, в хаскеле напрочь неовеществлены.
Неправда ваша. От MRef/IORef до каналов и (теперь уже) до Cloud Haskell.
no subject
no subject
Вот несколько, есть и другие:
http://wadler.blogspot.com/2008/02/data-types-la-carte.html
http://www.cse.unsw.edu.au/~sseefried/talks/SAPLING_expression_problem.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.6075&rep=rep1&type=pdf
Все они вокруг трюков с тайпклассами и системой типов для реализации подобия открытых типов данных (кодирования типа Inl/Inr и т.д.) - того, что в ООП делается просто наследованием. Если честно, я их не очень осиливаю, а вот Вадлеровское оригинальное решение на обобщённой джаве с первого раза понял. Только оно мне не очень нравится. Вообще, проблема очень глубокая и многогранная.
Вот на скальных трейтах набросал что-то приблизительно охватывающее проблему на базовом уровне:
http://www.scalakata.com/509fd55ce4b093f3524f3da5
И я, кстати, не сразу понял почему ретроактивная расширяемость функциональности типа тайпклассов и имплицитов не подходит, а это очень важно. Вот здесь видно:
http://www.scalakata.com/509fdf76e4b093f3524f3daf