Vlákno názorů k článku Proč se má vyplatit vývoj pro Linux? od peter - Na zaklade vlastnych skusenosti s vyvojom desktopovych aplikacii...

Myslím že jste se trochu spletli. I když aplikace používají sdílené knihovny stejně si každá alokuje paměť na dané vytvářené objekty znovu. V .NET jde spíše o strukturu dědění tříd která umožňuje programátorovi používat už předvytvořené třídy ve svém programu. Je škoda že takovéto promáklé množství tříd na Linuxu není. Tedy nevím o tom.

Ehm, jasným soupeřem .NETu je Java.

Java + SWT .. ? to uz by snad i slo ne? :)

Hmm, možná jsem to formuloval špatně - věc se má tak, že původně měli VBA + C++ a teď přecházejí na Haskell a C++. Protože Haskell je (aspoň skrzevá GHC) pravděpodobně mnohem výkonnější než VBA, asi se dá čekat, že kódu v C++ nemusejí mít tolik (ostatně i podle Language Shootoutu na tom Haskell není až tak špatně ;-)). Myslím, že jsem našel k tomuhle našel vyjádření ještě někde, ale teď ho nemůžu najit. ;/ Kouknu po tom ještě.

Jenže problém je, že k programování v .NETu se dneska dostanou lidi, co jsou schopný zplodit takovýhle věci. ;/ Kamarád se mi svěřil před pár dny s téměř totožným problémem. Některé zdánlivě "velké profi firmy" by radši svoje interní aplikace měly před světem tajit, aby si neutržily ostudu... ;/

U Javy to nejaky ten patek taky neplati, zvlast v novejsich verzich, ktere standardne zapinaji platformni 2D akcelerace (byly tam i drive, ale z obavy z kompatibility byly vypnute).


Jinak samozrejme ta nepouzitelnost .NETu ci Javy je naprosty nesmysl, kdyby to bylo skutecne tak, tak jaktoze je v techto jazycich napsano tolik pouzivanych programu :-) A jestli dana aplikace je o par procent pomalejsi, bere o par MB vic v pameti, to uz dneska opravdu vetsinu vyvojaru trapit nemusi (neco jineho je samozrejme vyvoj embedded zarizeni atd., bavim se zde o klasickych desktopovych/serverovych aplikaci) :-)

Ale samozrejme, spatna aplikace se da slepit v .NET stejne dobre jako v C/C++.. Holt je treba si uvedomit, ze efektivita a rychlost aplikace v tkvi primarne v algoritmech, ne v tom, jestli se patlate s kodem v C nebo Jave :-)

Vidím, že o .NETu a zvlášť o verzi 3.5 toho předřečníci moc neví.
Hibernate a podobné ORM nástroje jsou sice fajn, ale LINQ je integrovaný na úrovni jazyka.
Tlusté UI v Javě - hrůza, měl jsem tu čest a to bylo naposled.
U webu je to sice lepší, ale ne o moc. Motání zdrojových kódů do xml markupu, to je zvěrstvo, které ztěžuje ladění a testování.

QT je asi o něco lepší než MFC, ale opět WCF je už daleko jinde.

A tady někdo asi moc neví o Javě.
Předně nevím, co je podle vás tlusté UI. Jestli myslíte tlustého klienta... pak by mě zajímalo v čem máte problém.

Hibernate tu byl o pár let dříve než nějaký LINQ, takže se jeho funkce daly používat již v době, kdy se o něčem takovém .NETU nejspíš ani nesnilo. To že není uvnitř jazyka považuji skoro za výhodu. Už vidím ty prasečárny kde se míchá práce s DB a business logika. Nějaké dělení aplikace na vrstvy to ale .NET programátor asi řešit nebude :) (ale ne, všichni nejsou takový, já vím). Ale když jste tak chytrý, vyzdvihněte mi konkrétně 5 výhod LINQ proti Hibernate. Mě bohatě stačí integrace Hibernate pluginem do vývojového prostředí, kterou si zkontroluji dotazy a mapování na DB.

No a to poslední o webu a míchání zdrojáků do xml? Co jste to proboha viděl? Asi jste v nějaké jiné dimenzi než já.

Vono od MS je všechno dál než cokoliv ostatní, viďte. Ono i to Visual Studio předběhlo celou konkurenci, že? Někdy se u komentářu opravdu bavím. Tohle je ten případ.

A business logika nepracuje s databází? ;-) No LINQ se hlavně moc nesnaží si hrát na ORM vrstvu. Já osobně tyhle objektizační pokusy moc nechápu, buď používám relační algebru, nebo graf z objektů, ale smíchat to dohromady znamená v podstatě uříznout dobré vlastnosti obojího. Další dort pejska a kočičky... To už třeba ten LINQ, HaskellDB nebo CL-SQL/LOOP syntaxe, než si hrát na něco, co neexistuje. Nebo použít pořádnou objektovou databázi, jako AllegroCache.

