Java вышла на первое место?

> Вообще, интересно, чтобы доказать, как убог язык Java, приводятся примеры из нескольких принципиально разных языков - Eiffel, Ruby и Lisp. Как насчет одного единственного языка, который бы убил Яву в одиночку?

Пожалуйста, это будет лисп. Примеры из Ruby я приводил просто по причине его большей читабельности, а из Eiffel - поскольку это "чисто ООП" язык безо всяких отвлекающих сущностей; он одновременно этим хорош, т.к. на нем хорошо изучать ООП, не отвлекаясь на все остальное, и плох, т.к. писать что-то практичное неудобно =)

> Я не говорю уже о том, что ссылаться на механизмы функциональных языков, обсуждая язык нефункциональный, как-то некорректно.

А нет жесткого разделения ФП и не-ФП языков. Есть некоторые уровни градации. Вот в питоне функции first-class, и что? Да и в C# делегаты по сути выполняют ту же роль, хотя назвать его функциональным язык не повернется.

> Я могу еще добавить - в Java нету механизма рандеву как в Аде, механизма COMMON-областей как в Фортране, сопрограмм как в Модуле-2, перегрузки операторов как в C++ и т.д. и т.п.

Насчет сопрограмм и перегрузки операторов - это очень верно подмечено =) Насчет первых двух - где про это можно почитать?

Кстати, сопрограммы есть и в лиспе: call-with-current-continuation. Полезная штука.

> И потом, я же могу задать и такой вопрос: как насчет написать обработчик прерывания на Лиспе? Трудно? Тогда, простите, Лисп - отстой, C - вот наш выбор.

Кроме шуток. Действительно, для работы с железом и вообще низкоуровневых извратов C рулит - именно поэтому я по нему еще ни разу не проехался =) Однако же речь в данном случае идет именно о языках, занимающих _одну_ нишу: Java, C#, Ruby, Lisp - это все высокоуровневые языки общего назначения. Поэтому их сравнение корректно.

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

Ты многое пропустил. Они там уже были :) Лет сорок назад.

// boshik

> Чем плох XML, как формат обмена данными, когда скорость их обработки большой роли не играет?

Избыточностью. Те же атрибуты, entities, CDATA... Как следствие - сложность корректного парсинга.

> Может есть лучшая альтернатива XML-форматам оффисных документов? Не, может я дремуч, просвети.

Например, http://en.wikipedia.org/wiki/S-expression

Вообще есть масса способов описывать деревья намного более компактно и читабельно, чем XML.

> А что уважаемые товарищи скажут про Ruby? Я его в рейтинге не заметил, значит ли это что он такой плохой и никому не нужный?

Сыровато оно еще. Либ мало (хотя это довольно быстро меняется в лучшую сторону), с уникодом грабли, тормоза. Тем не менее, если ты прокрутишь страницу вниз, то увидишь его на 28-м месте - выше bash, Forth, и Tcl/Tk =)

>Избыточностью. Те же атрибуты, entities, CDATA... Как следствие - сложность корректного парсинга.

:)))))))

Опять 25-ть. Это универсальный язык описания данных. УНИВЕРСАЛЬНЫЙ. Для этого всего и предназначены аттрибуты, CDATA и т.д.

Сравнивать набор технологий XML, XSL, XSD etc с S-деревьями как сравнивать Java и Lisp ;)

// boshik

> возмем например ML очень бы хотелось что бы на всю его стандартную библиотеку depricated поставили - редкостное дерьмо

Не берусь комментировать по причине весьма поверхностного знакомства с O'Caml. Хотя не примомню там ничего откровенно отвратного. Но, что характерно - где я выше сравнивал жабку с ML?

> а дизайн патернами в функциональных языках не пользуются не потому что не надо а потомучто микроцефальской головки не хватает

Ну так расскажи поподробней, что там не так. На примере Haskell как чисто ФП-языка.

> Пожалуйста, это будет лисп.

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

> Насчет сопрограмм и перегрузки операторов - это очень верно подмечено =) Насчет первых двух - где про это можно почитать?

Ну, насчет рандеву я несколько погорячился, с помощью wait/notify в Java можно сделать очень приблизительное подобие адовских рандеву, но все равно это далеко не то. Про фортран не знаю современной литературы, свою уже всю сдал в магазин. COMMON BLOCK в сочетании с EQUIVALENCE - это просто убийственный инструмент :)

