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

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í?

Programováním se zabývám trochu kratší dobu, ale zřejmě jste se nezabýval programováním dostatečně.

1) Persistence přímo v programovacím jazyku funguje. Račte se pěkně prosím seznámit s programovacím jazykem Smalltalk, který pracuje podobně jak o tom sníte z hlediska persistence.

2) Networking přes (dokonce paměťové pointery) už je také řadu desetiletí vyřešený, a to technologiemi zvanými ORB (Object Request Broker). Například známá je CORBA, byť starší provenience. Ale stejně funguje třeba Windowsovské DCOM.

Nutno podotknout, že mikrokernelové operační systémy fungují na několika počítačích najednou, třeba na celé síti už z podstaty, a komunikace mezi počítači je naprosto přirozená. Kromě zastaralých konceptů, jako je monolitický Linux či trochu lépe navržené Windows, jde budoucnost spíše směrem mikrokernelu. Například QNX, wxWorks, Plan9, atd.

3) Ohledně tahání dat versus tlačení. Myslím, že za 28 let byste mohl pochopit naprostý základ, a to že existují imperativní programovací jazyky, kde to musíte tlačit, a pak procedurální programovací jazyky, kde se data sama táhnou. Počet imperativních a počet procedurálních programovacích jazyků je tak půl na půl.

Dále už jsem nečetl. Spíše mi přijde, že autor zná jen Javu a z toho usuzuje.

Chybí základy programátorských znalostí