Autorem blogu je 
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.
Komentáře
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
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
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.
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?
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íž.
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
developer.apple.com/.../Introduction.html
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.
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.
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.
Možná ale bylo krátkozraké se takovým věcem smát:
lidovky.cz/.../...
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....
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.
Petr V
RSS kanál komentářů k tomuto článku