OT: software - zaujimave citanie

[Milan B.]

>> To nie su programatori. A nerobi sa s tym nic z inych dovodov - ucinne
>> metody na detekovanie chyb su drahe.
> Ale nejsou drahe. Staci pouzit vhodny programovaci jazyk a pulka chyb
> zmizi sama od sebe. Jenze ten jazyk nebude programatorovi "poskytovat
> volnost" a programatori je masove odmitaji. Proste je to takove
> zakladni lidske pravo, moci priradit dva ASCII znaky najednou do
> jednoho intu :-)
>

Su drahe.  Ucinne metody vyzaduju implemenatciu istych procesov a 
kontrolnych mechanizmov. A na to treba dalsich ludi, ktori tomu rozumeju 
- to znamena drahych ludi.

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?

>> Ach jo. Priklady ad absurdum. Neslo by to bez nich? Pridajme este GUI v
>> assembleri, rezervacny system v assembleri ... asi tomu nebudete verit,
>> ale kedysi sa cele operacne systemy pisali v assembleri - a fungovali a
>> boli hotove v realnom case ...
> Neslo by to bez nich protoze se snazim vysvetlit, ze i kdyz se v
> jazyku da formalne vzato naprogramovat vsechno tak presto muze byt
> prakticky nepouzitelny a na tu implementaci ma vliv. V realne praxi s
> realnymi programatory.
>
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.
>> Techniky a algoritmy sa oznamuju inym sposobom, ako pomocou
>> programovacieho jazyka. To ako keby ste cakali, ze matematika sa bude
>> sirit prostrednictvom kalkulacky.
> Jak se lidi naucili pouzivat oop? Precetli si vysoce teoretickou praci
> nejakeho univerzitniho teoretika nebo si stahli C++ a zacali bastlit
> oop programy?
>
Pokial sa niekto ucil OOP podla C++, tak OOP nerozumie. Vyraz "bastlit 
oop program" je v tomto pripade mimoriadne vystizny.

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?

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.


>>> To myslím zcela vážně a o tom je celá debata :-)
>>>
>>> Když jazyk nepodporuje výjimky, tak budete muset ošetřovat chyby
>>> jinak, jestli nechcete aby vám to vystřelilo na "zero divide" :-)
>>>
>> Ano, budem chyby osetrovat inym sposobom. Ale to ze jazyk nepodporuje
>> vynimky, neznamena, ze chyba nebude osetrena. O tomto je ta debata.
> Klidne to muze znamenat i neosetrene chyby, lidi (i profici) to obcas
> radi odflaknou. Ale rozhodne to bude znamenat vetsi pracnost a vetsi
> pracnost bude znamenat priblizeni k limitu kdy program v danem case s
> danymi lidmi nezvladnu udelat, coz znamena praktickou neresitelnost
> problemu. Ja se samozrejme pohybuji ve svete smluv, dodacich lhut,
> prejimacich testu, seznamu zavad a podobnych radustek, ktere celkem
> ostre rikaji co jde a co nejde.
>
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.


>> IMHO ak naprogramujem nieco tak, ze nastane delenie nulou, tak mam z
>> principu zly algoritmus. Taketo pouzivanie vynimiek ako metody
>> programovania je velmi zla praktika, pretoze presuva riesenie chyby z
>> miesta jej vzniku niekam inam.
> Nemusim mit spatny algoritmus, staci nacist spatna data - a k tomu
> muze dojit i prostou programatorskou chybou. Ta vyjimka deleni nulou
> (a rada dalsich, podobne "blbych") ma sve opodstatneni treba u
> programu ktere se musi umet zotavit i z run-time chyb - a nemit v
> jazyku system vyjimek tak by se musel osetrovat kdejaky pitomy vypocet
> a tam by vzdycky dochazelo k chybam.
>
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 :).

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.

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.

Pozn. Aby nedoslo k nedorozumeniu - nezamienat assertions s osetrenim 
vstupnych parametrov.

> O tom nahodou neco vim a verte mi, ze programovaci jazyk ma velice
> velky vliv na rychlost hledani chyb a omezeni jejich vzniku. Drobny
> priklad: jsou jazyky, kde kdyz zavolate funkci (podprogram, proceduru,
> metodu, predate zpravu) se spatnym poctem parametru tak se nic nestane
> (az na to, ze to dava spatne vysledky - nekdy). A jsou jine, kde vam
> to uz pri prekladu rekne, ze tudy ne. A tohle je nesmirne casta chyba
> ve velkych projektech, kdy nekdo zmeni interface modulu ci komponenty
> a pres vsechny softwarove podpory ktere se pouzivaji pro rizeni
> projektu to proste neda vedet ostatnim. Rozumny programovaci jazyk ma
> vestavene (=jazykem definovane) moznosti jak kolizi interface
> rozpoznat a ohlasit. Nerozumny jazyk vas to proste necha hledat...
> Nebo pouzit nadstavbu ktera castecne zaplatuje to, co se melo primo
> vyresit o uroven niz (ted mluvim o refactoringovych nastrojich :-)).
>
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.

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.

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

> 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.

> Ales Prochaska
>
>
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 :)


> _______________________________________________
> HW-list mailing list  -  sponsored bywww.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20100930/eaeea3c8/attachment.htm>