Тормоза на LOR в баннере и в top100. на этих компонентах ЛОР большую часть времени и проводит. Проверил я это пару дней назад из разных мест в мире ( Лондон, Сан-Хосе, Бостон ).

Irsi, well i can't belive it's you :) I've never seen Cisco's web interface at routers and switches?

try "ip http server" :))) or so...

You'll get involved about java :)))

Should i metion Oracle?

Should i mention huge set of applets for administration some funny devices wich use java? Should I show you a lot of java-software (take a look at freshmeat at last :) ) well, wrtitten-by-geeks is not main factor but never the less, in opposite there is NOTHING at C#.

:)

Trust me, during last month i've seen more java than since it was born. There are LOT of java software. A LOT of companies use java and "Write once, run everywhere" is a little bit more, than just a slogan.

Майкрософт никогда и неддерживала Java (для тех программистов, кто этого не знал и кто всю жизнь на перле пописывал). У M$ даже нет лицинзии на то убожесто, которое они когда-то выпустили... Так что всё нормально с этой точки зрения.

Все верно:) и писать на ней удобно. Одна проблема - иди установи
JRE 1.3.1 на SunOS 5.6 :((( Одних патчей на 60 мегов наберется, да 
и там не факт что заработает.

Ради справедливости надо отметить что на SunOS 5.8 ставится с лета и работает сразу:)

P.S. да, я в курсе что разница между 5.6 и 5.8 это как между вндовс 
95 и ХП, с разницей в том что 5.8 уже есть и работает:))

P.P.S. мне не удается писать на яве, все на Ц/Ц++, но иногда мне 
не хватает явовских интерфейсов и динамической подгрузки....

P.P.P.S. А чего бы действительно Майкрософту поддерживать Яву, если:
  о Для клиентов есть плагины
  о Для серверов есть application servers
  о Для stand-alone есть stand-alone-овские virtual machines
  o Для Linux будет гцц с нативной явой
  Т.е. с продажи _своей_ виртуальной машины Майкрософту ни 
   холодно, ни жарко.

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

>>a TCL/TK?

>Увы, он слишком далек по числу сервисов

Это не так. Все необходимое в Сети есть, надо только знать где брать. Кроме того Tcl/Tk непревзойден в смысле легкости встраивания кода на С. Ни XS, ни Python-овские интерфейсы даже рядом не стояли.Про Java Native Methods врать не буду, ибо никогда не пробовал их писать.

А типичный RSS Tcl/Tk программы, соизмеримой по сложности с Oracle Installer - 5-10Мб против 128.

А еще мне приходилось сталкиваться с такими платформами, например BSDI 3.1, где Java не было как класса, а Tcl/Tk собирался с легкостью. И лицензия у него BSD.

Недаром та же Oracle его в дистрибутив включает начиная с версии 7,3, когда Java еще не пахло.

Просто никто не замечает, что внутри Oracle Intelegent Agent Tcl есть - не глючит, не тормозит, какая разница что там внутри.

Полностью согласен с коструктивными людьми такими как Mr. Bool и др.

Нечего дрыгать ногами и орать типа "На х.. Джаву" идите сами нафиг Ничего сами не сделали а туда же. Апплеты - это не вся Java а в 2001 и далее доминантой будет серверное ПО (Servlets, JSP и иже с ними) Видимо эти психопаты и не знают о разнице в скорости разработки и внедрения ПО в разы. Иными словами ПО к примеру (на Delfi или C++)making time x 4 = Java making time. Так что динозавры отдыхайте.

Я не есть, ни стороник явы ни стороник MS.

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

Далее как мне кажется все языки(ну или почти все) делятся на языки высокого уровня для сборки (склейки компонентов)(Perl,Python,Tcl/Tk, VB т.д. и тому подобное) и языки более низкого уровня ( для написания компонентов)(С,С++,JAVA и т.д.) и получения максимального быстродействия.

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

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

Пример: Инсталятор ORACLE написанный на JAVA, и требующий для себя ресурсов иногда больше и проблем с JAVA, чем требуется самому серверу. Складывается впечатление что это просто дань моде. У того же Oracle если походить по каталогам можно обнаружить куски кода на TCL. Вопрос какого черта им надо было писать это на JAVA, когда кросcплатформенный инсталятор намного проще написать на TCL/TK? Я уже молчу о совместимости версий JVM. Что бы запустить инсталятор надо мало того что определенную версию JVM, но еще и от того парня который IBM.

