.

svu

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

Так и я не об этом ! :-))))

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

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

> А я вот на Питон перешел как раз с Ruby, по причине излишней заковыристости и синтаксической нагруженности последнего. Нет, когда читаешь спеки, все замечательно, а вот когда начинаешь что-нибудь писать - бррр! А потом увидел Питон... =)

Ну не знаю, не знаю... Я тоже поначалу долго качался между Питоном и Руби. Сделал выбор в сторону последнего и не скажу, что жалею. В Руби есть просто одна ма-аленькая хитрость, которая совсем не очевидна и в которую не все втыкают - Руби не собирается делать за программера то, что тот должен делать сам - т.е. проверку входных данных. Это многих стремает и для написания маленьких одноразовых скриптов это даже плохо. Но если принять его философию (что не так уж и сложно, лично мне не пришлось себя насиловать :-))) ), то писать на нем - одно удовольствие. :-))))

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

А не подскажет ли ALL есть ли аналог Tomkat (Servlet&JSP container), JBoss на Pythoon? И вообще, каким образом делаются серверные приложения (HTTP).

Через Zope.

2svu:
Забавно звучит по русски :) Случайно это звучание не определяет качество?

Каламбур преднамеренный. Правда, это просто шутка - я слишком мало знаю про продукт (почти ничего). Представить что-то масштаба J2EE мне сложновато. Хотя, кто их, серпентофилов, знает?:)

.

svu

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

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

> Но о массовом вторжении питона на рынок игр говорить пока не приходится.

А о массовом вторжении чего можно говорить ??? :-))) Я как раз к тому и веду, что питон вторгся в ту нишу, где и по ныне царствует С/С++. И это - показатель. Показатель самого питона как программного продукта. Затраты на внедрение питона в свой продукт (интерпретатор питона встроен в саму игрушку) и разработка на нем по показателю "трудозатраты/требования к ресурсам" оказались по меньшей мере сопоставимы с чистым с/с++. Вот собственно и все, на что я хотел обратить внимание почтеннейшей публики. :-))) А уж как это воспринимать - дело хозяйское...

> Значит - в общем, питон чего-то не дотягивает.

А если на это посмотреть с другой точки зрения ? До сих пор для этих целей (по крайней мере из известных мне проектов на х86) никто ничего не использовал, и тут на тебе - взяли и воткнули питон. Вы не учитываете того, что игростроение с примерно 2000 года - это маргинальная сфера ИТ. Примерно, как торговля контрфактными компактами на Савеле по сравнению с банковской деятельностью или экспортом нефтегаза. :-)) Тут уж если Акелла промахнулся - то промахнулся. И уже вряд ли когда-нибудь будет еще прыгать. Банковский софт и проч. ERP/CRM "солюшены" есть кому вытягивать в случае промаха, а игростроители могут расчитывать только на себя. И как следствие эта сфера ИТ _КРАЙНЕ_ консервативна. Так что вряд ли уж так стоит обращать внимание на отсутствие в ней массового распространения чего-либо. :-)))

Нынче все писатели http-приложений ломонулись на яве писать. Или с php долбятся.
Так что ответ получить будет нелегко. Ибо среди оставшихся "серпетнофилов" довольно низкий процент знающих что такое - "Tomkat (Servlet&JSP container), JBoss" и зачем его едят:-)

Tomkat — это Tomcat для KDE !!!

DonkeyHot пошел нахрен из этого треда.

Мы не однин контейнер кошек съели, и как к JSP питон прикрутить умеем, и пердлявый пончик нам не указ!!!

Серпентофилы

Slackware 9 с ядром 2.6.0-test1

2Серпентофилы

Самое интересное что названия Python к змеям никакого отношения не

имеет, это шоу такое было типа летающих клоунов

Масяныч, ты уже собрал ядро 2.6.0 на бзде?
Или все с бсддб играешься в сортировку?
Тебе по-любому не дотянуть до того анонимуса который спутал питон с бизоном ;)

Так может обьясните мне, неграмотному, *зачем* вы это делали?

Slackware 9 с ядром 2.6.0-test1

Тебе по-любому не дотянуть до того анонимуса который спутал питон с бизоном ;)

