[Java][Опрос] Откуда такая ненависть?

>> Для JVM есть пара десятков языков, включая Scala, Groovy, Scheme.

>И все они бешенно неэффективны, что весьма заметно сужает область их применимости

Кстати, ещё к вопрому JVM и статики/динамики.

Ещё раз обращу внимание на http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&...

Scala на JVM работает лишь в 1.6 раза медленнее чистой Java.

Для сравнения, Groovy - медленнее в 17 раз.

JRuby - медленнее в 29 раз.

(по моей памяти, Jython 2.0 медленнее Java тоже в 29 раз, правда, не на широком спектре тестов, а на одном рекурсивном Фибоначчи)

> Так как Scala, например, итак имеет скорость, равную C# на mono.

Только если не использовать сложные фичи языка.

> Я не знаком с ML.

Тогда не надо было так обобщать, про "статически типизированные языки". Как раз наиболее строгие статически типизированные языки под чрезмерно динамическую JVM компилировать оптимально и не получается.

> А про реализацию Scheme на JVM я не в курсе, но полагаю, что она динамическая.

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

Опция 1)

Java нужен для того, чтобы фирмы-производители ПО могли нанять толпы "индусов" по низкой цене. "Индусу" нельзя давать в руки C++ - сам порежется и других порежет нечаянно. И нельзя ему давать в руки динамические языки типа лиспа - он не будет знать, что с ними делать, растеряется и у него съедет крыша. А Java предоставляет прямой хорошо асфальтированный путь построения приложения, пусть и огороженный по сторонам бетонным забором с колючей проволокой. Запускаешь с одной стороны (точка А) группу индусов и можешь быть уверенным, что они не разойдутся по разным направлениям, а придут в точку Б, даже не особо утруждая моск.

Таким образом, разработка приложений получается дешевле и быстрее, но конечный продукт гарантированно не высшего сорта. Ширпотреб, типа китайской электроники, пипл хавает, все довольны. Искусство программирования - здесь это понятие неприменимо, и это даже уже не ремесло, это конвейер, причем вынесенный в страны третьего мира. Таков тренд.

«"Индусу" нельзя давать в руки опасную бритву - сам порежется и других порежет нечаянно. И нельзя ему давать в руки электробритву - он не будет знать, что с ней делать, растеряется и у него съедет крыша. А безопасная бритва предоставляет прямой хорошо асфальтированный путь для бритья, пусть и огороженный по сторонам бетонным забором с колючей проволокой...»

5

По поводу наездов на поддержку нежабских языков в jvm. Учите история, господа. jvm создавалась под один язык, никто на этапе дизайна даже не думал о многоязычии. Глупо предъявлять требования в нереализации того, чего и не обещали. Ни о каких "искусственных" ограничениях речи нет. Дотнет же изначально сделали многоязыковым (но он вышел тогда, когда народ уже прикрутил кучу языков к jvm и собрал основные грабли). В защиту сантехников можно сказать, что они постепенно двигают jvm в эту сторону, расширяют байткод. Но тут важнейшее слово "постепенность". Ниша жабки, в основном - ынтерпрайз, а там революций не любят. Потихоньку надо, семь раз отмерь, тише едешь...

> "Индусу" нельзя давать в руки опасную бритву - сам порежется и других порежет нечаянно

Язык программирования - это все-таки не средство гигиены, а инструмент. И когда он намеренно сделан тупым... Ну ты понял.

А меня Java заколебала тем, что там нельзя память освободить. Я знаю, что для индусов это лучше. Но для меня-то...

5. Выучил и не использую

> А меня Java заколебала тем, что там нельзя память освободить

Зачем?

Java как язык не люблю... ну, вы поняли, индус-стайл, бондаж и анальная доминация.