Теперь про технологию JSP. Много ли вам удалось с нее получить? А нет ди ей замены? Да сколько угодно, ведь технология динамических страниц насколько мне известно не новость сегодня. Например: ASP ( Детище MS) PHP PSP ( Это может быть как PERL SP, либо как Python SP) PL/SQL SP ( не помню как точно называется) -детище Оracle ADP - (AOLserver Dynamic Pages ) Думаю желающие могут продолжить этот список.

Про апплеты: наверно ява не единственная технология для написания апплетов,так мне приходилось видеть апплеты на TCL вполне прилично работающие.

Наверно самым интрестным в Ява есть технология сервлетов но и она как бы не есть новостью для индустрии IT.

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

Вообщем мораль сей басни такова. "Новое" - это хорошо забытое "старое".

Что касается отношений SUN и MS: "Дружба, дружбой, а табачек в розь" "Ну разве могут акулы империализма жить в мире"? ( Шутка).

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

Странник

2 Странник
"Вопрос какого черта им надо было писать это на JAVA, когда кросcплатформенный инсталятор намного проще написать на TCL/TK?"

А вот это к вопросу единства технологии. Коли Oracle включил Яву в сферу своих стратегических интересов, так почему же инсталлятор на нем не написать? Кстати, так не только Oracle поступил. У Sybase монитор промышленного сервера давно на Яве. И всякие management console тоже. И хлопот с переносимостью немного. Деньги, это же прямая экономия на разработке. Кстати, наверное не стоит относить Яву к средствам разработки компонент СИСТЕМНОГО уровня. Она хоть и компилятор(именно так, граждане, тут кто-то недопонял, что такое компилятор, а что такое интерпретатор. Отличия отнюдь не в том, что получается на выходе - исполняемый код ОС или исполняемый код виртуальной машины), но поддержку SSL, например, надо все же писать на натурально компилируемом языке. Удел Явы - прикладнуха, там быстродействие не во главе угла.

Полуденный Бес

Народ, чего вы так переживаете. Нам бабки и не маленькие под Java-проекты дают. Будут под C# давать, мы на C# перейдем. Это же специфика нашей предметной области, где знания на 90% обновляются каждые 5 лет.

Насчет тормозов в Java.

Я как-то делал исследование, так вот, на Java легко можно получить разницу в 10 раз по выполнению.

Что это значит? Аккуратно надо писать. Когда все правильно сделано, то тормозить не должно.

Короче, все зависит от рук программеров. Ну и от опыта, конечно.

JAVA - это чисто мода, так-же как и LINUX. Мода тем и хороша что она проходит...

Java is not fashion....well, it is in a way, but a bit too much money was invested in the technology just to let it go so soon...
Just look at EJB - now this is where the money is, this is where the fashion is.

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

Это у тебя что, религия такая? Ну в церковь сходи, свечку поставь. Только вот какое это отношение к IT имеет? За каким хреном быстро работать программе, запускаемой раз в час, и результат от коей требуется не раньше чем через десяток минут? Тут глубоко накакать, будет она десять секунд работать, или таки десять минут. При этом гораздо важнее, будешь ли ты её год писать на C++, месяц на Жабе или пару дней на Схеме.

Во всём остальном - согласен. Про замену убогой технологии JSP - советую посмотреть в сторону сюда: http://brl.sourceforge.net/

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

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

>При этом гораздо важнее, будешь ли ты её год писать на C++, месяц на >Жабе или пару дней на Схеме.

Вот, вот , сэр Антихрист, вы сами подписали себе приговор.
Учитывая что разница между C++ и Java в 12 раз неправдоподобна,
там от силы 3-5, а разница между Java и Scheme (Python, Tcl/Tk, Perl)
в 15 раз - более чем правдоподобна, на чем надо писать вещи, быстродействие которых не критично?

А вот требования к памяти для задачи которая болтается
на процессоре 12% времени (раз в час по 10 минут) - более чем
критичны. И если мой Tcl скрипт будет в этом месте кушать 5мб
из 512, а ваша Java-программа - 128 (пусть она при этом выполняется
за 5 минут, а не за 10) то каждый час для решения других задач
освободится 128*5 - 10*50 - 140 мегабайто-минут. или
почти 0.4% общей (512*60) производительности машины.
Боюсь,
что лишними они уж всяко не будут. Туда понимаете ли пяток копий
мод_перлового бэкэнда влезут, которые, заметим будут в течении
этих десяти минут юзеров контентом кормить.

