Vlákno názorů k článku Komiks: programátor lážo-plážo od Zdeno Sekerák - Ano programovat spamati sa da, ale uz je...

Problem je v tom "pokud mate dostatek casu". To v realite nikdy neplati a proto se v praxi pouziva C a frameworky.

K tomu memu tvrzeni, ze "C je rychlejsi nez assembler". Samozrejme (jak by soudny clovek chapal) to znamena ve vetsine pripadu (pro vetsinu vyvojaru, pro vetsinu casu co je k dispozici, pro vetsinu algoritmu).

Jasne ze muzete vzdycky napsat lepsi assembler, ale to de facto znamena objevit novou optimalizaci, kterou kompilator jeste nezna. Na druhou stranu, napsat to rucne v assembleru znamena provadet rucne spoustu optimalizaci, ktere uz kompilator umi (treba takovou alokaci registru). Drive nebo pozdeji dojde k tomu, ze to prvni se proste nevyplati (protoze vetsina optimalizaci na urovni assembleru uz byla objevena a vlozena do kompilatoru, nebo je program prilis slozity na to, abyste se schopnosti optimalizovat neco kompilatorem vyrovnal)

Napriklad takova optimalni alokace registru, navic intra-proceduralne, by vam asi dala pekne zabrat. Proto dnes uz nikdo nealokuje registry rucne, je to proste nuda a navic malokdy dosahnete lepsiho vysledku nez kompilator, co si na to proste obarvi graf.

Postupem doby vsechny implementacni detaily, co dnes resi programator rucne (napr. alokaci pameti, casem i volbu algoritmu a datovych struktur), bude schopen delat kompilator a daleko lepe. To je pokrok.

Rád bych Vás seznámil se sladkým tajemstvím, že rychlost kódu je určována mnohem složitějšími faktory, než jen pouhou alokací registrů. O tom neni sporu. Zejmena je urcovana vyberem datovych struktur a algoritmu, ktera v soucasne dobe predmetem optimalizaci temer vubec neni. Coz je podle me chyba, a nepochybne cesta do budoucna. A nehledě na to, že si na to sice může obarvit graf, ale pořád je omezený tím, že kód píše člověk omezenými prostředky C, které nezohledňují specifika toho kterého procesoru, dále, že kompilátor musí dodržovat nějaké své konvence (i registrové - například, že třeba do ecx/rcx předá vždy adresu instance objektu) atd. a pak to celé s těmito omezeními teprve překládá. Kvalitni kompilator specifika procesoru zohledni. Je pravda, ze paralelne probiha i vyvoj procesoru, takze nelze absolutne drzet krok. Ale kompilatory se neustale zlepsuji a zahrnuji stale vice optimalizaci, a ten trend bude pokracovat. Uvádíte tam i věci, které jsou matematicky dokázané, že nejdou automatem udělat. Toho jsem si velmi dobre vedom. Ale to ze nejdou obecne udelat neznamena, ze se tomu nelze na 99% (a vic) procent priblizit. A to se take stane.

Jen jedna otázka: tušíte vůbec aspoň rámcově, jak funguje kompilátor a automatická optimalizace?

Odpověď je nasnadě - pokud byste tušil, musel byste připustit, že pan Ponkrác má naprostou pravdu. Takže - už z principu automaticky generovaný (slovo "kompilovaný" je mnohem přesnější) kód NIKDY, opakuji NIKDY nemůže být lepší, než člověkem optimalizovaný program v assembleru!!! Alespoň do té doby, než se z kompilátoru stane myslící bytost. Pokud by vám někdo tvrdil opak, nevěřte mu.

Mimochodem co píšete o optimalizacích je naprostá hovadina. Je vidět, že tomu absolutně nerozumíte. Proto mne docela zaráží, že se pouštíte do takové debaty. Když něčemu nerozumím, tak raději mlčím a nejdřív si o tom něco sestuduji. V tomto případě byste ale musel studovat několik let. Jen pro vaši informaci - asi byste byl hodně překvapen, jak primitivní v porovnání s uvažováním člověka jsou ty nejsofistikovanější metody optimalizace i jen blbé alokace registrů!

Nejzásadnější překážkou veškerých optimalizací je to, že program obecně nikdy nepochopí smysl jiného programu. Člověk ano. Optimalizátor v překladači bude vždycky provádět jen DÍLČÍ optimalizace. Obvykle se jedná o optimalizace automaticky generovaného kódu, který by bez těchto optimalizací nebyl průměrný, ale do očí bijícím způsobem neefektivní.

