Vlákno názorů k článku Internet hloupých věcí od jiný muf - Článek moc pěkně popisuje několik zásadních problémů současného...

Článek moc pěkně popisuje několik zásadních problémů současného IT, které je nejvyšší čas řešit:

1) "Euforie". Obecná slepá důvěra a až náboženský technoteistický fanatismus v němž pramení nadšení z každé nové hračky, kterou člověk prostě "musí mít", samozřejmě co nejlevněji a hlavní je "aby to _něco_ dělalo". Už není podstatné jak. Vlastník tomu stejně nerozumí, jen upíná své naděje k tomu, že s tou hračkou bude šťastnější. Třeba takové "smartwatch" jsou jako kouzelný amulet. Když si je koupím, budu šťastný.

2) Zoufalá neznalost/nev­zdělanost u spotřebitelů i výrobců. Školy produkují polovzdělané poloprogramátory. Neumí myslet, software štrykují jak ponožky - ovšem s větším množstvím děr, ve špatné velikosti a ze špatného materiálu. Naštěstí díky předchozímu bodu to nikomu nevadí...

3) Ignorace filosofie a sociálních věd obecně. IT sféra a bohužel i IT školy systematicky ignorují staré známé pravdy a otázky filosofie, sociologie, psychologie, politologie a podobně. Ty vědy často řeší nebo už dávno vyřešily podobné problémy (např. právě problematiku útočení), k jakým se dostane při práci překvapivě i programátor. Jenže ten je zvyklý (kvůli své hlouposti a neznalosti) už od školy shlížet na humanitní vědy opovržlivě a ignorovat jejich poznatky. Důsledkem je jeho hloupé a nefunkční řešení, kterému by se musel humaniťák smát, pokud by ovšem měl elementární technické vzdělání (viz 1. bod).

Pokud už se něco z těchhle věd využívá, tak jde spíš o marketingové zneužívání jako třeba u facebooku nebo cílené reklamy obecně apod.

4) Konzumismus a obecná tendence vyrábět co nejlevnější zmetky, které se tváří, že fungují. Tohle je celospolečenská nálada, která podle mého názoru částečně pramení právě v IT a přesvědčení, že člověk se má především bavit a ne pracovat a že podstatný není vnitřek, ale stačí povrchní pseudokrása.

Před časem jsem v Kolíně nad Rýnem viděl věc, která mě nutila se zamyslet. Na místní katedrále jsem vystoupal na tu cca 100 m vysokou věž. Nahoře na téměř nepřístupném ochozu jsem se trochu vyklonil a všiml si za rohem části sochy. Ta socha nemůže být zespoda vidět. Není celá vidět ani z toho ochozu, což je místo nejbližší. Jediný, kdo ji může vidět je tak leda parašutista, který to nevybere a padá na věž. Přesto tam je a ta část, co jsem viděl je detailně zpracovaná, jako asi celek. Dneska by v tom místě nejspíš nebyla pořádně udělaná ani střecha, protože si toho nikdo nevšimne.

Co není vidět, to může být z jakéhokoliv aušusu. Naleštěný povrch a uvnitř shnilý sotva držící zmetek. Funguje to i u software. Userinterface barevný a "krásný", vnitřní funkčnost ale nespolehlivá nebo dokonce nesprávná... Umělohmotně dokonalá kráska na povrchu naleštěná nejmodernějším makeupem, uvnitř blbec jehož hloupost se nebe dotýká...

Je toho víc, ale myslím, že řešení paradoxně není v silách IT. Rozhodně nestačí jen používat IPv6. Jestliže udělám zmetek a skryji ho v dostatečně velkém adresním prostoru, je to totéž jako když si malé dítě zakryje ručičkama oči a schová se pod stůl. Dřív nebo později ho stejně někdo najde...

Změna je potřeba v přemýšlení a chování lidí. Stvoření nemůže být lepší než stvořitel (vidíte, teologické otázky v IT...). Blb nemůže stvořit chytré zařízení...

4) Sochy byly drahé vždy a nikdy se proto nedělaly jen tak zbůhdarma, aby nebyly vidět. Zato se ve středověku téměř vždy stavělo bez nějakých větších systematických plánů a sochu skryla pozdní dostavba, podle wikipedie se uvedená katedrála stavěla neuvěřitelných 600 let.

