Защо Java

Малко в страни от темата, но ако Oracle няма пари за кадърни програмисти,
кой ли има.
Клиентска част на Оракъл написана на Java е написана като от аборигени,
аз лично подразнеща програма не съм срещал(като натисна рефресш и после не се позиционира на клиента на който съм бил преди , аз ако напиша нещо такова потрботелите ще ме набият). Не знам дали е от Java-та, но е адски мудно и дразнещо.

ами в случая вината според мене е изцяло в Оракъла :)
Тия верно са болни/вманиачени У**кс 60-годишни програмисти с бели коси....

Сещам се - като създаваш база, едно че тоолът с който се създава се едно кривоглед далтонист го е правил, ама като свърши и излезе, остава примерно 1 час некъф процес на заден фон да изпълнява разни скриптове върху базата...

Сигнатура!

A какви бъгове има само. В шибаната enerprise consola смениx Total SGA и бъгавото изчадие го умножи по 1000(семних замо 1-та цифра) и Oracle се срина. И трябва да ровиш по 1000 страничните му книги. Не че SqlPlus(дето май е писан C има редактор на ред.

oralce имат само една база - всичко останало което правят е боклук но го продават покрай базата си която е добра

а който казва че vc++ + msdn е по добро от java мога само да му се изсмея

Не разбрах?

Казах, че MSDN е по-добър от документацията на лудата Жаба на сън. За средата казах, че нещата които ги имат жабешките среди са светлинни години пред VS. Тва е поради причината, че езикът Жаба е далеч по-прост за анализ и могат да се автоматизират много неща.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

За средата казах, че нещата които ги имат жабешките среди са светлинни години пред VS

Може ли кратко списъче?

InteliJ Idea, Eclipse.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Ами с някво кратко пояснение все пак? :)

Тъй като си писал грамотно и смислено, мисля да те поправя където грешиш поради непознаване на Java-та.

В отговор на:

---

Получава се, че хората пишат Object Pools и правят всякакви еквилибристики за Object Reusing за да задържат консумацията на памет в разумни граници.

---

Съвременните JVM правят писането на pools за управляние на паметта излишно упражнение, което само забавя нещата. Всъщност GC в Java е много добър механизъм за управление на паметта - ако сумираш времето отделено за GC и го сравниш с времето необходимо за управление с reference counting както в COM, разликата в полза на GC е огромна. В контeкста на сървърско приложение което работи дни и седмици наред, GC е по-добър дори от стандартните malloc / free, защото повечето обекти които се създават от даден момент нататък са само временни, a GC е оптимизиран да работи с такива: поддържа непрекъсната свободна област от паметта и алокирането на обект е само инкрементиране на указател, това е като или по-бързо от работа със stack frame. Недостатък, разбира се, е че не се знае кога се включва GC, и че това блокира работата на приложението.

В отговор на:

---

като имам нещо от рода на

for( i = 0; i < arr.size(); ++i ) // не помня как се пишеше това на Жаба

( i не се бара в цикъла ) проверката си е живо разточителство.

---

Aко JIT чрез static inference реши че няма нужда от проверка, няма нужда да я слага. Не знам дали това е реализирано, въпрос на оптимизации е, но платформата не е сбъркана заради това че обещава проверка.

Според мен стандартните библиотеки са по-добре документирани от MSDN, може да е въпрос на навик, но за мен обикновено е по-добре да пробвам първо Google search вместо да се ровя в MSDN. Вероятно е само навик наистина, но аз пиша и на Java и на C++ (по-малко).

За низове "+" се компилира до StringBuffer, рядко си струва да го ползваш експлицитно.

Иначе за много неща си прав: const е сериозна липса, по принцип Java програмистите не внимават много-много за ресурсите, generics са нови и нямат пълния expressive power на C++ templates.

Всичкият този критицизъм се отнася и за .НЕТ впрочем, включително липсата на истински const. ДотНЕТ още няма generics.

Ключовият момент е, че ти може и да не допускаш тези класове грешки от които те пази Java-та, но много хора ги допускат - затова са класически грешки. А нещата се пишат в екип. Има механизми за предпазване на целия екип от тези грешки когато пишеш на C++, като coding standarts които включват класове за управление на ресурси и т.н., но на практика е много трудно да постигнеш същото ниво по този начин. Човек може да пише качествен, generic код на С++, но повечето проекти, които уж са писани на С++ всъщност са писани на С, с някакви класове вместо само функции и използване на 2-3 тривиални разширения на езика. При това в един проект се работи с 3 различни класа string, но най-вече с char *.