Takže více studujte odborné prameny a méně reklamní materiály firem prodávajících překladače.

Odpověď je nasnadě - pokud byste tušil, musel byste připustit, že pan Ponkrác má naprostou pravdu. Takže - už z principu automaticky generovaný (slovo "kompilovaný" je mnohem přesnější) kód NIKDY, opakuji NIKDY nemůže být lepší, než člověkem optimalizovaný program v assembleru!!! Alespoň do té doby, než se z kompilátoru stane myslící bytost.
Ja ale nerikam, ze pocitac vygeneruje vsechen kod. Ja srovnavam prelozeny kod v C s kodem v assembleru. To co delate v assembleru navic je napr. alokace registru. A od jiste urovne slozitosti budete mit problem udelat ji lepe nez to za vas spocita stroj.
Nejzásadnější překážkou veškerých optimalizací je to, že program obecně nikdy nepochopí smysl jiného programu. Člověk ano. Optimalizátor v překladači bude vždycky provádět jen DÍLČÍ optimalizace.
Prekladac bude vzdy provadet optimalizace, ktere do nej vlozi clovek. S tim souhlasim. Ale muze je udelat milionkrat rychleji, na mnohonasobne vetsich problemech, a bez jakekoli unavy.
Vy se domnivate, ze v tom, ze program nepochopi smysl jineho programu je nejaky zasadni problem. S tim nemohu souhlasit. Chape snad Google vsechny stranky na internetu? Jak je pak mozne, ze vam na hledani vraci relevantni vysledky? Moje myslenka (ktera je predmetem meho zajmu) spociva na podobnem principu, ktery umoznuje, ze lze optimalizovat daleko vyssi uroven nez dnes, a to aniz bych musel ten smysl znat. Neni to slozity princip - nepochybne ho jiz objevil nebo objevi i nekdo jiny.

> od jiste urovne slozitosti budete mit problem udelat ji lepe nez to za vas spocita stroj

Jak jste na to přišel? Jakou metodu výpočtu optimální alokace máte konkrétně na mysli? Automaticky se můžete pokusit o nějaké optimalizace pouze v rámci toho, co je napsáno v daném vyšším jazyku. To je pro optimalizátor alfou omegou, hranicí, za kterou principiálně jít nemůže. Narozdíl od člověka - kouknu na kód, vidím, že tak jak to je to je nepohodlné, tak změním sémantiku té části programu, změním činnost podprogramů, změním pořadí jejich volání. Tohle se zkrátka spočítat nedá (a dá se dokázat, že se to spočítat nedá). Lidská bytost v podstatě dělá peephole optimalizaci a umí to dělat perfektně. O překladačích se dá říct pravý opak.
Mimo to nechápu, proč sem zavlékáte problém velkých programů. Otázka stojí, zda kompilátor vyprodukuje kód na úrovni kódu napsaného člověkem. Odpověď zní nikoli. Otázka, zda-li se to vyplatí a jak dlouho by to člověku trvalo je jinou otázkou. Bavíme se tu o kvalitativních, nikoli kvantitativních otázkách.

> Prekladac bude vzdy provadet optimalizace, ktere do nej vlozi clovek.

Právě. Jenže to bude vždy silně omezená množina jednoduchých postupů aplikovatelných na silně omezenou množinu případů. Alespoň v porovnání s možnostmi lidského mozku.

