C vs. JVM's benchmark

>Может авторы языка были того же мнения?

Авторы языка авторили язык в лохматой древности.

>кому нужно, тот уже готовый функционал использует, который за эти 20 лет уже наработан :)

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

>> Может пойдём дальше и найдём тот язык, для которого подобная Крутая IDE может быть написана безо всяких снижений общности? Basic? :)

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

Не увидел связи между репликами.

> Тюринг полнота не говорит о том насколько сложно будет решить задачу и прочие друдозатраты.

"Сложно" -- это понятие сугубо субъективное. Кому-то не сложно и ооп на с реализовывать и потом использовать, а кому-то писать мегабайты невыразительного кода.

Принципиальных проблем в том, что Крутые Кодоутилиты не пишутся на C, нет. И не надо мне говорить о том, что они не написаны потому, что писать неудобно. Гуй на gtk, например, писать куда сложнее чем на Tk, а при этом оценка количества программ даёт диаметрально противоположное сообрадение.

>Не увидел связи между репликами.

Язык простой - приличной IDE - нет.

>"Сложно" -- это понятие сугубо субъективное.

Но относительная сложность вычисляется легко. Что опять стринги начнем складывать?:)

>Принципиальных проблем в том, что Крутые Кодоутилиты не пишутся на C, нет

Кроме самого С:)

>И не надо мне говорить о том, что они не написаны потому, что писать неудобно.

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

>> Не увидел связи между репликами.

> Язык простой - приличной IDE - нет.

И почему же для него не написали Крутую Ide На Жаве? ;)

>> "Сложно" -- это понятие сугубо субъективное.

> Но относительная сложность вычисляется легко. Что опять стринги начнем складывать?:)

Не вычисляется. Вопрос подобен сравнению экскаватора и томика Блока.

>> И не надо мне говорить о том, что они не написаны потому, что писать неудобно.

> Нет - потому что все сводится к войне с языком, а не решению целевой задачи.

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

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

Опять двадцать пять... Неумеющих и нежелающих работать с памятью "программистов" надо переучивать на любую другую профессию чтоб не мешались.

>Опять двадцать пять... Неумеющих и нежелающих работать с памятью "программистов" надо переучивать на любую другую профессию чтоб не мешались.

«Весь взвод шёл не вногу, и лишь один поручик шёл вногу...»

>И почему же для него не написали Крутую Ide На Жаве? ;)

Нафиг никому не здалось. А для питона, руби и прочих С - вполне занимаются.

>Не вычисляется. Вопрос подобен сравнению экскаватора и томика Блока.

Вычисляется исторически. Сравнением IDE:)

>В маленьком проекте,...

В маленьком проекте!?

>если автор хоть немного понимает язык и предметную область.

Я надеюсь что те кто писал MSVC вполне понимают предметную область и тд.

>Неумеющих и нежелающих работать с памятью "программистов" надо переучивать на любую другую профессию чтоб не мешались.

Уволить всю команду которая написал визуалстудию - правильно?

> Вычисляется исторически. Сравнением IDE:)

msvs 6.0, delphi/cbuilder -- были плохими ide в своё время?

> Уволить всю команду которая написал визуалстудию - правильно?

У них выбор инструментальных средств определяется далеко не технарями. Надо ж удотнет пиарить!

>> Неумеющих и нежелающих работать с памятью "программистов" надо переучивать на любую другую профессию чтоб не мешались.

> «Весь взвод шёл не вногу, и лишь один поручик шёл вногу...»

Не уметь работать с памятью -- это теперь модно? (Уточнюсь: я не противник gc как таковых, я противник того, что своё неумение работать с памятью сваливают на Умный Менеджер Памяти)

>Не уметь работать с памятью

Изначально фраза строилась как «Неумеющих и нежелающих». Я умею, но не желаю. Полагаю, что сегодня также считает, как раз, основная масса программистов. Поэтому и говорю, что один поручик идёт вногу.

