> головная боль увеличится не менее, чем вдвое, когда для одних браузеров можно будет писать большое веб-приложение на Dart, а для других всё то же большое приложение придется второй раз написать на JavaScript
Так будет же кросс-компилятор из Dart в JS. Т.е. пишется только код на Dart а аналог на JS (для браузеров, не поддерживающих Dart нативно) автоматически генерируется.
Нет. Ну что Вы в самом деле. Я имею в виду, что надо развивать Dart как какой-нибудь libxml или libmysql, т.е. в виде библиотеки (а не плагина!), которые будут вкомпиливаться в браузеры.
> Именно по этой причине Erlang или Haskell никогда не будут повсеместно использоваться в промышленном программировании.
Тут бы поспорил. Тот же Erlang сейчас очень мощно начинает использоваться именно в практических проектах. Вспомнить тот же erlyvideo или один из самых навороченных jabber серверов ejabberd.
> Зачем ещё один язык, которые везде поддерживается частично?
Помечтаем. А что, собственно, мешает тому, чтобы развивать сей язык в качестве опенсорс библиотеки и линковать его во все возможные браузеры? Пожалуй, только политика больших компаний, которые все хотят иметь «своё», для обеспечения того, что называют vendor lock-in.
Там описана известная история того, как MS захотев изменять яву по своему разумению (что было запрещено лицензией Sun) в конечном итоге была вынуждена создавать с нуля почти идентичный (по концепциям) язык.
Хорошо это или плохо, судить сложно. Но из плохого — то, что по сути две весьма похожие технологии развиваются параллельно с довольно слабой способностью к переиспользованию (например, библиотек). Если бы это было в рамках одной платформы, прогресс и разработка, вероятно, шли бы быстрее.
> В джаве же Т я должен указывать в объявлении класса.
?
public class C {
public static void main(String[] args) {
someMethod(123, 456);
someMethod(new Object(), new Object());
someMethod("aaa", "bbb");
}
static <T> void someMethod(T a, T b) {
System.out.println("a=" + a + ", b=" + b);
}
}
Вывод:
a=123, b=456
a=java.lang.Object@fa3ac1, b=java.lang.Object@276af2
a=aaa, b=bbb
Во первых, как Ваш комментарий относится к моему? И во-вторых, то что Вы описали — лишь особенности реализации, которые прикладного программиста касаются в малой степени (лишь в той, где «это приводит к ряду ограничений», да и те ограничения не такие уж существенные).
> Смотрите мое предложение чуть ниже. или реализацию Int32 в C#
msdn.microsoft.com/en-us/library/system.int32.aspx, где (на мое удивление) используется тот же принцип, что и предложенный мной ниже
Что-то Вы опять ошибаетесь. По Вашей же ссылке нет и намёка на отдельные
Дело в том, что в природе существует не так много разных Number'ов. Самых основных можно пересчитать по пальцам: byte, double, float, int, long, short. Собственно это и есть список примитивных типов явы. Работая с числами, вы в 99,9% работаете в основном с этими 6ю типами. Вот почему дизайнеры JDK обязали все реализации Number (а их, на минуточку, есть не только в JDK но и в разных там commons.lang и др. библиотеках) реализовывать приведение к примитивным типам — для удобства конечных пользователей этих реализаций Number.
Если Вам, как программисту очередной реализации Number лень/не хочется реализовывать эти методы — просто не наследуйте Number, делов-то. Только, учтите, что тогда Ваши конечные пользователи не смогут пользоваться удобствами из JDK, скажем, java.text.NumberFormat / DateFormat /… или пакет commons.lang.math и ему подобные, понимающий любой Number именно за счет обязательной реализации этих методов.
> Класс Number изначально знает обо всех своих детях
Так можно сказать, что любой абстрактный класс знает о своих детях.
Класс Number обязывает любого кто осмелился его унаследовать реализовать методы конвертации этих самых наследников в стандартные типы явы (int, float, byte, etc...). По-моему весьма предусмотрительно, т.к. пользователи любых реализаций Number бесплатно получат удобство конвертации в эти типы, а не будет городить каждый раз своё преобразование.
>гораздо удобней было бы оперировать примитивами и иметь возможность присваивать им null значение. Если простой int занимает 4 байта, то обьект Integer уже целых 16.
Спасибо, не надо. Это только увеличит число NPE (NullPointerException). От этого наоборот стоит уходить. Скажем, меня удивляет, почему еще не добавили поддержку JSR-305 (@Nullable, @NonNull, ...) в компилятор.
И потом, Вы уверены, что если разрешить примитивным типам принимать null, то для int всё еще хватит 4 байта?
Так будет же кросс-компилятор из Dart в JS. Т.е. пишется только код на Dart а аналог на JS (для браузеров, не поддерживающих Dart нативно) автоматически генерируется.
Тут бы поспорил. Тот же Erlang сейчас очень мощно начинает использоваться именно в практических проектах. Вспомнить тот же erlyvideo или один из самых навороченных jabber серверов ejabberd.
habrahabr.ru/blogs/javascript/132698/#comment_4404597
а так же полностью запретить неявное приведение типов.
Увы, но в двух вышеприведенных случаях директива «use strict» бессильна =(.
Помечтаем. А что, собственно, мешает тому, чтобы развивать сей язык в качестве опенсорс библиотеки и линковать его во все возможные браузеры? Пожалуй, только политика больших компаний, которые все хотят иметь «своё», для обеспечения того, что называют vendor lock-in.
Ну вообще да, конкуренция, все такое.
Однако, недавно прочел статейку хорошую
pclt.cis.yale.edu/pclt/mscase/microsoft_java.htm
Там описана известная история того, как MS захотев изменять яву по своему разумению (что было запрещено лицензией Sun) в конечном итоге была вынуждена создавать с нуля почти идентичный (по концепциям) язык.
Хорошо это или плохо, судить сложно. Но из плохого — то, что по сути две весьма похожие технологии развиваются параллельно с довольно слабой способностью к переиспользованию (например, библиотек). Если бы это было в рамках одной платформы, прогресс и разработка, вероятно, шли бы быстрее.
Но всё, как обычно, решает высокая политика.
Ну вот, классы, например, хотели добавить в ECMAScript, да передумали.
И потом, добавлять не убавляя — не лучший вариант.
Согласитесь, питоновский слоган
There should be one-- and preferably only one --obvious way to do it.
весьма хорош и вне рамок питона.
Но добавляя новые возможности и не запрещая старые мы провоцируем нарушение этого принципа.
> Здесь выбрасывается NullPointerException и… теряется, исчезает без следа! Будьте бдительны.
Правильнее сказать не «Будьте бдительны» а "Ни в коем случае не используйте return или throw в finally блоке — это считается плохой практикой".
bit.ly/chaosconspiracy
bit.ly/rx8rrz
bit.ly/nanpfS
bit.ly/tvtkqn
> Тьюринг-полного механизма TEMPLATES
— недетерминированность времени компиляции.
Так портируемость же. Чем меньше написано на си — тем легче портировать.
?
public class C { public static void main(String[] args) { someMethod(123, 456); someMethod(new Object(), new Object()); someMethod("aaa", "bbb"); } static <T> void someMethod(T a, T b) { System.out.println("a=" + a + ", b=" + b); } } Вывод: a=123, b=456 a=java.lang.Object@fa3ac1, b=java.lang.Object@276af2 a=aaa, b=bbbmsdn.microsoft.com/en-us/library/system.int32.aspx, где (на мое удивление) используется тот же принцип, что и предложенный мной ниже
Что-то Вы опять ошибаетесь. По Вашей же ссылке нет и намёка на отдельные
> интерфейсы Float/Double/Imteger/etcExportable
Однако, если открыть документацию к интерфейсу IConvertible: msdn.microsoft.com/ru-ru/library/system.iconvertible.aspx мы увидим, что это та же идея что и в яве, только выделенная в отдельный интерфейс, который (о боже!)
> изначально знает обо всех своих детях объявляя у себя методы а-ля
ToBoolean
ToByte
ToChar
ToDateTime
ToDecimal
ToDouble
…
Обождите-ка. Как раз текущая реализация навязывает, да. А в Вашем варианте никто не мешает сделать без Ваших *Exportable
class Integer extends Number { ... }
и привет.
Дело в том, что в природе существует не так много разных Number'ов. Самых основных можно пересчитать по пальцам: byte, double, float, int, long, short. Собственно это и есть список примитивных типов явы. Работая с числами, вы в 99,9% работаете в основном с этими 6ю типами. Вот почему дизайнеры JDK обязали все реализации Number (а их, на минуточку, есть не только в JDK но и в разных там commons.lang и др. библиотеках) реализовывать приведение к примитивным типам — для удобства конечных пользователей этих реализаций Number.
Если Вам, как программисту очередной реализации Number лень/не хочется реализовывать эти методы — просто не наследуйте Number, делов-то. Только, учтите, что тогда Ваши конечные пользователи не смогут пользоваться удобствами из JDK, скажем, java.text.NumberFormat / DateFormat /… или пакет commons.lang.math и ему подобные, понимающий любой Number именно за счет обязательной реализации этих методов.
Так можно сказать, что любой абстрактный класс знает о своих детях.
Класс Number обязывает любого кто осмелился его унаследовать реализовать методы конвертации этих самых наследников в стандартные типы явы (int, float, byte, etc...). По-моему весьма предусмотрительно, т.к. пользователи любых реализаций Number бесплатно получат удобство конвертации в эти типы, а не будет городить каждый раз своё преобразование.
?
docs.oracle.com/javase/tutorial/extra/generics/methods.html
Спасибо, не надо. Это только увеличит число NPE (NullPointerException). От этого наоборот стоит уходить. Скажем, меня удивляет, почему еще не добавили поддержку JSR-305 (@Nullable, @NonNull, ...) в компилятор.
И потом, Вы уверены, что если разрешить примитивным типам принимать null, то для int всё еще хватит 4 байта?