>> Жаль автор не рассмотрел числодробилку

Числодробилка на java работает не так уж и плохо. Я думаю не трудно догадаться почему. Вот если работать не с примитивными переменными а с оболочками над ними тогда да - тогда жопа ...

>>Автор совсем пропустил затраты на кросплатформенную реализацию QT. Там >затраты немаленькие. А на JAVA я этим даже не занимаюсь.

Я думаю затрата только одна - пересобрать (перекомпилить) проект. Однако если речь идет о кроссплатформенности не только на уровне GUI, то пользуйте ACE - там есть все что нужно. Вообщем ACE + QT.

>> Второе - да там за все бабов платить надо! Прибвьте к последнему TAO ( ACE + QT + TAO ). А вообще есть КУЧА отличных FREE'шных брокеров. ( Мы еще используем OMNI - он работает с python - ом ).

>> Да там сетку копанентами загрузить придется! Хилым каналам кирдык!

Хм ... Вы ребята меня удивляете. Просто складывается впечатление что вы НЕ понимаете о чем вы говорите!

>> Да там у клиента такая тачка должна быть! С такими ресурсами!

1) Mozilla занимает 31M резидентно ( Вот сейчас посмотрел ) и если Вам не нужна на стороне клиента изощренная логика, то можно обойтись и без апплетов ...

2) Но всетаки если речь идет об аплетах, то на этом поприще конечно конкурентов у java нет (почти).

>> А давайте тепрь то-же самое на QT сваяем!

QT - это НЕ http browser, не J2EE контейнер, и не язык программирования а просто библиотека для разработки GUI.

>> Просто на JAVA+-SWING можно все и везде. Отнюдь не везде и не все. Бросьте этот ваш юношеский прыщавый максимализм. Ваша заметка ( без обид ) похожа на письмо Дяди Федора к маме и папе. ( Это та где писали Дядя Федор, затем пес, а затем кот ... ) Вы же вроде интерфейс то на http рисовали ? Помните "Лучше меньше да лучше!" В.И. Ульянов. А анекдот про неуловимого Джо помните ?

У java есть своя ниша. Не стоит ее переоценивать.

>> А QT+C++ можно только GUI, и далеко не везде.

Только GUI может QT ( что вообще говоря не правда. ) Хе-хе, пока все написато на С ( даже java vm ) С++ может все и везде. ( Каков удар - таков ответ ) А для полного счастья, разработчикам на C++ очень рекомендую ACE.

( А вообще мне больше нравится Ada )

Captain Nemo

2Skull (*) (2003-03-21 12:35:24.879463)

>Оптимально Lotus Domino поставить, а не изобретать велосипед. :)

Ха-ха. Очень смешно. :)) Особенно про Lotus Domino :))

"... а еще хороше бы построить такую башню, чтоб с нее Москву было видно..." (с) А.В.Гоголь

>Тык для сервера нужна инфраструктура, а не GUI
Вот я про то и говорю, что нефигово было сравнить QT и JAVA в аспекте где QT не катит, ели уж он JAVA поставил в неудобную позу.
Чего, например, не рассмотреть всякие палмы, мобилы, пылесосы, печатные машины,...? Что-то QT туда не очень пытаются засунуть, несмотря на "заведомую крутость".

А то сравнил "шнурок с ботинком", да еще и выводы сделал. Умора.

Ни чего не имею против QT+C++ Круто. Согласен. Целыми днями на KDE пялюсь. Но QT всего лишь библиотека+IDE+еще чего-то, а JAVA это образ жизни.

2 vada

> А то сравнил "шнурок с ботинком", да еще и выводы сделал. Умора.

это почему?? единственное что, название статьи некорректное. но после прочтения первого абзаца (aka аннотации)

"В этой статье сравнивается эффективность использования C++/Qt и Java/AWT/Swing для разработки программного обеспечения с пользовательским графическим интерфейсом."

я не заметил ни малейшего сравнения "шнурка с ботинком"

и далее тоже, имхо, весма правильно java сравнивается с C++, qt со awt/swing

Несколько не по теме статьи, но в контексте разгорающегося флейма: о причинах недолюбливать Jav'у. На мой взгляд, главная проблема Java это то, что она -- не два не полтора.

С одной стороны -- в принципе невозможно добиться такой контролируемости кода как в C, а с другой, Java -- язык гораздо более низкоуровневый и гораздо менее гибкий чем, положим Python или Perl. Стало быть, ни по скорости исполнения, ни по скорости разработки он не оптимален.

Да и с переносимостью постоянно проблемы -- одна локализация чего стоит (кто Unix'овых машинах Jav'ные приложения запускал -- знает как тщательно надо выбирать локаль :). И стандартность API в достаточной мере блеф -- те кто следил за развитием Java, мог наблюдать с какой легкостью Sun их менял, особенно не заботясь об обратной совместимости, а кто его знает чего им завтра в голову взбредет... Открытость архитектуры так же какая то странноватая -- для чего-то исходники доступны, для чего-то нет...

Боюсь, что кабы не Oracle, поднявший Java на знамя, то перспективы ее были бы крайне сомнительны :(

>2) Device driver. И тогда для С/C++ не надо никаких оберток, а для java опять нужно оборачивать ...

Кто сказал "нужно оборачивать" ? Pure java решение рулит.

> i.e. open/read/write/ioctl - покрывают 99.99999999.... всех потребностей

Типичный подход железячника - засунуть всё внутрь железки. Впрочем, здесь pure java решение тем более подойдет.

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

Вот те бум! По скорости разработки Hello World? А насчет скорости исполнения более подробно, пожалуйста.
Python не знаю, сказать ничего не могу. А насчет perl-а это, по моему, не есть верно.


> Да и с переносимостью постоянно проблемы -- одна локализация чего
> стоит (кто Unix'овых машинах Jav'ные приложения запускал -- знает как тщательно надо
> выбирать локаль :).

Здеть то что Вас не устроило ??? При компиляции можно указать кодировку файла.
Может проблема в том, что одна и та же программа может неверно воспринимать файлы разных кодировок?
Это да. Но откуда программе знать, что файл на иврите или в koi8-r? Поэтому по умолчанию берется текущая локаль.


> развитием Java, мог наблюдать с какой легкостью Sun их менял, 
Вы ткните пальцев в те программы, где интерфейс сохраняется неизменным. Hello World не конает.
Хотя конечно есть специфичные вещи, но исключения всегда есть.


> Открытость архитектуры так же какая то странноватая -- для чего-то исходники доступны, для чего-то нет... 

Я понял, вы путаете интерфейсы и реализацию. Интерфейсы всегда открыты и великолепно документированы. А реализаций море. Чего стоит портал http://jakarta.apache.org/.

