metaclass: (дзедline)
В книжке Programming in Scala есть 29 глава, "Modular programming using objects". Или вот на ту же тему: http://xeno-by.livejournal.com/75612.html
И вот еще пример: https://www.precog.com/blog-precog-2/entry/existential-types-ftw

Так вот, пока под руками нет задачи, требующей для решения именно этой модульности-на-объектах, понять в этом невозможно ничего. По отдельности слова и код понятны, вместе - ну хер поймешь, зачем это вообще надо и с какими целями так делается.
Это примерно, как описывать иммутабельность и ФВП человеку, который сам не дошел до них на практике, хотя бы в виде readonly/final полей-переменных и разных там паттернов, имитирующих ФВП.
metaclass: (дзедline)
Столкнулся с тем, что наиболее внятно задача, которую я решаю, укладывается в Clojure и не укладывается (без частичного выкидывания статической типизации) в скалы-хаскели-C#-F#.
Вернее даже не выкидывание, а просто получается имитация типичного для Clojure типа данных Map[Symbol,Any] и использование его во все поля.

Можно, конечно, было бы убрать вообще всю логику, вплоть до SQL-запросов, из БД и писать запросы для ORM типа slick, но это в данном случае натягивание совы на глобус, более чем бессмысленное, т.к. статически типизированный результат запроса в ORM нужно будет превратить обратно в нихрена не типизированнный датасет типа Seq[Map[Symbol,Any]] и сериализовать его в json для клиента.
Или прикрутить shapeless (https://github.com/milessabin/shapeless) и навернуть extensible records поверх HList на предмет того, чтобы типовыводилка генерила еще и метаданные, но в итоге получится что-то совсем печальное и малопонятное.
metaclass: (дзедline)
В целях недопущения упрощения жизни, а так же чтобы псить, при необходимости, со знанием дела, осиливаю скалу.
Причем начал практически с конца - клепаю RESTful сервис на основе spray с всякими json-маршалингами внутри через имплициты и прочую адову содомию.
При достаточном количестве type-level магии оно выглядит, конечно, так же просто, как какое-нибудь руби, или как лиспы без скобок и с инфиксной записью, но внутренняя сложность, по-моему, зашкаливает. "Импортируй себе немножечко имплиситов и получи на халяву сериализаторы в json для всего", "Оберни маршруты в директивы логгера" и прочее такое.

Сборку завел, сначала через sbt (простой способ), потом импортировал в IDEA (условно простой) и потом стырил у [livejournal.com profile] jdevelop конфигурацию для мавена (нормальный способ). Воедино надо это как-то свести, чтобы не редактировать при добавлении новых зависимостей все вручную. Плюс еще импорт sbt в IDEA выглядит как ад и смерть.

Завести то я это чюдо заведу, но вот что с ним дальше делать, не совсем понятно. На данный момент картина выглядит так: Clojure проще, но скобки и стектрейсы компилятора отпугнут новых пользователей, Scala дико сложнее, но поначалу она выглядит как "почти жаба", обработка ошибок более читабельна и есть шансы, что в эту западню попадутся и желающие новеньких языков и любители сойти с ума на почве вычислений на типах.
metaclass: (дзедline)
Разбираюсь потиху с Intellij IDEA и скалой. И, как обычно, утыкаюсь в "расхождения по земельному вопросу" с жабными инструментами. Сколько раз это все дело открывал - столько утыкался.

Вот у нас есть на данный момент что: jdk (много разных), мавен(две версии), sbt(аналог мавена для скалы), IDEA и тыщи плагинов под мавен, sbt и идею.
Я прочел документацию по мавену и sbt, но от входа все равно не понимаю, как принято создавать проекты с нуля и как принято их деплоить. Открываешь какой-нибудь пример, а там все заканчивается строкой вида sbt container:start, которая работает исключительно внутри запущенного sbt и с помощью плагина типа "com.github.siasia" %% "xsbt-web-plugin. Или мавен с jetty-плагином.

Предположительно, можно поставить jetty сервисом и деплоить туда приложение в виде war. Но сборка этого war и особенно копирование зависимостей для него для меня темный лес.
Я обычно начинаю с того, что запускаю jetty внутри своего приложения, передавая ему хендлер явно, т.к. таким образом для меня проще понять, что в каком порядке работает и откуда берется конфигурация. Но даже в этом случае количество вариаций на тему "запустить жабу с указанием classpath и main class" просто поражает.
Т.е. запуск из мавена, запуск из sbt, запуск из idea, деплоймент в контейнер и запуск из консоли руками и запуск в виде jar - это все совершенно между собой различающиеся варианты, с разными classpath, разными репозиториями и прочим таким.

Плюс еще несколько десятков версий на каждую зависимость, которые нужно внятно выбрать при добавлении. Слава богу, они хоть не конфликтовали у меня пока.
metaclass: (дзедline)
Читаю http://www.scala-sbt.org/
По виду - все ок, что-то аналогичное мавену-лейнингену-кабалу. Пошел смотреть, какие есть RESTful фреймворки и веб-сервера под скалу - набрел на Scalatra. Читаю, как ее установить - а вот тут уже началось буйство не совсем понятной фантазии:

Для начала надо поставить конскрипт: curl https://raw.github.com/n8han/conscript/master/setup.sh | sh
Т.е. "запусти неведомо что неведомо откуда". Причем я до сих пор не нашел внятного объяснения, что именно делает эта софтина. "This is a tool for installing and updating Scala software programs.". В принципе, проблемы разобраться во внутренностях особой нет, но это вебдванольное agile хипстерство с запуском скриптов из интернетов меня еще в rvm опечалило.

Потом с его помощью надо поставить giter8 ("Giter8 is a command line tool to generate files and directories from templates published on github or any other git repository."): cs n8han/giter8

Затем надо запустить этот самый гитер и скачать шаблон проекта: g8 scalatra/scalatra-sbt
Далее, как обычно - запускаем sbt и в нем собираем проект и запускаем контейнер.

Я не очень понимаю, зачем все это вуду с обходными путями и хипстерскими утилитами? По моему, выложить просто прототип проекта на гитхаб или вообще в виде архива и больше ничего не нужно, кроме жабы и sbt, для управления зависимостями.

PS: Гитлерхаб-вебдванольные хипстеры:

[info] Compiling 1 Scala source to F:\Scala\scalatra\scalatra-sbt.g8\project\project\target\scala-2.9.1\sbt-0.11.2\classes...
'git' is not recognized as an internal or external command,
operable program or batch file.
[error] Nonzero exit code (1): cmd /c git clone git://github.com/n8han/giter8 C:\Documents and Settings\user\.sbt\staging\c7021489c0636cd35788

Отправить бы их куда-нибудь работать, где интернет выдается под запись в журнал и под наблюдением службы безопасности.

PPS: Да у них еще и sbt свой личный в шаблоне проекта. Знатнейшая дичь.
metaclass: (дзедline)
В очередной раз, в связи с макросами подниму свой любимый вопрос:
Можно ли поиметь в языках типа скалы строгую типизацию, не объявляя типы записей заранее?

Идея в следующем: у меня в Clojure большая часть DSL основана на том, что я могу в любое место описания строк-колонок-ячеек отчета (условно говоря, Excel-like таблица фиксированной формы, заполняемая автоматом из проводок) в любой момент добавить атрибут типа :skip-in-vat true и обработать его. При этом мне нужно это изменить ровно в двух местах - описание документа ("данные") и расчетный алгоритм ("код"). Типов тут нет, а вместо них - структуры данных, скомбинированные из словарей, массивов и атомарных данных.

Но с динамически типизированными языками, а особенно с Clojure с ее destructring и прагматичным подходам к совместимости типов имеется постоянно проблема вида "сунул лишние скобки, на место числа попал массив и через 100500 вызовов когда дело дошло до суммирования, оператор + сдох от попытки просуммировать ссылку на массив со стек-трейсом на три страницы". Причем если мне такие ошибки чинить достаточно легко, то менее опытным коллегам это вырывает мозг.

В F# и прочих типизированных языках же мне придется сначала ползти в описание записи (если там записи вообще есть), добавлять поле или хуже того - еще один вариант для алгебраического типа, править вызовы конструкторов (если оверлоадинга нет) и прочая и прочая.

Кроме того, часто хочется такого: "тип записи создается в SQL запросе и далее используется в функции, обрабатывающей результат запроса". В clojure это опять же - словарь, с кейвордами в качестве ключей.

Языки же кроме F#, Scala и Clojure можно не рассматривать вообще - на них аналогичные задачи или сводятся к "наняли 100 ртишников по одному на объект предметной области и написали вручную" или к "написали самодельный лисп с хаскелем на дельфи/C#" или к "используем безумные ORM с еще более дикими, чем SQL языками и внешними декларативными описаниями".
Т.е. я не говорю, что они не пригодны - но затраты ресусов на решение задачи на таких языках заметно больше.
metaclass: (Default)
http://www.scala-lang.org/node/8610
"I distinguish between Scala application programmers and Scala library designers, because the required skill sets are really quite different."

Языки с таким свойством крайне огорчают. Потому что в случае бага в библиотеке можно оказаться в ситуации даже не "некому чинить", а в "никто не может понять - у нас баг или в используемой библиотеке, т.к. она нечитабельна".
metaclass: (Default)
Scala - это Haskell в жабьей шкуре?

Если кложура сразу видна как лисп и не совсем мейнстримный язык, то скала замаскирована жабьей шкуркой от зоркого ока менеджеров, чтобы к тому времени, как до них дойдет, во что они вляпались - было уже поздно.

Язык знатно безумный, я почти Programming in Scala дочитал. И кое-какие вещи там сильно похожи на решение некоторых проблем с наследованием и зависимостями типов друг от друга, которых мне не хватало в дельфи и дотнетах :)

