Опубликованы планы развития Scala 2.11 и 2.12

прочитал твой коммент, перешел по ссылке вверх. выиграл.

Это поделие не умерло еще? А пора бы уже, Java 8 содержащее все то, ради чего стоило с сабжем связываться, уже несколько месяцев как вышла.

Писал на скале 2.7 приложение несколько лет назад, весьма негативные впечатления остались. И стыдно немного перед теми товарищами, которые это приложение до сих пор поддерживают. Уже позже понял, что на Java 6 + Guava можно было то-же самое сделать с небольшой прибавкой LOC, при это даже не узнав про огромное количество грабель, которые в скале на каждом шагу. Больше всего от интеропа java-scala досталось, непонятно как можно было его настолько кривым сделать.

А по подробней можно что за проблемы?

«Pluralitas non est ponenda sine necessitate.» (С)

Java 8 уже изначально поддерживает ФП.

http://www.joinebook.com/java-8-lambdas-pragmatic-functional-programming/

А если нужен типа динамический ФП язычок - Groovy в помощь.

Старик-энтырпрайзник, а как же душа?

У меня сегодня нет корма для участников Специальной Олимпиады.

так убого,как в джаве, нужно еще постараться сделать. касается и стримов, и других ПЛЮШЕК.

Если не очень подробно, интероп оказался ужасающим. Он в скале рекламировался как seamless и в проекте решили скалу оставить за java-интерфейсами. В итоге над БД висели scala объекты, но JPA отдавал только Java коллекции этих объектов. Они затем обрабатывались в scala и отдавали удаленному гую через java интерфейсный ремотинг. И нормально работали только простейшие варианты, и валилось все на пустом месте. Вот зачем в скале свои енумы? Или свой BigDecimal? Правильно, чтобы скучно не было на интеропе, а то в жаве Gue Steele c Doug'ом Lea идиоты, и не могут правильные енумы сделать. А вот Одерский сумел.

Еще тогда скала коллекции умели java-коллекции оборачивать автоматически (вроде в 2.8 что-то меняли с этим). И это было удобно - функциональные операции над обычным java.util.List (тогда Guava еще не было). Но вот обратно в Java коллекции они внезапно не разворачивались.

Еще вроде простейшую операцию - вернуть итератор через yield как в питоне, оказалось хрен сделаешь (подробностей не помню правда).

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

Case классы - просто муть «без задач» (с). Абсолютно нерабочая хрень со сломанным наследованием.

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

Еще тулинг был ну просто пипец. scalac известный тормоз, но в то время еще и fsc был полурабочий и отладка была очень ограниченная.

Вообщем google: scala rants, там одни и те же проблемы описываются.

Как пост-мортем впечатления, стало понятно, что с Java-библиотеками scala неприменима - на Java будет быстрее и проще. Ну а после выхода Java 8 и подавно. А без java библиотек - если случится чудо и понадобится написать приложение без java-библиотек, то тут scala ну совсем не нужна, так как есть Django (либо рельсы для тех кто отступы в коде не любит), который по удобству/скорости разработки/наличию готовых компонентов просто несравним со скалой.

Груви умер не родившись же. Jython отлично работает же, если хочется чего-то JVM-скриптового. Зачем связываться с наркоманским Grails'ом (мы не знаем, как написать веб-фреймворк похожий на рельсы, давайте лучше hibernate и springMVC скриптами обмажем) с неясным будущем, когда можно на Jython за полчаса настроить cherrypy и приложения начать писать без контейнеров сервлетов и прочей EE-мути (которая имеет место жить, но только не рядом с динамическими языками).

Это поделие не умерло еще? А пора бы уже, Java 8 содержащее все то, ради чего стоило с сабжем связываться, уже несколько месяцев как вышла.