Java как платформа... Стандартная библиотека, при всей свой вылизанности, пропитана всё тем же жабьим духом, с дурным переизбытком ООП - даже если использовать более человеческий язык типа Scala, библиотека всё равно будет сильно связывать руки. Претнзии к VM - отсутствие value-типов, как тут неоднократно было говорено, через это легендарная жручесть по памяти. Отсутствие даже намёка на AOT-компиляцию в сановской реализации - в отличие от мелкомягкого дотнета. О мелочах типа ограничения на размер метода и отсутствия подхвостовой рекурсии в этом треде уже говорили. Плохая, негодная VM. Пресловутый invokedynamic, на который все молиться готовы, будет работать только для жабской модели наследования, множественное наследование не поддерживается (Jython как был тормозом, так и останется).

Только не подумайте, что я сторонник дотнета, там проблем ещё больше, но об этом в следующих сериях. Оставайтесь на связи, лол.

> > А меня Java заколебала тем, что там нельзя память освободить

> Зачем?

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

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

Что за ахинея? Тебе уже привели в пример Scala. Мало? С чем ты еще хочешь дружить жабу?

>Теперь, если надо вклиниться в развитую J2EE-инфраструктуру, то придется писать на Java, даже если это откровенно неподходящий язык для решения такой задачи.

Угу. А dotNET наше всё?

>Это когда речь идёт о разнице в 2-3 раза в скорости. Но тут разница в десятки и сотни раз - и это становится уже неприемлимым не только в узких местах, но и вообще для всего кода.

Что за ахинея? Приводи ссылку в подтверждение.

>Кстати, в случае со Scala-ой речь примерно о такой разнице и идёт, ЕМНИП.

В случае со Scala речь идет о 1-3% отставания от Java байткода.

Знамя ахинеи продолжает нести Legioner. Я сходил за попкорном.

>Например, тот же сложный логический движок, который в реальном времени должен на основании анализа потоковых данных решение принимать, на Java реализовывать заколебёшься,

Странно, почему тогда все брокерские системы в NY пишут на жабе, а не на ассемблере?

>Там этой типизации - с гулькин хер. Даже нормальных value types не предусмотренно, в отличии от .NET.

Value types? Это такой костыль, объекты без методов? Ну и зачем они нужны, если есть просто объекты? Value types не нужны© LOR

> Value types? Это такой костыль, объекты без методов? Ну и зачем они нужны, если есть просто объекты? Value types не нужны© LOR

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

>dotnet тоже открытая платформа. См. mono :)

Тоже мне открытая. Запусти ка мне под mono Ati Control Center. Запусти MS SQL Server Express 2005 Manager.

>А меня Java заколебала тем, что там нельзя память освободить. Я знаю, что для индусов это лучше. Но для меня-то...

Без тебя освободят. Ты о своей domain model лучше думай, а не о технических вещах освобождения памяти

> Value types? Это такой костыль, объекты без методов? Ну и зачем они нужны, если есть просто объекты? Value types не нужны© LOR

Тупой, да? Value type выделяется на стеке, объект - в куче. Разницу чувствуешь? В том же Managed C++ объекты через value types сделаны, между прочим.

> Что за ахинея?

Ламер, не возникай.

> Тебе уже привели в пример Scala. Мало?

Да, мало. Как только Scala становится непохожей на Жабу, она начинает тормозить. Любой хоть немного декларативный код уже не работает так, как работал бы на более адекватной виртуальной машине.

> С чем ты еще хочешь дружить жабу?

C ЛЮБЫМ языком. Вообще с любым. Сколько задач, столько и языков, и меня бесит, что авторы VM за меня решают, какими языками мне пользоваться, а какими нет.

> Угу. А dotNET наше всё?

Пока ничего лучшего нет - таки да.

> Что за ахинея? Приводи ссылку в подтверждение.

Посмотри на любую из имеющихся реализаций Схемы под JVM.

> В случае со Scala речь идет о 1-3% отставания от Java байткода.

Только если не используются продвинутые фичи языка.

> Странно, почему тогда все брокерские системы в NY пишут на жабе, а не на ассемблере?

Ты кретин. Такие движки пишут на декларативных языках. А именно они под JVM хреново компилируются. Так что, ламер, ты бы лучше не говорил о том, в чем не разбираешься, ок?

> Затем зачем обычно память освобождают.

Память в джава освобождается сама. И это правильно.

