OT: software - zaujimave citanie

[Milan B.]

Uz to zacina byt dlhe, tak niektore casti vyhodim

On 29. 9. 2010 21:24, Ales Prochaska wrote:

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

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

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

Ale k veci: Staci. Len nie je efektivny. To su dve rozne veci.
>
> To bychom se asi špatně pochopili. Programátor samozřejmě musí znát
> algoritmy (aspoň by si měl přečist Knutha :-)) a musí být schopen je
> implementovat v každém jazyce který zná. Ale narážím na techniky,
> které neznáte dokud je za vás někdo nevymyslí a nesdělí vám je
> prostřednictvím programovacího jazyka.
>
Techniky a algoritmy sa oznamuju inym sposobom, ako pomocou 
programovacieho jazyka. To ako keby ste cakali, ze matematika sa bude 
sirit prostrednictvom kalkulacky.

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

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

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.


> Když jazyk nepodporuje makra tak ... ale ne, to už by byla podpásovka
> :-)
>

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


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


>> Hint: Tu je vhodne miesto na protiargumenty plne TLA ako je  TCO, TTM  a
>> vplyv programovacieho jazyka na dosiahnutie ich vysokych hodnot ....
> ?
>
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.


> Nevyrobil. Umřel by někde u kolen :-)
>
Nie. Najal by viac pomocnikov, ktory by to osekali. A preco si myslite, 
ze dlato z nekvalitneho zeleza je lepsie ako diamant ?

>> Objav dlata nebol asi ten najdolezitejsi dovod, preco vznikol David.
> Dá se to říc tak, že to byla podmínka nutná, nikoliv postačující :-)
>
Tak to urcite nie.
>> Michelangelo bol dolezity, nie to dlato a ani iny nastroj.

> Michelangelo bez kamene a dláta by byl jen ten šikovnej od sousedů co
> nám vymaloval hospodu.
>
A to uz vobec nie.

> Ales Prochaska
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.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/20100929/7d28c5b8/attachment.htm>