А что касается перегрузки операторов, то это хорошо, что этого нет. Читабельность программы страдает очень сильно, особенно если какой-нибудь талант меняет семантику оператора на противоположную. Собственно, ИМХО, поточная баблиотека C++ как раз дает пример вопиюще недопустимого применения перегрузки операторов, когда арифметическую операцию сдвига применяют как запись в поток по той простой причине, что выглядит красиво.

> Java, C#, Ruby, Lisp - это все высокоуровневые языки общего назначения.

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

> Опять 25-ть. Это универсальный язык описания данных. УНИВЕРСАЛЬНЫЙ. Для этого всего и предназначены аттрибуты, CDATA и т.д.

Объясни мне, зачем нужны атрибуты? Почему не хватило тэгов?

> Сравнивать набор технологий XML, XSL, XSD etc с S-деревьями как сравнивать Java и Lisp ;)

Что характерно, речь шла только об XML. Аналог XSL в этом случае - это сам лисп =)

> Например, http://en.wikipedia.org/wiki/S-expression

Цитата оттуда:

The details of the syntax and supported data types vary in the different languages

Так как же насчет interoperability?

BTW, там есть аналог валидации по схеме/DTD?

>Объясни мне, зачем нужны атрибуты? Почему не хватило тэгов?

Неоднозначность в множественном определении.

> А что касается перегрузки операторов, то это хорошо, что этого нет. Читабельность программы страдает очень сильно

Хрен вам, это отсутствие перегрузки поганит читабельность неимоверно. m1.multiply(v1.add(v2.normalize())) - красиво смотрится, да?

> Собственно, ИМХО, поточная баблиотека C++ как раз дает пример вопиюще недопустимого применения перегрузки операторов, когда арифметическую операцию сдвига применяют как запись в поток по той простой причине, что выглядит красиво.

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

> Что Lisp - это язык общего назначения, вопрос спорный.

Вот давай и поспорим =) чего там, по-твоему, не хватает, чтобы назвать его языком общего назначения?

> Неоднозначность в множественном определении.

А кто мешает прописать это в схеме? И никакой неоднозначности.

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

> The details of the syntax and supported data types vary in the different languages. Так как же насчет interoperability?

Так же как и в XML - ровно настолько, насколько ты о нем позаботишься =)

> BTW, там есть аналог валидации по схеме/DTD?

Есть. Берешь и пишешь лисповскую макру, задающую данный S-expr. Получаешь парсер и валидатор в одном флаконе =)

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

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

Задумывался. Кстати, отвратительный язык, правда? Плохо структурированная грамматика, куча синтаксического мусора, нерегулярность...

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

>Задумывался. Кстати, отвратительный язык, правда? Плохо структурированная грамматика, куча синтаксического мусора, нерегулярность...

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

>Плохо структурированная грамматика

Назови мне язык с хорошо структурированной грамматикой :)

>куча синтаксического мусора

Назови мне язык без синтаксического мусора :)

> Назови мне язык с хорошо структурированной грамматикой :) Назови мне язык без синтаксического мусора :)

Эсперанто, логлан/ложбан.

> особенно если какой-нибудь талант меняет семантику оператора на противоположную

Во-во. Если в одиночку писать, и С++ - неплохой язык. А в условиях коллективной разработке может и хорошо, что в Java нет макросов. Тут коллеги и без них такое пишут, что <quote lang="surgik_UA">шо за тиждень не просцяти</quote>. Вообщем, иногда отсутствие чего-то в языке бывает даже очень полезно, и создатели Java здесь хорошо поработали, взяв за основу С++. Кое-где недоработали, кое-где перестарались, но получилась вполне подходящая вещь для написания больших проектов.

Что я хотел сказать: есть очень много факторов, влияющих на успех технологии, кроме маркетинга и наличия кучи features.

> А в условиях коллективной разработке может и хорошо, что в Java нет макросов. Тут коллеги и без них такое пишут

А зачем у вас такие коллеги? Может, пусть они лучше грузчиками устроятся? ;)

> есть очень много факторов, влияющих на успех технологии, кроме маркетинга и наличия кучи features.

