Про Collections: ну так обратная совместимость, нельзя так вот просто поменять методы старых классов видимо. Хоть вроде же есть сподвижки в правильную сторону в следующей java? (я про что-то наподобие extension методов).
Про многопоточность: акторы лишь иной способ многопоточности, видимо достаточно хороший, но java.concurrency уже тоже не локи в чистом виде, все же чуть более высокий уровень. Ну и есть Akka.
Про строчки: а что такое дешевые строчки? Храните char array где вам это нужно. Не встречал проблем со String, хоть может быть они и действительно распространенны.
Но вообще очень жаль, конечно, что ява очень медленно развивается.
Про Serializable мы имеем следующую проблему: вот Map, к примеру, Serializable или нет? А проблема в том что зависит это от типа ключа и значения, вот и переложили эту проблему полностью в runtime…
Про свитч: все же они реализовали его немного эффективней, они при компиляции просчитывают hashCode у строк, для всех объектов этого сделать нельзя.
Хоть конечно не понятно что им мешает сделать тупую реализацию, все равно хуже не станет…
Вообще в данном случае казалось бы проблема с тем что сериализация у листа пишет что-то лишнее. Ну и это в сочетании с тем что enum на особых правах (not nullable, но я не знаю C# так что не могу гарантировать что понимаю эту часть до конца).
Так что не особо и дырявая абстракция, лишь ее реализация.
Ну вашу фразу можно инвертировать: почему пишут на статически-типизируемых языках?
Что лично для меня — то я не очень люблю динамически-типизируемые языки. Когда я пишу код в IDE я хочу точно знать какие методы у какой переменной. Я хочу быть уверен что многие вещи задокументированы типами в самом коде. Я хочу смотреть на типы и понимать что делает данный метод. И мне не сложно дописать для этого типы.
Насчет быстродействия: иногда это все-таки важно, в том же гугле в-осномном (вроде как) используется java и с++. Хоть конечно для простого проекта это не критично.
Ну и про скорость еще одно соображение: когда разница на порядки (случай не самый частый, но бывает =( ) это становится грустно. И фразой «фронты множить очень легко» не отделаешься.
Да и не весь софт просто «фронты множатся».
Когда это просто перевод, то все не так уж и плохо. Бывают и вполне качественные топики, да и мне не важно кто написал. Жаль лишь что содержание такое =(
В 1000 раз лучше было бы, если бы автор просто перевел текст, потому что текст, в отличие от пересказа, хорош.
Всем рекомендую прочитать, то что по ссылке.
конечно проще, но это всего лишь простейший пример, возможно не совсем корректный.
Можно сотню других примеров привести. Например: «красный индикатор» при попытке перестроиться в соседнюю полосу када, на которой «что-то» летит со скоростью 250км/ч
Я думаю актор это примитив чуть более низкого уровня. Акторы используются для построения многопоточных систем, как например для этого используются блокировки и STM.
Есть еще вот такое дерево vk.com/note5333_11073544, говорят очень быстрое.
+ в данном случае наверняка желательна скорость + маленькая память занимаемая, с этих точек зрения наверное стоит смотреть на RB или splay.
Про многопоточность: акторы лишь иной способ многопоточности, видимо достаточно хороший, но java.concurrency уже тоже не локи в чистом виде, все же чуть более высокий уровень. Ну и есть Akka.
Про строчки: а что такое дешевые строчки? Храните char array где вам это нужно. Не встречал проблем со String, хоть может быть они и действительно распространенны.
Но вообще очень жаль, конечно, что ява очень медленно развивается.
Хоть конечно не понятно что им мешает сделать тупую реализацию, все равно хуже не станет…
Так что не особо и дырявая абстракция, лишь ее реализация.
Вот пусть лучше такие вещи будут в самом коде.
Что лично для меня — то я не очень люблю динамически-типизируемые языки. Когда я пишу код в IDE я хочу точно знать какие методы у какой переменной. Я хочу быть уверен что многие вещи задокументированы типами в самом коде. Я хочу смотреть на типы и понимать что делает данный метод. И мне не сложно дописать для этого типы.
Насчет быстродействия: иногда это все-таки важно, в том же гугле в-осномном (вроде как) используется java и с++. Хоть конечно для простого проекта это не критично.
Ну и про скорость еще одно соображение: когда разница на порядки (случай не самый частый, но бывает =( ) это становится грустно. И фразой «фронты множить очень легко» не отделаешься.
Да и не весь софт просто «фронты множатся».
Всем рекомендую прочитать, то что по ссылке.
Так что пример нормальный.
Можно сотню других примеров привести. Например: «красный индикатор» при попытке перестроиться в соседнюю полосу када, на которой «что-то» летит со скоростью 250км/ч
+ в данном случае наверняка желательна скорость + маленькая память занимаемая, с этих точек зрения наверное стоит смотреть на RB или splay.