Дык а че смешного ? Питон написан на yacc, как впрочем

и perl.

На yacc написан только парсер. Питон написан на си. Посмотрел бы я как ты сделаешь на яке gc. И потом, вот например BASIC можно написать на OCAML, ты скажешь что бейсик -- функциональный язык?

Slackware 9 с ядром 2.6.0-test1

Насколько я помню - yacc (bison) это анализатор грамматики, а не парсер

так и запишем : масяныч. не думает. не различает продукт и средства производства.

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

По-крайней мере первый Unreal был написан на собственном скрипте. У них на сайте статья в свое время валялась, где они объясняли (с упоминанием Хаскела и функционального программирования) зачем это им понадабилось - вначале новый язык создавать, а потом на нем уже логику программировать.

Скажите, а глядя на эту игру, Вы можете мне дать оценку ее требований к производительности железа (в целом, проц+видео) - относительно, скажем, первого half life? Действительно очень интересно.

Можно говорить о массовом _насыщении_ игрового рынка С/С++ и _специализированными_ языками (вторичными продуктами тех же С/С++). Вторжений как-то я вообще там не вижу (возможно, я далеко сижу). Что "трудозатраты/требования к ресурсам" оказались на уровне - верю. Вот только, думается мне, в массе своей игровые компании держат эту дробь на большем значении как числителя, так и знаменателя. И тогда другие показатели - зрелишность, видео-насыщенность - кстати, и минимальные требования к железу (не геймплей, конечно) можно улучшать. Мне, например, немного обидно за тех, кто мог бы играть в вышеозначенную игру, если бы она была сделана на Сях - но не могут, поскольку питон потормознее.

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

Т.е. игроделанье для писюков (и приставок) сегодня замешано на Сях и _спец._ скриптах. На телефонах к этому примешивается жабка. Все остальное - эксперименты (удачные, интересные ...). Так я вижу (издалека!) эту картину.

Да, а Монти Питон (в произношении действительно Пайтон:) к змеям действительно относится слабо.

.

> Скажите, а глядя на эту игру, Вы можете мне дать оценку ее требований к производительности железа (в целом, проц+видео) - относительно, скажем, первого half life? Действительно очень интересно.

Ну, первый HL - это, по сути, модифицированный Quake 2, со всеми вытекаюищми - типа 16 битного цвета. Эта игрушка, выпущена несколько позднее и здесь авторы позволили себе разгуляться :-))))) Для нее желателен проц не менее 300-400 и видюшка от 2-ой ТНТ.

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

Я не случайно говорил именно о соотношении - так как в данном случае важно именно оно.

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

Я бы не стал так сильно за них переживать - те разы, в которые питон тормознее С, составят от силы несколько процентов от общего потребления процессора игрушкой. Графика потребляет от 80 и выше процентов. Лишь в очень редких случаях ситуация иная.

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

:-))) Речь как раз о том, что безумцев то особо и нет.. :-)))

> Но пока нет массового распространения - говорить о прониконовении технологии в игростроение нельзя.

Да, безусловно. Но какие вообще программные технологии проникли в игростроение за последние 4-5 лет ???

На Python там (в Blade of Darkness) AFAIK была сделана токо игровая логика. Т.е. то за что в Q1 отвечал QuakeC. и, поскольку питон тоже компилируется в байт-код (хотя и на лету), производительность не страдает. Нет, конечно, из-за нестрогой типизации все равно работает не так быстро, как могло бы... но для AI и map-скриптов замечательно хватает. А целиком игру на нем писать, включая 3D-engine - это уже из разряда "а вот на QBasic тоже можно OS kernel написать!" =)

Кстати, я, помнится, следы Питона находил еще в некоторых играх, именно в качестве скриптового языка. И вот еще кое что - выдержка из FAQ'а "The Temple of Elemental Evil" (http://mywebpages.comcast.net/ibnobody/troika.html):

Q. What language are you writing the gamecode in? A. (S.M. 2/6) The renderer is written in C, the animation player is in C++, the game logic and user interface is also written in C, and most of the scripting is done in Python (thanks Guido).

кому не хватает GUI для питона:
www.iae.dp.ua

правда, только для бизнес-приложений

jet