Есть. Размер откатов еще, например.

> Хрен вам, это отсутствие перегрузки поганит читабельность неимоверно. m1.multiply(v1.add(v2.normalize())) - красиво смотрится, да?

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

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

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

> Вот давай и поспорим =) чего там, по-твоему, не хватает, чтобы назвать его языком общего назначения?

Нет уж, увольте, спорить на нечетких терминах ;) Скажем, Страуструп считает, что "всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо, обеспечивая близкое к оптимальному время выполнения и распределение памяти" (http://www.osp.ru/cw/2001/12/032_0.htm).

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

> Эсперанто, логлан/ложбан.

Скорее человечество перейдет на шеснадцатиричную систему счисления, чем они обгонят по популярности, скажем, эстонский.

Но в принципе и English можно доработать: http://www.kiok.com/humor/nice/english-evolution.html

> Есть. Размер откатов еще, например.

Да-да, я заметил, на ЛОРе принято ссылаться на откаты, чуть что не так. Хотел бы я узнать размер отката, который удовлетворил бы топ-менеджера из IBM. Серьезно, Сан не такая богатая контора :)

>Эсперанто, логлан/ложбан.

Эсперанто, логлан/ложбан, Лисп.

:)))

Осталось только найти страну(ы) где говорят на этих языках. А то ведь получается как с Лиспом ;)

> Не в угоду идиотам, а чтобы можно было, в том числе, использовать и идиотов.

Ok, этот аргумент я могу принять - сам по той же причине оставляю за Gnome право на жизнь =)

Проблема в том, что вырезание данных фич с корнями сильно вредит тем, кто _умеет_ ими пользоваться, заставляя тратить больше времени на решение тех же задач. Я не уверен, что одно окупает другое. Наверное, в идеале надо бы иметь как минимум два языка (или один, но гибко настраиваемый - кстати, лисп сюда тоже подходит, на макрах вполне можно сваять DSL с ограничениями в духе жабки) с возможностью прозрачной interoperability. Однако этого нет, и больше того - та же жабка продвигается саном именно как универсальный инструмент для всех задач и всех квалификаций.

В этом смысле больше радует .NET, где вполне можно половину проекта писать на C# (индусам), а половину на Nemerle (всем остальным). Кстати, Луговский, помнится, обещался прикрутить туда еще и лисп - посмотрим... =)

Если вам так не нравится Java, то назовите реальную альтернативу готовую предти на смену ей.

> Скорее человечество перейдет на шеснадцатиричную систему счисления, чем они обгонят по популярности, скажем, эстонский.

И ни говори. Не хотят дружно строиться и рядами шагать в биореактор, сволочи...

В такие минуты я начинаю понимать vsl =)

>В этом смысле больше радует .NET, где вполне можно половину проекта писать на C# (индусам), а половину на Nemerle (всем остальным). Кстати, Луговский, помнится, обещался прикрутить туда еще и лисп - посмотрим... =)

Прикручен уже давно. См. Гугл.

>Скорее человечество перейдет на шеснадцатиричную систему счисления, чем они обгонят по популярности, скажем, эстонский.

Ты хотел сказать албанский?

:)))

Товагищи! Пегед нами стоит тгуднейшая задача. Догнать и перегнать http://www.linux.org.ru/jump-message.jsp?msgid=959422 Но мы де здадимся! Уга! товарищи!

> А зачем у вас такие коллеги? Может, пусть они лучше грузчиками устроятся? ;)

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

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

> Да-да, я заметил, на ЛОРе принято ссылаться на откаты, чуть что не так. Хотел бы я узнать размер отката, который удовлетворил бы топ-менеджера из IBM.

Это скорее была потуга на шутку с моей стороны. Видимо несколько неудачная.

Вообще же проблема с менеджерами вот в чем... они не заинтересованы в продвижении наиболее эффективной технологии. Для них важно только одно: чтобы в случае накладок на них не повесили всех собак. Лучший способ этого добиться - использовать "industry best practices", то бишь "делай как все". Если что-то идет не так, стандартная (и всегда безотказно работающая) отговорка - "я не один такой умный, все так делали". И все потери списываются - ну действительно, раз все так делали, винить некого. Стадный инстинкт в действии. А вот что-то действительно новое - оно, конечно, может дать хорошую отдачу, но и риск выше, и главное, в случае чего отвечать будет именно менеджер - инициатива наказуема.

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

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