> Тут иногда поминают некого Томми. Который убил себя об стену. Когда у него Ява-машина сборкой мусора занялась.

Это бред. Если намёк на то, что GC не реалтаймовый, то есть и реалтаймовые, хотя для реалтайма джава - один из худших вариантов.

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

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

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

Толку то. Ещё дцатилетиями будем собирать грабли с поддержкой старых версий.

> Java нужен для того, чтобы фирмы-производители ПО могли нанять толпы "индусов" по низкой цене. "Индусу" нельзя давать в руки C++ - сам порежется и других порежет нечаянно.

Это всё так. Но подход Microsoft тут гораздо разумнее. Индусам дать VB.NET, а монстрам - F#, Managed C++ и System.Reflection.Emit, чтоб свои языки писали пачками под любые задачи. И всё в рамках одной VM и абсолютно интероперабельно.

Кстати, никто не тестировал Scala на JVM и .NET-е - как там с производительностью?

> > Затем зачем обычно память освобождают.

> Память в джава освобождается сама. И это правильно.

Ты наверное сильно молодой. Или прочитал всего одну книжку.

Java имеет право на жизнь. Но для МОИХ задач она неудобна. Хотя бы потому, что моя задача может отожрать памяти больше, чем есть физически на машине. При этом все уродство GC предстает во весь рост. Ну и по производительности (которая мне все-таки нужна) сильно отстает от С++.

> Ты наверное сильно молодой.

Конечно. И безмерно рад этому факту.

> Java имеет право на жизнь. Но для МОИХ задач она неудобна. Хотя бы потому, что моя задача может отожрать памяти больше, чем есть физически на машине. При этом все уродство GC предстает во весь рост.

А можно на пальцах - почему это? В смысле почему GC хуже чем рукописное управление в условиях своппинга? Не понимаю.

>Хотя бы потому, что моя задача может отожрать памяти больше, чем есть физически на машине. При этом все уродство GC предстает во весь рост.

И поэтому ты свою задачу пишешь на ... Scheme? Нет, на лиспе? Я угадал?

>C ЛЮБЫМ языком. Вообще с любым. Сколько задач, столько и языков, и меня бесит, что авторы VM за меня решают, какими языками мне пользоваться, а какими нет.

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

>Тупой, да? Value type выделяется на стеке, объект - в куче. Разницу чувствуешь?

Разницы в производительности нет. А раз разницы нет, зачем морочиться этой ахинеей?

> Разницы в производительности нет.

Сам придумал или мама сказала?

Scala на .NET сыровата пока. Нет смысла сравнивать.

> Это при том, что уже в то время прекрасно знали о необходимости многоязычия.

Зависит от того, чего хочется. Для того, что хотел Сан - не нужно многоязычие. Оно только мешает.

> Более того, лучше всех это знал один из авторов спецификации Java.

Кто? Где? (Когда?)

> Почему он остальным объяснить этого не смог - я не знаю.

Потому что они отталкивались от того, как позиционировал технологию java Sun. Кого колышат (на этом уровне) абстрактные технические умствования?;)

Я не программист, отвечу субъективно с точки зрения лоха и пользователя:

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

> При этом все уродство GC предстает во весь рост.

Жабского GC, а не GC вообще. Есть и умные GC реального времени, есть компиляторы с region analisys, много чего хорошего придумано для автоматического управления памятью. Ручное управление памятью устарело безнадёжно (причем, лет эдак тридцать назад устарело).

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

Ламер-сосунок, тебе же было велено не возникать. НЕЛЬЗЯ с JVM пользоваться любым языком. Вот напиши пару-тройку компиляторов под JVM для отличных от Java языков, а потом, шпана, возвращайся к этому разговору. До тех пор твоё мнение - дерьмо, как и ты сам.

> Разницы в производительности нет.

Разница в производительности есть, придурок.

> А раз разницы нет, зачем морочиться этой ахинеей?

Да, интересно, почему программисты на C++ так заморачиваются, стремясь всё на стек перенести. Почему Microsoft заморачивалась, вводя эту возможность в .NET (и заметно усложняя систему типов)?

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

