Re[14]: Ваше отношение к языку Scala - Java

Здравствуйте, mkizub, немного не понял претензий:

M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
M>площать в метрах квадратных.
Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что

Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.

Утверждение правильное, но Скала этого и не нарушает.
M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
Эээ... Объекты делаются из анонимных функций, это, наверное, следствие ограничений виртуальной машини. А вот про методы такого не слышал

M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Можно и без видов программировать, ничего особенного в них нет...

<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Ayreon — The Dream Sequencer

Здравствуйте, mkizub, Вы писали:

C>>А как твой Kiev поживает, кстати?

M>http://www.symade.org
У вас там на первой странице опечатка.
SymADE is an open-source project developed under CPL (Common Piblic Licence).

Здравствуйте, Аноним, Вы писали:

А>У вас там на первой странице опечатка.
А>SymADE is an open-source project developed under CPL (Common Piblic Licence).

Спасибо, поправил.

Здравствуйте, Gajdalager, Вы писали:

G>Здравствуйте, mkizub, немного не понял претензий:

G>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что
G>

G>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.

G>Утверждение правильное, но Скала этого и не нарушает.
Скала, к сожалению, не даст так просто сделать mixin из разных интерфейсов. Будет ругаться на несовместимость типов:

trait KiloSizes { 
   trait kg; 
   def getSize():kg = new kg {val v=1} 
}

trait ItemSizes { 
   trait sht;
   def getSize():sht = new sht {val v=2} 
}

trait AllSizes extends KiloSizes with ItemSizes {}