Дорогие мои, вы про какие-такие программы на Яве говорите, что они у вас по 128 мегов едят? Для примера Java Embedded Server на 50 - 100 коннектов отъедает до 20 мегов. Вы о чем? Опупели, что ли? У меня сейчас упомянутый мной Forte крутится - от 60 до 80 мегов, да, заметно. Так это други, среда разработки, написанная на той же Яве, case средство! У него функциональности больше чем у IDE Visual Studio. Ему Богом положено жрать память. Аська поганая - и та 4 мега, outlook - 11. Баек надо меньше слушать, а если приспичило - самим проверять.

Полуденный Бес

Привет всем!

...и ещё раз по-поводу тормознутости Java. Вы "Java программисты", к примеру, пробовали почитать книuгу "Java peformance tuning". Очень просветляет ...

Например, синхронизированность класса Vector притормаживает java-код раза в 3, как впрочем и прочая другая синронизация вместо этого полезнее испольозовать аналогичныйй класс ArrayList, та же самая петрушка и Hashtable - аналог его HashMap. Попробуйте, если вы конечно не погрязли multithread программировании. Хотя в этом случае лучше ипользовать аналог семафоров для синхронизации потоков, а не юзать всякие там вектора.

А как вы часто юзаете new? Часто - ну и продолжайте тормозить дальше. А о reusable объектах слыхали? И о том, что полезнее для производительности коде необходимо использовать спулы reusable объектов? Попробуйте и возоможно вам удасться ускорить прогу ещё раз эдак в 5...

По поводу объектов содержащих native вызовы тоже есть пара замечаний. Их вообще не рекомендуется часто создавать... А весь AWT практически на native коде и базируется. Так что рекомендации по использованию спулов здесь как никогда актуальны.

Можно продолжать ещё, но время жаль. Это же не jGuru в конце-то концов...

Ладно - я пошёл зарабатывать деньги на "тормозной жабе".

P.S. Эта мессага не призвана никого оскорбить, просто уже достали крики "тормозит"... Нет бы разобраться почему, почитать что думают по этому поводу умные люди. Обосрать всегда легче. И ещё раз настоятельно рекомендую почитать такие книжки, если вы ещё этого не сделали. Иначе как же вы сможете говорить что вы знаете Java, ели не можете нормально отпрофилировать свой код.

TCL 8.0(bolee pozdnie uzhe ne pol'zowal) byl tormoznym ugrobischem, ne objazatel'no ego tut woshwaljat'. Da i urodskij on mestami, poprobujte radi interesa na Expect(tot zhe tcl)/Tk napisat' programmu, kotoraja odnowremenno pol'zuet 2 drugih programmy. Huh, skol'ko ja nalowilsja wsjakogo integersnogo pytajas' odnowremenno pol'zowat' ftp & sqlplus... 2Vitus: ljubow' zla... Perl/Tk rulez ;-)

> что отказ от явы в Windows Xp рикошетом ударит

И правильно сделали, что нестали включать. Зачем портить репутацию Sun?
Непожалел пары часов - отрубил несколько гиг от винта и поставил туда XP
(build2504), поужасался и снес.

Машина P3-900/458/ATA100
Инсталируется ~ час. Весит полтора гигобайта (sic!).
При инсталянии задал всего два вопроса - настройка сетевушки и в какой
стране я живу. То есть выбора компонентов при инсталяции нет!
Через "add/remove..." возможно удалить только игрушки и
всякие калькуляторы/паинты. То есть от того-же Outlook не избавишся (Его каталог он недает удалить даже под администратором).
Так-же, например, неполучилось оторвать "Мои документы", "Моя музыка", "Мои картинки".

ГУИ сам по себе, имахо, не сколько красивый, сколько аляпистый.
Чем-то напоминает KDE1 с темой "для слепых".

По сравнению с 98-м ворочается довольно тяжело.
Переодически грохочет винтом, что-то грузит...
Навигация тоже изменена и, имхо далеко не в лучшую сторону.
Содержимое диска с XP, и подкаталога windows напоминает помойку. Какие-то забытые временные каталоги в корне с кусками реестра. Организация чем-то напоминает CorelLinux (т.е. бардак.)

