DŮLEŽITÉ UPOZORNĚNÍ!
Policie České republiky a šéfcensor Ústavu pro studium totalitních režimů Jaroslav Čvančara varují: citovat jakékoli texty z tohoto blogu způsobuje vážné nebezpečí trestního stíhání! Četba na vlastní nebezpečí!

26. 1. 2014

Java aneb Z růžové knihovny programátora

Zdálo se, že to bude Haßliebe na celý život, a možná to nakonec bude jinak.

Když jsem se koncem loňského roku rozhodl, že se konečně naučím Javu, skončilo to nezdarem, tak jako všechny předchozí pokusy. V učebních textech, které jsem používal, se o Javě hovoří jako o tom nejskvělejším počinu lidstva od vynálezu polohrubé mouky, a když jsem si spustil běžnou javovou aplikaci, zjistil jsem, že – minimálně na Linuxu – soudruzi z Oraclu udělali kdesi chybu, případně jim zapomněli říct, že některá písmena mají onu ošklivou vlastnost, že nekončí na účaří, a je dobrým a pereniálním typografickým zvykem zobrazovat i to, co je pod čarou ponoru. Java je propagována jako kompatibilní na všech platformách, tudíž předpokládám, že se stejně projevuje všude…

Ačkoli běžně studuji nové věci se zaujetím a informace absorbuji velmi rychle, v tomto případě skončil milostný vztah rozchodem hned zkraje. Přispělo k němu i to, že jako mnoho jiných z mé generace nemám příliš dobrý vztah k objektově orientovanému programování (OOP), a pokládám ho za modní výstřelek konce 80. let, který z nějakého důvodu opomněl odeznít. Ačkoli jsem čas od času donucen něco v objektech naprogramovat nebo upravit, nečiním tak nikdy s potěšením, jsa přesvědčen, že neobjektově by se to samé dalo napsat mnohonásobně jednodušeji a efektivněji. Vrcholem této nelásky bylo, když jsem cca před 7 lety upravoval pro své potřeby skripty MediaWiki, psané objektově v PHP (které také nemiluji, od doby, co jsem v něm byl kdysi nucen vytvořit redakční systém Britských listů). Nepřehlednosti a programátorská zmatenosti, tvé jméno je MediaWiki!

Javě jsem arci dal ještě jednu šanci, a to ve svém retro-programu, hlavně z toho důvodu, že pokud chci vytvořit software, který bude multiplatformní, mnoho jiných možností se mi nenabízí. Zpočátku to drhlo, např. když jsem zjistil, že optimalisátor z nějakého důvodu odmítne zoptimalisovat switch s velkým počtem variant a aby vůbec začal fungovat, musí se vše rozdělit do method.

Po několika dnech programování se ale ukázalo, že Java pro tuto aplikaci není vůbec tak špatný nápad. Vyloženě jsem si ji zamiloval ve chvíli, když jsem potřeboval implementovat chování podpůrných obvodů v osmibitových počítačích. Tyto obvody (např. 8251, 8253 a 8255) jsou velmi universální a je obtížné zachytit jejich chování čistě procedurální, resp. funkční cestou, a ani klasický event-driven přístup není to pravé.

OOP mi umožnilo vytvořit obecný model, kdy spolu jednotlivé propojené prvky počítače komunikují posíláním zpráv, jejichž formát jsem díky podpoře abstrakce dokázal v Javě vytvořit dostatečně obecně a zároveň robustně: je-li prvkem vodič, je zpráva tvořena informací o tom, zda na něj zařízení posílá nulu, jedničku nebo je ve třetím stavu, periferní obvod komunikuje s procesorem přes porty posíláním jednoho bytu, když budu implementovat disketovou jednotku, může být ve zprávě obsažen celý sektor apod. Jednotlivé objekty, představující prvky hardwaru, postačí propojit tak, jako jsou propojeny v emulovaném počítači, o zbytek se postará Java. Mohu dokonce nechat vypisovat situace, které svědčí o chybě v programu emulovaného stroje, např. že dvě zařízení se snaží táhnout jeden a ten samý pin (v horším případě každé jinam) nebo se naopak čte pin, na který neposílá data žádné zařízení.