> Зависит от того, чего хочется. Для того, что хотел Сан - не нужно многоязычие. Оно только мешает.

Сан хотел управлять кофеварками. Для этого многоязычие было бы крайне полезно, но они этого тогда не смогли осознать.

> Кто? Где? (Когда?)

Гай Стил, естественно.

> Потому что они отталкивались от того, как позиционировал технологию java Sun.

То, как её позиционировал сан, и куда оно пришло в итоге - это две большие разницы. Сантехники сами не знали, чего хотят.

> Сан хотел управлять кофеварками.

Это был фальш-старт;)

> То, как её позиционировал сан, и куда оно пришло в итоге - это две большие разницы.

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

> Это был фальш-старт;)

А с тех пор в технологии и в идеологии ничего не изменилось.

> и глупо их за это упрекать с т.зр. абстрактного технического перфекционизма (вообще, технический перфекционизм очень мешает бизнесу).

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

> А можно на пальцах - почему это? В смысле почему GC хуже чем рукописное управление в условиях своппинга? Не понимаю.

Потому что у человека есть разум, а у машины нет. Это с философской точки зрения.

А с технической - когда в программе на С++ создаются и уничтожаются временные обьекты (а их ДОФИГА) место которое они занимали повторно используется. На Java эти обьекты продолжают жить до следующей сборки мусора. В результате программа насилует своп не только дополнительными затратами памяти, но и сборкой мусора (которая должна просмотреть все ссылки на обьекты).

А еще... В моей нынешней программе (на С++) есть собственный распределитель памяти. Так вот со своим распределителем памяти программа работает в ДВА раза быстрее, чем с системным. Локальность размещения обьектов играет.

А лучше-хуже - это субьективная оценка. Есть области, где кровь-из-носу нужна производительность и там Ява не играет. А есть области, где важнее надежность, скорость разработки и переносимость. И там Ява на месте.

System.gc() ?

> Потому что у человека есть разум, а у машины нет. Это с философской точки зрения.

Но работать то предстоит машине, человек не будет в процесс вмешиваться. И предугадать шаблон нагрузки на память человек часто просто не в состоянии. Так что, Лаврентий Палыч, хреновый вы программист, если таких простейших вещей не понимаете.

> На Java эти обьекты продолжают жить до следующей сборки мусора.

RTFM про generational GC. Короткоживущие объекты не переживут stop'n'copy, который, кроме всего прочего, может и компактификацию проделать, так что производительность только увеличится (за счет снижения числа кэш-промахов).

> (которая должна просмотреть все ссылки на обьекты).

Мсье, вы явно не в курсе, как устроены современные GC.

> А еще... В моей нынешней программе (на С++) есть собственный распределитель памяти.

Ага, ага, небось подсчет ссылок или ещё какое подобное позорище. Не стыдно?

> Локальность размещения обьектов играет.

Вменяемый GC это обеспечит автоматом. А если при этом ещё и region analisys работает - то вообще гарантированно лучший результат чем при любом, даже самом оптимальном ручном управлении памятью.

Последнему анонимусу - месье теоретик или сам пробовал то, о чем вещает?

А то фирма SUN тоже хотела доказать, что Ява не медленнее С++ и надорвалась. Хотя, где ей до анонимусов! :-)))) смеюсь.

PS. А я действительно не знаю, как устроены современные GC. Знаю только, что полезный выхлоп у них маленький.

> Мультиязыковость реально сделать гораздо легче

Для этого надо ее хотеть. Они, судя по всему, резко НЕ ХОТЕЛИ.

> Последнему анонимусу - месье теоретик или сам пробовал то, о чем вещает?

Пробовал, пробовал. Жесткое реальное время с GC делаю.

> PS. А я действительно не знаю, как устроены современные GC. Знаю только, что полезный выхлоп у них маленький.

А видел их вообще, чтоб такие выводы делать, или теоретизируешь? Даже у той же сановской Жабы GC можно подкручивать очень тонко, под почти любое возможное применение.