Scala

Nov. 6th, 2012 04:15 am
metaclass: (Default)
Читаю книжку Одерского, до основной шизы еще не добрался, но такое ощущение, что в скале чрезмерно много синтаксического сахара. Типа "тут вы можете скобки опустить, а тут вместо скобок использовать фигурные скобки, а тут мы прямо в параметрах класса сделаем их полями, а в multiline string literal вы можете сделать отступ и stripMargin" и прочая и прочая в том же духе.
Основное из этого, видимо - function literals и вызов методов в стиле a methodName b, без точек и скобок, что делает код более лаконичным, одновременно позволяя при желании превратить код в нечитабельный ад.

Заодно по наводке [livejournal.com profile] 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

По-моему, это уже достаточно сложно, чтобы увлечь психов и стать новыми крестиками. Вот [livejournal.com profile] xeno_by еще приделает макросы - и совсем хорошо станет.
metaclass: (Default)
Вспомнил один срач на тему однопроходных компиляторов, где Steve Yegge критиковал Clojure за то, что в ней объявления видны не во всем модуле, а только ниже объявления. (Ну, за исключением declare которые что-то вроде forward-объявлений).
Сижу приделываю новую фичу к кодогенератору на F# - и таки внезапно оказывается, что это не только в Clojure, но так же и F#, и, что самое печальное, - в долбаном SQL, который я генерирую.
Сижу вот, сортирую объекты из которых генерируется SQL по зависимостям.