A podobně přívětivou se Java ukázala i k propojení GUI s koncovým hardwarem: stisknutí klávesy na klávesnici počítače PMI-80, který emuluji jako první (chtěl jsem, pravda, začít PMD-85, ale tento klenot jsem prostě nemohl opominout), propojí switch v matici, což způsobí, že modul klávesnice bude po předvolenou dobu – počet cyklů mikroprocesoru – reagovat na zprávy o změně úrovně na výstupu skenovacího demultiplexoru, případně přímo na skenovacím pinu 8255 příslušnou zprávou na čtecí pin. Podobně strobované mody obvodu 8255, které přesně emulovat není snadné, se rozdělením na jednotlivé bity a abstrakcí vyřeší jako zázrakem. Potřebujete naemulovat řadič přerušení Intel 8259? Po bitech hračka!

Takto si mohu po libosti sestavovat i přídavný hardware, který původní počítač nemá (např. tuto desku I/O), a po připojení na příslušné piny mi bude vše fungovat samo od sebe, a to samé zařízení mohu připojit např. i k emulátoru Atmel AVR, jediné, co se změní, je zapojení/přiřazení pinů.

Tedy se zdá, že můj vztah s Javou bude nakonec konsumován.

PS: Jakmile bude emulátor funkční, vystavím ho, včetně zdrojového kodu, ku potěše dalších elektro-nostalgiků.

Aktualisováno.

Pomalu se chýlím k závěru, avšak žádná zvláštní infatuace ve vztahu k Javě se nedostavila. Někdy je práce s ní příjemná, třeba když kompilátor najde ve zdrojáku daleko víc chyb než kompilátor C/C++, ale několikrát se mi stalo, že si javac stěžoval na možnost použití neinicialisované proměnné v situaci, kdy z logiky algorithmu vyplývalo, že taková eventualita je nemožná.

Rozpačitý jsem rovněž ze Swingu, který, jak jsem pochopil, se v Oraclu chystají nahradit dalším API, Java FX. Měnit každých pět let API pro GUI nesvědčí o tom, že by firma příliš dobře věděla, kam chce dojít.

Aplikaci PMI-80 mám naprogramovanou ve třech jazykových mutacích (ovšemže nemohla chybět slovenština, jde přece o slovenský stroj!) a čtyřech velikostech, základní framy jsou v absolutních posicích, což by mělo vyloučit většinu problémů. Naprogramoval jsem bohatá rozhraní pro práci s daty, v XML, binárních podobách i všech používaných formátech pro pásek i paměť (a zvažuji, že budu podporovat i ELF, kdyby chtěl někdo překládat GNU Assemblerem). PMIčko funguje hladce a rychle, stejně jako magnetofon. Ještě musím dokončit debugger a vyřešit několik odložených bugů, týkajících se vesměs potíží se Swingem, a poté vygeneruji versi k distribuci a zvážím, zda by mělo smysl upravit program i do podoby appletu.