Минимальный размер свопа, по умолчанию, 750мегабайт.

Выводы: Будет ещё одно мёртворожденное дитя от MS и второй неуловимый Джо (WinME).

2Ogr Суд все-таки был насколько я помню не по поводу jvm, а только по поводу термина "java-compatible"

Да, WinXP это чудо....

... в перьях. Я поражён был просто.

К сведению тех, кто часто говорит о тормознутости java: этот сайт использует Java и работает, по-моему, вполне стабильно и быстро. Так что не стоит говорить о том, чего не знаете :)

> а кто этим реально пользуется?

I am. Don't you know for what? to create nice pictures from ClusterManager because HP OV still doen't know difference between stand alone and clustered switches but my boss want this visualy.

Well, also one of our admins uses this interface instead of SSH to terminal server and connection directly to console port. But we gonna disallow him to do this for security reasons. :)

> два десяка мегобайт дело максимум на две-три минуты...:)

About 15 seconds :)

"Вот, вот , сэр Антихрист, вы сами подписали себе приговор. Учитывая что разница между C++ и Java в 12 раз неправдоподобна, там от силы 3-5, а разница между Java и Scheme (Python, Tcl/Tk, Perl) в 15 раз - более чем правдоподобна, на чем надо писать вещи, быстродействие которых не критично?"

Ну, с этими цифрами я согласен. Я же всего лишь пример приводил. Естественно, на Java писать эффективнее, чем на C++, но это не повод её использовать - на Схеме/Tcl/ML/Python всё ещё проще. Единственная проблема - на Жабу очень легко переходить полуграмотным сиплюсплюсникам, которые ничего другого не знают и знать не желают.

Я жабу терпеть не могу, но вынужден пользовать - начальство приказало. Правда, выход нашелся - я их убедил, что им не жаба нужна, а только JVM, и юзаю теперь Kawa. Вроде бы жить можно. И портабельность, и JDBC, и сервлеты и Схема - в одном флаконе.

To ораклисту-хренову:
А инсталлер Oracle... 1000Mhz-вый Athlon тормозит при инсталляции так, что мышка останавливается! 512Мб памяти при этом юзая!

Сам лично ставил на AMD 266Mhz, 64 Mb памяти Oracle 8.1.7 для Linux, swap правда был добавлен, 200 или 400 Mb, не помню.

Oracle

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

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

Уши вянут от дебильного трепа... Найдите что-то еще для распределенных вычислений и многослойных систем, кроме java (J2EE,CORBA). Конечно, есть стандарт мапирования CORBA на C++. Довелось тут нам писать управление ISDN-потоками DIALOGIC DM/V1200-4E1. DIALOGIC, уроды, до сих пор не сваяли драйвера под Linux, пришлось пользовать MS VisualC++ под W2000 - это что-то! Глюк на глюке - утечки памяти, handle, а уж родное API многопоточности!... CORBA - только упомянута, конечно, присутствует ихний ублюдочный COM. Естественное решение - JNI, модуль управления трафиком прекрасно взаимодействует с серверами приложений (J2EE, естественно), а какие базы - Oracle, PostgreSQL или MS - не очень то и волнует. Кучу времени убили на войну с Win API, а серверные компоненты на Tcl/Tk писать что ли? А J2SE-J2EE - промышленный стандарт.

2anonymous (*) (2001-07-24 02:43:07.0): "Уши вянут от дебильного трепа"
Это Вы про себя? API многопоточности в Виндовс довольно хорош, или Вам не приходилось pthread_* исрользовать, все форки и форки, пионеры.

anonymous (*) (2001-07-23 11:46:10.0) > (на Delfi или C++)making time x 4 = Java making time

Легко видеть: (на Delfi или C++)making time = Java making time : 4,

т.е. в 4 раза меньше... Так что, динозавры хоть математику знают в отличие от пионеров :)