> Изначально фраза строилась как «Неумеющих и нежелающих». Я умею, но не желаю. Полагаю, что сегодня также считает, как раз, основная масса программистов. Поэтому и говорю, что один поручик идёт вногу.

Попробую развить тему принципиального нежелания заботиться о памяти. Разумеется, на примере явы.

Итак, получаем из базы пару тысяч записей. Естественно, одним махом в List<Object[]>. Потом итеративно проходимся по листу и строим из него XML-ку. Естественно через DOM, весь SAX нам неудобен :)

Затем через пару проксей передаём полученное в веб-часть, где гоним xml через xslt и делаем из него html-ку. Которую потом отдаём через сервлет.

При желании данную апокалиптическую картину можно дополнить дополнительным нежеланием думать о распределённой памяти.

> Попробую развить тему принципиального нежелания заботиться о памяти.

Но я полагаю, что меня хотели поймать на упёртости в том, что каждый байт надо освобождать вручную? Такая упёртость действительно ни к чему и тут я "в ногу".

>При желании данную апокалиптическую картину

Есть способ сделать апокалиптичную картину намного проще. Из практики одного проекта, в котором я участвовал. Есть класс сервера. В нём список глобальных объектов. Регистрируем объект. А разрегистрировать иногда забываем. Через сутки работы сервер выжирает всю отведённую память.

...

Есть разница между «не думать об управлении памятью полностью» и «не думать об управлении памятью по каждому чиху».

Честное слово, за...ло в своё время отслеживать все перепитии объектов, созданных по new, которые могут использоваться и освобождаться в сложном проекте в десятках мест.

А как на языках без gc бороться с кольцевыми ссылками?

>Но я полагаю, что меня хотели поймать на упёртости в том, что каждый байт надо освобождать вручную? Такая упёртость действительно ни к чему и тут я "в ногу".

Так о чём и речь. О памяти надо заботиться даже в PHP. И, тоже, реально иногда нарываешься на её исчерпания, когда забываешь освобождать некоторые объекты. Особенно, те, которыми обмениваешься между процессами через memcached.

> Есть разница между «не думать об управлении памятью полностью» и «не думать об управлении памятью по каждому чиху».

Я потом добавил комментарий про "каждый чих". над ними действительно думать задалбывает.

> Честное слово, за...ло в своё время отслеживать все перепитии объектов, созданных по new, которые могут использоваться и освобождаться в сложном проекте в десятках мест.

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

> А как на языках без gc бороться с кольцевыми ссылками?

Ну вот перловый gc кольцевые ссылки не разбирает :) Наверно, немного другое, нежели gc имелось в виду?

А вообще, из ms visual c++ версии года эдак 2003 мог получиться хороший гибридный язык в стиле "хочешь -- освобождай руками, хочешь -- сваливай работу на мусорщик". Но увы, потом visual c++ стал сишарпом с синтаксисом какого-то страшного паскалесиплюсплюса, с крышечками^ и стрелочками->.

> Так о чём и речь. О памяти надо заботиться даже в PHP. И, тоже, реально иногда нарываешься на её исчерпания, когда забываешь освобождать некоторые объекты.

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

>msvs 6.0, delphi/cbuilder -- были плохими ide в своё время?

Почему они такими и остались как были в свое время? Почему 7 человек на жабе пишут намного круче чем в свое время писали большие команды?

>Не уметь работать с памятью -- это теперь модно? (Уточнюсь: я не противник gc как таковых, я противник того, что своё неумение работать с памятью сваливают на Умный Менеджер Памяти)

Почему это неумение? Ты уверен что в 21 веке с железками которые стоят сейчас на десктопах для прикладного програмирования следует заниматься "работой спамятью" для класса задач типа сложения строк?

>При желании данную апокалиптическую картину можно дополнить дополнительным нежеланием думать о распределённой памяти.

