Пользователь
0,0
рейтинг
11 ноября 2013 в 04:22

Разработка → Java навсегда! 12 причин длительного доминирования Java перевод

Java foreverЛегко забыть значимость технологии, как только она пронесется кометой через коллективное сознание и погаснет огненной смертью за горизонтом. К примеру, Cobol — когда-то этот язык был культовым для целой эпохи, а сейчас его можно сравнить разве что с протухшей рыбой. В наши дни любой хипстер-программист вам отчеканит, что Cobol – это полный отстой, старый и бесполезный язык. Java может стать следующей жертвой «актуальных» суждений.

Пик продаж книг по Java – далеко в прошлом. Матерые Java-утилиты уже не достаточно сексуальны для обложек журналов. Java уже 19 лет, а прогрессивные разработчики увлечены такими моднейшими и актуальнейшими технологиями как Node.js, Objective-C, Dart, Go и т.д., удивляясь: «Java? Этот артефакт эпохи Web 1.0 еще жив?»

Беглый поиск на Dice.com показывает, что работы на Java — навалом. Если для iOS около — 2500 предложений, для Java — более 17000. Конечно, нельзя всецело полагаться на эти цифры. Но тот факт, что на Dice.com рынок работы на Java потенциально в семь раз больше, чем для моднейшей iOS, говорит о том, «старина Java» чувствует себя довольно таки неплохо.

Может быть, это потому, что Java предлагает бизнес-план более привлекательный, чем отдать 30 процентов доходов Apple и скрестить пальцы в надежде, что ваше приложение попадет в список Top-25. В большинстве случаев, Java решает задачи, более полезные, чем помочь злым птицам отомстить не менее злым свиньям. Java является основой ряда платформ, предназначенных для разработки программного обеспечения и обеспечивающих эффективную работу на системах с разной чип-архитектурой. Java помогает решать задачи разработчикам серверных, клиентских и встраиваемых систем.

Прежде, чем мы забудем огромный вклад Java в IT-отрасль и его роль в наши дни, хотелось бы озвучить 12 веских причин, почему Java не просто выживает, но и активно процветает наши дни.

Не называйте это возвращением; Java никуда не уходила, она тут и повсеместно доминирует.

Java forever

Причина № 1: Непотопляемость в мире политики (зачастую грязной)


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

Первым большим врагом Java была Microsoft. Эта компания увидела в Java наиболее достойного преемника тому единству, которое на то время предлагал только MS-DOS. Редмонд критиковал и боролся с Java с самого начала. Java не пользовалась успехом для разработки десктоп-приложений, отчасти потому, что магическая виртуальная машина Java запускалась слишком медленно. Несмотря на небольшие притормаживания, в целом, Java приложения в Windows достаточно юзабельны.

По какой-то необъяснимой причине, Стив Джобс никогда не любил Java. Даже когда Mac в значительной степени проигнорировали все, кроме Adobe, Java не дали шанс. Java-совместимость могла бы активизировать разработку для Mac-а, но для Apple – Java всегда была актером второго плана. (В общем-то, смартфоны на iOS работают более плавно, чем мой Android, так что, возможно Стив был прав)

Java также пострадала от многочисленных внутренних разборок. В IBM любили этот язык, но всегда сражались с Sun. Решение IBM о том, чтоб назвать свою замечательную IDE «Eclipse» (Затмение), было довольно холодно принято людьми из Sun (парни из Sun никогда не понимал в бизнесе настолько хорошо, как IBM).

Не смотря на все оплошности создателей, Java стремительно укрепляла позиции на серверах и становилась пригодной для эксплуатации в десктоп-сегменте. Каждая технология должна плыть против политических течений, и в случае Java, она упорно плыла дальше, доказывая, что является отличным инструментом для решения задач.

Java forever

Причина № 2: Магия потоков


Одна из сильных сторон виртуальной машины Java, всегда была ее способность с легкостью жонглировать несколькими потоками. JVM оптимизирована для больших многоядерных машин, и она без проблем может управлять сотнями потоков. Благодаря этой способности, на JVM появились и другие языки — создаются кросс-компиляторы и эмуляторы, работающие поверх JVM.

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

Ruby является одним из современных конкурентов Java. У него более чистый, напоминающий живой английский язык, синтаксис. Но все же, когда любителям Ruby нужна высокая производительность, они обращаются к JRuby. Это версия Ruby, которая бежит поверх JVM, обеспечивая гораздо более высокую производительность при больших нагрузках с множеством потоков. Вложив кучу усилий для надежной работы с потоками, инженеры из Sun не прогадали.

Java forever

Причина №3: Java, как первый язык программирования


Java является основным языком для Advanced Placement Computer Science (Advanced Placement (AP) — учебная программа и экзамены для учащихся средней школы в США). Это означает, что зачастую, для студентов Java является первым языком программирования. Таким образом, Java дальше с ними «и в горе и в радости». Когда в дальнейшем студенты изучают новые языки программирования, они сравнивают с тем, что есть в Java. Если они даже меняют Java на что-то другое, их мнение все равно базируется на том, что они узнали «в первом классе».

У Java множество преимуществ для изучения информатики. Некоторые программисты ненавидят указывать типы данных, часто называя это «подушкой безопасности» в программировании. Это может звучать странно, но это отличный способ для новичков понять, как устроен компьютер. Требование указывать типы данных заставляет их думать о внутреннем устройстве системы.

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

Кто-то пытается продвинуть собственный язык, и в большинстве случаев создает язык с менее строгим синтаксисом, чем у Java. Это отлично, но вот более простой и чистый синтаксис таит свои опасности, которые проявляются позже. Кто-то считает, что «подушки безопасности» ограничивают их свободу в программировании, но Java прививает хорошие привычки с самого начала. В дальнейшем, накопив опыт, бывшие «новички» смогут приручить более изящные и опасные конструкции.

Java forever

Причина №4: (Почти) кроссплатформенная совместимость


Язык Java не был первым языком для написания кроссплатформенных приложений, но он стал самым популярным. Это не означает полную совместимость на разных платформах — отсутствующие библиотеки или несовместимые версии библиотек запросто похоронят ваш код. Вы не можете взять код десктоп приложения, скомпилированный под JRE 1.7 и запустить его на телефоне в Java ME. Чуда не произойдет.

Sun, а сейчас и Oracle, выжимают по максимуму для кроссплатформенности. Когда код не работает, как правило, понятно, в чем проблема. Если вы используете правильные версии Java и у вас достаточно памяти, ваш код будет работать. Java разработчики могут разрабатывать приложение на своем компьютере, а затем развернуть его на целевой платформе, будь то телефон или сервер. Если для компилятора доступны нужные библиотеки, код будет работать. Это бесценно.

Java forever

Причина № 5: Устойчивый успех Java на микрочипах


Java никогда не была популярным инструментом для разработки десктоп-приложений, но она расцвела в мобильном сегменте рынка, который, в последнее время рванул вверх. Платформа Android построена на Java от и до, и в настоящее время Android устройства продаются лучше, чем iPhone.

Это господство не в новинку. Урезанная версии языка и виртуальной машины, известные как Java ME широко использовались во многих так называемых недосмартфонах (feature phone), которые исчисляются миллионами во всем мире.

Если все это слить вместе, доминирование Java — ошеломляющее.

Java forever

Причина № 6: Blu-Ray


Язык Java когда-то назывался «Oak» предназначался для ТВ-ресиверов, где компания Sun хотела доминировать. Точно придерживаться плана не получилось, но Java все равно удалось найти уютное место в гостиной. Blu-Ray стандарт построен вокруг Java, и тому, кто хочет добавить дополнительный контент на Blu-Ray нужно будет воспользоваться Javac компилятором.

Blu-Ray диски – это не просто сырое видео. С помощью Java-кода можно изменить/добавить дополнительные функции и интерактивность. Blu-Ray диски – это смесь сжатого видео и Java байт-кода.

Java forever

Причина № 7: Фигурные скобки просто работают


Любители таких модных языков, как Ruby, Python, или CoffeeScript снисходительно наблюдают за тем, как Java (и C) принуждают программистов вставлять фигурные скобки, явно обозначая начало и конец каждого блока кода. Круглые, фигурные, и даже квадратные скобки — все это проклятие для этих прогрессивных разработчиков. (Я сам не люблю скобки, и до сих пор ностальгирует по тому, как в некоторых версиях Lisp-а можно закрыть все открытые скобки одной квадратной скобкой)