В Java 8 достаточно поверхностная поддержка функционального программирования в стандартной библиотеке. Такое ощущение, что по-быстрому запили, что успели до дедлайна. Берём, например, класс Optional<T>. Вроде неплохой класс, много чего есть, монады и всё такое. Берём аналогичный класс OptionalInt. Специализированный аналог для int-а, чтобы не тратить место на лишний object. Но в нём нифига нет вообще, никаких map-ов.

В старые коллекции добавили чуток функциональных методов, но их очень мало! Нужно гораздо больше функциональщины.

до дедлайна

Это не дедлайн, это обратная совместимость. Они же лямбды по-человечески реализовали на уровне JVM, на это большинство усилий было направлено. А стандартную библиотеку они не любят ворошить, чтобы не сломать чего-нибудь в существующем коде.

Про специализацию - она не готова еще в нормальном виде, уже после выхода Java 8 драфт по value-классам появился, которые должны объединить объекты и примитивы под одними интерфейсами (примитивы как частные случаи value-классов). Может к Java 10 допилят.

Про функциональщину - категорически не согласен. В энтерпрайзе, где JVM царь и бог - не нужна она. Точнее нужна, но очень ограниченно, map нужен, а вот fold - уже нет. Гуава в этом отношении - ну очень прагматичная библиотека, любителей функциональщины они в фичреквестах сразу лесом шлют.

Если же ваши интересы простираются дальше очередной «автоматизации склада, которая нужна вчера и должна интегрироваться со всем существующим г-ном», то, если high performance - то опять же не нужна функциональщина. Императивный код всяко проще оптимизировать (речь не про алгоритмическую оптимизацию - алгоритм правильный и там и там можно написать, просто в императивщине больше писать, а про кеши процессора всякие).

Если же нет ни «склада» ни high performance и время на разработку есть, то напиши куда слать резюме можно и на гомоморфизмы порукоблудствовать. Только здесь скала тем более не нужна, берите Хаскель и рукоблубдствуйте на здоровье. Если алгоритм внутри важнее сотни ентити-классов и до железа не надо оптимизировать, то можно и на Хаскеле веб-морду с crud'ом к этому алгоритму прилепить.

Что, на старости лет на борщевую маргинальщину потянуло? ФП не нужно. Все, что в Java появлялось после Java6 не нужно. Ну да ты и сам должен знать, что enterprise с шестерки еще лет пятнадцать никуда не слезет.

Это не дедлайн, это обратная совместимость. Они же лямбды по-человечески реализовали на уровне JVM, на это большинство усилий было направлено. А стандартную библиотеку они не любят ворошить, чтобы не сломать чего-нибудь в существующем коде.

Обратная совместимость тут не при чём. Никто не мешал им спроектировать *новый* класс нормально. Никто не мешал им подобавлять побольше *новых* методов. Естественно существующая библиотека коллекций должна оставаться рабочей в том виде, в котором она есть, но расширять её никто не мешает.

Про функциональщину - категорически не согласен. В энтерпрайзе, где JVM царь и бог - не нужна она. Точнее нужна, но очень ограниченно, map нужен, а вот fold - уже нет. Гуава в этом отношении - ну очень прагматичная библиотека, любителей функциональщины они в фичреквестах сразу лесом шлют.

Многие участки кода в функциональном виде как пишутся, так и читаются лучше, чем в императивном. fold это довольно частый случай цикла, который делает что-нибудь, чего там ненужного-то? Есть и обратные примеры, когда 10 строчек императивных циклов и пишутся и читаются проще, чем пара развесистых функциональных строк, не спорю. Всегда надо головой думать.

Хотя мне исполнение scala понравилось, с её for-ом, который и выглядит красиво и знакомо любому императивщику, и по факту является сахаром для функциональных преобразований. Вроде LINQ - та же идея. Могли бы и в Java как-нибудь перетащить попробовать.

Если же ваши интересы простираются дальше очередной «автоматизации склада, которая нужна вчера и должна интегрироваться со всем существующим г-ном», то, если high performance - то опять же не нужна функциональщина. Императивный код всяко проще оптимизировать (речь не про алгоритмическую оптимизацию - алгоритм правильный и там и там можно написать, просто в императивщине больше писать, а про кеши процессора всякие).

