Autorem blogu je 
Předpokládám, že úlohu, jež dala původ nadepsanému rčení, znáte: úkolem je spojit devět bodů uspořádaných do matice 3 x 3 souvislou čarou složenou z nejvýše čtyř úseček. Je řešitelná pouze tak, že úsečky leží mimo pravoúhelník vymezený danými body, ale najít řešení je pro většinu lidí obtížné, neboť intuitivně předpokládají, že úsečky musejí ležet pouze uvnitř pravoúhelníku – ačkoli zadání o tom ničeho nepravilo.
Stereotypy a automatismy v myšlení jsou zrádné, o čemž jsem se přesvědčil naposledy během uplynulého week-endu. Pojal jsem totiž úmysl, že pro svůj (na třetím blogu traktovaný) emulátor doplním emulaci mikroprocesoru Zilog Z80. To je, myslím, jediná elektronická součástka, kterou jsem v životě opravdu miloval, a i když jsem měl původně v úmyslu omezit se na tři emulované historické stroje – PMI-80, PMD 85 a IQ 151 – mít Z80 by mi umožnilo pojmout do emulátoru i počítač Ondra, který byl hardwarově velmi zdařilým dílem a jeho většímu rozšíření zabránila pouze pro praktické používání nevhodná, příliš ořezaná
klávesnice.
Domníval jsem se, že maje naemulovaný Intel8080A, nezabere mi doplnit instrukce Z80 než jeden, nejvýš dva dny. Jenže celý jeden den a spoustu nervů mi zabralo hledání chyby, kterou jsem nemusel udělat, kdybych nebyl myslel – v krabici.
Posuďte sami. Pro emulátory používám instruction exerciser (více o něm zde), který jsem si rovněž přepsal do Javy, abych mohl rychleji najít chyby implementace jednotlivých instrukcí. Pro 8080 žádný problém, ale u Z80 jsem narazil na chybu, kterou jsem nemohl a nemohl najít. Až poté, co jsem si zprovoznil emulátor CP/M, v něm druhdy slavný debugger DDT, a propadaje střídavě amoku a stavům chorobné skleslosti, jsem na to, co je problémem, nakonec přišel. A protože je to problém věru bizarní, dělím se o něj se svými milými čtenáři i zde.
Když si prohlédneme zdrojový soubor Franka D. Cringla z r. 1994, vidíme, že jádrem exerciseru jsou test cases, jejichž dlouhá řada jest popsána v makrech na ř. 194–728. Povšimněme si parametrů těchto maker: vyjma triviálních hodnot 0 a –1 jsou všechny konstanty (literály) zapsány hexadecimálně.
Až na dvě výjimky, na ř. 277 a 285, kde se stkví neobvyklý zápis 010
. Když jsem ho přepisoval do Javy, automaticky jsem napsal 0x08, domnívaje se, že Frank Cringle udělal chybu a mínil zapsat 0x10 a protože si neuvědomil, že assembler takto zapsanou konstantu vyhodnotí oktalově, vyšlo mu něco, co nechtěl, ale co je s ohledem na neměnnou hodnotu CRC nutno respektovat. Pro tuto hypothesu hovořilo i to, že je v závorce za voláním makra uvedeno (1024 cycles)
, což odpovídá počtu jedniček v řádku – tedy deseti.
Dlouhé hodiny jsem se pak vrtal ve svém kodu a pátral, co mám špatně, protože CRC ne a ne vyjít, jak mělo. Řešení bylo arci zcela triviální, ale tak outside the box, že mě stálo dobrých deset hodin času: Protože Cringle programoval v r. 1994 a assembloval v CP/M, předvěšená nula pro assembler neznamenala, že má konstantu interpretovat jako oktalovou: tehdejší softwarové nástroje to ještě nedělaly. Assembler proto vyhodnotil jeho zápis 010 jako 10 (dekadických); vedlejším důsledkem bylo, že ve skutečnosti se neprovádí 1024, nýbrž 2048 cyklů.
Jak se to celé stalo, bych mohli zjistit asi jen od Cringla, kdybychom mu napsali a pokud si to ještě pamatuje. Moje (upgradovaná) hypothesa zní, že původně měl 0x10, ale protože si uvědomil (nebo laděním zjistil), že by instrukce CPI/CPIR vyšla (o jeden byte) mimo rozsah testovacího pole, opravil hodnotu na deset, ale zapomněl smazat nulu a nenaznal, že se mu tím změnil i počet cyklů.
Já vím, chybami se člověk učí, jen by jich, pokud bych směl prosit, mohlo být o něco méně.
Komentáře
Assembler člověka naučí přidávat nadbytečné nuly před čísla, protože číslo nesmí začínat písmenem. Což je dobré pravidlo, kdyby do písmen nepatřily i hexadecimální číslice ABCDEF. Takže časem člověk rezignuje a píše nulu, pak číslo co chtěl napsat a na konec H jako hexadecimální číslo.
C-like syntaxe je zase plná artefaktů jako je nula na začátku čísla je oktalová hodnota. Nebo záporné kódy znaků v horní polovině ASCII. C je vysloveně šit na míru prvním unixům.
Miloslav Ponkrác
C oktalovou soustavu implementovalo, protože unixová práva na soubory a adresáře se zapisují v oktalové soustavě, tedy k tomuto se dodnes používá. A tak můžete třeba při vytváření souboru do práva napsat v oktalové soustavě jaká práva chcete pro vlastníka, jaká pro ... Kromě toho mám pocit, ale nevím přesně, že původní PDP-7 byla 18bitový počítač, takže oktalová soustava tam byla docela užitečná.
Mně připadá spíše směšné, že v jazyku C byla oktalová soustava, ale nebyla binární.
Pokud se vzdálíte ze světa inspirovaného Céčkem, které samo o sobě je neuvěřitelně zflikovaným jazykem, pak nuly na počátku jako oktalová soustava se nepoužívají. Považuji nuly jako indikátor oktalové soustavy za zvěrstvo.
Jako asm používám nasm (nasm.us), který je možné použít s každým myslitelným kompilátorem co znám, a tam nuly na počátku čísel jsou bezvýznamné. Stejně tak MASM, tedy asm od Microsoftu žádnou nulu na počátku nepřiřazuje jako oktalový indikátor. Jinak řečeno, ve všech assemblerech nula neznamená oktalovou soustavu s výjimkou Céčkoidního gasu.
GAS je céčkoidní asm vytvořený týmem gcc, a obsahuje částečně i Céčkové konstrukce. Java vysloveně převzala C syntaxi, a Python v některých výrazech také. Ostatně Python byl před lety představován jako glue language pro C.
Nula jako oktalová soustava je unixoidní nápad - a šíří se spíše stylem "co unix/linux dělá je nejlepší a pokud to neplatí platí pravidlo číslo jedna". Ačkoli mám unix rád, ale tato neschopnost unixu vylepšovat nedobře navrhnuté věci způsobuje (kromě toho, že dnes už většina unixů včetně linuxu neodpovídá unixové filozofii velmi malé jádro a zbytek user mode) že už se na unix neorientuji jako jedinou věc jako jsem dělal v minulosti.
Stejně tak SQL jazyk a databáze - ani v MySQL, ani v Oracle není 0 jako octal. Kdyby tomu tak bylo, vznikala by taková kvanta chyb, až by to hezké nebylo.
Novější jazyky zaplaťpámbu od nuly jako indikátoru oktalu ustupují. Například Lua ho nepoužívá, jazyk Swift od Apple také ne.
Miloslav Ponkrác
GAS je pozůstatek z tohoto procesu a sloužil právě pro překlad C. Nebyl určený pro lidi ani pro to, aby v něm někdo programoval. Proto třeba jeho makrovací schopnosti jsou velmi ubohé, prakticky žádné. Plus třeba pro x86 procesor si dokonce vytvořili nesmyslnou vlastní sysntaxi instrukcí. Na druhé straně je GAS dělaný pořádně, staré assemblery skutečně byly pro bastlení, ne pro programování.
Sám jsem v GAS psal pro ARM. Spolu se skriptem pro linker se z toho daly udělat neuvěřitelné věci a vytvořit v podstatě jakoukoli strukturu výsledného binárního výsledku. Pokud člověk opravdu chce dělat nezvyklé věci, tak věci kolem GCC jsou docela dobré.
Jen mám dost trauma z GPL a GNU programů, které tkví v neuvěřitelné složitosti a špatné dokumentaci open source programů kolem těchto licencí a hnutí. Když je chci využít, obvykle musím luštit jejich zdrojové kódy, abych pochopil, co vlastně v určitých případech dělají, jako třeba u toho linkového skriptu. A když pak čtu zdrojáky těch gnu a gcc, tak mám smíšené pocity. Například linkový skript intepretuje příkazy tak, že je zpracovává pomocí strlen/strcmp, takže co bych v jazyce podporující slušně řetězce napsal na jediný řádek, je v C zdrojáku na jednu až dvě obrazovky. A ve výsledku to limituje možnosti samotného skriptování linkeru, protože víc už programátor neměl sílu naprogramovat.
Jinak klobouk dolů za DES a AES v assembleru.
Miloslav Ponkrác
Hnutí GNU je založeno na principu, že nejlepší (a obvykle jediná) dokumentace je zdroják, to si časem zvyknete
Preprocesor v Javě používat můžete, dělal jsem to tak občas. Nic vám nebrání přechroustat javovský zdroják C preprocesorem a výsledek předhodit javovskému kompilátoru.
GNU hnutí nemohu upřít, že se mu podařilo srazit ceny sw na rozumnou mez a mnohé zdarma. Na druhé straně mám s GNU a GPL programy poněkud spíše traumatické zkušenosti. Je mi poměrně divné, proč třeba s programy pod BSD, MIT a jinými licencemi mám podstatně příznivější zkušenosti. Asi náhoda.
Miloslav Ponkrác
Moje zkušenost je, že kromě assembleru a LISPu programovací jazyky nezvládají nějakou slušnou integraci maker. Není proto vcelku divu, že jazyky spíše preprocesor a makra vyhazují pryč. Je obtížné to vymyslet tak, aby to nebyla prasečina. Pokud by někdo vymyslel slušnou integraci maker do vyšších jazyků, nejspíše by se to rozšířilo. Hlavním problémem je, že z maker kompilátor nic nevyčte.
Moje nepodložená představa je, že makra ve vyšších jazycích pro efektivitu nejsou nutně třeba. Že je zastoupí klícové slovo inline, metaprogramování a optimalizátor kompilátoru plus dobře navržená syntaxe jazyka dávající dostatek informací optimalizátoru. Nicméně nikdy jsem neprogramoval AES a DES, takže asi bych změnil názor.
Metaprogramování je to co se v C++ nazývá šablony (template). Myslím, že je to hlavně pokus o rozumnější makrování. U dynamicky typovaných jazyků je to ještě jednodušší.
Java není na rychlost a nikdy nebyla.
Miloslav Ponkrác
Java je záměrně osekána v možnostech na často obtížně použitelné minimum, aby hloupí programátoři měli jedinou cestu, jak něco udělat. Třeba se upsat k smrti, což je cesta, kterou vás v případě implementace DESu nabízí Java - rozepsat pěkně makra na velmi dlouhou sekvenci základních příkazů.
Mám na mysli dnešní většinové programovací jazyky, kde ani chytrý programátor nic moc nepořídí, protože programovací jazyk je hloupý a nedomyšlený. Makrování je obecný koncept, který je ale nepřehledný, proto se nahrazuje jinými koncepty. Stejně jako goto jako obecný koncept se nahrazuje podmínenými příkazy a příkazy cyklů, případně výjimkami.
Já osobně makrování ve vyšších programovacích jazycích vidět nechci. Chci v nich ale vidět koncept, který umožňuje efektivné kód pomocí vlastní optimalizace a pomocí metaprogramování. A to bohatě jako náhrada maker stačí a IMHO to udělá stejnou práci. IMHO. Makrování nerespektuje nic, je to prostá textová operace. Ani prostory jmen identifikátorů, ani obory viditelnosti identifikátorů ani nic jiného.
Problém je, že pokud se bavíme o C nebo Javě - bavíme se o hloupých jazycích plných kompromisů, které nejsou dobře navrženy. Pak je třeba dělat kompromisy. V C makrování neruší, C je v podstatě druh assembleru. C nemá ani skutečná pole, nemá prostory jmen, je tam silná tendenci všechny identifikátory být globálními.
Miloslav Ponkrác
OOP zcela bezpečně vznikl před jazykem C. Na počátku to nebyl zcela špatný koncept, dokud někdo z OOP neudělal zlaté tele k uctívání. A pak bylo OOP zpraseno a pokřiveno několika věcmi, aby to asi lépe připomínalo náboženství. Zejména byla na dědičnost navešeno moc funkci: 1) znovupoužitelnost kódu, 2) typová kompatibilita a přetypovávání, 3) definice interface. To nemohlo dopadnout dobře, protože docpat do dědičnosti 3 odlišné funkce nejde zvládnout jinak, než že OOP vykastrujete k nepoužití. A to se také stalo s dnešním OOP, ale tak to vždy nebylo.
Původní OOP znamenalo objekty, které si předávají zprávy. Nic jiného. Takový byl třeba Smalltalk. Později se to nějak ohnulo v to, že OOP se stalo syntaktickým cukrem volání funkce, kde prvním parametrem byl odkaz na data objektu. A pak do toho někdo hloupě nacpal třífunkční dědičnost a od té doby je to hnus.
Ohledně knih nechci dávat seznamy. Mám dojem, že knihy, které jsem četl kromě názvu musely také přijít v pravou chvíli, kdy jsem ve svém životě zrovna daný přelom potřeboval. Za nejdůležitější svou první knihu o programování považuji Niklaus Wirth "Algoritmy a datové struktury".
Miloslav Ponkrác
Ale přesně to od programovacího jazyka chci! Abych se mohl vyjadřovat ve výrazech a přitom přesně nebo skoro přesně věděl, jak je kompilátor přeloží. U Javy to nevím, a nejsem si jist, zda se to kdy dozvím (tj. zda je problémem moje imanentní hloupost nebo jen javová nevzdělanost).
Wirtha jsem četl krátce před K&R, kteří mi, dá se říct, všechno převrátili na hlavu. Důležitá kniha byl samozřejmě Knuth's The Art of Computer Programming, ale to je asi u všech programátorů stejné.
Nikoli, u assembleru vím, jak bude zdroják přeložen, vždy a z definice. U vyššího programovacího jazyka to jen zhruba tuším, ale mohu ty kdykoli snadno ověřit, a také ovlivnit např. klíčovým slovem register. U Javy to ani nevím, ani to nemohu snadno zjistit (jen na úrovni byte codu), a prakticky nijak to nemohu ovlivnit. Je-li vaším přáním mít nad počítačem méně kontroly, budiž; já mám požadavky opačné.
Java, stejně jako Python není kompilátor, ale intepretr. Obojí se překládá do byte kódu a následně intepretuje nějakým virtuálním strojem. To, že JVM často používá JIT je už jiná věc.
Java sice generuje slušně rychlý kod, ale zároveň mi bere možnost dosáhnout jakékoli optimalisace, i tam, kde ji potřebuji, takže příkladmo DES bych napsal v C a do Javy ho integroval jako hotovou funkci. To není čisté řešení a nelíbí se mi, Java mi bohužel jinou možnost nedává.
Dobré programovací jazyky jsou v optimalizaci dostatečně dobré, že se nevyplací trávit čas ani v asm, ani kontrlou každé instrukce. Proto dodnes matematici a fyzici rádi Fortran, a C se mu rychlostí ne a ne rovnat třeba. Proto NASA píše v Adě, a to i na kdejaký mikrokontroler, protože kromě bezpečnosti je to i velice efektivní kód ve výsledku.
Zde se ukázaly dva problémy zároveň: 1. nedostatečná semantika vyššího programovacího jazyka; a 2. nedostatečné používání instrukční sady kompilátorem.
Dokonce je Céčko tak špatný jazyk, že zpočátku jeho efektivita byla prachbídná. Museli mu pomoci sami výrobci procesorů a přidat strojové instrukce pro jeho podporu. To, že dnes má C slušnou efektivitu je tím, že procesory přidaly strojové instrukce - zejména různé inkrementace pointerů a indexové operace, které dříve byly vzácné a ani nebyly moc třeba. Cokoli, co vzešlo od unixu se těšilo podpoře IT průmyslu včetně výrobců čipů.
A obecně, je to naopak. Programátor je schopen jen výjimečně napsat něco lépe než kompilátor, pokud se nejedná o miniaturní projekt. Možná napíšete lépe jednu dvě vysoce optimalizované rutiny, jednu z deseti tisíc, zbytek prohrajete. Jen velmi výjimečně najdete praktický algoritmus, který je lépe napsat v asm.
C není přece žádný assembler, je na procesoru nezávislé. Je to low-level programovací jazyk, navržený tak, aby se v něm psaly snadno přenositelné a paměťově i časově velmi efektivní programy.
Naposledy jsem psal v C větší program asi před dvěma lety, šlo o solver pro hru Freecell, takže prohledávání stavových prostorů, párování, heapsorty apod. V Javě by to bylo o dost pomalejší.
Dále byste měl rozlišovat, pro který procesor se píše. Pro x86_64 s obrovskými registry a poměrně bohatou instrukční sadou je použití assembleru spíš raritou, naopak třeba pro Atmely AVR, které mají uzoučké registry a chudé možnosti adresace, není vyšší programovací jazyk přínosem. Mimochodem, dodnes jsem pro osmibity napsal jeden jediný program v C, a to jen na zkoušku, abych ověřil, že jsem si správně upravil Small-C (je součástí emulátoru). Tak jednoduché procesory raději programuji v assembleru, je to zábavnější a daleko lépe se využijí jejich možnosti.
Jazyk C lze udělat optimální jen s určitou sadou instrukcí. Jak jsem psal, musely se procesory přizpůsobit C, nikoli naopak.
Nicméně dobře navržené programovací jazyky jsou schopny dosti efektivního kódu a není ho vždy snadné přebít ručně. Ostatně považuji programování optimalizátoru u kompilátorů za větší machrovinu, než mnoho jiného. Nikdy mě nelákalo programovat třeba linux kernel, protože je to v zásadě nuda. Ale přál jsem si někdy nachomýtnout se k optimalizaci kompilátorů, to považuji za výzvu a machrovinu.
Procesory se přizpůsobují potřebám dominantního použití, co je na tom divného? Kdyby se většina softwaru psala v Adě, byly by přizpůsobeny Adě.
Souhlasím, že optimisery jsou složité a zajímavé algorithmy, je to, jak jsem psal, fakticky AI.
Ad 2) Většina jazyků toto přizpůsobení pro efektivitu nepožaduje, zrovna tak Ada. C ale ano, jinak je neefektivní. C je postaveno jako "emulate all by pointers" a bez strojových instrukcí pro bohaté indexování při dané bázové adrese je hodně neefektivní. Neuvádím to jako nevýhodu C, ale jako fakt, že ne každý procesor umožňuje efektivně hodit C.
Ad 3) Není to AI. Je to o tom, že programovací jazyk musí mít strukturu a syntaxi, která umožňuje kompilátoru získat maximální informace pro optimalizaci (C je z tohoto důvodu dost špatné). A následně deterministickými postupy překopat syntaktické stromy a tedy výsledný kód do podoby co nejlepšího kódu. Ty postupy jsou vcelku známé. Problém je, že napsat neoptimalizovaný kompilátor je 10000 x menší práce, než optimalizovaný, proto se optimalizace píši jen pro platformy, které jsou frekventovanější.
Tak to jste mě dostal, roky žiji přesvědčen, že 32
Zapojení je zcela jistě geniální, a se snahou udělat počítač co nejlevnější. Nicméně věcí, co tam dřelo bylo jistě více, než klávesnice. Procesor s taktem 2 MHz, který pracoval pro program jen 25 % výkonu a zbytek šlo na DMA. Génius autora byl brzděn omezenou nabídkou součástek a možností té doby a režimu.
Nutno ale říci, že chovám podobnou úctu k autorovi i dílu samotnému, protože ono zapojení a řešení je v zásadě umělecké dílo. A také trochu opak dnešní doby, kde se věci, i počítače, i elektronika, skládají z modulů, kde je využito s bídou 1 % možností součástek.
Miloslav Ponkrác
Eduard Smutný si podle svých rozhovorů představoval, že uvedou na trh sérii několika počítačů, z toho Ondra bude ten nejslabší a nejlevnější.
Mně přijde, že Ondra je sice geniální po hw stránce, ale že po stránce upotřebitelnosti uživatelem nešťastný. Už tehdy z něj čišelo "no co, uživatel se prostě omezí". Klávesnice, nevestavěný basic, výkon kvůli sdílení se zobrazováním velmi mizerný, přestřelená cena, žádné barvy (20 000 Kč v roce 1987! V té době stálo výrazně lepší ZX Spectrum kolem 6 000 Kč). Zkrátka Smutný a Ondra udělali všechno proto, aby počítač skončil debaklem.
Miloslav Ponkrác
Takže IMHO nebyl čas ho dodělat a když něco nešlo, tak to holt muselo ven. Nápad udělat Ondru se prý zrodil v září 1985 a v listopadu 1985 byla výstava, na které bylo předvedeno hotových prvních 5 kusů Ondry. Osobně jsem je na vlastní oči viděl.
Ondra trpí nedodělaností, a to mu podle mého srazilo vaz. A zcela zaslouženě. Kdyby tomu věnovali delší čas a udělali ho pořádně, mohl to být velmi dobrý počítač. Takže všechny součástky měly prioritu v tom, co šlo rychle sehnat před čímkoli jiným.
Sám si na ten moment, když jsem poprvé uviděl Ondru na výstavě pamatuji, vrylo se mi to do paměti. Jednak mě překvapilo, že jsem o něm předtím neslyšel, protože o všech novinkách jsem věděl chvíli dopředu. Druhak mě překvapilo, jak nepraktický a k ničemu počítač to je.
Sinclair ZX80 byla vyvíjena od května 1979 a prodávala se v únoru 1980. A to Sinclair i Westwood byli zcela nepochybně o třídu výš, než Smutný a kolektiv.
V té době ale začala být důležitá jiná věc, kterou bych já tehdy neodhadl také. A to standardy. V době kolem revoluce se začalo lámat to, že se prosazovaly standardy a ne každý pes jiná ves. Tedy určitá abstrakce služeb. Myslím, že to postupně zabilo i ZX Spectrum a mnoho dalších 8bitových počítačů.
Mám dojem, že Československo zanedbalo vytvoření cenově dostupného domácího 8biťáku a snažili se to rychle zaplácnout kolem roku 1985 = Ondra, Maťo a další. Maťo byl myslím lepší pokus. Oba vznikly rychle, ale Maťo stavěl na PMD-85.cNakonec nejúspěšnější byla zkopírovat zahraniční i s chlupama = Didaktik apod.
A už nic z té doby nevím. Vyčerpal jsem se a nemám k tomuto tématu už co říci. Jen jsem chtěl podpořil názor, že Ondra přišel pozdě, v době, kdy už končily CP/M a začalo dominovat PC XT. A že Ondra byl hlavně nestandardní, stejně jako to ZX Spektrum.
CP/M je textově orientovaný operační systém, takový hodně (ale opravdu hodně) ořezaný Unix. Teď jsem v něm trochu pracovat při ladění Z80 a překvapilo mě, jak nesmírně primitivní je to systém; pamatoval jsem si ho složitější
Pokud se bavíme o standardech, šlo hlavně o grafiku, a dá se říct, že standardem bylo cokoliv, čeho výrobce dokázal prodat nadkritické množství, tedy Spectrum, Commodore, Atari, Apple atd. IBM PC přišlo v pravou chvíli, protože jednak bylo hardwarově kvalitní (hlavně klávesnice), bylo šestnáctibitové a přineslo koncepci grafiky mimo základní desku, na rozšiřující kartě. To byl podle mě ten rozhodující geniální nápad, který zajistil PC "nesmrtelnost".
Tím se ze scénáře "jedna firma se pokouší dělat reklamu a prodat počítač" stane scénář "tisíce firem dělá reklamu a podporuje jeden počítač" - což je mnohem účinnější.
Základní scénář, jak něco rozšířit do světa je nech vydělat mnoha lidem, když to rozšíří. Tento koncept rozšířil PC, tento koncept rozšířil Windows, tento koncept rozšířil třeba SAP, rozšířil třeba ARM, a rozšiřuje koncepty i mimo IT sféru včetně politických převratů v zemích.
Kolik stál Ondra nikdo pořádně ani neví. Ono se ho vyrobilo asi jen 1000 kusů, a několik let po revoluci bylo nalezeno obrovské množství neprodaných Ondrů v jednom skladě, takže se prodalo minimum.
Dnes je zcela stejné stigma. Podívejte se, jak chcípají herní věci. Jak se propadá prodej extenrích grafických karet. Jak klesají zisky z her. Jak ubožejší a rychleji zastarávající jsou herní konzole. Do jisté míry se dnes opakuje to samé = herní ptákovinky vypadávají, zůstává praktičnost.
Problémem je, že profíci v IT trendy nevidí. Eduard Smutný neviděl trend, že v době vydání Ondry už jsou požadavky lidí řádově jinde, a Spectrum je tak tak splňovalo na dolní hranici. Už chtěli disky, barvy, klávesnici, programy. Stejně tak dnes na hw webech se diskutuje stejně. Nevidí trend, že herní zaměření umírá. Ale stále se diskutuje o tom, jaké herní věci vybrat. Výrobci nevyrábějí dobrou klávesnici, ale bazilióny herních. Lidé chtějí maličké počítače PC typu MacMini, nechtějí velké herní krávy factory vzhledu. Atd.
Historie se dnes opakuje. Výrobci si totiž myslí, stejně jako tehdy, že herní je hlavní tahoun. Ale lidi chtějí ty počítače spíše na internet, psaní, účetnictví, programování, atd. Ale výrobci jen - herní, herní, herní, totéž IT weby.
Miloslav Ponkrác
Já bych Smutnému rozuměl, že chtěl, aby se děti učili spíš programovat, než aby pařily Manic Minera. Ale v populaci je těch, kteří se dívají na počítač jako na fascinující technologickou hračku, stěží procento (ne-li promile), pro zbytek je Facebook a Farm Ville a Angry Birds a podobné nesmysly. To je realita, s níž se lidé jako Smutný museli smířit.
Realita je taková, že lidé rádi budou používat počítač k užitečným věcem. Ne nutně programovat. Jenže pokud se počítač určitého typu hodí jen na hry, pak budou hrát hry.
Například já jsem měl asi loni ideu, že budu profesionálně sázet. Tudíž jsem si objednal z USA knihu od Knutha a začal jsem. Úspěšně jsem si napsal asi 400 KB maker, takže v plain TeXu udělám to samé co v LaTeXu a lezou z toho krásné dokumenty. A pak jsem s tím sekl. Došlo mi, že těch pár algoritmů, co má TeX lze zcela určitě přenést do lepšího jazyka, než je makrovací jazyk TeXu. Tedy jazyk, který rezervuje jednotlivé znaky jako klíčová slova pro různé kategorie, nemá lokální proměnné, vyhodnocování výrazů stojí za starou bačkoru. Asi nejvíce humorné je, že jazyk na práci s textem nemá ani funkci na zjištění délky řetězce. A když jsem si pak přečetl dokument od CSTUGu, jak se pokoušeli vybudovat makro na porovnávání dvou řetězců a selhali, pochopil jsem, že nejsem škarohlíd a můj názor na TeX makrování je správný (XeTeX makro strcmp má).
V podobném stavu je i dnešek. Lidem je nabízen low level jazyk C nebo Java. A to si zkuste v těchto klasických jazycích udělat třeba graf! To je teprve masochismus. (Dříve to s Borlandem a BGI šlo poměrně snadno.) V dávném basicu to šlo několik příkazy plot a line přímo v jazyce raz dva.
Linuxová komunita ještě nedávno lákala lidi na linux stylem "každý se přeci může naučit bash, awk, C, flex, bison, ...". Zcela po zásluze tento zábavný přístup způsobil, že lidi se Window či OS X drží zuby nehty a nepouštějí se.
Já se ani nedivím, že k těmto věcem lidé nechtějí. Viděl jsem laiky s radostí programovat - v grafickém prostředí Smalltlaku nebo v HTML/CSS. A v několika dalších prostředích. A nebo v hloupém Excelu. Ostatně mnoho lidí, když se dostane k Pythonu se první učitelů zeptá, proč mu Python neukázali hned a otravovali ho nějakým C či Javou. A mají pravdu.
Já dodnes nechápu, proč programovací jazyky nemají základní abstraktní datové struktury jako součást jazyka. Tak jako Python. C nemá ani pole, ani řetězec, práci s řetězcem emuluje přes str*. Java už pole a řetězec má, ale tím končí, vše ostatní je už přes knihovny. Jakpak mají pak laici programovat?
Protože na něj neměl místo. Shodou okolností právě rozebírám to jeho zapojení a analysuji, co který IO dělá a co na kterém pinu kdy je, takže mám trochu přehled, jak je to udělané.
Slušný BASIC by zabral 10–12 KB místa (původní PMDčkový má 10 KB, tedy řekněme deset), a protože tehdy v ČSSR nebylo nic nad 2708/2716, tzn. 1/2 KB, musel by tam nastrkat, kromě monitoru, spoustu dalších velkých integrovaných obvodů, včetně patic, které zabírají víc prostoru než samotný chip. Takže Ondra s BASICem by byl pomalu dvakrát tak velký než bez něj.
Došlo mi, že těch pár algoritmů, co má TeX lze zcela určitě přenést do lepšího jazyka, než je makrovací jazyk TeXu
Zkuste tedy Luatex. Já stejný problém řeším, resp. v krátké době řešit budu, tak, že dokument bude napsaný v XML, ze kterého si přes XLST vygeneruji texový zdroják, protože, marná sláva, nic jiného tak dobře sázet neumí. Všechny dokumenty, které vystavuji na druhém blogu, jsou mimochodem generovány (plain) TeXem.
A nebo v hloupém Excelu. Ostatně mnoho lidí, když se dostane k Pythonu se první učitelů zeptá, proč mu Python neukázali hned a otravovali ho nějakým C či Javou. A mají pravdu.
Programátoři jsou elitáři, a víceméně právem, na rozdíl od jiných profesních skupin, které elitami nejsou ani náhodou, ač se tak tváří (právníci, lékaři apod.). Proč by se programátor měl snažit, aby laika naučil programovat, když mu může prodat svou práci?
K TeXu bych napsal rozsáhlejší komentář, ale nechci to tu zahltit. Všiml jsem si, že sázíte XeTeXem jako já. Nápad jsem měl podobný jako vy, použít rozumný skriptovací jazyk a vygenerovat soubor obsahující jen primitivní makra TeXu a nepoužívat makrovací jazyk.
Myslím, že v každém oboru je mnoho vyvolených a málo povolaných. Na vašem argumentu něco je. Je pravdou, že programátoři učit nikoho nebudou. Nicméně očekával jsem, že firmy živící se vývojovými prostředími tak budou k potěše své peněženky činiti, a vydají takové nástroje, aby slušné programy v nich vytvořila i lázeňská veverka na stromě. Nicméně neděje se tak.
Procesor už má standardně v sobě řadič paměti, různé věci, co dřív byly součástí můstků na základní desce, a čím dál více se integruje právě grafická karta. Nakonec se to postupně vrátí tam, co 8bity, tedy all in one, vcelku téměř nerozšířitelné.
Miloslav Ponkrác
Vy jste jako vazne napsal benchmark ze kteryho vylezlo ze tech 256 instrukci s prefixem 0xCB je nejrychlejsich kdyz se to roztahne na 60kB zdrojaku? Moc se mi to nezda, i kdyz je jasny ze tim odpada potreba rozebirat bajt opcodu na kousky.
> Vždyť to mělo čtyři shift-klávesy, a stav se zjišťoval podle toho, zda svítila žlutá LED, zelená LED, případně obě nebo žádná.
Ctyri ruzny shifty? Jako fanda Emacsu zacinam litovat ze jsem se s tim neseznamil dukladneji.
> Linuxová komunita ještě nedávno lákala lidi na linux stylem "každý se přeci může naučit bash, awk, C, flex, bison, ...".
Opravdu? Tehle vsech 5 veci jsem sice uz pouzil, ale nenadchla me ani jedna z nich a krome bashe jsem nic z toho uz mozna roky nevidel. A to sedim na Linuxu denne a (kdyz nejsu v IDE) delam skoro vsechno pres prikazovou radku.
> Zcela po zásluze tento zábavný přístup způsobil, že lidi se Window či OS X drží zuby nehty a nepouštějí se.
No ja o tomhle zabavnym pristupu jeste neslysel. BFU nepozna Linux od Pindowsu kdyz mu tam date spravny ikonky.
Experimentoval jsem s tím poměrně dost, a zjistil jsem, že Java nesnáší dlouhé switche, které chápe jako jeden kod a neumí je proto optimalisovat. Proto se musí kod rozsekat. Zda ho rozdělit na jednotlivé opcody nebo na jejich skupiny podle masky, je už celkem jedno, moje řešení je nicméně programátorsky čisté. Další optimalisace by šla sloučením manipulace s flagy do výrazů, ale vzhledem k tomu, jak nepatrnou zátěž emulace ALU představuje, se to prostě nevyplatí a postačí mi vědomí, že jsem dal kompilátoru možnost inlinovat prakticky všechny methody volané z instrukcí, např. incPC, CLEARNF, HL() apod., a není moje vina, pokud to případně nedělá (ale spíš dělá, celý exerciser pro Z80 mu trvá 2,5 sekundy).
Ctyri ruzny shifty? Jako fanda Emacsu zacinam litovat ze jsem se s tim neseznamil dukladneji.
Jako fanda Emacsu fanovi Emacsu vám říkám, nelitujte. Po napsání čtyřřádkového programu v Basicu jsem hluboce oddechoval a měl nutkání změřit si tep.
Tento zábavný přístup propagoval Linux minimálně 10 let v kuse. Což je přesně důvod, proč LInux má na desktopu 1 %. Posledních několik málo jednotlivých let už tomu tak není, ale důvodem je spíše prořídnutí staré linuxové garnitury a nahrazení další generací, než jiný důvod.
A to mluvím už o zralejším LInuxu. Co se dělo třeba v letech řekněme kolem roku 2000, raději nepíši. Ani o historkách k popukání v letech před a krátce po tomto roku. Například masový prodej počeštěného RedHat Linuxu CZ 6.2 (číslo verze si přesně nepamatuji),. který se prodával v každé trafice a kvůli chybě v instalátoru nešel vůbec nainstalovat. To bylo první setkání obecného českého lidu s Linuxem vůbec. Samozřejmě s komentáři "konečně můžete všicni opustit to chybové Windows a přejít na bezchybný Linux" ze všech stran linuxové komunity a webů.
V dobách Windows 98 pak Linux byl ve tvaru, že bez čtení mnoha megabajtů plain text anglické dokumentace, nastudování kódu modemu, detailů protokolu - jste se k internetu nepřipojil vůbec. Mně to trvalo 14 dní celodenní práce v tehdejším Debain Linuxu. A to jsem pěkně prosím znal unix jako svoje vlastní boty.
Dnes už je Linux poměrně mnohem vychytanější, a excesy jsou minimální. Nicméně představa linuxové komunity směrem k laikům byla poměrně dosti - mírně řečeno sadistická. A to ani nezmiňuji, s jakou vřelostí (ironii cítíte zcela správně) se laik či zkušený uživatel jiného operačního systému setkával na diskusních skupinách.
Dnešní Linux je zcela něco jiného a linuxová komunita změnila taktiku. Dnešní Linux je prímový, a mám ho rád. Ovšem linuxová komunita nyní připomíná svědky jehovovy, šíří desatera a víra směrem od "politbyra", což je můj slangový název pro centrální dodávání názorů do linuxové komunity. Když se chci zasmát, přečtu si nějaké články o linuxu, zejména články, které mají v názvu "vyvracení mýtů o ..." jsou téměř vždy velice lživé a plné vtipů.
Miloslav Ponkrác
RSS kanál komentářů k tomuto článku