Ты это скажи тем тысячам программеров, которые пишут под явой. А то что это гнилая технология полный %;*(;#! Да, у неё есть проблемы с памятью, но только там где нет компов нормальных, а знаешь ли ты, что эту "гнилую" технологию используют в штатах и Европе в интранетах почти везде, где есть сильный сервак и нормальные клиентские компы. Апплеты - это неудача Явы, но идея - классная.

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

Уважаемые Динозавры! Я, наверно, математику не знаю, но Org вряд ли
писал для возлюбленной Win что-то достаточно сложное и много-многопоточное
для режима 7x24 c серьезным железом. Читая умные книжки по Win,
написанные умными людьми, постоянно натыкаешься на "данный системный
вызов не работает", "работает не так", "не освобождает ресурсы",
приводит при таких-то обстоятельствах к любимому "программа выполнила
недопустимую"... - так оно и есть! Но я упомянул VisualC++ не для
оценки Win, это дерьмо уже до дыр (бесчисленных) заоценивали, думаю,
более компетентные люди. Речь шла о применении C++ и Java в разработке
крупных распределенных систем в гетерогенных сетях. Другие языки тут
и близко не лежали. К примеру, в новой серии Ericsson-овских коммутаторов
базовых станций открытая платформа - "JAMBALA". Это ОСРВ TelORB (ORB!),
SPARC Solaris, а весь средний слой - Java + CORBA.

P.S.: На счет математики не очень понятно - при чем тут какое-то making time.

P.P.S.: Динозавры вымерли.

Пионэр.

Примеры неработающих вызовов?

vsl ты же вроде недавно гпл опускал.А сам вот пользуещься и хвалишь такие вещи как кава и т.д. в чем дело?Может и огр потихоньку на гсс компиляет а вокруг только пальцы кидает по поводу вижулстудио?:)

2 Странник для Полуденному Бесу

>>"Вопрос какого черта им надо было писать это на JAVA, когда >>кросcплатформенный инсталятор намного проще написать на TCL/TK?"

>А вот это к вопросу единства технологии. Коли Oracle включил Яву в >сферу своих стратегических интересов, так почему же инсталлятор на >нем не написать? Кстати, так не только Oracle поступил. У Sybase >монитор промышленного сервера давно на Яве. И всякие management >console тоже. И хлопот с переносимостью немного. Деньги, это же >прямая экономия на разработке. Но ведь уже у них были наработки на TCL/TK. По-поводу средств мониторинга отвечу опять же примером. Oracle Enterprise Manager версии 2.0 написан на Яве, а здорово ли он переносится между платформами. Например хотябы на Linux. В доке сказано что работает только на WinNT да Solaris Sparc (даже не Intel x86). Так о какой экономии идет речь?

> Кстати, наверное не стоит относить Яву к средствам разработки >компонент СИСТЕМНОГО уровня. Она хоть и компилятор(именно так, >граждане, тут кто-то недопонял, что такое компилятор, а что такое >интерпретатор. Отличия отнюдь не в том, что получается на выходе - >исполняемый код ОС или исполняемый код виртуальной машины), но >поддержку SSL, например, надо все же писать на натурально >компилируемом языке. Удел Явы - прикладнуха, там быстродействие не >во главе угла. Ну если так то почему на использовать тот же TCL/TK, Perl, Python ведь у них с переносимостью а тем более со скоростью написания гораздо лучше чем в Яве.

Ну что вы заелись с этим C#. Смотрите шире - дот.нет + любой встроенный язык. Возможно та же ява. Но общем смысле яве все же нужен конкурент ибо это токо подстегнет ее развитие. Сегодня рано говорить о дот нете как о конкуренте. Можно ли сказать что свои задачи ява решает ? К сожалению только частично ... Вот это и есть ее ахилесова пята которую и будет давить МС.

Я говорил про очевидную и неизбежную зловредность GPL для современного капиталистического мира и современной модели финансирования разработок. Ну так что из этого? Я что, на буржуина-капиталиста похож? Задавим GPL-ом капитал!

2 Antichrist (*) (2001-07-24 15:04:25.0)
{
Я говорил про очевидную и неизбежную зловредность GPL для современного капиталистического мира и современной модели финансирования разработок...
}
Ты не задумывался, что эти идеи (GPL etc) рождаются именно в капиталистическом
окружении. Можно в красках представить, что было бы с разработчиками
свободного софта, пускай даже, при Леониде. Особенно с разработчиками
сильных шифровальных алгоритмов. Соц-идеи в капитализме -- обратная
отрицателная связь, компенсатор, что бы некоторые не зарывались и не
теряли бдительности.
Так что ударить не удасться, максимум -- поставить на место.
Что не мешает использовать любимые эффективные средства разработки
в коммерческих проектах.

