OT: software - zaujimave citanie

[Ales Prochaska]

> Programovaci jazyk nie je samospasitelny. Ale mate do istej miery pravdu
> - pri dnesnom sposobe riadenia projektov, kde sa namiesto programatorov
> prijimaju lacne, a neschopne "resources" so zivotnostou na projekte od 3
> do 6 mesiacov, je treba pouzivat jazyky ktore eliminuju chyby typu 
> "blbec, ktory nevie programovat".

> Mimochodom, preco mi stale podsuvate nejake C-cko? Spomenul som ho snad
> niekedy?

Ja to beru jako obecnou debatu o vlastnostech programovacich jazyku. A
cecko je nadherny, exemplarni souhrn vseho co na nich povazuji za
nespravne :-) Ale explicitne jsem cecko nejmenoval :-)

> To uz odbiehate od povodneho problemu - a to od tvrdenia ze aby
> programator mohol pouzit urcite metody, tak *musi* existovat jazyk ktory
> ich podporuje. Nemusi. Take metody sa daju implementovat aj v jazyku, 
> ktory ich nepodporuje. Len to nemusi vzdy jednoduche.
> Ale nie nemozne.

Ale o tom mluvim. To, ze to neni jednoduche pro mne znamena, ze to je
prakticky (za daneho stavu casu, penez, poctu lidi a jejich
zkusenosti) vyloucene. Ze to principialne jde o tom nepochybuji.

> Pokial sa niekto ucil OOP podla C++, tak OOP nerozumie. Vyraz "bastlit
> oop program" je v tomto pripade mimoriadne vystizny.

Ale to je realita :-)

> A zase tu mame extremny priklad - ono existuje cele spektrum vynikajucej
> literatury leziacej niekde na polceste medzi vysoko teoretickymi pracami
> a manualom k C++. Ale kto by to cital, vsak?

Presne tak :-)

> Mimochodom, snad si nemyslite ze OOP prislo s C++? Pozrite si 
> Smalltalk-80 (rok 1979) - uplna objektova bestia (len skoda tej 
> syntaxe). Alebo si pozrite prezentaciu Sketchpadu od Ivana Sutherlanda
> (rok 1963) - krasna implementacia objektoveho pristupu.

Sketchpad neznam, podivam se. O Smalltalku vim, ale zaroven vim o tom,
ze lidi zacali pouzivat oop pristup az kdyz byl implementovan do c++.

> Ale aj vynimku je treba zachytit a osetrit. Co je samozrejme vec ktora
> sa bude odflakavat, presne tak isto ako akykolvek iny sposob osetrovania
> chyb .

> Nepopieram ze vynimky mozu priniest iste zjednodusenie, ale prinasaju ak
> iste negativne javy - ako je napriklad prenasanie zodpovednosti za 
> spracovanie chyby.

To byl zejmena priklad komplexni vlastnosti jazyka kterou je obtizne
nahradit. Ze se to s tim musi umet aby to k necemu vedlo, o tom
nepochybuji. 

> Ak sa nacitaju nespravne data - to ma byt odchytene snad pred tym, ako
> sa nad nimi zahaji vypocet. Realizovat vypocet nad zlymi datami a 
> spoliehat sa na to, ze sa bude delit nulou je trochu absurdne. Co ak  sa
> nacitaju zle data a k deleniu nulou (alebo akejkolvek inej vynimke) 
> nedojde? Mame zly vysledok - ale vsetci su vysmiati :).

Ma se, ale zrovna tohle je vec ktera se blbe testuje, blbe formalne
popisuje a delaji se v ni chyby. Proste se delaji, kazdy vetsi program
neni nic jineho nez sbirka chyb cekajicich na nejmene vhodnou
prilezitost :-) A za kazdou vec ktera pocet chyb pomuze snizit jsme
vdecny.

> Malo by sa to robit inac. Kazda jedna funkcia (alebo blok kodu) ma mat
> stanovene iste predpoklady za ktorych je vykonana spravne a dodat 
> vystup, ktory splna nejake predpoklady. Pokial vstupne predpoklady nie
> su splnene, tak sa musi generovat chyba. Obvykle sa to vyuzivaju 
> assertions. A pokial k tejto chybe dojde, tak sa jedna o zavaznu 
> neosetritelnu chybu programu, a malo by nastat nejake recovery 
> (reinicializacia dat, reinicializacia procesu, reboot, restart programu,
> odovzdanie riadenia standby systemu alebo jednoducho havaria programu 
> (ak o nic nejde)) - ale nechat bezat program ktory nefunguje spravne je
> nezodpovedne.