S databází pracuje ve třívrstvém modelu datová vrstva (řekněme DAO). Takže v podstatě mohu říct: ne business logika nepracuje s databází. Pracuje s datovou vrstvou (která vůbec nemusí mířit jen do databáze). Proč zvolit třívrstvý model si najděte už sám.

Ani se pak nedivím, že nechápete důvody pro vznik ORM.
Při zběžném pohledu na AllegroCache - kdopak s tím asi bude umět pracovat? Kolik vývojářů a správců databáze. Navíc je to úplně zadarmo, že :)

Ono totiž když mě naštve jeden databázový server, mohu s Hibernate snadno přejít na jiný. Nabídnout zákazníkům verzi na komerční databázi nebo nějaké otevřené variantě. Nikdo mi taky nebrání použít stále SQL a využít tak plně relační databázi. V čem podle vás spočívá to uříznutí dobrých vlastností obojího?

LINQ v .NET není pejsek a kočička?

Uvidíme co přinese z hlediska syntase Java do budoucna. Já bych naopak nerad, aby toho přinesla tolik co .NET (například closures). Generiky by chtěly asi ještě dokopat.

LINQ pro mě (ještě jsem ho moc nestudoval) toho moc nepřináší. Jak znám MS dobroty, tak to bude vhodné pro téměř školní příklady a na reálném projektu se to ukáže jako betonová zeď.

"Hibernate a podobné ORM nástroje jsou sice fajn, ale LINQ je integrovaný na úrovni jazyka."

A Common Lisp umožňuje napsat si LINQ za víkend, ostatně právě proto některé lispové knihovny pro přístup k databázím měly něco podobného už před lety. A co má být?

A moc to MS nezvládl. Místo toho, aby věci co jsou dobré a zažité převzal (třeba slovo deprecated když už jste ho použil, vymyslí si vždy něco "zajímavého" vlastního - slovo obsolete). Balíky navržené v Javě mi vyhovují. Namespaces v .NET jsou běs. Partial class, metody označené jako virtual a override, neexistující povinnost odchycení výjimky a řada dalších problémů s data bindingem na které denně narážím mi jen cuchají nervy. O Visual Studiu 2008 a Team Foundation Server ani nemluvím. Je to zralé na kompletní přepis. Java má své problémy a opravdu některá api jsou zastaralá, ale celkově je pro mě použitelnější.

Javě mohu navíc přičíst obrovské množství otevřených knihoven a velikost celé komunity. Ono si stačí porovnat výsledky hledání v googlu při řešení konkrétního problému. U .NETu často najdu MSDN, které je mnohdy opravdu nepoužitelné a pak pár žbleptů.

Kdyby byl MS chytřejší, tak se poučí spíš ze Smalltalku než z Javy a pak nemusí řešit věci typu "exntension methods", což mi přijde jako šílený hack. Nakonec je z pěkného a čistého jazyka dort pejska a kočičky. ;/ Ale javoidní jazyky se líp prodávají managorům, to je ten problém. ;/

Javu mám opravdu rád. Tak ať je to klidně cítit. Svět mimo javy ale stále vnímám. Myslíte, že jsem přišel k programování až s Javou?

Slovo obsolete bych klidně přežil, kdyby mi okamžite VS nenabídlo jako nápovědu k takové metodě, že je deprecated :). To slovo jsem použil jen jako příklad něčeho, co si mohl .NET z Javy vesele ponechat.

V Javě neexistují pravé namespaces? Třída že je silně svázána s namespace? To příliš nechápu. Obdobou namespaces jsou v javě packages. Vazba třídy a namespace a třídy a package mi přijde naprosto identická. Pouze Java měla ten rozumný nápad, že balíku bude odpovídat adresář a třídě soubor a já jsem za to rád. Co je podle vás "pravý" namespace?

Panický strach z volnosti jsem získal na projektech, kde pracuje více než 20 lidí, kteří dostali onu volnost.

Neexistující povinnost výjimky bych tak snadno neoznačil jako za správnou vlastnost. Lidi jsou prostě líní výjímky odchytávat a něco s nimi dělat, že? Pokud vás to omezuje, používejte RuntimeException a nevykládejte pohádky o omezování. Jste asi prostě lajdák, kterého nebaví přemýšlet co s nastalou výjímkou. Pak prostě výjímky zrušte úplně a máte klid. Ale když to tak snadno smetete ze stolu, jak asi podle vás zjistíte v nějaké chabě dokumentované knihovně v .NETu jáká výjímka může z volání jedné metody na vás vyskočit? Mám celou knihovnu dekompilovat a lovit?

MSDN má dobrou vlastnost - vše na jednom místě a pohromadě. Kvalita informací však někdy kulhá a struktura dokumentů by si zasloužila překopat.

Já za nápad svázat namespace s adresářem a třídu se souborem opravdu za dobrý nepovažuji, nelíbí se mi, a jsem rád, že Java v tomto zůstalo osamocena. Asi není náhoda, že toto nepřevzal žádný jiný programovací jazyk - a i to o něčem svědčí - co si o tom myslí "nejavovský svět".