> Боюсь, что кабы не Oracle, поднявший Java на знамя, то перспективы ее были бы крайне сомнительны :(

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

>С одной стороны -- в принципе невозможно добиться такой контролируемости кода как в C, а с другой, Java -- язык гораздо более низкоуровневый и гораздо менее гибкий чем, положим Python или Perl. Стало быть, ни по скорости исполнения, ни по скорости разработки он не оптимален.

Про скорость разработки Java vs Perl можно поспорить. Особенно если несколько человек и кода _много_ и поддерживать совместимость _нужно_. Perl тут вообще сосет.

>Да и с переносимостью постоянно проблемы -- одна локализация чего стоит

Не заметил проблем. В чём они?

>И стандартность API в достаточной мере блеф

То, что называется J2SE принципиально уже не меняется, только развивается.

>Открытость архитектуры так же какая то странноватая -- для чего-то исходники доступны, для чего-то нет...

Скачать полные исходники J2SE SDK не проблема. Реализации API тоже почти все есть (если не находятся в стадии early access).

Перспективы Java таковы: по мере роста мощи компьютеров и появления новых версий, преимущества C++ будут всё более сомнительными, а цена разработки C++ vs Java всё менее выгодной для C++.

>> низкоуровневый и гораздо менее гибкий чем, положим Python или Perl.
>> Стало быть, ни по скорости исполнения, ни по скорости разработки он не оптимален.
>А насчет скорости исполнения более подробно, пожалуйста.

Скорость исполнения программ на Яве и на Питоне слишком сравнима, чтобы первая как-нибудь могла конкурировать за звание "лучшего средства":-). При том, что средний размер эквивалентного кода на питоне раза в 2 короче, незначительное преимущество Явы в run-time не интересно. Ибо если нужна скорость - можно писать на Haskell,OCaml,etc - будет быстрее и работать и писаться. Или на C,C++,etc - возможно будет еще быстрее - но дольше.

>>А как же Qt, KDE и Linux? Основные их разработчики - это Норвегия, Финляндия и Германия.

Что касаетсья ядра, то рекомендую таки посмотреть на linux/CREDITS
Американов там больше чем всех остальных вместе взятых.

QT А ,эта та небольшая GUI библиотечка, которая скомпилена америкосским компилерами (g++, VC++) ?
и ту которую пользуют < 1% GUI приложений ? Значение QT как платформы ничтожно, лично я вообще без нее прекрасно обхожусь. Единственная прога которая у меня с ней слинкована - это licq.


KDE это тот монстрообразная надстройка для управления окнами и утилитами? Даже в мире линукс ее пользует не шибко много народу... Ценность QT для бизнес приложений стремится к 0. Или ссылку в студию на бизнес систему для банка, предприятия и т.п. которая не может работать без KDE?

А ну как в студию СУБД ?, компилер, Кады, Редакторы которые >50% кода написано за переделами USA?

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


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

> Скорость исполнения программ на Яве и на Питоне слишком сравнима, чтобы первая как-нибудь могла конкурировать за звание "лучшего средства":-). 

http://www.flat222.org/mac/bench
Вот что-то откопал, по моему как-то они не сравнимы... 

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

Блин! Ананас! Ну ты так и не понял! Это не сравнение. Это курам на смех. Это годится только для директоров (читай фраеров ушастых), которых требуется накренить в определенную сторону.

Можно сравнить продуктивность программирования на C++ и JAVA (Очень спорно) Можно сравнить быстродействие программ на C++ и JAVA (Правильно) Можно сравнить ресурсоемкость программ на C++ и JAVA (Правильно) Можно сравнить существующие IDE для разработки на C++ и JAVA (Серьезно мимо) Но это только малая толика вопросов, возникающих при выборе того, или иного инструментария для разработки. А почему автор не сравнил расходы на разработку? А распределенность капиталовлажений по времени жизни системы? А сколько стоит сопровождение с учетом переносимости системы? А сколько стоит обновление системы на сотне рабочих мест? Че? Это теперь все побарабану? Деньги теперь ни кто не счетает? Какой смысл в сравнении гвозля и швейной иголки при протыкания дырки? А в чем дырка? А для чего дырка? А размер дырки? А усилия протыкания? А сколько дырок? Тысячи вопросов... А сравнив на сколько дырка более круглая, при протыкании газеты, ни чего решить нельзя. Бред какой-то.

2 vada

вообще-то я ни слова не сказал о ценности данной статьи в частности и подобных сравнений вообще. я только сказал, что в статье сравнивались обекты одного и того же класса т.е. C++ vs Java и QT vs AWT/Swing, а отнюдь не "шнурки с ботинками"

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

>Вот что-то откопал, по моему как-то они не сравнимы...
Выбором тестов можно многое сделать:-). Python обязан быть медленнее - по причине интерпретируемости, динамической типизации и, возможно, еще нескольких свойств. Особенно в ситуации, когда Python интерпретирует текст, а Java закружает уже байт-код и при этом имеет возможность эффективно пользоваться JIT-ом. Более коректно было бы сравнение скорости выполнения реальных программ - с _большим_ обьемом кода, при условии, когда львиная часть времени не сосредоточена в одном цикле, а разбросана по разным методам и не учитывая время компиляции питоном в байт-код - например вынесением главной части в модули, как обычно и делается.

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

2sadov
> Да и с переносимостью постоянно проблемы -- одна локализация чего стоит (кто Unix'овых машинах Jav'ные приложения запускал -- знает как тщательно надо выбирать локаль

native2ascii запускал?

> Боюсь, что кабы не Oracle, поднявший Java на знамя, то перспективы ее были бы крайне сомнительны :(

Боюсь, что кабы не известность Oracle TM, его(оракла) Java-продуктами вообще никто бы не пользовался. Они даже application server свой написать не смогли, а у Orion лицензировали.

Эка блин - закинули пачку резиновых молотков в палату со злостными больными суицидом. Все нормально автор сравнивает, а к словам цепляться - удел сами знаете кого (Л...В!)

Постарался оценить сколько нужно протоптать "чтобы оно заработало" да постарался посмотреть "как оно работает". Как говорил Иван Грозный в к/ф "И. В, меняет профессию" :"Любишь боярыню? (- Люблю!)...- Так че тебе собака еще надо!"

:)))

to ifconfig (*) (2003-03-21 16:54:12.855215)

>QT А ,эта та небольшая GUI библиотечка,
Да, ничтожная :-) 30 метров зажатых сырцов :-)

> которая скомпилена америкосским компилерами (g++, VC++) ?
И ещё рядом кокосовских компИлеров http://www.trolltech.com/developer/compilers/index.html

> и ту которую пользуют < 1% GUI приложений ?
Уважаемый, вы треплитесь. :-) Сколько всего приложений? И сколько <1%?

>Значение QT как платформы ничтожно, лично я вообще без нее прекрасно обхожусь.
А я вот без джавы, и вокруг меня - тоже без джавы... И чуть подальше - тоже джавы нет! Не находите, что это лишь дело точки зрения и областей применения?

> Единственная прога которая у меня с ней слинкована - это licq.
Дело ваше. А у меня весь десктоп и вокрг: значит ваша одинокая лиску :-) не показатель.

> KDE это тот монстрообразная надстройка для управления окнами и утилитами? Даже в мире линукс ее пользует не шибко много народу...
Очевидно, опять голословно. Категории у вас "много-мало" - очень точные.

> Ценность QT для бизнес приложений стремится к 0. Или ссылку в студию на бизнес систему для банка, предприятия и т.п. которая не может работать без KDE?
Qt != KDE. Сассекстори читайте на сайте троллей http://www.trolltech.com/success/index.html?cid=1
Всё прочее, включая списки приложений - тамже.

>А ну как в студию СУБД ?, компилер, Кады, Редакторы которые >50% кода написано за переделами USA?
Что да - то да.

>И в конце концов (не забыв железячников), хоть один проц на котором это можно будет исполнить.
Железки, 95% изготовлены ВНЕ пределов США. Крупнейший производитель памяти Samsung, проц у меня стоит хоть и Интёл (здесь) и АМД (дома), но изготовлены в малазии. и.т.п.