HPC не писал, но имхуется мне, что пишут быстро приложение и потом узкие места профилируют и оптимизируют, хоть в императивные циклы развернут, хоть на ассемблере перепишут и через JNI подключат. Вряд ли узким местом будет всё приложение от начала до конца.

вернуть итератор через yield как в питоне, оказалось хрен сделаешь

Как страшно жить. А в жаве yield так и вовсе идентификатор.

Это поделие не умерло еще? А пора бы уже, Java 8 содержащее все то, ради чего стоило с сабжем связываться, уже несколько месяцев как вышла.

разве в Java 8 можно сделать

import p.{x => a}

А пора бы уже, Java 8 содержащее все то, ради чего стоило с сабжем связываться, уже несколько месяцев как вышла.

Что-то в репозиториях openjdk 8 не видать.

А пора бы уже, Java 8 содержащее все то, ради чего стоило с сабжем связываться

Stackable trait pattern жаба уже умеет? Или по-прежнему надо файлы писать на 10 000 строк для нетривиальной модели данных?

Ага, python 3 так успешен, что вторую ветку продлили до 2020. Правда в том, что людям без разницы на чем писать, ибо реальных, существенных достоинств у третьей ветки нет. Поэтому новые проекты идут на P3, а старые на P2 и никто их переписывать не будет, пока в P3 не появится действительно киллер фича.

Хуже от этого только разработчикам популярных библиотек, которым трахают мозги оба лагеря.

пока в P3 не появится действительно киллер фича.

asyncio?

Ну, понятно, я с интеропом не сталкивался, полет нормальный. Юзаю скадьные либы, нравится. Питон нравится меньше. Но некоторые претензии к скале тоже уже есть. Например иногда не комплится код, использующий библиотеку. Лезешь в исходники, а там тааакая сигнатура, без ученой степени не разобрать. И javadoc-а часто нет. Ощущение такое, что в скала сообществе считают, что пользователь библиотеку должен как 100% black box воспринимать, что мне кажется полной мутью, время от времени приходится разбираться в исходниках либ, а там тихий ужас.

Да, asyncio хорошо, но по массовой доле почти никому не нужен. Вот если бы настоящая многопоточность, или существенный рост производительности, то переход был бы, а так всем просто плевать на небольшое, не существенное изменение функциональности.

Хуже всего для разработчиков питона, то, что крупные конторы, спонсирующие разработку так на P3 и не перешли пока.

Короче неприглядная реальность написана тут от лица одного из совета директоров.

и type DomainMap = Map<RedundantStupidKeyClassName, StupidRedundantValueName> тоже.

если в Java (Java 8) — и этого тоже нет (как и import)...

...то у меня создаётся впечатление что программирование на Java это процесс постоянного копи-пастинга кусков кодового текста :-) :-D

Любое программирование на 99% состоит из копи-пастинга. Все уже давно написано, сейчас остается только затачивать под конкретную мелкую задачу.

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

ССЗБ. Вон из профессии!

Последние несколько лет проектом в основном как раз токи занимался Пауль. Вот он и дал понять что этим топором в пору гавно месить.

сам сделал, сам поплакал - какой мужественный, в сущности, человек...

А если нужен типа динамический ФП язычок - Groovy в помощь.

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

Императивный код всяко проще оптимизировать (речь [..] про кеши процессора всякие).

это высказывание требует хорошего обоснования

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

Сам-то посмотрел прежде чем писать? Нормальная у него активность на гитхабе: https://github.com/odersky Щас интенсивно пилит проект dotty

Дурак ты, сразу видно. Какой смысл писать Джаву на Скале? Это же изначально гиблая идея, да ещё и с таким уровнем интеропа. Хочешь seamless, бери Xtend, Kotlin какой-нибудь. Скала - это язык с другой парадигмой и философией, интероп там сделали в чисто маркетинговых целях, чтобы когда дело доходит до вызова Java API из Scala, не надо было изъёбываться и писать bridge между Scala и Java. Но если у тебя весь код состоит полностью из взаимодействия с чистыми Java-классами, то зачем ты тогда вообще выбрал Scala?