Вот я и учу, пока дают =)

Ничего, пригодится. Пусть оно никогда не станет мэйнстримом - но даже на жабке, понимая идеологию лиспа, можно писать лучше.

Гы. Ты его не заметил, а он там есть

28 Ruby 0.290%

Только мааааленький

> Прикручен уже давно. См. Гугл.

Поискал. Нашел Common Larceny - но это во-первых Scheme, а во-вторых, альфа. Потом dotLisp - но там похоже нет multiple dispatch (только single и binary), да и прямое использование нативных .NET-типов настораживает.

> Иногда далеко не тупые люди забывают, что они не одни на проекте.

Бить линейкой по рукам и вообще всячески приучать к порядку =)

В-общем, не надо обвинять инструмент в недостатках (исправимых!) людей, которым его дают.

> Вообще же проблема с менеджерами вот в чем... они не заинтересованы в продвижении наиболее эффективной технологии.

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

> Есть такое дело. Но это не всегда от тупости. Менеджеру надо, вообще-то, проект сдать, результат получить.

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

> А с инженерами бывает другая проблема - им процесс интереснее результата.

Это есть =) но с этим не надо бороться, имхо - этим надо пользоваться.

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

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

>Гы =)

>http://www.linux.org.ru/profile/int19h/view-message.jsp?msgid=833349

>Не на лиспе, правда, а на питоне.

А на икс мне твоя Evo, если я под виндой сижу? Нафиг нужен питон, если он только под Evolution работает?

>В свое оправдание: в перспективе есть планы переписать это дело по-нормальному, с полноценным парсингом HTML и прочими делами. Но это еще не скоро... а пока - enjoy =)

Переписал? Давай новую версию в студию

>m1.multiply(v1.add(v2.normalize())) - красиво смотрится, да?

А ты на такой низкий уровень и смотреть то не должен никогда. Читают интерфейсы классов, а копаться в низкоуровневой имплементации?.. один раз написано и не переписывается

Потому, что Англия была морской империей и везде оставляла свои следы, книги etc Вследствие этого английский стал нормой жизни

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

100% согласен. После поверхностного знакомства с OCaml (thanks to LOR) немного по другому стал писать на Java. И чаще плеваться :)

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

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

Да, возвращаясь к Java: IMHO, большая состовляющая ее успеха - неплохая бесплатная и переносимая стандартная библиотека.

> А на икс мне твоя Evo, если я под виндой сижу? Нафиг нужен питон, если он только под Evolution работает?

Ты не удосужился даже прочитать описание, или просто идиот? Ева там не при чем, этот скрипт просто тянет мессаги с ЛОРа и кладет их локально в виде Maildir. Соответственно, под виндой оно будет замечательно работать. Отправка сообщений реализована через SMTP-гейт, опять же, платформонезависимо.

> Переписал?

Нет. Лень. Я начал ковыряться с использованием XSLT для распарсивания ЛОРовского хтмля в божеский вид, но видимо, займусь этим только тогда, когда новые фичи сломают парсинг.

> А ты на такой низкий уровень и смотреть то не должен никогда. Читают интерфейсы классов, а копаться в низкоуровневой имплементации?.. один раз написано и не переписывается

Понятно. "Спец" по жабке не знает о существовании рефакторинга...

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

У меня это вызывает чувство внутреннего протеста, как у человека, который знает о существовании экскаваторов, но которого заставляют копать котлован лопатой =)

> В-общем, не надо обвинять инструмент в недостатках (исправимых!) людей, которым его дают.

Не совсем согласен. Проект растет до тех пор, пока не превысит способности разработчиков :) В больших проектах, IMHO, главная проблема - сложность. Со сложностью борятся путем разбиения на части. Причем, торчать наружу (public API) из каждой части должен необходимый минимум. Любая ненужная торчащая наружу вещь всё усложняет и приносит вред. Язык - это тоже часть проекта, и к нему это все относится тоже. Все излишества языка приносят вред, чем больше проект, тем это сильнее заметно.

> Со сложностью борятся путем разбиения на части. Причем, торчать наружу (public API) из каждой части должен необходимый минимум. Любая ненужная торчащая наружу вещь всё усложняет и приносит вред.