А как с этим дела обстоят в Scala?
Я тут подумываю, что надо бы провести сравнение F# и Scala на моих задачах, все равно уже полная работа JVM и жаб, так может, выводилка типов в Scala для меня окажется более приемлемой, чем дикий ад в F# (теперь я понимаю, почему его [livejournal.com profile] thesz критикует). Ну и макросы в скале [livejournal.com profile] xeno_by прикрутил вроде уже.
Хотя единственное, что мне приходит в голову на тему приличного использования макросов - это при их выполнении долбится в БД или модель этой БД и генерировать код.
metaclass: (Default)
http://lex-kravetski.livejournal.com/424713.html
Все сомнения о том, что какие-то штуки не будут работать, всё развалится в самый последний момент, возникнут непредвиденные сложности с языком, будет чего-то важного не хватать и так далее, они логичны и обоснованы, однако эксперимент показал, в случае со Scala такого не происходит. За полгода разработки я не встретил ни одной непреодолимой сложности, всё работало, из Java вызывалось и так далее.

Реальный выигрыш будет в основном для тех, кто уже сейчас пишет по сути на Scala, только под Явой. То есть использует похожие концепции для выражения своих мыслей и понимает эти концепции. Тот, кто в некотором смысле сам для себя их «изобрёл». В этом случае он получает инструмент, при помощи которого пользоваться ими на порядок проще, и начинает переться. Те же, кто копипастил, не видят перемен к лучшему — какая разница, где копипастить? Они видят только, что синтаксис другой, а их коллеги повсеместно используют какую-то долбанную магию вуду.

Все то же самое, дословно, можно сказать про Clojure или F#.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 24th, 2017 05:30 pm
Powered by Dreamwidth Studios