Ну это как на машине. Заявлено что есть отсечка, т.е. как бы на педаль не давил, больше 8000 не раскрутишь движок, но есть кнопка которую водитель может нажать и раскрутить движок пока он не накроется.
С одной стороны заявлено что есть отсчека, а с другой стороны есть шанс увидеть «руку друга».

Я всё-таки не понимаю, в каком месте эти три возможности языка противоречат друг другу. В .NET всё это есть (только аннотации там называются атрибутами) и вполне сосуществует.

В C# в документации так и написано что использование нетипизированных переменных не безопасно, но ... бла-бла-бла.

долгострой не нужен

Я обычно толерантно отношусь ко всяким недосверх языкам,
Scala определенно нужен для того, что бы доказать что и на приличном функциональном языке, те кто не смогли ничего путного написать на java, тоже ничего не напишут.
Groovy тоже нужен как кросплатформенная замена startup скриптов для приложений типа tomcat(те кто видел шэл крипт для запуска tomcat меня поймут)/activemq/jboss и т.д.

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

Лучше прочитайте хоть раз Java Puzzlers, после этой книги обычно хотелок новых фич от языка становиться меньше.

Я вам про Фому, вы мне про Ерёму.

Ну что не понятного?

очередная версия Ceylon - языка программирования со статической типизацией

т.е. у нас фича «Отсечка».
Но!

Типизация параметров на этапе выполнения

т.е. можем отсечку отключить. Да еще

Аннотации, определённые пользователем.

т.е. мы можем напридумывать свои правила «отсечки»

Заявлено что машина супер-пупер защищена от неправильных действий водилы, но водила может всю защиту отключить и поломать что угодно.

одной из главных причин того, что Scala не пошла на .NET

http://lampwww.epfl.ch/~magarcia/ScalaNET/

«Partial erasure» на смену «Type erasure»?

Там можно объявить IEnumerable и IEnumerable<T>. Это будут два разных типа.

Потому что это два разных интерфейса - один System.Collections.IEnumerable а второй System.Collections.Generic.IEnumerable. А на уровне компиляции тебе ничто не мешает эрейзить типы до object в дотнете - получиться та же джава. Вот в обратную сторону хуже - jvm checkcast плюет на генерики.

уже не существует параметрических типов во время загрузки байт-кода Java и его исполнения.

Они существуют: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/reflect/ParameterizedT...

Просто checkcast/instanceof на них плевать. Единственно такой информации не усществует на уровне праметра инстанциирования - поэтому скала например обходит это ограничение манифестами. Небольшие изменения вполне решают проблему. Просто ее не решили в jvm изначально чтобы все сторонние либы не навернулись с ClassCastException. Имхо лучше бы решили ее как в дотнете с их двумя разными типами и все.

Type erasure в .NET и нет

«пока хватает Common Type System» тут подскажет ехидный голос из зала.

Потому что это два разных интерфейса - один System.Collections.IEnumerable а второй System.Collections.Generic.IEnumerable. А на уровне компиляции тебе ничто не мешает эрейзить типы до object в дотнете - получиться та же джава. Вот в обратную сторону хуже - jvm checkcast плюет на генерики.

Типы, различающиеся параметрами, могут находится и в одном пространстве:

> type MyClass () =
-   member x.Name = "MyClass";;

type MyClass =
  class
    new : unit -> MyClass
    member Name : string
  end

> type MyClass<'a> () =
-   member x.Name = "MyClass<'a>";;

type MyClass<'a> =
  class
    new : unit -> MyClass<'a>
    member Name : string
  end

> (MyClass ()).Name;;
val it : string = "MyClass"

> (MyClass<int> ()).Name;;
val it : string = "MyClass<'a>"

Возвращаясь к Scala, проблему вижу в интероперабельности Scala и C#. Думаю, что будет хуже, чем в случае Scala - Java, или язык Scala придется изменить (твою ссылку особо не смотрел, но похоже, что они там именно язык Scala поменяли).

Имхо лучше бы решили ее как в дотнете с их двумя разными типами и все.

В .NET нет вариантности уровня Scala. Что-то частичное добавили в четвертой версии, но этого мало.

Вообще, у меня такое чувство, что генерики Scala - это переработка идеи явовских генериков, второе поколение. По-моему именно Одерский стоял у истоков явовских генериков (точно не помню). В .NET немного другая модель, и там делали другие люди (Дон Сайм - автор F#).

Типы, различающиеся параметрами, могут находится и в одном пространстве:

Дело не в пространствах имен, а что это разные классы. В java List и List<Int> один и тот же класс - List<T>.

Думаю, что будет хуже, чем в случае Scala - Java

В первой реализации Scala.NET наличествует type erasure. Причина - сохранение одинаковой семантики со Scala JVM, и второе - так быстрее выпустить. Но нарушается интероперабельность с .NET. Например в Java фигурально выражаясь работать будет:

scalacode.newJavaList<String>() instanceof java.util.List<?> == true

Аналогичный код C# вернет противоположное:

scalacode.newNETList<String>() is List<String> == false

Потому что скала типы эрейзнула для .NET а C# нет.

Так я примерно об этом и пишу (по обоим пунктам).

Вообще, у меня такое чувство, что генерики Scala - это переработка идеи явовских генериков, второе поколение.

Не совсем. Несмотря на то что компилер генериков для java разрабатывал Одерский - он просто на этом деле специализируется. В скале есть higher-kinded generics:

[code=scala]
scala> class A[X, L[X]](v:L[X]) { def get:L[X] = v }
defined class A

scala> class B[A]
defined class B

scala> class C[A]
defined class C

scala> class D
defined class D

scala> new A[String, B](new B[String]).get
res6: B[String] = B@70d11f32

scala> new A[String, C](new C[String]).get
res7: C[String] = C@5552e7a4

scala> new A[String, D](new D).get
<console>:10: error: D takes no type parameters, expected: one
new A[String, D](new D).get

[/code]

В C# такого не напишешь.

Да, про higher-kinded generics я так же считал. В .NET этого тоже нет (надо бы как-нибудь разобраться с этими higher-kind, а то ума пока не приложу, где они мне могут пригодиться).

Собственно, повторю свой прошлый тезис, что более примитивная система генериков Java (и, соответственно то, как это поддерживается на уровне JVM) оказалась удобнее для Scala, чем чуть-чуть более навороченная система из .NET. Похоже на парадокс :)

а то ума пока не приложу, где они мне могут пригодиться).

trait Container[E, C[x]] { def map[E2](f:E => E2) : C[E2] }

class Lst[E] extends Container[E, Lst] { def map[E2](f:E => E2) = new Lst[E2] }

class Sset[E] extends Container[E, Sset] { def map[E2](f:E => E2) = new Sset[E2] }

scala> new Lst[String].map(x => x)
res13: Lst[String] = Lst@78e782a8

scala> new Sset[String].map(x => x)
res14: Sset[String] = Sset@7de4605c

Обрати внимание на статические типы результатов функции map.

Спасибо за пример. С первого раза вникнуть не удалось :)