<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<blockquote type="cite">
<pre wrap="">To nie su programatori. A nerobi sa s tym nic z inych dovodov - ucinne
metody na detekovanie chyb su drahe.
</pre>
</blockquote>
<pre wrap="">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 :-)
</pre>
</blockquote>
<br>
Su drahe. Ucinne metody vyzaduju implemenatciu istych procesov a
kontrolnych mechanizmov. A na to treba dalsich ludi, ktori tomu
rozumeju - to znamena drahych ludi.<br>
<br>
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".<br>
<br>
Mimochodom, preco mi stale podsuvate nejake C-cko? Spomenul som ho
snad niekedy?<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<blockquote type="cite">
<pre wrap="">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 ...
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
To uz odbiehate od povodneho problemu - a to od tvrdenia ze aby
programator mohol pouzit urcite metody, tak <b>musi</b> existovat
jazyk ktory ich podporuje. Nemusi. Take metody sa daju implementovat
aj v jazyku, ktory ich nepodporuje. Len to nemusi vzdy jednoduche.<br>
<br>
Ale nie nemozne.<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<blockquote type="cite">
<pre wrap="">Techniky a algoritmy sa oznamuju inym sposobom, ako pomocou
programovacieho jazyka. To ako keby ste cakali, ze matematika sa bude
sirit prostrednictvom kalkulacky.
</pre>
</blockquote>
<pre wrap="">Jak se lidi naucili pouzivat oop? Precetli si vysoce teoretickou praci
nejakeho univerzitniho teoretika nebo si stahli C++ a zacali bastlit
oop programy?
</pre>
</blockquote>
Pokial sa niekto ucil OOP podla C++, tak OOP nerozumie. Vyraz
"bastlit oop program" je v tomto pripade mimoriadne vystizny.<br>
<br>
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?<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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" :-)
</pre>
</blockquote>
</blockquote>
<blockquote type="cite">
<pre wrap="">Ano, budem chyby osetrovat inym sposobom. Ale to ze jazyk nepodporuje
vynimky, neznamena, ze chyba nebude osetrena. O tomto je ta debata.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
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 .<br>
<br>
Nepopieram ze vynimky mozu priniest iste zjednodusenie, ale
prinasaju ak iste negativne javy - ako je napriklad prenasanie
zodpovednosti za spracovanie chyby. <br>
<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
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 :).<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
A ziadny system vynimiek ani programovaci jazyk toto nespasi.<br>
<br>
Pozn. Aby nedoslo k nedorozumeniu - nezamienat assertions s
osetrenim vstupnych parametrov.<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<pre wrap="">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 :-)).
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Ale mam dojem, za sa tu vychadza z predpokladu, ze kazdy pouziva
nastroje tym najhorsim moznym sposbom, ktory tie nastroje umoznia.<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<pre wrap="">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 :-)))
</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<pre wrap="">Ales Prochaska
</pre>
</blockquote>
PS. K tym TLA: prave mi dosiel mail od Mentora so subjektom:
Reducing Design Cost - Improve ROI With Concurrent DFM Verification
- Web Seminar<br>
<br>
Dve TLA v jednej vete - vrchol blaha :) <br>
<br>
<br>
<blockquote cite="mid:1592136413.20100930031839@alsoft.cz"
type="cite">
<pre wrap="">
_______________________________________________
HW-list mailing list - sponsored by <a class="moz-txt-link-abbreviated" href="http://www.HW.cz">www.HW.cz</a>
<a class="moz-txt-link-abbreviated" href="mailto:Hw-list@list.hw.cz">Hw-list@list.hw.cz</a>
<a class="moz-txt-link-freetext" href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
</pre>
</blockquote>
<br>
</body>
</html>