Что принципиально изменится если это делать выделяя память самостоятельно?

Ничего.

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

Потому и нет IDE.

>Для проверки этого утверждения достаточно скачать и запустить eclipse :)

Опять 25. По сравнению с чем? Сравнить но не с чем. Ты уверен что если бы там все зарулили руками оно ело бы меньше? Я например абсолютно уверен что если бы в проекте типа эклипс памятью рулили руками - он бы никогда не был написан.

>Для проверки этого утверждения достаточно скачать и запустить eclipse :)

А что с ним не так? Отличная IDE. Я под ней в дебагере с профайлером гонял MMORPG-сервер, жрущий в одно рыло по 500Мб оперативки на Celeron-1700 с 1Гб RAM :) Всё это ещё с интенсивно используемыми оным сервером mysql и кучей демонов в памяти :)

>> msvs 6.0, delphi/cbuilder -- были плохими ide в своё время?

> Почему они такими и остались как были в свое время?

Проприетарщина рождается и умирает в малой зависимости от своих качеств.

> Почему 7 человек на жабе пишут намного круче чем в свое время писали большие команды?

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

>> Не уметь работать с памятью -- это теперь модно? (Уточнюсь: я не противник gc как таковых, я противник того, что своё неумение работать с памятью сваливают на Умный Менеджер Памяти)

> Почему это неумение? Ты уверен что в 21 веке с железками которые стоят сейчас на десктопах для прикладного програмирования следует заниматься "работой спамятью" для класса задач типа сложения строк?

Да хрен с ними, с двумя строками по 50 символов. Пускай для такой мелочи мусорщики юзаются. Но когда выделяешь разом по 10 метров -- изволь их потом сразу же освободить, не дожидаясь пока gc решит что пора бы и убраться.

>> При желании данную апокалиптическую картину можно дополнить дополнительным нежеланием думать о распределённой памяти.

> Что принципиально изменится если это делать выделяя память самостоятельно? Ничего.

У любого мало-мальски грамотного программиста волосы встанут дыбом, когда он увидет огромное количество malloc-ов и копирований на пути следования этого куска данных.

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

А почему сразу на ц? Такой код и на яве можно красиво и дёшево написать. Главное --- не отказываться от слежения за пямятью широким жестом, как это любят делать явисты, оттмежёвываясь от плюсплюсников.

>> Для проверки этого утверждения достаточно скачать и запустить eclipse :)

> Опять 25. По сравнению с чем? Сравнить но не с чем.

О 6, 36. Для того, чтобы понять, что програма _тормозит_, мне не нужно знать о её аналогах. Мы тут с Кроном же вывели как-то критерий тормознутого гуя: программа не отвечает на действия пользователя сменой картинки в течении 1/20(1/20) секунды(тут наши мнения немного расходятся). А эклипс любит безо всяких причин подвиснуть на срок от 5 секунд до пары минут.

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

Эти "проекты типа эклипса" плохи тем, что написаны одним куском на одном языке. В итоге ни кусочка из них не пореюзаешь в других проектах(а как бы было прикольно: vim+cdt :) ) и приходится писать на языке с автоматическим управлением памятью, чтоб не делать наведённых ошибок. Жил бы cdt отдельным процессом -- основному приложению было бы глубочайше пох, на каком языке он написан.

>> Для проверки этого утверждения достаточно скачать и запустить eclipse :)

> А что с ним не так? Отличная IDE.

Фич много. Но работать без мата невозможно из-за подвисаний.

> Я под ней в дебагере с профайлером гонял MMORPG-сервер, жрущий в одно рыло по 500Мб оперативки на Celeron-1700 с 1Гб RAM :) Всё это ещё с интенсивно используемыми оным сервером mysql и кучей демонов в памяти :)

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

>Проприетарщина рождается и умирает в малой зависимости от своих качеств.

Ну давайте посмотри на KDevelop.