M$ загибается...

2 Странник

Дело в том, что TCL, Perl и т.д. - плоды труда ЭНТУЗИАСТОВ, которые вольны рулить куда им захочется, а то и вовсе бросить развитие и сопровождение этих продуктов просто потому, что им так захотелось или в силу личных причин(картоху выкапывать надо, кой там Perl, вы что?). С Явой такого произойти не может. Устойчивость производителя.

Насчет Enterprise manager'a и инсталлятора. Насчет менеджера не знаю, сам только под Windows пользовался, но если приложение написано на Яве без фокусов, то оно должно безболезненно переноситься всюду, где есть jre с соответствующей поддержкой графики и JDBC драйвера. У меня приложения спокойно качуют из домашнего Solaris'a 8 x86 в Windows 2000 на работе без перекомпиляции. Инсталлятор же работает под многими платформами(с чем я дело имел: Windows, Linux - RH, SuSE, Solaris). Кстати, net8 уилиты я под x86 Solaris'oм запускал и они нормально работали.
Насчет экономии. Ява живет в SQL сервере и на это затрачена бездна труда и денег, масса Явы есть для Appplication сервера. Всякие Wallet'ы написаны, Net8 - программы настройки. Для этого был нанят штат Ява-программистов. И немалый, я думаю. При кроссплатформенности Явы зачем что-то писать на TCL, имея широко распространенное средство, производимое SUN (а это имя и авторитет)? Я думаю, что разработки на TCL свернули или, по крайней мере заморозили, уволив программеров. Это только логично. (Честно говоря, я не понимаю, когда большая коммерческая фирма начинает включать в свои продукты компоненты написанные энтузиастами, пусть и дьявольски талантливыми)

Относительно пузометрии между Явой и Perl'ом( про Python ничего сказать не могу - "не ел"). Да, в некоторых случаях эти языки существенно быстрее. Но, ты представляешь себе перловый проект с объемом кода мегов этак в 5-10? Это же несопровождаемя штука! Perl - нечитаемый язык! Уж по сравнению с Явой - точно. А в большом проекте(я говорю только про них, микропиписечные проекты можно писать на Perl, VB, суахили, хинди или урду - все равно) читаемость кода - штука донельзя важная. Кроме того, я тут слышал фразу "для TCL все в сети есть, надо знать, где искать". М-м-м... Ты представляешь, приходишь ты к Главному Ораклу и говоришь: "А знаешь, брат Оракл, я тут на www.crack.ru такой софт нашел!". Как думаешь, что Главный Оракл ответит на подобное предложение?

И еще. Видимо надо признать, что упомянутые тобой средства НЕПЕРЕНОСИМЫ поскольку изо всех сил ориентированны на Unix и X - сервера, в качестве GUI. Отсутствует КОММЕРЧЕСКАЯ поддержка их в Windows (Active Perl как-то в расчет брать не хочется). В меня сейчас будут плевать, но я скажу, что нет на десктопе(рабочей станции) другой операционной системы кроме Windows.

Полуденный Бес

Да... бабок вложено не мало...
Блин, все деньги на эту яву потратили... и вот получили кризис...
Лучше бы С++ улучшили (портабельность, новые фичи,новые библиотеки классов)

yesal

> В меня сейчас будут плевать, но я скажу, что нет на десктопе(рабочей станции) другой операционной системы
Плевать не будем, а ОС есть. Иначе на чем бы я сейчас это писал ;)

2 anonymous (*) (2001-07-24 17:37:16.0)

Есть? Покажи! Но что бы процент десктопов(!) с этой ОС можно было бы разглядеть без микроскопа.

Полуденный Бес

2 Странник для Полуденному Бесу

>Дело в том, что TCL, Perl и т.д. - плоды труда ЭНТУЗИАСТОВ, которые >вольны рулить куда им захочется, а то и вовсе бросить развитие и >сопровождение этих продуктов просто потому, что им так захотелось >или в силу личных причин(картоху выкапывать надо, кой там Perl, вы >что?). С Явой такого произойти не может. Устойчивость производителя.

>>> Никогда не говори никогда. Ну так уж и не может. Пойдет ко дну, аж гай шуметь будет. Именно потому, что подерживается одной фирмой производителем. А не сообществом разработчиков. <<<