Dobrý den
S tímto by jsem úplně nesouhlasil. Gotická katedrála byla stavěna věřícími v boha pro boha. Dle jejich tehdejšího pohledu byl bůh na nebesích. A proto stavba musela být nejkrásnější z jeho pohledu. Což z dnešního pohledu vypadá ne zcela pochopitelně neboť z pohledu lidí bylo mnoho detailů pro lidi neviditelných. Nicméně pro ně tyto detaily ani vidět být neměli. Adresát byl jiný.

To je zcela slepá cesta, sochy na katedrálách a dalších se zásadně stavěly a staví tak, aby to viděli lidé.

Úplně 100% bych si tím jist nebyl. Nevím jak sochy, ale třeba Santiniho kostel na Zelené hoře při pohledu shora ukazuje o investorovi stavby mnohem víc informací než je vidět ze země. To samé některé barokní aleje jsou budované tak, aby byly hezké shora.
Viz: Jiří Sádlo, Krajina a revoluce. Ale pravdou je, že socha je trošku menší objekt.

Souhlasím, jen bych ty humanitní vědy nepřeceňoval. Myslím, že k tomuto nemají moc co říci.
Tady chybí hlavně elementární poctivost a technická vzdělanost a to, čemu se v řemeslech říkalo fortelná práce. Spousta záležitostí je bohužel poháněna hlavně lidskou blbostí a tupým kšeftem.
Internet věcí...co to vlastně je? Hlavně zoufalá snaha výrobců vnutit uživatelům další víceméně neužitečný brak, za který budou platit. A ty opravdu přínosné záležitosti kolem toho se ztratí pod nánosem smetí. Bude se dále navyšovat kapacita sítí jen proto, aby byly schopné přenášet další neužitečná data, poroste v nich chaos...

Sociální a humanitní vědy? Upadl si na hlavičku? Ty nemaji k technickým problémům co říci.

Na to ale není potřeba žadný humanitní pavědec.

Děkuji. Lepší ukázku vzorového IT omezence pro podložení mého argumentu jsem si přát nemohl... :-)

Mají mnoho co říci - ona bezpečnost, s tím související např. soukromí! Nebo třeba společenské chování při používání nových věcí jako mobilní telefony... atd.
To je ale těžko vysvětlovat informatikovi, který je v lepším případě všeobecně nevzdělaný (a ještě je na to pyšný!), v horším stojí za hovno i jako ten informatik. Jako jsem kdysi parafrázoval větou „ekonom je dobrý sluha, ale zlý pán“, to samé platí pro informatiky - informatika nemůže řídit život, protože jsou věci, které ji přesahují.

Mohl bys trochu rozvést tu trojku? Co konkrétně máš na mysli?

"Blb nemůže stvořit chytré zařízení..."
Může. Můžeme se hádat o tom, jak moc je to pravděpodobné, ale může.

Ad 3) No, konkrétní příklady, to je docela těžké, ale zkusím: IT už v rámci umělé inteligence dost úspěšně využívá jiné přírodovědné obory, konkrétně biologii. Genetické algoritmy jsou de facto klasická evoluce zapsaná algoritmem. Z oblasti humanitních věd nevím o ničem, co by informatika využila. Jednoduchá argumentace by byla, že to může být i "nepoužitelností" nebo "zbytečností" humanitních objevů, ale to si nemyslím.

Příkladem filosoficko-teologické otázky v IT je například otázka stvoření a jsoucna v objektovém programování. Problematika pochopení toho, jak ve Squeaku/Smalltalku fungují metatřídy, to je dost blízké. Podobně jako otázka mnohonásobné dědičnosti (C++ vs. Java) je pěkný příklad otázky ze sociologie/an­tropologie. V počítačových sítích vyvstal nový prostor paradoxně bez pevných pravidel "etikety", tak jako vznikl na světě. Myslím si, že problematika kyberzločinu a kyberválek by se měla studovat s ohledem na znalosti z politologie, psychologie, sociologie atd...

