Ruby je skvelej jazyk, ale napsat v tom _rozsahlej_ projekt a pak zmenit jednu metodu v nejaky tride, ktera je hodne pouzivana - to je koledovani si o velkej pruser, protoze u Ruby neni zadnej preklad, zadna kontrola typu a parametru - vse jen za behu - a to je vazne pozde. Jinak pro skriptovani a mensi zalezitosti je "vykon" psani v Ruby neuveritelnej.
Odvazny tvrzeni :).
Jak velkej je projekt, kterej ma v Ruby 20 tisic radku, coz odpovida odhadem tak 30 tisicum radku v Jave? Asi to bude pouze mensi zalezitost, protoze jinak si nedovedu predstavit, proc jsem s Ruby tak moc moc spokojenej.
P.S.2 Jestli chcete pouzivat typovou kontrolu pri prekladu, jako hledac chybneho volani prave zmenene metody, tak si v jakymkoliv objektovym jazyce koledujete o dost velky pruser :).
Co presne si predstavujete pod pojmem compile-time check? Jestli kontrolu syntaxe, tak tu dela vetsina interpretovanych jazyku pred spustenim pri parsovani zdrojaku. Jestli kontrolu datovych typu, tak ta Vam neni v lepe navrzenych objektovych jazycich prilis k uzitku.
Vsichni programatori v Jave jsou tak genialni, ze jim staci program zkontrolovat kompilerem a pak si jsou bez testovani jisti, ze nema zadne chyby? Nebo je prani otcem myslenky? - neco jako udelat ze spatny featury dobrou: "k rychlemu a malemu jazyku ma Java fakt daleko a uprimne doufam, ze tak daleko nikdy nepujde...".
P.S. Nemuzu si po dvou letech intenzivniho programovani v Ruby vybavit jedinou chybu, ktera by se dala zachytit kompilerem, a kterou neodhalil parser pred spustenim nebo jsem ji nezjistil pri prvnim testu funkcnosti ;). Takze si troufam rict, ze tvrzeni, "ze kompilace snizuje mnozstvi chyb v programu nebo zrychluje jeho vyvoj", je pouze teoreticky nesmysl ;)
Tak to ja si zase vybavuju spoustu situaci, kdy compile-time kontrola datovych typu zachytila stupidni preklepy a usetrila mi cas tim, ze jsem se k samotnemu testovani nemusel ani prokousavat... Samotne testovani je samozrejme nutne, nicmene pokud probiha tahle cela typova maskarada az v dobe behu programu, neni to tak bezpecne, a ladeni chyb je obtiznejsi.
Souhlasím s vámi, že statická (compile time) typová kontrola nesnižuje množství chyb a neurychluje vývoj (nejraději používám jazyk Smalltalk). Rychlost vývoje spíše zpomaluje. Stejně člověk musí testovat. A chyby v záměnně typů jsou velmi snadno odhalitelné a opravitelné. Nadruhou stranu se domnivám že pro dokumentační účely a refaktoring se může hodit.
Vsadim se, ze jsi v Jave napsal tak maximalne Hello World a mozna ani to ne. A ze jsi ji videl tak nanejvys jako applet v MS JVM :-). Java neni vhodna na vsechno ale tam kde se pouziva je jeji vykon naprosto srovntelny s jinym resenim.
Pouzivame Javu na WWW serveru (jako vetsina bank a dalsich instituci) a s rychlosti rozhodne problemy nejsou. Na svem kompu (1GHz P4) mam kompletni vyvojove prostredi (IDE) NetBenas napsane v Jave s online syntax checking, on-line doplnovanim atd. atd. a slape to perfektne. Na stejnem kompu mi soucasne jede Apache, Tomcat (Java Servlet Engine), Postgres, KDE a dalsi a dalsi veci. Bez nejmensich problemu.
Takze klidek, nejdrive si v tom neco zkus nebo alespon precti.
"Java neni vhodna na vsechno ale tam kde se pouziva je jeji vykon naprosto srovntelny s jinym resenim."
Neni. Mozna po nafouknuti HW do mnohdy makabroznich rozmeru. Konkretne Tomcat a nad nim postavene aplikace se na normalnim HW oproti jinym resenim (Apache + mod_perl, trebas) vlaci nekdy az nesnesitelne.
Stejne tak NetBeans, my co nemame 1 GHz P4 a stovky MB RAM se muzeme na NetBeans divat jako na povedenou slideshow. Swing je co se vykonu tyka bumbrlicek jako vystrizeny ze zurnalu.
Java ma sve vyhody, ale vykon k nim rozhodne nepatri.
T.
To je dan za to, jak je java navrzena.
Vemte si priklad pristupu k nejakemu poli:
Pokazde se (za behu programu) zkontroluje zda index neni mimo pole => musi se sahnout nekam pro 2 adresy (zrejme do tabulky symbolu) a provest 2 porovnani + mozna nejake dalsi akce (snad nekecam) => z toho plyne priserna pomalost. Nemuzete to treba srovnavat treba z C, ktere je prakticky pouze citelnejsi asembler.
Mozna ze programy psane v Jave byvaji pomalejsi, ale zase s v tom rychlejc programuje ... takze je to pak zajimave hlavne pro firmy ... jim pak prijde levnejsi zaplatit 100000 za naprogramovani aplikace v Jave a 100000 za nadupany server nez 200000 za to same v necem rychlejsim a 30000 za levnejsi server :o)
A navenek je to oboji stejne rychly ...
No, dobre, ty cisla jsou dosti mimo a jen ilustrativni ... ale je fakt, ze kdyz se to takhle secte, tak pak Java jasne vyhrava nad assemblerem :O)
A ono taky zavisi na tom, jak je dotycny program napsany, i Jave jdou delat veci rychle....
No, nevim, jestli zrovna kontrola rozsahu poli je to, co dela Javu "priserne" pomalou. Ten proces se (troufam si odhadnout) vejde do 20 strojovych instrukci tedy u jmenovaneho procesoru cca 20 nanosekund (velmi zjednoduseno). To je myslim rozumna dan za skody ktere muze preteceny index napachat.
Jisteze bude aplikace napsana v C (skoro) vzdy rychlejsi. Ale v assembleru to pujde jeste rychleji. Jde o to urcit si pro danou apklikaci pomer bezpecnosti/citelnosti/rychlosti_vyvoje/vykonu. Jina to bude kdyz budu psat driver a jinak kdyz velky webovy projekt.
Prominte, ale Perl NENI srovnatelne reseni. Delal jsem v obojim takze si troufnu porovnavat. V soucasne dobe ma nas projekt (J2EE) tesne pod 1/2 milionu radku a to jen diky tomu, ze hojne vyuzivame existujici projekty (FreeMarker, Jakarta a dalsi). Neumim si predstavit, ze bych neco takoveho mohl nekdy napsat v Perlu. Teoreticky jiste ano, tak jako bych to mohl napsat v C nebo v shellu ale trvalo by to straslive dlouho.
V tom je rozdil mezi profesionalnim resenim a necim, co si zkousim doma nebo na nejakem stredne malem webu. Naklady na HW jsou oproti vyvoji takoveho systemu zanedbatelne.
A mimochodem nase aplikace jede na Resinu (Servlet engine) na AMD 1800+ 1GB RAM, je tam stredne velky provoz (asi 2000 hitu/hodinu), odezva je perfektni a server je 93,5% Idle.
Neni moc reseni pro rozsahle apklikace ale mezi nimi je Java kral :-).
NetBeans: souhlasim s vami, ze Java potrebuje hodne pameti. Pokud ji ma je rychlost vyborna. NetBeans je profesionalni vyvojovy nastroj a predpoklada se, ze 1GHz P4 a 1GB RAM neno pro profesionalni vyvoj nic neprekonatelneho :-).
Nechapu, proč by se Perl nehodil na něco většího? Vemte si projekt http://is.mendelu.cz/, ten je napsaný celý v Perlu. Není tam ani řádek jiného jazyk s výjimkou metadat v XML, SGML, HTML, uložených procedur v PL/SQL nebo stylů pro TeX. Pravda, má to jen 1/4 miliónu přádek kódu, ale co je to za měřítko rozsah programu v řádcích? To bychom museli napřed uvažovat, že schopnost Perlu vyjádřit myšlenku je tolikrát úspornější než schopnost Javy a to už je tenký led. Takže zkuste příště neuvádět takový nesmysl. A považuju ten projekt is.mendelu.cz za profesionální. Za 3 roky vznikl kompletní studijně-provozní webový informační systém školy, což není na jeho rozsah (asi 600 funkčních aplikací) příliš mnoho.
zaoberam sa tvorbou vacsich projektov (pre niekoho hooooodne velkych) projektov pre webove rozhranie a vsetko je to perl. java bola pre pomalost vylucena. vravim o stotisicoch az milionoch pageviews denne pri dynamickych strankach (vratane USRM a podobnych lahodok) a ziaden zvlastny hardware. to najsilnejsie co som mal kedy v rukach bol Sun Solaris 250 s loadavg pri maximalnej zatazi na 0.10 a to na tom nebezali len tie stranky v perli ale i databaza a mediaserver.
Jo, ale ma nesporne jine vyhody. Ostatne kdyby ne tezko by M$ navrhobal neco jako CKanal.
Napr. jista nejmenovana telekomunikacni firma ma uctovaci system v Jave. HW stal nesporne vic, nez by bylo treba pro jina reseni. Duvodem je bezpecnost Javy. Chyby se hledaji mnohem snaz a tudiz kdyz vas vypadek na nekolik minut stoji miliony, trochu vetsi investice do HW se bohate vyplati.
Když se píše něco rychlého, je nejlepší C/ASM. Když něco bezpečného, tak ADA. Když chci rychlý vývoj, pak Python, Ruby nebo eventuelně Perl. Všechny tyto jazyky jsou specializované na určitý typ aplikací. Java je takový slepenec vlatsností všech výše uvedených a nějak mi uniká cílová aplikační skupina.
Zlí jazykové tvrdí, že Java spojuje nevýhody všech ostatních programovacích jazyků :-)
Jistě, Java je použitelná téměř na všechno, ale téměř na všechno existuje i výkonnější/rychlejší/bezpečnější/snažší řešení.
Na Javě mi také vadí, že není free as speech. Tedy alespoň to předpokládám, když není standardní součástí distribucí. Jestli se pletu, prosím poučte mě.
Prenositelnost, bezpecnost, rychli vyvoj ti nestaci jako aplikacni domena jazyka Java? To je slusne na jeden jazyk ne? Ostatni maji po jednom. A java hned tri zajimave ne?
Proc by si ji vybrali vetsina z bank a instituci. Prave pro rychli vyvoj, bezpecnost. Prenositelnost je az na druhem miste, ale ma jednu vyhodu. Musi se drzet standardu a tedy zadne proprietalni reseni. Co vi si prat.
Vam se to zda jako pozbirani spatnych vlastnosti z ostatnich jazyku? Me to zni jako vyhody.
Jen pridam dalsi dobre vlastnosti: jednoduchost a cistota syntaxe a typova kontrola.
Java je jeden z nejhůře přenositelných běžně používaných programovacích jazyků -- překladače a interprety existují pouze pro některé platformy, rozumně použitelný svobodný pak pokud vím neexistuje žádný, takže například pro svobodný software je míra přenositelnosti nulová.
Mohl byste ten rychlý vývoj upřesnit? Moje zkušenost s programováním v Javě je, že člověk neustále píše, píše a píše (zbytečnosti) a že neustále musí vynalézat kolo.
Takže zbývá jen ta bezpečnost spouštění cizího kódu, což je vlastnost myslím stále ještě unikátní, a považoval bych to za přesně tu specializovanou oblast, kde může být použití Javy na místě.
Pokud vim, tak interpret pro Javu existuje pro Windows/Linux/Solaris od Sunu a Linux/AIX/OS X/OS2 od IBM. Napr. kompilator Jikes je open source (OSI Certified) (i pod FreeBSD a Mac OS), GCC je take open source a jeho GCJ kompiluje do nativniho kodu procesoru (zatim ma problemy se Swing).
Rychlost vyvoje v programovacim jazyku (a cele platforme) zavisi nejen od rychlosti psani kodu (jeho programovych konstrukci), ale take od jeho prehlednosti, moznosti dokumentace, jeho bezpecnosti (hlavne ukazatele), kvalitnim knihovnam. Dobre napsany kod (i kdyz upovidany) usetri mnoho prace a casu pri udrzbe softwaru, hledani chyb a pri praci v tymu. To co investujete na zacatku se vrati pozdeji a vicekrat. Nezamenujme pocet radek kodu od jeho vypovidaci hodnoty a jednoduchosti. Jednu vlastnost miluju: striktni typova kontrola. Tato chyba se napr. v C/C++ velice lehce prehledne (pokud to necte nekdo jiny)
int i = 5, j = 6;
...
if (i = j) { ... } // true vzdy, kdyz j != 0
Java to nedovoli prelozit (zachrani spoustu casu pri krokovani).
Porad se tu omyla Java je pomala. Ale to vam nikdo nebere ze je pomalejsi nez C, ale svymi vlastnosti je primarne urcena pro vyvoj rozsahlych aplikaci, prenositelnych a bezpecnych. Neni urcena na psani driveru, super rychlych vypoctu (i kdyz se objevuji i knihovny pro vedecke vypoctu a rychlost na tom neni zas tak spatne). Programuji take v C/C++ graficke algoritmy, tak vim o cem mluvim.
Porad se tady neco mluvi o vykonu. V dnesnim prostredi ale nejde o to, ze v nejakem jinem jazyku napisu stejnou vec o 20% rychleji, ale o to, ze ji napisu za polovinu casu a penez. Pokud je problem s vykonem, je nekdy lepsi koupit silnejsi server, nez dalsiho pul roku optimalizovat. Nerikam, ze se vykon da vzdy obetovat-zalezi na konkretni situaci a nasazeni. Nicmene v beznych inet projektech (informacni systemy, databaze...) me osobne zajima, za jak dlouho jsme schopni to napsat, jak drahe bude rozsirovani systemu a jeho udrzba a rovnez stabilita celeho reseni. A taky aby programatori byli spokojeni a jazyk jim jejich praci maximalne usnadnil.
Skutecne to muze byt jednoduse tim, ze to blbe napsali :). Jinak co se tyce "pomalosti", mam dalsi typ - IBM Update Connector, ktery aktualizuje sw pro Thinkpad, strasne pomaly program. Na druhou stranu je zase sw, ktery je v pohode - napriklad Netbeans je od verze 3.5 uz docela rychle.
Ono je toho vic. O tady tech par zakladnich vecech se pise vsude mozne uz docela dlouho, na ty dalsi se bohuzel dost zapomina, a kdyz uz se zmini, tak jen jako kratoucky napis, ktery nikomu nic nerekne.. Pritom treba ta zminena zmena pametoveho modelu by mela mit docela vliv na praci s vlakny a synchronizaci, jestli se nepletu tak napr. korektni chovani tzv. 'double-checked locking' idiomu ap. coz se programatoru muze dotknouty dost vyrazne. A mate tam dalsi podstatny veci, jako napr. concurrent api., podpora unicode 4.0 s jeho 32 bit znaky atd..
Souhlasim, ze kod se stane necitelnejsim a taky se mi to nelibi. Jeste bych pochopil zalozeni "generickych typu" i kdyz se obavam zpetne kompatibility.
Rozsireny cyklus for, Static import a Metadata povazuji za velmi nestastne a zbytecne.
Trocha nebezpecne se mi zdaji byt Generické datové typy. I kdyz neco velmi podobneho celkem dobre funguje v C# a nejsou s tim problemy. Ale bude se na to spatne zvykat.
Naopak vitam Proměnný počet parametrů a Vyctive typy.
precti si clanek jeste jednou nebo se jen zamysli - se zpetnou kompatibilitou rozhodne zadny problem pri pouziti generickych datovych typu nastat nemuze. a v cem by to melo byt nebezpecne??? presunuje to velkou cast typovych kontrol pri pouziti kolekci do compile-time a to je opravdu dulezity krok spravnym smerem - zrovna absence tohoto mechanismu byla jednim z hlavnich nedostatku javy a zpusobovala velke mnozstvi obtizne dohledatelnych chyb.
Blbost, v Javě dělám už kolem čtyř let a mám za sebou pěknou řádku projektů a systémů. Chyby si způsobují sami programátoři a né nějaká absence mechanismu v jazyku. Z vlastní skušenosti vím, že pokud člověk nemá tuchy o tom, jak provést typovou kontrolu, tak ani v případě že to bude nějaký mechanismus dělat za něj, nebude kód takového člověka bezchybný a stále bude tápat. Takhle to nutí se zamyslet co to tam do toho editoru píšu.
A o dohledatelnosti chyb: využitím exceptions a logů lze přesně zjistit kde která chyba je a opravit ji. Pro příště skus přemýšlet dříve než něco plácneš do fóra. Dík.
Samozrejme, ze chyby zpusobuji programatori, na druhou stranu typovane kolekce skutecne zabrani vzniku nekterych z nich a usetri potrebu vpisovat kontroly do kodu rucne, nevim co se vam na tom nezda.. Samozrejme, ze to nezabrani vsem chybam, ale to neni duvod proti pouzivani takovychto mechanismu. To uz muzeme rovnou zrusit staticke kontroly typu a vychutnat si to ladeni prez vyjimky a log se vsim vsudy. Ale to uz pak nebude java ale python, ruby nebo neco podobneho..
asi nechapes ze je vyhodnejsi najit stejnou chybu pri prekladu nez za behu, coz je dost smutne. toho kdo "nema tuchy o tom jak se provadi typova kontrola" nepovazuju za programatora v jave a jak se ho dotknou pripravovane zmeny je mi uplne jedno, skutecnym programatorum to pomuze protoze budou moci vynutit volani metod s korektnimy parametry ve vice pripadech nez nyni UZ ZA PREKLADU. tobe nepripada vyhodne kdyz muzes rict, ze tvoje metoda pracuje napriklad s retezci, na urovni jazykove konstrukce a ne jen v nejakem komentari? obtiznou dohledatelnosti mam na mysli to ze misto kde se stala chyba (napriklad vlozeni objektu spatneho typu do kolekce) muze byt uplne jinde nez se chyba projevila (klidne v kodu nekoho jineho), navic program je chybny ale muze dlouho fungovat spravne.
No, z exception a logu sice zjistim, ze chybu zpusobil napr. nejaky objekt v nejakem zasobniku na radce te a te, ale ze ten chybny objekt tam vlozila jina funkce uplne nekde jinde uz nemusi byt tak snadne zjistit ... to pak clovek obvykle musi nejakou dobu premejslet kde se to tam vzalo ... takze tak snadne to neni .... snad ve vsech progrtamovacich jazycich se muzou vyskytovat takove chyby, ktere se projevi jinde nez kde je programatr napsal (napr. memory leaky - i kdyz ty se v Jave obvykle nevyskytuji...., obvykle typu 'tady neco nastavim a o kus dal mi to na tom sleti')
Nesouhlasim. Vyhody prevazi nevyhody. Citelnost bude jiste vetsi. Prikladem muze byt prave pretypovani, zkracena sekvence 'for' (obdoba 'foreach' z jinych jazyku) a generickych typu. Jejich kombinaci je program nejen kratsi a prehlednejsi, ale vyhnete se take mnohym chybam a prekladac ma lechci praci pri obtimalizaci. Syntaxe techto zmen nejsou tak velke, aby je programator nevstrebal do jednoho tydne (maximum).
Kdo programuje v C++, tak mu nebude delat problem ani genericke typy, ktere jsou na pochopeni pro zacatecnika asi nejslozitejsi.
Generickymi primitivnimy typy myslite asi autoboxing primitvnich typu. Na tuto vlastnost ceka mnoho programatoru jake na smylovani. Predstavte si, ze je to jen zkraceni zapisu a lehce to pochopite. Stejne jako nepremyslite nad zapisem:
"Ahoj".equals("Ahoj")
pak stejne zapis:
3.doubleValue()
se rychle vzije do krve.
Stejne jako zapis:
(new String("Ahoj")).equals(new String("Ahoj"))
je neprehlednejsi i zapis:
new Integer(3).doubleValue()
Hlavne pri vkladani do poli, map a mnozin mi to dost vadilo. Pro me je prece jedno jestli je to primitivni typ nebo jeho objektove zapouzdreni. No neni to prehlednejsi
Map<Integer, Integer> map = new Map<Integer, Integer>();
map.put(3, 15);
int i = map.get(3);
nez
Map map = new Map();
map.put(new Integer(3), new Integer(15));
int i = ((Integer) map.get(new Integer(3)).intValue()
Static import je vec, z ktere mam rozporuplne dojmy. Predstavil jsem si situace kdy je to vyhodne, ale i ty, kdy to kod zneprehledni.
U metadat ukaze az cas, jake najdou vyvojari vyuziti. Ocekavam neco ve stylu C# u WebMethod a dalsi napr. jiz zminovane snadnejsi modifikaci rozhrani. Rozhodne to neni neprekonatelny problem pro programatora to pochopit. Nikdo Vas nenuti je pouzivat, ale pouzitim muzete zkratit cas uprav casti kodu a celych knihoven atd.
Veskere upravy by meli byt spetne kompatibylni ve smyslu, ze kod vytvoreny pro 1.4 pujde bez uprav pouzit v 1.5 (krome noveho slova enum - kdo ho pouziva pro promenne muze vyuzit nejaky prepinac pri kompilaci). Mozna asi nepujde spustit kazda aplikace zkompilovana pod 1.5 se starsi JRE, opravdu nevim.
Mno nevim, nektere ty Vase priklady na pouziti autoboxingu by spis mohly slouzit jako protiargument vuci jeho zavedeni. Protoze jestli se programatorum vziji do krve cunarny jako
3.doubleValue()
tak budou produkovat programy generujici spousty zbytecneho balastu. Samozrejme, ze v urcitych situacich se to uplatni, viz napr. Vas priklad s kolekcemi, ale kdyz uz chcete argumentovat pro, tak proboha nevytahujte zmrseniny jako
new Integer(3).doubleValue()
(new String("Ahoj")).equals(new String("Ahoj"))
ap. Navic ta analogie neplati, kratky priklad se stringem skutecne jen vola metodu a s tou delsi variantou nema mnoho spolecneho, kratky priklad s intem je vicemene eq. dlouhe forme, kompilator vam vygeneruje neco jako
Integer.valueOf(3).doubleValue(),
coz v aktualni implementaci vede k zbytecnemu vytvoreni noveho objektu, v ostre by snad melo byt nejake kesovani objektu pro casto pouzivane hodnoty.
Jinymi slovy, autoboxing ano, ale jen tam, kde by se jinak pouzilo eq. reseni..
Jako prave neco jako 3.doubleValue() mi pripada zverstvo.
Kdyz tohle napise profik, tak asi vi co dela...ale bude kazdemu novackovi jasne, ze to udela novy object, ktery se pak posleze zahodi po vraceni doubleValue.
Je pravdou ze ve Smalltalku se takove vaci taky delaji, jenze prave tam ta 3 uz je objektu.
Nikde se nerika ze se musi vytvorit novy objekt, ktery se zahodi. Zalezi to na prekladaci a jeho optimalizacich. Pokud vznikne objekt a hned zanikdne neni problem tuto konstrukci obejit.
Uznavam ze priklad 3.doubleValue() je umely (totezne z '(double) 3' ), ale nevim co je na tom prasackyho.
Je to jen zvyk na primitivni typy a odmitani mozneho pohledu na ne jako na objekty. Pro me ma int a Integer stejnou vypovidaci hodnotu - cele cislo a je prece na me jestli vyuziji jeho objektovych metod nebo matematickych operator.
Stejne tak v C++ mohu po implementaci operatoru nad objektem ComplexniCislo nahlizet jako na primitivni typ. Nic z objektoveho pohledu na svet tim neporusim.
Ale rika. Specifikace pravi, ze pokud pouzijete primitivni typ na miste wraperu, provede se konverze na prislusny wrapovaci typ, coz se momentalne provadi prez prislusnou factory method a vzhledem k zpetne kompatibilite se to bude dost tezko menit..
Jinak osklive je na tom to, ze se pred programatorem skryva, ze jim specifikovana konstanta/objekt neni az tak uplne to, jako co se tvari, ale ze misto intuitivne predpokladaneho primeho zavolani metody se deji podivuhodne veci.. A to je to u konstanty jeste pomerne jasne, ze se deje neco podezreleho, u promennych a navratovych hodnot funkci to bude horsi..
Jeste k tem prim. typum. To neni vec odmitani mozneho pohledu na ne jako na objekty, to je vec toho, ze to objekty nejsou, a ze z michani s nima budou jen problemy.. Ze ma pro vas int a Integer stejnou vypovidaci hodnotu je fajn, ale ekvivalentni nejsou, objekt se da pouzit na spoustu dalsich veci, jako napr. synchronizace ap., objekt se prirazenim nemeni, atd atd.
Kdyby primitivni typy byli ciste objektove, pak by mohli existovat vyjimky ze syntaxe jako u tridy String - z duvodu prehlednosti (spojovanim retezcu pomoci znamenka '+' je vlastne vytvoreni StringBufferu, spojeni a vysledek). Take se tam neco deje aniz by to clovek videl. Prekladac take provadi optimalizace napr. "Ahoj " + "Jardo" + s zkrati rovnou na "Ahoj Jardo" + s. Tzn. ty kde je vysledek dopredu znam. Coz v pripade 3.doubleValue() je take. Souhlasim ze v pripadech jake je predavani parametru metodam takove optimalizace provadet nelze. Ale prekladaci nikdo nepredepisuje jak se ma chovat ve vyse popsanych pripadech. Takze optimalni prekladac do binarniho kodu ulozi rovnou 3.0
Jelikoz musi zustat Java zpetne kompatibilni, pak nelze dosahnout namapovani matematickych operatoru na funkce objektu a odposteni se od primitivnich typu.
U tridy String bylo rovnou pocitano jako z objektovym typem a vyhnuli se tak problemum z C++ ( jejich stringu a char*, v nekterych funkcich je pozadovano char* z duvodu kompatibility a v tele je to hned prekonvertovano do stringu, predkladame-li tedy string, musime ho nejdrive zkonvertovat do char*).
Stejne jako ve formalnich jazycich je implementace cisel optimalizovana a tedy namapovana na ciselne typy pouzivane v pocitaci. Duvod je jasne: rychla a jedina moznost jak vyrazy spocitat na dnesnich pocitacich. Pouziti je, ale striktne funkcionalni a zalezi na interpretu jak si s tim poradi.
Prikladem v Jave je trida BigDecimal, kterou by bylo mozne (jeji metody add, substract, multiply, divide) namapovat na operatory + - * /. Operator = by zustal zachovan tedy prirazeni objektu (dalsi operatory by se chovaly obdobne a += b je jen zkratka a = a + b). Pouziti by bylo stejne jako u int:
BigDecimal a = 3.5bd, b = 2.3bd; // bd je oznaceni typu obdobne jako 3.0f
BigDecimal i = a + b;
Funkcnost zustava stejna jako je nyni, ale vypada to jako primitivni typ. Opacnym postupem z int, long, float, ... by se doslo k objektovym typum a prirazovani primitivnich typu by odpovidalo prirazeni objektu (objekt by se nesmel modifikovat stejne jako BigDecimal).
Vysledek
Integer a = 5, b = a;
a = 3;
Integer i = a + b;
by byl stejny jako
int a = 5, b = a;
a = 3;
int i = a + b;
V pripade modifikace instance objektovych typu (zapouzreni primitivni) pri operaci = by byl vysledek jiny.
Priklad:
(new String("Ahoj")).equals(new String("Ahoj"))
byl jen zpusob jak predvest co za nas dela prekladac. konstrukce "" tady nebyla chapana jako objekt String, ale posloupnost znaku. To ze konstrukce "" je chapana jako vytvoreni instance String se stejnym obsahem jako je posloupnost znaku je jen konvenci Javy (v C++ je to pole znaku). Moje chyba ze pisu rychleji nez myslim.
Sticka metoda Integer.valueOf() vyzaduje String jako parametr, takze prekladac skutecne vyraz
3.doubleValue();
prelozi na
(new Integer(3)).doubleValue();
s moznymi optimalizacemi, takze vysledek bude asi
(double) 3;
Ano je to ekvivalentni zapis, ale jde spise o priklad ruzneho pohledu na typy v Jave. Znate-li nekdo funkcionalni jazyky pak vite, ze primitivni typy tam neexistuji na vse se pohlizi prozmenu jako na funkce: Cislo 3 je chapana jako nularni funkce vracejici vzdy hodnotu 3 (coz muze byt formalne jine vyjadreni vzajemne struktury mnozin - teorie mnozin).
Nevim proc se Vam stale nelibi pohlizet na primitivni typy jako na objekty. Kdyby od zacatku byli primitivni typy v Jave navrzene jako objektove, pak byste se nad tim nepozastavovali (bylo by to asi i formalne cistsi).
Zopakuji ze autoboxing se pouziva tam, kde je potreba objektovy typ a v pripade ze je predlozen primitivni typ je implicitne vytvoren odpovidajici objektovy typ. A stejne tak naopak.
V pripade ze jsou zde dve pretezovane metody
f(int) a f(Object) predpokladam ze vyraz f(3) povede k volani f(int) a ne k autoboxingu a volani f(Object).
Oki, Stringy uz nechame byt:) (i kdyz prekladac udela neco jineho, alebrz obe instance budou identicke a vytahnou se z konstant poolu misto aby se vytvareli v dobe volani..) Jinak ta staticka valueOf() co jsem mel na mysli je az z 1.5 a pouziva se prave pro boxovaci ucely.
Co se optimalizaci tyce, prijde mi to jako zajimavy problem. Otazka je, jestli by si kompilator vubec mel takoveto optimalizace dovolit. Dokud se zachazi s prim. typy, muze si delat v podstate co chce, ale u wrapperu, jakozto objektu, ktere dostane z nejake knihovny, muze narazit na nejake sideefekty ap. Neco jineho uz to bude u JIT kompileru, ktery vidi skutecne implementace a muze analyzovat dobu pouziti objektu ap. ..
A co se mi nelibi na michani objektu a prim typu - viz komentar asi o 2 zpet.;) Samozrejme ze by bylo cistsi, kdybychom meli jen objekty, otazka je, co by to udelalo napr. s vykonosti ap. Rekl bych, ze by nakonec stejne doslo minimalne k vzniku ekvivalentu poli primitiv, a zas by se objevila otazka, co jsou vlastne jejich prvky? A muzu je pouzit jako objekty? A co treba ona drive zminena synchronizace? Atd ..
> i kdyz prekladac udela neco jineho, alebrz obe
> instance budou identicke a vytahnou se z konstant
> poolu misto aby se vytvareli v dobe volani..)
muze platit u nekterych prekladacu, pokud se nachazeji u sebe dve konstanty a operator to dovoli (priorita), pak neni problem z nich udelat jednu a tu pak ulozit do poolu konstant
> Jinak ta staticka valueOf() co jsem mel na mysli je az z 1.5 a pouziva se prave pro boxovaci ucely.
OK
> Otazka je, jestli by si kompilator vubec mel takoveto optimalizace dovolit. ...
Veskere vysledky odvozene od predem danych konstant lze predpocitat. Nehrozi zadne nebezpeci (od toho jsou konstanty a operace povedou vzdy ke stejnemu vysledku).
Optimalni prekladac by mel umet i
"Ahoj " + "Jardo, ted je " + 5 + " hodin."
v dobe prekladu spojit do
"Ahoj Jardo, ted je 5 hodin."
bez nebezpeci.
> ... otazka je, co by to udelalo napr. s vykonosti ap ...
To je otazka. Jelikoz by kazdy instance 'objektoveho primitivniho typu' byla zaroven i konstantou (viz muj prispevek o neco vyse). Mohl by s ni prekladac zachazet jako s primitivnim typem a jeji metody chapat jen jako operace nad nimi (ve skutecnosti to tak opravdu je). Meli by proste vysadni postaveni mezi tridami stejne jako String. Nejsem si jist co by to presto nestalo nejakou rezii v dobe behu aplikace.
To vse je jen otazkou semantiky a implementace.
V implementaci by to byl vzdy primitivni typ. Semanticky by to byl objekt. Rozdil v kodu nepoznas (viz. muj prispevek o neco vyse).
Nevim jastli pujde v 1.5 napsat:
Integer a = 5, b = 3;
odpovida po autoboxingu
Integer a = new Integer(5), b = new Integer(3);
a nebo
Integer c = a + b;
po unpoxingu a naslednem autoboxingu
Integer c = new Integer(a.intValue() + b.intValue());
Pokud bude toto v 1.5 mozne, pak rozdil mezi nimy se vypari a obe dvojce obou prikladu jsou jen syntaktickou variantou teze semantiky.
Jen by zustaly dvojice jmen pro totez (napr. int a Integer) - alias. Implementovan by ovsem mohl byt jen primitivni typ (napr. int). Prenesla by se tedy vyjimka pro primitivni typy ze syntaxe cisteho objektoveho jazyka do jeho implementace, tzn. navenek jen objektove typy, uvnitr samozrejmne nektere primitivni (tak jako u funkcionalnich jazyku).
> Rekl bych, ze by nakonec stejne doslo minimalne k
> vzniku ekvivalentu poli primitiv, a zas by se
> objevila otazka, co jsou vlastne jejich prvky? A
> muzu je pouzit jako objekty? A co treba ona drive
> zminena synchronizace?
K ekvivalentu poli primitiv by nedoslo. Vzdy by to bylo pole objektu (syntakticky) Implementacne to muze byt cokoliv. Zalezi na fantazii prekladace. Pokud by neexistoval rozdil mezi int a Integer. Pak
Integer[] = {3, 4, 5, 6};
Je chapano jako pole objektu Integer (je zaruceno ze tam neni nic nez Integer kontrolou typu vkladanych objektu) pak nevidim duvod proc by to prekladac nenahradil polem intu v pameti.
Zopakuji, ze je to jen jiny pohled na totez. Primitivni typ a operace nad nim a objekt s metodami.
U synchronizace bych potreboval vedet co mate na mysli za problem (lepe specifikovat).
vtip je v tom ze kdo je liny se to ucit tak muze psat po staru a nema problem. ovsem bude ho mit kdyz bude chtit pouzivat kod od tech co nejsou lini se ucit ale naopak jsou lini psat dokolecka stejny idiom iterace kolekci, stale za behu pretypovavat, hledat chyby v pouziti ruznych nahrazek vyctovych typu...
Kdybys cetl poradne, tak sis vsiml ze se nejedna jen o pocet radku, ale jeho prehlednosti. V ukazkach se kod zkratil i o nekolik radku, ale i poctu znaku na radcich, ale hlavne se logicteji rozclenil. Vyhodou je take prisnejsi kontrola v dobe kompilace. Coz vam take zmensi pocet probdelych noci pri hledani chyby.
Argument ze mi vyjimka urci radek s chybou je chaba. Mnohdy je nutne vyuzit vnorenych vyjimek nebo vyvolani vyjimek jinych typu nez je chyba (pretezovana funkce nedovoluje vyvolat jine vyjimky nez funkce z predka). Dale se chyba muze projevit az pri pouziti chybne konstrukce a ne pri jejim vytvoreni.
V takovych pripadech mohou nove konstrukce take pomoci.
Myslim ze hlavni myslenkou Javy bylo byt ciste objektovou - k cistoty se priblizilo autoboxingem/unboxingem a vyctovymi typy (SmallTalk je asi cistejsi :-( ). Dalsi myslenkou byla striktni typova kontrola - genericke typy. Dalsim je rychly vyvoj - rozsireni for, static import, promenny pocet parametru urychluje zapis a cteni a tim i rychlost uprav, a take auto/un-boxing a metadata (v C# velice urychluji vyvoj napriklad webovych metod).
Java IMO nechtela nikdy byt ciste OO, ale spis pseudo OO - prave kvuli primitivnim typum a jejich predavani hodnotou... Zrovna ten autoboxing mi moc cisty neprijde, ale to nic nemeni na tom, ze navrhovanymi zmenami se nijak nemeni objektovy vlastnosti Javy, vsechno je to zamereno spis na pohodli programatora. Mozna krome generics, ktery budou vynikajici pro compile-time kontrolu...
Neodchyluje, naopak. Svého času jsem pátral po tom, proč je Java tak nemožná, když za ní stojí někteří velmi schopní lidé. Nakonec jsem někde narazil na článek ze stránek Sunu, kde se vysvětluje, že Java musí být na začátku co nejjednodušší (co se definice jazyka týče), aby se ji snadno mohl naučit každý. Až na Javu přejde dostatek lidí, lze do jazyka začít přidávat složitější konstrukce. A vida, právě se to začíná dít.
Zatimco autoboxing mi prijde jako jasne pozitivni vec, ktera sebou nenese takrka zadne riziko, tak o vyctovem typu a statickem importu dost pochybuji. Prijde mi, ze veskere zprehledneni kodu je zadne. Otazky "Odkud se tu, k certu, bere to abs()? Ze ktere tridy to tu vlezlo?" budou asi dost caste. Bojim se, ze vysledkem muze byt i zcela chaoticky kod ve stylu jazyka C.
Promenny pocet parametru mi prijde jako zcela zbytecny. Muzu prece predavat pole a kontejnery. Navic si umim predstavit i par matoucich situaci jako metoda(int i), metoda(int i, Object o), metoda(int i, Object... o). Nevi nekdo, jak se tohle resi?
Genericke dat. typy a rozsireny for jsou zajimave. Kdyz jsem to videl prvne, tak jsem se lekl, ze vyvoje Javy se zmocnili sileni C++ sablonari. Ted si rikam, ze to mozna nebude tak uplne zle.
Ve statickych importech se asi vsichni shoduji, ze mohou, ale nemusi kod sprehlednit.
Promenny pocet parametru je opravdu jen zkratka pro pole objektu (nebo jinych typu). Nevim jak to bude fungovat, ale vetsina jazyku (prekladacu jazyka) se snazi najit funkci s presne odpovidajicimi parametry, pokud ji nenajde hleda nejblizsi. Priklad
metoda(2) zavola vzdy metoda(int)
metoda(2, new Object()) vzdy metoda(int, Object)
metoda(2, new Object(), new Object()) zavola metoda(int, Object...)
Funguje to i v C++ a jejich implicitnich hodnotach parametru. V pripade moznych kolizi prekladac ohlasi chybu. Priklad:
metoda(int i)
metoda(int i, int j = 0)
je nepripustne. Sablony v Jave bohuzel (mozna bohudik) nejsou funkcne totozne se sablonami v C++ (spise makra). V C++ lze s nimy dosahnout vypocetni optimalizace v dobe prekladu, kterym se C v nekterych pripadech jen zda.
Java je jazyk pro neschopne programatory. Kdyz si programator neumi udelat logickou analyzu kodu takovou, ze odalokuje vse, co naalokoval, potrebuje garbage-collection, ktery zere spoustu pameti a casu. Kdyz je nekdo tak blby, ze neumi udelat praci s retezci tak, aby nesahl za konec alokovaneho mista (skutecne jsem videl pripad, kdy clovek na nekolikaty pokus nebyl schopen napsat v C parsovani retezce obsahujiciho datum tak, aby se pri jakemkoli vstupu nesahlo za konec toho retezce), potrebuje na retezce preddefinovane objekty, kvuli kterym se to cele zpomaluje ... a tak dale.
Vzhledem k tomu, ze informacni systemy zpravidla programuji blbci (kdo je v tehle branzi inteligentni, dela analyzu projektu a kod nepise; programovani se skutecne prenechava tem nejmene schopnym), je pouziti javy nekdy vhodne.
Mimochodem --- na tom serveru, co dela 2000 hitu za hodinu a ma zatez 93.5%, jak tady nekdo psal, vam jeden request trva 0.11 sekund --- coz je asi 175 milionu tiku procesoru --- to teda je DOST POMALY!!!
Ano, castecne mate pravdu. Java byla vyvijena tak, aby vystrel do vlastni nohy pozadoval explicitni potvrzeni.
To, ze existuje velke mnozstvi predpripravenych obejktu ve slusne (nikoliv oslnujici), kvalite muzeme povazovat za nevyhodu jen pokud chceme predcasne optimalisovat kazdy detail. Pokud chcete muzete si vytvorit vlastni implementace temer cehokoli.
Vy jset fakt dost mimo - mam pocit ze navrhujete systemy jeste metodou waterfall - prisne oddeleni analyzy a kodovani. To se dnes uz dela opravdu jen ve vyjimecnych dobre oduvodnenych pripadech nebo to prosazuji starsi generace manageru ktere nic jineho nepoznaly.
Lidi chyby delaji a delaji je i ti absolutne nejlepsi - vase bozskost je samozrejme vyjimkou. A protoze jsou na svete apliakce, u kterych je velmi nezadouci aby se ladily metodou pokusu a omylu, vznikaji jazyky a systemy, ktere maji alespon nektere chyby eliminovat.
Ad alokace pameti a garbage collector: teoreticky vi kazdy, ze co naalokuje musi vratit ale krome bohu kazdy z nas obcas zapomene. Taky je bez GC tezsi pouzit nektere standardni design patterns jako treba Object Factory. Musite tak sledovat cely zivotni cyklus objektu nebo si pocitat reference coz muze byt dalsim zdrojem chyb.
A pokud jde o ten zminovany server - tak tech 93,5% casu je IDLE. Ale i kdyby trval jeden request tech 0.11 sekundy jak muzete proboha rict, ze je to pomale kdyz nevite co za tu dobu udela? Ale ja vlastne zapominam, ze komunikuju s Bohem takze vy to jiste vite dokonale :-/.
Je pro zacatek 93,5% nebyla uvadena zatez, ale idle. Nez budete pokracovat v urazeni programatoru. Tak si uvedomte ze napriklad Linux delaji lide, kteri o nem premysli analyzuji a vetsinou si analyzovane veci i programuji. Vetsina doktorantu si programuji svoje vedecke vysledky a sami a nemaji na to ty debily, jak jim rikate. Znam lidi, kteri jen analyzuji a absolutne nechapou programovani, smysl algoritmu. Postaveni cloveka ve firme nerika nic o jeho inteligenci nebo demenci. Ja napriklad nekdy analyzuji problem. A nekdy si ho i schuti simplementuju a nikdy neurazim lidi, kteri jen programuji. Jejich pracovni vykon mnohdy nekolikanasobne prekonava vykon lidi kteri jen sedi, premysleji a sem tam neco nakresli do diagramu. Vasi poucku nam rikali i na vysoke skole: Programovani je pro stredoskolaky. Nekdy to vsak vypada opravdu tak jak to vypada.
Programuji jak v C++ (grafiku, nikoliv vsak nejake kresleni, ale geometricke algoritmy), tak Jave. Vase absolutni pocitani casu me utvrzuje ze nechapete k cemu informacni systemy jsou. Tech 0.11 sekundy je merena rychlost i s transportem (to jsem se z vaseho prispevku nedozvedel)? Je to vysledek jednoduche operace nebo i cteni z databaze? Spracovaval system Vas pozadavek samostatne nebo obsluhoval vice pozadavku? Nedelam zavery z neceho co jsem si jednou zmeril a jeste k tomu nevim co to ve vnitr dela. Nas firemni system bezici na Jave obsluhuje desitky pozadavku za minutu. Odezva je na webu nekolik sekund. Musite si vsak uvedomit, ze jsou tam:
- kontrola prav na aplikaci podle stukturovanych roli
- dotazy do databaze
- vygenerovani vysledku do XML
- pres XSL je vysledek v XLS, PDF, HTML
server je 'jen' jednoprocesorovej Sun a nebyl s nim vetsi problem (dostupnost nekolik mesicu bez preruseni).
Programovat tak rozsahly system v C++ je hola sebevrazda a k tomu je Java jak delana: v odvetvych s kritickou spolehlivosti.
Psal jsi uz nekdy neco nad 20 radku ? Programovani je neustaly boj s chybami a pokud to nekdo nevidi, tak jde bud o genia jakeho jsem nepotkal a ani nepotkam, nebo o kecalka ktery je mimo. A tvuj zpusob vnimani veci jako souboje mezi "debily" a "inteligenty" ..... precti si tohle http://alexandr.ritual.cz/via/energie/1001/
Pro Sickyboye:
Prenositelnost binarniho kodu mezi systemy nema u serverovych aplikaci zadny vyznam --- tam se to da vzdycky prekompilovat.
Pro Dirigenta:
Jak to navrhujete vy? Tak, ze analytik navrhne dialogove okno, pak ho zacne programovat, nekolik hodin ho ladi, az ho ma odladene, tak zapomene k cemu vlastne bylo a jaka jina okna kolem neho chtel udelat? Eventualne az udela i ta jina okna, tak zjisti, ze v tom uz naprogramovanem by melo byt neco trochu jinak. Tak to snad ani nejde.
Pro Mata:
spatne jsem to napsal, ale dobre spocital. Zatez 6.5%, 2000 rq za hodinu = 0.555 rq za sekundu. 0.065 / 0.555 = 0.117 sekund na request. Athlon 1800 ma frekvenci 1500. 0.117 * 1500M = 175.5M tiku.
Ohledne argumentu, jestli je to pomale: co byste delal pred 5 lety? Na tehdejsich pocitacich se taky pouzivaly informacni systemy a nebyly pomale --- nekdo se s tim holt tenkrat piplal, aby to behalo rozumne. Dnes je levnejsi si koupit silnejsi pocitac nez programovat rychle bezici programy.
Ohledne programovani rozsahleho systemu v C++ --- vemte si treba jadro systemu, kompilator nebo SQL server --- to jsou dost slozitejsi projekty (ne nutne vetsi) nez podnikovy system a pisi se nekdy dokonce v C bez ++. Kdybyste najali same lidi, co neco slozitejsiho v C psali, klidne by vam v C udelali cely podnikovy system. Ale najmout tym takovych lidi je znacne tezke, proto se firmy musi spokoji s programatory, kteri pisi v jave.
Pro Jirku Hradila:
Jak uz moje jmeno napovida, jsem lamer.
Rel bych, ze blbec je spis ten, kdo si mysli, ze vykon aplikace jde pocitat na tiky procesoru, ja to teda nevim z vlastni hlavy, ale nekdo mi rikal, ze v pocitaci jsou i jine casti. Znam nekolik velmi chytrych lidi, kteri se programovanim v Jave zivi a uz z vaseho projevu je zrejme, ze jim nesahate po kolena.
Nemam nic proti C, ale podobne nazory vetsinou zlysim od lidi, kteri uz invetsovali tolik usili do zvladnuti nastroje jako je C++ (proti tomu mam pro zmenu hodne), ze jim vlastni jesitnost nedovoli si priznat, jak zbytecna namaha to byla.
Ano, pro systemove programovani je C jiste nenahraditelny nastroj, ale pokud se bavime o aplikacnim, tak jeho ukolem je problemy resit a ne porad hlidat a pocitat, kde mi tece pamet. Take zneprehlednit nejakou cast kodu za ucelem usetreni dvou instrukci procesoru je v momente, kdy ma system chvili vydrzet (cti naklady na udrzbu/dalsi vyvoj vyrazne prevysi pocatecni). je zhovadilost.
Mimochodem oznacenim Javy za jazyk pro debily ji dela cest, protoze to znamena, ze se jedna o jednoduchy nastroj.
Uz len pridat #define, pretazovanie operatorov a zopar drobnosti co mi v Jave chybaju a vazne zacnem uvazovat o presedlani z C++.
Go, Java, go ! :) Osobne si myslim, ze pokial bude nutne pisat zverstva typu Integer.valueOf(String("3")).intValue(), tak to ku citatelnosti velmi nepridava ...
No mne se zrovna "3".to_i zda jako dobre zverstvo. Co je na tom elegantniho? Kdyby to bylo "3".to_int, jeste bych to chapal, protoze cloveka by hned na prvni pohled napadlo, ze se konvertuje na integer. Ale mnohem lepsi je podle me reseni z Pythonu, proste napisu int("3") a je to... Protoze pak muzu konzistentne psat i float("3"), MyOwnNumericType("3") apod. Zkratka a dobre, Ruby je urcite zajimavy jazyk, ale obcas byla pri navrhu zbytecne obetovana citelnost.
porovnavate cislo so stringom :) takze bud $a == $b
alebo $a eq $b
ale nie "$a" == $b pokial $b je cislo. i ked perlu je to jedno, syntakticky to nieje moc ciste.
pokial sa totiz pracuje s == porovnava sa ciselna hodnota. z toho by mohlo vyplinut ze "$a" > $b a to by pekne uz nebolo :) "$a" > "$b" je prakticky sortovanie :)) $a > $b je len porovnanie cisiel. nezda sa to ale nieje to to iste.
a ak nie ukamenujte ma prosim :)))
Podle tohohle vypisu je zjevne, ze Java dohani .NET, primarne je to zjevne na tom JSR175 a JSR40, tedy Metadata. Jinak tohle vsechno uz ted .NET ma a uz jsou implementovane i ty Generics, anonymous methods a nebo partial classes. To Java jeste ani neregistruje...Jinak vse ostatni v .NET jiz davno je.
Aha, to jsou zase cancy lidi, co o tom nic nevedi. TO, ze je tam syntakticka podobnost je asi jako to, kdyz programator v C++ tvrdi a tvdili, ze Java je paskvil na C/C++ a ze je to jen jejich zmrsena kopie.
A jeste ad zminka kompilace do bajtkodu. To jsou tu panove hodne mimo. Microsoft v roce 95 koupil firmu, ktera kompilovala do "mezikodu" VB (Colusa SOftware) a dokazala kompilovat VB kod, C++ a pozdeji i Javu. A ta firma vznikla v roce 93, tedy davno pred uvedenim Javy v roce 95. Trochu se seznamte se skutecnosti a vyvojem a neplacejte tu nesmysly.
Jo a posledni komentar k partial classes...to naopak je skvela featura, jen hlupak ji oznaci za zmatecnou (je navrhovana v nekolika univerzitach u nekolik let pro teoreticke jazyky). A je dulezita prave pro snadnou orientaci v kodu, ktery je psat a take generovan nejakym IDE prostredim, aby si vyvojari mohli cist je to, co sami napsali a ne to, co vygeneroval nejaky tool aby to bylo pomichane.
Aha...a to, ze Java vykradla treba ASP se svymi JSP, nebo ze Javabeans kopiruji model COM, ze JTA a cely transakcni model ma velkou inspiraci v MTS...to asi nic matlo? TO jako Java spadla z nebes a najednou preorala cely IT prumysl? Vzdy to vzniklo jako reakce na neuspech, kdy Sun chcel prodat svoji Star7, kde Java (tehdy Oak) byla pro vyvoj setopboxovych aplikaci a kdyz je nekdo nechtel koupit, tak to preorali a udelali z toho tool zvany Java :)) fakt psina
Proboha lidi, kouknete se trosku dal nez jen MS kontra Sun!!!
Vetsina tech technologii, o terych pisete (virtual machine, bytecode, komponenty, ...) nebyla vymyslena ani jednou z vyse uvedenych firem, ale podstatne driv... To, ze si MS a Sun udelali kazdy svou trochu upravenou implementaci vhodnou pro jejich prostredi z nich ani jednoho nedela zlodeje. To je jako byste rikali, ze vsechny firmy jsou zlodeji, nebot pouzivaji quicksort!!!
Generics v .Net budou teprve v dalsi verzi (Java si je pujcila zase od C++). Anonymni metody Java nema a asi mit nebude, ale anonymni tridy ma uz dele. Partial classes si myslim bude nejvetsi bordel jakej muze byt. Implementovat neco na nekolka mistech, potazmo souborech no to, aby se cert vyznal. U metadat mate pravdu ze jsou z C#.
Ale C# prevzal z Javy to hlavni: kompilace do bytecodu.
Neni rozhodujici co od koho kdo prevzal. Vyvoj jazyka by nemel zustat stat. Myslim ze prilis mnoho se v syntaxi vymyslet neda, tak aby to melo smyls. Veskere objektove jazyky se dle meho nazoru blizi ke svemu maximu, kdy jiz dalsi upravy syntaxe nebudou mit smysl (vetsina z nich je jen zkraceninou nekolika konstrukci vzniklych predtim). Vetsina se pote zameri jen na upravy knihoven.
Vznika-li nejaky novy jazyk, ma od pocatku nejakou filozofii, kterou nechce prekrocit. Ma par konstukci, se kterymi si vystaci, a ktere mohou byt i prejaty z jazyku jinych. Pretahnuti programatori si vsak vetsinou vynuti rozsireni jazyka o dalsi konstrukce, na ktere jsou zvykli z jinych jazyku. Jde vesmes o stejne konstrukce jen jinak syntakticky zapsane. Neco se vsak nedostane do jazyka, ale jen do podpurnych knihoven. Vetsinou z duvodu poruseni filozofie jsou nektere upravy i odmitnuty. Takze az zas nektery jazyk vymysli neco genialniho (tato mnozina se rychle tenci) a bude to zivotaschopne, pak za cas to vetsina jazyku prevezme, pokud to neodporuje jejich filozofii.
To je klasicke. Urazet a jeste tak primitivne. Kdyz nejsou argumenty, pouziji se takovehle nic nerikajici fraze. Prestante uz s timhle "marketingem" anti-neco a radeji jednejte racionalne a jako dospely lidi, co dokazi soudne uvazovat.A neboj jste porad jeste pubertaci, co musi neco shazovat, aby se ukazali, jak oni jsou ti borci sveta?
Vase intelektem a dospelosti nabita reakce me primela k jedne otazce - jake _konkretni_ informace o ekonomickych vysledcich spolecnosti Novell a Sun mate k dispozici? Ono je sice uplne jedno, jake maji vysledky, protoze tady mluvime o konkretni vyvojove platforme a zmenach navrhovanych primo v jazyce, ale kdyz uz mate plna usta racionality a atgumentu, pak by me zajimalo, jestli to neni jenom marketingovy letak;-)
Prave ze to si ty hlupaci kolem Javy mysli a vubec nevedi, ze koncept VM byl rozvijen uz od roku 69. A pak na tom zaklade vzniknul tzv. P-kod, do ktereho kompiloval Pascal. A co je paradoxni, ze prave autorem Turbo Pascalu a velkym prispevatelem k vyvoji P-kodu byl Anders Hjelsberg, coz je mimo jine autor Borland Deplhi a nyni je to hlavni inzenyr v MS a navrhoval celou koncepci .NET a C#. Tedy koncept VM znal jiz davno predtim a s tim, jak uz bylo psano, ze MS koupil Colusa Software, tak mel MS jiz koupenou i technologii pro VM, ktera byla nezavisla na programovacim jazyku a na platforme, proto je tak .NET i navrzen. Java a Gosling ti naopak vychazeli prave z modelu VM od UCSD Pascalu a ten byl pro ne inspiraci (Gosling o tom mluvil na OOPL kdyz byla Java uvadena, ze pro nej byl vzor VM z UCSD Pascalu).Takze jsou ti hlupaci kolem Javy uplne mimo, JVM ma pouze upraveny bajkod vice svazany s Javou, jinak interni struktura se podoba VM Pascalu (az nyni se zmenou na dynamicky generacni GC se to zmenilo).
mno .NEt dosel s tou svoji nezavislosti nadruhou az tak dalece ,ze ho spustite jen na MS platforme - a pokusy ho portovat na jinou platformu jsou neuspesne. jinak co se tyka kopirovani - C# je syntakticky v podstate java + nejake drobnosti ,kteree si prisvojila ted. Je to naprosto pochopitelny krok ,kdy se berou ty nejlepsi myslenky ,ktere jsou a plikuji se . Ted byla proste na rade java a je videt ,ze je state tam ,kde se .NEt bude dostavat cele roky...
Ach jo, to jsou porad jen obecny kecy nejakyho zaslepence. Tohle nema cenu komentovat, nebudu se snizovat k nejake flameware bez argumentu a nebo lacinym argumentum, ze neco je okopirovane a nebo to je tak dokonale, ze jiz nemuze byt nic lepsiho. Tohle fakt nema zadny vyznam krome emotivniho vybliti.
a ten zaslepenec jsem ja a nebo vy - me to pripada jako se bavit o tom co bylo drive - vejce ,nebo slepice. ?? holt je to vyvoj - MS nemel nic takoveho jako java a prebral si co bylo dobre. - blaboly typu - predni odbornik ,ktery vymyslel vsechno - si nechte pro deti ,ty vam to mozna sezerou
slova jako nezavislost ,najdete v kazdem druhem popisu .NET<br>
vymysly Ms jako COM , nebo binarni registry se nikam jinam nerozsirily ,nebot existuji kvalitnejsi - corba ,rmi web servisy atd<br>
"Co se faktického významu přenostelnosti týče, velké SW projekty v Javě beztak nejsou přenosné bez rozsáhlých úprav na jinou platformu" : jsou - to co nazyva Microsoft managed kod ( v jave jni ) se v jave dnes nepouziva ( nebo zridka v nutnych pripadech - nicmene bezne se s tim nesetkate<br>
"Co se rozšíření .NETu týče, je za dva roky rozšířen na 30% desktopů a zhruba na polovině aplikačních serverů." 30% procent z windows desktopu za celou dobu posobeni .NEt spise beru jako extremni neuspech ,nebot se to mohlo sirit updaty. - co se tyka aplikacnich servru ,tak samozrejme se to tyka pouze MS servru - jinak co se tyka webovych servru(www.netcraft.com) je velmi vystizne sledovat jak ohodnotili velci zakaznici kvalitu win2003 - za posledni kratke obdobi probehl brutalni propad na uroven ,kterou mel Microsofti produkt vroce 1997 - velmi vystizna je krivka dosvedcujici snahu o migraci na win platformu a rychly nasledny navrat na apache ( coz se tyka javy tez ,nebot apache je pouzivan modulem pro java aplikace ( neplest s tomcatem))<br>
". Už dnes lze říci, že .NET spolu s PHP vytlačil Javu z klinta i web serveru do oblasti middleware." vytlaceni viz vyse - jedna se o pravy opak. -jinak java a swing je dneska jediny zpusob jak propagovat gui aplikaci primo ke klientu nezavisle na operacnim systemu - viz web start <br>
" Další problém je absence kvalitních widgetů podporující visuální design jak pro pro desktopové i webové rozhraní (server web controls). Proč dodnes Javě chybí např. print preview dialog či datagrid podporující databinding (něco, co čím disponoval Visual Basic 3.0 blahé paměti) - to opravdu nechápu."
<br> mno evidedntne moc vyvoj nesledujete a neprogramujete jave - tudiz jen kratce - gui nastroje jsou imho kvalitni ,print preview dialog samozrejme v jave pouzivat muzete a datagrid alespon jsem kdysi resil prez beanu - na druhou stranu jsem vzdycky musel resit specificke dotazy ,ktere nejdou obecne popsat a tak pristup prez klasicke dotazy je jednodussi
- graficky navrh tagu mi krapet schazi ,ale myslim ,ze neco takoveho uz taky existuje - ale web nedelam ,takze mocnesleduji
jinak k te platformove zavislosti ,nebo nezavislosti - prijde mi VELMI nerozumne vytvaret v dnesni dobe jakykoliv projekt s tim ,ze omezim cilovou skupinu pouze na majitele MS windows - uz pro migrace ,ktere dnes probihaji ( k nelibostem lidi ,kterym to holt nesedne) - pokud zvolite .NEt ,tak mate temto svym zakaznikum moznost nabidnout web interface ,coz jejen slaba nahrazka a vyvoj tvrva zbytecne moc dlouho
Co se podpory smart klientů na úkor web aplikací týče - to je určitě trend, který bude do budoucnosti podporovat i Microsoft. Ale obávám se, že je zbytečné o tom nyní diskutovat v souvislosti s Javou vzhledem k tomu, že Sun první kolo boje o desktopy vlastní neprozíravostí a sebestředností prohrál tím, že přiměl MS k vyvinutí vlastní platformy.
Když se Java na desktopech nedokázala prosadit za sedm let existence - jak by se jí to mělo povést nyní v situaci - když má v podobě platformy .NET takovou konkurenci ?
Dokonce i IBM pochopilo dřív než Sun, že k tomu aby se Java dala na desktopech rozumně používat nemůže být napsaná v Javě, ale v nativním kódu dané platformy (SWT widgety, obdoba MS Java wfc). Vylepšená HW podpora dnes Java GUI nezachrání - tim spíš, že Windows budou HW akceleraci brzy podporovat systémově (Avalon).
Jenže .NET bude mít i potom oproti Javě stále náskok ve výkonu, protože správu GUI událostí (listenery), resources a dalších záležitostí obstarávají v .NETu už dnes nativní Win32 API. Ale - jak už jsem uvedl výše - hlavní problém Javy pro použití na desktopech je, že Sun zaostal ve vývoji reusable GUI komponent a DB rozhraní.
To není problém z hlediska použití, ale návrhu - jenže s ohledem na konečný úspěch platformy je ergonomie designu z hlediska vývojáře snad ještě důležitější, než pohodlí uživatele. Bez dobrého vývojového prostředí a komponent rychle dobrou aplikaci neuděláte: vývoj IT diktuje ten kdo má desktopy a směr vývoj na desktopech určuje ten, kdo má kvalitní vývojové prostředí.
mno tak postupne:
Microsoft si vyvinul vlastni net z duvodu ,ze se mu nopovedlo ovladnout vyvoij javy - vyz problem s MS javou a umyslnym zanasenim nekompatibilit - tohle vyresil ku prospechu javy soud
.NEt je castecnou konkurenci pro javu pouze na MS platforme - a vzhledem k tou ,ze je zacinajici trend migrace z MS pryc ,tak ...
SWT je krapet nepovedene a dnes se uz nepouziva - prave proto je skoda ,ze autor zde neuvedl detaily ohledne hardwarove akcelerace j2d -swingu. SWT je etapou v historii
DB rozhrani v jave je podle me docela dobre udelano -
"Bez dobrého vývojového prostředí a komponent rychle dobrou aplikaci neuděláte: vývoj IT diktuje ten kdo má desktopy a směr vývoj na desktopech určuje ten, kdo má kvalitní vývojové prostředí." to naprosto souhlasim - tahle podminka splnena je
MS Java Foundation classes je v zásadě to samé rozšíření, co SWT toolkity, které mj. používá Eclipse - nejlepší vývojové prostředí pod Javou a pro Javu, co existuje - proto bych byl opatrný s prohlášením, že už se "moc nepoužívá".
DB rozhraní v Javě je o generaci pozadu za ADO.NET - jde víceméně o kurzorový engine nad ODBC (opět se mi mimoděk vybavuje VisualBasic 3.0 z roku 1994). Jenže VB 3.0 už podporoval od začátku ten databinding a model datových událostí....
Co se flamování týče, respektuji, že tenhle článek o Javě je pro příznivce Javy a původně jsem do diskuse nehodlal vůbec zasahovat - pokud si na závěr přečtou nevlídné srovnání s .NETem, můžou být za to první řadě vděčni Vám a Vaší zmínce o .NETu.
Jak se do lesa volá....
mno ,nevim ,jak jste prisel na to ,ze eclipse je nejlepsi editor na javu ????? eclipse byl dobry ,dokud byl jednodychy . Jenze jakmile chctete aby podporoval nejruznejsi veci ,tak musite doinstalovavat nejruznejsi moduly - v tom je zadrhel ,protoze okamzite se z toho stava nepohyblivy moloch. S eclipse jsem delal intenzivne skoro rok ,nez jsem si uvedomil ,ze z puvodne mileho maleho editoru mam pred sebou nepohybliveho golema - dneska delam v podstate jen v netbeansech. - je to jen subjektvni hodnoceni ,ale po vyzkouseni mnoheho se mi libi nejvic kombinace netbeans(swing) + xdoclet.
jinak ohledne toho netu jsem to nezacal ja
"DB rozhraní v Javě je o generaci pozadu za ADO.NET - jde víceméně o kurzorový engine nad ODBC " jdbc nema s odbc nic spolecneho ( nastesti)
mily zephire ,aleias fermi - stejne efektivne to napises i v jave ,ale s tim rozdilem ,ze to bude prehlednejsi a nebudu psat deset prikazu na jedu radku - a to nebudu pouzivat zadne cizi veci ,ale i zadne databindery - proste nasypsat veci do tabulky je jednodussi ,nez to co jsi sem dal
Milý sss, alias WELFe: nenasypeš - musíš na to použít cyklus. A i když to nakrásně nasypeš nějakou smyčkou, pro propisování hodnot do DB při každé změně DataGridu budeš muset napsat další kód (WindowsForms DataGrid nabindovaná data v databázi aktualizuje sám, ASP.NET DataGrid poloautomaticky). A i když ty data budeš zapisovat z tabulky do databáze (v té chvíli ovšem tvůj kód v Javě bude mít více než sto řádek, pokud bude stále umět současně podporovat filtrování a řazení záznamů - můj DataGrid umí sám od sebe), tvoje tabulka stále nebude relační (všimni si těch linků na relačně svázaný tabulky v mý ukázce). Odhadem bys na emulování základní funkcionality DataGridu v mojí ukázce potřeboval několik tisíc řádků Java kódu.
Jinak pro představu - mých deset řádků je kompletní Panel aplikace, včetně nadefinování relací a naplnění tabulky - to ostatně v mojí ukázce obstarává jediná metoda.
JEZIS!!!
No to je novinka to je uplna bomba. Nahodou neco o JRE i o .NETu vim a muzu tyto API srovnat. Pokud budeme srovnavat .NET OLEDB a JDBC3 pak jsou to naprosto totozne technologie se kterymi jde stejne efektivne pracovat.
Jinak absolutne jste nepochopil, co je hlavni myslenka .NET OLEDB. Je to naprosto stejny jako u Javy, tj. ze ovladac, ktery implementuje toto API *POTREBUJETE*. Jenomze vy asi pristupujete jenom do Accessu nebo MSSQL, ktery tam uz jsou predinstalovany... Takze vam to ani neprijde.
Pro Javu existuje hafo ovladacu (vic nez pro .NET) a jak komercni tak i zadarmo (stejne je to u .NETu to mi verte). Pokud si ale zakoupite nejaky profesionalni nastroj (za stejnou cenu jakou date dejme tomu za MS VS), pak obvykle dostanete s timto nastrojem balik kvalitnich ovladacu. Coz u MS VS nemate. Takze bych to shrnul...
.NET OLEDB ma zatim do Java JDBC daleko :)
Nene nezakladejme novy flame, na ten tu neni sirka :)) Technologie jsou to minimalne srovnatelne...
Já nový flame zakládat nehodlám - na druhý straně vaše obavy z mý odpovědi tak trochu chápu...;-) Především věta že .NET OLEDB ma zatim do Java JDBC daleko je tak trochu nesmysl, protože něco jako ".NET OLEDB" v .NETu neexistuje. Existuje tu jen OLEDB provider pro ODBC datový zdroje, ale pro MS SQL nebo Oracle existuje samostatná datová vrstva. Ale ta hlavně nepředstavuje základ databázových technologií .NETu, to je jenom datová pajpa - "trubka na data".
Základem DB technologií je vrstva ADO.NET což je v kostce engine pro in-memory replikační XML databáze. Myslím, že schopnost JDBC3 končí někde kdesi u odpojených datasetů (CachedRowSet) a sortování a filtraci rowsetu - ale už nepodporuje fíčury klasického ADO (datashaping, hiearchický, vícenásobný a relační rowsety a recordy, distribuovaný datový zdroje a persistenci a indexaci datasetu - a to jsme stále u klasické, sedum let staré COM technologie - nikoliv .NETu. Ten k tomu navíc přidává referenční integritu a replikační engine. Pomocí ADO.NET lze relativně jednoduše aplikaci vybavit off-line databázovým engine, který cachuje změny v relačních tabulkách (dataset zde není jednoduchý nebo několikanásobný rowset - ale kompletní relační databáze s udržování konzistence, co se týče DRI a datových typů) a při replikaci/synchronizaci je propíše do podkladové databáze.
Pokud ani teď netušíte, co ADO.NET umí anžto ho usilovně srovnáváte s JDBC (a co víc, snažíte se přisoudit tento omyl mě...) - pokusím se objasnit základní myšlenku ADO.NET na příkladu: Mám smart klienta napsaného v .NETu, který si po spuštění v režimu on-line natáhne kompletní data ze všech tabulek týkající se daného konkrétního uživatele včetně constraintů a relací do datové struktury, kterou lze snadno (jediným příkazem) serializovat na disk a vytvořit tak pro klienta jeho vlastní kopii databáze. Off-line uživatel si v ní data šudlá, mění maže a upravuje tak dlouho, než má možnost/potřebu práce v režimu on-line - ADO.NET s datovým vzorkem přitom stále nakládá tak, jako by byl pořád připojený on-line. A nakonec se klient připojí se na server buď přímo, nebo přes middle-tier vrstvu webových služeb a propíše jediným příkazem všechny změny do databáze zpět. V zásadě jde o replikaci dat a v trochu odlehčené a redukované podobě to funguje i po dobu web session na web serveru, kdy třeba uživatel kliká po e-biz serveru semo tamo a modifikuje nákupní košík (zde se ovšem in-memory databáze udržuje pouze v paměti). ADO.NET engine se přitom stará o všechny otázky s tím spojené - třeba replikační identifikátory, správné pořadí update relačně svázaných tabulek při jejich replikaci, optimalizaci - indexaci a datové manipulace, dotazování z DataSetu atd.) - čili zdaleka zde nejde vůbec o nějakou OLEDB nebo SQLDB vrstvu, což je pouze kurzorový engine na nejnižší vrstvě téhle technologie.
A to celé je pěkně prosím součást základní funkcionality .NETu, kterou si stáhnete free z MSDN, je prefektně zdokumentovaná (pokud nevěříte, porovnejte si v Google počet výsledků na "+sort +filter +Rowset" (430 výsledků) a "+sort +filter +DataSet" - 42.000 výsledků) a je pěkně integrovaná do Visual Studia.NET (databinding, design-time containery, atd.) a funguje to pěkně i ve standard verzi VS.NET za 4.000,- Kč (v profi verzi VS.NET platíte za generátory sestav a enterprise rozšíření, ale nikoliv za popsané features).
Jinými slovy, technologie jsou to nesrovnatelné - protože co se DB technologií týče, zde MS staví na více než desetiletých zkušenostech s vývojem ODBC, RDO a OLEDB/ADO.
Pominu-li, že jsem omylem zazěnil dva pojmy (OLEDB s ADO.NET - kdo se v tom má
vyznat, těch zkratek je prostě moc a MS nám to teda moc neleučuje), tak vy
se jenom snažíte přenést diskuzi na vyjmenovávání, co že to vlastně s ADO.NET
lze dělat a poukazujete na to, že to má všechno vestavěno přímo v RT
knihovnách.
Stejně tak tady mohu já začít psát, čeho všeho dosáhnete spojením JDBC a
jiných technologií (mapování objektů, XML, EJB), které většinou seženete jako
open source (což se jeví vždy jako lepší řešení než MS) a jedinou nevýhodou je
to, že musíte stáhnout několik souborů s příponou JAR a přidat je k projektu.
Mohl bych pokrýt všechno, o čem tady dlouhosáhle píšete. Zkušenosti na to mám
a můžete si být jist, že se Vašich odpovědí nebojím. Čeho se bojím jsou ty
úzké nudle, které na rootu vznikají a redakce to ne a ne odstranit. Je to asi
nejslabší stránka roota.
Diskuze se týkala něčeho jiného. Poukázal jste na to, jak efektivně se dá
dělat frontend pro rel. databázi. Uporotnil jsem vás, že toto jde stejně dobře
v Javě, přičemž ovladače třetích stran jsou samozřejmě pro ADO.NET také
zapotřebí. Nevidím důvod, proč se při vývoji omezovat na jedno API, které
poskytuje sadu rozšíření, jež asi stejnak ani nevyužijete. Třeba replikace by
měl podporovat přímo dat. server a pokud je k tomu nutná nějaká emulace v .NET
vrstě, asi byste měl uvažovat o změně serveru. Nehledě na to, že toto
rozšíření nadiktoval a navrhnul Microsoft.
U Javy si můžete technologii vybrat. Kvalitních technologií, které se dají
použít, jsou stovky, možná tisíce. Ať to jsou inmemory databáze, XML,
distribuované datové zdroje, perzistence, objektové mapování včetně
dědičnosti. Co je datashaping nevím, tak podrobně jsem ADO.NET nestudoval,
nicméně je asi jasné, že všechny tyto věci "navíc" musí ovladač nějak
implementovat. Jestli to dělají všechny ovladače to je otázka, kterou Vám
touto formou pokládám a o čemž pochybuji.
Technologie jsou to srovnatelné. Nic nového či převratného podle mě ADO.NET
nepřináší a na té nejnižší úrovni zhruba kopíruje JDBC (teď netvrdím, že MS
okopíroval JDBC, pouze kopíruje) přičemž přidává ty fajnůstky navíc.
trosku (no, hodne) si pletete AWT a SWT... to jsou hrusky a jabka, takze:
AWT - je nepovedene API, ktere bylo nahrazeno Swingem, nejlepsim OO rozhranim pro tvorbu GUI na teto planete
SWT - je API od firmy IBM, ktery dela presne to, co .NET WinForms, tedy rychly okna, problem je, ze je to hure dokumentovane
tak, pro priste uz to vite...
Myslím, že rozdíly mezi AWT, Swingem, IFC/WFC, JFC a SWT chápu.
Co k tomu dodat ? SWT má řadu nevýhod a jeho vývoj ustrnul, takže ho nikomu pro seriózní vývoj doporučit nelze, ale kdyby byl Swing ve své době nejlepší OO rozhraní pro GUI, nevyvinulo by IBM vlastní. A kdyby bylo AWT tak špatné, nepoužívalo by se dodnes javax.swing spolu s java.awt. Většina appletů na webu pracuje s AWT, protože je jednak jednodušší a snáze se programuje, je komaptibilní s MS Java - a v neposlední řadě je rychlejší, než Swing.
Jen bych to doplnil. SWT vzniklo v době, kdy Swing prakticky neexistoval.
Jeho použití je však zavádějící. Nesnaží se nahradit Swing a ani není možné je
srovnávat. Dneska velké programy ve Swingu (IDEA, Netbeans) jsou možná
rychlejší než Eclipse. To je ale můj subjektivní názor.
Jinak dělat aplety tak, aby fungovaly na MS implementaci je holý nesmysl. Já
to vím, protože jsem zruba rok pracoval na projektu, který byl původně
zamýšlen tak, aby pracoval i pod tou jejich chudou implementací Javy, která je
nekompatibilní a pomalá. Ukázalo se, že se to prostě nedá. Nakonec stejnak
aplety smetla technologie WebStart. Aplety už prostě nejsou potřeba, tady už
známe vítěze už dávno - je jím Flash.
AWT je slabé řešení pro správu GUI a bylo to zapříčeněno také tím, že bylo
navrženo narychlo a v době, kdy v jazyku nebyla zakomponovaná jedna klíčová
vlastnost, která dělá programování ve Swingu tak příjemnou. Bohužel se
používají třídy z AWT i ve Swingu, do dneska nechápu proč (uspora místa na
disku?). Toto je jedna z věcí, která me u Javy tíží. Java a její RT API se
dost vyvíjelo a programátor se musí seznámit ve většině klíčových tříd hned s
několika verzemi a vědět, jak se to dělalo dříve a jak se to doporučuje dělat
nyní. Stejné to nebude ani s Javou 1.5 ačkoliv by měly být změny zpětně
kompatibilní. Tady spatřuji výhodu hlavního konkurenta: .NETu.
Jak můžete říci že vývoj SWT ustrnul? Stačí se podívat na stránku projektu
Eclipse a hned zjistíte, že se připravuje verze 3.0 s mnoha vylepšeními právě
pro SWT. Nic tady netrne a SWT je prostě alternativa pro ty, kteří třeba
Swing použít nemohou (GCJ, diskety a podobně).
Když už se mluví o soudu, tak ve skutečnosti došlo mezi MS a Javou k mimosoudnímu vyrovnání. Z nějakých důvodů ovšem Sun začal porušovat podmínky tohoto vyrovnání, a to i přesto, že MS všechny podmínky plnil a plní.
Pravděpodobně se projevila skutečná, tedy i ta nepěkná tvář firmy Sun.
To jen pro upřesnění soudu o úmyslné zanášení nekompatibilit. Po mimosoudním vyrovnání mimo jiné se Sun písemně zavázal, že jsou vyrovnáni, a že nejsou mezi nimi žádné závazky a nedořešené otázky. Sun za to dostal slušný paklík dolarů. Součástí dohody byla i možnost instalovat velmi starou verzi MS Javy po dlouhý čas do Windows.
Sun ovšem dohody dodržovat nemusí, nebo si to aleposň myslí...
ASP.NET controls, ktere jsou standardne nabizeny jsou nechutny perverzni bastl, vedle ktereho vypada dort Pejska a Kocicky jako gurmanska pochoutka. A nemluvim o koncepci, mluvim o implementaci -- nakonec zjistite, ze je snazsi to vubec nepouzivat, nez se neustale piplat s tim, vsechny ty blbosti povypinat a ty co nejdou alespon neutralizovat. Takze s takovym vizualnim designem jdete do ........ (kdzy si doplni svoje oblibene misto).
Nechapu co tady flamujete.
Kazdy jazyk ma sve pro a proti. Velky projekt se da delat jak v Jave tak v Perlu i v cemkoliv jinem. JE TO O TOM JAKY MA PROGRAMATOR (CI CELY TYM) STYL PROGRAMOVANI. Pokud se bude dbat postupu a pravidel a prisne vsechno kontrolovat, pak to neni problem udrzet.
Java je vhodna pro obrovske projekty s velkym poctem lidi. Je lehka na nauceni, OO a take ma skvelou podporu pri ladeni a navic ta prenostitelnost. Je pomalejsi, ano. To jsou jeji silne a slabe stranky...
Pokud nekdo nechce pouzivat BOXING/UNBOXING, nemusi, nikdo ho k tomu nutit nebude. Jinak i s B/U lze psat cisty kod, staci se drzet pravidel a nedelat "prasarny".
Tak uz se prestante urazet.
nevite nekdo, jestli se do javy nekdy dostanou i pretizene operatory? vim ze jdou celkem jednoduse nahradit funkcemi, ale z c++ jsem na ne zvykly a myslim, ze hodne zrychluji praci a zvysuji citelnost kodu. a nevite nekdo jestli se tam nekdy dostanou implicitni konstruktory, aby se funkce nemuseli psat se vsemi moznymi kombinacemi parametru.
jeste by me zajimalo jestli v dalsi verzi bude mozne dedit ze 2 a vice ruznych trid.
v c++ uz delam celkem dlouho a v jave jen chvili, takze pokud tam tyhle veci nekde jsou, tak mi, prosim, napiste.
Me se libi jazyky kde si muzu sam nadefinovat zakladni veci jako jsou cisla, stringy, pole, listy atp. a definovani operatoru nad podobnymi (a samozrejme i ruznymi jinymi) objekty je naprosto logicky pozadavek.
Treba scitani, scitat muzu pole, komplexni cisla, cisla s neomezenou presnosti, matice, zretezene seznamy atp.
Nebo operator [], pro hash tabulky a jine kontejnery, recordsety.
Nechapu co s tim ma spousta lidi za problem, blbe pouzivani operatoru je blbost programatora, stejne tak jako blbe jmeno funkce je jeho vlastni blbost. Operatory jsou jen funkce se specialnim jmenem. Kde je nejaky problem ?
Ano, hezky receno :). Osobne si myslim, ze rozlisovani mezi operatory a funkcemi je spis v hlave, ale to se dostavame k funkcionalnimu programovani, na ktere ani Java ani C++ navrhovane nebyly. Pretezovani operatoru v C++ ale tento problem neresi, zato vytvari dalsi.
Ostatne idea kvuli kazde kravine rozsirovat jazyk je primo zhoubna. Mnohem pochopitelnejsi se miz daji snahy resit problem v ramci jednoduchych a jasnych pravidel.
Pretizitelnost operatoru je dobra vec jen, pokud programujete vedecke vypocty. V dalsich pripadech kod vetsinou znecitelnuji.
Implicitnimi konstuktory myslite ass implicitni paramametry. Tak toho se take asi nedockate, prave kvuli citelnosti kodu. (neni problem udelat funkci ktera ma vsechny parametry, a ostatni ji volaji s defaultnimy hodnotami parametru).
Dedeni ze dvou a vice trid bylo nahrazeno pomoci interfacu (C++ muselo zavest dalsi modifikatory por dedeni, aby se tak vyhnulo problemum). Nekdy to je otrava, jindy to ocenuju.
Jasne ze to vsechno nepotrebujes, je to jen kvuli pohodli, rozhodne mi pripada lepsi pouzit treba pro pocitani s vektory zapis a = b + c; nez a = b.plus(c); a to ze nekdo nevhodne pretizi nejaky operator, jeste neznamena, ze je to zbytecne nebo nezadouci. navic si myslim, ze pretizeni operatoru by neznamenal velky zasah do kompilatoru javy a jvm. verim, ze implicitni konstruktory uz mohou javu hodne zmenit a mozna i k horsimu, ale kdyby treba implicitne byly vsechny konstruktory explicitni a uzivatel by si vybral jen ty, ktere chce pouzit pro automatickou konverzi klicovym slovem implicit, nemuselo by to dokonce zmenit ani manualy, ale jenom je rozsirit. ale jak rikam mozna by to bylo velkym zasahem do javy samotne. dedeni z vice trid neni sice potreba, ale nevidim duvod proc by tam nemohlo byt. jinak jsem rad, ze tam dali sablony.
Já taky nevidím důvody, proč by to tam nemělo být. Slušné použití operátorů velmi zpřehledňuje kód. Koneckonců asi není náhoda, že v Javě je operátor+ pro sčítání řetězců. Asi i Sun pochopil, že jsou výhodné.
Není potřeba zabředávat do teorie, protože rozumně použité operátory jsou užitečnou věcí.
Můj názor prostě je, že skutečný vývoj Javy skutečně akcelerovala až konkurence .NET a taky neustálé snahy IBM.
<noflame>Jinak jsem si zvykl, že lidé kolem Javy jsou velmi nekritičtí vůči svému miláčkovi.</noflame>