OT: software - zaujimave citanie

[Ales Prochaska]

>> Ti experti se tak moc nemýlili. COBOL byl na tehdejší dobu zajímavý
>> jazyk na zpracování složitě strukturovaných sekvenčních souborů a
>> rozvoji počítačů rozhodně pomohl. Bohužel determinoval myšlení
>> některých lidí natolik, že potom i v céčku psali cobolské programy
>> (jen globální proměnné apod.), ale ty programy měly statisíce řádků a
>> fungovaly.
>>
> Experti sa mylili. Mylili sa v tom, ze programatori stracali kontrolu 
> nad projektmi vdaka tomu, ze programovacie jazyky boli vzdialene ludskym
> jazykom. COBOL bol uvedeny ako priklad ukecaneho jazyka - nikto 
> nespochybnuje jeho vyhody v danom case.

Sama ukecanost neni na zavadu (aspon podle me). A osobne te
vzdalenosti lidskym jazykum docela rozumim. Samozrejme, Cobolska
koncepce "dopisu pocitaci" je opravdu lehce ujeta, ale v te dobe
nevedeli presne co vlastne chtit ani takovi geniove jako autori
Algolu, takze to bych nebral jako neco hrozneho. Ta ztrata kontroly
byla opravdu zpusobena tim, ze se museli piplat s bity misto aby
projektovali aplikace. A tyto jazyky jim to mely usnadnit.

>> Experti o pár let později identifikovali další problém a ten je platný
>> dodnes - nutnost zvládání chyb. Ten si ovšem řada programátorů -
>> mistrů světa odmítá připustit a podřídit se mu, takže se s tím ve
>> větším měřítku nic nedělá.
>>
> 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 :-)

>>> Pokial programovaci jazyk splna kriterium Turingovej kompletnosti , tak
>>> je dostatocnym prostriedkom na implementaciu cohokolvek a nemal by mat
>>> ziaden vplyv na implementaciu.

>> Formálně máte pravdu - jazyk zahnující pouze podmíněný skok a přičtení
>> jedničky by měl stačit na vyřešení jakéhokoliv problému, ale tak nějak
>> nestačí...
>>
> 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.

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

>> Asi neznáte Adu - doporučuji se jistou pasáž naučit a pravděpodoboně
>> mi pak uvěříte. Nejdřív si ale sepište na papír všechny metody
>> synchronizace paralelních procesů které znáte, pak si přečtěte metodu
>> "randezvous" a správu tasků z Ady (docela makačka na bednu to
>> pochopit) a pak si řeknete ejhle, tohle by se dalo skvěle využít na
>> tohle a tohle a vyplyne vám nové a jednodušší řešení starých problémů
>> se kterými jste se kdy potýkal. A to je přesně to co mám na mysli.
>> Určitě jste to už zažil, stačí si vzpomenout.
>>
> Myslite r*e*ndezvous? Je to ta klient/server implementacia volania 
> taskov? Kde jeden task (server) caka uspaty na zavolanie od klienta, 
> zobudi sa, porobi nieco a znova sa uspi a caka na nove spojenie?

> Ale ak je to tak, tak to nie je nic nove a ani nic zlozite. Ved tak 
> nejako su implementovane aj sokety v IP stacku, napriklad. Na to 
> nepotrebujem Adu aby mi povedala ze existuje tento sposob IPC ...

Ano, myslim rendezvous + zacleneni typu "task" do datovych struktur
Ady. Samozrejme na implementaci nic neni, takhle je implementovane
kdeco, myslim tim dosazenou uroven abstrakce.

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

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

> Ked nepodporuje makra, tak nepodporuje makra. Comu to vadi?

Ze se zase neda pouzit urcita trida programovacich technik. Dusledky
viz vyse. Makra jsme zvolil jako ukazku funkcionality ktera se opravdu
neda obejit.

>> Ale ano, já také naprogramuju bubblesort v Céčku, v Pascalu, ve
>> Fortranu, v Adě, v Cobolu, ve Flexu a když na to přijde tak i ve
>> skriptu pro řízení závlahového automatu, ale v okamžiku kdy budete v
>> plain C zkoušet naprogramovat systém o 10,000,000 řádků tak jste
>> prostě vedle a utopíte se v chybách (to hlavně!) a nedodržíte termín a
>> zákazník vás rozdupe.

> Presne tak isto sa utopim v chybach ako vy s tou vasou Adou alebo neviem
> s cim. Pretoze pri takychto projektoch musia nastupit trochu ine metody
> riadenia a spravovania projektov - a verte mi, nazov programovacieho 
> jazyka sa v nich nehra ziadnu ulohu.

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

> TLA = Three Letter Abbreviations (trojpismenove skratky) - vec, z ktorej
> su manageri na vrchole blaha. TCO - Total Costs of Ownership. TTM -  
> Time To Market - to su vsetko tie argumenty, ktore sa pouzivaju ked je
> treba obhajit pouzitie Javy, ARM-u dotnetu c-sharpu a podobne.

:-)

> Argument ak pouzijete ... nedodrzite termin patri do tejto kategorie.

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

Ales Prochaska