> А видел их вообще, чтоб такие выводы делать, или теоретизируешь? Даже у той же сановской Жабы GC можно подкручивать очень тонко, под почти любое возможное применение.

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

> Как бы его так подкрутить, чтоб эклипс с нетбинсом по гигу памяти не хавали, ололо?

Они криво написаны. Крути как угодно, а жрать будут.

А вообще, пожалуй, не буду больше отвечать скотам, которые употребляют "ололо"...

> А видел их вообще, чтоб такие выводы делать, или теоретизируешь? Даже у той же сановской Жабы GC можно подкручивать очень тонко, под почти любое возможное применение.

Да я что, я ничего. Это я так просто. С Явой последний раз имел дело 4 года назад. Может быть ты действительно сможешь меня удивить. Давай простой эксперимент - берем библиотеку Мошкова и посчитаем частоту появления всех слов. (У меня такие задачи). Кто быстрее справится С++ или Ява? Будем пробовать, или посчитаем, что ты сразу слил?

> Давай простой эксперимент - берем библиотеку Мошкова и посчитаем частоту появления всех слов

Что-то я в упор не догоняю, на кой тут вообще сильно динамическое выделение памяти? Задача статична, trie строить то надо, а удалять - не фиг.

> Кто быстрее справится С++ или Ява? Будем пробовать, или посчитаем, что ты сразу слил?

А давай я OCaml вместо Java возьму? У него GC то посимпатичнее будет.

> > Давай простой эксперимент - берем библиотеку Мошкова и посчитаем частоту появления всех слов

> Что-то я в упор не догоняю, на кой тут вообще сильно динамическое выделение памяти? Задача статична, trie строить то надо, а удалять - не фиг.

Это просто моя задача. Просто взял то, что я в данный момент делаю. И уверен, что Ява проиграет. А более опытный аноним сказал бы, что сначала программа упрется в диск :-)

> > Кто быстрее справится С++ или Ява? Будем пробовать, или посчитаем, что ты сразу слил?

>А давай я OCaml вместо Java возьму? У него GC то посимпатичнее будет.

Не, тут должна быть именно Ява. Про нее же разговор. Причем, не просто Ява, а Ява настолько же доступная как gcc. А то ведь я тоже могу интеловский компилятор взять :-)))

> Просто взял то, что я в данный момент делаю. И уверен, что Ява проиграет.

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

> А более опытный аноним сказал бы, что сначала программа упрется в диск :-)

Сказал бы, и обломался б сразу. Оно целиком в виртуальный диск поместится, в память.

> Не, тут должна быть именно Ява. Про нее же разговор.

Кое кто тут баллоны катил на GC вообще.

Так вот - в этой задаче жаба скорее всего проиграет, но не благодаря GC (он тут использоваться и не будет вовсе). Тут всякие проверки границ массивов и прочая гадость сработает. .NET в принципе может в на равне с C++ пойдет. OCaml тоже.

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

Ну, я так предположил, что оно всё уже выкачано локально.

4

Про Нетбинс не скажу, а под Эклипсом я _профайлил_ в _debug_-mode рилтаймовый java-сервер, жрущий по 500+Мб оперативы. Т.е. 500Мб на сервер + под отладчик и профайлер + под сам эклипс + нагруженный mysql + джентльментский набор в фоне от apache до Gnome.

Всё это на Celeron-1700 с 1Гб оперативки.

Ы?

>> Так как Scala, например, итак имеет скорость, равную C# на mono.

> Только если не использовать сложные фичи языка.

Заюзал тест с массовым созданием объъектов. Scala обогнала чистый Java :)

http://balancer.ru/tech/forum/2008/08/t63003--Proizvoditel~nost~-yazykov.Ob~e...

>Заюзал тест с массовым созданием объъектов. Scala обогнала чистый Java :)

ВопервЫх, там скала 2.3.0 версии, а на дворе актуально уже 2.7.1. Надо-с перемерять, да-с.
ВовтОрых, Java тоже старой версии, ну а time под Windows запустить невозможно, поэтому непонятно как прогнать тесты под вендой?