>Насчет американцы или там живущие.. Да какая нафиг разница, если люди там работают, значит есть причины не работать дома.. И этого достаточно чтоб формально продукты их труда называть американсими. Более того, процент местных аборигенов в софтверных компаних не такой уж маленький. Приезжие вообщето восновном кодеры..
:-)

2 Captain Nemo.

>> но при этом компилить их под кучу разных платформ 
> Дак веть на чистой java device driver не напишеш ...
> По видимому Вы дружище просто не понимаете о чем Вы сами говорите.

Нет, это вы не поняли/не вняли того примера, который я приводил. Что-ж
попробуем еще раз, может дойдет ;)

Во первых я приводил пример когда R&C's Device - это допустим коммутатор (или любой другой девайс, который общается с компом через что-то
 стандартизованное - ethernet-link/USB/COM/LPT/.....), который управляется
 J-апплетом с админского компа.  Что мы будем иметь в  случае если R&C
 будет это все писать на C/C++/Pascal/etc.. - необходимость давать
 бинарники под кучу разных OS и разных версий этих самых OS, для
 того, что-бы это все работало. А на Java - один код, он и на eMac-е пойдет, и
 на Linux x86, и на WinNT, и еще много где. 
Java тем и уневерсальна, что для того, что стандартизовано - у свои
 библиотеки классов для работы с этим нечто. То есть на Java мы не
 задумываемся вообще о том, на какой аппаратной платформе будет
 исполнятся код - он будет работать и все тут. 
А возвращаясь к R&C's Device - раз этот девайс подлинкован к компу
 допустим через что-то поверх чего проложено TCP/IP (хоть null-модемом), то
 апплету который будет этим девайсом рулить нужно знать только IP и порт, где этот R&C висит, остальное не важно - оно будет им рулить сколько влезит. 

сСерёга :-) откуда ты такой грамотный? :-)
Ты всегда девайсами через джава апплеты рулишь? :-)

2 Captain Nemo.

>Для каждого устройства или платформы нужна СВОЯ собственная jvm,

прадва, а я и не знал...

>и написать эту jvm значительно сложнее чем библиотеку на C.

Да, но написав один раз jvm под конкретную платформу получаем сразу бонус такой мааасенький-мааасенький - под этой платформой будет работать огромная толпа приложений уже написанных на Java, и еще прог-софтин-программулинок, созданных позднее тоже будут работать, пусть даже прога писалась для мобильника, а мы ее под соляркой на спарке пускаем

> И в любом случае полный комплекс jvm + java программа ВСЕГДА по > ресурсоемкости будет проигрывать ЛЮБОЙ откомпилированной программе > не важно на чем последняя была написана С++, PLI, ADA, ASM ...

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

Прямо таки спор немого, глухого и слепого! Кождый инструмент предназначен для своей задачи! Java - 100% кроссплатформенная система и все в ней подчиняется этому принципу. Отсюда и издержки.
Интересная мысль о том что проги на С можно делать переносимыми. Но я не знаю пользователей, которые будут собирать себе проги. Они ваще не знают что программы компилируются. Это не их проблемы.
Полностью поддерживаю Vada по поводу построения корпоративных приложений. J2EE - гениальная вешь. Скорость разработки явно не ниже чем для сей, особенно если в конторе применяется зоопарк операционок: Win, Linux, FreeBSD, MacOS 8-9, MacOS X. Готов поспорить с любым.

"сСерёга :-) откуда ты такой грамотный? :-) Ты всегда девайсами через джава апплеты рулишь? :-)"

нет, просто видел своими глазами как админ наш в локалке свичем через апплетик рулил ;)

Хе.. а я вот видел как апплетик завалил установку за несколько килоуе. Не успел отработать :-) Думаю, что этот апплетик ой как долго и нудно писался, особенно низкоуровневая часть... Хотя, предполагаю - что это не более чем фронтенд к системе конфигурирования, не более того.

Борис_с (свистящий зуб чтоль вышибли? :-) - эко тебя...) Вот немножечко перефразирую фразу "Линукс - 100% кроссплатформенная система..." Зачем мне нужна ещё одна платформа (про жабку)? :-) и с этой проблем хватает порой - без этого сэндвича из платформ.
Проги на си трудно сделать переносимыми, их можно сделать посикс-соответствующими, к примеру :-). Насчёт спора? Хмм... странное предложение слепого поспорить с глухим о чём спорить будем? Об изобразительном искусстве, или о музыке? :-) ... Вот и я про то :-) Из васт-фуда мне блинчики с мясом нравятся больше :-))

По существу, гуеклепалка какая клёвей, кутя али жабка? :-)

Опять эта блядская тупая жаба, задрали ею в универе уже

Не буд цитировать, некогда..

30 Метров это что?? либа?? или может таки примеры, доки, прочая муйня..?
во вторых, это что много??

компилеры.. посмотрел..
Borland C++ Windows 95/98/NT/2000/XP
CDS++ Reliant UNIX
Compaq C++ Tru64
GCC / egcs most platforms
HP aC++ HP-UX
Intel C++ Linux
KAI C++ Linux
MIPSpro IRIX
Sun WorkShop / Forte Developer Solaris
Visual C++ Windows 95/98/Me/NT/2000/XP
IBM xlC AIX

где хоть один не штатовский...

а причем тут java? я вообще не об этом гутарил, я все больше возмущался за фразу "ТУПЫЕ АМЕРИКОСЫ".. Задрало ее уже регулярно слышать от УМЫХ СНГовшиков.

но если уж и сравнивать значимость java vs QT+KDE.... то сравнивать ваще нечего... ибо без первый сейчас главный (пока) игрок на рынке бизнес-приложений... Второе, Хорошая GUI библиотека (правда ничем, кроме кросплатформености не лучше той же MFC) + расфуфыреный нагруженый побрякущками десктоп. Если бы в один момент он исчез вбезну, то это бы заметило очень мало народу.. О цифрах.. Доля линукса на десктопах достаточно четка известна..(печальная цифра) Доля KDE на линуксах ну никак не больше 50%.. Скорее значительно меньше... Правда есть еще и BSD.. но BSD+KDE вообще по пальцам мона пересчитать. Вот и можешь посичтать процент людей которые заметят пропажу сего шедевра.. Хотя я этим не вуоем случае не могу именьшить заслуги разработчиков, просто маштаб и значимость для индустрии все равно не та.. Ну это типа много авобмобилей.. Все по своему хороши.. Но если пропадет с рынка к примеру АВТО-ЗАЗ, то сильно плакать никто не будет.. А вот если ФОРД ил GM то это уже совсем другая история..


Ну за процы возразить нечего.. Производство тут вообще ни при каких делах, ибо это определяетсья СОВСЕМ другими показателями. Прочую компутерную атрибутику зачем привел??? она что умееть исполнять код?? ты бы еще китайские кулеры бы приплел...

anonymous> Про скорость разработки Java vs Perl можно поспорить. Особенно если несколько человек и кода _много_ и поддерживать совместимость _нужно_.

Ну знаете, ребята, это весьма голословно. Perl, разумеется, куда лучше приспособлен к быстрому прототипированию по тем простым причинам, что он использует более высокоуровневый языковые конструкции, возможна динамическая генерация исполняемого кода. А про встроенные механизмы работы с текстовыми потоками данных я и вовсе не говорю -- все гораздо короче получается. Проблема Perl'а, особенно в разработках больших проектов где много народу работает, лишь в том, что он несколько более рыхлый по структуре, одни и те же вещи можно сделать тысячью разных способов и при отсутсвии каких-то разумных стандартов на разработку в данном коллективе все может легко превратится в неудобоваримую кашу (но от плохих программистов и барадака в организации не страхует ни один язык:) Python же занимая ту же весовую категорию, этих недостатков лишен, строго объектно-ориентирован, кроме того имеет такую особенность как интерактивную моду, крайне удобную именно на этапе создания прототипов, и по общей идеологии он ближе к C и Jav'e.