>За эти годы выработана куча шаблонных решений для ниши, которую занимает жаба.

А для С которому уже четыре десятка лет - неасилели до сих пор?

>Потому и пишется быстро.

А вот тут мы уже ближе к теме:)

>> Проприетарщина рождается и умирает в малой зависимости от своих качеств.

> Ну давайте посмотри на KDevelop.

1. Его не спонсировал IBM

2. В нём пишет только половина фанатиков :)

>> За эти годы выработана куча шаблонных решений для ниши, которую занимает жаба.

> А для С которому уже четыре десятка лет - неасилели до сих пор?

Осилили. Только вот жабка заняла нишу (веб-)гуйков к бд, в которой постоянно был полный разброд и где на ц писать невыгодно.

>> Потому и пишется быстро.

> А вот тут мы уже ближе к теме:)

Да, писать хелловорлды стало легче. Это подкупает.

> Это хорошо. Только хотелось бы видеть, от чего ради этого придётся отказаться. Сходу всплывает отказ от "чистого" eval. А оно уже как-то называется или это только задумка?

Оно никак пока не называется, и ближе всего к resyntaxed C++.

>> И что еще надо?

> Надо не потерять то, что уже есть :) А вообще, понять, что потеряно можно только понабрав опыта и шишек.

Эээ... а можно наоборот? Например, допустим что ява будет ресинтаксифицирована вот под такой синтаксис. Что там будет потеряно по сравнению с тиклем?

> Например, допустим что ява будет ресинтаксифицирована вот под такой синтаксис. Что там будет потеряно по сравнению с тиклем?

Увидев пару строчек сложно сказать что поменяется, но я попробую:

явное указание слова 'command' намекает на то, что код явно отделяется от данных. Это потеря.

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

Ещё, в яве нет "..." в параметрах(или я что-то пропустил?). А без этого многие вкусные фичи отвалятся.

Далее, замыкания в яве черезчур многословны и это снижает широту их применения. А так как язык предполагается типобезопасным, то всё-таки тип передаваемой функции надо указывать. Уж не знаю, как это будет выглядеть в предлагаемом синтаксисе, но в си-подобном будет как-то так:

int myproc(int command(int a, int b), string c);

myproc(int @(a,b) { return a+b) }, "blah");

P.S. Пока писал, понял, что моё видение находится под сильным влиянием c++0x.

> Здесь имелось ввиду не сложение строк - а задачи класса сложения строк. Можешь строки заменить матрицами. ТАк что частный случай наличия библиотеки для строк тут ничего не решает. Если библиотеки не найдется - придется мозг таким гемором мучить.

Я понял про что ты :)

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

> Попробую развить тему принципиального нежелания заботиться о памяти. Разумеется, на примере явы.

> Итак, получаем из базы пару тысяч записей. Естественно, одним махом в List<Object[]>. Потом итеративно проходимся по листу и строим из него XML-ку. Естественно через DOM, весь SAX нам неудобен :)

> Затем через пару проксей передаём полученное в веб-часть, где гоним xml через xslt и делаем из него html-ку. Которую потом отдаём через сервлет.

> При желании данную апокалиптическую картину можно дополнить дополнительным нежеланием думать о распределённой памяти.

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

Это примерно как использовать Oracle. Можно написать очень кривое приложение и оно будет работать на Оракле за счет мощи сервера, но при этом нещадно проседать на более OpenSource серверах. Хотя проблема опять же в архитектуре, а не сервере БД.

> Тут проблема в голове архитектора, а не в дополнительной памяти.

Проблема в нежелании думать о памяти, ведь Умный ГЦ всё сделает за программиста :)

> Но даже в этом запущенном случае GC будет помогать - после каждой функции когда объекты перестают использоваться их зачистит.

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

>> Тут проблема в голове архитектора, а не в дополнительной памяти.