>> Для нее желателен проц не менее 300-400 и видюшка от 2-ой ТНТ.

Ну, я играю в Counter-Strike в софтовой моде (графика не тянет). Правда, проц 800:) Вопрос был не в этом. Вопрос в том, пойдет ли питоновская игрушка на тех же 300-400?

>> Да, безусловно. Но какие вообще программные технологии проникли в >> игростроение за последние 4-5 лет ??? Что интересно, почти никаких (с моей профанской точки зрения). Ну, разве что если называть все более высокие версии DirectX (и новые фичи граф. адаптеров).

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

.

> С учетом того, что скриптинг (как указано другим коллегой) использовался только для логики и AI (я-то уж думал, _весь_ код был на питоне!) - тогда почти все мои возражения про требования снимаются.

Блин, ну как вы (вы лично и ваш коллега :-)) ) читаете ??! Я ДВАЖДЫ сказал, что на питоне только "внутренняя логика" и ИИ. :-))

1) http://www.linux.org.ru/profile/LamerOk/add_comment.jsp?topic=356275&repl...

2) http://www.linux.org.ru/profile/LamerOk/add_comment.jsp?topic=356275&repl...

Ну стормозил. Ну не учел. Ну зачем же так ругаться?:)

.

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

>А не подскажет ли ALL есть ли аналог Tomkat (Servlet&JSP container), JBoss на Pythoon? И вообще, каким образом делаются серверные приложения (HTTP).

Tomcat и Jboss - весьма разные вещи, т.е. кому действительно нужен сервер приложений - на Python есть подобные вещи, но я в них не вникал, (посмотрите на http://www.vex.net/parnassus). А у меня фирма маленькая, J2EE ни к чему, достаточно простые задачи для intranet (отчеты, запросы к БД) я пробовал делать на JSP/Tomcat, мне показалось громоздко, неудобно и медленно. Сделал на Tcl (mod_dtcl), а недавно перевел все на Python, через чистый mod_python безо всяких templates и тем более Zope. Мне нравится, особенно учитывая, что на этом же языке можно делать кроссплатформных гуевых клиентов (с wxPython).

> Насколько я помню - yacc (bison) это анализатор грамматики, а не парсер

А насколько я помню yacc (bison) - это именно парсер (он же анализатор грамматики), а lex (flex) - это лексер.

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

> Они есть и на перл и на lua и на рhp.

Насчет спеков на lua нельзя ли поподробнее. Насколько я знаю в lua даже синтаксис объявления переменных с lexical scope менялся несовместимымым образом от lua 3 -> 4 -> 5.

P.S. Вам удалось в lua развернуть function из байт-компиленного представления в исходник? У меня с наскоку не получилось.

> А насколько я помню yacc (bison) - это именно парсер (он же анализатор грамматики), а lex (flex) - это лексер.

Это не так важно, в сравнении с заявлением масянычя что "Питон написан на yacc, как впрочем и perl". Вот уж действительно перл ))))

GUI

А почему говоря про жабу все вспомнили только тормозной SWING? Давно уже есть SWT, который быстрее в разы - скорость даже на моей тормозной тачке не отличается от С++ приложений. Если бы придурки из сана признали что провалились со своей идеей SWINGа, никто бы уже не считал что жаба душит. Ну, может gcj, кстати, он есть на большем кол-ве платформ, чем питон ;), но до качества жабы недотягивает - дотянет - у жабы надежда только на него. Кто не верит что на жабе можно писать быстро работающие приложения - поставьте eclipse (www.eclipse.org) и убедитесь.

Посмотрел я на это "Эатмение". Смешная штука, однако. С одной стороны, действительно скорость собственно виджетов поражает быстротой (по сравнению со свингом). С другой - чувствуется, что функциональный-то код работает на жабке - притормаживает. В результате - двигатель "Гольфа" в корпусе "Порша". Странные ощущения... Да, проц совсем не самый быстрый, PIII-800