Насчет Enterprise manager'a и инсталлятора. Насчет менеджера не знаю, сам только под Windows пользовался, но если приложение написано на Яве без фокусов, то оно должно безболезненно переноситься всюду, где есть jre с соответствующей поддержкой графики и JDBC драйвера. У меня приложения спокойно качуют из домашнего Solaris'a 8 x86 в Windows 2000 на работе без перекомпиляции. Инсталлятор же работает под многими платформами(с чем я дело имел: Windows, Linux - RH, SuSE, Solaris). Кстати, net8 уилиты я под x86 Solaris'oм запускал и они нормально работали.

>>> Нет, я знаю конечно что можно писать переносимые приложения без перекомпиляции, но я привел пример когда производитель ПО не смог решить эту задачу. <<< Насчет экономии. Ява живет в SQL сервере и на это затрачена бездна труда и денег, масса Явы есть для Appplication сервера. Всякие Wallet'ы написаны, Net8 - программы настройки. Для этого был нанят штат Ява-программистов.

>>> Ну на этот вопрос я отвечу очень просто. "Проблемы индейцев шерифа не волнуют" ( шутка) Ява - это просто товар который надо было раскрутить и продать по возможности за большие деньги. Это политика и я ее предпочитаю не касаться. Таже SUN тихонечко купила продукт NEXTStep который мог бы составить ей конкуренцию и где сейчас этот продукт???? На самом деле совершенно не важно что это за продукт - можно раскрутить что угодно и насколько угодно. Главное чтобы это можно было продать.... Самые продаваемые решения не те которые с технической точки зрения самые современные и совершенные,а те что удалось раскрутить. <<<

И немалый, я думаю. При кроссплатформенности Явы зачем что-то писать на TCL, имея широко распространенное средство, производимое SUN (а это имя и авторитет)? Я думаю, что разработки на TCL свернули или, по крайней мере заморозили, уволив программеров.

>>> Я думаю это сделали чтобы он не мешал JAVA. <<< Это только логично. (Честно говоря, я не понимаю, когда большая коммерческая фирма начинает включать в свои продукты компоненты написанные энтузиастами, пусть и дьявольски талантливыми) >> Таже компания Oracle поcтроила свой продукт свой IAS ( Internet Application Server ) на основе Apache. Тоже самое сделала IBM с Apache.

Относительно пузометрии между Явой и Perl'ом( про Python ничего сказать не могу - "не ел"). Да, в некоторых случаях эти языки существенно быстрее. Но, ты представляешь себе перловый проект с объемом кода мегов этак в 5-10? Это же несопровождаемя штука! Perl - нечитаемый язык! >>> Согласен насчет Перла. Достаточно сложно почитать програмку написанную другим, вот почему я сейчас побую перебраться на Питон он намного читабельнее и понятнее. <<<

Кроме того, я тут слышал фразу "для TCL все в сети есть, надо знать, где искать". М-м-м... Ты представляешь, приходишь ты к Главному Ораклу и говоришь: "А знаешь, брат Оракл, я тут на www.crack.ru такой софт нашел!". Как думаешь, что Главный Оракл ответит на подобное предложение? >>> А ты предлагаешь изобретать велосипед с нуля? Если не дурак то выслушает в первую очередь. <<<

И еще. Видимо надо признать, что упомянутые тобой средства НЕПЕРЕНОСИМЫ поскольку изо всех сил ориентированны на Unix и X - сервера, в качестве GUI. >>> А что GUI TK под Windows не работает? Как Перл так и Питон подерживают работу с ТК <<< Отсутствует КОММЕРЧЕСКАЯ поддержка их в Windows (Active Perl как-то в расчет брать не хочется). В меня сейчас будут плевать, но я скажу, что нет на десктопе(рабочей станции) другой операционной системы кроме Windows. >>> Все в мире меняется все течет. Раньше никто Linux в серьез не ставил как ОС а теперь использование Комерческих Unix-ов становится все меньше и уже по мере подьема Linux Думаю дойдет и до рабочих станций... Развитие настольный ОС напоминает Вторую Мировую Войну. Все думали что пронесет и ничего не делали для того чтобы бороться с монополией (Гитлера )( MS). Теперь конечно с альтернативой трудновато, но похоже все идет к лучшему. >>>

Простите, не флейма ради, а эрудиции для.
В чем прелесть серверных приложений на Java(в смысле зачем Java на сервере)?

