Scala себя убивает

Собственно зачем оно нужно(Scala), когда есть Clojure?

Scala себя убивает

Они хотят добавить макросы

Предложения не согласуются.

давно хотят. и даже добавляют. в общем-то почему нет?

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

В том то и дело, что если туда пихать говно подобное макросам, то Scala присоеденится к неюзабельной маргинальщине типо Clojure

кодогенерился имхо не помешает. что плохого-то?

кодогенерилка *

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

Ни Scala, ни Clojure не нужны. Нет, кому-то нравится, но ничего сверхфичастого.

А мне кажется, что Scala — это C++ двадцать первого века. История повторяется: был успешный однопарадигменный ЯП (C / Java), но потом пришёл какой-то сумасшедший мужик из маленькой европейской страны (Страуструп / Одерски) и решил навесить на него модную примочку (ООП / ФП). Получился сложный (в изучении, в использовании, в написании плагинов к IDE) и уродливый язык-монстр. Но, как ни странно, он нашёл большую поддерку и популярность среди неокрепших умов, которые считают, что чем сложнее и непредсказуемее инструмент, тем круче тот, кто умеет кое-как им пользоваться. Пройдёт время, и Scala'у бдут проклинать, как сейчас проклинают C++.

Почему сделан такой вывод?

В чём же неюзабельность кложуры?

в том, что с практическим применением у нее так же как у лиспа? :)

скала - эксперимент, вышедший из под контроля.

скаля --- это хорошо, красиво и жизнеспособно. на скале можно писать с ФП фишками, а можно и без, в явском стиле. может нравится тебе, или просто не умеешь еще. очень удобно переползать ;)

всё логично

в том, что с практическим применением у нее так же как у лиспа? :)

Согласен с применением, но к юзабельности - это не аргумент. Как по мне, то кложура более понятна и юзабельна чем скала.

Время покажет про практичность.

Имхо, лисп с возможностью прозрачного заюза Java библиотек нужен + более-менее вменяемая поддержка в IDE (я имею ввиду IDEA). На счёт Scala - хз, а Clojure просто хороший лисп для которого вполне возможно решение проблемы отсутствия либ\нехватки документации к ним.

можно писать с ФП фишками, а можно и без

На CL тоже.

Хм, а как в Clojure с загрузкой jar-файлов на ходу? В идеале хотелось бы что-то вроде (load «foo.jar»).

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

что сложного в изучении? что с использованием? очень интересно про написание.

от себя: получилось крайне хорошо.

математика пишется приятно, доступ к БД приличный, формы/таблички шлепаются на ура. букав, в сравнении с жабой, сильно меньше, геморроя, в сравнении с плюсами, считай что нет вообще.

расскажи о своих проблемах использования скали, мне интересно.

лисп с возможностью прозрачного заюза Java библиотек нужен

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

Clojure просто хороший лисп

ты видел сколько у нее вариантов скобочек?

На CL тоже.

можно. вот только никто (исчезающе мало) не пишет.

о чем-то это, да говорит ;)

На Скале написан твиттер. о чем-то это да говорит :)

Во-первых, работа над макросамы идет уже достаточно продолжительное время. Это не результат сиюминутного порыва. Было множество постов, конференции на эту тему.

Во-вторых, насколько я знаю, они в языке ничего не ломают из-за макросов.

В-третьих, причинно-следственная связь сильно хромает в «Они хотят добавить макросы» => «Scala себя убивает».

Если кого-то серьезно интересует, без «аналитики», что на самом деле добавляют, то можно, хотя бы, ознакомиться с вот этой презентацией проекта Kepler - https://github.com/xeno-by/kepler/blob/master/papers/SID100-LightweightMacros...

как в Clojure с загрузкой jar-файлов на ходу?

в jvm. никак.

встречный вопрос: для чего это и где используется? про космический карапь, один и много лет назад, все знают. еще?

ты видел сколько у нее вариантов скобочек?

Видел - () [] {} #{} запоминается элементарно за 5 мин.

Сам так не делал (не нужно пока было). Нагуглилось следующее:

http://www.jarvana.com/jarvana/view/org/clojure/clojure/1.3.0/clojure-1.3.0-j...

На Скале написан твиттер. о чем-то это да говорит :)

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

пример такой современной системы на лиспе? :)

Это сразу перечеркивает нужность лиспа на jvm. Динамический язык без возможности загрузить библиотеку на ходу не нужен.