Velmi podobné principy (i když trochu volnější) má i např. Python a spousta programátorů je dodržuje i pokud to není nucené jazykem (např. Qt a na něm postavené KDE, Gtk+ a GNOME a tak dále a tak dále). Java v tomhle rozhodně není sama, i když je trochu extrémní. Navíc takové řešení velmi usnadňuje hledání problému: pokud potřebujete najít definici nějaké třídy, ať už kvůli dokumentaci (slušný programátor napíše u definice Doxygen nebo podobnou dokumentaci) nebo importu (includování), víte přesně, kde se nachází a nemusíte mít kvůli tomu spuštěné žádné IDE nebo spouštět hledání.

A co ti na tom proboha vadi? Vzdyt je to naprosto postacujici "vyjadrovani schopnost" - typicky mas namespace typu treba "com.firma.projekt.major-verze.trida", coz staci pro 99.9% vsech projektu ;-)

Vše ostatní co píšete je jenom z nouze ctnost - obhajoba něčeho, co jinde nikdy neobstálo.

Netvrdil bych o systému, který ač není vyžadován jazykem, se přesto běžně používá, že neobstál.

Píšete osekané možnosti. Jaké jsou tedy možnosti Pythonu při práci s namespaces a jaké je praktické využití? Zatím to vídím tak, že Java má pravidla, která mi neubírají možnosti. Jestli vidím v Javě v něčem problém, tak je to hierarchie (nebo spíš neexistence hierarchie) v balících. Ale to není o svázání balíku s adresářem.

Nesnášenlivost? Tu máte asi vy proti Javě. Jediné po čem tu já střílím je .NET (resp. C#) což je něco velmi podobného Javě, jen z mého pohledu nepovedené (na to, že to vznikalo se zkušenostmi s fungováním Javy). Neříkám že nepoužitelné, ale s tím co jsem napsal v závorce je to nepovedené.

Uznávám, že slovo obsolete jsem skutečně moc netrefil. ale za zbytkem si docela stojím.

I to Visual Studio vám vloží třídu do namespace podle adresáře. To že potom při refactoringu, kdy se třída přesune mezi adresáři nezmění namespace já považuji za nehorázné a nekonzistentní. Ať tedy žádný namespace při vytváření třídy nedává vůbec.

Sám si odporujete - volnost a pravidla. Tvůrci Javy pochopili, že je potřeba stanovit pravidla tak, aby už samotný jazyk pomáhal udržovat pořádek v projektu. Nechápu co vám může vadit na svázání package a adresáře. Když mi někdo řekne, že je to v balíku org.hlupák.trouba tak okamžitě vím, kam mám jít a kde třída bude. Nechápu v čem to někoho omezuje. Také jste napadal, že Java nemá pravé namespaces. A já stále čekám v čem to tedy spočívá. Oproti tomu, když v ostatních jazycích může třída ležet kde chce a mnohdy (.NET je opět černou ovcí) i ve více souborech (návrat k C++ ? ) tak opravdu děkuji, ale nechci. Nejdřív vám vadí pravidlo Javy, ale pak říkáte, že na projektu s 20 lidmi je potřeba stanovit pravidla. Java v některých směrech myslela na vývoj velkých projektů, ale podle vás je to špatně.

Totéž platí o výjímkách. Sám říkáte, že je zpracování výjimek důležité. Java se k tomu postavila čelem a proto nutí člověka nad výjimkou přemýšlet. A protože existují výjimky, na které nelze vhodným způsobem reagovat, zavedla RuntimeException. Tím způsobem si můžete při tvorbě vlastní knihovny vybrat, jestli se budete chovat jako ostatní jazyky a nebudete vyžadovat odchycení výjimky nebo budete kapku přemýšlet a budete vyhazovat na vhodných místech výjimky, na které je potřeba reagovat.

Asi se však zbytečně námáhám, protože vskutku budete lenoch. Java API na většině míst nevyhazuje RuntimeException (Tu jsem doporučil pouze vám jako lenochovi, který nehodlá k výjimkám přistupovat zodpovědně. Sám bych jí ve své knihovně používal pouze na místech k tomu určených) a proto se mi totéž co v .NETu nestane.

Já slovo dokumentace znám, ale vy asi nežijete v reálném světě. Ony všechny knihovny mají ty dokumentace ve skvělém stavu. Java byla navrhována jako bezpečný jazyk (nesoudím na kolik se to povedlo), tak to prosím zkuste pochopit. Zpracování výjimky není pouze o dokumentaci. Já si to mohu v ní přečíst, ale to mě vůbec nenutí na ni reagovat. Java udělala krok dál, výjimku považuje za tak důležitou situaci v programu (což považují i ostatní jazyky, které výjimky mají - proto je zpracovávají jiným způsobem než běh celého programu), že nenechá programátora spoléhat na nějakou DOKUMENTACI DOKUMENTACI DOKUMENTACI.