Здравствуйте, dimgel, Вы писали:
D>Я склонен полагать, что выигрыш будет огромным и там, и там. Либо в банальном количестве букв, либо в плане кодирования логики фреймворков в систему типов, что даёт недостижимую в жаве защиту от ошибок неправильного использования фреймворка прикладным программистом. И кстати, насчёт DSL — я бы побоялся бога называть минимальным выигрышем тот же squeryl (LINQ-like DSL for Scala). Не говоря уже о тех же Combinator Parsers, код использования которых выглядит ровно как BNF, не требует никаких препроцессоров, жёстко контролируется типизатором и имеет при этом вполне достойную производительность.
Я немного о другом — как правило когда пишется какой-то общий код — в разумных пределах не очень важно сколько конкретно времени он пишется. Вот даже взять парсер, с ANTLR то же самое было бы написано ну пусть за вдвое больший срок (на самом деле я так не думаю, но гипотетически предположим) — и пофиг, эта неделя размажется на годы использования. Я хочу сказать — польза есть и если есть возможность — можно пользоваться, но качественного изменения картины от этого не получить.
А squeryl — редкостная гадость, за пределами "hello world" — прыжок на месте — попытка улететь. Замах интересный, но реализация — бяка.
Здравствуйте, doarn, Вы писали:
D>Я немного о другом — как правило когда пишется какой-то общий код — в разумных пределах не очень важно сколько конкретно времени он пишется. Вот даже взять парсер, с ANTLR то же самое было бы написано ну пусть за вдвое больший срок (на самом деле я так не думаю, но гипотетически предположим) — и пофиг, эта неделя размажется на годы использования. Я хочу сказать — польза есть и если есть возможность — можно пользоваться, но качественного изменения картины от этого не получить.
Не согласен, но спорить лениво — это будет очередной срач на тему статика/динамика.
D>А squeryl — редкостная гадость, за пределами "hello world" — прыжок на месте — попытка улететь. Замах интересный, но реализация — бяка.
Одерски летом 2011 говорил, что в их планах собственное LINQ-like двигло к языку прикрутить. Т.е. squeryl и прочие пойдут после этого лесом. Лично для меня у squeryl два существенных недостатка:
1. В лучших традициях scala DSL он интенсивно юзает implicits, в результате IDE ацки тормозит и глючит. Да и компилятор тоже.
2. Для динамической генерации запросов приходится такие дикие пляски устраивать...
В общем, затея ScalaQL с плагином была концептуально вернее: возможность прикручивания трансформации/оптимизации запросов, в частности. Но то был чисто proof of concept, развивать его оказалось никому неинтересно. Посмотрим, чего Одерски родит.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, insighter, Вы писали:
C>>>Нет статической типизации -> в морг. I>>вот и сделали статическую компиляцию в груви: http://docs.codehaus.org/display/GROOVY/2012/05/07/Static+compilation+in+the+new+Groovy+2.0+beta I>>это должно прибавить ему очков в противостоянии со скалой ) C>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы.
А можно поподробнее, на тему собственного опыта? Прочитал ихнее "comparison to scala", но окромя толковой null safety ничем особо не впечатлился.
Здравствуйте, dimgel, Вы писали:
C>>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы. D>А можно поподробнее, на тему собственного опыта? Прочитал ихнее "comparison to scala", но окромя толковой null safety ничем особо не впечатлился.
Я пишу на нём планировщик. Пока нравится.
Из плюсов:
0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов.
1) Сильные generic'и. Nuff said.
2) Интересная система ко/контравариантности — проще, чем в Скале.
3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих.
4) Нелокальный выход — так что цикл for в Kotlin работает так же быстро, как и while, поддерживая нормальный break/continue.
5) Скорость компиляции.
6) Поддержка IDE.
Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано.
Здравствуйте, Cyberax, Вы писали:
C>3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих.
А это точно плюс? Жавовские контейнеры рядом со скаловыми — это ссаные ясли. Без map/filter/fold жить было бы тошно. И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж).
C>5) Скорость компиляции.
Гы, про слона-то я и запамятовал.
C>Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано.
Я только что читал вот это обсуждение. Понятно, что всяк кулик своё болото хвалит. Но мне понравился пойнт одного чувака на тему простоты: говорит, пишет парсеры регулярно, и только со скаловским DSL ему стало хорошо; а возможны ли такие средства на простых языках? Хотя среди перечисленных тобой плюсов простота вроде не фигурировала.
Здравствуйте, dimgel, Вы писали:
C>>3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих. D>А это точно плюс? Жавовские контейнеры рядом со скаловыми — это ссаные ясли. Без map/filter/fold жить было бы тошно.
map/filter/fold уже добавлены с помощью методов-расширений.
D>И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж).
И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода.
C>>Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано. D>Я только что читал вот это обсуждение. Понятно, что всяк кулик своё болото хвалит. Но мне понравился пойнт одного чувака на тему простоты: говорит, пишет парсеры регулярно, и только со скаловским DSL ему стало хорошо; а возможны ли такие средства на простых языках? Хотя среди перечисленных тобой плюсов простота вроде не фигурировала.
Возможностей для DSL в Котлине достаточно. Причём мне лично парсеры что-то не приходится писать каждый день.
Здравствуйте, Cyberax, Вы писали:
D>>И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж). C>И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода.
Нуууу, если так рассуждать, то прогресс бы вообще на месте топтался бы. Java несовместима с тоннами legacy-кода на C++.
А с другой стороны, скала тоже чудненько интегрируется с жавовскими коллекциями. Даже есть имплиситы, перегоняющие одно в другое. А не хочешь перегонять — юзай java-классы из скалы. Не вижу проблемы.
C>Возможностей для DSL в Котлине достаточно.
Ок, возможно.
C>Причём мне лично парсеры что-то не приходится писать каждый день.
Ну это так себе аргумент. Кому-то не приходится делать ничего сложнее формоклёпства, ну и пусть он значит юзает дельфЮ. Пойнт в том, что чем проще язык, тем он сложнее для сложных задач. Т.е. простое сделать проще, а как только появляется человек со своей спецификой (парсеры, или что ещё) — он тут же огребает геморрой. Меня вот несколько вымораживает факт существования implicits. Но с другой стороны я понимаю, что без них не было бы ни scalatest, ни squeryl. Оно конечно я хз зачем этот "human-like syntax" в scalatest (мне с головой хватало влоб-тупого JUnit), но вот squeryl — это аргумент.
Здравствуйте, dimgel, Вы писали:
C>>И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода. D>Нуууу, если так рассуждать, то прогресс бы вообще на месте топтался бы. Java несовместима с тоннами legacy-кода на C++. D>А с другой стороны, скала тоже чудненько интегрируется с жавовскими коллекциями. Даже есть имплиситы, перегоняющие одно в другое. А не хочешь перегонять — юзай java-классы из скалы. Не вижу проблемы.
В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать.
C>>Причём мне лично парсеры что-то не приходится писать каждый день. D>Ну это так себе аргумент. Кому-то не приходится делать ничего сложнее формоклёпства, ну и пусть он значит юзает дельфЮ. Пойнт в том, что чем проще язык, тем он сложнее для сложных задач. Т.е. простое сделать проще, а как только появляется человек со своей спецификой (парсеры, или что ещё) — он тут же огребает геморрой. Меня вот несколько вымораживает факт существования implicits. Но с другой стороны я понимаю, что без них не было бы ни scalatest, ни squeryl. Оно конечно я хз зачем этот "human-like syntax" в scalatest (мне с головой хватало влоб-тупого JUnit), но вот squeryl — это аргумент.
А в Java есть QueryDSL, который достигает бОльших результатов без выноса мозга в squeryl.
Здравствуйте, Cyberax, Вы писали:
C>В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать.
Вот тут поподробнее пожалста. Что жава может делать со своими коллекциями такого, что не может скала? Вообще без преобразований.
Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Здравствуйте, dimgel, Вы писали:
C>>В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать. D>Вот тут поподробнее пожалста. Что жава может делать со своими коллекциями такого, что не может скала? Вообще без преобразований.
Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна.
D>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру.
Здравствуйте, Cyberax, Вы писали:
C>Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна.
Вот я и пытаюсь понять, в чём неудобство-то. Если java-классы она вполне себе юзает.
D>>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда? C>Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру.
А зачем тебе cons-список, если ты с java-коллекциями работаешь? В жаве (и тем более в легаси-коде на жаве) cons-списков нет.
Здравствуйте, dimgel, Вы писали:
DD>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Есть две вещи: во-первых, очень часто используется большинство функций отсюда. А во-вторых что бы передать коллекцию куда-то дальше в скала код её обычно тоже требуется привести к скаловскому виду.
Впрочем, я не считаю что написать .asScala или .asJava это ужасно сложно, да и делать это обычно приходится лишь в ограниченном количестве мест — только на стыках java-библиотек и scala-кода.
Здравствуйте, dimgel, Вы писали:
C>>Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна. D>Вот я и пытаюсь понять, в чём неудобство-то. Если java-классы она вполне себе юзает.
Как мне в Java работать с Option'ами, к примеру? Мне хочется банального, чтобы map.get(key) показывала, что может вернуть null.
Нужно городить огород с implicit'ами. В Kotlin я просто делаю класс-дублёр, где помечаю аннотациями nullable-методы. Всё.
И таких мелочей много.
C>>Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру. D>А зачем тебе cons-список, если ты с java-коллекциями работаешь? В жаве (и тем более в легаси-коде на жаве) cons-списков нет.
А в Скале есть, и хочется с ними работать. Аналогично, хочется делать такое:
Здравствуйте, Cyberax, Вы писали:
C>Из плюсов: C>0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов.
Ну, и слава богу, что в Scala сделано именно так, как есть сейчас. Такой же подход используется в F#, Ocaml и Haskell с точностью до названия.
Здравствуйте, dsorokin, Вы писали:
C>>Из плюсов: C>>0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов. D>Ну, и слава богу, что в Scala сделано именно так, как есть сейчас. Такой же подход используется в F#, Ocaml и Haskell с точностью до названия.
В Haskell Option(1)==1 вызовет ошибку типа. В Скале оно вполне скомпилится.