Uznávám, že tu skrývám i přesně opačný problém a sice že tak jako zarytí ajťáci ignorují humanitní vědy, protože jim nerozumí a museli by se učit úplně jiný přístup k vědě, tak svorně i humanitní vědy ignorují IT, protože tomu nerozumí a nechtějí se učit exaktní, deterministrický (algoritmický) přístup. Navíc IT je paradoxně právě oblastí, kde je nezbytná spolupráce s jinými obory a pochopení látky jiných oborů. Akorát zatím se používá jen biologie, medicína, fyzika atd.

Ad "Blb nemůže stvořit chytré zařízení":
no ano, takhle zjednodušené tvrzení je zavádějící, ale principiálně mi jde o toto: algoritmus je deterministický, je to posloupnost kroků/instrukcí. Abych stvořil chytrý algoritmus, musím ho sám být schopen pochopit a zapsat. Existuje sice ještě alternativa náhody, kdy budu tak dlouho skládat instrukce za sebe, až se to začne "chovat chytře", ale ve chvíli kdy jsem nebyl schopen ten chytrý algoritmus pochopit a zapsat, ho stejně nebudu schopen rozpoznat i kdybych ho vytvořil nahodile, protože mu nebudu rozumět. Můžeme se bavit o evoluci, ale pak je potřeba si specifikovat pojmy "blb" a "chytré zařízení". Jestliže je někdo schopen vytvořit systém schopný evoluce, pak jistě není blb...

No nevím, myslím si, že přesně takový přístup je pak zdrojem oněch problémů s nekvalitním kódem.

Ano, jedna věc je např. nastavení omezujících podmínek a nechat běžet výpočet tak, aby je splňoval... Dejme tomu, jenže to vyžaduje zadefinování těch omezujících podmínek, tzn. autor musí vědět, čeho chce dosáhnout a i když nerozumí postupu, rozumí alespoň požadavkům na cílový stav.

Jinak "stačí otestovat, zda se pro nějaký vstupní subset chová korektně" popírá nezbytnou vlastnost algoritmu a sice korektnost. Nestačí, aby byl korektní jen pro "nějaký subset". Nejsem si jistý, jestli je rozumné programovat tímhle způsobem. Řídící software pro letadla se chová korektně od výšky 0 po 200 metrů, tak s tím vzlítneme? Překročíme 200 metrů algoritmus vypne všechny motory...

Jinak uznávám, že mi chybí potřebné znalosti z logického programování a programování s omezujícími podmínkami, což je oblast, která se toho úzce týká.

Je škoda, že věda je tak rozvinutá, že člověk už není schopen ji celou ani v základu pojmout...

Existuje sice ještě alternativa náhody, kdy budu tak dlouho skládat instrukce za sebe, až se to začne "chovat chytře", ale ve chvíli kdy jsem nebyl schopen ten chytrý algoritmus pochopit a zapsat, ho stejně nebudu schopen rozpoznat i kdybych ho vytvořil nahodile, protože mu nebudu rozumět.

Přesně takhle se ale dělají neuronové sítě pro rozpoznávání obrazů, vzorů, atd. Pospojuje se pár neuronů, chvilku se trénují a pak najednou začnou dělat to, co se od nich chce. Nikdo nemá ani páru, jak to opravdu funguje, jen několik málo lidí má možná mlhavé tušení, jak by to asi tak mohlo být.

Podobně se zkoušely dělat návrhy hradlových polí evolučními algoritmy. Vyšla hradlová pole, která fungovala, ale nikdo nevěděl proč.

Jsem si poměrně jistý, že "nikdo nevěděl proč" není úplně pravdivé tvrzení...

Jedna věc je, když tomu nerozumí autor, druhá věc je když si s tím někdo hraje, "nějak" to nastaví a "něco" z toho vyleze a třetí věc je, když kolegové nebo publikum v aule zírá, co ten algoritmus vyrobil a nerozumí, protože si nepřečetlo skripta před přednáškou a nemá dostatečné základy pro porozumění přednášejícímu...

Pokud se nemýlím, neuronové sítě používají hodnotící funkce a výpočet chyby v populaci ke zhodnocení korektnosti výstupu, případně v rámci genetických algoritmů k selekci.

Blb nedokáže korektně nastavit hodnotící funkci a proto mu pravděpodobně polezou ven zmetky. I kdyby ne a vylezlo něco, co je (zdánlivě) korektní, nedokáže to rozhodnout, jelikož to nedokázal zhodnotit.