И еще - SWING - не ошибка. SWT убивает идею кросс-платформенности (точнее, до тех пор, пока он не стал частью J2SE). В мире жабы только Сану позволено писать нативный код:) Если серьезно, лично у меня, жаваписца, жабские либки с нативным кодом вызывали, вызывают и будут вызывать естественное отторжение. Да и на нынешнем железе свинг бегает _приемлемо_ быстро. Посмотрите на мой любимый jEdit - он, кстати, работает на любой платформе с j2se 1.3+ - а таких платформ, думается, больше, чем поддерживаемых SWT.

>А почему говоря про жабу все вспомнили только тормозной SWING?

В жабе глуп сам исходный принцип - статический в основе язык исполняется тормозным полуинтерпретатором/полукомпилятором. Я не спорю, на java можно достичь приемлемой эффективности почти для любой задачи (и можно бесконечно развивать библиотеки и VM) - но все это громоздко и некрасиво. Програмировать на жабе эффективно - неудобно, а програмировать удобно - неэффективно либо невозможно. Почти любая задача на Python решается в разы менее трудоемко, а обычно и выполняется быстрее.

Другое дело, что большинство производящих "программный продукт" контор (начиная с самой богатой) заинтересованы именно в громоздких трудоемких средствах, поэтому и обзывают Python "скриптовым" языком (сам GvR его так не называет), мол это все несерьезно...

GUI

to svu:

Вот и начальству моему показалось, что swing бегает "_приемлимо_ быстро", а теперь покупатель говорит, что ">256M на клиентских машинах? Да вы с дуба рухнули.".И теперь идея отказаться от толстого клиента и переписать всё так чтобы клиентом был браузер. А всё из-за того, что испугали загазчика swing'ом. Нифига сан не понимает в гуях. И да,ты прав, только Сану - нативный код, но только Сан делает вид, что не слышит, и не собирается ускорять swing нативным кодом. Вот и получается, что скрипт написаный студентом на коленке, используюший perl+tk работет бвстрее, чем написанный профессионалом на жабе. Все делают вывод, что жаба - тормоз, и или продолжают сидеть на скриптовых языках (те кому кросс-платформенность нужна) или идут на .net. И они, в общем-то, правы - выбор есть. Поэтому я и вижу будущее жабы за gcj, поскольку со SWINGом он не дружит (в т.ч. из-за лицензий), а с swt - за милую душу.

Да, Swing - тормоз еще тот. Лично могу засвидетельствовать, на Athlon 1Ghz 256Mb мало-мальски большие жабские проги того... притормаживають. А вот SWT'шные - нет!

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

Кстати, на 256 можно запускать вполне себе толстые жабские приложения. Зачем же больше памяти?

Про нативное ускорение свинга. awt славен тем, что предоставляет виджеты и функции отрисовки, доступные на любой платформе. Виджеты свинг игнорирует, отрисовку - использвует. Как я понял, swt делает то же самое (custom widget set), но на С (или я вру - и он использует нативные платформенные виджеты? - тогда у него должны быть большие ограничения на переносимость). Тем самым объем нативного кода по сравнению с awt сильно больше, жабского - сильно меньше. Всякая параллель хромает, но мне почему-то это напоминает многократно обсужденную тут ситуацию с переносом некоторых функций отрисовки в ядро НТ (в конце концов, что такое нативный код с т.зр. жабки, если не "ядро ОС"?). Выигрыш в производительности - проигрыщ в архитектурной "строгости". И потенциально - в переносимости. Кстати, я запамятовал - какая лицензия на сырцы swt?

Вот в том-то все и дело, что SWT использует нативные виджеты! За счет этого собственно и достигается platform-consistent look&feel.

Да, кстати. Как уже было сказано, 256Mb зачастую *недостаточно* для толстых жабских Swing-приложений. Проверено на практике. Хотя, Eclipse тоже тот еще монстр. Но зато проц так не грузит.

Тогда скажите мне, плиз, что они будут делать на платформе, на которой нет виджета "дерево"? Или такой виджет есть везде? Соббсно, мой вопрос вот к чему - либо они должны поддерживать "минимальный общий" набор виджетов (как делает awt - в результате чего сам набор удивительно скуп) - либо они должны иметь проблемы с переносимостью.

Про 256М спорить не буду. Готов поверить, что можно наваять прикладуху, которой 256 будет мало. Но все, что я видел - прекрасно ложилось в 256М. Включая eclipse (правда, я только смотрел на нее - больших проектов не грузил).