Согласен, но не совсем понятно, как ты из этого выводишь:

> Язык - это тоже часть проекта, и к нему это все относится тоже. Все излишества языка приносят вред, чем больше проект, тем это сильнее заметно.

Кроме того, что записать в излишества? Вот в жабке до недавнего времени не было enum'ов, причем оправдывалось это именно борьбой с излишествами. Однако же имхо отсутствие сей фичи принесло намного больше вреда, чем пользы (помните, даже паттерн такой был?). Аналогичная ситуация с дженериками - пришлось-таки включить. А то так будешь воевать с излишествами - от языка останется один RISC-ассемблер, а то и вовсе Brainfuck =)

>от языка останется один RISC-ассемблер, а то и вовсе Brainfuck

unlambda - концептуальней.

> Вот в жабке до недавнего времени не было enum'ов, причем оправдывалось это именно борьбой с излишествами. Однако же имхо отсутствие сей фичи принесло намного больше вреда, чем пользы (помните, даже паттерн такой был?). Аналогичная ситуация с дженериками - пришлось-таки включить.

Даже спорить не буду :) То, что надо, должно быть, особенно Generics :)

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

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

А у него и получился не язык высокого уровня, а такой же "portable assembler", каким был C. Только с нагромождением по сути не нужных там фич типа ООП.

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

AVA Desktop software Azureus - самый популярный BitTorrent client RssOwl - IMHO лучший RSS reader Подавляющее большинство UML редакторов написано на JAVA Начиная с монстров Borland Together, IBM Rational, >> Вот краткий список ПО на Java, причем большинство из них - это ПО c открытым кодом.

>Обрати внимание, что очень многие пункты из твоего списка - это по сути ПО для разработки и деплоймента Java-софта. Всякие там IDE и UML-редакторы, JSP и J2EE серверы etc.

UML нужен для разработки JAVA софта? А для других ООП языков (C++, Python, C#)он не нужен?! ;-)

Или может IDE не нужен python'у? ;-)

>Если выкинуть все это, то на десктопе мало что останется.

Мало? Я старался приводить по одному приложению из каждой нищи

QNEXT - IM клиент c поддержкой Video Conferencing и Audio Chat работает с ICQ, AIM, MSN. (Можешь в список воткнуть ICQ2GO)

jlGui Music Player - аналог XMMS,WinAmp на java (supports MP3, Ogg Vorbis, Speex, WAV , ... audio formats and shoutcast streaming for internet radios)

Storm Music Studio - простой, но довольно удобный софт для работы со звуком.

JEdit- текстовый редактор c большим количеством plugin'ов.

easyPhoto - простой, удобный редактор фотографий

jalbum - программа для создания альбомов для web. (http://jalbum.net)

Runescape - сетевая RPG в которую играют 700тыс человек.

Tribal Trouble - уже набрала около 100 тыс.

и т.д.

Мое мнение - сейчас рынок настольного по JAVA будет расширятся очень быстро java получила очень приличную поддержку 2D/3D, webstart (способ установки по одним кликом по ссылке)получил широкое распростронение благодоря тому что инет доступен Eclipse SWT (библиотека виджетов альтернативная SWING)особенно после выхода 3.1 стал быстро приобретать популярность. SWING стал куда лучше и быстрее (вгляние на QNEXT)

Стала активно развивается индустрия игр Runescape,Tribal Trouble,Tanx,Chrom,Megacorps Online etc уже активно пошли в массы (кто там говорил что под Linux нет игр? рекомендую зайти http://java.com/en/games

http://www.gamelizard.com - тут все игры для java web start вам нужно только кликнуть и игра установится и запустится.

PS может ли таким списком похвастаться хоть один из ваших нормальных языков?

> UML нужен для разработки JAVA софта? А для других ООП языков (C++, Python, C#)он не нужен?! ;-)

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

> Или может IDE не нужен python'у? ;-)

Речь шла не об IDE вообще, а именно о жабских IDE. Вообще есть тенденция IDE для некоторого языка писать на нем же.

> может ли таким списком похвастаться хоть один из ваших нормальных языков?

Из моих - нет. О причинах написано выше.

Отдельные приложения все же есть. Скажем, MLdonkey.