Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
Вопросы, собственно, прсоты:
1. Знаете ли вы что такое Scala?
2. Если знаете, то как к ней относетесь?
3. Не думаете ли вы применить Scala-у в своих разработках?
4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Знаете ли вы что такое Scala?
Играюсь уже несколько месяцев. VD>2. Если знаете, то как к ней относетесь?
В принципе понравилась, но не дай Бог она и дальше будет засахариваться различными
оторванными от жизни ФП фичами, тогда можно будет сразу в морг (причины см. ниже).Там есть приятные моменты, но ее главное достоинство (для меня на данный момент) — простота встраивания в java приложение и возможность использовать уже написанные на java библиотеки. По сути ее эквивалентность java в данном вопросе, хотя вызов некоротрых вещей написанных на scala из явы занятие не для слабонервных — посмотрите как называются классы эмулируеющие функции, так что если планируется использовать библиотеку написанную на scala из java — лучше сразу отказаться от всяких извращений (или во всяком случае спрятать их внутри), есть серьезное
подозрения в этом случае также лучше отказаться от коллекций scala. Пока на мой взгляд
ее можно применять или отдельно или для скриптинга ява приложений (сразу оговорюсь что насчет скорости ничего сказать не могу (хэллоу ворлд на двухядернеке не тормозит . VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Думаю — в качестве замены xslt+расширения на яве (выглядит страшно), там возможно не сложней будет обработка xml, но зато никаких проблем с расширениями. VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
В порядке убыванию важности:
1. Будует ли она полноценной заменой xslt? Я видел их документацию, но как обычно бывает
в самый последний чего-то начинает не хватать, вообщем пока не попробуешь не узнаешь...
2. Отсутвие нормальной литератруры (ScalaByExmaple и пр. не в счет), некоторые вещи просто
вгоняют в ступор, например пытался написать небольшей пример — обертку над JDBC — банальный класс DataBase (open,close,commit,rollback,executeFor[A] и т.д.), так вот с удивлением обнаружил что String и int приводяться к java.lang.Object, а double, boolean — нет (через asInsntaceOf) — получается банальная ошибка компиляции типа found/required. Возможно для авторов это все очевидно, но не все такие умные..
3. Отсутсвие поддержки со стороны используемой IDE (Netbeans), я конечно понимаю что реальные пацаны пишут в vim, ну так они и дальше могут продолжать пЫсать. Даже если это
поддержка будет, непонятно как отлаживать код исполняемый встроенной скалой (если он не соотвествует по структуре проекту IDE).
4. Субъектвные:
a)Отсутвие документации на русском, читать англоязычную как-то насобачился еще когда осваивал яву, но времени и сил на это уходит больше. Щас пришел к тому что если выбор — читать эписталярный шедевр на аглицком или смотреть исходники с примерами (с комментариями из трех слов ) — выбираю второе.
b)Отсутвие времени на работе — проект с xslt уже подходит к стадии беты и попытки развернуть его щас ни к чему хорошему не приведут.
c)Отсутвие времени дома — скажем спасибо нашем высшему образованию (скорей бы что ли оно загнулось, по крайней в сегодняшнем виде от него нет никакого толку, просьба госудраственников не кидаться помидорами — хотели субъективное — получите!)
d)Лень.
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala?
С около года наверное уже в ней ковыряюсь (последнее время особенно плотно)... Уже начал иногда понимать код VD>2. Если знаете, то как к ней относетесь?
Очень положительно. При определенных недостатках в целом внятный язык. Плюсы по мере важности
1. Вывод типов
2. Функции как объекты и "функциональность" вообще (т.е. scala-library в функциональном стиле)
3. Расширяемый синтаксис (scala-dbc как пример)
4. Встороенная поддержка xml (хотя возможно и не стоило ее внедрять в язык, ибо если посмотреть _как_ работает парсер чтобы разобрать xml это или scala код, то у меня кроме как "хак" других слов нет)
VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Пока рассматриваю как замену ibatis и xml/xslt процессорам и dao слой. Возможно где-то (в "домашних" проектиках) буду использовать как движек бизнес-логики. Еще внимательно слежу за liftweb. Интересна поддержка cldc и актеров адаптируют под cldc. Т.е. вполне возможно, что в некоторых местах можно получить что-то аналогичное erlang актерам на embedded платформах, но без необходимости тащить erlang vm.
VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
На данный момент останавливающим фактором являются (по мере убывания):
1. Остуствие поддержки в Idea. (та что есть — под 7-ку и с моей точки зрения не правильная, ибо использует свой parser/lexer вместо использования возможностей компилятора, как сделано в eclipse плагине). Маленьким проектам и мне лично это не критично, но вот для большого проекта — это проблема.
2. Мало документации "для чайников". Сейчас все приходится либо экспериментально либо из высоконаучных работ выковыривать. Но надо отметить, в списках рассылки сложные случаи объясняют без проблем. Но факт — отсутствие такой документации останавливает внедрение. (Одерски пишет книгу, но когда она точно будет — не известно)
3. Часто меняющийся синтаксис. Т.е. конечно хорошо, что старый все еще продолжает работать (хотя и не весь, например синтаксис кортежей не совместим), но немного напрягает. Ну и сам компилятор еще недостаточно stable. Приходится сидеть на current. Хотя я понимаю, что у любого растущего проекта — это нормально.
4. Сложная система типов. (это и хорошо и плохо, но чтобы их использовать нужно очень хорошо понимать как они работают)
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, VladD2, Вы писали:
__>так вот с удивлением обнаружил что String и int приводяться к java.lang.Object, а double, boolean — нет (через asInsntaceOf) — получается банальная ошибка компиляции типа found/required. Возможно для авторов это все очевидно, но не все такие умные..
Хорошо возможно это я ступил, тогда подскажите мне как можно например сделать что-то такое
import java.sql._;
class DataBase
{
....
def executeFor[A](_sql: String): A =
{
......
A macth
{
case ..... => r.getString(1).asInstanceOf[A];
case ..... => r.getInt(1).asInstanceOf[A];
};
......
}
....
};
Не компилируется...
Какой вообще формат у case можеть быть в различных случаях? Я видел: case x: String, case </element> и др. Но общей сути так и не понял. В ScalaReferences написано что-то типа case e1 => p1 — ну и что такое e1, и каким оно может быть в разных ситуациях?
Поэтому я указал среди основных претензии отсуствие нормальной литературы...
Здравствуйте, aka50, Вы писали:
A>1. Остуствие поддержки в Idea. (та что есть — под 7-ку и с моей точки зрения не правильная, ибо использует свой parser/lexer вместо использования возможностей компилятора, как сделано в eclipse плагине). Маленьким проектам и мне лично это не критично, но вот для большого проекта — это проблема.
Или посмотреть как это реализованно в scala-dbc. Там запросы имеют вид
select (
"age" is smallint,
"name" is clob,
"salary" is int )
from ("persons" naturalJoin "employees")
where (
"gender" == "M" and
("city" == "lausanne" or "city" == "geneva"))
orderBy "age"
Вариант, приведенный тобой работать не будет, т.к. информация о типе стирается, а значит в рантайме A грубо говоря AnyRef (аналог Object)
__>Какой вообще формат у case можеть быть в различных случаях? Я видел: case x: String, case </element> и др. Но общей сути так и не понял. В ScalaReferences написано что-то типа case e1 => p1 — ну и что такое e1, и каким оно может быть в разных ситуациях?
case может иметь несколько видов (при чем части выражения, например vc или v могут опускаться, если нет необходимости работать с сами заматченым объектом, а например только с параметрами ca1, ca2)
case vc: CaseClass(ca1, ca2) — где параметры конструктора исползовавшиеся при конструировании case классов (специальный вид классов)
case v: ClassName — фактически оптимизированный instanceOf с последующим преведением и присвоением val v = matchVal.asInstanceOf[ClassName]
scala> class U(val v: int) {}
scala> val m=new U(1)
m: U = U@5a936b
scala> m match { case l: U => println("" + l + " " + m) }
line6$object$$iw$$iw$U@5a936b line6$object$$iw$$iw$U@5a936b
Есть еще конструкции с экстраторами и анонимными фукнциями.
Но основное надо помнить: информации о типах нет (erasure как в java) по этому весь match работает только над объектами и константами.
Здравствуйте, aka50, Вы писали:
A>Или посмотреть как это реализованно в scala-dbc. Там запросы имеют вид A>
A>select (
A> "age" is smallint,
A> "name" is clob,
A> "salary" is int )
A>from ("persons" naturalJoin "employees")
A>where (
A> "gender" == "M" and
A> ("city" == "lausanne" or "city" == "geneva"))
A>orderBy "age"
A>
Интересно, надо будет посмотреть исходники. А насколько реально построить на scala собственный мини DSL? А с учетом
того что скала еще и в яву встраивается можно будет пракически нахаляву получить движок для бизнес правил. Блин, ручки уже начинают чесаться...
Здравствуйте, mini_root_2, Вы писали:
__>Интересно, надо будет посмотреть исходники. А насколько реально построить на scala собственный мини DSL? А с учетом __>того что скала еще и в яву встраивается можно будет пракически нахаляву получить движок для бизнес правил. Блин, ручки уже начинают чесаться...
Конечно не все так радужно (т.е. до макросов далековато), но в целом жить можно. Правда в рассылке недавно активно обсуждали синтаксис макросов, но пока не понятно, что же все таки решили... Небольшое описание создания DSL на scala можно тут почитать: http://phoenix.labri.fr/DSPD/final/dubochet2006zytyg.pdf
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala?
Да VD>2. Если знаете, то как к ней относетесь?
Положительно — лучше пусть будет, чем не будет — от меня не убудет VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Нет VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Несогласие с базовой концепцией, тормознутость.
Здравствуйте, mkizub, Вы писали:
VD>>3. Не думаете ли вы применить Scala-у в своих разработках? M>Нет
И не удивительно VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>Несогласие с базовой концепцией, тормознутость.
Тормознутость компилятора или получаемого кода?
Здравствуйте, aka50, Вы писали:
VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>Несогласие с базовой концепцией, тормознутость. A>Тормознутость компилятора или получаемого кода?
У меня не было достаточно больших проектов, чтоб оценить степень тормознутости компилятора.
Кода, конечно.
Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно.
Конечно, для определённой ниши приложений (серверных) скорости Scala хватит с головой.
Но поскольку у меня есть решения получше (где надо удобно — там пусть будут тормоза, где надо быстро — там
будет без накладных расходов), то решения разработчиков Scala меня лишь удручают. Как я написал Мартину —
yet another good language.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
VD>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>Несогласие с базовой концепцией, тормознутость. M>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>[skip] решения разработчиков Scala меня лишь удручают.
Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
M>Как я написал Мартину — yet another good language.
А можно ссылочку, где это обсуждалось (если конечно это в рассылке есть)?
Здравствуйте, aka50, Вы писали:
VD>>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>>Несогласие с базовой концепцией, тормознутость. M>>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>>[skip] решения разработчиков Scala меня лишь удручают. A>Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
площать в метрах квадратных.
2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка.
В C++ выбрали полную обратную совместимость с С, и принцип — пока ты фичу не пользуешь, она не должна
давать оверхеда в твоём коде. Это привело к тому, что С++ скоро сдохнет, вытесненный конкурентами,
которые себе такой груз на спину не взвалили. В яве сделали выбор в пользу параноидальной защищённости
и верифицируемости кода всегда. Получили тормоз, даже когда исполняется trusted приложение, даже
если оно пытается переложить работу на нэйтив код — всё равно тормоз. И так далее.
Создатели языков вынуждены делать этот выбор, и всегда найдутся проекты, в которых именно этот
выбор станет ножом в сердце. А я знаю, как создать среду для разработки и исполнения программ, где
этот выбор будут делать не создатели языка, а архитектор данного конкретного проекта. Об этом я Мартину
и написал, и обозвал Scala "ещё одним", пусть хорошим, но банальным языком программирования.
M>>Как я написал Мартину — yet another good language. A>А можно ссылочку, где это обсуждалось (если конечно это в рассылке есть)?
Это было личное письмо, простой e-mail. И он на него не ответил, может даже просто в спам упало.
Здравствуйте, mkizub, Вы писали:
VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>Несогласие с базовой концепцией, тормознутость.
А как твой Kiev поживает, кстати?
M>Встречный вопрос. А зачем вам этот опрос?
Товарищ VladD2 — фанат другого нераспространенного, но крутого языка
Здравствуйте, Cyberax, Вы писали:
VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>Несогласие с базовой концепцией, тормознутость. C>А как твой Kiev поживает, кстати?
http://www.symade.org
Сегодня статью про него послал на RSDN, скоро, наверное, напечатают.
M>>Встречный вопрос. А зачем вам этот опрос? C>Товарищ VladD2 — фанат другого нераспространенного, но крутого языка
Nemerle?
Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании
дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка.
Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
Здравствуйте, mkizub, Вы писали:
C>>А как твой Kiev поживает, кстати? M>http://www.symade.org M>Сегодня статью про него послал на RSDN, скоро, наверное, напечатают.
M>>>Встречный вопрос. А зачем вам этот опрос? C>>Товарищ VladD2 — фанат другого нераспространенного, но крутого языка M>Nemerle?
Да.
M>Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
Текст — очень удобная форма представления дерева. Нужно просто действия над текстом переводить в действия над деревом — та же IDEA так и делает.
Здравствуйте, Cyberax, Вы писали:
M>>Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. C>Текст — очень удобная форма представления дерева. Нужно просто действия над текстом переводить в действия над деревом — та же IDEA так и делает.
C>Так что тут несогласен.
Мы, видимо, о разном говорим. Вот напечатают статью и будет ветка обсуждения — там обсудим.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
VD>>>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>>>Несогласие с базовой концепцией, тормознутость. M>>>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>>>[skip] решения разработчиков Scala меня лишь удручают. A>>Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
Тип (наиболее близок к typeclass): набор сигнатур и констант которые должны быть в классах данного типа.
А что по твоему должно быть типом? (не забывай еще, что нужно поддерживать раздельную компиляцию).
M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>площать в метрах квадратных.
Это сделано из соображений совместимости с jvm. И собственно, а что это будет за объект, который имеет size сразу и в kg и в sqm (при чем не преобразуемых, т.к. методы разных сущностей)?
M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
Это ты о чем? Методы как методы, только когда мы хотим передать метод куда-то, тогда да, рожается объект... Ну и анонимные функции тоже превращаются в объекты.
object test {
class A {
def myMethod() = println("hello")
def myAnotherMethod() = println("hello")
}
class B(a: A) {
def myTest() = (1 :: 2 :: Nil) map (_ + 1)
def mySuper() = a.myAnotherMethod _
}
}
target
|-- test$.class
|-- test$A.class
|-- test$B$$anonfun$0.class
|-- test$B$$anonfun$1.class
|-- test$B.class
`-- test.class
$ javap test\$A
Compiled from "methods.scala"
public class test$A extends java.lang.Object implements scala.ScalaObject{
public test$A();
public void myAnotherMethod();
public void myMethod();
public int $tag();
}
$ javap test\$B
Compiled from "methods.scala"
public class test$B extends java.lang.Object implements scala.ScalaObject{
public final test$A test$B$$a;
public test$B(test$A);
public scala.Function0 mySuper();
public scala.List myTest();
public int $tag();
}
$ javap test\$B\$\$anonfun\$0
Compiled from "methods.scala"
public final class test$B$$anonfun$0 extends java.lang.Object implements scala.Function1,scala.ScalaObject,java.io.Serializable{
public test$B $outer;
public test$B$$anonfun$0(test$B);
public final java.lang.Object apply(java.lang.Object);
public test$B test$B$$anonfun$$$outer();
public final int apply(int);
public int $tag();
public scala.Function1 andThen(scala.Function1);
public scala.Function1 compose(scala.Function1);
public java.lang.String toString();
}
M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Не вижу оверхеда. Тот же код, что вынесен во view будет просто писаться руками. Учитывая, что view обычно разботают на границе компонент, это не страшно...
Ну и собственно "жуткий оверхед" — это сколько в цифрах? В java повсеместно используются анонимные классы и ничего... здесь фактически тоже самое...
M>Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка.
Не совсем. Scala — одна из задач, это совместимость с java. Отсюда и определенные ограничения.