А то же, что wxWindows. По принципу - если есть нативный, использовать, , иначе ваять свой.

Мрачно как-то... А как же консистентный l&f? Кстати, даже наличие виджетов на некоей платформе не делает их одинаковыми по набору доступных свойств и методов. В пределе, все виджеты однажды могут оказаться не-нативными. Получаем тот же swing, только реализованный "в ядре" (поэтому сильно быстрее, это правда). Да, так можно жить. Только все-таки напомните мне, плиз - swt Open Source или нет? И - главное, если Вы так уж боретесь за скорость GUI - может, просто лучше все сразу на C наваять?:) Кстати, вообще скриптовые языки - действительно лучше предназначены для построений визуальных аппликух. Один tcl чего стОит...

Кстати, только сейчас сообразил - к вопросу о 256М - это не тяжелый GUI делает приложения такими большими, а внутренние функции - и в этом смысле SWT никак не облегчает положения. Сам по себе swing достаточно легковесен в смысле потребляемых ресурсов (в смысле, по сравнению с цифрой 256M).

Что касается look&feel - ну что поделать, если нет такого виджета? Так или иначе приходится ваять многое ручками, так всегда было и всегда будет. Да вот хотя бы под Вынью сколько реализаций TreeListView и тулбаров есть? Другой вопрос, что как правило система предоставляет некий "blending API", т.е. способ получить системные цвета, части отрисовки стандартных виджетов и т.д., а уже из них можно склеивать свои. И они вполне вписываются в систему.

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

Использование C/C++ - а как быть с "compile once, run everywhere"? Да и с compile-time портабельностью тоже проблемы... Лучшее, что пока есть, это wxWindows, но платформ он имхо покрывает пока маловато.

Насчет памяти - так это уже наезд на саму жабу, ну право же, как можно! =) Кстати, а вот что там насчет .NET/C#? Мои эксперименты на мелких прогах показали несколько заторможенную загрузку, но отменную скорость во время собственно исполнения (кстати, "арифметика" на C#+CLR бегает заметно шустрее, чем на Java+JVM). А вот как с толстыми прогами?

Если нет виджета - действительно нужно его отрисовывать, никто и не спорит. Просто тогда лучше отрисовать ВСЕ виджеты - тогда хотя бы будет консистентность внутри приложения. Или я не прав? И для этого использовать платформенно-зависимый способ отрисовки - тоже, в общем, можно. Только все-таки лучше сделать некий HAL для отрисовки (для удобства портирования) - типа awt (если выкинуть из него виджеты, которые swing все равно не использует). По-моему, такая архитектура красивее и логичнее. Остается только вопрос в том, какую ее часть делать нативной, какую - жабской. Стремление Сана к минимизации нативного кода - вещь осмысленная. Да, при этом несколько страдает производительность при отрисовке виджетов. Им кажется, что эту жертву можно принести. Наверное, я с ними соглашусь. Кстати, насколько я знаю, отрисовка на винюковой платформе реализована через directx - все-таки они думают о производительности на десктопе, только они не хотят поступаться принципами. Уважаю их за это:)

Про compile one/run everywhere - извините, не понял. Что с переносимыми виджет-сетами для С есть проблема - знаю.

Про арифметику - немного странно. По идее, однажды скомпиленный jit-ом байткод должет давать нативную производительность в обоих случаях. Или "налог" на объекты и стек в жабке больше? Или все-таки Вы используете в С# указатели в циклах - тогда сравнение не очень корректно, хотя сразу же объяснимо:)

Кстати, прямо сейчас на slashdot народы базарят за виджеты. Так вот там ребята утверждают, что jbuilder и idea (и распоследний netbeans) не отличимы от eclipse по скорости. И если это даже не совсем правда - ИМХО даже 10% отличие в скорости не окупает "отхода от принципов" (и потерь в портабельности, и нестандартности). Кстати, там же мне напомнили, что swt - open source. Это они маладцы. Да, кстати, а вот если кто действительно хочет компилить нативный код из жабки чере gcj - ИМХО пусть лучша сразу забивается на gtk-шный binding. То же gtk, но накладных расходов меньше.

