Hlavní navigace

Názor ke článku Co mě se_e na programování od VSimon - Máte úplnou pravdu, zcela souhlasím. Ono, nechť to...

  • 8. 9. 2014 18:28

    VSimon

    Máte úplnou pravdu, zcela souhlasím. Ono, nechť to autor přijme jako konstruktivní, byť je to od člověka, který "tahal kačera v době, kdy on už programoval (pro) MacOS", ale:

    1) Java vznikla v roce 1998, takže má své nedostatky, které se bohužel ukázaly až časem a s nimi v rozjetém vlaku toho už mnoho nenaděláte, když jsou hotové aplikace. Viz například JAR balíčky a jejich verzování. Hotová lahůdka udržet to v nějakém souladu a přehledu. Program složený z komponent třetích stran, kde jedna využívá verzi 1, druhá verzi 2, třetí verzi 1.1., atp.. Zkrátka Windows má DLL hell, Java zase JAR hell, bohužel, nemůžu si pomoci. Ostatně i proto v Javě programuji jen velmi nerad a jen, když se jí nemůžu vyhnout.

    2) Persistence opravdu funguje v řadě jazyků, možná to chce jinou technologii, která toto podporuje. I když, řekl bych, že i Java už tohle podporuje.

    3) Pokud jde o SQL databáze a manipulace s SQL daty, zajisté jste slyšel o (dynamicky generovaných) objektových datových rámcích, například nHibernate. Má sice svou značnou režii, ale nebudete se muset tolik dřít s funkcemi, objekty mapujícími DB tabulky, atd. Vše byste "tahal" a tvořil v diagramu a framework by se postaral o tvorbu na pozadí. Režie u NHibernate je (aspoň svého času byla) sice značně velká, ale používat se dá, když to ušetří práci.

    Vy, programátoři v Javě, jste na vyšší paměťové nároky svých aplikací dozajista zvyklí. Kromě Data Manageru od Oracle jsem totiž neviděl žádnou, z hlediska práce se zdroji, efektivně napsanou aplikaci. Sotva se nahraje do paměti, hned máte minimálně 128 MB zabraných. Co to je? U .NETu je to obvykle u srovnatelné aplikace tak 1/4 tohoto, ale dá se s tím fungovat.

    Pokud jde o SQL databáze, nečekejte, že se budou zásadně měnit. Jsou tu už dobrých 30 let nejméně. Rozšíření? Možná. Zásadní změny? Nepravděpodobné. Jestli se Vám nelíbí SQL databáze, zkuste noSQL databáze (http://cs.wikipedia.org/wiki/NoSQL), ale i tam, obávám se, budete aspoň někde potřebovat SQL. A ve výhyn SQL databází nedoufejte, nanejvýš ustoupí do menšiny oproti noSQL, ale ani to se možná nestane. Poměr obou typů bude podle mě někde 60 : 40 ve prospěch standardního SQL.

    Pokud jde o tvorbu struktur, tak to je nezbytnost. Jak si to vlastně představujete? Že ta DB bude sama detekovat, jestli to a to mohu převést na číslo nebo datum? Jak pozná ze řetězce binární obsah? Jak pozná rozsahy datového typu? To je bude měnit pokaždé, co tam něco dáte? A když budete dávat různá data různých struktur, tak se bude rozšiřovat počet polí a dodávat NULL tomu, co zrovna v těch datech není nastaveno? Nereálné. Používejte tedy v takovém případě serializaci. MS.NET ji umí a Java taky. Pokud jde o SQL databázi, můžete použít i nějakou embedded - SQL Lite a podobně. Tam si tvořte, co jen chcete a protože je to souborové, dá se to i pohodlně smazat diskovou operací, až budou uzavřené handlery, vynulované pointery a uzavřená spojení.

    4) Networking: tady není pomoci, Java je prostě Java a má řadu svých specifických tříd (.NET to má stejné) dědících z jedné nadřízené. Možná zkuste zvážit, zdali by nebyla použitelná ta nadřízená s pomocí přetypování. Nevím, jak postupujete, těžko se pak radí. Pokud Vám vadí testy na vyjímky, těm se také nevyhnete (nejen v Javě, ale kdekoli), má li program správně fungovat. Nevím, zkusil jste si třeba vytvořit třídu s proměnnými a specifickými get metodami, kde byste si podobné věci (sken po zařízeních, pamětech, heapu, atp.)? Napsal byste to jednou a revyužil v budoucnu v jiných projektech a měl byste později půl práce.

    5) Tahání dat místo tlačení:
    Pokud jde o dotazování, už nevím jak to bylo v Javě, ale v .NETu máte možnost "připojovat" funkce objektů na delegáta se shodným funkčním předpisem a poté, když objekt něco provede, aktivuje delegáta a tím i všechny na něj napojené funkce z cizích objektů. O vzoru Observer jste zajisté už musel slyšet (dávno dříve, než my jsme začali tahat toho kačera :-)). Neříkejte, že v Javě nejde provést obdobná věc.

    6) To, že se v Javě dělají některé věci viditelně hůř než jinde, jak jste sám částečně naznačil, s tím se nedá nic dělat. Je to prostě jazyk, který byl ve svých začátcích na tu dobu převratný a často tehdy "dláždil" cestu jiným (například: MS.NET) a tím samozřejmě odkrýval nedokonalosti, slepé cesty, těžkopádná řešení, atp. To tak zkrátka je a každý jazyk/technologie se jednou přežije a musí nastoupit nová, která ty věci bude zvládat lépe a pružněji. To je vývoj.

    6) Existuje řada (dynamicky typovaných a třeba i skriptovacích) jazyků, například Python, který Vám vezme řadu "sv*nstev" a "nezjančí" se z toho, jako Java, která zkrátka všude potřebuje try ... catch, aby ustála případné problematické stavy. Případně můžete použít všeobecný Exception a tu vyjímku "zahladit" prázdným obslužným blokem a pokračovat dál. Sprosté a dělat se to nemá, ale program bude fungovat i dál.

    7) Jazyk nemusí být virtuální, vytvořte si svůj a udělejte všechny konstrukty tak, jak Vám vyhovují. Práce plno, běh na dlouhou trať a s každou verzí každého systému aby se to pomalu předělalo, ale pak budete spokojen. Pokud se do toho rozhodnete jít, klobouk dolů.

    8) Jak byste nahradil HTTP, SQL, JSON a DOM? Jsou nějaké náhrady? Kromě XML nebo XSLT specifikace a XML z ní?