Методите се компилират с JIT общо взето веднъж. Ако приложението работи дълго (сървър), времето за компилация може да се пренебрегне. Затова JVM има 2 версии - клиентска и сървърска, защото баланса е различен, и на сървърската изобщо не я е грижа колко време отнема компилацията.

Почти никакви оптимизации няма compile-time, освен свързани с константите и inline на final методи. И не може да има, защото се компилира до bytecode.

Тук искам и аз да се включа малко.

VS (за 6.0 говоря) е доста по-схваната от eclipse по отношение на навигацията и достъпността до отделни елементи на кода. Колкото и с++ да е старомоден език, не е чак толкова трудно да се навигира по класовете, без да се занимава човек с генериране на броузинг дивотии.

Говоря за пресни чувства, тъй като от около година работя с еклипс (мързи ме да превключвам), а от преди седмица работя по една програма на ВС6, и съм малко разочарован като си припомних колко спартанско ИДЕ е това.

Не може да се каже обаче, че еклипс е на светлинни години пред ВС6. Спомнете си, от колко години работим с ВС6 (струва ми се от 4-5 вече) и какъв беше хардуерът тогава. В същото време много по-трудно се навигира с/с++ код, отколкото джавешки. Всеки с малко повече опит може да си представи какво представлява парсерът на едното (С вече е на повече от 20 години и има зад гърба си няколко стандарта), и колко осакатено е другото (Джавата още не е навлязла във възраст за пъпки по лицето ).
В тази връзка се сещам как един колега, който пише само на джава, беше много изненадан като му казах, че темплейтите които едва сега от версия 1.5 се появяват в Джава, ги има в с++ от години (не знам дали не и от самото начало).

Още нещо. Сравнете моля:

javac myStupidProgram

със старата мантра:

precompiler-compiler-linker (със всичките им прилежащи опции)

Това е за да припомня на уважаемите колеги джавофили, че докато еклипс е едно дизайнерско творение, ВС има за какво да се грижи отдолу.

За завършек искам да кажа, независимо че вече съм своего рода еклипс фен, и за С/С++ понякога предпочитам за развойна среда EditPlus и обикновен компилатор, щом става дума за VS6.0 мога само да кажа:

СТАНИ! И ОТДАЙ ЧЕСТ НА СТАРОТО!

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

В отговор на:

---

Съвременните JVM правят писането на pools за управляние на паметта излишно упражнение, което само забавя нещата.

---

JRE 1.4.2 достатъчно съвременна ли е? Щото аз съм виждал как без Object Pool вдига 1G при обработка на много изображения ( по-точно - правене на thumbnails от тях), когато за същата операция на C++ биха ми стигнали няколко M. Никакви опити за нулиране на пойнтери и т.н. не помагат - gc-то не се вика докато не приключи операцията.

Не говоря теоретично а от практиката си, за това в случая познанията ми по Жаба не са съществени. Те наистина са скромни.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Да, JRE 1.4 е достатъчно добро.

Pooling-a не може да влияе на консумацията на памет, а само на скоростта. Освен ако не броиш за консумация паметта, която се брои за заета и при следващия пас на GC ще се освободи. GC се вика когато му трябва памет, няма нищо общо с конкретни операции които текат в този момент. Ако укажеш на JVM да ползва по-малко памет, GC просто ще се пуска по-често, и пак ще си работи. Това е като кеша на операционната система - паметта се брои за заета, но е на разположение.

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

Имаш една текуща картинка от която се създава един thumbnail и това се прави в цикъл докато свършат картинките и се напълни един масив с малки картинки. Тоя масив не заема много памет, но докато се върти цикъла консумацията на памет се вдига неимоверно, защото паметта за текущия имидж не се освобождава каквито и фокуси да прилагаш. Ако файловете са достатъчно много се получава 'Out of virtual memory', но gc така и не се задейства. И ръчно викане не помага.

Не знам дали успяха да решат проблема (отдавна се махнах от там ) и не съм много добре запознат с механизма на pooling-а, но идеята беше да не се правят нови имиджи, че не пускат лесно паметта.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Ми аз си ползвам VisualAssist, и общо взето, не знам какво да искам повече от IDE-то.

Пробвай някой път да се пожабуркаш с InteliJ Idea и като се върнеш на която и да е съвременна C/C++ среда ще се чувстваш много зле. Тогава вече ще знаеш ( какво да искаш от IDE-то ). Некои хора са много изобретателни!

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Добре де, що не обясниш? Евреинът Амит, който вече придоби определена популярност, от време на време имаше проблясъци, като например - "Ако не можеш с 5 думи да ми обясниш дадена идея, изобщо не ми я хвали".

Tva samo evrein moje da go izmisli...

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.