>Проблема в нежелании думать о памяти, ведь Умный ГЦ всё сделает за программиста :)

А какие есть способы менеджмента памяти кроме GC? Их не существует.

>> Но даже в этом запущенном случае GC будет помогать - после каждой функции когда объекты перестают использоваться их зачистит.

>Тут не столь давно в девелопменте один жаьист жаловался, что у него получается outofmemoryexception, когда он трёхсотметровый файл пытается отдать. Разумеется, проблема была в перерасходе памяти в момент копирования, хоть потом всё и чистилось.

Скажи еще что с такими объемами в С++ ты работаешь как и этот жабист - не потоковым образом, загружая целиком в память.

> Для того, чтобы понять, что програма _тормозит_, мне не нужно знать о её аналогах. Мы тут с Кроном же вывели как-то критерий тормознутого гуя: программа не отвечает на действия пользователя сменой картинки в течении 1/20(1/20) секунды(тут наши мнения немного расходятся). А эклипс любит безо всяких причин подвиснуть на срок от 5 секунд до пары минут.

Да, по данному определению Eclipse - тормозит. Но аналогов по функциональности не существует, потому СЕЙЧАС нет возможности проверить можно ли за создать приложение аналогичное по функционалу и не тормозящее по этому определению. И чтобы все плагины не тормозили, ибо в Eclipse базовый функционал для Java - не тормозит, тормозят плагины.

> Эти "проекты типа эклипса" плохи тем, что написаны одним куском на одном языке. В итоге ни кусочка из них не пореюзаешь в других проектах(а как бы было прикольно: vim+cdt :) ) и приходится писать на языке с автоматическим управлением памятью, чтоб не делать наведённых ошибок. Жил бы cdt отдельным процессом -- основному приложению было бы глубочайше пох, на каком языке он написан.

Еклипс написан очень модульно, вроде есть биндинги C к Java - бери и пользуйся. Только этот велосипед намного сложнее чем сам Eclipse получится.

> Ещё, в яве нет "..." в параметрах(или я что-то пропустил?).

Да, действительно пропустил ;)

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

Не распарсил ))) но черезчер многословность Java как раз и вызвана типобезопастностью. И именно для безопастности нужно много писать, чтобы не было неоднозначности. Хотя наверняка можно было сократить, но решили сделать с более понятным но многословным синтаксисом.

>> Тут проблема в голове архитектора, а не в дополнительной памяти.

> Проблема в нежелании думать о памяти, ведь Умный ГЦ всё сделает за программиста :)

Представим тот же сценарий, НО только память менеджится руками. Что изменится? XML останется как и мега-списки из БД и XSTL так же жрать память будет (мы же говорим, о кривости использования памяти, а не смене архитектуры;) )

> Да, по данному определению Eclipse - тормозит.

Ура!

> Но аналогов по функциональности не существует, потому СЕЙЧАС нет возможности проверить можно ли за создать приложение аналогичное по функционалу и не тормозящее по этому определению.

В любом случае, существование аналога на скорость работы эклипса не повлияет -- он как был тормозом, так и останется.

> И чтобы все плагины не тормозили, ибо в Eclipse базовый функционал для Java - не тормозит, тормозят плагины.

Эклипс без плагинов -- это всё равно что xmms без модулей вывода звука. Да и сам факт того, что тормозной плагин может затормозить само приложение ужасен.

>1. Его не спонсировал IBM

IDEA тоже не спонсировал IBM.

>2. В нём пишет только половина фанатиков :)

Так что - и смотреть не на что получается да? Все С++сное поделие приказало долго жить?:)

>Только вот жабка заняла нишу (веб-)гуйков к бд, в которой постоянно был полный разброд и где на ц писать невыгодно.

