Здравствуйте, mkizub, Вы писали:
M>Да, JetBrains реализует очень похожую идею. Только они не идут в реализации до конца. M>Они выходной код генерируют как текст (явовский), и опять попадают в узкое горлышко. M>Конечно, там ниже всегда будет узкое место, всё равно прийдётся в конечном итоге M>генерировать машинные комманды.
И в чем же узость подхода с генерациепй Явовского кода?
Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
M>Идея SOP в том, чтоб убрать промежуточные узкие места.
Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT.
Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
Лично я даже предпочту генерацию промежуточного кода на высокоуровневом ЯП, так как его можно отлаживать. Ведь кодга ты делашь ДСЛ, расширяешь язык или делаешь фрэймворк, то нужно отлаживать то что ты делаешь. Если у тебя генерируется машинный код, то отлаживать его будет чретовски сложно. А если промежуточный код на Яве (да на чем угодно), то его моно легко отладить и найти ошибку в генераторе или логике.
M>Чтоб не надо было извращаться генерируя явовский код.
Это только в твоих устах извращение. Причем пахнет это фанатизмом — бездумным отрицанием.
M>Чтоб не надо было извращаться над JIT компилятором, который по байткоду пытается понять, что ж там M>было в исходном коде написано, а то иначе оптимизация не удаётся.
Ясно. Как я и предполагал изачально тебе не нравится сама Ява, ее архитектура. Отталкиваясь от этого ты и пыташся критиковать, то что на ней основано.
Откровенно говоря меня не интересует твое отношеие к Яве. А нового ты так ничего и не предложил. Взял чужую идею язков-ориентированного программирования (а.к.а. DSL-подход), дал ему свое название, накрутил откровенного балшита, добавил требования обязательной компиляции в машинный код и выдаешь за свою идею. Извини, но мы тут не мальчики и прекрасно разбираеся в данном вопросе. Эта идея стара как мир.
К>>А то что можно графику использовать дак это понятно, только на практике текст имхо много гибче и универсальней.
M>У меня есть спецификация узла для loops, M>ForStat { M> Stat init; M> Expr cond; M> Block body; M> Expr iter; M> Label lblcnt; M> Label lblbrk; M>} M>и мне к нему надо специфициоровать Control/Data Flow. Я это делаю как M> @dflow(out="lblbrk") private static class DFI { M> @dflow(in="this:in") ASTNode init; M> @dflow(in="init", links="iter") ENode cond; M> @dflow(in="cond:true") ENode body; M> @dflow(in="body") Label lblcnt; M> @dflow(in="lblcnt") ENode iter; M> @dflow(in="cond:false") Label lblbrk; M> } M>Как ты думаешь, что удобнее было-бы, нарисовать стрелочками граф, или разбираться в этом коде?
Удобнее было бы написать читабельную строчку кода. Вот как выглядит описание цикла for в Nemerle:
macro @for (init, cond, change, body)
syntax ("for", "(", Optional (init), ";", Optional (cond), ";",
Optional (change), ")", body)
{
M>А у него ещё нет проверки на правильность строк в аннотациях, если что — в рантайме баги вылазят
А зачем строки использовать? Использую AST.
M>Первое, что сделаю, когда редактор стрелки научится рисовать — перепишу все эти control flow M>красиво.
Ты бы лучше подумал над тем, что изобретение колес не лучшее занятие для 21-го века. Сэкономил бы массу времени.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Ты хочешь привести всё к одному знаменателю. Либо только текст, либо только диаграмы. M>Не надо этого. Можно и то и другое. Рисовать flow control удобнее стрелками. Да, с цветами — типа чёрным безусловные переходы, красным — если выражение true и синим — если false. M>А другие вещи лучше выразить текстом. Желательно тоже расцвеченым. Ты же не возражаешь против colorer-ов? А некоторые вещи удобнее как математика, формулами рисовать.
Одним из постулатов ФП как раз зувучит мысль о том, что управление потоком управления есть не правльный стиль программирования. Что вместо того чтобы думать о программе как о потоке упрвления, лучше думать о ней как о наборе рекурсивных вызовов.
Думаю, что выражать рекурсию стрелочками занятие неблагодарное. Как с этим быть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
M>>Да, JetBrains реализует очень похожую идею. Только они не идут в реализации до конца. M>>Они выходной код генерируют как текст (явовский), и опять попадают в узкое горлышко. M>>Конечно, там ниже всегда будет узкое место, всё равно прийдётся в конечном итоге M>>генерировать машинные комманды.
VD>И в чем же узость подхода с генерациепй Явовского кода?
Там много проблем. Самая простая — отсутствие goto. Без него нарисовать эффективную state machine практически невозможно.
VD>Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
В чём-то усложняет, в чём-то облегчает.
M>>Идея SOP в том, чтоб убрать промежуточные узкие места.
VD>Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT. VD>Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
Я почитал дальше, и мне стало грустно.
Иди ты нафиг.
Здравствуйте, mkizub, Вы писали:
M>А при трансляции это будет разворачиваться плагином в дерево узлов соответствующее хаскелевской семантике, или С-шной семантике, в зависимости от наших пожеланий. M>Разумеется, вводить новый узел только для сортировки будет не очень умно в обычной ситуации, но если вдруг надо будет написать проект, который будет сортировать M>списки в каждой строчке программы — то почему нет?
1. Во что в С++ развернутся функции с паттерн-матчингом?
2. Во что в Хаскеле развернутся перегруженные фукнции?
Ты вообще, знаком с Хаскелем? Ты представлящь насолько это другой язык?
Все что ты сможешь сделать — это создать 10 парсеров для разных синтаксисов одного и того же (по семантике) языка, и создать 10 же прети-принтеров, которые будут преобразовывать твое АСТ в разный синтаксис. Один из принтеров будет графическим.
Толку от этого будет 0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>>>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. M>>>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка. M>>>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
VD>>Можно по подробнее? В чем проблема? В чем решение?
M>http://www.rsdn.ru/Forum/message/2520182.aspx M>http://www.symade.org/ M>http://www.symade.com/
Зачем мне ссылки на сайти и на совершенно пустое сообщение? Ты на ответ то можешь ответить?
В прочем, почитав твою дисскуссию я понял, что ты переизобретаель велосипед языко-ориентированногшо программирования. Да еще и далешь это так же как ДжетБрэйновцы. По мне так это бесполезная и провальная идея.
Код и дальше будут писать в тексте. А ЯОП и так неплохо развивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
M>>>http://www.rsdn.ru/Forum/message/2520182.aspx К>>Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно WH>Все верно. Ссылка ведет в приватный форум. WH>Туда есть доступ только у команды. WH>У mkizub есть доступ только к этой теме в форуме.
Скажу больше. В этом собщении ничего (ровным счетом) нет. Вот его текст: OE>Здравствуйте, mkizub, Вы писали:
M>>А то ведь по новой это же самое прийдётся повторять всем, а не только рецензентам.
OE>золотые слова! может сразу в статье эти вопросы и осветить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Я бы сказал — он очень хороший язык. Но не перспективный. Это общая закономерность — в конце развития M>технологии появляются наиболее яркие и соверненные её проявления.
Как много нового можно узнать на форумах. Вот оказывается уже подходит конце развития каой-то там технологии.
M>Что до Scala для явы — то это не очень интересно, потому как Scala пытается впихнуть в яву невпихуемое. M>Scala намного лучше будет выглядеть на .NET или LLVM, а на яве это будет сплошная борьба с JVM.
Не вижу огромной разницы. Но если нужно .NET, то Немреле и есть такой варинат. Более того там ЯОП уже реализовано (макросами).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Там в другом фишка — это не генерация кода, это его изображение, одно для дазайнера и другое для программиста. M>Ты можешь один и тот-же код отображать в редакторе программы по разному. В Nemerle ты этого принципиально не можешь — он в себе подобный рендерер кода не имеет.
Ну, почему же не могу? Я вот в отладочных целях вывожу на экран древесное представление код. Так что потенциально это сделать можн, но не нужно. Точнее так. Можно для кода создать визуальные дизайнеры (дизайнер форм вобщем-то и есть такой дизайнер), но не стоит создавать много синтаксисов для одного языка. Написать прети-принтер чтобы он выдвал лексически разный код можно, но глупо. Создать несколько парсеров тоже можно, но тоже глупо.
В общем, я правильно понял, что вся фишка в том, что товарищь как и ДжетБрэйновцы фактически прелагает отказаться от текста в пользу внутреннего представления и графики (точнее некого представления доступного только в IDE)?
Мне кажется такой подход не перспективным. Код он и в айрике код. Его и в сорс-контрол можно положить, и по контесту заменить, и в форуме разместить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Там много проблем. Самая простая — отсутствие goto. Без него нарисовать эффективную state machine практически невозможно.
Хм. Может для Явы это и проблема, но на Немерле я без единого готу любой ДКА накропаю.
ОК, но почему бы тогда не взять дотнет и C#? Или не гнерировтаь байткод явы? Все же было бы проще.
VD>>Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
M>В чём-то усложняет, в чём-то облегчает.
Главное что во многом усложняем жизнь пользователей. Как такой код в форум запостить? А как в SVN положить?
M>>>Идея SOP в том, чтоб убрать промежуточные узкие места.
VD>>Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT. VD>>Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
M>Я почитал дальше, и мне стало грустно. M>Иди ты нафиг.
То что тебе стало грустно — это как раз нормально. На мой взгляд, ты занимашся совершенно бессмысленной фигней. А вот хамить не надо.
Влез в тему в которй твои игрушки никого не трогали, развел флуд на 100 сообщений, и еще тех кто с тобой не согласен посылашь куда по дальше. Иди лучше сам отсюда, пока не забанили.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ОК, вопрос в представлении? Ну, и что мне помешает сделать дизайнер котрый отобразит данные в нужном виде?
У меня есть средства которые распарсят код в АСТ и дадут его мне. Остается только взять и отобразить его в нужном виде.
M>Это никакого отношения к макросам не имеет. Это больше похоже на folding в редакторе, когда блок кода сворачивается в {...} M>Только тут не просто сворачивание кода, а отображение самой существенной его части, так как хочет видеть архитектор программы.
Ты говоришь о разных представлениях. Я не понимаю зачем при этом отказыватться от кода. Код — это то в чем хранится программа (текст). А представления — это то, что позволяет отобразить код по разному. Зачем делать полностью новую систему если вся задача втолько в создании разных представлений?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Расширяемость языка (и создание DSL) как в Lisp, удобство программирования превосходящие WYSIWYG редакторы и современные IDE. M>Возможность программировать ближе к человеческим понятиям.
1. Чем это отличается от языко-ориентированного программирования и DSL-подхода в частности?
2. Чем не удовлетворяют макросы? Они вроде решают эту задачу на олично.
M>Запись M>Logger.getLogger("FooBar").log(WARNING, "Message") fM>это трансляция на язык программирования пожеланя разработчика "каким-то образом сообщить такое-то предупреждение". M>Вся фишка в том, что предлагается так и писать M>trace WARNING "Message"
Хреновый пример. В том же дотете это так и будет выглядеть:
Trace.WriteLine("Message")
И опять же можно наклепать макросы (что и сделано в Немереле, но лично я ими не пользуюсь за ненадобностью).
M>и отдельно написать плагин к компилятору (точнее — среде разработки), который будет это пожелание trace трансформировать M>в понятия более низкого уровня, вроде "вызвать функцию такую-то с такими-то аргументами".
Это и делает макрос. Макрос и есть плагн к компилятру (и по совместительству к IDE).
M>Программист не будет переводить задачу не с человеческого описания на конкретный язык с конкретными библиотеками.
В общем, мне ясно одно. Ты пыташся переизобрести колесо. Макросы давно придуманы, проработаны и реализованы. Выбирай язык который их поддерживает и вперед. Никакие виртуальные машыны тут не помеха. А ты просто явно вместо того, чтобы изучить имеющийся опыт пыташся изобретать давно изобретенные вещи. Естественно, что без учета чужого опцта у тебя ничего путного пе получится. И не надо плеваться на работу тех, кто уже что-то сделал заявляя, что это тупиковый путь. Лучше разберись, что же они сделали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>>>List<String> ls = ...; M>>>String[] arr = ls.toArray(); M>>>а не M>>>String[] arr = ls.toArray(new String[ls.size()]); M>Я знаю, что он требуется в яве. А в моем комплиторе он не требуется.
Ну это на каждом углу написано: http://www.ibm.com/developerworks/java/library/j-jtp01255.html
1. Массивы примитивный тип, в scala — это объект (c прямой поддержкой компилятора)
2. Массивы в java ковариантны, а генерики нет. java для type safety втыкает проверки в рантайме, scala все делает в compile time.
3. Вывод типа по возращаемым типам не работает.
Конкретно по toArray (что собственно ничто иное как newInstance):
Why was Array generified this way? Again, the frustrating answer is to preserve backward compatibility. To create an array of a primitive type, such as int[], you call Array.newInstance() with the TYPE field from the appropriate wrapper class (in the case of int, you would pass Integer.TYPE as the class literal). Generifying Array.newInstance() with a parameter of Class<T> instead of Class<?> would have been more type-safe for reference types, but would have made it impossible to use Array.newInstance() to create an instance of a primitive array. Perhaps in the future, an alternate version of newInstance() will be provided for reference types so you can have it both ways.
You may see a pattern beginning to emerge here -- many of the problems, or compromises, associated with generics are not issues with generics themselves, but side effects of the requirement to preserve backward compatibility with existing code.
В scala подобных проблем нет (с ковариантностяим/контрвариантностями и primitive type) т.к. все есть объект. Остается одна проблема: erasure. Если твой компилятор ее решает, значит он не совместим с java либо реализует механизм рефлекшина либо скрытые параметры у объектов. Предлагать миру новый рантайм без библиотек может только sun или ms.
К стати, что и куда будет записывать компилятор, чтобы не используя reflection родить тип 'a' в классе Succ?
object ChurchNum {
type _0[s[_], z]= z
type _1[s[_], z]= s[z]
type _2[s[_], z]= s[s[z]]
type plus[m[s[_], z], n[s[_], z], s[_], z] = n[s, m[s, z]]
type _3[s[_], z] = plus[_1, _2, s, z] // = _2[s, _1[s,z]] = s[s[_1[s,z]]]
// = s[s[s[z]]]class Zero
class Succ[a] { def makeMe: a = new a }// в скала этот код не будет работать, естественно...
type +[m[s[_], z], n[s[_], z]] = plus[m, n, Succ, Zero]
type _4 = _2 + _2
// the values van be regarded as proofs that, e.g., 4 = 2 + 2
val proof : Succ[Succ[Zero]] = new _2[Succ, Zero]
val proof_ : Succ[Succ[Succ[Zero]]] = new _3[Succ, Zero]
val proof__ : Succ[Succ[Succ[Succ[Zero]]]] = new _4
}
M>Я не знаю, как в Scala сделан List[Int].toArray, но он не может этого делать M>без инлайнинга или передачи спрятанных параметров в метод. Чудес не бывает. M>Откуда-то метод toArray должен узнать тип массива.
А чудес там и нет, фокус аналогичен работе с примитивными типами в java — boxing:
object arrays {
val ls = "1" :: "2" :: "3" :: Nil
val als = ls.toArray
}
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, aka50, Вы писали:
Ну вот пришел Влад и все испортил. Тут ветка про scala и java была... там где есть java, нет nemerle, но есть scala... любой из этих примеров может работать на jvm, а твой не может
По этому надо уже отделить эту ветку (прос СОМ) и отправить ее в философию (или в декларативное??)
А про макрсы... ну скажем так, когда их очень много — это плохо, т.к. может начаться проблема совместимости (например две команды по разному определили эти самые comprehension, и более того, синтаксические конструкции таковы, что макросы начинают конфликтовать, на уровне компиляторов это решаемо, но на уровне читаемости — это будет плохо).
Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов.
VD>Так что проблемы Лиспа все же в очень большой степени упираются в его убогий синтаксис и в некоторые другие дизайнерские решения. Ну, и конечно в хреновый маркетинг и никудышное обучение. Накинулись на старичка...
Здравствуйте, aka50, Вы писали:
A>А про макрсы... ну скажем так, когда их очень много — это плохо, т.к. может начаться проблема совместимости (например две команды по разному определили эти самые comprehension, и более того, синтаксические конструкции таковы, что макросы начинают конфликтовать, на уровне компиляторов это решаемо, но на уровне читаемости — это будет плохо).
Это теоретизирование. Я вот никаких проблем от испоьзования макросов не вижу. Это же не макросы С?! Нужно решить проблему решаемую макросом — используешь макрос. Не нужно — не испоьзуешь. А так можно все что угодно превратить в проблему если использовать не по месту.
A>Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов.
Очень по Майкрософтовски, пока у нас чего-то нет, то оно лишнее или даже зло, а как появляется, то класная фича, и мы от не не откажемся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это теоретизирование. Я вот никаких проблем от испоьзования макросов не вижу. Это же не макросы С?! Нужно решить проблему решаемую макросом — используешь макрос. Не нужно — не испоьзуешь. А так можно все что угодно превратить в проблему если использовать не по месту. Влад, я все понимаю, но я пишу на java, в проекте у меня около 30 библиотек. И я рад, что это библиотеки, где достаточно читать объекты и методы. Все достаточно прозрачно и понятно (ну исключая кодогенерацию) А теперь представь, если они все будут макросами (использующих всякую короткую нотацию). Я слабо представляю какие надо иметь мозги чтобы это все понимать. Т.е. я это к тому, что макросы должны решать какую-то общеизвестную задачу (ну там orm или sql или di) но никак не пихаться где попало. Читать такой код (особенно без ide с полностью поднятым и компилируемым проектом) — застрелишься. Основная проблема в макросах (ИМХО) — это наличные скрытой семантики не видной в коде. Макрос работает _над_ аст, которого я естественно в коде не вижу, т.е. понять, что именно происходит — проблематично (именно для случая кучи макросовых библиотек).
ЗЫ: опыт с макросами и их потенциальными проблемами я еще из лиспа вывел. И не в синтаксисе дело (в лиспе даже более читабельно) а именно в мешанине и скрытой семантике.
A>>Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов. VD>Очень по Майкрософтовски, пока у нас чего-то нет, то оно лишнее или даже зло, а как появляется, то класная фича, и мы от не не откажемся.
Не я не отказываюсь... я против тотальной пропаганды оных. Это как шаблоны в С++. Когда с умом — хорошо, когда везде и всюду, да еще и без соотвествующей квалификации — атас (мы же рассматриваем возможность применения в мейнстриме , а не только среди отдельных гуру (гуру еще стать надо), ибо что может сделать сила языка в мейнстриме показал С++).
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala? VD>2. Если знаете, то как к ней относетесь? VD>3. Не думаете ли вы применить Scala-у в своих разработках? VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Доброго времени!
Сорри, что подтянул такую бородатую ветку
Но, чего-то я прочел 12 страниц обсуждения... и обсуждение темы увидел только на 1-й А дальше либо флейм, либо оффтоп. Либо и то, и другое.
А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум?
Как бы, идеи хорошие, но как они в реальной работе, в реальных проектах?
Если используете -- то для чего?
Если нет -- пожалуйста, тоже напишите, почему, если только это не будет сообщение типа "а нам и так хорошо в своем скворешнике живется"
Здравствуйте, Kuzz, Вы писали:
K>А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум?
Я использовать начинаю постепенно.
Просто только сейчас для этого языка появляются нормальные тулзы для разработчиков. Несколько недель назад вышел достаточно рабочий Scala-плугин (http://plugins.intellij.net/preview/popup/?sid=370&pid=1347). Этот плугин пишется самими работниками IntelliJ в рамках развития IDEA, так что это даёт мне некоторые гарантии того, что им достаточно безопасно можно пользоваться. По уровню, пожалуй, этот плугин уже обошёл интеграцию Немерля в Студию.
Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
K>>А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум? C>Я использовать начинаю постепенно.
Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая.
Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее.
C>Просто только сейчас для этого языка появляются нормальные тулзы для разработчиков. Несколько недель назад вышел достаточно рабочий Scala-плугин (http://plugins.intellij.net/preview/popup/?sid=370&pid=1347). Этот плугин пишется самими работниками IntelliJ в рамках развития IDEA, так что это даёт мне некоторые гарантии того, что им достаточно безопасно можно пользоваться. По уровню, пожалуй, этот плугин уже обошёл интеграцию Немерля в Студию.
Вы пишете, используя IDEA? Мне, в силу некоторых обстоятельств, привычно и надо использовать Eclipse. По поводу работы с Java кодом нарекний нет, но за сегодня поигрался со Scala в Eclipse-- впечатление, что еще работать надо много. Хотя и сделано уже много.
Ни не Немерля со Студией, ни Скалы с Идеей не видел
Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть.
C>Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Щас только приглядываюсь
C>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java.
Я так понимаю, общее впечатление после столького времени -- положительное?
Значит смысл потратить время на изучение -- есть, это хорошо.
Здравствуйте, Kuzz, Вы писали:
C>>Я использовать начинаю постепенно. K>Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая. K>Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее.
Я прочитал спеку языка и начал сразу писать. Просто я уже немного знаю другие функциональные языки и С++, что существенно помогает.
Вот тут есть неплохой вводной цикл: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
K>Вы пишете, используя IDEA?
Да, причём даже приложения на SWT+JFace
K>Ни не Немерля со Студией, ни Скалы с Идеей не видел K>Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть.
Пробовал где-то месяц назад. Особо ничем не удивил, сырой он ещё. В IDEA уже лучше даже работает.
C>>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java. K>Я так понимаю, общее впечатление после столького времени -- положительное?
Да, как язык Scala очень приятен. Вопрос пока остаётся только в инструментах — без них язык почти что бесполезен для крупных проектов (IMHO). Текущий уровень уже позволяет начинать использовать Scala для небольших модулей.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
C>>>Я использовать начинаю постепенно. K>>Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая. K>>Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее. C>Я прочитал спеку языка и начал сразу писать. Просто я уже немного знаю другие функциональные языки и С++, что существенно помогает.
C>Вот тут есть неплохой вводной цикл: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
Пасибо, поглядим. С функциональными у меня -- поверхностное знакомство с Лиспом еще из универа. С++ знаем. Значит порог вхождения будет не очень высоким, судя по всему Мож пару шишек набью.
K>>Вы пишете, используя IDEA? C>Да, причём даже приложения на SWT+JFace
Нисколько не сомневаюсь, что на IDEA можно и нужно писать Я считаю, что коммерческие проекты потому и платные, что есть за что платить (IDEA, MS VS Studio + Resharper).
Но из бесплатных Eclipse как-то впереди планеты всей. А я пока могу только его и использовать, ибо ломать IDEA... даже для дома не хочу
K>>Ни не Немерля со Студией, ни Скалы с Идеей не видел K>>Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть. C>Пробовал где-то месяц назад. Особо ничем не удивил, сырой он ещё. В IDEA уже лучше даже работает.
Опять-таки, спасибо, пощупаю
C>>>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java. K>>Я так понимаю, общее впечатление после столького времени -- положительное? C>Да, как язык Scala очень приятен. Вопрос пока остаётся только в инструментах — без них язык почти что бесполезен для крупных проектов (IMHO). Текущий уровень уже позволяет начинать использовать Scala для небольших модулей.
Кстати, в основном, почему у меня возник этот вопрос -- документация и инструменты, а в целом, поддержка. То есть, как я вижу, стоит сегодня Scala рассматривать как:
— разминку для мозга;
— после разминки инстумент для замещения *некоторых* текущих работ и модулей на Java.
А вообще интересно, есть ли на ней крупные проекты? Так, уже ради моего, чисто личного интереса?