> Chape snad Google vsechny stranky na internetu?
To jste si docela naběhl... A teď si zkuste představit, že byste chtěl po googlu, aby vám na základě hesel, jež mu zadáte, sestavil recept na dort. Ne aby ho našel, ale sestavil na základě vašich přání a dílčích informací, které má k dispozici. Něco jako "Chci třívrstvý ořechový dort s máslovým krémem a jahodami vážící jedno kilo" a on mi vyplivnul "Budeš potřebovat x gramů másla, mouky, vody, mléka, cukru.... 1. vezmi mouku, smíchej s tím, tím a tím, vypracuj těsto, pak přidej tohle..." Co myslíte, co by pro takový automat bylo jednodušší - jednoduché recepty, nebo naopak ty komplikované, které se údajně už nevyplatí psát rovnou? Jahodový puding nebo nadívaný kapoun se švestkovou omáčkou, jablky a pomeranči? Protože přesně to se chce po kompilátoru! Stejně mu budu muset popsat, jak se dělá švestková omáčka a on k tomu bude moct použít jen poměrně omezenou množinu z toho, co mu nabízí vybavení kuchyně - povařenou zeleninu bude muset rozmixovat, protože ho nedonutím k tomu, aby použil cedník a místo toho ji propasíroval, protože mu někdy někdo napsal, že cedník se používá na oddělení tekutiny od pevné hmoty v podobě heterogenní směsi a jinak ho použít nedokáže.
Dovedu si představit, že by bylo možné takový automat použít v závodní jídelně, kde se neočekává nic extra k jídlu, prostě jen k zasycení žaludku, přičemž spotřeba prostředků kuchyně by byla veliká (potřebuji bílky - M vajec, žloutky se vyhodí, potřebuji žloutky - N vajec, bílky se vyhodí, potřebuji rybí maso - odřezky se vyhodí, potřebuji rybí polévku - vezme se další ryba a udělá se z ní kotel polévky, jehož 2/3 se vyleje...). Tvrdit, že výsledek takového podniku může konkurovat práci šéfkuchaře by mohl opravdu jen člověk, který snad v životě nepozřel normální jídlo a nikdy nebyl u toho, jak se takové jídlo připravuje. Jediný důvod by byl, že šéfkuchař je tak drahý, že se mi vyplatí rezignovat na chuť a raději obětovat více surovin a energie nevalnému, ale stravitelnému výsledku. Nic to ovšem nebude měnit na faktu, že šéfkuchař bude vždycky lepší.

> Neni to slozity princip - nepochybne ho jiz objevil nebo objevi i nekdo jiny.
Principů jak optimalizovat je mnoho a každého, kdo někdy psal vlastní překladač, napadnou i myšlenky, o kterých se nikde nic nedočte. Ale všechno to má stále stejný problém - jsou to jen optimalizace dílčích problémů. Žádný algoritmus vám kód bubblesortu nezoptimalizuje na quicksort. Zatím to zvládá jen člověk a mám pocit, že ještě dlouho mu tohle výsadní postavení žádný stroj neohrozí.

> Automaticky se můžete pokusit o nějaké optimalizace pouze v rámci toho, co je napsáno v daném vyšším jazyku.

To je pravda. A proto je take (podle me) vyssi abstrakce nezbytna pro lepsi optimalizace.

>Otázka stojí, zda kompilátor vyprodukuje kód na úrovni kódu napsaného člověkem.

To zdaleka nemusi. Muze vyprodukovat uplne jiny druh kodu, staci, kdyz bude rychlejsi. Podobne jako sachove programy resi stejny problem uplne jinym zpusobem.

>Ale všechno to má stále stejný problém - jsou to jen optimalizace dílčích problémů. Žádný algoritmus vám kód bubblesortu nezoptimalizuje na quicksort.

Problem je, ze se na to divate prilis primocare. Tim argumentem s Googlem jsem chtel naznacit, ze vsichni cekali (v dobe Altavisty), ze nebudeme schopni udelat relevantni vyhledavac, pokud neporozumime psanemu textu. A Google na to sel necekane jinak - zacal sledovat odkazy. Podobne je to i s tim sortem. To, ze ve skutecnosti musime vyresit tento problem, si myslite vy. Ja si myslim, ze tento problem lze obejit, podobne, jako ho obesel Google. Je reseni Google dokonale? Ne. Ale je prakticky postacujici? Ano.

No, asi nema smysl se moc dal hadat. Vy proste na vyznamny pokrok v tomto smeru neverite, ja ano (a mam pro to dobry duvod).

Nebo jste nikdy nepracoval s assemblerem a tím pádem nevíte, o čem mluvíte.

Znam 3 assemblery. V jednom delam denne, takze moc dobre vim, jake je to zoufalstvi, kdyz musite rucne programovat/optimalizovat neco, co dnes bezne umi kompilator.

Jinak je to zvlastni, jak jste si tolik jisti, ze neco neni mozne, a pritom se me ani nezeptate na podrobnosti. Ne ze bych je tu chtel sirit (ve skutecnosti bych moc rad, ale dal jsem si zavazek), ale ta nafoukanost je zarazejici.

Programuješ Matrix? Hlavně pozor aby si neuvědomil svojí jedinečnost :-D