Простейшие плагины так можно реализовать.

Если из classpath то всё проще, там есть целый ворох средств use, load, require. Можно загрузить с открытием неймспейса, загрузить часть функций и т.п.

хороший лисп

() [] {} #{}

бугага ))

Это сразу перечеркивает нужность лиспа на jvm.

ну так а я о чем? :)

в jvm. никак.

Что это никак? Стандартными средствами явы делается в 5 строчек, а можно еще и свой ClassLoader отнаследовать и грузить что хочешь и откуда хочешь.

На Скале написан твиттер. о чем-то это да говорит :)

В твитере на кложуре написано в джва раза больше чем на скале:

https://dev.twitter.com/docs/twitter-libraries#clojure

https://github.com/mattrepl/clojure-twitter

ClassLoader отнаследовать и грузить что хочешь и откуда хочешь.

ну один раз --- да. что будет, если я в jar-е поменяю поведение объектов и захочу загрузить второй раз без рестарта всей аппликухи? что будет с объектами, которые я насоздавал из предыдущего jar-а и рассовал по ниткам? :)

ты видел сколько у нее вариантов скобочек?

Ты же это не серьёзно? Это аргумент?!

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

Вот тебе пример:

(defmacro my-let [let-binds & body]
  `(let [~@let-binds]
     ~@body))

user=> (macroexpand '(my-let (a 1) (println a)))
(let* [a 1] (println a))

Clojure->Lisp->мусорка->точка

Нехорошо будет. Я не помню точное поведение при загрузке классов с существующими именами (где-то читал, что они считаются новыми и не связанными со старыми с совпадающими именами).

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

// А зачем грузить второй раз одно и то же?

Clojure->Lisp->мусорка->Nil

fixed

Это клиенские API если че. На Scala написаны внутренности твиттера если че

))

и тем не менее если чо

А зачем грузить второй раз одно и то же?

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

нет, круто, да. но бесполезно :)

ппц. ты слил

Придерживаюсь мнения, что один ЯП должен реализовывать только одну парадигму дабы способствовать поддержанию концептуальной целостности программ. Не стоит смешивать ООП и ФП пусть даже ценой краткости кода. Хотите решить задачу через ООП — берите Яву или Руби, хотите через ФП — Haskell в руки. С ним я познакомился раньше Scala'ы и наверное поэтому её создание кажется мне нецелесообразным. Если подытожить, то мне приятнее иметь для изучения и разработки два отдельных языка, чем один комбайн.

Что касается написания плагинов, то в этом вопросе я полагаюсь на мнение специалистов из JetBrains. Их IDE обеспечивают отличную поддержку Явы, Groovy, но с плагином для Scala дело все ещё обстоит весьма плохо, и это отностится и к другим популярным IDE. Почему они начали мутить свой ЯП Kotlin? Мне удалось лично пообщаться с разработчиками, и они ответили, что Scala не подходит им в качестве замены Явы именно из-за сложности. Можно еще почитать здесь: http://confluence.jetbrains.net/display/Kotlin/Comparison to Scala. Порою очень трудно понять, что делает код.

Почему нельзя map, filder, foldLeft по mixinу с 3 трейтами?

Не стоит смешивать ООП и ФП пусть даже ценой краткости кода

стоит. это удобно и хорошо.

Хотите решить задачу через ООП — берите Яву или Руби, хотите через ФП — Haskell в руки.

глупость какая. я хочу решить задачу. ООП это или ФП мне лично фиолетово. задачу надо решить и решить быстро. скаля в этом плане мне нравится значительно больше жабы. _значительно_. все просто, все красиво, просто «ах».

иметь для изучения и разработки два отдельных языка

о, бестолковый дроч! ты истинный фанат :)

Порою очень трудно понять, что делает код.

это, внезапно, справедливо вообще для любого языка. просто не слеует писать такой код :)

ппц. я и не спорил.

Эээ… Не могу ответить, так как не знаю, что такое трейты. Да и вообще не стоит спорить по повод мультипарадигменности. Это исключительно дело вкуса, ведь кто-то любит односолодовый ви́ски, а кто-то купажированный (да простят меня ЛОРовцы за аналогию с бухлом).

На диспетчер пишут больше чем на скала.
Поищите на job board

На диспетчер пишут больше чем на скала.

диспетчер

?