Но изменение пунктуации не устраняет сложности, а скрывает их. Использование пустого пространства для обозначения вложений заставляет вас интуитивно видеть то, что вы не можете видеть. Обозначение вложенности пробелами отлично работает, если ваше выражение помещается на одну строку, но становится ужасным, если у вас несколько уровней вложенности. Когда я пишу на Python-е, я замечаю за собой, что считаю и пересчитываю отступы. Если код выглядит как английский язык, не означает, что его также легко понять, как и предложение на английском.

Java forever

Причина № 8: Groovy


Если Java программистам нужен более чистый и простой синтаксис, динамическая типизация, это не повод сбежать к новомодным языкам. Они могут использовать Groovy, аккуратный хак Java с препроцессором, который производит JVM байт-код. Язык полностью интегрирован с Java — вы можете смело вызывать Java библиотеки из Groovy кода. Это как Java с плюшками.

Такая гибкость позволяет программистам самостоятельно конструировать решение своих проблем. Когда Groovy медленнее (такое часто бывает при использовании динамического вызова методов), программист всегда может переписать куски кода критичные для производительности на core Java.

Java forever

Причина № 9: JVM


JVM была построена и оптимизирована под типизированный код со статическим контекстом, генерируемый javac компилятором, но со временем разработчики языков поняли, что JVM может запускать код написанный не только на языке Java. Если компилятор создает корректный Java байт код, JVM не волнует на каком языке он был написан. Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.

Привлекательность очевидна. Sun/Oracle делает свою часть работы по созданию кросс-платформенной среды, а все остальные пользуются этим. Инженеры Sun/Oracle причесывают платформу и беспокоятся о совместимости, а мы пишем код на том языке, который нам по душе.

Microsoft позаимствовала эту идею (а также многое другое), создав C# и свой подход к созданию компиляторов для языков, работающих на C# VM (CLR). C # программисты говорят, что могут писать на разных языках – правда, только на VM под Windows. Удивительная гибкость!

Java forever

Причина № 10: Революция NoSQL, построенная во многом на Java


Давным-давно, база данных была непостижимым черным ящиком, который хранит информацию и быстро и эффективно отвечает на запросы. Потом пришла революция NoSQL, — программисты поняли, что могут писать свои собственные базы данных и адаптировать код к своим потребностям. Большая часть из основных игроков на рынке NoSQL была написана на Java. Cassandra, Lucene, ElasticSearch, HBase и neo4j – это лишь некоторые примеры. Кроме того, есть некоторые ACID-совместимые базы, написанные на Haskell и работающие на JVM.

Эти базы, как правило, с открытым исходным кодом и легко встраиваемы. Кто-то запускает их как независимые сервисы, кто-то встраивает их код (в виде библиотек) в свой собственный стек. В любом случае, статус Java в качестве рабочего языка на уровне базы данных гарантирует, что разработчикам на Java разобраться и работать с этими базами будет легче. Кодировки или разделители строк не будут волновать Java-разработчиков.

Java forever

Причина № 11: в этом веке рулит Minecraft


Пока Ruby продолжает собирать свою долю поклонников, следующее за ними поколение влюбляется в Java. Почему? Одно слово: Minecraft. Он написан на Java. Юные геймеры, желающие расширить Minecraft, должны знать Java, чтобы писать плагины под Minecraft. Это гарантирует, что повзрослевшие «детки» будут непременно писать на Java.

Java forever

Причина № 12: Открытый исходный код


Компания Sun всегда была одним из лидеров в Open Source сообществе, но она так и не решилась полностью освободить Java. Это не помешало Java программистам написать кучу отличных библиотек и проектов под свободными открытыми лицензиями. Проект Apache продолжает поставлять множество проектов на Java под лицензией, которая не требует многого взамен.

Sun закончила выпускать большую часть кода под лицензией GPL в 2007 году. С тех пор, компания Sun и ее новый владелец, Oracle, старались быть хорошими менеджерами для языка Java. Несомненно, Oracle подмочил свою репутацию исками к Google, но в остальном, платформу можно в значительной степени считать открытой и свободной.

Ненавистников предостаточно, но Java двигается вперед


У Java, безусловно, хватает своих проблем. Java-хейтеры будут продолжать брызгать слюной и стучать по клавиатуре, постя злостные коменты в интернете. Сборщик мусора может вызвать икоту и дрожь. Типизация данных является рутиной и не может отбраковать действительно плохой код. Аннотации слишком сложны. Новые возможности Java развиваются не так быстро, как это было в прошлом. Фигурные скобки добавляют некоторый беспорядок. Этот список можно продолжать и дальше.

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