nofate> Здеть то что Вас не устроило ??? При компиляции можно указать кодировку файла.

Да нет, все еще хуже! Возьмем готовые приложения -- известное дело, если запустить напр. Oracl'овый инсталлятор в какой-нибудь русской локали, то он рухнет, погребая незадачливого инсталлятора под невразумтельной лапшой своих ctack trace'ов. Причем в очередных патчах Real App-n Cluster'a не спасает даже LANG=C, подавай им en_US! И Oracle не одинок!

Опять же о стандартности и совместимости -- не кажется ли вам странным, что появляющиеся время от времени продукты, писанные на Jav'е так тесно привязанны к конкретной версии JRE? Я не буду говорить о всяких сторонних производителях, но такая ситуация даже у Sun'а (например в софте обслуживающем его SunRay'и)! Шаг влево, шаг вправо -- расстрел.

sseREGa> нет, просто видел своими глазами как админ наш в локалке свичем через апплетик рулил ;)

Ну дык этож девайс-то не настоящий -- он же небось по SNMP управляется, а попробуй реальной железке из своего компьютера подпихнуть JavaApplet драйвер из его-то sandbox'а :)

> невразумтельной лапшой своих ctack trace'ов. Причем в очередных
> патчах Real App-n Cluster'a не спасает даже LANG=C, подавай им en_US! И Oracle не одинок!

Встречный вопрос. Как у Вас работают приложения написанный на QT версии 1.X.X ?
Оракловый инсталятор не переделывался еще со времен 1.1 java. А насчет LANG, если мне мамять не изменяет,
то инсталятор у них при руской локали подымает руские профайлы. А тут может начаться пляска с бубнами,
то фонты криво содраны с виндовых, то фонты нормальные но не все. Когда-то я с ним много возился.
Лечится. Но если я в логику программы заложу, что все входящие данные в KOI, а мне придут в win,
то виноват буду я, а не java. Или нет?

> Jav'е так тесно привязанны к конкретной версии JRE?
Вы никогда не имели проблем с разными версиями libstdc++ ? Многое при написании программ
зависит от культуры программирования и нужности в совместимости. Возьмем пример
swing появился с версии 1.2. С версии 1.4.X встроен свой Logger. Если я завяжусь на эти вещи,
пойдет ли у меня программа на 1.1 java? Но написать код, который будет выполняться
на PDA И на PC java от 1.1 до 1.4 полностью реально.

> Опять эта блядская тупая жаба, задрали ею в универе уже
Дык, хули, Вы в нем делаете ? Вона в армию и повиг вся эта муйня!

> Более коректно было бы сравнение скорости выполнения реальных
> методам и не учитывая время компиляции питоном в байт-код - например вынесением главной части в модули, как обычно и делается.

Что-то Вы запутались. При запуске сначала идет компиляция в байт-код, а затем уже запуск
на исполнение и поэтому время затраченное на подъем jvm или python vm роли не играет.
Просто, как я понимаю python в нынешней реализации, как и perl это интерпритатор.
А java, все же ближе к native коду.

> Вы действительно считаете, что "Java-технологии" так уж неповторимы?
Пересмотрел свои посты и не вижу со своей стороны ничего подобного. Я подразумеваю, что для
java они есть и имеют сильное развитие. Все остальные пока отстают.

> Слегка резковато, но у меня сложилось мнение, что это всего лишь набор спорного качества библиотек, заставляющих программиста 

А поконкретнее, если Вас не затруднит, на примерах.

> Так что я бы поспорил. 
Всегда рад. :)

>поэтому время затраченное на подъем роли не играет.
Это если они догадались мерять время не посредством "time программа". Питон при старте(вероятно) компилит быйт-код. Возможно не весь - но модули точно компиленые лежат.

>это интерпритатор.А java, все же ближе к native коду.
Они оба гоняют байт-код IMHO. Только ява иногда пытается преобразовать его в native, а питон - нет. Посему 1 маленький цикл повторенный очень много раз питон делает намного медленнее.
Но в реальных программах это нужно не очень часто(хотя бывает). Посему разница должна быть меньше.

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

>А поконкретнее, если Вас не затруднит, на примерах.
К сожалению(или к счастью:-) затруднит. Какие технологии Вы имеете ввиду, говоря Ява?

> программа". Питон при старте(вероятно) компилит быйт-код. Возможно не весь - но модули точно компиленые лежат. 

Но как я понял, пинот все же интерпритатор. И тут он всегда проиграет. Я не знаком с
питоном и в по данной теме спорить не готов. :)


> Они оба гоняют байт-код IMHO. Только ява иногда пытается 

Ошибочное мнение. Для java можно указать режим client ( или hotspot по умолчанию) и server. В первом случае имеем быстрый старт и компиляцию по требованию. Во втором полную компиляцию.

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

Я бы про EJB высказался немного по другому. Реализация всего этого затруднена. Хотя языков несчесть и могу ошибаться.

> К сожалению(или к счастью:-) затруднит. Какие технологии Вы имеете ввиду, говоря Ява? 

Навскидку для WEB портала: Object/Relational mapping (под ним незаметно шевелится JDBC :), JSP (добавим struts для MVC и jstl для отображения, ну и JavaBean), XML/XSLT, JNDI, JavaMailm ну и ко всему этому JSSE, чтоб врагам неповадно было.

> А ниче, что сами американцы(или работающие там) Java и написали... А вообще они ВСЕ (чем пользуюсь я, да и большинство из вас) написали. А все остальные умные, и потешающиеся над америкосами не НАПИСАЛИ НЕХРЕНА сложнее клиентской прикладухи (да и ту, на американских тулзах )...

Ты тупой мудак, не представляющий масштабов оффшорного программирования.

2asoneofus:
>свистящий зуб чтоль вышибли? :-) - эко тебя...
Спасибо за беспокойство. Вроде пока все ОК ;-)

>Зачем мне нужна ещё одна платформа (про жабку)? :-) и с этой проблем хватает порой - без этого сэндвича из платформ.
Полагаю что тебе хватит и одной. У меня дома тоже Linux'а вполне достаточно. Но в моей конторе необходимо использовать как минимум 3 платформы: Linux, Win и Mac. От этого никуда не денешся. Вот и получается что единственным нормальным инструментом в такой ситуации является java. Хотя к теме статьи это никакого отношения не имеет.

"Преимущества" Ява-технологий

>Питон всегда проиграет
Несомненно. Главный вопрос - сколько. Достаточно ли чтобы пойти на удвоение времени разработки?

Дальше излагается мое дилетантское мнение - я не работал с этим на Яве. Но какой смысл спорить о том, что хорошо знаешь? Ведь в результате не получишь новых знаний:-)

>Навскидку для WEB портала: Object/Relational mapping
Это типа стандартные методы для сохранения состояния обьекта в БД? Тривиальная в случае питона вещь.
>JSP
HTML со встроеными кусками кода? Это есть на _очень_ многих языках.
>XML/XSLT
Это уж точно все умеют не хуже явы.