Если отрисовывать *все* виджеты, то возникает сильное желание нарисовать их по-своему... и в итоге Swing'овые проги под любой ОС смотрятся "чужеродными". Если же рисовать самим, но с оглядкой на настройки ОСа, все равно можно попасть в чудную: история появления GUI-скинов в WinXP тому пример. Trolltech всем рассказывала сказки, какой у них гуй замечательный, и шта его от винды не отличить (и в принципе были правы)... а потом вдруг раз - и все вылезло, пиши manifest, не пиши. Пришлось править. А на wxWindows проги спокойно продолжили работать дальше...

Далее. Стремление к минимизации нативного кода. Мне мало интересна их идеология, мне на компе работать надо! И если на вопрос "а почему оно тормозит" мне будут рассказывать про чистоту кода (или я своим заказчикам) - дальше я слушать просто не буду. Более того, как уже было замечено, только Sun практически может безболезненно делать native-code вставки, ибо распространяет их в составе JRE. Так что мое глубокое имхо - чем больше стандартных классов жабы будут нативными, тем лучше. Java-программерам от этого хуже никак не станет, а вот нам, юзерам, всяко лучше.

Про C++ я сказал в том смысле, что на жабе прогу можно написать и скомпилить на одной платформе, а потом результат спокойно запускать где угодно. C++ надо перекомпилировать, что для определенного контингента пользователей составляет проблему =)

Про арифметику. Никаких указателей, тупой алгоритм в лоб. Если конкретно, это был Адамс 4-го порядка. WinXP, JRE 1.4.1 против .NET 1.1. Так вот, C# оказался настолько же быстрее Java, насколько C++ быстрее C#. Правда, разница в обоих случаях была порядка 5%. Но все же... =) Может, не зря говорят, что M$ с самого начала оптимизировала CIL под JIT-компиляцию?

To anonymous (2003-08-13 14:17:11.15823):

Полностью согласен. Если идеология не позволяет эффективно решать задачи - такой идеологией надо поступиться, она для теоретиков.

To svu:

LGPL она. Возможно, что это одна из причин почему представители Сана заявили, что никогда не включат swt в официальный дистр. По поводу платформ - она держит Motif, gtk и другие кросс-платформанные библиотеки. Да, возможно что наладонники из коробки не поддерживаются, но всё таки когда ты пишешь gui для нормальной системы и наладонника, это будет разный gui в любом случае - другие эргономические концепции.

ты ничего не хнаешь о Java

Про три модели отношения к отрисовке виджетов - я, честно говоря, не понял Вашу мораль. Что же Вам лично нравится? Полная независимость (ценой СВОЕГО лук-н-фила), частичная (с потенциальными "ляпами") или полная нативность (правда, тогда объясните мне как быть с отсутствующими виджетами/свойствам/событиями)?

Тормозить, безусловно, не должно. Но тут мы уходим с проблемы использования виджетов на проблему жабки на десктопе вообще. Как я и другие тут уже отмечали, на сегодня разница в скорости между разными подходами (особенно если эту разницу сравнить с общим торможением jvm) - не настолько велика. "Быстрогуий" еклипс тормозит в своих "потрохах" примерно так же как современным "свингомордые" среды.

Про то, что компиляция - не проблема, даже как-то обсуждать не хочется. Если Вы много работали на С(С++), наверняка должны представлять уровень проблем для создания переносимой (даже в сырцах!) сложной проги. Даже с использованием wx для "морды". Даже разные компиляторы на одной и той же платформе способны порой доставить вам некоторое количество отрицательных эмоций (например, какой-нибудь коммерческий компилятор и gcc под соляркой на спарке)

Да, еще про "мало интересна их идеология". Я - разработчик. И я больше доверяю технологии, где есть некая продуманная архитектура (последовательная идеология). Это дает мне некие основания считать, что при разработке технологии авторы _думали_, _планировали_ - а не просто лепили "от балды". В жабке я люблю именно то, что почти за каждым решением я чувствую _мысль_ (хотя я не всегда соглашаюсь с этими мыслями). И что я особенно люблю - это некий юношеский максимализм, проявляющийся в нежелании жертвовать архитектурной целостностью ради призрачных целей улучшения _видимой_ производительности.

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