Správně, mrhejte čas a finance na konstrukci perpetua mobile a neztrácejte víru, že se vám to někdy podaří. Vždyť ti vědci, kteří se teorií k tomu celý život zabývají, jsou asi úplní pitomci když došli k důkazu který tvrdí, že to zkonstruovat nelze. Taky držím palce! A hlavně o tom pokud možno nic nevědět, zbytečně si nezatěžovat hlavu vědomostmi. Blažená nevědomost. Vivat tabula rasa!

Zdravim, docela by me zajimal Vas projekt, protoze me uz davno napadlo neco podobneho, ale jeste jsem nemel cas pustit se do praktickeho experimentovani. Muzete se mi (pokud budete chtit) ozvat na weird.m (zavinuta-ryba) centrum (v-TLD) cz

C (ani žádný jiný vyšší jazyk) prostě NEMŮŽE být nikdy rychlejší než assembler. Vyplývá to z podstaty assembleru. Žádné optimalizace nejsou ručně neproveditelné. Vyšší jazyky se používají, protože by to v ASM trvalo napsat moc dlouho, ne proto, že by dělaly rychlejší kód.

> cokoli z vyššího jazyka jde (teoreticky) napsat v assembleru
No tak pokud by to nešlo i prakticky, tak by to asi nešlo vůbec, nemyslíte? Nebo vy snad znáte nějakou konstrukci vyššího jazyka, která se nedá napsat v assembleru? Tak to by byla opravdu "velmi užitečná" konstrukce.

> abychom dosáhly
Vy jste žena mluvící za skupinu žen?

> Nemluvě o tom, že některé vyšší jazyky optimalizují kód za chodu
Můžete jmenovat? Včetně stručného popisu metod, kterými tak činí?

> Důležitá je hospodárnost
Otázka zněla, zda-li člověk vyprodukuje lepší kód než kompilátor. Ne, je-li to hospodárné. BTW: je spousta případů, kdy to hospodárné je. Je rozhodně hospodárnější zaměstnat k programování laseru na operaci očí zdatného programátora, než to nechat poflikovat nějakým amatérem a přeložit nějakým programem a pak se muset soudit s osleplým pacientem o miliony, když to z neznámých důvodů selže.

> získat za to 0,00001% výkonu navíc.
Můžete nějak popsat, jak jste došel k číslu 0,00001% ?

> po dosažení "určitého stupně složitosti" člověk už nezvládá
To je sice hezké, ale žádný problém se neřeší v celku, i ten sebesložitější problém je dekomponován a faktorizován na mnohem menší celky, které jsou již zvládnutelné. A tento rozklad komplexního složitého problému na jednotlivé subproblémy kupodivu nedělá počítač, ale člověk. Krom toho, i ten raketoplán můžete udělat s logaritmickým pravítkem, počítač se nepoužil kvůli tomu, že by konstrukce raketoplánu byla člověkem nezvládnutelná, ale jen kvůli tomu, aby na něm bylo možné rychle provést celkem primitivní, ale pro člověka úmorné výpočty.

> Viz např. Java a Just-in-time compilation.
To je pouze mechanismus na dílčí vylepšení jinak obecně celkem nevalných výsledků interpretovaných jazyků. Lisp to de facto obsahuje už někdy od 60. let a např. Forth to nepotřebuje. Když připomenu, že by dle tebe tato věc měla umožňovat "dosáhnout lepších výsledků, než by dosáhl největší guru-programátor v assembleru," nemohu se ubránit smíchu.

> Pokud se ti povede přepsat program o velikosti OpenOffice do assembleru tak, že bude rychlejší než 0,00001%
Proč by to mělo být nemožné? V assembleru se v historii psaly mnohem větší projekty, než je OpenOffice. Neexistuje žádný problém, který by byl tak komplikovaný, že by nešel napsat v assembleru člověkem. Vždycky se nakonec dostanete na úroveň rutin čítajících několik desítek až stovek instrukcí a ty zvládnutelné jsou. Navíc tuto diskusi nevyprovokovala poznámka o tom, že by assembler byl lepší nástroj k vývoji, ale o tom, že dnešní překladače produkují kód, který je lepší než ručně psaný. Což je volovina. Já netvrdím, že by bylo lepší psát rozsáhlé projekty v assembleru.