С надеждой на конструктивный ответ, ant.

2 Странник
"Пойдет ко дну, аж гай шуметь будет. Именно потому, что подерживается одной фирмой производителем. А не сообществом разработчиков" - "послушайте, Сикорски...", там сообщества разработчиков столько, что этих разработчиков из окна в собак кидать можно . А кроме того, у меня такое ощущение, что Ява помрет только вместе с Sun, а такая корпорация имеет чудовищную энерцию. Возможно, больше чем MS.

"Нет, я знаю конечно что можно писать переносимые приложения без перекомпиляции, но я привел пример когда производитель ПО не смог решить эту задачу" - скорее не захотел, я думаю. Очевидно десктопная утилита, нечего ей делать на сервере, по моему разумению.А десктоп - это Win'ды. А SPARK - это же свовсем другой разряд железа.

Apache - дествительно феномен, согласен, мысленно ему аплодирую. В OAS 9 используется именно он. Вышел из разряда "любительских" приложений. Но сколько лет он шел до признания!

"А ты предлагаешь изобретать велосипед с нуля? Если не дурак то выслушает в первую очередь." - конечно выслушает, обязательно. А потом скажет примерно следующее(я бы, по крайней мере, так сказал):
"Амиго! Хорошо, мы включим в технологию твой(обрати внимание - "твой", т.е. в случае неприятностей отвечать амиге) замечательный продукт и завтра же начнем тестирование. Кто там его делает? "Данила - Wizard"? Ах "World Wide eBook'и"! Чудно! Что будем делать, когда "WW eBook'и" окажутся совсем W eBook'ах? Не окажутся? М-да? А где сейчас Watcom? Развивать и патчить сами будем? Как "не придется"? Такого не бывает. А с RedHat что пришлось сделать? Зуб даешь? Зеер гуд! Верю ((c) Рабинович-Данченко). До утра думай и если не передумаешь - начинай." И утром амига придет извиняться. Гад буду. И только если амига придет с чем-нибудь вроде Апача разговор будет иной. А много ты знаешь подобных продуктов?

И насчет перемен. Естественный отбор должен быть, иначе жить нам под уродами вроде Windows. Вот только отбор ведется по дикому количеству критериев, всех не обозреть. И выживает не тот, кто казалось бы лучше, по моему(твоему, ихиму) мнению, а лучший с точки зрения этого отбора, а она проходит по ведомству "путей Господних".

Watcom! Watco-o-o-om!!! Блин, и куда подевался?..

Полуденный Бес

2 anonymous (*) (2001-07-24 09:25:05.0)

>На счет математики не очень понятно - при чем тут какое-то making time.

Как это причем? Человек сказал, что на яве в 4 раза быстрее программы разрабатываются, однако в формулу написал так, что получилось все наоборот :)

>Динозавры вымерли

Все возвращается на круги своя :)

P.S. Я кстати против явы ничего не имею. Только мне кажется, что есть языки, которые значительно больше подходят под определение простых. По крайней мере для определенных задач. Перл - понятно для чего... Или к примеру, Пролог. Решите задачки очень легко решаемые с его помощью на с ,с++ или яве. Тогда поймете, что между ними никакой разницы нет, т.е. будет так же сложно и долго.

2 Havoc (*) (2001-07-24 10:28:48.0) > Примеры неработающих вызовов?

Запустите под Микрософт Bиндоус98 (TM) Микрософт ФоксПро фор Виндоус 3.1/3.11... И не задавайте глупых вопросов.

2Пионэр: "но Org вряд ли писал для возлюбленной Win что-то достаточно сложное и много-многопоточное для режима 7x24 c серьезным железом" Турдно сказать, что есть серьезное железо, но вот программки мои многопоточные работают как в министерстве финансов одной из земель Германии так и в таких компаниях как Shell и Боинг. И что пермечательно без утечек ресурсов...

ТО Полуденный бес.
Если Java так переносима, то почему JDBC драйвера для Oracle появляются не сразу для всех платформ... ?
Из новостей - вышел JDBC под Solaris!
через месяц - вышел JDBC под Linux,
еще через некоторое время - появились JDBC под Windows.

Кстати JDBC для Java 1.2 под Linux для Oracle 8.1.7 так и нету...
а для Java 1.1 глючные до невозможности.

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