К тому же на фоне хаскелевского HaXML XSLT(и вероятно JSP) выглядит крайне убого, несмотря на недоделаность первого.

>JNDI
Всего лишь еще один API для прикручивания драйвера базы данных.

>(добавим struts для MVC и jstl для отображения, ну и JavaBean),
>JavaMailm и JSSE, чтоб врагам неповадно было.
Не представляю, что это если оно так уж круто:-( и по названию непонятно :-) Так что об этом пока спорить не могу.
=================
Итого для портала: API для разных БД и средства обработки результата, генератор HTML, преобразователь XML->XML, поддержка пары прикладных протоколов. Все указаное есть почи везде. И зачастую удобнее, чем в Яве(хотя бы по причине меньшего удобства самого языка). Так что особенного в Яве?

Для Boris_s:'''3 платформы: Linux, Win и Mac...единственным нормальным инструментом ... является java.'''

А как же любимый мною питон?

> Несомненно. Главный вопрос - сколько. Достаточно ли чтобы пойти на удвоение
времени разработки? 


Немножко встречный вопрос какие для python существуют средства разработки а-ля IDE.
Как они по функциональности сопоставими с java средствами IDEA, eclipse, JBuilder ?

> результате не получишь новых знаний:-) 
Ну для себя я немного преобрету знаний о python.

> Это типа стандартные методы для сохранения состояния обьекта в БД? > Тривиальная в случае питона вещь. 

Это самая малая часть возможностей, вот еще Object Caching, lazy materialization
through virtual proxies or a distributed lock-management with configurable
Transaction-Isolation Levels. Optimistic and pessimistic Locking is supported. Еще
можно добавить поддержку polymorphism. На сколько API всего этого в python стандартизировано.
Можете ли бросить немколько ссылок для изучения.

> HTML со встроеными кусками кода? Это есть на _очень_ многих языках. 
Это примитивизм. Все немного запутанней и в то же время проще. Бизнес логика отделена
от отображения. Времени занимает немного больше, при написании. Но, как всегда
оказывается при сопровождении и доработке, отладке намного проще


> Это уж точно все умеют не хуже явы. 
Стандартное API есть ? Вот я столько знаю XML парсеров под C++ И все друг с другом несовместимы.

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

>(добавим struts для MVC и jstl для отображения, ну и JavaBean), 
Маленький примерчик:
<table>
 <c:forEach var="object" items="${items}">
   <tr>
    <td><c:out value="${object.id}" /></td>
    <td><c:out value="${object.value}" /></td>
   </tr>
 </c:forEach>
</table>
Выволится какой-то список. Заполняется он не на странице, и акк он получается на данном
уровне нас не интересует.

>JavaMailm и JSSE, чтоб врагам неповадно было. 
оопс, javaMail - так яснее? :)
JSSE - Java Secure Socket Extension

Если Вася Пупкин и Козя Красноглазик захотят написать по отдельности свои XML парчеры на какое API они
будут опираться ?

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



ага, умный анонимус, расскажи мне про офшор... %)) Точнее что пишеться на офшоре... Теже конуретные прикладухи..
Я в прошлом году сам много писал, но что то вот в разработке Java или Oracle мне не предлагали учавствовать..

Ну а мудак, пусть на твоей совести будет... Грамотный ты наш %))

>средства разработки а-ля IDE? Как они по функциональности?
Какие-то есть(искать на http://python.org/). Я не особо почитаю такие средства(мягко говоря).

>самая малая часть возможностей, OC,lmtvp|dlmwcTIL.OapL,pm
А насколько эти средства позволяют вам сократить обьем работы? У меня складывается впечатление, что это "one size fits all"-решение и соответствующие методы решения проблем, чаще свего отсутствующих в первоначальной задаче. "Брак это союз 2х людей, предназначеный для преодоления проблем, порожденных браком".
Проектируйте так, чтобы не пришлось сохранять (кешировать,материализовать,лочить) "Ява-обьекты" - и пропадет необходимость в использовании большей части всего этого.

>Это примитивизм.
Разумеется, я упрощаю. Так проще понять.

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

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

>Стандартное API есть
Есть(DOM,SAX).

>Маленький примерчик
Все таки посмотрите на HaXML. Я получил кучу удовольствия пытаясь понять как оно работает. Приблизительно эквивалентный кусок выглядит так(возможно неточно - я HaXML серьезно еще не ковырял):
> table $ map mkrow items
> where mkrow (id,value) = [td id,td value]

>javaMail,JSSE - Java Secure Socket Extension
Если я правильно понял первое == модулям email,smtplib,poplib,imaplib в стандартной поставке Python. Второе просто встроено в стандартный socket.

>на какое API они будут опираться
AFAIK этим занимается w3c.org. А во вторых - ваш проект не сильно пострадает, если вы воспользуетесь библиотекой с нестандартным API - до тех пор, пока есть доступ к ее исходникам.

Ребята, а кто - нибудь из вас знает что такое "together"? А аналог у него на QT есть? ;-). А написать вы чего - нибудь платное на QT сможете? Только заплатив денюжку? А на жабе?

> >Времени больше, при написании. Но, при сопровождении проще
> Вот это у меня вызывает недоумение. Как может быть сопровождение и
> особенно доработка(которая есть написание) эффективнее, если написание
> неудобно? Ведь это есть один и тот же процесс, эффективность которого
> на всех этапах определяется адекватностью средств разработки и
> архитектуры системы поставленой задаче.
Не верно. Не дольше в написании, а непривычнее - подход другой. А какая связь между скоростью разработи и эффективностью сопровождения??? ИМХО связь очень и очень хилая. MVC (model - view - controller) рулит однозначно и не только при построении WEB-приложений, он идеально подходит для _любых_ средств кде необходима визуализация (P.S. вожможно есть исключения, но я с ними не сталкивался).

MVC не изобретение Java, а наследие SmallTalk. Впрочем из SmallTalk вышли практически все ООП идеи тот же рефакторинг к примеру.

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

В случае модели MVC гибкость в том, что можно реализовывать практически сколько угодно сложный интерфейс (V) без изменения (M) и (C). По поводу struts можно найти на http://jakarta.apache.org, но я больше предпочитаю FreeMarker (http://www.freemarker.org) - на первый взгляд это напоминает легку систему шаблонов, но при использовании понимаешь, что это очень мощный инструмент аналогов которого в других языках (кроме .NET) нет, но есть вариации с другой функциональностью.


>>Стандартное API есть
>Есть(DOM,SAX).
Знаете, а в Ява эти стандарты и поддерживаются, но все отличие в том, что Ява определяет _интерфейс_ (паспорт) DOM, SAX. А разработчик только реализует своими алгоритмами этот паспорт. При таком подходе разработчик не может испортить паспорт, но может ввести новые функции. Благодаря этому все XML/XSLT парсеры взаимозаменяемы и между ними можно легко проводить обмен данными, а это действительно сильное преимущество. Реализаций XML много от 3Kb легких, до мегабайтных.

Если хочется быстрого и легкого пользования XML в Java посмотри на www.jdom.org к примеру (есть у них на сайте PDF с демонстрацией легкости ее применения).


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

К примеру есть аналог XDoclets (искать на sourceforge.org и freshmeat.net) в Pythoon?

>Не дольше в написании, а непривычнее
Статистика утверждает - скорость зависит от размера кода. А у Питона она сильно меньше чем у Явы. Говорят, что у Хаскеля - еще короче.