> "Zdatný programátor" je méně než pět průměrných programátorů, deset testerů a dobře čitelný programovací jazyk a dobrá metodika vývoje
Na to jsi přišel jak? Sackman už v roce 1968 na základě empirických studií ukázal, že dobrý programátor je 10x produktivnější, než průměrný. Je až komické sledovat, jak se v poslední době spousta firem vydala po cestě, která už byla před desítkami let ukázána jako špatná. No ale "mladí dynamičtí" manažeři vědí všechno lépe, že... Taky tomu odpovídají ty výsledky. Pokud bychom porovnali současný software s tím před 20-30 lety v tom smyslu, že bychom ohodnotili jeho užitečnost a podělili schopnostmi železa, na němž běží, vyjde ten současný jako totální propadák.
A pokud jde o ty "kritické" aplikace - zde konkrétně finance, tak už jsem měl tu čest nahlédnout pod pokličku... Internetovému bankovnictví se od těch dob raději vyhýbám a taky už je mi jasné, kam mizí ty všeliké různé poplatky za pojistky a za vedení účtu. Ani ve státní sféře se tak nemrhá penězi! BTW doporučuji několikaměsíční stáž např. v Unicornu, aby člověk viděl, jak se dá patlat software ve stylu "jak Pejsek s Kočičkou vařili dort."

No tak zrovna Java a Just-in-time compilation závratných rychlostí opravdu nikdy nedosáhnou. Běží totiž v podstatě v emulátoru.
Ale jinak souhlasím, většina dnešních programů by v assembleru napsat nešla. I když na druhou stranu takový Menuet OS ...

> většina dnešních programů by v assembleru napsat nešla

Ale šla. S přehledem. Že si to dnešní "programátoři" nedovedou představit neznamená, že by to nešlo.

> Proboha, už z podstaty a principu nemůže nikdy nic v rychlosti předstihnout dobře napsaný ruční assembler/stroják.

Predpokladejme, ze programator napise jeden program, ten se postupem casu distribuuje mnoha uzivatelum a uzivatel si ho prelozi a pouziva.

Pak optimalni program v C muze byt klidne rychlejsi nez optimalni program v assembleru
(optimalnim myslim takovy program, ktery ze vsech programu resicich danou ulohu ma nejmensi prumer doby behu (pres danou mnozinu uzivatelu)). Proste proto, ze kod v C se muze prelozit do ruznych kodu ve strojaku podle toho, jakou ma uzivatel variantu procesoru. Programator v assembleru muze sice pripravit vic variant, ale netusi, jake prijdou nove varianty daneho procesoru v budoucnu a jak na nich bude vypadat optimalni strojak.

> Nemůže - protože za podmínek, které jste popsal není psán v assembleru optimálně. Tudíž to co říkáte je protimluv.

To je pravda, nenapsal jsem to vhodne. V dobe psani programu jeste neni zafixovana mnozina uzivatelu a tedy ktery program bude optimalni - to zavisi na pozdejsim vyvoji (jake se objevi procesory a kompilatory). Ale tipuji, ze u programu v assembleru budou ty rozdily mezi potencialne optimalnimi (optimalnimi v ruznych vetvich budouciho vyvoje) vyrazne vetsi, nez u programu v C.

> Při optimalizaci na nové procesory jasně vede assemblerista.

Assemblerista (a programovani v assembleru) mozna ano, ale assemblerovy program ne - ten uz je jednou napsan a nemuze tedy byt prizpusoben novemu prostredi. Zatimco jiz jednou napsany program v C muze byt prelozen pro novy procesor.

> Je naprostá pitomost, aby optimálně (používám Vaše slovo) napsaný kód v assembleru a optimálně v C neskončil vítězstvím assembleru.

Pokud odhledneme od absolutni optimality a budeme brat v potaz pouze realne situace -

Co treba takovy kod napsany nekdy v roce 1983 pro 286ky? Pochybuji, ze by ho nekdo napsal rovnou tak, aby bylo mozne pouzit na Pentiich (az by se pozdeji objevily) obe pipeliny. Zatimco kod napsany v te dobe by nemel byt problem prelozit modernim kompilatorem a ten sice nemusi udelat zadne jo chytre optimalizace, ale aspon by mohl dodrzet pravidla pro vhodne rozmisteni instrukci pro dany (novy) procesor.

> aby bylo mozne pouzit na Pentiich (az by se pozdeji objevily) obe pipeliny.

Vypadlo me tam slovo: aby bylo mozne pouzit na Pentiich efektivne obe pipeliny.

Jednou jsem s assembleristou závodil. Nepoužil jsem žádný rychlý jazyk a stejně jsem vyhrál o několik délek. Zatímco on optimalizoval kód, mě se zatím povedlo vylepšit algoritmus ...