<console>:6: error: error overriding method getSize in trait KiloSizes of type ()AllSizes.this.kg;
 method getSize in trait ItemSizes of type ()AllSizes.this.sht needs `override' modifier
trait AllSizes extends KiloSizes with ItemSizes {}
^

trait AllSizes extends KiloSizes with ItemSizes { 
   override def getSize: kg = super[KiloSizes].getSize() 
}

:6: error: error overriding method getSize in trait ItemSizes of type ()AllSizes.this.sht;
 method getSize has incompatible type ()AllSizes.this.kg
trait AllSizes extends KiloSizes with ItemSizes { override def getSize: kg = super[KiloSizes].getSize() }
                                                           ^

trait AllSizes extends KiloSizes with ItemSizes { 
    override def getSize: kg = super[KiloSizes].getSize(); 
    override def getSize: sht = super[ItemSizes].getSize 
}

:6: error: method getSize is defined twice
trait AllSizes extends KiloSizes with ItemSizes { 
    override def getSize: kg = super[KiloSizes].getSize(); 
    override def getSize: sht = super[ItemSizes].getSize 
}

Здравствуйте, Gajdalager, Вы писали:

G>Здравствуйте, mkizub, немного не понял претензий:

M>>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
M>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
M>>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
M>>площать в метрах квадратных.
G>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что
G>

G>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.

G>Утверждение правильное, но Скала этого и не нарушает.

Что значит не нарушает?! Разве это не скомпилируется?

object test {
trait KiloSize {
def getSize() : int;
}
trait ItemSize {
def getSize() : int;
}
def getSize() : int = 10;
def main(args: Array[String]) : unit =
{
test.asInstanceOf[KiloSize].getSize();
test.asInstanceOf[ItemSize].getSize();
}
}

разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Gajdalager, Вы писали:

G>>Здравствуйте, mkizub, немного не понял претензий:

M>>>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
M>>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
M>>>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
M>>>площать в метрах квадратных.
G>>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что
G>>

G>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.

G>>Утверждение правильное, но Скала этого и не нарушает.

M>Что значит не нарушает?! Разве это не скомпилируется?

M>object test {
M> trait KiloSize {
M> def getSize() : int;
M> }
M> trait ItemSize {
M> def getSize() : int;
M> }
M> def getSize() : int = 10;
M> def main(args: Array[String]) : unit =
M> {
M> test.asInstanceOf[KiloSize].getSize();
M> test.asInstanceOf[ItemSize].getSize();
M> }
M>}

M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.

Упс. Вопрос снят. Просто Scala не проконтролировала, что test как singleton тип не может быть
унаследован никаким новым типом, и следовательно надо выдавать ошибку компиляции на asInstanceOf[KiloSize]
В рантайме оно прекрасно выдала ошибку кастинга.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Gajdalager, Вы писали:

M>Что значит не нарушает?! Разве это не скомпилируется?

M>object test {
M> trait KiloSize {
M> def getSize() : int;
M> }
M> trait ItemSize {
M> def getSize() : int;
M> }
M> def getSize() : int = 10;
M> def main(args: Array[String]) : unit =
M> {
M> test.asInstanceOf[KiloSize].getSize();
M> test.asInstanceOf[ItemSize].getSize();
M> }
M>}

M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.
Угу... А запускать пробовал?

C:\Program Files\scala\bin>scala test
java.lang.ClassCastException: test$
        at test$.main(Test.scala:11)
        at test.main(Test.scala)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:75)
        at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:106)
        at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

C:\Program Files\scala\bin>

Почти аналогичный код на Жаве:

public class TestJava
{
    public int getSize()
    {
        return 10;
    }
    public static void main(String[] args) {
        TestJava object = new TestJava();
        ((KiloSize)object).getSize();
        ((ItemSize)object).getSize();
    }
}

interface KiloSize
{
    public int getSize();
}

interface ItemSize
{
    public int getSize();
}

Exception in thread "main" java.lang.ClassCastException: TestJava
    at TestJava.main(TestJava.java:42)

<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Ayreon — Out Of The White Hole

Здравствуйте, mkizub, Вы писали:

M>Что значит не нарушает?! Разве это не скомпилируется?
Конечно, ведь ты используешь явное приведение. Это аналогично void *p; (MyClass *)p->upps.

M> test.asInstanceOf[KiloSize].getSize();
M> test.asInstanceOf[ItemSize].getSize();

M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.
Извини, но это ерунда какая-то. При чем тут вообще килограммы и штуки, если объект test всего лишь декларирует трейты,
но не имеет к ним никакого отношения (разве что как outer). Я често вообще не понял, чего ты вообще хотел добиться этим кодом, эмулировать питон? scala вообще-то строго и статически типизированный язык с выводом типов...

Правильнее было бы (правда это уже не python-like, но уже и не грубое приведение типа непонятно к чему):

object test {
   trait KiloSize {
      def getSize() : int;
   }

   trait ItemSize {
      def getSize() : int;
   }

   def getSize() : int = 10;

   def sz[T](a: => T) = a match {
      case k: KiloSize => k.getSize()
      case i: ItemSize => i.getSize()
      case t: test.this.type => t.getSize()
      case _ => throw new Error("What is this?")
   }

   def main(args: Array[String]) = {
     println(sz(this))
     println(sz(new KiloSize { override def getSize(): int = 20 }))
     println(sz(new ItemSize { override def getSize(): int = 30 }))
     println(sz(1))
   }
}

 scala -cp target test             
10
20
30
java.lang.Error: What is this?
        at test$.sz(methods.scala:26)
        at test$.main(methods.scala:33)
...

Здравствуйте, aka50, Вы писали:

A>Правильнее было бы (правда это уже не python-like, но уже и не грубое приведение типа непонятно к чему):
А если еще подумать, то можно вообще вот так

object test {
  
  trait WithSize {
    val getSize: ()=> int
  }
  
  trait KiloSize {
      def kilos() : int;
  }

  trait ItemSize {
     def items() : int;
  }

  class KiloEntity extends WithSize {

    val getSize = mySize.kilos _
    val mySize = new KiloSize { override def kilos() = 1 }
  }

  class ItemEntity extends WithSize {

    val getSize = myItems.items _
    val myItems = new ItemSize { override def items() = 2 }
  }
  
  def size(sizeable: WithSize) {
    println(sizeable.getSize())
  }

  def main(args: Array[String]) = {
     val k = new KiloEntity
     size(k)
     val i = new ItemEntity
     size(i)
  }
}

Здравствуйте, mkizub, Вы писали:

VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
M>Несогласие с базовой концепцией, тормознутость.

А можно пояснить в чем заключается несогласие?

M>Встречный вопрос. А зачем вам этот опрос?

Скала очень перспективный язык, но нужен ли он ява-комьюнити? И если не нужен, то очень интересует аргументация.

Здравствуйте, mkizub, Вы писали:

M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
M>площать в метрах квадратных.

Возможно. Не знаю...

M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.

100% заблуждаешся. К тому же объекты скорее всго делаются не из методов, а из замыканий. Их по другому сделать очень не просто.

M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.

В чем тут оверхэд? К тому же вроде бы от view отказались в новой верси. Или я что-то путую?

M>Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка.
M>В C++ выбрали полную обратную совместимость с С,

Не полную, а приемлемую.

M> и принцип — пока ты фичу не пользуешь, она не должна
M>давать оверхеда в твоём коде.

Пока ты не используешь замыкания ты точно так же не получашь оверхэд. Да и оверхэд там минимльный. Так что все тоже самое.
Да и гулпо сравнивать Скалу с С++. С++ дпотопный язык, с морем граблей и без автоматического управления памятью. Писать на нем во много аз сложнее чем даже на Яве. Со Скалой его вообще сравнивать нельзя. Это как сравнивать телегу с вездеходом.

Мнея интересует сравнение с Явой. Потому на этом форуме и задал ворос. Понятно, что Ява в следствии дизайна имеет некоторый оверхэд по сравнению с С/С++, но все же он приемлем для многих применений. Скала вроде бы не сильно его увеличивает. Или я ошибаюсь?

M> Это привело к тому, что С++ скоро сдохнет, вытесненный конкурентами,

Думаю, нас он переживет.

M>которые себе такой груз на спину не взвалили. В яве сделали выбор в пользу параноидальной защищённости
M>и верифицируемости кода всегда. Получили тормоз, даже когда исполняется trusted приложение, даже
M>если оно пытается переложить работу на нэйтив код — всё равно тормоз. И так далее.

Спор по поводу скорости Явы меня не интересует. Меня интересует сравнение с Явой (языком).

Здравствуйте, aka50, Вы писали:

A>Правда в рассылке недавно активно обсуждали синтаксис макросов, но пока не понятно, что же все таки решили... Небольшое описание создания DSL на scala можно тут почитать: http://phoenix.labri.fr/DSPD/final/dubochet2006zytyg.pdf

Прикольно. Если дело пойдет так и дальше, то Скала и Немрле будут почти близнецами

Здравствуйте, Cyberax, Вы писали:

M>>Встречный вопрос. А зачем вам этот опрос?
C>Товарищ VladD2 — фанат другого нераспространенного, но крутого языка

Одно уточнение. Я не фанат, я просто отлично разбираюсь в колбасных обрезках и не привык быть себе врагом

Здравствуйте, mkizub, Вы писали:

M>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании
M>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
M>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка.
M>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.

Можно по подробнее? В чем проблема? В чем решение?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mkizub, Вы писали:

M>>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании
M>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
M>>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка.
M>>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.

VD>Можно по подробнее? В чем проблема? В чем решение?

http://www.rsdn.ru/Forum/message/2520182.aspx
http://www.symade.org/
http://www.symade.com/

Здравствуйте, mkizub, Вы писали:

M>http://www.rsdn.ru/Forum/message/2520182.aspx
Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mkizub, Вы писали:

VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
M>>Несогласие с базовой концепцией, тормознутость.

VD>А можно пояснить в чем заключается несогласие?

Наличие решений сделанных дизайнерами языка. Сам факт их наличия.

M>>Встречный вопрос. А зачем вам этот опрос?

VD>Скала очень перспективный язык, но нужен ли он ява-комьюнити? И если не нужен, то очень интересует аргументация.

Я бы сказал — он очень хороший язык. Но не перспективный. Это общая закономерность — в конце развития
технологии появляются наиболее яркие и соверненные её проявления.
Что до Scala для явы — то это не очень интересно, потому как Scala пытается впихнуть в яву невпихуемое.
Scala намного лучше будет выглядеть на .NET или LLVM, а на яве это будет сплошная борьба с JVM.

Здравствуйте, VladD2, Вы писали:

VD>Да и гулпо сравнивать Скалу с С++. С++ дпотопный язык, с морем граблей и без автоматического управления памятью. Писать на нем во много аз сложнее чем даже на Яве. Со Скалой его вообще сравнивать нельзя. Это как сравнивать телегу с вездеходом.

VD>Мнея интересует сравнение с Явой. Потому на этом форуме и задал ворос. Понятно, что Ява в следствии дизайна имеет некоторый оверхэд по сравнению с С/С++, но все же он приемлем для многих применений. Скала вроде бы не сильно его увеличивает. Или я ошибаюсь?

Я не сравниваю Scala с С++.
Я пишу о том, что разработчик языка делает выбор, исходя из своих собственных представлений о том, как правильно, хорошо, как надо.
И потом про это книжки пишет, почему я выбрал так, а не иначе.
А загогулина в том, что автор другого языка сделал прямо противоположный выбор, и тоже правильный, тоже обоснованный.
Тоже книжки пишет, почему его выбор правильный.

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

Здравствуйте, mkizub, Вы писали:

M>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
Может тогда стоит глянуть на lisp и не изобретать лисапед?

Здравствуйте, aka50, Вы писали:

M>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
A>Может тогда стоит глянуть на lisp и не изобретать лисапед?

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

Собственно, лисп и надо брать за начальную точку расширяемого языка. Только убрать текст.
Dylan часто обзывают лиспом с удобным синтаксисом. Всё равно не получил распространения,
хотя, скорее, по историческим причинам (apple финансировала, а потом забила на него).
Ну и производительность тоже была гвоздём в гроб как Lisp-а так и Dylan-а и прочих.

	От:	Gajdalager
	Дата:	07.06.07 08:07
	Оценка:

	От:	Аноним
	Дата:	07.06.07 08:13
	Оценка:

От:	mkizub	http://symade.tigris.org
Дата:	07.06.07 10:04
Оценка:

	От:	aka50
	Дата:	07.06.07 10:49
	Оценка:

От:	mkizub	http://symade.tigris.org
Дата:	07.06.07 11:03
Оценка:

От:	VladD2	www.nemerle.org
Дата:	08.06.07 21:20
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	09.06.07 07:39
Оценка:	+1