>связь между скоростью разработи и эффективностью сопровождения
Если не рассматривать неподконтрольные разработчику параметры то:
Скорость разработки определяется длинной кода. Последняя - качеством и адекватностью средств разработки.
Эффективность сопровождения - простотой понимания(П) и модификации(М) написаного кода. П - опять же качеством средств разработки. М - чуть сложнее, качеством средств и правильностью архитектурных решений. Последние зачастую включает выбор тех же средств разработки. Конечно, модель сильно упрощена - но все таки все очень сильно зависит от выбора языка, инструментов, библиотек, технологий.
А, как уже неоднократно отмечалось, Ява не имеет выдающихся характеристик - уступает C,C++,OCaml и даже Haskell в скорости, Питону в гибкости, Хаскелю в понятности и возможностям, ... Сравнивать можно долго и безрезультатно. Единственное, что у нее лучше - текущее состояние - большое количество готовых компонент, технологий и раскрученое имя. Это IMHO очень спорные преимущества.

>К примеру есть аналог XDoclets
Я пока не понял, что оно делает. Судя по всему генерирует что-то основываясь на коментариях в исходном коде. Если я пряв - то в питоне круче - там у _загруженых_(выполняющихся) обьектов есть документация(те же коментарии). И результат можно получать во время выполнения у клиента(а не у разработчика).

2DonkeyHot
>>Не дольше в написании, а непривычнее
>Статистика утверждает - скорость зависит от размера кода. А у Питона
>она сильно меньше чем у Явы. Говорят, что у Хаскеля - еще короче.
Статистику в студию! А если серьезно, то выдранная фраза из контекста уже имеет другой смысл. Разоговор шел не столько о:
- "Как может быть сопровождение и особенно доработка(которая есть написание) эффективнее, если написание неудобно?"
А это, согласитесь, разные вещи.

Скорость выполнения и написания вообще-то имеет очень малую зависимость от объема исходного кода. Надеюсь это не оспаривается? Ах да. Оспаривается именно _написание_, но, заметьте, 1) при использовании IDE время на _набор_ команд уходит меньше чем при полном кодировании. Даже если брать не навороченные IDE такие как Forte, NetBeans, IDEA и проч., а простые текстовые редакторы как JEdit, то разница в объеме кода не играет никакой роли.

А вот для _понимания_ кода и, соответственно, его сопровождения объем уже имеет роль, но! Когда он мал это так же плохо когда его много. За примерами далеко ходить не надо достаточно посмотреть на Perl.

>>К примеру есть аналог XDoclets
>Я пока не понял, что оно делает. Судя по всему генерирует что-то
>основываясь на коментариях в исходном коде. Если я пряв - то в питоне
>круче - там у _загруженых_(выполняющихся) обьектов есть
>документация(те же коментарии). И результат можно получать во время
>выполнения у клиента(а не у разработчика).

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


> А, как уже неоднократно отмечалось, Ява не имеет выдающихся
> характеристик - уступает C,C++,OCaml и даже Haskell в скорости,
> Питону в гибкости, Хаскелю в понятности и возможностям, ...
> Сравнивать можно долго и безрезультатно.
Кем отмечалось? Я видел много тестов где для WEB Java проирывала в скорости решениям на Perl, PHP, но проведенные мною тесты показывают обратное и чем сложнее код тем гибче, быстрее и удобнее код на Java чем на других языках (Pythoon в качестве WEB не знаю говорить не буду, .NET имеет ну очень малое отличие в данном контексте поэтому тоже не рассматриваю).

А какой язык имеет _выдающиеся_ характеристики перед другим чтобы можно было с чистой совестью "забить" на остальные? Нет такого и не будет и это благо.
А в качестве выдающейся характеристика Java перед C/C++ можно привести ее байт-код который исполнятеся без необходимости перекомпиляции на разных платформах. При сравнении с OCaml, Haskell это уже не является преимуществом, а нормой.

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

А почему затронув XDoclets обошли вниманием XML/XSLT? Если нечего добавить так и скажите, а то разговор получается односторонний как со стенкой.

> Perl, разумеется, куда лучше приспособлен к быстрому прототипированию

Кто спорит. Вот только к реальным большим проектам он не приспособлен.

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

Это как сказать. Язык образует культуру программирования. На том же C++ или Java нельзя совсем уж плохо писать нормальную долгоживущую мультитредную программу - будет часто падать :)

>Статистику в студию
В subj приводились названия по которым можно найти пару исследований. Вкратце: обьем кода на скриптовых языках в среднем в 2 раза меньше; время затраченое на разработку пропорционально обьему кода.

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

>А вот для _понимания_ и сопровождения объем уже имеет роль,
Процесс создания программы требует понимания, не так ли;-)

>Когда он мал это так же плохо когда его много...Perl.
Не правильно(если не рассматривать perl-golf). Чем больше текст тем более логика разбавлена синтаксическими конструкциями языка. Тем больше обьем данных, которые требуется обработать для понимания. Посмотрите http://www.dtek.chalmers.se/~sylvan/haskell/why_does_haskell_matter.html и попытайтесь _понять_ 2 алгоритма сортировки - на C++ и на Хаскеле(примерно 50% от начала - искать польшой синий блок с текстом). Что легче?

>Java добавляются к ней достаточно просто и понятно
Что простого и понятного в пустых(без функций) интерфейсах(Serializable).

>А какой язык имеет _выдающиеся_ характеристики перед другим
Многие языки имеют некоторые параметры намного лучше других. Кроме Явы:-). Erlang, Oz = паралельные способности, Python - простота и легкая обучаемость, С,С++,OCaml - скорость выполнения, можно продолжать. У явы что? Большой обьем библиотек? У Перла их, пожалуй, не меньше. Но пользовать его не стоит.

>без необходимости перекомпиляции
Это важно тем, кто пытается продавать софт без исходникови тестирования ? :-) Иначе не проблема пересобрать.

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

>почему обошли вниманием XML/XSLT
А что об этом можно сказать? В чем тут крутость Ява-технологии?
В наличии описания API?

>>to Korwin

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

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

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

IMO.

Плюс тренировка умения убеждать:-)

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


>>при использовании IDE время на _набор_ команд уходит меньше
>Проблема не во времени набора. Проблема в продумывании, увязывании
>кусков, отладке, понимании.
Фраза вырванна из контекста и потеряла свой первоначальный смысл._Продумывание_ - не зависит от языка (реализация зависит), "увязывании кусков" - это как?. Отладка и понимание во многом схожи и не имея четких представлений о языке и его конструкциях будет сложно проделать первое и второе. Если же необходимо понять чужой код, то для Java и SmalTalk это сделать проще - рефакторинг верный для этого инструмент. Для C++ и других ООП его, конечно, можно применять, но этот процесс для них не описан и изучен столь широго как для указанных языков, а к не ООП вообще слабо применим к сожалению.


>>Java добавляются к ней достаточно просто и понятно
>Что простого и понятного в пустых(без функций) нтерфейсах(Serializable).
???? Как можно не понимать выгоду и силу интерфесов (interface) и сериализации(serializable) я не понимаю. Чтобы это объяснить понадобится больше времени чем у меня есть на это желания.


>>без необходимости перекомпиляции
>Это важно тем, кто пытается продавать софт без исходникови
>тестирования ? :-) Иначе не проблема пересобрать.
Ух ты! А у вас, значит, всегда имеются все исходники всех исп. библиотек? И они все написаны так чтобы можно было легко переносить на разные платформы?