Что только люди не придумают лишь что бы на СмаллТалке не писать

Пишу на Scala ынтерпрайз-систему нового поколения для большой компании-лидера в своей области. Саси.

Такое ощущение, что по-быстрому запили, что успели до дедлайна.

Слушал как-то закулисные разговоры разработчиков JVM про фичи в языке, не всё понял, но впечатление осталось, что они на самом деле очень сильно над всем этим задумываются. И что главная проблема - как новые фичи будут сочетаться с тем, что уже есть.

А ты не юзай JPA со скалой и усё будет впорядке.

По остальным предъявам - в актуальной скале большинство перечисленных проблем решены.

ынтерпрайз-систему нового поколения

Учетный сайтик, так и скажи.

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

Ну это понятно. Ещё аутентификация хитрая и интероп со старыми системами. В общем работы много: ограничения предметной области и требования нетривиальные. У меня какая-то неприязнь просто к маркетинговым штукам типа «Энтерпрайз нового поколения».

Ну и как скала себя показывает?

Какие крупные библиотеки используешь?

Ну и как скала себя показывает?

На 4-ку. Почему не 5:

Разработчики на проекте в основном закоренелые джависты (EE-шного разлива), осваивают язык в процессе, так что код иногда получается, мягко скажем, неидиоматический. Иногда даже хуже, чем на джаве было бы.

Ещё часть написана на Akka - видимо по тем же причинам на неё без слёз не взглянешь.

Были проблемы с интеропом с уже написанными спринговыми приблудами.

Долго компилируется, да. Не си++, но иногда заметно.

Лично моя боль: в процессе написания маленького DSL со scalaz, выяснилось, что вывод типов в скале совсем не всесильный. В итоге, не всегда заранее очевидно нужно ли писать тайп-параметры в данном конкретном вызове или нет, пока не скомпилируешь.

Навскидку:

• Spring MVC, Spring Data JPA, Spring Data MongoDB (или как там её)
• Akka persistence - для новомодного эвентсорсинга
• великий и ужасный scalaz - кто притащил, теперь народ пользуется

Всего не упомнишь - WAR-ки по сто мегабайт получаются, всё либы сторонние.

Из особых извращений: Akka-акторы у нас инстанциируются спрингом с внедрением зависимостей и прочими радостями EE-мирка. Мне бы такое даже в голову не пришло, до сих пор не уверен, что это было необходимо.

На C++ только ленивый не ругался, это не мешает писать на нём говнокод (tm)

fixed

Интересно, а в самом языке никаких новых интересных фич не будет? Как раз сейчас читаю книгу, есть спорные моменты но в целом ничего так, интересно.

Какой ужас, неужели кто-то может так любить JPA чтобы притащить ее в Scala-проект? Даже через Spring Data.

Slick хороший и приятный, при этом работает не через миллион слоев AOP и не требует DI, который в скале не особо то и нужен.

Вместо Spring MVC можно было юзать Scalatra или Spray, которые в отличии от Play можно спокойно завернуть в обычный WAR-ник.

Ещё бы я знал, как объяснить это архитектору и остальной американской команде. Если честно, у меня нет общей картины проекта, я плохо представляю в целом, что мы делаем и зачем. Архитекторы и лиды проекта сидят в США, а мы тут такие умные на подхвате.

А вот это http://scalamacros.org/news/2014/07/16/roadmap-for-scala-macros.html уже упоминали?

для Ъ: по ссылке scala macros roadmap.

Scala “Don Giovanni”

Cleaned-up syntax
Removing puzzlers
Simple foundations
Better tooling
Faster code

http://developers.slashdot.org/story/14/09/06/1539224/scala-designer-martin-o...

Собираются