Systém IBM pro sálové počítače byl psán ještě v assembleru. Za dvacet let se v postatě nezměnil a nakonec zastaral natolik, že IBM s radostí sáhla po Linuxu. Protože provést v něm nějakou zmenu bylo v podstatě nemožné, natož ho dále rozvíjet.
Je jenom málo programů, ve kterých není potřeba provádět změny. A povětšinou bleskurychle. Řekl bych, že je to kritérium mnohem důležitější, než rychlost běhu - alespoň ve většině případů. Protože spousta programů simuluje nějaké reálné procesy a realita se bohužel neustále mění.

Daleko víc, než nedostatečně optimalizující kompilátory mi vadí nabubřelé systémy, které se po většinu času věnují sami sobě a na uživatelův program si pomalu nenajdou čas. A tam už ani ten assembler nepomůže ...

Aha, proto se dnes ty nejlepší audiozesilovače stavějí zase s elektronkami... Proto se ty nejpřesnější lineární zesilovače pro měřící techniku sestavují opět z tranzistorů... Proto se kvalitní A/D převodníky znovu stavějí odděleně od DSP procesorů, přestože před deseti lety se začaly integrovat na jeden chip.

Akorát si pletete dojmy a pojmy. Nevěřím tomu, že by zastánci diskrétních součástek tvrdili, že jejich řešení je lacinější a rychlejší. Že je ale v mnoha případech lepší a integrovanými obvody nenahraditelné, to je prosím fakt. Takže nevím, o jaké prohře mluvíte. Naopak bych tvrdil, že lidi, co si mysleli, že integráče všechno vyřeší, zažili dost studené vystřízlivění ze své bláhovosti.

Ani bych neřekl. Naopak si dovolím tvrdit, že procento využití integrovaných obvodů kulminovalo tak před deseti lety, pak se snížilo kvůli např. mnou vyjmenovaným oblastem.

Ano a počítač nemůže nikdy porazit člověka ve hře v šachy. :-D Vycházíte z naprosto neodůvodněného předpokladu, že ten ručně napsaný kód v assembleru je nejlepší možný. Kdyby tomu tak vždy bylo, dalo by se tvrdit, že se kompilátor může maximálně člověku vyrovnat. Ale jelikož člověk, jak víme, není dokonalý, může se časem klidně stát, že lidi prostě už nebudou mít šanci být v průměru lepší než kompilátor.

To se může stát jedině v případě, že bude soutěžit kompilátor a blb, tedy průměrný současný lepič kódu.

Stejně jako počítač může porazit v šachách pouze mladšího žáka na úrovni maximálně okresního přeboru. ;-)

A že jste si vybral zrovna šachy? Mají k problematice kompilátorů nějaký relevantní vztah? Proč si nevyberete k porovnávání třeba hru GO? V níž jsou i nejlepší algoritmy celkem s přehledem drceny průměrným hráčem. Ne že by to mělo ke kompilátorům nějaký větší vztah, než šachy, jen tím chci naznačit, že srovnáváte hrušky a jablka.

Šachy jsem si vybral jako ukázku úspěšného proniknutí počítačů do oblasti, která byla donedávna doménou nejlepších lidských mozků. Proč by tedy nemohl vzniknout podobně dobrý kompilátor nebo podstatě lepší počítačový hráč Go (ten asi spíš na bázi neuronové sítě než jako algoritmus)?

No jo, jenže ikdyž se to na první pohled nezdá, i ty šachy jsou v podstatě spíš hra o paměti - a tam je počítač silný v kramflecích.
Jistě že by eventuálně takový algoritmus mohl vzniknout a jsem přesvědčen, že i s neuronovými sítěmi se v této oblasti experimentovalo. Otázkou je, jak velká by ta síť musela být... aby nemusela být tak velká, jako ta lidská :-)

Ono stačí, aby ten kód byl formálně verifikovatelný a už je na tom počítač lépe než assemblerista, protože opět jde jen o dokonalou paměť.

Jinými slovy - programátoři jsou rok od roku blbější. S tím souhlasím. Bohužel je to tak. 90% lidí, kteří sami sebe dnes nazývají "IT experty" by si za časů, kdy jsem začínal já, ani neškrtlo. Patrně by jim byla doporučena nějaká manuální práce, na niž by svým intelektem dosahovali lépe.