>>когда количество готовых решений
>Когда количество готовых решений будет достаточным чтобы не писать
>программ?
Надеюсь это шутка? Иначе эту фразу никак не понять.


>>А какой язык имеет _выдающиеся_ характеристики перед другим
>Многие языки имеют некоторые параметры намного лучше других. Кроме
>Явы:-).
Это заявление плюс про XML, интерфейсы, длину кода, байт-код создают впечатлене что у вас стойкое неприятие Java как таковой. Даже без намека на попытку вникнуть в эту технологию и понять ее суть и преимущества. Как уже подметил выше, что разговор больше похож на разговор со стенкой - становится скучно.

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


2ifconfig
>повторяешь мои ошибки.. Ввязываешься в бесполезные споры.. Все одно
>мало кто оценит, пока жизнь не заставит.
Уффф. Ты прав, а также знаешь почему я ввязался в этот спор. Похоже было, что в треде есть люди кому это будет интересным и понятным. Ан нет - ошибся.

Все. Завязываю. Наверное действительно лучший ответ на заявления что-то cool, а что-то sux это - RTFM.

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


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

А вобщем, собака лает, караван идет..
Люди склонны хаят то, что не понимают. Иногда даже честно в этом признаются, но дела это не меняет.

"php хороший потому что я написал hello world через 10 минут прочтения доки.. А Java уже плоха тем, что я ПЫТАЛСЯ прочесть Thinking in Java и ничего не понял... "

"Я не понимаю зачем нужны интерфейсы - поэтому я не считаю их наличе плюсом платформы.. "

"у оракла есть достойный конкурент MySQL"

такое оч часто можно здесь услыщать.

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



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

P.S. За postgreSQL я помню...

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

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

>Как можно не понимать выгоду и силу интерфесов
Внимательнее: я говорил не об идее интерфейсов а о "простоте" расширения явы. Конкретно: интерфейс serializable _не_ _содержит_ _ни_ _одного_ метода. Следовательно конструкция "implements Seria..." должна быть бессмысленной(по логике). Тем не менее он необходим. Следовательно при попытке расширения явы авторы столкнулись с _невозможностью_ в рамках логики языка реализовать необходимую функцию. И добавили костыль. Сколько их еще будет?

>стойкое неприятие Java
Ну, когда-то в 90х(1.1-1.2) я тоже считал ее лучшим решением. А теперь считаю средненьким, но очень популярным. Это непонятно - пытаюсь понять.

>без намека на попытку вникнуть
Этим я тут и занимаюсь. Я пытаюсь увидеть в ней какие-то преимущества. Точнее спросить о них у вас, знающих. И пока слышу только:
1. портабельность(мы все знаем, как это сделать - если написать POSIX библиотеку для "всего" - большинство юникс программ вдруг станут кросплатформенными)
2. готовые библиотеки для многого(их есть везде)
3. Стандарты на API( я хоть каждый месяц могу публиковать свои стандарты API:-)
4. "Технологии"-(1+2+3). Это самое загадочное. Что-то на уровне "способа думать", внедренного в сознание кучи программистов.

Последнее вызывает стойкую неприязнь. Откуда SUN знал, как мне нужно будет думать через 3 года?

>ответ на заявления что-то cool, а что-то sux это - RTFM
Пожалуй да. Но я был мягче - всего лишь "это не cool":-).
А FMов по этим технологиям - на пол года чтения. А в сокращенном виде есть только маркетинговые слоганы.

>>_Продумывание_ - не зависит от языка
>Зато зависит от предпочитаемой(наиболее знакомой) технологии.
И где здесь беда Java? Все это относится к любому языку.


>>"увязывании кусков" - это как?
>Если начинаешь использовать крупные готовые компоненты приходится
приспосабливаться к их идеологии...
Тоже самое. Где здесь беда Java? Такие проблемы будут при использовании любого языка, а в некоторых применение одних компонент тянут туеву кучу других которые напрямую не нужны в проекте - наглядным примером этого может служить Perl CPAN.


>>Как можно не понимать выгоду и силу интерфесов
>Внимательнее: я говорил не об идее интерфейсов а о "простоте"
>расширения явы. Конкретно: интерфейс serializable _не_ _содержит_
>_ни_ _одного_ метода. Следовательно конструкция "implements Seria..."
> должна быть бессмысленной(по логике). Тем не менее он необходим.
>Следовательно при попытке расширения явы авторы столкнулись с
>_невозможностью_ в рамках логики языка реализовать необходимую
>функцию. И добавили костыль. Сколько их еще будет?
Ну и? Как правильно подметил ifConfig:
"Я не понимаю зачем нужны интерфейсы - поэтому я не считаю их наличе плюсом платформы..".
Это уже не смешно. Интерфейсы это очень сильная вещь, т.к. она заставляет объекты соответствовать определенному паспорту.
И конструкция "implements Serializable" ни в коем случае не выглядит быссмысленной - это просто глупо. Эта конструкция объявляет для компилятора и для объектов, что данный объект _реализует_ паспорт сериализации, а вот каким образом он это делает уже зависит от реализации. Поэтому в интерфейсе и нет ни единой строчки кода. Можешь сериализовывать в байт-код, XML и любой другой необходимый тебе вариант в зависимости от ситуации.

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

Если это не понятно, то обратите пример на _interface_ Map. Это набор _описаний_ какие методы должен иметь объект _реализующий_ (implements) работу с данными в виде ключ-значение. В свою же очередь Map наследует _интерфейс_ collection который определяет особенности объектов работы с коллекциями объектов.

Имеются разные _реализации_ Map это: HashMap, WeakHashMap, SortedMap.TreeMap. Для чего они нужны надеюсь объеснять не надо?

Кроме того. Вы можете написать собственную реализацию коллекции. И если, вдруг, ваша реализация будет эффективнее, то мне в своем коде не придется менять _логику_ кода, вводить правку во всех местах где исп. Map объект. Я просто сменю объявление одного объекта на ваш. Все. Больше ничего делать не надо, т.к. _интерфейс_ вашего объекта соответствует интерфейсу Map.

Это уже расжевывание азбучных истин какое-то.


>>стойкое неприятие Java
>Ну, когда-то в 90х(1.1-1.2) я тоже считал ее лучшим решением. А
>теперь считаю средненьким, но очень популярным. Это непонятно -
>пытаюсь понять.
А вы не думали, что за десять лет многое могло измениться? Подумайте над этим.


>>без намека на попытку вникнуть
>Этим я тут и занимаюсь. Я пытаюсь увидеть в ней какие-то
>преимущества. Точнее спросить о них у вас, знающих. И пока слышу
>только:
>1. портабельность(мы все знаем, как это сделать - если написать POSIX
> библиотеку для "всего" - большинство юникс программ вдруг станут
>кросплатформенными)
POSIX далеко не означает портабельность. Есть еще воз и маленькая тележка из-за которой приходится постоянно пользоваться #ifdef
Тот же Linux далеко не во всем является POSIX-compilant. Это особенно видно когда переводится достаточно большой проект из комм. UNIX на Linux. Но не мне судить - для этого есть отличное средство www.google.com


>2. готовые библиотеки для многого(их есть везде)
Ну не скажи. Дело не только в количестве, но и в качестве, а также в гибкости использования. А за счет четкого API и унифицированных интерфейсов использование доп. библиотек в Java проще и легче чем в других. Нет сильной завязки на опр. вендора часто (если не сильно спец.) можно с мин. усилиями сменить библиотеку.