Нишу гуйков к бд всегда занимало делфи, а вебгуйков - пхпмайадмин:) Это тоже показатель - в жабе сменится успелидесятки подходов - слишком сложное упроститься, нежизнеспособное - отмереть и тд за последний десяток лет - то есть есть движение. На С банально один интерфейс к бд неасилели. Не то что инфраструктуру X-Open/DTS. Все память распределяют?:)

>Да, писать хелловорлды стало легче. Это подкупает.

Не хеловорлды - все писать легче.

> Еклипс написан очень модульно, вроде есть биндинги C к Java - бери и пользуйся. Только этот велосипед намного сложнее чем сам Eclipse получится.

Сложное API для плагинов(всё-таки негоже называть это биндингом) не делает эклипсу чести.

> А какие есть способы менеджмента памяти кроме GC? Их не существует.

Мозг? Или продвинутые программисты мозгом не пользуются?

>или я что-то пропустил?

угу.

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

Их сейчас пилят на менее многословные - но с манифестационной статической типизацией все равно не хаскел.

>Тут ещё смотреть нужно, что бы не получилось, что забиваем гвозди микроскопом.

Такида - куте и апр никто не отменял - но само наличие оных говорит что ну сколько ж можно то:)

> Представим тот же сценарий, НО только память менеджится руками. Что изменится? XML останется как и мега-списки из БД и XSTL так же жрать память будет (мы же говорим, о кривости использования памяти, а не смене архитектуры;) )

В языке с ручным управлением памятью ты _видишь_, в каком месте ты её расходуешь и освобождаешь. А в яве о перерасходе памяти зачустую узнают в рантайме по outofmemoryexception.

> Не распарсил ))) но черезчер многословность Java как раз и вызвана типобезопастностью. И именно для безопастности нужно много писать, чтобы не было неоднозначности. Хотя наверняка можно было сократить, но решили сделать с более понятным но многословным синтаксисом.

Да пусть будет безопасность. Но дайте мне гибкость! А гибкие безопасные языки пусть проследуют в музей, а лучше -- в кунсткамеру.

>Проблема в нежелании думать...

Так будет лучше. Жаба не единственный язык с гц. ГЦ не отменяет мозг - он избавляет от гемора. У меня всякие серваки которые всякой грязной памятижрущей работой занимаются включая ковыряние в видео и архивирование всяких терабайтов - и все запускается в пределах 64 метров вместе с котом.

>Да, по данному определению Eclipse - тормозит.

На компьютере который в текущий момент стоит 14 т.р. текущий релиз Эклипса *не подвисает* на срок от пары сек до пары минут, так что это вранье.

>> А какие есть способы менеджмента памяти кроме GC? Их не существует.

>Мозг? Или продвинутые программисты мозгом не пользуются?

Машина все сделает лучше чем мой убокий человеческий умишко, по крайней мере пока нет имплантантов (ц) Луговский

>А в яве о перерасходе памяти зачустую узнают в рантайме по outofmemoryexception.

outofmemoryexception - это всегда ошибка в коде.

> IDEA тоже не спонсировал IBM.

Проприетарщина.

> Так что - и смотреть не на что получается да? Все С++сное поделие приказало долго жить?:)

Слухи о смерти kdevelop сильно преувеличены. Конечно же, то, что интерфейса для плагинов там проактически нет, тоже будет отнесено в счёт превосходства явы над сиплюсплюсом?

> Нишу гуйков к бд всегда занимало делфи, а вебгуйков - пхпмайадмин:) Это тоже показатель - в жабе сменится успелидесятки подходов - слишком сложное упроститься, нежизнеспособное - отмереть и тд за последний десяток лет - то есть есть движение.

С моей колокольни это выглядит иначе: яву пытаются сунуть то в одно место, то в другое, а всё никак не найдут место, где она всех зарулит. Но всё никак, потому бродяга продолжает движение. Может как раз эклипс и есть ниша жабки? ;)

> На С банально один интерфейс к бд неасилели.

Ну вообще-то осилили.

> Не хеловорлды - все писать легче.

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