Pokud jsem schopen sestavit korektní hodnotící funkci, pak systému rozumím bez ohledu na to, že nevím, proč z něj vylezly zrovna ty parametry, které to dalo. Podstatné je, že ty parametry byly získány na základě pochopené hodnotící funkce a jsou s ní v souladu. To, že nemám čas provádět simulaci ručně neznamená, že nerozumím principu...

Se vším souhlasím. Jen mi pořád vrtá hlavou, jak nedělat programové zmetky. Na to neexistuje snad žádná literatura. Jediné co jsem kdy četl je kniha "Co programátory ve škole neučí". Mimo to, jak asi víte, tak není možné nikdy vytvořit 100% spolehlivý a už vůbec bezpečný program.

Jo, ten je relativně dobrej, ale spíš s soustředí na Javu a ne vždycky je to aplikovatelný jinde.

Raděj mám Code Complete II od Mc Connela. Je to čtení na trochu delší dobu, ale spousta zajímavých postřehů a donutí člověka myslet...

No a pak bylo něco o DDT/Iconix, z hlavy si nevzpomenu. Ale docela inspirativní pro strategie testování. Jenom to nesmí člověk brát mo doslova, byla to óda na DDT a nedostatky umně maskovali.

Jednoduše. Nepsat. Generovat.

Komunikační protokol, to je sada zpráv. Řekněme, že by jich bylo 50, v každé pět parametrů a společná hlavička. Napsat samotný parsování protokolu v C je otročina a kdo se bude psát s unit testama?

Pro každou zprácu je potřeba udělat testy, kde bude
- Správná délka dat
- Víc dat pro daný typ zprávy (buffer overflow)
- Nekompletní zpráva
- Simulace chyby zabezpečení

Potom pro každý parametr
- kontrola validace (řekněme 100 hodnot v průměru)
- minimum a maximum
- korektní uložení do aplikace
- notifikace o změně

To je 5*105+4 = 529 testů/zprávu. Pro 50 zpráv 26450dílčích testů jenom pro korektní příjem dat.

Při tom pro 5*50 parametrů by to bylo 250 validačních funkcí + 50 parsovacích funkcí + dispatcher + validace hlaviček + CRC, + ... Počítejme 350 funkcí a kdekoliv může být chyba. Viděl jsem takový parsery na 25kLOC a víc.

Při tom stačí protokol popsat abstraktně, ale ve strojově čitelné formě, prohnat skriptíkem a vyjedou unit testy i kostra parseru bez překlepů. Za pět minut vytvořeno a otestováno...

Je to věda. Postupů a přístupů je řada, mnohé dokonce z dob před počítači (diagnostika a spolehlivost je obor starý pár set let). Vydá to na celou knihovnu. Důležité je ale hlavně myšlení. Pracovat s tím, že nic není spolehlivé, nic není bezpečné a všechno se pokazí. A už od začátku s tím počítat a tomu se přizpůsobit. Ale to z knížky nenačtete, na to je potřeba najít společnost, která si na tom zakládá a chvíli v tom žít. Osobně jsem měl to štěstí, že jsem začínal ve společnosti, co vytváří programy pro řízení údržby v jaderných elektrárnách. Pro tuto metodiku vývoje SW se používá název "fault tolerant".

Proto docela pláču, když někdo přeceňuje unit testy nebo předpokládá, že spolehlivost zlepší kontrolou vstupních parametrů. Protože jádro spolehlivosti není v tom, zjistit, že je něco špatně, ale v tom, umět se s tím vypořádat nebo to dokonce opravit. Kdykoliv se setkám s programem, který jen oznámí "general exception, call administrator" a vypne se, tak si podvědomě řeknu: bum.

Zkrátka: chyby byly, jsou a budou. Cestu nevidím v tom, vytvářet bezchybný software a hardware. Já cestu vidím v tom, vytvářet software, co dokáže chyby detekovat a vypořádat se s nimi.

Smutná pravda, bohužel. Sám programuji v oboru embedded sw a u zařízení, která by měla být jakýmsi technickým etalonem jsem nucen více řešit vzhled než funkcionalitu. "Ono to úplně nefunguje? To nevadí, hlavně že to pro marketing bude vypadat dobře ..."

Divný svět, kde se řemeslo a fortel považují div ne za sprostá slova :-(