А как на счет готовых решений? К примеру Servelet контейнеры. Есть множество реализаций. От самых простых в 200Kb, до IBM WebSPhere.
Часто именно решения и предпочтительны чем отдельные кирпичики. Затем, исп. решение его легко наростить и даже поменять функциональность за счет средств ООП - это тоже неоспоримый плюс.

>3. Стандарты на API( я хоть каждый месяц могу публиковать свои
>стандарты API:-)
Пожалуйста - ваше право. Но одно дело ваши доморощенные API, а другое дело DOM, SAX и прочие которые прошли шлифовку на должном уровне.

Или посмотреть на это дело по другому. При написании WEB-проектов приходится делать объекты реализующий единицу информации - аналоги единичной записи в таблице БД, а очень часто это и есть такие записи. Нет проблем - реализуем собственный API.

Затем с ростом объектов и их количества замечаем, что исп. SQL запросы в каждом из них не удобно - далает враппер на SQL так, чтобы объекты даже не знали что они работают с БД. Отлично! Теперь мы можем в случ. необходимости хранить не в БД, а в XML, LDAP либо проецировать на файловую систему. Имеем еще один уровень собственного API.

Кроме самих объектов надо организовывать их взаимодействие между собой (FOREIGN), а также взаимодействие с бизнес логикой. Имеем еще один уровень API.

Эти данные должны быть использовании для отображения информации. Отлично значит каким-то образом им нужно средство отображения - имеем еще API.

Все замечательно, проект развивается. Народу ходит много и появились заказчики которые хотят заплатить деньги за наш разработанный движок. Просто замечательно! Но тут встают след. вопросы:
1. Как легко его наращивать.
2. Как быть с вопросами безопасности (не все данные всегда видны).
3. Как на счет масштабирования (load balancing).

Мы говорим - Все Окейно! И вводим измнения в сущ. API чтобы добавить возможность plugin, добавляем wrapper API на объекты чтобы они реализовывали вопросы контроля доступа и безопасности. И даже умудряемся все это переделать так, чтобы все объекты могли работать в распределенной системе (по опыту самая трудоемкая и долгая задача).

После много летней работы имеет супер систему с развитым API и умеющую делать потрясные вещи. Заметьте, господа, все это буквально выросло из маленького проекта. Слава рефакторингу! Нашему бессменному помошнику.

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

Давайте теперь расширим кругозор на то, что некоторые так упорно называют "Java платформой". И что видим? А то, что было потрачено много человеко-часов/дней/месяцев на то, что уже имеется и готово. Разговор не только о готовых "кирпичиках"-библиотеках которые можно было бы использовать вместо собственно написанных. Разговор идет на уровне API.

Ведь что имеется:
JMX - Java Manager(?) eXtentions - управление расширениями. Для простоты Plugin, он это не полностью раскрывает ее сущность.
JMS - Java Messaging System
EJB
J2EE
и многие другие страшные слова, на проверку оказывающиеся готовым колесом которое в том или ином виде при развитии проекта приходится "изобретать" заного. Так почему бы не потратить некоторое малое время для ознакомления с этими технологиями и в последствии их применять. Вот один из параметров определяющий Java как технологию.


>4. "Технологии"-(1+2+3). Это самое загадочное. Что-то на уровне
>"способа думать", внедренного в сознание кучи программистов.
Технология понятие многогранное и в объеме одного LOR сообщения его не опишешь, да и не так уж много у меня знаний и опыта чтобы попытаться описать. Но думаю, что часть все таки удалось раскрыть в этом ответе (см. выше).


>Последнее вызывает стойкую неприязнь. Откуда SUN знал, как мне нужно
>будет думать через 3 года?
Эта неприязнь появляется тогда когда не знаешь предмета. У меня, к примеру, ковыряние в карбюраторе вызывает стойкую неприязнь - ну не знаю я всех этих автомобильных штучек.
SUN не знает, но предполагает и, главное, реализует давая реально работать уже сейчас, не завтра и не в будущем. При изменении мышления, конюктуры, технологий и проч. происходит смена API, но! обрати внимание что в конструкциях языка имеется возможность объекты и методы казывать как deprecated - благодаря этому происходит плавная изменение API без сильных потрясений для клиентской базы, а также для программистов.


>>ответ на заявления что-то cool, а что-то sux это - RTFM
>Пожалуй да. Но я был мягче - всего лишь "это не cool":-).
Да? По вашему изложению я сказал бы не "всего лишь "это не cool", а именно sux. Это ваше?:
* Следовательно конструкция "implements Seria..." должна быть бессмысленной(по логике). Тем не менее он необходим. Следовательно при попытке расширения явы авторы столкнулись с _невозможностью_ в рамках логики языка реализовать необходимую функцию. И добавили костыль. Сколько их еще будет?
* Последнее вызывает стойкую неприязнь. Откуда SUN знал, как мне нужно будет думать через 3 года?
* >почему обошли вниманием XML/XSLT
А что об этом можно сказать? В чем тут крутость Ява-технологии?
В наличии описания API?
* Многие языки имеют некоторые параметры намного лучше других. Кроме Явы
* Ява не имеет выдающихся характеристик - уступает C,C++,OCaml и даже Haskell
* остально просто не перечислить %')

В общем надеюсь, что это сообщение даст повод для размышлений и вы не станете сразу же давать голословные утрверждения в вашу защиту, а выспитесь, подумаете, почитаете что-нибудь не про 1.1-1.2, а 1.4, сходите на official Java site, посмотрете на то как Java использует IBM и тогда напишете ответ.

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


А FMов по этим технологиям - на пол года чтения. А в сокращенном виде есть только маркетинговые слоганы.

А мне русский намного больше нравится чем английский. А на китайском письменность тысячилетий не потеряла былой смысл - лишь изменила произношения. По моему глупо спорить о машине Тьюринга. И Ява и Питон и QT отличные языки(платформы) для тех кто их знает. Именно на том что знаешь и надо писать. Выбор языка как инструмента - это выбор лидера команды берущего ответственность на себя. Параллельные языки тоже надо уважать. По-моему это признак здравого смысла. Сам я люблю Яву больше всего за то что я ее знаю. Кстати меня не выводят из себя хвалы другим языкам - мне не нравится когда ругают то что я люблю - из этого все споры Мне кажется что во всех языках плюсов и минусов поровну, они лишь смещены по разному. Лучше выбирать то что знаешь. ps. Serializeable - на самом деле выходит за пределы понятий java - этот интерфейс реально представляет из себя абстрактный класс и интерфейсом назван лишь чтоб скрыть множественное наследование. При отсутствии понятия атрибутов в языке сие скрыто довольно удачно.

> Ха-ха. Очень смешно. :)) Особенно про Lotus Domino :))
А конкретнее, чем смешно? Или у вас есть достойная альтернатива?

> Вот я про то и говорю, что нефигово было сравнить QT и JAVA в
> аспекте где QT не катит, ели уж он JAVA поставил в неудобную позу.
Почему же? Серверные приложения не сравнивали - сравнивали простоту разработки GUI. Потому вам и не надо приплетать сюда совершенно левые темы. Хотя про некорректность сравнения я согласен...

2 eXOR (*) (2003-03-22 19:57:29.036889)

>Ребята, а кто - нибудь из вас знает что такое "together"? А аналог у
>него на QT есть? ;-). А написать вы чего - нибудь платное на QT
>сможете? Только заплатив денюжку? А на жабе?

Ага :)) У меня на десктопе KDE (QT) а из него Together торчит :)))