25 komentářů :

  1. Mám takový dojem, že jsem předmět Vašeho emulování viděl naposledy na cvíkách na FEL, no, pár let už to asi bude…
    Jinak – no to je prostě paráda! Vy si tak s těmi objekty bastlíte, páječky ni kalafuny nemaje! Tiše závidím a vracím se ke svému hloupému importnímu filtru v PHP, coby obživě.

    Quidofil

    OdpovědětVymazat
    Odpovědi
    1. Já si na něj vzpomínám jen matně, kdesi jsem ho měl možnost používat, ale nikdy jsem ho snad ani nezapnul. Podobně SDK-85, originál od Intelu, s krásnými bílými tlačítky. Vždy jsem si vystačil s možností spustit v cílovém zařízení monitor a nahrávat programy po seriové lince (RS-232C, ale s TTL úrovněmi) přímo do něj.

      Vymazat
    2. Člověk se vyblbne i s takovými hračkami jako je authentický retro kasetový magnetofon. Jen nevím, zda bych pro zvýšení authenticity neměl softwarově generovat nahodilé kolísání rychlosti posunu pásku, ale to by uživatele asi retro nálada rychle přešla! :-)

      Vymazat
    3. :-) Kdepak! Zlatá analogová technika. Ty dnešní digitální krámy jsou studené, jak psí čumák.
      Já třeba fotografie, které fotím ze záliby (tedy nikoli na kšeft) požizuji buď na 6x6 barevné diapozitivy a nebo, a to je opravdová lahůdka, na černobílý kinofilmový diapozitiv (Foma stále vyrábí, bohužel ale ne ve svitku). Samozřejmě v manuálním režimu. Je to radost.
      Předtím jsem své retro touhy kojil stavbu napájecího zdroje (s výkonovými vakuovými diodami AZ4) a nízkofrekvenčního zesilovače ve třídě A, též s elektronkami.
      Ta stará doba má takové kouzlo opravdovosti. Myslím, že bylo běžné jít daleko více k jádru věcí.

      Quidofil

      Vymazat
  2. S PMI-80 se mi vybavily vzpomínky na mládí. Ten krám jsem dovedl programovat přímo v haxakódech - tedy znal jsem zpaměti většinu nejčastějších instrukcí a do programů jsem tu a tam vkládal pro jistotu i tři byty NOPů, pro případ, že bych potřeboval drobnější úpravu.
    Vy jste nebezpečný člověk, před časem jste laškoval s arduinem a teď tohle.
    Za všechno ale může liknavá státní správa - kdyby byli rychlejší v projednávání kauz, měl byste méně času na tohle.

    OdpovědětVymazat
    Odpovědi
    1. Možná vás to překvapí, ale mezi 40 let starou 8080A a Atmelem AVR v Arduinu jsou jen zanedbatelné rozdíly. Hodinová frekvence je vyšší asi jen o řád a instrukční sada je ve většině ohledů analogická, dokonce i mnema některých instrukcí se shodují.Modernější je možnost zapsat program do Flash paměti (ty tehdy neexistovaly) a integrace I/O obvodů, což se řešilo externími 8255 apod. (ale už 8048/51 je měly, takže tam je podobnost ještě výraznější).

      Vymazat
    2. Ale jo, věřil bych tomu, tyhle jednodušší procesory budou ještě zvládnutelné. Pamatuju ještě dobu, kdy člověk napsal program v céčku a pak se podíval, co mu překladač vygeneroval za kód (pro 286). Když se cítil, mohl zkusit do assembleru zasáhnout. Mnohdy si i pomohl, v nejhorším se aspoň něco naučil. Jenže od jisté doby to prakticky nešlo i kvůli komplikovanosti.
      Ale tohle už mě tolik nemrzí, holt technika pokročila a v assmbleru na výkonnějších procesorech už se psát nebude, stejně jako necháváme na stroji návrh desky plošných spojů.
      Co mě ale mrzí, je naprosté fiasko v oblasti, o které jsem se domníval, že naopak poroste. Na mysli mám transputery a jazyk Occam. Hardware už se nedělá desetiletí a jazyk v Kentu sice vyvíjeli i bez INMOS, ale přesto zůstal širšímu okruhu lidí naprosto neznámý. Tehdy jsem si myslel, že budoucnost bude patřit čistému paralelismu a Occam je tak přímo stavěný. Místo toho se vylepšila Pentia a PC a jazyky i OS dostaly pár nástrojů na řešení synchronizačních problémů.
      Jenže, uznejte sám - může příkaz fork se vší tou agendou kolem nahradit eleganci klíčového slova PAR?

      Vymazat
    3. Ad 1: Záleží na tom, co píšete. Když jsem před půldruhým rokem psal (z čiré nudy) solver na solitaire v C, několikrát jsem si nechal assembler vygenerovat (gcc -S) a studoval ho z hlediska provedených optimalisací.

      Ad 2: Paralelismus se přece rozvinul, i nejlevnější grafická karta má nejméně 64 stream procesorů a supercomputery mají tisíce procesorových jader. Jiná otázka je, že se z výkonu dnešních počítačů využívá stále méně a méně. Už v době osmibitů bylo zatížení procesu něčím jiným než čekací smyčkou někde na procentu, a dnes, pokud připočteme zahálející výpočetní výkon v grafikách, jsme ještě o několik řádů níž.

      Vymazat
    4. Přece jen to šlo jiným směrem, než jsem si tehdy myslel. Hlavně se ukázalo, že principiální paralelismus se užije maximálně v OS nebo pár specializovaných aplikacích (samozřejmě grafické karty), ale jinak se rychlost dožene hrubým výkonem. Až na naprosté výjimky se nikdo nestará o optimalizace aplikací, natož se drbat s analýzou.
      Proto možná ta nostalgie po 8bitech s omezením paměti, rychlosti a základní instrukční sadou, kterou lze po pár dnech používat poměrně přirozeně.

      Ještě další dvě oblasti jsem přecenil. Obojí se týká de facto her (ačkoliv nejsem hráč). První jsou 3D brýle - čekal jsem jejich rozšíření kolem roku 2000. Druhou pak fyzikální modely. Důvod, proč mne hry nikdy moc nechytily, byl nerealistický fyzikální model. Čekal jsem, že se objeví specializovaný HW a knihovny podobné OpenGL. HW se sice objevil, ale neujal se a nějak to celé zhaslo.
      Člověk aby se pomalu obával se o něco začít zajímat, aby to zákonitě nechcíplo :-)

      Vymazat
    5. Ono je strašně složité paralelní systém programovat, a i příroda při konstrukci mozku vycházelo spíš z modelu centrálního CPU a řady specialisovaných koprocesorů. Člověk má v hlavě obrovskou výpočetní kapacitu, a přesto nedokáže myslet současně na víc než jednu věc (např. nelze řešit dvě mathematické úlohy naráz, nebo číst současně dvě knihy).

      Vymazat
    6. Jen pro zajímavost, o paralelismus jsem se zajímal právě v souvislosti se solitairem. Je známo jedno rozložení, o kterém nikdo neví, zda je – s určitým počtem volných polí – řešitelné. Všechna ostatní známá rozložení umíme buď vyřešit, nebo prokázat jejich neřešitelnost. Při řešení jde samozřejmě o klasické prohledávání grafu. Měl jsem v úmyslu využít paralelní zpracování v grafické kartě, ale zjistil jsem, že v mé je pouze 128 (ne-li 64) procesorů, takže bych si příliš nepomohl, a myšlenku jsem zavrhl. Kdybych měl kartu s (řekněme) 1024 procesory, už by to mělo smysl.

      Vymazat
    7. Možná by vás k tomu paralelismu mohlo zajímat: v té "vrstvě" o které tu diskutujete mi programování níkdy nezajímalo, ale pracuju (a bavím se) poslední dobou v Objective-C (pro iOS) a tam jsou prvky paralelního programování stále prominentnější. Prostě vytváříte úlohy (NSOperation) a posíláte je do fronty (NSOperationQueue). Nebo můžete procházet array tak že napíšete blok a ten se vykoná pro každý prvek arraye s tím že pokud chcete a systém běží na vícejádrovém procesoru, tak i parallelně (NSEnumerationConcurrent option). Ostatně i "metodám" se se v Objective-C správně říká messages.

      https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html

      Vymazat
    8. Pro mě je iPad jedna velká záhada. Na jednu stranu moc hezký HW, stabilita a poměrně funkční SW, na straně druhé naprostá a pro mě nepochopitelná rigidita a nemožnost tu placku používat jinak, než bylo naplánováno soudruhy u flipchatru. A to ji mám osvobozenou z vězení. Ty aplikace snad ani současně neběhají, až na naprosté výjimky.

      Vymazat
    9. Já se upřímně na toto téma nechci rozepisovat protože celý problém spočívá v něčem na způsob odlišnosti kultur. Nejsou to - pro třetí strany - univerzální počítače. Jsou zaměřeny na koncového uživatele a na to aby fungovaly bezúdržbově. Já osobně jsem jako uživatel na nich žádné omezení nepociťval, asi proto že jsem od nich nečekal že budou něco jiného než jsou. Ani jako člověk který se zabývá vývojem aplikací - prostě je beru jaké jsou. Možnosti které nabízejí při vývoji aplikací jsou takové že mi ta omezení oproti univerzálním počítačům/systémům (která jsou časem, jak je u Apple zvykem a jak se zvyšuje výkon hardware, postupně snižována, resp. překonávána vesměs dobře fungujícím a inovativním řešením) připadají nepodstatná.

      Vymazat
    10. Pokud se týká toho paralelního běhu aplikací, mám zato, že to sice prakticky žádná nevyužívá, ale možné by to mělo být. Systém by to měl vnitřně umožňovat, ale GUI přímo nepodporuje. Jednou jsem si nechal stahovat mapy do navigace, ale jakmile jsem začal používat prohlížeč, stahování se zastavilo.. to je absurdní, muset mít na GUI stahování, aby se stahovalo.
      Existuje rozšíření, které umí aplikace provozovat v oknech, ale zase to má jiné nectnosti. Proto mě překvapuje zmiňovaná paralelizace na úrovni prvků pole. Pochopil bych to u Mac OS, ale v kontextu iOS to budí spíš úsměv.

      Vymazat
    11. Systém jako takový pochopitelně paralelní běh aplikací umožňuje, je postaven na Unixu, resp. BSD. Neumožňuje je pouze pro instalované aplikace třetích stran.

      To že před verzí iOS 7 nebylo v aplikacích možné stahování na pozadí byla pro některý typ aplikací opravdu nepříjemnost. Aplikace se nicméně nicméně jasně dozví že bude suspendována a proto kdo o stál mohl a měl aplikaci naprogramovat tak aby uměla navázat na přerušené stahování, případně uživatele přri stahování upozornit že holt musí projednou tu minutu počkat.

      Postoj Apple je jasný: nic co není vidět si nemůže dělat co chce. Ani to nové stahování na pozadí neznamená že vaše aplikace celou dobu běží: pouze je stahování předáno systémové službě která aplikaci informuje o průběhu, a v případě že je aplikace suspendovaná ji po stažení těch dat na omezenou dobu na pozadí probudí aby si ta stažená data zase vzala k sobě.

      Paralelismus na malých zařízeních má velký smysl: umožňuje nejúčiněji alokovat zdroje podle hardware na kterém to zrovna běží, a neblokovat UI když to není třeba. Apple ho do iOS netlačí náhodou.

      Ale jak jsem psal, jde o to jak k tomu člověk přistoupí, jestli se šroubovákem že to bude vylepšovat aby to dělalo co si myslí že to přece musí dělat, a nebo jako něčemu co má svoji vnitřní logiku, někam směřuje a umožňuje spoustu skvělých věcí jak je.

      Vymazat
    12. Já samozřejmě zhruba vím, co je jádrem iOS a do určité míry chápu i to směrování - bombenfest a idiotsichr pro největší lamy. Jenže občas udělají chybku i soudruzi od jablek a pak je horko.
      Např. příklad z poslední doby: nainstaloval jsem si iTunesU a postahoval několik přednášek. Ty jsem si pak pouštěl offline. Nato jsem je smazal a chtěl si stáhnout další sadu... ale nešlo to pro nedostatek místa. Napřed jsem pomazal pár věcí, ale pak mi došlo, že to jsou drobnosti a problém bude hlouběji.
      Takže pustit iFile a omrknout, co se děje. No a podle očekávání, těch 15 videí z iTunesU zůstalo prostě viset a nesmazalo se. (Mimochodem, je docela chuťovka zjistit, o které soubory se jedná, ta nadstavba nad ext3 a klasický unixový filesystem je čistá úchylárna) Opravdu nevím, co by s tím dělal člověk bez šroubováku. Možná to později opravili, možná ne, já jsem zůstal u osvobozeného iOS 5 a na ver. 7 přecházet nehodlám, dokud k tomu nebude vážný důvod + spolehlivý JB.
      Štve mě, že tak hezký a povedený kousek HW je uměle degradován na lepší terminál a člověk není schopen provádět základní usecasy typu "tady mám videjko, nahrej si ho k sobě" atd.
      Dovedu přijmout tezi, že současný stav je bezpečný pro výrobce a přijatelný pro nadpoloviční počet uživatelů. Neplatí to ale pro všechny a silná komunita kolem JB je toho důkazem. Bohužel, kromě zpřístupnění pár částí OS se toho nedá moc udělat a slot na kartu tam prostě softwarově nedostaneme :-)
      Nic ve zlém, iPad považuju za dobré zařízení, jen mě o to víc rozčiluje jeho umělá degradace.

      Vymazat
    13. Existuje skupina vtipů na téma "co by se stalo kdyby..." a jedna varianta se týkala případu, kdyby Apple vyráběl automobily.

      Možná ale bylo krátkozraké se takovým věcem smát:
      http://www.lidovky.cz/reditel-automobilky-tesla-potvrdil-jednani-s-applem-f9a-/auto.aspx?c=A140223_181942_ln-auto_jzl

      Vymazat
    14. Já si spíš pamatuju tu variantu, kde automobily vyráběl Microsoft:
      Zastavovat vůz se bude tlačítkem Start, občas bez důvodu úplně vypne motor a zastaví, když ho dáte na diagnostiku, diagnostický protokol vyplivne hlášku, že "něco způsobilo pád systému"....
      Vyvolal to tehdy Gates svým prohlášením, že kdyby Microsoft vyráběl auta, stála by asi 100 dolarů. A ředitel GM mu takhle nějak odpověděl....

      Vymazat
    15. Já zase říkávám, že kdyby právníci stavěli most, vypadal by jako ten v Avignonu: zbytek řeky by překlenuli výkladem.

      Vymazat
  3. Podívejme na Solitaire - člověk to považuje za klíčovou aplikaci úřednic státní správy a ona to nakonec může být i zábavná věc.

    OdpovědětVymazat
    Odpovědi
    1. Právě. Také mne zaujalo, co na něm ty úřednice tak fascinuje, a po 4 500 řádcích solveru v C to, myslím, chápu.

      Vymazat
    2. Před časem jsem si dělal prográmek na sudoku. Manželku to nějak chytilo a rejpala, že to je na mě moc složité (a ne že je to nuda, jak se snažím tvrdit já). No tak jsem nakódoval jednoduchý algoritmus a pár těch tabulek z toho časopisu tím prohnal. Měl jsem to za vyřešené, ale kdepak s programem na tuhle alternativní logiku! Ony ty tabulky jsou prý každá jiná a chce to fištrón... a ne nějaký trapný algoritmus.
      Je ale pravda, že zajímavé by to mohlo být. Ovšem až v případě, kdy by se např. rozhodovalo o počtu řešení bez užití hrubé síly. Ona by byla konec konců zajímavá i přebíjená, kdyby algoritmus neprováděl kola hry, ale místo toho rozhodoval o vítězi na základě např. grupové algebry.
      Jenže takové úvahy nahlas vyslovené spolehlivě otráví všechny karbaníky a posilují ty nejošklivější předsudky.

      Vymazat
    3. To máte naprostou pravdu. Většina lidí nechápe, co je skutečně zábavné!

      Vymazat
  4. To je ten Váš linux... tam všechno vypadá divně... Kdybyste měl Windows, tak byste viděl....
    Petr V

    OdpovědětVymazat

Kursiva: <i>text</i>
Tučně (když už to musí být…): <b>text</b>
Odkaz: <a href = "http://adresa">název odkazu</a>, tedy <a href = ""></a>

Poznámka: Komentáře mohou přidávat pouze členové tohoto blogu.