В конце концов, это одно из преимуществ Java. Ее можно менять и использовать практически для любых задач. Вы можете заменить большинство библиотек вашим собственным кодом, если вам нужны особенные функциональные возможности. Java — очень гибкий язык с открытым исходным кодом. Независимо от ограничений языка и платформы, практические любые проблемы можно решить относительно легко. Это означает, что Java программисты продолжают быть одними из самых производительных. Несмотря на то, что книги по Java больше не доминируют в списке бестселлеров и Oracle выпускает апдейты не так часто как хотелось бы, Java продолжает не просто жить, но и процветать.
Перевод: Peter Wayner
Артем @woworks
карма
70,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (198)

  • +23
    > Но все же, когда любителям Ruby нужна высокая производительность, они обращаются к JRuby.

    Когда любителям Ruby нужна высокая производительность они обращаются к Scala :)
    • 0
      А чем, с точки зрения среды исполнения, Scala отличается от JRuby?
      • +2
        Да ничем (ну кроме того что код на JRuby всё-таки интерпретируется, а Scala — компилируемый язык).
        Мой комментарий был про Твиттер, который успешно перевел высоконагруженные части Ruby-проекта на Scala.
        • 0
          jruby вполне себе компилируется в нормальный байткод

          github.com/jruby/jruby/wiki/JRubyCompiler
          • 0
            С JRuby никогда близко не знакомился, всегда думал что это только интерпретатор Ruby на основе Java. Спасибо.
  • +4
    Про майнкрафт верно подмечено! Сам с него начинал, да и несколько друзей тоже :3
    • НЛО прилетело и опубликовало эту надпись здесь
      • +8
        игра ведь вообще не оптимизирована

        Она достаточно оптимизирована просто для того, чтобы попросту существовать, иначе бы её вовсе не было.
        • –1
          Она не оптимизирована. Она написана… но это как операция на гландах через… ну вы знаете. Вполне можно было бы достичь куда большей производительности, но авторы были не в ладах с мультипоточностью. А ещё можно было достичь большей производительности при оптимизации данных под GC.
          • +3
            А ничё, что автор писал игру в одиночку? И что, если бы обработка блоков не была оптимально сделана, то, на тот момент, игра вообще бы не была написана, потому что объёмы оперативной памяти не позволяли бы? Мультипоточность? Это дополнительная оптимизация, но никак не вообще.
            • 0
              «Ничё». Оптимально сделано (весьма относительно, кстати) и оптимизировано — разные вещи. И насчет «объёмы оперативной памяти не позволяли бы» — извините, но это насколько косоруко надо сделать?
              • +1
                Кстати вопрос не в тему, на том же xbox майнкрафт же не на java?
                • 0
                  Вот чего не знаю — того не знаю. Теоретически может с собой таскать ява-машину и запускаться в ней. Но вообще уже давно есть порты на с++, возможно это они.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Официальная вики говорит, что таки на плюсах.
                    • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Видимо вы не играли в Minecraft онлайн с сотней игроков. Сервер захлебывался от избытка многопоточности.
      • +9
        Хм, что-то Вы все в кучу смешали.

        Оптимизация конкретной игры мало что имеет общего с языком программирования, неоптимизаровано можно на чем угодно написать и обвинять язык… просто надо думать, когда пишешь, не? Да, изначальный выбор языка играет роль, но никак не влияет на отсуствие оптимизации как таковой.

        Далее, насчет попсовости андроида конечно спорно, но вот ведь в чем штука — кроме андроида огромное количество софта написано на java, те же hadoop/hbase, банковские системы — их попсовыми называть язык не повернется.

        Ну и да, конечно для каждой задачи надо подбирать подходящий инструмент, и писать сайтик на 3 странички на java — это самоубийство; на хабре встречались уже такие посты, не припомню сейчас линки, но там наглядно было видно, где проходит эта грань — когда сайт на java — это бред, а когда вся эта махина реально востребована.
        • +3
          Оптимизация конкретной игры мало что имеет общего с языком программирования, неоптимизаровано можно на чем угодно написать и обвинять язык
          Как программист я вас понимаю и Джаву уважаю, а как пользователь я не люблю Джаву из-за тормозов, глюков и корявого интерфейса в софте на ней написанном :)
          • +2
            Устраните хотя бы первый пункт, перейдите на IntelliJ IDEA, сразу 100500 проблем уйдет!
            • –2
              Вполне возможно, что он работает над RCP приложениями… Мне жалко тех, кто выбрал этот путь. Честно. Они гвоздями прибиты к Eclipse.
              • 0
                Не, ну теоретически можно писать Eclipse RCP-приложения не в Eclipse — библиотеки-то все есть. Но это отдельное извращение…
      • +1
        Да вот именно! Код майнкрафта не оптимизирован. Инструмент тут совершенно не при чём. Сила инструмента Java — на ней можно решать очень широкий круг задач. И для игры тоже подходит (если не нужно что-то новое из стандартов 3d графики).
        • +2
          если не нужно что-то новое из стандартов 3d графики

          Ну, если вас устроить OpenGL, то на Java вы можете найти всё что вам нужно! На сколько я знаю (а знаю я неплохо, потому что это именно то, чем я занимаюсь), все новые 3d-технологии поддерживаются OpenGL последней версии, а значит и Java. Хотя совсем другое дело если PhysX называть 3d-технологией.
          • 0
            Хм… А можете посоветовать биндинг для Java в OpenGL? Пару лет назад интересовался — было достаточно печально.
            • +1
              LWJGL вроде бы полностью реализовывает всё что есть в OpenGL последней версии (я сама до 3.0 только работаю, так что могу врать про 4.0+). Там же OpenAL и OpenCL есть + утилиты для таких вещей как мышь и клавиатура.

              Если что: lwjgl.org
      • +3
        Я бы могла часами рассуждать о коде майнкрафта, ведь знаю его наизусть как свой… Но что за глупый спор? Посыл-то в том, что множество мододелов выучили Java начиная модить Minecraft. Я сама обязана ему знаниями, работой и будущим.

        Другое дело, что мало модов для Minecraft сделаны нормально. Можно даже статью написать «Пример плохого дизайна: Minecraft и его моды»…
  • НЛО прилетело и опубликовало эту надпись здесь
  • +21
    Вот только синтаксис застрял в лохматых годах. И VM с никому не нужной поддержкой древних версий (это мешает той же Scala). Повторяет, похоже, этот язык путь Delphi, только гораздо масштабнее. А так, да, супер.
    • +9
      Удваиваю этого сэра. Минусуют senior enterprise architects.
    • +1
      Хотите сахара? Для этого есть Groovy. И связка Java+Groovy работает стабильно и четко.
      • +6
        Я предпочитаю Scala.
        Речь идёт о Java. И Groovy не может исправить фундаментальные недостатки самой среды VM. Где, например, те же generic реализованы через одно место.
        • +7
          … недостатки самой среды VM. Где, например, те же generic...


          «самой среды VM» — это же про рантайм, да?
          Так вот, в свете type erasure, дженерики не имеют ни малейшего шанса быть реализованными в VM через одно место.
        • +2
          Где, например, те же generic реализованы через одно место.

          Если вы про type erasure, то scala это не особо мешает. Да, pattern matching по параметризованным типам не работает (что обходится без проблем), зато ко[нтра]вариантность не требует доработок в jvm.
    • +5
      И как же это мешает Scala?
      • –2
        Также, как и новым версиям Java, как и Groovy, как и Scala. Костыли на низком уровне и сильное падение производительности без возможности это всё поправить.
        • +6
          Пример вы могли бы привести? Какие именно костыли и в каком месте мешают?
          • +3
            Например, отсутствие структур. Не нативная реализация generic, лямбд и прочих кошерных вещей — делается в Groovy/Scala через тормозные костыли. Какой-то кошмар со стандартными библиотеками (тут на хабре была статья про логирование в Java — у меня от неё волосы на голове шевелились) — в Scala поверх стандартных типов даже свои обёртки пишут.
            И вообще, Java — классный язык. Но наследие прошлого ему сильно мешает. Выпустили бы новый рантайм без совместимости, как делает .NET — цены бы ему не было.
            • +2
              А куда девать ранее написанный код?
              Все-таки очень много банковского софта под java есть и его вот так на ура не выкинешь. Было бы так все просто — то да, заменили бы. Но это ж не андроид, который раз — и все новое всосал, а старое выкинул — тут как раз проблем нет, это очень динамичный рынок. Но проблема фундаментальных языков — в совместимости со старыми версиями. В С++ те же проблемы — это очень консервативный язык.
              • 0
                [irony]Большинство банковского софта пока всё равно в лучшем случае на 1.4 работает, и там и останется.[/irony]
            • НЛО прилетело и опубликовало эту надпись здесь
              • +2
                В C# структуры являются типами значений и размещаются на стеке. Возможно, semmaxim имеет в виду это.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +1
                    И всё же, наличие структур было бы полезным в языке. Кстати, их возможно сделают в JVM openjdk.java.net/jeps/169
                    • 0
                      Разработчики JVM будут плакать, если нужно будет реализовывать передавачу структур через параметры. :)
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +1
                        В Java или JVM?
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • +1
                            А еще, например, в C# невиртуальные методы со временем стремятся превратиться в виртуальные.

                            Это с какого вы взяли? Разве что с того, что и обычные, и виртуальные методы вызываются MSIL-овской командой callvirt?

                            Насчет похожих структур: во-первых ссылка потребляет +4 (+8 для х64) байт, во-вторых уменьшается вероятность попадания данных в кэш. Может джваисты уже окончательно забили на производительность, но структура из двух интов занимает 8 байт, а вот экземпляр класса — 12, а в x64 — все 16. Я бы не хотел раздувать размер объектов в 2 раза, да и еще терять на скорости, из-за аллокации памяти в кучи, а не на стеке.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                Это связано не с MSIL, а с развитием кода. В самый неожиданный момент выясняется, что метод должен быть виртуальным, что бы его перекрыть.

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

                                Я считаю, что компилятор и среда выполнения должны быть достаточно умны, что бы самостоятельно оптимизировать код, написанный без низкоуровневой оптимизации и хаков. Можно сказать, Oracle Java вполне удовлетворяет этому требованию. Поэтому, не вижу смысла захламлять обычный код хаками и низкоуровнемыми оптимизациями.

                                какой хак? какия низкоуровневая оптимизация? Как раз в тему попадалась хаброцитата
                                «Переход на графен откроет совершенно новую эпоху — частота электронных устройств может достигнуть терагерца.»
                                exvel: Ну, слава богу. Можно продолжать говнокодить.

                                А то логика «пусть за меня это делает компьютер. Если компьютер еще недостаточно умен, чтобы решать это за меня — значит пользователям не повезло, т.к. я слишком себя люблю, чтобы париться знанием устройства ЭВМ»
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +1
                                    Заранее ничего нельзя предусмотреть со 100% точностью. Это абсолютно нормально, такова жизнь.

                                    да, но не до такой степени же, что «ой, ребят, вы мне сайт делаете, я на самом деле хотел приложение в аппстор».

                                    Заказчику не нужно ПО, которое работает на 10% быстрее и на 10% экономнее по памяти, но при этом периодически валится по непонятной причине в самый неподходящий момент.

                                    В жизни есть ценности поважнее пары сэкономленных байт.

                                    100% прирост по памяти, путем замены слова class на поле struct, это, конечно, огромные затраты ресурсов за ничтожный выигрыш.

                                    но при этом периодически валится по непонятной причине в самый неподходящий момент.

                                    ой, опять придумываете. В общем, ваша ТЗ ясна. От структур одно зло. Ваша воля — класс byte паковался бы тоже в класс, чтобы занимать в 5(9) раз больше места.

                                    Тем более, что это возможность, а не обязанность. Недостаток VM, которая просирает все типы во время рантайма, тоже предоставляется как достоинство. Круто, что сказать.

                                    Как захотели, так и извратили.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Вовсе нет. Моя точка зрения в том, что оптимизировать стоит 1% кода, который действительно является узким местом и от этого будет польза.

                                        совершенно верно
                                        А от оптимизации 99% кода сомнительными практиками типа структур

                                        а вот с тем, что использование структур это плохая практика — категорически не согласен. Вряд ли бы вам понравилась запись
                                        int a = 5; int b = a.Clone()
                                        из-за того, что иначе a и b указывали бы на пятерку, а не присваивались просто и понятно.

                                        Естественно, я говорю про иммутабельный структуры с полями read-only.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • +1
                                            Ну например строки в C# — иммутабельны. Это не мешает вполне нормально с ними работать. А то, что структуры даже если их копировать при каждом присваивании быстрее, чем объекты в куче — вы же, конечно, это знаете?

                                            А структуры по-умолчанию иммутабельны. Потому что мутабельные структуры — прекрасный способ отстрелить себе все что можно. На примере int видно, зачем могут быть нужны иммутабельные структуры.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • –2
                                                Чтобы не изменять оригинал, очевидно. Не говоря про интернирование и прочие штуки.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • –2
                                                    Если бы их можно было менять без копирования, они и небыли бы Ииммутабельными. А удобства от неизменяемости по ссылочке
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                              • –1
                                            • 0
                                              Строки в .Net — класс, а не структура. Они никуда не копируются при передаче, а вполне себе передаются по ссылке.
                                              И да, структуры по умолчанию не иммутабельны и это добавляет геморроя.
                                              • 0
                                                Строки — класс. Но они неизменяемые. Если пример структуры, то DateTime, ну и хотя бы тот же IEnumerator, причем последняя — мутабельная.
                                                • 0
                                                  IEnumerator — интерфейс. При чем тут вообще структуры?
                                                  • 0
                                                    Энумераторы, реализующие его, например ListEnumerator — мутабельные структуры.
                                                    • 0
                                                      Если их использовать как IEnumerator, то они будут висеть в хипе, а на стеке будет только указатель на IEnumerator. Так что зачем вы тут вообще IEnumerator вспомнили?
                                                      • 0
                                                        Они будут на стеке, вызов методов будет разве что через интерфейс.

                                                        К чему вспомнил: вот это — действительно отстрел ноги, можете попробовать этот код для просветления:

                                                        var x = new { Items = new List<int> { 1, 2, 3 }
                                                                .GetEnumerator() };
                                                        while (x.Items.MoveNext())
                                                        {
                                                            Console.WriteLine(x.Items.Current);
                                                        }
                                                        


                                                        Кстати еслиб энумератор был «в хипе», то этого эффекта не наблюдалось бы.
                                                        • 0
                                                          Я же специально вам указал: «Если их использовать как IEnumerator». GetEnumerator у List<int> возвращает List<T>.Enumerator. Вы попробуйте привести его к IEnumerator или лучше List<T> предварительно привести к IList<T> и получите размещение в хипе.
                                                          • 0
                                                            Ладно, уже ушли от темы, и возможно, я не прав, так что тем более нужно перевсти тему :)

                                                            Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя, если не хочется за каждым чихом писать код на другом, более низкоуровневом языке (С++ тот же). Андройд выпустил целый NDK, потому что java-приложения часто из-за своей высокоуровневости и абстракции не обеспечивали нужной производительности.

                                                            Никто не заставляет ими пользоваться. Но само их наличие — это очень нехилый буст для определенных задач.

                                                            Если нужен иммутабельный класс (той же даты), то её логично сделать структурой — получаем бонус от thread safety и прочего. Если не нужно — пишем обычный класс и не пытаемся себе отстрелить ногу мутабельными структурами.

                                                            В общем, имхо — это ценная возможность, которую нужно уметь применять, потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций, а несколько больше. Не всегда узкое место — медленная выгрузка из базы по узкому каналу, иногда и так бывает.

                                                            Ваше мнение: для низкоуровневых задач использовать С/С++ (насколько я понял из речей выше), мое — хорошо, когда все есть в одном языке и не нужно возиться с P/Invoke. И то и то имеет право на жизнь, но мое мнение, логично, я считаю более правильным (иначе бы я его изменил на ваше :) )
                                                            • +1
                                                              Смешались в кучу кони, люди...


                                                              Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя

                                                              При этом в качестве примера приводите крайне не очевидный баг, вызванный наличием этой части языка. И тут же, кстати, в ответ получаете, что при правильном использовании плюсы теряются (улетает в хип).

                                                              В java есть escape analysis, позволяющий размещать данные в хипе, не напрягая программиста и не плодя криптобагов.

                                                              то её логично сделать структурой — получаем бонус от thread safety и прочего

                                                              Как вообще структуры связаны с thread safety? Неизменяемый класс ни чуть не менее thread safety, чем структура. Посмотрите на scala и akka — весьма безопасная многопоточность благодаря удобным неизменяемым классам и механизмам работы с ними (на jvm).

                                                              потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций

                                                              Я знаю только 2 профита от структур: тяжелая арифметика и размещение в массиве. Это полезно в очень редких случаях. При этом на jvm можно таких же улучшений добиться, хоть и с чуть большими затратами.

                                                              Ваше мнение

                                                              Я вообще ни чего подобного не писал. Мое мнение выше: есть крайне узкая ниша полезности структур в C# и не то, чтобы без них не обойтись.
                                                              • 0
                                                                При этом в качестве примера приводите крайне не очевидный баг, вызванный наличием этой части языка. И тут же, кстати, в ответ получаете, что при правильном использовании плюсы теряются (улетает в хип).

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

                                                                Как вообще структуры связаны с thread safety? Неизменяемый класс ни чуть не менее thread safety, чем структура. Посмотрите на scala и akka — весьма безопасная многопоточность благодаря удобным неизменяемым классам и механизмам работы с ними (на jvm).

                                                                неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.

                                                                Я знаю только 2 профита от структур: тяжелая арифметика и размещение в массиве. Это полезно в очень редких случаях. При этом на jvm можно таких же улучшений добиться, хоть и с чуть большими затратами.

                                                                может в этом дело — последнее время я работаю с массивами структур, в частности при триангуляции объектов в 3d-моделировании, над которыми, соответственно, проводятся довольно непростые вычисления…

                                                                Я вообще ни чего подобного не писал. Мое мнение выше: есть крайне узкая ниша полезности структур в C# и не то, чтобы без них не обойтись.

                                                                а я говорил, что без них нельзя обойтись? Просто если можно их в язык поместить — почему бы и нет, если есть сценарии, когда они удобны. Они применяются не часто, но всегда по делу.
                                                                • +1
                                                                  неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.

                                                                  С чего бы вдруг? Да, копирование структуры довольно быстро происходит, но создание экземпляра неизменяемого класса происходит 1 раз, а копирование структуры — при каждой передаче. Так что где тут «быстрее»? Да и в случае многопоточности передача между потоками — через хип. А если нет передачи между потоками, то в бой вступает escape analysis.

                                                                  Ну и да, чтоб immutable данные не ели совсем уж неприличное количество памяти надо использовать персистентные типы данных. А их со структурами не добиться — то есть просядем по памяти.

                                                                  Но вообще я в этот спор ввязался только из-за вашего смешивания неизменяемости и структур.
                                                              • 0
                                                                В java есть escape analysis, позволяющий размещать данные в хипе

                                                                в стеке, ошибочка.
                                                                • 0
                                                                  Но вообще я в этот спор ввязался только из-за вашего смешивания неизменяемости и структур.

                                                                  Я несколько оговорился. Я не путал, я постулировал, что
                                                                  1.Структуры обязаны быть неизменяемыми.
                                                                  2.Изменяемые структуры — путь мучений и невзгод.
                                                                  3.Неизменяемые структуры — при правильном подходе могут дать хороший буст в некоторых сценариях

                                                                  В общем то остальное — косноязычие при попытке сформулировать и доказать эту мысль. В частности, попытки доказать, что этих сценариев не так уж мало, чтобы «Забить на них», как в джаве. Хотя и там, насколько я помню, существует выделение памяти на стеке, только там оно автоматизированно. насколько я помню.
                                                                  • 0
                                                                    Хотя и там, насколько я помню, существует выделение памяти на стеке, только там оно автоматизированно. насколько я помню.

                                                                    Погуглите escape analysis. Я раз 5 повторил этот термин. Jvm самостоятельно заботится чтоб при размещении на стеке не возникало криптобагов.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • 0
                                                Да, несколько косноязчыно сказал. Мысль в том, что выделение памяти для структур заключается всего лишь в увеличении указателя стека, причем память под все локальные переменные выделяются вообще одной инструкцией. В то время как выделение памяти с помощью newobj несколько более затратно (хотя и намного быстрее, чем new в каком-нибудь C++). Ну и то, что структуры уничтожаются сразу при выходе из области видимости (по той же причине со стеком), а объекты должны пережить сборку мусора. Особенно если это объекты с финализаторами.

                                                И даже множественные присвоения стэковой переменной получаются быстрее, чем изменение переменной по ссылке. Естественно, граничные условия в которых все наборот — существуют, но в целом картина такая. Если бы от структур не было бы толка — их не стали бы вводить в язык. Обошлись бы классами, а для взаимодействия с неуправляемым кодом позволили бы классам также иметь атрибут ClassLayout, например
                                                • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                В данном контексте под структурой понимается тип, хранящийся в стеке. Т.е. «такой же» как int, только пользовательский.

                • +1
                  Тип, хранящийся на стеке — неправильное определение структуры. Если структура — поле класса, то эта структура будет храниться в куче вместе с объектом. Просто там не будет ссылки.
                  • 0
                    Конечно, я и не говорил, что это правильное определение. Я написал то, что должно было заинтересовать человека из мира Явы, не знакомого с такой концепцией вовсе. А уж с деталями он разберется, если откроет первую же статью по теме.
                    • +1
                      Ага, и в первой статье будет написано, что структуры хранятся на стеке.
                      • 0
                        Когда мне говорят про то, что структуры — это типы данных, хранящиеся на стеке, мне всегда вспоминается эта знаменитая статья Липперта.
              • –1
                Вы что С не проходили?
              • +3
                «Структуры» в терминах .net — это определенные пользователем value-типы. Т.е. типы с семантикой копирования, а не передачи по ссылке. Как int-ы и float-ы.
                • –3
                  Структуры в терминах C++ в общем-то то же самое
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Я не понял, как это противоречит тому, что C++ структуры то же самое, что и структуры в C#?
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Возможно он прав, если я правильно понял его мысль.
                          Значимые типы могут размещаться в памяти и передаваться по ссылке, достаточно привести к object.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +3
                    Соотносится с бритвой просто: если бы они были не нужны — их бы не было.

                    Value-типы как правило нужны когда:
                    — нужно компактно хранить или быстро обрабатывать что-то
                    — при взаимодействии с внешними библиотеками.
                    — где нужна value-семантика. Например Nullable<> или какой-нибудь Vector<>.

                    В ситуациях когда они нужны, они безусловно облегчают жизнь. Потому что если бы их не было, их бы пришлось как-то имитировать другими средствами. Например юзать float[] вместо List, жонглировать байтиками и смещениями, запоминать что Nullable — это ссылка на контейнер с ссылкой, что ведет к неприятным эффектам.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +1
                        Но для компактности и быстрой обработки лучше хранить данные по полям в массиве, а не в структуре, т.к. нет потерь на выравнивание и т.п.


                        В .NET структуры можно выравнять, как и в си. Т.е. физически массив структур будет разложен в плоский кусок памяти, но для программиста это не будет набор несвязанных int-ов, а именно массив строго типизированных сущностей с разными полями.

                        Мысль не понял. В чем проблема обмена объектами?


                        Внешними для .net библиотеками, например с API операционных систем, заточенными под си, и требующими передать ссылку на правильно выравненную структуру.

                        В ситуациях, когда оператор GOTO безусловно облегчает жизнь. Потому что если бы его не было, его пришлось бы как-то имитировать средствами if, while и т.п… Нет, не так?


                        Наоборот. В Java ты вынужден эмулировать семантику структур, например через ByteBuffer. В .net есть фича, умеющая это делать прямо.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Есть там возможность указать нужное выравнивание, порядок байт, объединения (union)?


                            Есть. Атрибутами «StructLayout» и «FieldOffset» можно явно указать размер и смещения полей в структурах. Union делается этим же средством.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                Понятно что порядок байт short, int и long будет такой же как и на платформе. Смысл ведь как раз в этом — избежать лишней прослойки, типа берем кусок памяти и сразу как с родным числом работаем.

                                Если нужно Little-endian — можно сделать какую-нибудь обертку — какой-нибудь struct LittleEndianInt32 с пропертью Value, которая будет конвертировать туда-сюда.
                        • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              При этом почему-то зверский хайлоад типа твитера, сервер-сайда многих онлайн-игр и инвест-банки живут на JVM, а не на CLR
              • +2
                А это как раз и есть плюс совместимости — код, написанный ранее, успешно функционирует и нет никакой необходимости тратиться на переписывание рабочих движков, а новые фичи можно писать на новом.
            • 0
              Очень интересует «Причина № 6», есть ли данные о том, столько программистов работают над созданием Java-интерактива дисков и какие диски приобрести, чтобы сильнее впечатлиться работой этих программистов.
            • +3
              Можно поподробнее про тормозные костыли с generic'ами? В рантайме никаких generic'ов нету (и правильно) — там нечему тормозить.
              • +3
                Не вижу плюсов в том, что в JVM в рантайме дженериков нет. Кроме того что это было проще сделать. Минусы же очевидны — с value-типами нельзя и шага сделать шага без боксинга.
                • 0
                  Плюсы — скорость, простота, совместимость. Для value-типов можно сделать специализацию на конкретный тип.
                  • +5
                    Скорость — определенно нет, боксинг же.
                    Простота — для реализации JVM — да, для программиста — нет. Программисту просто — это когда можно List и Dictionary<int, string>, и это все работает без фокусов.
                    Совместимость — как по мне проблема высосана из пальца. В .NET дженерики только со второй версии появились, но все прошло довольно гладко.
                    • +2
                      Скорость определяется не только боксингом.
                      Dictionary<Integer, String> — это проблема Java, а не JVM. В Scala я пишу Dictionary<Int, String>.
                      Generic'и в рантайме мешают развитию других языков, потому что CLR навязывают свою жесткую систему типов. Я про такую совместимость говорил. Например, в Scala можно присвоить List<String> к List<Nothing>, если список пустой. А в .NET такого сделать нельзя, потому что нельзя отнаследовать Nothing от любого объекта. Поэтому реализовать Scala на CLR либо очень трудно, либо невозможно.
                      • +3
                        В Scala я пишу Dictionary<Int, String>.

                        И это наверняка транслируется в Dictionary<Integer, String>, со всеми боксингами.

                        В мысли не держать вообще в рантайме типы есть смысл. Пример javascript показывает что и без типов можно достигать впечатляющей скорости. Пример typescript — показывает что можно сделать статически-типизированный язык поверх нетипизированного рантайма. Причем система типов там кардинально отличается от мейнстримной. Еще с динамической типизацией взаимодействие между разными языками может быть попроще.

                        С другой стороны системы типов JVM и .NET не так сильно отличаются. Приводить отсутствие generic-ов в плюсы JVM — как-то странно. Вот если бы JVM была совсем динамической, работала при этом с той же скоростью что и .NET, и имела бы несколько реализаций языков с принципиально разными системами типов — тогда да, аргумент бы прошел.

                        По факту в .NET есть DLR, которая позволяет эту идею развивать, и тот же F#, где система типов сильно не такая, но положили на CLR всё нормально. А проблема со Scala — скорее всего в том, что ее затачивали под JVM изначально.
                        • 0
                          Что значит не держать в рантайме типы? Не путаете ли вы динамическую типизацию с отсутствием типизации? Javascript держит типы, ещё как.

                          F# — аргумент не канает, потому что F# — это не OOP, а FP язык. А Scala — это OOP язык.
                          Хорошо, другой пример. Fantom изначально проектировался под JVM и CLR. И что там с дженериками? Их вообще нету в Fantom.

                          • +1
                            «Не держать в рантайме типы» — это значит что рантайм не знает что на входе были какие-то там классы, функции, ADT или что там еще. У него есть какой-то базовый набор примитивов и всё, дальше он сам как-то пытается что-то придумывать чтобы это более-менее быстро работало. Получаем большую гибкость для разработчиков языков под этот рантайм за счет большей сложности рантайма, и скорее всего скорости его работы.

                            А с ООП в F# все не хуже чем в C# и Java.
                            • +2
                              На F# никто в звдравом уме не будет писать в OOP-стиле. OOP там сделали исключительно ради совместимости с C#.
                              • 0
                                Никто не будет чисто потому что есть более понятный способ это делать — C#. Так-то там объявления классов и методов даже короче получаются.
            • –2
              Честно, говоря, из того что вы перечислили более менее подходит только отсутствие структур. Их ограничение на AnyVal и в правду есть (http://docs.scala-lang.org/sips/pending/value-classes.html). Только реально структуры востребованы только при реализации библиотек GUI.

              Про .NET в контексте Scala вообще лучше помалкивать.

              Generic — это не часть JVM. Его элементарно добавить в саму Java компилируя List в ListInteger, только хрен вы потом передадите ссылку на этот класс, в код, который ждет List.
            • +9
              Выпустили бы новый рантайм без совместимости, как делает .NET — цены бы ему не было.


              Цена была бы 0.
  • +3
    Представленные в статье первые четыре картинки — из замечательного пародийного ролика «Java vs Microsoft .NET Trailer»
    Удивляюсь, что вы не дали на него ссылку
    www.youtube.com/watch?v=13A0_QkqtaQ
    • +5
      лучше по этой ссылке
      www.youtube.com/watch?v=kLO1djacsfg
    • +1
      В оригинальной статье не было этих картинок и упоминаний о роликах, это «отсебятина» — так сказать, примечания переводчика :)
  • +2
    Пятая картинка из Java Life: www.youtube.com/watch?v=b-Cr0EWwaTk
    И к этим двум роликам всегда идёт прицепом Java Zone: www.youtube.com/watch?v=Mk3qkQROb_k
  • +9
    Вопрос: почему при всей крутости Java, огромное количество (большинство?) приложений, написанных на ней, выглядят так отвратительно под Windows? Нет, Intel, правда?

    А вообще статья ну уж слишком холиварная.
    • +6
      Вы забыли поговорку «на вкус и цвет товарища нет».
      IMHO: У меня вот мнение что Windows под Windows стал выгладить ужасно.
    • +9
      огромное количество (большинство?) приложений
      Ну потому что десктоп-приложения — это никак не огромное количество и тем более не «большинство», а крошечная часть приложений на Java. А вообще на скриншоте просто «ненативный» l&f одного конкретного, хоть и вроде как «стандартного», gui-фреймворка. Java это ж язык, а не набор виджетов, она не имеет никакого отношения к виду программ, на Java можно написать gui так, что и не отличите от нативного.
      • +1
        >>Ну потому что десктоп-приложения — это никак не огромное количество и тем более не «большинство»

        Из десктоп приложений на java под Win приложения на java под Win для десктопа всё-таки составляют большинство. И вот среди них-то «огромное количество (большинство?) приложений» таки да, выглядят не очень.
        • +2
          Мне так и не удалось понять что имеллось в виду в первом предложении, но раз выглядят не очень, значит и не было такой цели
          • +7
            Раньше было все просто: одно приложение — одна операционка, все круто.
            Потом приперлась java с ее мультиплатформенностью.
            И вот ведь проблема — теперь надо вид приложений делать под все операционки! Засада! Раньше надо было новое приложение писать. А теперь только морду меняй — и все недовольны. Давайте жить проще: нет приложения — нет проблемы. А коль есть — так сразу видите ли морда ее не так выглядит…

            А вцелом java ставит перед разработчиками новые проблемы — поддерживать нативный вид на множестве платформ, и это не так просто с наскоку решить.
            • +1
              Нативный вид, как уже писали в комментах, добавляется в свингах одной строчкой обернутой в try-catch
    • +2
      Разработчики не прописывают стили в Swing, если я правильно вас понял.
      • 0
        Если под «прописывают стили» вы имеете в виду внешний вид приложения, то, конечно, можете с gui делать что хотите. Т.е. можно использовать готовые «шкурки» («look and feel»), можно использовать нативные (на винде будет как любое другое виндовое приложение), можно делать свои и тогда, как уже написано выше, gui может выглядеть как угодно
        • +1
          Мне так кажется, что если человек пишет десктопное приложение пол линуксой — он не будет заморачиваться его видом под виндой и наоборот — слишком гиморно это. А большие продукты — они вполне адекватно выглядят. Но вцелом кастомизация под морду ОС — это какбэ вторая задача, главное — юзабилити, а картинки — потом.
    • +2
      Нативно выглядящие приложения на Java вполне себе реальны при использовании SWT. Например Eclipse посмотрите. Но такое решение, к сожалению, платформозависимое. Если не гнаться за нативностью, то Swing можно прилично застилизовать.
    • +4
      Потому что прикладному программисту (тому, кто родил непонравившуюся вам поделку, а не из Sun/Oracle) было лень вставить одну строчку
      UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

      Но вообще лучше SWT…
  • +19
    Каждая вторая статья про Java — о том, что с Java все хорошо.
    • +7
      а каждая другая из двух — о том, что с Java все плохо
  • +3
    Не могу не вспомнить рекламный видеоролик о жизни мальчика в семье вендокодеров. Они ему на ночь мануалы читали, а он задавал неудобные вопросы. Потом, в юности, познакомился с симпатичной джависткой, которая его через постель заинтересовала джавой и так далее.

    Ну и недавно на башорге тоже пост видел «Хотите пригласить симпатичную HR-ку в гости — скажите, что у вас дома живет java-программер»
  • +4
    Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.

    А можно поподробнее про Haskell на JVM?
    • +2
      Я так понимаю поддерживать полный 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"
      • +2
        И еще есть Jaskell :)
      • 0
        То, что по первой ссылке я как-то смотрел, и выглядит оно заброшенными трупиками =/
        Frege выглядит более интересно. Было бы здорово послушать, если если его кто-то пробовал использовать.
  • –14
    Но тот факт, что на Dice.com рынок работы на Java потенциально в семь раз больше, чем для моднейшей iOS, говорит о том, «старина Java» чувствует себя довольно таки неплохо.

    Дальше решил не читать. Сравнение мух с котлетами не пошло.
    • +6
      Спасибо, что сообщили нам, очень информативно
  • +3
    Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.


    1. Haskell здесь вообще не к месту. Ни к Java, ни к JVM разрботка Haskell никогда не была привязана. И не будет, не надейтесь. Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.

    2. Scala / Clojure это как раз-таки пример «Java-хейтеров», как вы их назвали. Они используют JVM и байткод, но создавались именно по той причине, что у Java куча проблем (о которых в статье ни слова не сказано).
    • +3
      Как еще Рич Хикки (создатель Clojure) говорил: «Это нормально — ненавидеть Java и любить JVM».
    • +2
      Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.

      Мне не понятна причина. Раскроете? Гугл вот говорит, что этой темой занимаются.
  • –2
    Да, язык Java по-своему хорош, с этим спорить не буду. Но, то что было описанно в этом посте, меня «удивило». Вот, к примеру:
    Вы можете заменить большинство библиотек вашим собственным кодом, если вам нужны особенные функциональные возможности.


    Тот же пример с Minecraft-ом. Это все чего было хорошего написано на Java?
    • +3
      Нет, на Java всего лишь живет почти весь бизнес софт: все банки, промышленность и т.п. (думаю, в РФ тоже).
  • 0
    Жаль, только, что этого нет в тексте поста.
  • +7
    По пунктам
    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) — как-то забывают. Так что выбора у них особо не было.

    Вывод: я сравниваю с шарпом просто потому, что эти языки прямые конкуренты. Но это конкуренты, а не враги! Вся статья пропитана фанатизмом и нонконформизмом. Жаль, что есть люди, у которых микроскопы — в друзьях, а лупа — злейший враг.
    • +2
      6. Блю-рей. Вывод: возможно, сказана правда, никогда ими не пользовался: кино и цифровой контент наше все.

      Имеется ввиду BD-J. Это лишь небольшая часть стандарта, так что то, что «Blu-Ray стандарт построен вокруг Java» — очень сильное преувеличение. Но то, что Java там используется — правда.
    • 0
      Зачем-то упоминают андройд, который наоборот, пытается избавиться от Dalvik и переходит на ART.


      Что, по сути, является тем же, но в профиль. Вместо JIT компиляции в runtime будет JIT в install-time. Java никуда не уходит.
      • +1
        Но когда говорят, что приложение «ну чуть-чуть медленее, чем нативное», как в этой статье — откровенно лукавят, не так ли?
        • 0
          Вроде ж про кроссплатформенность речь была, а не производительность.

          По поводу нативности: что такое нативное приложение на андроиде? С каким «нативным» подходом происходит сравнение, если речь идет не в контексте андроида?
          • +1
            Несмотря на небольшие притормаживания, в целом, Java приложения в Windows достаточно юзабельны.

            Вот — конкретная заявка на производительность.

            Про нативное — в контексте андройда и десктопа.
  • +4
    В одном из пунктов промелькнула критика в отношении кроссплатформенности C#, но про Mono никто не сказал. Достаточно кроссплатформено, и именно моно и растущая армия c#-разработчиков в ближайшем будущем могут вторгнуться на рынок серверных разработок.
    • +1
      Я конечно, поставлю Вам плюс за камент, но скажу при этом, что Вы гадаете на кофейной гуще.

      Mono по сравнению с .NET это жалкая бажная поделка. Сравните количество QA, которые работают над Mono и над .NET. Серьёзный шаг вперёд для .NET на линуксе будет сделан только если Microsoft этого захочет и этим займётся.

      Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?
      • –1
        Разве количество специалистов, работающих над средой выполнения — это показатель? Сколько не спрашивал — у всех mono работает без проблем и в продакшн на серверах уже используется.
        • +1
          конечно показатель. И количество вбуханных денег показатель.

          Чтобы какой-то продукт «работал без проблем и в продакшн на серверах использовался» кто-то должен довести до продакшен-качества. Кто это делает в случае с моно?
      • –4
        > Mono по сравнению с .NET это жалкая бажная поделка. Сравните количество QA, которые работают над Mono и над .NET. Серьёзный шаг вперёд для .NET на линуксе будет сделан только если Microsoft этого захочет и этим займётся.

        Есть Xamarin, который сделал Моно более чем портабельным, стабильным и платным.

        >Что касается растущей армии .NET-разработчиков — это вообще спекуляция. Там динамика на уровне погрешности. Не говоря о том, что любые подобные рейтинги и заявления — это всё равно, что измерение средней температуры по больнице. Чтобы делать такие заявления нужны факты. Они есть у Вас?

        Есть факт, что нынешних студентов учат C# во всех вузах и это их основной язык на протяжении всего периода обучения. Коим раньше был Delphi. И с вашей стороны будет полнейшей глупость отрицать, что это никак не сказывается на рынке.

        Еще есть факт, что .net — это тренд на отечественном рынке разработки. И бизнес делает акцент на эту технологию. Если Вы не знакомы с этим рынком, то не стоит выражать дилетантское мнение вообще.

        Я и не утрвеждал, что mono вытеснит джаву, как, судя по всему, вы недальновидно восприняли мой комментарий.

        И, пожалуйста, меньше дерзости в общении с незнакомыми людьми. Вас это не красит.
        • +3
          Есть Xamarin, который сделал Моно более чем портабельным, стабильным и платным.

          Окей. Кто их крупнейшие/известнейшие кастомеры? Что на нём крутится в продакшене?

          Есть факт, что нынешних студентов учат C# во всех вузах и это их основной язык на протяжении всего периода обучения.

          Этот факт Вы сами придумали? Где пруф? Где статистика по ВУЗам? Это всё спекуляция с Вашей стороны. «Какие Ваши доказательства?»

          И с вашей стороны будет полнейшей глупость отрицать, что это никак не сказывается на рынке.

          Я проигнорирую этот дурацкий выпад в мой адрес. Насчёт рынка — см. ниже.

          Еще есть факт, что .net — это тренд на отечественном рынке разработки. И бизнес делает акцент на эту технологию.

          «Какие Ваши доказательства?»

          Если Вы не знакомы с этим рынком, то не стоит выражать дилетантское мнение вообще.

          толсто.

          Я и не утверждал, что mono вытеснит джаву, как, судя по всему, вы недальновидно восприняли мой комментарий.

          толсто.

          И, пожалуйста, меньше дерзости в общении с незнакомыми людьми.

          угрожаете?

          Вас это не красит.

          Назовите мне хоть одну причину вообще учитывать Ваше мнение.
          • –4
            Зайдите в любой университет, пообщайтесь со студентами. Статистика с мест, собранная лично.
            Какие Ваши доказательства и предоставьте мне статистику адекватных ответов с Вашей стороны, чтоб считаться с Вашим мнением :)
            Вы первый начали грубить и хамить, поэтому не удивляетесь такой ответной реакции. Отвечайте спокойно, без хамства и с уважением человеку, который с Вами общается, тогда не будет таких ситуаций.
            • 0
              Во-первых, я не удивляюсь. Видал и не таких. Во-вторых, у меня нет никакого желания отвечать Вам ни «без хамства» ни «с уважением» ни вообще как либо. Я Вас не знаю, и не горю желанием знакомиться. Оставайтесь при своём мнении, нет проблем.
              • –4
                Вы непрошибаемы. Кстати, ник Вам вполне подходит.
            • +1
              У вас какая-то альтернативная статистика. В большинстве случаев «делайте на чём хотите». Есть устаревшие программы на c/c++, есть «модерновые» — python/ruby. Требований «Java» или «C#» ещё ни разу не встречал. И используется он не более, чем в реальной разработке.
  • +6
    Интересно читать о наличии типов для понятия устройсва компьютера, когда нет явных указателей и выделения памяти.
    Интересно читать о новомодных языках как python и ruby, которые старше java.
    Интересно читать как автор не любит скобки и при том ставит под сомнение их отсутсвие.
    Интересно читать как автор пишет про блю-рей, когда есть smart tv.

    Как-то слишком односторонне и субективно повествуется.
    • 0
      Устройство компьютера это как-то совсем обобщенно, но модель памяти обязательно проходится в курсе Java.
      модный и новомодный != новый.
      Скобки это у всех субъективно, т.к. есть плюсы и минусы и там и там. Автор говорит, что они хороши для начинающих.
      Smart TV это круто, но оно уже у вас есть? Или оно как-то отменяет Blu-ray? Вот то, что оно редко используется это да.
      • 0
        Раз обобщено, то зачем автор об этом пишет?

        Когда языку много лет и он при этом активно развивается, то вряд ли на нем никто и ничего не делал и вряд ли он становится более популярным мгновенно. Если имеется ввиду популярность для веб, то совсем непонятно причем тут java, а не php.

        Я крайне не согласен в таком случае с автором, тк для новичка главное не скобки, а б**дь писать правильно, выдерживая принятые соглашения в языке, давая нормальные имена переменным и избегая партянок кода с огромной вложенностью. Если придерживаться соглашений и язык не подразумевает минификации, как js, то скобки по сути не нужны.
        • 0
          Раз обобщено, то зачем автор об этом пишет?

          либо неточности перевода, либо автору нечего было больше написать

          Когда языку много лет и он при этом активно развивается, то вряд ли на нем никто и ничего не делал и вряд ли он становится более популярным мгновенно.

          А кто сказал мгновенно? Я могу ошибаться, но руби начал активнее использоваться когда вышли рельсы, а о питоне я начал слышать чаще из-за гугла

          тк для новичка главное не скобки

          Не главное, конечно, но скобки помогают чуть лучше понять структуру класса для совсем начинающих.
          • 0
            Я всего лишь хотел обратить внимание что подача материала автором чересчур сомнительна. С такой подачей можно повествовать в красках о многих языках. Не скажу о руби, но рассказывать когда питон начал поставляться по умолчанию с линуксовыми дистрибутивами, когда появлялись библиотеки для вычислений, популярнейшие фреймворки, в каких программах и играх использовался можно долго.

            Что касается новичков, то они могут написать страшное, тем более существует вероятность, что могут быть использованы скобки разного стиля (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
            

            • 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
                    }
                 }
              	
              
              }
              


              Хотя, по-моему, сомнительно это приписывать к плюсам языка.
    • +1
      А почему это ruby старше java?

      Вот что молвит википедия:
      Разработка Java началась в 1990 году
      Ruby начал разрабатываться 23 февраля 1993 года


      Оба языка вышли в свет в 1995.
      • 0
        Да, действительно.
  • 0
    не в ту ветку…
  • +1
    > Java никогда не была популярным инструментом для разработки десктоп-приложений, но она расцвела в мобильном сегменте рынка, который, в последнее время рванул вверх. Платформа Android построена на Java от и до, и в настоящее время Android устройства продаются лучше, чем iPhone.

    Наврено оно и к лудшему, что не была. Большенство ява приложений выглядили топорно и чужеродно, что не добавляло им удобство использования.

    А вспомниая начало своей проф дейтельности на мобильных платформах в 2005ом — J2ME, то я до сих пор задаюсь вопросом — пошто?
    Это же был сущий ад — куча слабосовместимых реализаций j2me, масса костылей, уймы портов. И всё это замешано на очень слабом апи и жутких тормозах. По сравнению с этим программирование на Symbian, PocketPC — это было как ракета, против велосипеда с квадратными колёсами.
    Иногда ещё вспоминаю куски кода типа:
    splash = null;
    if(iMotorola) for(int i=0; i<CONST31; i++) System.gc();
    В общем было весело :)
    • +2
      Я не использовал J2ME, но как-то сложно представить вообще что-нибудь, чему бы помог вызов System.gc() в цикле
      • 0
        Может он пытался удалить таки неиспользуемые объекты, а с первого раза ГС их не удалял?:)
        • +1
          Многократный вызов System.gc() вряд ли поможет :)
          • 0
            В теории да, а вот на практике — помогал :)
            Ниже чуть подробнее описал ситуацию.
      • +3
        Я не уверен насчёт того была ли это моторола — но такой код для одного из вендеров точно был.
        Фишка в том что если какой-то кол-во раз вызвать gc для реализации явы от того вендера, то он гарантированно пройдётся и срберёт мусор.
        Это делалось, например, после освобождения больших картинок, ибо последующая загрузка новой картинки вызвала бы гарантированный креш игры из за нехватки памяти. А там мы её выдерали у ГЦ :)
        Этот код писал не я — у нас был отдел портирования, который знал все нюансы поведения явы на разных телефонах, и собирал сто пицот миллионов билдов для разных трубок. Яже немного писал логику игр на яве, а потом в мессе занимался портом с J2ME на C++ (Symbian, Palm, PocketPC и так далее), и глядя в код портов для разных трубок, сравнивая его с тем что мы получаем на плюсах я искренне жалел отдел портирования :)
        • 0
          Весело. Мне интересно как об этой фишке вообще узнали, видимо кто-то был очень зол на сборщика :)
          • +2
            К сожалению этого я не знаю — были сайты, которые собирали всякие разные «особенности» разных трубок, для облегчения жизни портеров.
            Сейчас попытался найти код 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» в реальных мобильных приложениях и близко небыло.
      • 0
        Для отладки сборщика мусора? :)
        • 0
          Выше, в ответе для Encircled я описал для чего :)
    • 0
      Кстати, зря вы так. При всех косяках оно всё очень и очень неплохо справлялось с гораздо-гораздо более фрагментированным парком девайсов, чем даже сейчас можно представить. Не было «слабосовместимых реализаций», было только дополнительное api вендорское, которое в случае midp2 и новее было неактуально уже. Сравнивать с нативными программами на Symbian как бы некорректно ведь. При должном старании вполне писались переносимые проги под практически любой телефон тогдашний, потому их просто куча была. Бесило там кое-что местами, конечно, но всё же. Лучше и переносимее ничего не было, да и сейчас нету по идее.
      З.ы. я сам довольно много писал.
  • +7
    Если говорить именно о главных причинах длительного доминирования 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, но паровоз уже был угнан.

    А половина причин, описанных в статье — десятые производные от этих. Как говорится, надо смотреть в корень!
    • 0
      Я думаю, что случайность существеннее в разы, чем все три предложенных Вами аргумента вместе взятые. Подробнее тут.
    • 0
      А зачем знать Maven/ant? Мавен надо сконфигурить раз (кому-нибудь одному) и пользоваться всей командой. То же и анта касается.
      • 0
        Я имел ввиду не столько сам Maven, сколько всю архитектуру проекта: технологии, тулзы, фреймворки, библиотеки. У джавелоперов любой проект начинается с горячего обсуждения что из этого будет использоваться. Кто-то за Maven, кто-то за Gradle. Кто-то за Spring, кто-то за Guice. Кое-кто предлагает webservice, а другой ему отвечает, что restful моднее. Кто-то хочет apache-commons, кто-то привык к guava, etc… Тем не менее, любой уважающий себя джавелопер должен их знать и уметь пользоваться некоторыми из них. То есть джава — это уже не только язык+API, но масштабируемая платформа с готовыми технологическими решениями.
  • 0
    Я сам большой любитель платформы Java и считаю, что она мегакрутая. И аргументы у автора оригинала вполне достойные. У меня есть только одно, но концептуальное возражение предложенному в статье ретроспективному анализу: задним числом можно объяснить всё, что угодно. И найти хоть 12 причин, хоть 112. Есть масса прекрасных технологий, которые сочетают в себе и многие из перечисленных и массу иных достоинств. Но они не получили и сотой доли популярности Java.

    На тему объяснений явления задним числом, есть классная книга Талеба. Вот, например, статья на википедии. Обратите внимание на пункт 3 раздела «Критерии события типа «чёрный лебедь».
    • 0
      Согласен, хороший дизайн решения — это лишь половина от необходимого для популярности технологии. Есть много нетехнических факторов. Сан много лет вкладывал громадные ресурсы в развитие технологии, Оракл прододажет вкладывать. Сан наделал много ошибок, из-за чего проиграл битву на поле J2ME. Но на рынке серверных технологий была проблема разрозненности серверных платформ и Java стала спасением от vendor lock-in. И это еще одна причина, в довесок к перечисленным в статье и в комментариях.
      • +1
        С чем вы соглашаетесь?! Я такого не писал.

        Я писал, что:
        1. в успехе той или иной технологии/продукта/чегохотите очень велик фактор случайности.
        2. задним числом можно объяснить успех или провал чего угодно.

        Это концептуально. А если по фактам, то какая битва на поле J2ME? Что Sun проиграл? Вы вообще о чём?
        • 0
          задним числом можно объяснить всё, что угодно. И найти хоть 12 причин, хоть 112

          С этим и согласен

          Что Sun проиграл?

          Рынок проиграл. Рынок инструментария и рантайма для приложений для смартфонов и т.п.
  • 0
    К самому языку Java у меня только одна претензия — невозможность передать функцию как аргумент (без оборачивания этого хозяйства в объект или ещё какое шаманство).
    А вот к Sun, Oracle, IBM и экосистеме претензий куча. Для начала неразбериха с лицензиями и Java машинами. К примеру почему OpenJDK не всё может запустить а оракловый требует явно не свободную и ограничивающую лицензию? И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.
    Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт, а в среднем гиг (тот же Eclipse).
    Потом — ужасные GUI библиотеки без нормальных биндингов (Qt, GTK), помню как долго мучался что бы в NetBeans в меню шрифты стали не вырви глаз а со сглаживанием (как в системе), а про внешний вид я уже и молчу.

    Собственно если эти проблемы убрать то будет хороший инструмент. Правда он тогда будет мало отличатся от C++ особенно C++11.
    • 0
      у меня только одна претензия — невозможность передать функцию как аргумент

      Functional interface — наиболее подходящий эквивалент.
      И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.

      Потому что разным пользователям нужны разные версии, и потому, что платформа развивается.
      Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт

      Для эффективной работы системы с автоматической сборкой мусора нужно «пространство для маневра». А мусора — много, это особенность языка. Нет, можно писать код так, чтобы вообще выйти на некое плато и не порождать объекты, но это уже будет не совсем java-программа
      • 0
        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 всё равно приходится делать свои сборки.
        • 0
          Это сколько лишней писанины

          Java, конечно, не самый компактный язык. В определенных случаях поможет краткость лямбд.
          часто не столько в фичах сколько в брендах

          Я не так понял исходное утверждение, думал, вы про версии апдейтов.
          в C++,Python и т.д. мире то же есть разные компиляторы и интерпретаторы но они все стараются по максимуму реализовать платформу

          Вот тут все строго: или реализуешь платформу на 100%, или это не java. TCK все должны проходить.

          Последный параграф не понял совсем. Если код с JNI — то да, а иначе — не понимаю. В чем плюс? Имхо, в разделении семантики и реального кода, исполняющего программу, что свойственно JIT системам.
  • 0
    ошибся веткой :(
  • –1
    Я, как программист на Java, очень опечален прогнозом «Java навсегда» и «длительного доминирования».

    А о причинах популярности сказал давно ещё Луговский.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.