Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 198
> Но все же, когда любителям Ruby нужна высокая производительность, они обращаются к JRuby.
Когда любителям Ruby нужна высокая производительность они обращаются к Scala :)
Когда любителям Ruby нужна высокая производительность они обращаются к Scala :)
Про майнкрафт верно подмечено! Сам с него начинал, да и несколько друзей тоже :3
игра ведь вообще не оптимизирована
Она достаточно оптимизирована просто для того, чтобы попросту существовать, иначе бы её вовсе не было.
Она не оптимизирована. Она написана… но это как операция на гландах через… ну вы знаете. Вполне можно было бы достичь куда большей производительности, но авторы были не в ладах с мультипоточностью. А ещё можно было достичь большей производительности при оптимизации данных под GC.
А ничё, что автор писал игру в одиночку? И что, если бы обработка блоков не была оптимально сделана, то, на тот момент, игра вообще бы не была написана, потому что объёмы оперативной памяти не позволяли бы? Мультипоточность? Это дополнительная оптимизация, но никак не вообще.
«Ничё». Оптимально сделано (весьма относительно, кстати) и оптимизировано — разные вещи. И насчет «объёмы оперативной памяти не позволяли бы» — извините, но это насколько косоруко надо сделать?
Кстати вопрос не в тему, на том же xbox майнкрафт же не на java?
Вот чего не знаю — того не знаю. Теоретически может с собой таскать ява-машину и запускаться в ней. Но вообще уже давно есть порты на с++, возможно это они.
Официальная вики говорит, что таки на плюсах.
Видимо вы не играли в Minecraft онлайн с сотней игроков. Сервер захлебывался от избытка многопоточности.
Хм, что-то Вы все в кучу смешали.
Оптимизация конкретной игры мало что имеет общего с языком программирования, неоптимизаровано можно на чем угодно написать и обвинять язык… просто надо думать, когда пишешь, не? Да, изначальный выбор языка играет роль, но никак не влияет на отсуствие оптимизации как таковой.
Далее, насчет попсовости андроида конечно спорно, но вот ведь в чем штука — кроме андроида огромное количество софта написано на java, те же hadoop/hbase, банковские системы — их попсовыми называть язык не повернется.
Ну и да, конечно для каждой задачи надо подбирать подходящий инструмент, и писать сайтик на 3 странички на java — это самоубийство; на хабре встречались уже такие посты, не припомню сейчас линки, но там наглядно было видно, где проходит эта грань — когда сайт на java — это бред, а когда вся эта махина реально востребована.
Оптимизация конкретной игры мало что имеет общего с языком программирования, неоптимизаровано можно на чем угодно написать и обвинять язык… просто надо думать, когда пишешь, не? Да, изначальный выбор языка играет роль, но никак не влияет на отсуствие оптимизации как таковой.
Далее, насчет попсовости андроида конечно спорно, но вот ведь в чем штука — кроме андроида огромное количество софта написано на java, те же hadoop/hbase, банковские системы — их попсовыми называть язык не повернется.
Ну и да, конечно для каждой задачи надо подбирать подходящий инструмент, и писать сайтик на 3 странички на java — это самоубийство; на хабре встречались уже такие посты, не припомню сейчас линки, но там наглядно было видно, где проходит эта грань — когда сайт на java — это бред, а когда вся эта махина реально востребована.
Оптимизация конкретной игры мало что имеет общего с языком программирования, неоптимизаровано можно на чем угодно написать и обвинять языкКак программист я вас понимаю и Джаву уважаю, а как пользователь я не люблю Джаву из-за тормозов, глюков и корявого интерфейса в софте на ней написанном :)
Да вот именно! Код майнкрафта не оптимизирован. Инструмент тут совершенно не при чём. Сила инструмента Java — на ней можно решать очень широкий круг задач. И для игры тоже подходит (если не нужно что-то новое из стандартов 3d графики).
если не нужно что-то новое из стандартов 3d графики
Ну, если вас устроить OpenGL, то на Java вы можете найти всё что вам нужно! На сколько я знаю (а знаю я неплохо, потому что это именно то, чем я занимаюсь), все новые 3d-технологии поддерживаются OpenGL последней версии, а значит и Java. Хотя совсем другое дело если PhysX называть 3d-технологией.
Я бы могла часами рассуждать о коде майнкрафта, ведь знаю его наизусть как свой… Но что за глупый спор? Посыл-то в том, что множество мододелов выучили Java начиная модить Minecraft. Я сама обязана ему знаниями, работой и будущим.
Другое дело, что мало модов для Minecraft сделаны нормально. Можно даже статью написать «Пример плохого дизайна: Minecraft и его моды»…
Другое дело, что мало модов для Minecraft сделаны нормально. Можно даже статью написать «Пример плохого дизайна: Minecraft и его моды»…
Вот только синтаксис застрял в лохматых годах. И VM с никому не нужной поддержкой древних версий (это мешает той же Scala). Повторяет, похоже, этот язык путь Delphi, только гораздо масштабнее. А так, да, супер.
Удваиваю этого сэра. Минусуют senior enterprise architects.
Хотите сахара? Для этого есть Groovy. И связка Java+Groovy работает стабильно и четко.
Я предпочитаю Scala.
Речь идёт о Java. И Groovy не может исправить фундаментальные недостатки самой среды VM. Где, например, те же generic реализованы через одно место.
Речь идёт о Java. И Groovy не может исправить фундаментальные недостатки самой среды VM. Где, например, те же generic реализованы через одно место.
… недостатки самой среды VM. Где, например, те же generic...
«самой среды VM» — это же про рантайм, да?
Так вот, в свете type erasure, дженерики не имеют ни малейшего шанса быть реализованными в VM через одно место.
Где, например, те же generic реализованы через одно место.
Если вы про type erasure, то scala это не особо мешает. Да, pattern matching по параметризованным типам не работает (что обходится без проблем), зато ко[нтра]вариантность не требует доработок в jvm.
И как же это мешает Scala?
Также, как и новым версиям Java, как и Groovy, как и Scala. Костыли на низком уровне и сильное падение производительности без возможности это всё поправить.
Пример вы могли бы привести? Какие именно костыли и в каком месте мешают?
Например, отсутствие структур. Не нативная реализация generic, лямбд и прочих кошерных вещей — делается в Groovy/Scala через тормозные костыли. Какой-то кошмар со стандартными библиотеками (тут на хабре была статья про логирование в Java — у меня от неё волосы на голове шевелились) — в Scala поверх стандартных типов даже свои обёртки пишут.
И вообще, Java — классный язык. Но наследие прошлого ему сильно мешает. Выпустили бы новый рантайм без совместимости, как делает .NET — цены бы ему не было.
И вообще, Java — классный язык. Но наследие прошлого ему сильно мешает. Выпустили бы новый рантайм без совместимости, как делает .NET — цены бы ему не было.
А куда девать ранее написанный код?
Все-таки очень много банковского софта под java есть и его вот так на ура не выкинешь. Было бы так все просто — то да, заменили бы. Но это ж не андроид, который раз — и все новое всосал, а старое выкинул — тут как раз проблем нет, это очень динамичный рынок. Но проблема фундаментальных языков — в совместимости со старыми версиями. В С++ те же проблемы — это очень консервативный язык.
Все-таки очень много банковского софта под java есть и его вот так на ура не выкинешь. Было бы так все просто — то да, заменили бы. Но это ж не андроид, который раз — и все новое всосал, а старое выкинул — тут как раз проблем нет, это очень динамичный рынок. Но проблема фундаментальных языков — в совместимости со старыми версиями. В С++ те же проблемы — это очень консервативный язык.
В C# структуры являются типами значений и размещаются на стеке. Возможно, semmaxim имеет в виду это.
И всё же, наличие структур было бы полезным в языке. Кстати, их возможно сделают в JVM openjdk.java.net/jeps/169
Разработчики JVM будут плакать, если нужно будет реализовывать передавачу структур через параметры. :)
В Java или JVM?
А еще, например, в C# невиртуальные методы со временем стремятся превратиться в виртуальные.
Это с какого вы взяли? Разве что с того, что и обычные, и виртуальные методы вызываются MSIL-овской командой callvirt?
Насчет похожих структур: во-первых ссылка потребляет +4 (+8 для х64) байт, во-вторых уменьшается вероятность попадания данных в кэш. Может джваисты уже окончательно забили на производительность, но структура из двух интов занимает 8 байт, а вот экземпляр класса — 12, а в x64 — все 16. Я бы не хотел раздувать размер объектов в 2 раза, да и еще терять на скорости, из-за аллокации памяти в кучи, а не на стеке.
Это связано не с MSIL, а с развитием кода. В самый неожиданный момент выясняется, что метод должен быть виртуальным, что бы его перекрыть.
значит, нужно было думать раньше, а не в последний момент. «Наговнокодим — а там как-нибудь разберемся», а виноваты в этом, конечно же, IDE, язык, ось, что угодно, но не мы.
Я считаю, что компилятор и среда выполнения должны быть достаточно умны, что бы самостоятельно оптимизировать код, написанный без низкоуровневой оптимизации и хаков. Можно сказать, Oracle Java вполне удовлетворяет этому требованию. Поэтому, не вижу смысла захламлять обычный код хаками и низкоуровнемыми оптимизациями.
какой хак? какия низкоуровневая оптимизация? Как раз в тему попадалась хаброцитата
«Переход на графен откроет совершенно новую эпоху — частота электронных устройств может достигнуть терагерца.»
exvel: Ну, слава богу. Можно продолжать говнокодить.
А то логика «пусть за меня это делает компьютер. Если компьютер еще недостаточно умен, чтобы решать это за меня — значит пользователям не повезло, т.к. я слишком себя люблю, чтобы париться знанием устройства ЭВМ»
Заранее ничего нельзя предусмотреть со 100% точностью. Это абсолютно нормально, такова жизнь.
да, но не до такой степени же, что «ой, ребят, вы мне сайт делаете, я на самом деле хотел приложение в аппстор».
Заказчику не нужно ПО, которое работает на 10% быстрее и на 10% экономнее по памяти, но при этом периодически валится по непонятной причине в самый неподходящий момент.
В жизни есть ценности поважнее пары сэкономленных байт.
100% прирост по памяти, путем замены слова class на поле struct, это, конечно, огромные затраты ресурсов за ничтожный выигрыш.
но при этом периодически валится по непонятной причине в самый неподходящий момент.
ой, опять придумываете. В общем, ваша ТЗ ясна. От структур одно зло. Ваша воля — класс byte паковался бы тоже в класс, чтобы занимать в 5(9) раз больше места.
Тем более, что это возможность, а не обязанность. Недостаток VM, которая просирает все типы во время рантайма, тоже предоставляется как достоинство. Круто, что сказать.
Как захотели, так и извратили.
Вовсе нет. Моя точка зрения в том, что оптимизировать стоит 1% кода, который действительно является узким местом и от этого будет польза.
совершенно верно
А от оптимизации 99% кода сомнительными практиками типа структур
а вот с тем, что использование структур это плохая практика — категорически не согласен. Вряд ли бы вам понравилась запись
int a = 5;
int b = a.Clone()из-за того, что иначе a и b указывали бы на пятерку, а не присваивались просто и понятно.
Естественно, я говорю про иммутабельный структуры с полями read-only.
Ну например строки в C# — иммутабельны. Это не мешает вполне нормально с ними работать. А то, что структуры даже если их копировать при каждом присваивании быстрее, чем объекты в куче — вы же, конечно, это знаете?
А структуры по-умолчанию иммутабельны. Потому что мутабельные структуры — прекрасный способ отстрелить себе все что можно. На примере int видно, зачем могут быть нужны иммутабельные структуры.
А структуры по-умолчанию иммутабельны. Потому что мутабельные структуры — прекрасный способ отстрелить себе все что можно. На примере int видно, зачем могут быть нужны иммутабельные структуры.
Чтобы не изменять оригинал, очевидно. Не говоря про интернирование и прочие штуки.
И да, гугл наше все:
stackoverflow.com/questions/2365272/why-net-string-is-immutable
stackoverflow.com/questions/2365272/why-net-string-is-immutable
Строки в .Net — класс, а не структура. Они никуда не копируются при передаче, а вполне себе передаются по ссылке.
И да, структуры по умолчанию не иммутабельны и это добавляет геморроя.
И да, структуры по умолчанию не иммутабельны и это добавляет геморроя.
Строки — класс. Но они неизменяемые. Если пример структуры, то DateTime, ну и хотя бы тот же IEnumerator, причем последняя — мутабельная.
IEnumerator — интерфейс. При чем тут вообще структуры?
Энумераторы, реализующие его, например ListEnumerator — мутабельные структуры.
Если их использовать как IEnumerator, то они будут висеть в хипе, а на стеке будет только указатель на IEnumerator. Так что зачем вы тут вообще IEnumerator вспомнили?
Они будут на стеке, вызов методов будет разве что через интерфейс.
К чему вспомнил: вот это — действительно отстрел ноги, можете попробовать этот код для просветления:
Кстати еслиб энумератор был «в хипе», то этого эффекта не наблюдалось бы.
К чему вспомнил: вот это — действительно отстрел ноги, можете попробовать этот код для просветления:
var x = new { Items = new List<int> { 1, 2, 3 }
.GetEnumerator() };
while (x.Items.MoveNext())
{
Console.WriteLine(x.Items.Current);
}
Кстати еслиб энумератор был «в хипе», то этого эффекта не наблюдалось бы.
Я же специально вам указал: «Если их использовать как IEnumerator». GetEnumerator у
List<int> возвращает List<T>.Enumerator. Вы попробуйте привести его к IEnumerator или лучше List<T> предварительно привести к IList<T> и получите размещение в хипе.Ладно, уже ушли от темы, и возможно, я не прав, так что тем более нужно перевсти тему :)
Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя, если не хочется за каждым чихом писать код на другом, более низкоуровневом языке (С++ тот же). Андройд выпустил целый NDK, потому что java-приложения часто из-за своей высокоуровневости и абстракции не обеспечивали нужной производительности.
Никто не заставляет ими пользоваться. Но само их наличие — это очень нехилый буст для определенных задач.
Если нужен иммутабельный класс (той же даты), то её логично сделать структурой — получаем бонус от thread safety и прочего. Если не нужно — пишем обычный класс и не пытаемся себе отстрелить ногу мутабельными структурами.
В общем, имхо — это ценная возможность, которую нужно уметь применять, потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций, а несколько больше. Не всегда узкое место — медленная выгрузка из базы по узкому каналу, иногда и так бывает.
Ваше мнение: для низкоуровневых задач использовать С/С++ (насколько я понял из речей выше), мое — хорошо, когда все есть в одном языке и не нужно возиться с P/Invoke. И то и то имеет право на жизнь, но мое мнение, логично, я считаю более правильным (иначе бы я его изменил на ваше :) )
Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя, если не хочется за каждым чихом писать код на другом, более низкоуровневом языке (С++ тот же). Андройд выпустил целый NDK, потому что java-приложения часто из-за своей высокоуровневости и абстракции не обеспечивали нужной производительности.
Никто не заставляет ими пользоваться. Но само их наличие — это очень нехилый буст для определенных задач.
Если нужен иммутабельный класс (той же даты), то её логично сделать структурой — получаем бонус от thread safety и прочего. Если не нужно — пишем обычный класс и не пытаемся себе отстрелить ногу мутабельными структурами.
В общем, имхо — это ценная возможность, которую нужно уметь применять, потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций, а несколько больше. Не всегда узкое место — медленная выгрузка из базы по узкому каналу, иногда и так бывает.
Ваше мнение: для низкоуровневых задач использовать С/С++ (насколько я понял из речей выше), мое — хорошо, когда все есть в одном языке и не нужно возиться с P/Invoke. И то и то имеет право на жизнь, но мое мнение, логично, я считаю более правильным (иначе бы я его изменил на ваше :) )
Смешались в кучу кони, люди...
Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя
При этом в качестве примера приводите крайне не очевидный баг, вызванный наличием этой части языка. И тут же, кстати, в ответ получаете, что при правильном использовании плюсы теряются (улетает в хип).
В java есть escape analysis, позволяющий размещать данные в хипе, не напрягая программиста и не плодя криптобагов.
то её логично сделать структурой — получаем бонус от thread safety и прочего
Как вообще структуры связаны с thread safety? Неизменяемый класс ни чуть не менее thread safety, чем структура. Посмотрите на scala и akka — весьма безопасная многопоточность благодаря удобным неизменяемым классам и механизмам работы с ними (на jvm).
потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций
Я знаю только 2 профита от структур: тяжелая арифметика и размещение в массиве. Это полезно в очень редких случаях. При этом на jvm можно таких же улучшений добиться, хоть и с чуть большими затратами.
Ваше мнение
Я вообще ни чего подобного не писал. Мое мнение выше: есть крайне узкая ниша полезности структур в C# и не то, чтобы без них не обойтись.
При этом в качестве примера приводите крайне не очевидный баг, вызванный наличием этой части языка. И тут же, кстати, в ответ получаете, что при правильном использовании плюсы теряются (улетает в хип).
ну да, я же не любитель представлять только в выгодном свете, нужно учитывать плюсы и минусы.
Как вообще структуры связаны с thread safety? Неизменяемый класс ни чуть не менее thread safety, чем структура. Посмотрите на scala и akka — весьма безопасная многопоточность благодаря удобным неизменяемым классам и механизмам работы с ними (на jvm).
неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.
Я знаю только 2 профита от структур: тяжелая арифметика и размещение в массиве. Это полезно в очень редких случаях. При этом на jvm можно таких же улучшений добиться, хоть и с чуть большими затратами.
может в этом дело — последнее время я работаю с массивами структур, в частности при триангуляции объектов в 3d-моделировании, над которыми, соответственно, проводятся довольно непростые вычисления…
Я вообще ни чего подобного не писал. Мое мнение выше: есть крайне узкая ниша полезности структур в C# и не то, чтобы без них не обойтись.
а я говорил, что без них нельзя обойтись? Просто если можно их в язык поместить — почему бы и нет, если есть сценарии, когда они удобны. Они применяются не часто, но всегда по делу.
неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.
С чего бы вдруг? Да, копирование структуры довольно быстро происходит, но создание экземпляра неизменяемого класса происходит 1 раз, а копирование структуры — при каждой передаче. Так что где тут «быстрее»? Да и в случае многопоточности передача между потоками — через хип. А если нет передачи между потоками, то в бой вступает escape analysis.
Ну и да, чтоб immutable данные не ели совсем уж неприличное количество памяти надо использовать персистентные типы данных. А их со структурами не добиться — то есть просядем по памяти.
Но вообще я в этот спор ввязался только из-за вашего смешивания неизменяемости и структур.
В java есть escape analysis, позволяющий размещать данные в хипе
в стеке, ошибочка.
Но вообще я в этот спор ввязался только из-за вашего смешивания неизменяемости и структур.
Я несколько оговорился. Я не путал, я постулировал, что
1.Структуры обязаны быть неизменяемыми.
2.Изменяемые структуры — путь мучений и невзгод.
3.Неизменяемые структуры — при правильном подходе могут дать хороший буст в некоторых сценариях
В общем то остальное — косноязычие при попытке сформулировать и доказать эту мысль. В частности, попытки доказать, что этих сценариев не так уж мало, чтобы «Забить на них», как в джаве. Хотя и там, насколько я помню, существует выделение памяти на стеке, только там оно автоматизированно. насколько я помню.
Да, несколько косноязчыно сказал. Мысль в том, что выделение памяти для структур заключается всего лишь в увеличении указателя стека, причем память под все локальные переменные выделяются вообще одной инструкцией. В то время как выделение памяти с помощью newobj несколько более затратно (хотя и намного быстрее, чем new в каком-нибудь C++). Ну и то, что структуры уничтожаются сразу при выходе из области видимости (по той же причине со стеком), а объекты должны пережить сборку мусора. Особенно если это объекты с финализаторами.
И даже множественные присвоения стэковой переменной получаются быстрее, чем изменение переменной по ссылке. Естественно, граничные условия в которых все наборот — существуют, но в целом картина такая. Если бы от структур не было бы толка — их не стали бы вводить в язык. Обошлись бы классами, а для взаимодействия с неуправляемым кодом позволили бы классам также иметь атрибут ClassLayout, например
И даже множественные присвоения стэковой переменной получаются быстрее, чем изменение переменной по ссылке. Естественно, граничные условия в которых все наборот — существуют, но в целом картина такая. Если бы от структур не было бы толка — их не стали бы вводить в язык. Обошлись бы классами, а для взаимодействия с неуправляемым кодом позволили бы классам также иметь атрибут ClassLayout, например
В данном контексте под структурой понимается тип, хранящийся в стеке. Т.е. «такой же» как int, только пользовательский.
Тип, хранящийся на стеке — неправильное определение структуры. Если структура — поле класса, то эта структура будет храниться в куче вместе с объектом. Просто там не будет ссылки.
Конечно, я и не говорил, что это правильное определение. Я написал то, что должно было заинтересовать человека из мира Явы, не знакомого с такой концепцией вовсе. А уж с деталями он разберется, если откроет первую же статью по теме.
Ага, и в первой статье будет написано, что структуры хранятся на стеке.
Когда мне говорят про то, что структуры — это типы данных, хранящиеся на стеке, мне всегда вспоминается эта знаменитая статья Липперта.
Вы что С не проходили?
«Структуры» в терминах .net — это определенные пользователем value-типы. Т.е. типы с семантикой копирования, а не передачи по ссылке. Как int-ы и float-ы.
Структуры в терминах C++ в общем-то то же самое
Соотносится с бритвой просто: если бы они были не нужны — их бы не было.
Value-типы как правило нужны когда:
— нужно компактно хранить или быстро обрабатывать что-то
— при взаимодействии с внешними библиотеками.
— где нужна value-семантика. Например Nullable<> или какой-нибудь Vector<>.
В ситуациях когда они нужны, они безусловно облегчают жизнь. Потому что если бы их не было, их бы пришлось как-то имитировать другими средствами. Например юзать float[] вместо List, жонглировать байтиками и смещениями, запоминать что Nullable — это ссылка на контейнер с ссылкой, что ведет к неприятным эффектам.
Value-типы как правило нужны когда:
— нужно компактно хранить или быстро обрабатывать что-то
— при взаимодействии с внешними библиотеками.
— где нужна value-семантика. Например Nullable<> или какой-нибудь Vector<>.
В ситуациях когда они нужны, они безусловно облегчают жизнь. Потому что если бы их не было, их бы пришлось как-то имитировать другими средствами. Например юзать float[] вместо List, жонглировать байтиками и смещениями, запоминать что Nullable — это ссылка на контейнер с ссылкой, что ведет к неприятным эффектам.
Но для компактности и быстрой обработки лучше хранить данные по полям в массиве, а не в структуре, т.к. нет потерь на выравнивание и т.п.
В .NET структуры можно выравнять, как и в си. Т.е. физически массив структур будет разложен в плоский кусок памяти, но для программиста это не будет набор несвязанных int-ов, а именно массив строго типизированных сущностей с разными полями.
Мысль не понял. В чем проблема обмена объектами?
Внешними для .net библиотеками, например с API операционных систем, заточенными под си, и требующими передать ссылку на правильно выравненную структуру.
В ситуациях, когда оператор GOTO безусловно облегчает жизнь. Потому что если бы его не было, его пришлось бы как-то имитировать средствами if, while и т.п… Нет, не так?
Наоборот. В Java ты вынужден эмулировать семантику структур, например через ByteBuffer. В .net есть фича, умеющая это делать прямо.
Есть там возможность указать нужное выравнивание, порядок байт, объединения (union)?
Есть. Атрибутами «StructLayout» и «FieldOffset» можно явно указать размер и смещения полей в структурах. Union делается этим же средством.
Понятно что порядок байт short, int и long будет такой же как и на платформе. Смысл ведь как раз в этом — избежать лишней прослойки, типа берем кусок памяти и сразу как с родным числом работаем.
Если нужно Little-endian — можно сделать какую-нибудь обертку — какой-нибудь struct LittleEndianInt32 с пропертью Value, которая будет конвертировать туда-сюда.
Если нужно Little-endian — можно сделать какую-нибудь обертку — какой-нибудь struct LittleEndianInt32 с пропертью Value, которая будет конвертировать туда-сюда.
При этом почему-то зверский хайлоад типа твитера, сервер-сайда многих онлайн-игр и инвест-банки живут на JVM, а не на CLR
Очень интересует «Причина № 6», есть ли данные о том, столько программистов работают над созданием Java-интерактива дисков и какие диски приобрести, чтобы сильнее впечатлиться работой этих программистов.
Можно поподробнее про тормозные костыли с generic'ами? В рантайме никаких generic'ов нету (и правильно) — там нечему тормозить.
Не вижу плюсов в том, что в JVM в рантайме дженериков нет. Кроме того что это было проще сделать. Минусы же очевидны — с value-типами нельзя и шага сделать шага без боксинга.
Плюсы — скорость, простота, совместимость. Для value-типов можно сделать специализацию на конкретный тип.
Скорость — определенно нет, боксинг же.
Простота — для реализации JVM — да, для программиста — нет. Программисту просто — это когда можно List и Dictionary<int, string>, и это все работает без фокусов.
Совместимость — как по мне проблема высосана из пальца. В .NET дженерики только со второй версии появились, но все прошло довольно гладко.
Простота — для реализации JVM — да, для программиста — нет. Программисту просто — это когда можно List и Dictionary<int, string>, и это все работает без фокусов.
Совместимость — как по мне проблема высосана из пальца. В .NET дженерики только со второй версии появились, но все прошло довольно гладко.
Скорость определяется не только боксингом.
Dictionary<Integer, String> — это проблема Java, а не JVM. В Scala я пишу Dictionary<Int, String>.
Generic'и в рантайме мешают развитию других языков, потому что CLR навязывают свою жесткую систему типов. Я про такую совместимость говорил. Например, в Scala можно присвоить List<String> к List<Nothing>, если список пустой. А в .NET такого сделать нельзя, потому что нельзя отнаследовать Nothing от любого объекта. Поэтому реализовать Scala на CLR либо очень трудно, либо невозможно.
Dictionary<Integer, String> — это проблема Java, а не JVM. В Scala я пишу Dictionary<Int, String>.
Generic'и в рантайме мешают развитию других языков, потому что CLR навязывают свою жесткую систему типов. Я про такую совместимость говорил. Например, в Scala можно присвоить List<String> к List<Nothing>, если список пустой. А в .NET такого сделать нельзя, потому что нельзя отнаследовать Nothing от любого объекта. Поэтому реализовать Scala на CLR либо очень трудно, либо невозможно.
В Scala я пишу Dictionary<Int, String>.
И это наверняка транслируется в Dictionary<Integer, String>, со всеми боксингами.
В мысли не держать вообще в рантайме типы есть смысл. Пример javascript показывает что и без типов можно достигать впечатляющей скорости. Пример typescript — показывает что можно сделать статически-типизированный язык поверх нетипизированного рантайма. Причем система типов там кардинально отличается от мейнстримной. Еще с динамической типизацией взаимодействие между разными языками может быть попроще.
С другой стороны системы типов JVM и .NET не так сильно отличаются. Приводить отсутствие generic-ов в плюсы JVM — как-то странно. Вот если бы JVM была совсем динамической, работала при этом с той же скоростью что и .NET, и имела бы несколько реализаций языков с принципиально разными системами типов — тогда да, аргумент бы прошел.
По факту в .NET есть DLR, которая позволяет эту идею развивать, и тот же F#, где система типов сильно не такая, но положили на CLR всё нормально. А проблема со Scala — скорее всего в том, что ее затачивали под JVM изначально.
Что значит не держать в рантайме типы? Не путаете ли вы динамическую типизацию с отсутствием типизации? Javascript держит типы, ещё как.
F# — аргумент не канает, потому что F# — это не OOP, а FP язык. А Scala — это OOP язык.
Хорошо, другой пример. Fantom изначально проектировался под JVM и CLR. И что там с дженериками? Их вообще нету в Fantom.
F# — аргумент не канает, потому что F# — это не OOP, а FP язык. А Scala — это OOP язык.
Хорошо, другой пример. Fantom изначально проектировался под JVM и CLR. И что там с дженериками? Их вообще нету в Fantom.
«Не держать в рантайме типы» — это значит что рантайм не знает что на входе были какие-то там классы, функции, ADT или что там еще. У него есть какой-то базовый набор примитивов и всё, дальше он сам как-то пытается что-то придумывать чтобы это более-менее быстро работало. Получаем большую гибкость для разработчиков языков под этот рантайм за счет большей сложности рантайма, и скорее всего скорости его работы.
А с ООП в F# все не хуже чем в C# и Java.
А с ООП в F# все не хуже чем в C# и Java.
Честно, говоря, из того что вы перечислили более менее подходит только отсутствие структур. Их ограничение на AnyVal и в правду есть (http://docs.scala-lang.org/sips/pending/value-classes.html). Только реально структуры востребованы только при реализации библиотек GUI.
Про .NET в контексте Scala вообще лучше помалкивать.
Generic — это не часть JVM. Его элементарно добавить в саму Java компилируя List в ListInteger, только хрен вы потом передадите ссылку на этот класс, в код, который ждет List.
Про .NET в контексте Scala вообще лучше помалкивать.
Generic — это не часть JVM. Его элементарно добавить в саму Java компилируя List в ListInteger, только хрен вы потом передадите ссылку на этот класс, в код, который ждет List.
Выпустили бы новый рантайм без совместимости, как делает .NET — цены бы ему не было.
Цена была бы 0.
Представленные в статье первые четыре картинки — из замечательного пародийного ролика «Java vs Microsoft .NET Trailer»
Удивляюсь, что вы не дали на него ссылку
www.youtube.com/watch?v=13A0_QkqtaQ
Удивляюсь, что вы не дали на него ссылку
www.youtube.com/watch?v=13A0_QkqtaQ
лучше по этой ссылке
www.youtube.com/watch?v=kLO1djacsfg
www.youtube.com/watch?v=kLO1djacsfg
В оригинальной статье не было этих картинок и упоминаний о роликах, это «отсебятина» — так сказать, примечания переводчика :)
Пятая картинка из Java Life: www.youtube.com/watch?v=b-Cr0EWwaTk
И к этим двум роликам всегда идёт прицепом Java Zone: www.youtube.com/watch?v=Mk3qkQROb_k
И к этим двум роликам всегда идёт прицепом Java Zone: www.youtube.com/watch?v=Mk3qkQROb_k
Вопрос: почему при всей крутости Java, огромное количество (большинство?) приложений, написанных на ней, выглядят так отвратительно под Windows? Нет, Intel, правда?
А вообще статья ну уж слишком холиварная.
А вообще статья ну уж слишком холиварная.
Вы забыли поговорку «на вкус и цвет товарища нет».
IMHO: У меня вот мнение что Windows под Windows стал выгладить ужасно.
IMHO: У меня вот мнение что Windows под Windows стал выгладить ужасно.
огромное количество (большинство?) приложенийНу потому что десктоп-приложения — это никак не огромное количество и тем более не «большинство», а крошечная часть приложений на Java. А вообще на скриншоте просто «ненативный» l&f одного конкретного, хоть и вроде как «стандартного», gui-фреймворка. Java это ж язык, а не набор виджетов, она не имеет никакого отношения к виду программ, на Java можно написать gui так, что и не отличите от нативного.
>>Ну потому что десктоп-приложения — это никак не огромное количество и тем более не «большинство»
Из десктоп приложений на java под Win приложения на java под Win для десктопа всё-таки составляют большинство. И вот среди них-то «огромное количество (большинство?) приложений» таки да, выглядят не очень.
Из десктоп приложений на java под Win приложения на java под Win для десктопа всё-таки составляют большинство. И вот среди них-то «огромное количество (большинство?) приложений» таки да, выглядят не очень.
Мне так и не удалось понять что имеллось в виду в первом предложении, но раз выглядят не очень, значит и не было такой цели
Раньше было все просто: одно приложение — одна операционка, все круто.
Потом приперлась java с ее мультиплатформенностью.
И вот ведь проблема — теперь надо вид приложений делать под все операционки! Засада! Раньше надо было новое приложение писать. А теперь только морду меняй — и все недовольны. Давайте жить проще: нет приложения — нет проблемы. А коль есть — так сразу видите ли морда ее не так выглядит…
А вцелом java ставит перед разработчиками новые проблемы — поддерживать нативный вид на множестве платформ, и это не так просто с наскоку решить.
Потом приперлась java с ее мультиплатформенностью.
И вот ведь проблема — теперь надо вид приложений делать под все операционки! Засада! Раньше надо было новое приложение писать. А теперь только морду меняй — и все недовольны. Давайте жить проще: нет приложения — нет проблемы. А коль есть — так сразу видите ли морда ее не так выглядит…
А вцелом java ставит перед разработчиками новые проблемы — поддерживать нативный вид на множестве платформ, и это не так просто с наскоку решить.
Разработчики не прописывают стили в Swing, если я правильно вас понял.
Если под «прописывают стили» вы имеете в виду внешний вид приложения, то, конечно, можете с gui делать что хотите. Т.е. можно использовать готовые «шкурки» («look and feel»), можно использовать нативные (на винде будет как любое другое виндовое приложение), можно делать свои и тогда, как уже написано выше, gui может выглядеть как угодно
Мне так кажется, что если человек пишет десктопное приложение пол линуксой — он не будет заморачиваться его видом под виндой и наоборот — слишком гиморно это. А большие продукты — они вполне адекватно выглядят. Но вцелом кастомизация под морду ОС — это какбэ вторая задача, главное — юзабилити, а картинки — потом.
Нативно выглядящие приложения на Java вполне себе реальны при использовании SWT. Например Eclipse посмотрите. Но такое решение, к сожалению, платформозависимое. Если не гнаться за нативностью, то Swing можно прилично застилизовать.
Потому что прикладному программисту (тому, кто родил непонравившуюся вам поделку, а не из Sun/Oracle) было лень вставить одну строчку
Но вообще лучше SWT…
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());Но вообще лучше SWT…
Каждая вторая статья про Java — о том, что с Java все хорошо.
Не могу не вспомнить рекламный видеоролик о жизни мальчика в семье вендокодеров. Они ему на ночь мануалы читали, а он задавал неудобные вопросы. Потом, в юности, познакомился с симпатичной джависткой, которая его через постель заинтересовала джавой и так далее.
Ну и недавно на башорге тоже пост видел «Хотите пригласить симпатичную HR-ку в гости — скажите, что у вас дома живет java-программер»
Ну и недавно на башорге тоже пост видел «Хотите пригласить симпатичную HR-ку в гости — скажите, что у вас дома живет java-программер»
Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.
А можно поподробнее про Haskell на JVM?
Я так понимаю поддерживать полный Haskell для JVM не получилось — www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F
Но есть Frege (https://github.com/Frege/frege), "more or less equivalent to Haskell 2010"
Но есть Frege (https://github.com/Frege/frege), "more or less equivalent to Haskell 2010"
И еще есть Jaskell :)
То, что по первой ссылке я как-то смотрел, и выглядит оно заброшенными трупиками =/
Frege выглядит более интересно. Было бы здорово послушать, если если его кто-то пробовал использовать.
Frege выглядит более интересно. Было бы здорово послушать, если если его кто-то пробовал использовать.
Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.
1. Haskell здесь вообще не к месту. Ни к Java, ни к JVM разрботка Haskell никогда не была привязана. И не будет, не надейтесь. Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.
2. Scala / Clojure это как раз-таки пример «Java-хейтеров», как вы их назвали. Они используют JVM и байткод, но создавались именно по той причине, что у Java куча проблем (о которых в статье ни слова не сказано).
Как еще Рич Хикки (создатель Clojure) говорил: «Это нормально — ненавидеть Java и любить JVM».
Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.
Мне не понятна причина. Раскроете? Гугл вот говорит, что этой темой занимаются.
Да, язык Java по-своему хорош, с этим спорить не буду. Но, то что было описанно в этом посте, меня «удивило». Вот, к примеру:
Тот же пример с Minecraft-ом. Это все чего было хорошего написано на Java?
Вы можете заменить большинство библиотек вашим собственным кодом, если вам нужны особенные функциональные возможности.
Тот же пример с Minecraft-ом. Это все чего было хорошего написано на Java?
Жаль, только, что этого нет в тексте поста.
По пунктам
1. Непотопляемость. Я вот почему-то думал что языки — это инструменты, а получается, что тут есть враги, друзья, свои и чужие, чужих нужно уничтожить, своих — защитить… Вывод: хороший вброс для холивара.
2. Многопоточность. Вопрос — а где её, собственно, нет? Не говоря про TPL и async/await в C# 5.0. Вывод: выдача желаемого за действительное
3. Первый язык программирования. В целом согласен. Разве что у студентов стран СНГ первым языком все еще является паскаль, реже — С. Вывод: в целом верно.
4. Кроссплатформенность. Фишка джавы. Вывод: очевиден.
5. Снова кроссплатформенность. Зачем-то упоминают андройд, который наоборот, пытается избавиться от Dalvik и переходит на ART. Вывод: присобачили как получилось информацию, выдали в нужном свете — и готово.
6. Блю-рей. Вывод: возможно, сказана правда, никогда ими не пользовался: кино и цифровой контент наше все.
7. Фигурные скобки. Ну это просто смешно. Какое достижение! Какой прогресс! Скобки джавы ведь намного удобнее и скобочнее, чем скобки С 70годов…
8. Groovy. Спорить не о чем.
9. JVM. Опять же, спорить не о чем, обо всем сказал в пункте 5. Не забыли оскорбить C#, забыв, что как раз-таки с помощью Xamarin можно писать одно и то же для всех платформ (Win-iOS-Android). Ну бывает, видимо у автора действительно припекло с врагами и друзьями (имеется ввиду автор оригинала).
10. Не совсем понятно, связь NoSQL с Java. Если бы не было С, WinAPI был бы написан на паскале. Ребята взяли наиболее подходящий язык и реализовали ан нем. Не было бы его — реализовали бы NoSQL на том же шарпе, или еще на чем.
11. Про производительность Minecraft ходят легенды. Хотя можно отнести к плюсам, как авторы пишут.
12. Опен-сорс. Ну, как говорится, любой код на управляемом языке — опен-сорс поневоле :) Про то, что тот C# и CLR тоже являются опен-сорсными (ECMA334,ECMA334) — как-то забывают. Так что выбора у них особо не было.
Вывод: я сравниваю с шарпом просто потому, что эти языки прямые конкуренты. Но это конкуренты, а не враги! Вся статья пропитана фанатизмом и нонконформизмом. Жаль, что есть люди, у которых микроскопы — в друзьях, а лупа — злейший враг.
1. Непотопляемость. Я вот почему-то думал что языки — это инструменты, а получается, что тут есть враги, друзья, свои и чужие, чужих нужно уничтожить, своих — защитить… Вывод: хороший вброс для холивара.
2. Многопоточность. Вопрос — а где её, собственно, нет? Не говоря про TPL и async/await в C# 5.0. Вывод: выдача желаемого за действительное
3. Первый язык программирования. В целом согласен. Разве что у студентов стран СНГ первым языком все еще является паскаль, реже — С. Вывод: в целом верно.
4. Кроссплатформенность. Фишка джавы. Вывод: очевиден.
5. Снова кроссплатформенность. Зачем-то упоминают андройд, который наоборот, пытается избавиться от Dalvik и переходит на ART. Вывод: присобачили как получилось информацию, выдали в нужном свете — и готово.
6. Блю-рей. Вывод: возможно, сказана правда, никогда ими не пользовался: кино и цифровой контент наше все.
7. Фигурные скобки. Ну это просто смешно. Какое достижение! Какой прогресс! Скобки джавы ведь намного удобнее и скобочнее, чем скобки С 70годов…
8. Groovy. Спорить не о чем.
9. JVM. Опять же, спорить не о чем, обо всем сказал в пункте 5. Не забыли оскорбить C#, забыв, что как раз-таки с помощью Xamarin можно писать одно и то же для всех платформ (Win-iOS-Android). Ну бывает, видимо у автора действительно припекло с врагами и друзьями (имеется ввиду автор оригинала).
10. Не совсем понятно, связь NoSQL с Java. Если бы не было С, WinAPI был бы написан на паскале. Ребята взяли наиболее подходящий язык и реализовали ан нем. Не было бы его — реализовали бы NoSQL на том же шарпе, или еще на чем.
11. Про производительность Minecraft ходят легенды. Хотя можно отнести к плюсам, как авторы пишут.
12. Опен-сорс. Ну, как говорится, любой код на управляемом языке — опен-сорс поневоле :) Про то, что тот C# и CLR тоже являются опен-сорсными (ECMA334,ECMA334) — как-то забывают. Так что выбора у них особо не было.
Вывод: я сравниваю с шарпом просто потому, что эти языки прямые конкуренты. Но это конкуренты, а не враги! Вся статья пропитана фанатизмом и нонконформизмом. Жаль, что есть люди, у которых микроскопы — в друзьях, а лупа — злейший враг.
6. Блю-рей. Вывод: возможно, сказана правда, никогда ими не пользовался: кино и цифровой контент наше все.
Имеется ввиду BD-J. Это лишь небольшая часть стандарта, так что то, что «Blu-Ray стандарт построен вокруг Java» — очень сильное преувеличение. Но то, что Java там используется — правда.
Зачем-то упоминают андройд, который наоборот, пытается избавиться от Dalvik и переходит на ART.
Что, по сути, является тем же, но в профиль. Вместо JIT компиляции в runtime будет JIT в install-time. Java никуда не уходит.
Но когда говорят, что приложение «ну чуть-чуть медленее, чем нативное», как в этой статье — откровенно лукавят, не так ли?
В одном из пунктов промелькнула критика в отношении кроссплатформенности C#, но про Mono никто не сказал. Достаточно кроссплатформено, и именно моно и растущая армия c#-разработчиков в ближайшем будущем могут вторгнуться на рынок серверных разработок.
Я конечно, поставлю Вам плюс за камент, но скажу при этом, что Вы гадаете на кофейной гуще.
Mono по сравнению с .NET это жалкая бажная поделка. Сравните количество QA, которые работают над Mono и над .NET. Серьёзный шаг вперёд для .NET на линуксе будет сделан только если Microsoft этого захочет и этим займётся.
Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?
Mono по сравнению с .NET это жалкая бажная поделка. Сравните количество QA, которые работают над Mono и над .NET. Серьёзный шаг вперёд для .NET на линуксе будет сделан только если Microsoft этого захочет и этим займётся.
Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?
Разве количество специалистов, работающих над средой выполнения — это показатель? Сколько не спрашивал — у всех mono работает без проблем и в продакшн на серверах уже используется.
> Mono по сравнению с .NET это жалкая бажная поделка. Сравните количество QA, которые работают над Mono и над .NET. Серьёзный шаг вперёд для .NET на линуксе будет сделан только если Microsoft этого захочет и этим займётся.
Есть Xamarin, который сделал Моно более чем портабельным, стабильным и платным.
>Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?
Есть факт, что нынешних студентов учат C# во всех вузах и это их основной язык на протяжении всего периода обучения. Коим раньше был Delphi. И с вашей стороны будет полнейшей глупость отрицать, что это никак не сказывается на рынке.
Еще есть факт, что .net — это тренд на отечественном рынке разработки. И бизнес делает акцент на эту технологию. Если Вы не знакомы с этим рынком, то не стоит выражать дилетантское мнение вообще.
Я и не утрвеждал, что mono вытеснит джаву, как, судя по всему, вы недальновидно восприняли мой комментарий.
И, пожалуйста, меньше дерзости в общении с незнакомыми людьми. Вас это не красит.
Есть Xamarin, который сделал Моно более чем портабельным, стабильным и платным.
>Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?
Есть факт, что нынешних студентов учат C# во всех вузах и это их основной язык на протяжении всего периода обучения. Коим раньше был Delphi. И с вашей стороны будет полнейшей глупость отрицать, что это никак не сказывается на рынке.
Еще есть факт, что .net — это тренд на отечественном рынке разработки. И бизнес делает акцент на эту технологию. Если Вы не знакомы с этим рынком, то не стоит выражать дилетантское мнение вообще.
Я и не утрвеждал, что mono вытеснит джаву, как, судя по всему, вы недальновидно восприняли мой комментарий.
И, пожалуйста, меньше дерзости в общении с незнакомыми людьми. Вас это не красит.
Есть Xamarin, который сделал Моно более чем портабельным, стабильным и платным.
Окей. Кто их крупнейшие/известнейшие кастомеры? Что на нём крутится в продакшене?
Есть факт, что нынешних студентов учат C# во всех вузах и это их основной язык на протяжении всего периода обучения.
Этот факт Вы сами придумали? Где пруф? Где статистика по ВУЗам? Это всё спекуляция с Вашей стороны. «Какие Ваши доказательства?»
И с вашей стороны будет полнейшей глупость отрицать, что это никак не сказывается на рынке.
Я проигнорирую этот дурацкий выпад в мой адрес. Насчёт рынка — см. ниже.
Еще есть факт, что .net — это тренд на отечественном рынке разработки. И бизнес делает акцент на эту технологию.
«Какие Ваши доказательства?»
Если Вы не знакомы с этим рынком, то не стоит выражать дилетантское мнение вообще.
толсто.
Я и не утверждал, что mono вытеснит джаву, как, судя по всему, вы недальновидно восприняли мой комментарий.
толсто.
И, пожалуйста, меньше дерзости в общении с незнакомыми людьми.
угрожаете?
Вас это не красит.
Назовите мне хоть одну причину вообще учитывать Ваше мнение.
Зайдите в любой университет, пообщайтесь со студентами. Статистика с мест, собранная лично.
Какие Ваши доказательства и предоставьте мне статистику адекватных ответов с Вашей стороны, чтоб считаться с Вашим мнением :)
Вы первый начали грубить и хамить, поэтому не удивляетесь такой ответной реакции. Отвечайте спокойно, без хамства и с уважением человеку, который с Вами общается, тогда не будет таких ситуаций.
Какие Ваши доказательства и предоставьте мне статистику адекватных ответов с Вашей стороны, чтоб считаться с Вашим мнением :)
Вы первый начали грубить и хамить, поэтому не удивляетесь такой ответной реакции. Отвечайте спокойно, без хамства и с уважением человеку, который с Вами общается, тогда не будет таких ситуаций.
Во-первых, я не удивляюсь. Видал и не таких. Во-вторых, у меня нет никакого желания отвечать Вам ни «без хамства» ни «с уважением» ни вообще как либо. Я Вас не знаю, и не горю желанием знакомиться. Оставайтесь при своём мнении, нет проблем.
У вас какая-то альтернативная статистика. В большинстве случаев «делайте на чём хотите». Есть устаревшие программы на c/c++, есть «модерновые» — python/ruby. Требований «Java» или «C#» ещё ни разу не встречал. И используется он не более, чем в реальной разработке.
Интересно читать о наличии типов для понятия устройсва компьютера, когда нет явных указателей и выделения памяти.
Интересно читать о новомодных языках как python и ruby, которые старше java.
Интересно читать как автор не любит скобки и при том ставит под сомнение их отсутсвие.
Интересно читать как автор пишет про блю-рей, когда есть smart tv.
Как-то слишком односторонне и субективно повествуется.
Интересно читать о новомодных языках как python и ruby, которые старше java.
Интересно читать как автор не любит скобки и при том ставит под сомнение их отсутсвие.
Интересно читать как автор пишет про блю-рей, когда есть smart tv.
Как-то слишком односторонне и субективно повествуется.
Устройство компьютера это как-то совсем обобщенно, но модель памяти обязательно проходится в курсе Java.
модный и новомодный != новый.
Скобки это у всех субъективно, т.к. есть плюсы и минусы и там и там. Автор говорит, что они хороши для начинающих.
Smart TV это круто, но оно уже у вас есть? Или оно как-то отменяет Blu-ray? Вот то, что оно редко используется это да.
модный и новомодный != новый.
Скобки это у всех субъективно, т.к. есть плюсы и минусы и там и там. Автор говорит, что они хороши для начинающих.
Smart TV это круто, но оно уже у вас есть? Или оно как-то отменяет Blu-ray? Вот то, что оно редко используется это да.
Раз обобщено, то зачем автор об этом пишет?
Когда языку много лет и он при этом активно развивается, то вряд ли на нем никто и ничего не делал и вряд ли он становится более популярным мгновенно. Если имеется ввиду популярность для веб, то совсем непонятно причем тут java, а не php.
Я крайне не согласен в таком случае с автором, тк для новичка главное не скобки, а б**дь писать правильно, выдерживая принятые соглашения в языке, давая нормальные имена переменным и избегая партянок кода с огромной вложенностью. Если придерживаться соглашений и язык не подразумевает минификации, как js, то скобки по сути не нужны.
Когда языку много лет и он при этом активно развивается, то вряд ли на нем никто и ничего не делал и вряд ли он становится более популярным мгновенно. Если имеется ввиду популярность для веб, то совсем непонятно причем тут java, а не php.
Я крайне не согласен в таком случае с автором, тк для новичка главное не скобки, а б**дь писать правильно, выдерживая принятые соглашения в языке, давая нормальные имена переменным и избегая партянок кода с огромной вложенностью. Если придерживаться соглашений и язык не подразумевает минификации, как js, то скобки по сути не нужны.
Раз обобщено, то зачем автор об этом пишет?
либо неточности перевода, либо автору нечего было больше написать
Когда языку много лет и он при этом активно развивается, то вряд ли на нем никто и ничего не делал и вряд ли он становится более популярным мгновенно.
А кто сказал мгновенно? Я могу ошибаться, но руби начал активнее использоваться когда вышли рельсы, а о питоне я начал слышать чаще из-за гугла
тк для новичка главное не скобки
Не главное, конечно, но скобки помогают чуть лучше понять структуру класса для совсем начинающих.
Я всего лишь хотел обратить внимание что подача материала автором чересчур сомнительна. С такой подачей можно повествовать в красках о многих языках. Не скажу о руби, но рассказывать когда питон начал поставляться по умолчанию с линуксовыми дистрибутивами, когда появлялись библиотеки для вычислений, популярнейшие фреймворки, в каких программах и играх использовался можно долго.
Что касается новичков, то они могут написать страшное, тем более существует вероятность, что могут быть использованы скобки разного стиля (java style и c# style).
При форматировании отступами, такое врядли допустимо:
Что касается новичков, то они могут написать страшное, тем более существует вероятность, что могут быть использованы скобки разного стиля (java style и c# style).
function example (test0, test1, test2) {
if (test0)
{
if (test1)
{if (test2) {
return 10;
}} else { return 5;}}
return 0;
}
При форматировании отступами, такое врядли допустимо:
def example(test0, test1, test2):
if test0:
if test1:
if test2:
return 10
else:
return 5
return 0
function example (test0, test1, test2) {
if (test0)
{
if (test1)
{if (test2) {
return 10;
}} else { return 5;}}
return 0;
}
…
Новичок изучает язык по своему коду что ли? Имеется в виду, что новичку более четко видны границы
public class Foo {
public Foo(){
}
private void todo(boolean param){
if(param){
// to do
} else {
// or no to do
}
}
}
Хотя, по-моему, сомнительно это приписывать к плюсам языка.
А почему это ruby старше java?
Вот что молвит википедия:
Оба языка вышли в свет в 1995.
Вот что молвит википедия:
Разработка Java началась в 1990 году
Ruby начал разрабатываться 23 февраля 1993 года
Оба языка вышли в свет в 1995.
не в ту ветку…
> Java никогда не была популярным инструментом для разработки десктоп-приложений, но она расцвела в мобильном сегменте рынка, который, в последнее время рванул вверх. Платформа Android построена на Java от и до, и в настоящее время Android устройства продаются лучше, чем iPhone.
Наврено оно и к лудшему, что не была. Большенство ява приложений выглядили топорно и чужеродно, что не добавляло им удобство использования.
А вспомниая начало своей проф дейтельности на мобильных платформах в 2005ом — J2ME, то я до сих пор задаюсь вопросом — пошто?
Это же был сущий ад — куча слабосовместимых реализаций j2me, масса костылей, уймы портов. И всё это замешано на очень слабом апи и жутких тормозах. По сравнению с этим программирование на Symbian, PocketPC — это было как ракета, против велосипеда с квадратными колёсами.
Иногда ещё вспоминаю куски кода типа:
splash = null;
if(iMotorola) for(int i=0; i<CONST31; i++) System.gc();
В общем было весело :)
Наврено оно и к лудшему, что не была. Большенство ява приложений выглядили топорно и чужеродно, что не добавляло им удобство использования.
А вспомниая начало своей проф дейтельности на мобильных платформах в 2005ом — J2ME, то я до сих пор задаюсь вопросом — пошто?
Это же был сущий ад — куча слабосовместимых реализаций j2me, масса костылей, уймы портов. И всё это замешано на очень слабом апи и жутких тормозах. По сравнению с этим программирование на Symbian, PocketPC — это было как ракета, против велосипеда с квадратными колёсами.
Иногда ещё вспоминаю куски кода типа:
splash = null;
if(iMotorola) for(int i=0; i<CONST31; i++) System.gc();
В общем было весело :)
Я не использовал J2ME, но как-то сложно представить вообще что-нибудь, чему бы помог вызов System.gc() в цикле
Может он пытался удалить таки неиспользуемые объекты, а с первого раза ГС их не удалял?:)
Я не уверен насчёт того была ли это моторола — но такой код для одного из вендеров точно был.
Фишка в том что если какой-то кол-во раз вызвать gc для реализации явы от того вендера, то он гарантированно пройдётся и срберёт мусор.
Это делалось, например, после освобождения больших картинок, ибо последующая загрузка новой картинки вызвала бы гарантированный креш игры из за нехватки памяти. А там мы её выдерали у ГЦ :)
Этот код писал не я — у нас был отдел портирования, который знал все нюансы поведения явы на разных телефонах, и собирал сто пицот миллионов билдов для разных трубок. Яже немного писал логику игр на яве, а потом в мессе занимался портом с J2ME на C++ (Symbian, Palm, PocketPC и так далее), и глядя в код портов для разных трубок, сравнивая его с тем что мы получаем на плюсах я искренне жалел отдел портирования :)
Фишка в том что если какой-то кол-во раз вызвать gc для реализации явы от того вендера, то он гарантированно пройдётся и срберёт мусор.
Это делалось, например, после освобождения больших картинок, ибо последующая загрузка новой картинки вызвала бы гарантированный креш игры из за нехватки памяти. А там мы её выдерали у ГЦ :)
Этот код писал не я — у нас был отдел портирования, который знал все нюансы поведения явы на разных телефонах, и собирал сто пицот миллионов билдов для разных трубок. Яже немного писал логику игр на яве, а потом в мессе занимался портом с J2ME на C++ (Symbian, Palm, PocketPC и так далее), и глядя в код портов для разных трубок, сравнивая его с тем что мы получаем на плюсах я искренне жалел отдел портирования :)
Весело. Мне интересно как об этой фишке вообще узнали, видимо кто-то был очень зол на сборщика :)
К сожалению этого я не знаю — были сайты, которые собирали всякие разные «особенности» разных трубок, для облегчения жизни портеров.
Сейчас попытался найти код 2005-6 годов — не нашёл.
Но в более позднем нашёл похожую фишку, только со слипом:
Это я всё к тому, что кросплатформенность была весьма условная — всё равно приходилось делать и поддерживать кучу портов.
При знании таких вот нюансов, и наличии ant это дело в немалой степени автоматизировалось, но всё равно — «write once run anywhere» в реальных мобильных приложениях и близко небыло.
Сейчас попытался найти код 2005-6 годов — не нашёл.
Но в более позднем нашёл похожую фишку, только со слипом:
/**
* a'la System.gc() c принудительной задержкой
* @param time long
*/
static void sleepGC(long time)
{
System.gc();
// libThread.yield();
try
{
libThread.sleep(time);
}
catch (Exception ex)
{
}
// newTime = System.currentTimeMillis();
}
Это я всё к тому, что кросплатформенность была весьма условная — всё равно приходилось делать и поддерживать кучу портов.
При знании таких вот нюансов, и наличии ant это дело в немалой степени автоматизировалось, но всё равно — «write once run anywhere» в реальных мобильных приложениях и близко небыло.
Для отладки сборщика мусора? :)
Кстати, зря вы так. При всех косяках оно всё очень и очень неплохо справлялось с гораздо-гораздо более фрагментированным парком девайсов, чем даже сейчас можно представить. Не было «слабосовместимых реализаций», было только дополнительное api вендорское, которое в случае midp2 и новее было неактуально уже. Сравнивать с нативными программами на Symbian как бы некорректно ведь. При должном старании вполне писались переносимые проги под практически любой телефон тогдашний, потому их просто куча была. Бесило там кое-что местами, конечно, но всё же. Лучше и переносимее ничего не было, да и сейчас нету по идее.
З.ы. я сам довольно много писал.
З.ы. я сам довольно много писал.
Если говорить именно о главных причинах длительного доминирования Java, их три: простота языка, кроссплатформенность и стардартизация. То, что нужно для серьезного восприятия технологии.
1. Никто не будет спорить, что по меркам того времени после C++, Delphi и подобных простота и лаконичность Java вкупе с GC давала огромную фору. Кроме того, достаточно полный и продвинутый API позволял легко сделать нетривиальные вещи. Достаточно низкий порог вхождения, сишный синтаксис и ориентированность на то, чтобы «не выстрелить себе в ногу» (напр. checked exceptions) в разы упрощала разработку.
2. Кросплатформенность. Удивительно, но код, работающий одинаково без сборки и перкомпиляции работает одинаково на чем угодно, где есть JVM. По тем временам это был настоящий прорыв. Идеология SUN (write onсe run everywhere) дала свои результаты. Это позволило легко разрабатывать и запускать даже для ни с чем не совместимых монстров. Однако, с GUI дела обстояли не так гладко. Ввиду неоднородности виджетов на разных платформах было выбрано минимальное их множество, включенное в AWT. Когда же поняли, что этого не хватает, сделали Swing, с полностью джавовским рендерингом. Но проблемы не исчезли: виджетов все-равно не хватало (по сравнению с MFC или VCL), приходилось поддерживать look-and-feel разных платформ, нельзя встраивать нативные компоненты, etc. Однако возможность писать игрушки для статичных в то время вебстраниц привлекло к Java кучу разрабочиков. И поспособствовала этому именно Microsoft, включив свою Java 1.1 в Windows. После иска Sun к Microsoft те потихоньку выпилили Java из Windows и вместе с этим прошел бум на аплеты: реально в то время мало юзеров с диалапом хотели тащить многотонную JVM от сан. К тому же MS JVM работала с графикой в разы быстрее, быстрее пускалась и отжирала меньше памяти. («Приложеньице запущено» — для тех, кто помнит ;)
3. В SUN быстро поняли, что кроссплатформенность может быть полезной штукой и в разы упрощала написание серверных приложений (опять же по тем временам). И тут ребята подошли со всем размахом и серьезностью. Они начили активно пиарить Java как серверную платформу. Заручились поддержкой других компаний (IBM, Oracle,...) и создали JCP. Типа теперь в рамках всеобщей совместимости мы будем вместе заключать стандарты, а каждый производитель уже будет сам дописывать имплементации. В JCP родилось такое жуткое чудовище как Java ынтерпрайз ыдишн. Писать на нем что-то удобоваримое (а именно простые веб странички) до самого последнего времени было жутко дорого, долго, и глючно. Однако провайдеры быстро поняли, что чем дороже и сложнее делается проект, тем больше бабла можно срубить на саппорте, обучении и задвигании дорогих и объективно ненужных решений. Они резко подключились к активному пиару Java среди компаний-клиентов: семинары, проспекты, статьи, работа с клиентами, ВУЗами, девелоперами… На фоне растущего пузыря доткомов и всеобщей информатизации задвинули Java практически в любую контору. В итоге когда выдрессированному клиенту презентуешь план проекта, он спрашивает: «а какой сервер апликаций вы будете использовать»? Плюс паралельно САН пыталась запилить Java в каждую стиральную машину и чайник, что естественно добавляло понтов. После развала доткомов сразу же открылась такая профитная область как недотелефоны, куда стараниями ребят из JCP и SUN, можно было залить недоигрушку и даже немного поиграть в нее.
Тем не менее, JCP на всем протяжении пеклось об обратной совместимости. Именно поэтому многие выбирают Java как технологический стандарт для своей компании. Код, написанный для самой первой JVM будет точно также работать и компилироваться в последней (естественно, теоретически).
4. Это уже второстепенная причина. Понимая, что Java — мощное орудие, но меркнущее, будучи загнанным в рамки JSR-ов и J2EE, разработчики-энтузиасты мало по малу начали писать свои библиотеки и фреймворки. По началу для себя. Потом это вылилось в разные communities, одно из них была организована самой Sun (java.net). Все это росло как снежный ком, кодовая база увеличивалась, и вот уже communities диктуют архитектуру и технологические решения (Maven, Spring, Hibernate, Struts, etc...) основная идея их всех — сделать как можно проще повседневные вещи (однако получается не всегда). Сейчас на Java, наверное, самая мощная база решений после C на все случаи жизни. Сейчас разработчик Java — это не только тот, который знает язык, но и хорошо плавает в бульоне различных околотехнологичных решений. Как это программист Java и не знает Maven/Ant?
5. Тоже второстепенное, но серьезно добавило ништяков. Это Eclipse. Долгое время SUN не могла выпустить удобоваримую IDE. По сравнению с существовавшим в то время Visual C/Basic от MS и богатством Delphi мало кому хотелось задиться за Notepad. Eclipse в то время был босяцким подгончиком для всех Java-девелоперов. Открытая архитектура позволяла дописывать плагины на все случаи жизни. Позже САН допилила свою IDE до Netbeans, но паровоз уже был угнан.
А половина причин, описанных в статье — десятые производные от этих. Как говорится, надо смотреть в корень!
1. Никто не будет спорить, что по меркам того времени после C++, Delphi и подобных простота и лаконичность Java вкупе с GC давала огромную фору. Кроме того, достаточно полный и продвинутый API позволял легко сделать нетривиальные вещи. Достаточно низкий порог вхождения, сишный синтаксис и ориентированность на то, чтобы «не выстрелить себе в ногу» (напр. checked exceptions) в разы упрощала разработку.
2. Кросплатформенность. Удивительно, но код, работающий одинаково без сборки и перкомпиляции работает одинаково на чем угодно, где есть JVM. По тем временам это был настоящий прорыв. Идеология SUN (write onсe run everywhere) дала свои результаты. Это позволило легко разрабатывать и запускать даже для ни с чем не совместимых монстров. Однако, с GUI дела обстояли не так гладко. Ввиду неоднородности виджетов на разных платформах было выбрано минимальное их множество, включенное в AWT. Когда же поняли, что этого не хватает, сделали Swing, с полностью джавовским рендерингом. Но проблемы не исчезли: виджетов все-равно не хватало (по сравнению с MFC или VCL), приходилось поддерживать look-and-feel разных платформ, нельзя встраивать нативные компоненты, etc. Однако возможность писать игрушки для статичных в то время вебстраниц привлекло к Java кучу разрабочиков. И поспособствовала этому именно Microsoft, включив свою Java 1.1 в Windows. После иска Sun к Microsoft те потихоньку выпилили Java из Windows и вместе с этим прошел бум на аплеты: реально в то время мало юзеров с диалапом хотели тащить многотонную JVM от сан. К тому же MS JVM работала с графикой в разы быстрее, быстрее пускалась и отжирала меньше памяти. («Приложеньице запущено» — для тех, кто помнит ;)
3. В SUN быстро поняли, что кроссплатформенность может быть полезной штукой и в разы упрощала написание серверных приложений (опять же по тем временам). И тут ребята подошли со всем размахом и серьезностью. Они начили активно пиарить Java как серверную платформу. Заручились поддержкой других компаний (IBM, Oracle,...) и создали JCP. Типа теперь в рамках всеобщей совместимости мы будем вместе заключать стандарты, а каждый производитель уже будет сам дописывать имплементации. В JCP родилось такое жуткое чудовище как Java ынтерпрайз ыдишн. Писать на нем что-то удобоваримое (а именно простые веб странички) до самого последнего времени было жутко дорого, долго, и глючно. Однако провайдеры быстро поняли, что чем дороже и сложнее делается проект, тем больше бабла можно срубить на саппорте, обучении и задвигании дорогих и объективно ненужных решений. Они резко подключились к активному пиару Java среди компаний-клиентов: семинары, проспекты, статьи, работа с клиентами, ВУЗами, девелоперами… На фоне растущего пузыря доткомов и всеобщей информатизации задвинули Java практически в любую контору. В итоге когда выдрессированному клиенту презентуешь план проекта, он спрашивает: «а какой сервер апликаций вы будете использовать»? Плюс паралельно САН пыталась запилить Java в каждую стиральную машину и чайник, что естественно добавляло понтов. После развала доткомов сразу же открылась такая профитная область как недотелефоны, куда стараниями ребят из JCP и SUN, можно было залить недоигрушку и даже немного поиграть в нее.
Тем не менее, JCP на всем протяжении пеклось об обратной совместимости. Именно поэтому многие выбирают Java как технологический стандарт для своей компании. Код, написанный для самой первой JVM будет точно также работать и компилироваться в последней (естественно, теоретически).
4. Это уже второстепенная причина. Понимая, что Java — мощное орудие, но меркнущее, будучи загнанным в рамки JSR-ов и J2EE, разработчики-энтузиасты мало по малу начали писать свои библиотеки и фреймворки. По началу для себя. Потом это вылилось в разные communities, одно из них была организована самой Sun (java.net). Все это росло как снежный ком, кодовая база увеличивалась, и вот уже communities диктуют архитектуру и технологические решения (Maven, Spring, Hibernate, Struts, etc...) основная идея их всех — сделать как можно проще повседневные вещи (однако получается не всегда). Сейчас на Java, наверное, самая мощная база решений после C на все случаи жизни. Сейчас разработчик Java — это не только тот, который знает язык, но и хорошо плавает в бульоне различных околотехнологичных решений. Как это программист Java и не знает Maven/Ant?
5. Тоже второстепенное, но серьезно добавило ништяков. Это Eclipse. Долгое время SUN не могла выпустить удобоваримую IDE. По сравнению с существовавшим в то время Visual C/Basic от MS и богатством Delphi мало кому хотелось задиться за Notepad. Eclipse в то время был босяцким подгончиком для всех Java-девелоперов. Открытая архитектура позволяла дописывать плагины на все случаи жизни. Позже САН допилила свою IDE до Netbeans, но паровоз уже был угнан.
А половина причин, описанных в статье — десятые производные от этих. Как говорится, надо смотреть в корень!
Я думаю, что случайность существеннее в разы, чем все три предложенных Вами аргумента вместе взятые. Подробнее тут.
А зачем знать Maven/ant? Мавен надо сконфигурить раз (кому-нибудь одному) и пользоваться всей командой. То же и анта касается.
Я имел ввиду не столько сам Maven, сколько всю архитектуру проекта: технологии, тулзы, фреймворки, библиотеки. У джавелоперов любой проект начинается с горячего обсуждения что из этого будет использоваться. Кто-то за Maven, кто-то за Gradle. Кто-то за Spring, кто-то за Guice. Кое-кто предлагает webservice, а другой ему отвечает, что restful моднее. Кто-то хочет apache-commons, кто-то привык к guava, etc… Тем не менее, любой уважающий себя джавелопер должен их знать и уметь пользоваться некоторыми из них. То есть джава — это уже не только язык+API, но масштабируемая платформа с готовыми технологическими решениями.
Я сам большой любитель платформы Java и считаю, что она мегакрутая. И аргументы у автора оригинала вполне достойные. У меня есть только одно, но концептуальное возражение предложенному в статье ретроспективному анализу: задним числом можно объяснить всё, что угодно. И найти хоть 12 причин, хоть 112. Есть масса прекрасных технологий, которые сочетают в себе и многие из перечисленных и массу иных достоинств. Но они не получили и сотой доли популярности Java.
На тему объяснений явления задним числом, есть классная книга Талеба. Вот, например, статья на википедии. Обратите внимание на пункт 3 раздела «Критерии события типа «чёрный лебедь».
На тему объяснений явления задним числом, есть классная книга Талеба. Вот, например, статья на википедии. Обратите внимание на пункт 3 раздела «Критерии события типа «чёрный лебедь».
Согласен, хороший дизайн решения — это лишь половина от необходимого для популярности технологии. Есть много нетехнических факторов. Сан много лет вкладывал громадные ресурсы в развитие технологии, Оракл прододажет вкладывать. Сан наделал много ошибок, из-за чего проиграл битву на поле J2ME. Но на рынке серверных технологий была проблема разрозненности серверных платформ и Java стала спасением от vendor lock-in. И это еще одна причина, в довесок к перечисленным в статье и в комментариях.
С чем вы соглашаетесь?! Я такого не писал.
Я писал, что:
1. в успехе той или иной технологии/продукта/чегохотите очень велик фактор случайности.
2. задним числом можно объяснить успех или провал чего угодно.
Это концептуально. А если по фактам, то какая битва на поле J2ME? Что Sun проиграл? Вы вообще о чём?
Я писал, что:
1. в успехе той или иной технологии/продукта/чегохотите очень велик фактор случайности.
2. задним числом можно объяснить успех или провал чего угодно.
Это концептуально. А если по фактам, то какая битва на поле J2ME? Что Sun проиграл? Вы вообще о чём?
К самому языку Java у меня только одна претензия — невозможность передать функцию как аргумент (без оборачивания этого хозяйства в объект или ещё какое шаманство).
А вот к Sun, Oracle, IBM и экосистеме претензий куча. Для начала неразбериха с лицензиями и Java машинами. К примеру почему OpenJDK не всё может запустить а оракловый требует явно не свободную и ограничивающую лицензию? И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.
Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт, а в среднем гиг (тот же Eclipse).
Потом — ужасные GUI библиотеки без нормальных биндингов (Qt, GTK), помню как долго мучался что бы в NetBeans в меню шрифты стали не вырви глаз а со сглаживанием (как в системе), а про внешний вид я уже и молчу.
Собственно если эти проблемы убрать то будет хороший инструмент. Правда он тогда будет мало отличатся от C++ особенно C++11.
А вот к Sun, Oracle, IBM и экосистеме претензий куча. Для начала неразбериха с лицензиями и Java машинами. К примеру почему OpenJDK не всё может запустить а оракловый требует явно не свободную и ограничивающую лицензию? И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.
Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт, а в среднем гиг (тот же Eclipse).
Потом — ужасные GUI библиотеки без нормальных биндингов (Qt, GTK), помню как долго мучался что бы в NetBeans в меню шрифты стали не вырви глаз а со сглаживанием (как в системе), а про внешний вид я уже и молчу.
Собственно если эти проблемы убрать то будет хороший инструмент. Правда он тогда будет мало отличатся от C++ особенно C++11.
у меня только одна претензия — невозможность передать функцию как аргумент
Functional interface — наиболее подходящий эквивалент.
И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.
Потому что разным пользователям нужны разные версии, и потому, что платформа развивается.
Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт
Для эффективной работы системы с автоматической сборкой мусора нужно «пространство для маневра». А мусора — много, это особенность языка. Нет, можно писать код так, чтобы вообще выйти на некое плато и не порождать объекты, но это уже будет не совсем java-программа
Functional interface — наиболее подходящий эквивалент.
Это сколько лишней писанины по сравнению с C,C++,Ruby,Python… или я плохо документацию изучил?
Потому что разным пользователям нужны разные версии, и потому, что платформа развивается.
Разные версии чего? Языка или платформы? И разница то часто не столько в фичах сколько в брендах: dev-java/apple-jdk-bin, dev-java/hp-jdk-bin, dev-java/ibm-jdk-bin, dev-java/oracle-jdk-bin, dev-java/soylatte-jdk-bin, dev-java/sun-jdk — честно понятия не имею в чём разница. Это больше похожее на агонию, а не развитие.
Опять же в C++,Python и т.д. мире то же есть разные компиляторы и интерпретаторы но они все стараются по максимуму реализовать платформу (хотя возможно и со своими идеями), а не внести туда свои плюшки и это больше похоже на здоровую конкуренцию.
Для эффективной работы системы с автоматической сборкой мусора нужно «пространство для маневра». А мусора — много, это особенность языка. Нет, можно писать код так, чтобы вообще выйти на некое плато и не порождать объекты, но это уже будет не совсем java-программа
Python, Ruby так же имеют сборщики мусора, почему то они не весят столько (причём это динамические языки, а значит почти всё там хэш таблицы). Ну и это к слову пример почему в современном мире новые сайты (с некоторыми исключениями, как тот же Twitter) никто не пишет на Java, а пишут на PHP,Python,Ruby…
Ну и по хорошему — вот в чём плюс Java перед современным C++ с мультиплатформенными либами? В идеале Java не надо собирать для каждой платформы, на практике для Windows,Linux,MacOSX всё равно приходится делать свои сборки.
Это сколько лишней писанины
Java, конечно, не самый компактный язык. В определенных случаях поможет краткость лямбд.
часто не столько в фичах сколько в брендах
Я не так понял исходное утверждение, думал, вы про версии апдейтов.
в C++,Python и т.д. мире то же есть разные компиляторы и интерпретаторы но они все стараются по максимуму реализовать платформу
Вот тут все строго: или реализуешь платформу на 100%, или это не java. TCK все должны проходить.
Последный параграф не понял совсем. Если код с JNI — то да, а иначе — не понимаю. В чем плюс? Имхо, в разделении семантики и реального кода, исполняющего программу, что свойственно JIT системам.
ошибся веткой :(
Я, как программист на Java, очень опечален прогнозом «Java навсегда» и «длительного доминирования».
А о причинах популярности сказал давно ещё Луговский.
А о причинах популярности сказал давно ещё Луговский.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java навсегда! 12 причин длительного доминирования Java