I v tom se delaji chyby. Jinak zastaveni programu neni zdaleka vzdycky
nejvhodnejsi reseni. Chyba muze nastat v nejake doplnkove funkci ale
prece nebudu restartovat bankovni system a neprerusim na nekolik hodin
transakce kdyz nastane chyba v necem co zavaznosti odpovida importu
jidelnicku ze zavodni kantyny.

> Vstupy z okoliteho sveta (vratane uzivatelskeho vstupu) je ina kategoria
> - to sem nepatri. To je pokryte vetou "musi dodat vystup, ktory splna 
> iste predpoklady. Napriklad neprijat teplotu 250 stupnov od izboveho 
> teplomera alebo zadanie veku 180 rokov od uzivatela.

> Kazdopadne,  akykolvek vysledok na zaklade vstupov nesplnajucich 
> predpoklady je neprijatelny - nevieme ci je spravny alebo nespravny. A
> nespravny vysledok na zaklade vstupov splnajucic predpoklady znamena 
> hrubu chybu v programe.

> A ziadny system vynimiek ani programovaci jazyk toto nespasi.

Spasi.

type teplota is new range 0..60

a v okamziku kdyz kdykolikv jakkoliv, blbe osetrenym vstupem,
nasobenim spravne teploty poctem teplomeru v mistnosti nebo prictenim
kalibracni konstanty teplomeru uvedene v milimetrech priradim do typu
teplota formalne nespravnou hodnotu tak vyjimka - dejme tomu -
sestreli cely task "monitorovani teploty v obyvaku" ale nesestreli mi
ekvitermni regulaci kotle a neumrznou mi kvuli tomu rybicky.

> Evidentne zase hovorite o C. Ale aj moderne kompilatory C maju
> implementovane mnohe kontroly. Ak ich niekto vypina, tak je nie je 
> problem samotneho toho jazyka, ale nezodpovedneho pristupu. To, ze 
> povodne verzie C boli blizsie k strukturovanemu assembleru ako k 
> vyssiemu jazyku je historicky fakt. Ale odvtedy presiel ako jazyk, tak
> (a to hlavne) kompilatory istym vyvojom a obsahuju nastroje na 
> eliminaciu mnohych spominanych problemov.

Nemluvim o C, tuhle hruzu jsme uz videl leckde. Refactoring je
minimalne ze 2/3 zaplata na spatne navrzeny programovaci jazyk.

> A ano, trebars tomu C-cku chybaju iste kontrolne mechanizmy, co sa tyka
> kontroly interface. Ale nie na urovni jazyka alebo kompilatora, skor na
> urovni vygenerovanych objektovych suborov a kniznic - teda na urovni 
> linkovania. Ale tieto problemy predstavuju nepatrny zlomok  problemov a
> vyzaduju brutalne zlyhanie projektoveho managementu.

No, ceckovy pristup k linkovani je, kdyz uz na to narazite,
prinejmensim zvlastni a k delani chyb primo vyzyva:-) Na management
bych to nehazel, to jsou vetsinou programatorske chyby, kdyz se
prilinkuje neco jineho nez melo.

> Ale mam dojem, za sa tu vychadza z predpokladu, ze kazdy pouziva 
> nastroje tym najhorsim moznym sposbom, ktory tie nastroje umoznia.

To myslim ne, ale kazdy dela chyby. Dokonce i ja jsem myslim uz nekdy
v zivote udelal v programu chybu :-)

>> Jestli narazite na tech deset mega radek v holem cecku tak to
>> samozrejme byla nadsazka. Ve skutecnosti byste jich myslim nedal ani
>> milion aniz byste musel resit balik znacnych problemu :-)))
>>
> Jasne. Ale nesuviseli by s pouzitym jazykom. Som si isty, ze by som 
> nestratil kontrolu ani nad velkym projektom v assembleri. A viete preco?
> Nespolieham sa, ze ma programovaci jazyk uchrani od chyb.

Ovsem, dobry projekt je zaklad. Ale budete urcite rad, kdyz za vas
nejake najde - a i ja to beru takhle.

> PS. K tym TLA: prave mi dosiel mail od Mentora so subjektom: Reducing 
> Design Cost - Improve ROI With Concurrent DFM Verification - Web Seminar

> Dve TLA v jednej vete - vrchol blaha :)

:-)

Ales Prochaska