Здравствуйте, Cyberax, Вы писали:
C>Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Я с Груви по сути не знаком, но что мне сразу приходит в голову, что Groovy динамически типизирован, Scala -- статически.
И, Scala в байт-код Java компилится, что дает ей возможность использовать все преимущества JVM.
Больше пока сказать не могу -- ковыряюсь. Потихоньку заинтересовываюсь в потенциале связки Java+Scala. Мысли, мысли...
Вооот, щас чего-то в ступор впал, читая этот цикл. Объясните, пожалуйста, какая разница между:
args.foreach (arg => greeting += (arg + " "))
и
args.foreach {arg => greeting += (arg + " ")}
И почему это работает в обоих случаях?
Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае?
Более того меня смутило, что будет работать даже
Здравствуйте, Kuzz, Вы писали:
K>Я с Груви по сути не знаком, но что мне сразу приходит в голову, что Groovy динамически типизирован, Scala -- статически. K>И, Scala в байт-код Java компилится, что дает ей возможность использовать все преимущества JVM.
собственно, groovy в байткод не хуже скалы компилится
да и можно статически всё типизировать при необходимости.
имхо главный минус груви на текущий момент — это проблемы с производительностью, а остальное там как минимум не хуже ruby или, скажем, javaFX
я к тому что groovy вроде как уже стабильный и популярный язык, а тут на RSDN им особо никто не интересуется... или, быть может, мне это просто показалось?
Здравствуйте, rsn81, Вы писали:
K>>>Вы пишете, используя IDEA? C>>Да, причём даже приложения на SWT+JFace R>И RCP?
Ага. Лучший способ чего-то изучить — это не использовать поддержку IDE
T>я к тому что groovy вроде как уже стабильный и популярный язык, а тут на RSDN им особо никто не интересуется... или, быть может, мне это просто показалось?
Интересуются. Но немного народу.
Re: Ваше отношение к языку Scala
От:
Аноним
Дата:
14.07.08 10:54
Оценка:
VD>1. Знаете ли вы что такое Scala?
Пару месяцев VD>2. Если знаете, то как к ней относетесь?
Тащусь
Но судя по джире, для промышленного применения слегка сыровата (можно налететь на вилы),
VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Планирую в своем частном проекте VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Отсутствие нормальной IDE(хотя jetbrains обещает поддержку в восьмой версии)
Отсутствие проектов, на которых можно было бы поучится проектированию в рамках Scala
K>И почему это работает в обоих случаях? K>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае? K>Более того меня смутило, что будет работать даже K>
Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису.
Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?)
Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается.
А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете?
Здравствуйте, Kuzz, Вы писали:
K>Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису. K>Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?)
Очень просто — классы Java и Scala видят друг друга и могут без проблем использоваться совместно. Естественно, из Java недоступна часть функциональности Scala типа pattern-matching'а.
K>Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается.
Да. Но оно пока глючит у них.
K>А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете?
Я Maven использую, там всё просто.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
K>>Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису. K>>Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?) C>Очень просто — классы Java и Scala видят друг друга и могут без проблем использоваться совместно. Естественно, из Java недоступна часть функциональности Scala типа pattern-matching'а.
K>>Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается. C>Да. Но оно пока глючит у них.
K>>А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете? C>Я Maven использую, там всё просто.
Спасибо! Вот ведь... потянул за одну ниточку, вытащил клубок. Придется взглянуть на Maven
А по поводу моего вопроса по коду не можете подсказать, в чем там фишка?
K>И почему это работает в обоих случаях? K>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае?
То же самое. Скобки при вызове методов — опциональны (точнее, это получается инфиксная запись). А фигурные кавычки {} просто обозначают блок кода, как и в Java.
K>>И почему это работает в обоих случаях? K>>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае? C>То же самое. Скобки при вызове методов — опциональны (точнее, это получается инфиксная запись). А фигурные кавычки {} просто обозначают блок кода, как и в Java.
Здравствуйте, thevery, Вы писали:
T>Здравствуйте, Kuzz, Вы писали:
T>собственно, groovy в байткод не хуже скалы компилится T>да и можно статически всё типизировать при необходимости.
Поставить тип у переменной — еще не значит сделать язык статически-типизированным
T>имхо главный минус груви на текущий момент — это проблемы с производительностью, а остальное там как минимум не хуже ruby или, скажем, javaFX
Эта проблема является одним из следствий динамической типизации. Представь, что все методы вызываются грубо говоря через рефлекшн.
Здравствуйте, l00ser, Вы писали:
L>Эта проблема является одним из следствий динамической типизации. Представь, что все методы вызываются грубо говоря через рефлекшн.
так что ждем тестов invokedynamic
а вам знакомо название "програмирование в намереньях" intention programming?
это очень похоже на то что вы описываете.
но на сколько мне известно оно загнулась у микрософта на стадии работающего прототипа
идея красивая, но "меня терзают смутные сомненья"