OT: software - zaujimave citanie

[Ales Prochaska]

> Aj ked dalekohlad je podstatnou zlozkou astronomie, astronomia nie je
> veda o dalekohladoch (volne parafrazovany EWD)

Ale kdyby astronomové/programátoři neměli dalekohledy/programovací
jazyky tak by toho jen velmi málo vyzkoumali/naprogramovali a čím mají
lepší dalekohledy/jazyky tím je jejich potenciál něco
vyzkoumat/naprogramovat vyšší.

>> Jazykovědci (přes přirozené jazyky) se už shodli, že jazyk determinuje myšlení
> Ale asi v tom zmysle, ze jazyk dokaze vyjadrit javy a myslienky, ktorymi
> spolocnost zije a ktore ju formuju - clovek ma moznost prijimat 
> informacie a na ich zaklade sa moze formovat jeho myslenie. Chcete snad
> povedat ze Francuz rozmysla zasadne inac ako Madar?

Ano - i když ne zásadně. Ale třeba Evropan a Číňan už myslí o dost
jinak, když Evropan popisuje scény tak začíná popředím, Číňan pozadím
a tomuto odpovádá i struktura vět v indoevropských jazycích a
činštině. Nicméně abych zůstal u programování: když budete mít jazyk
který nemumí pointery, tak spíš vyřešíte problém bez pointerů než
abyste si udělal veliké pole a nad ním vybudoval znova všechny funkce
které už jazyk má, ale tentokrát i s pointery... Samozřejmě,
implementujete - řekněme - cokoliv, ale různými způsoby. Když budete
vymýšlet nové algoritmy, nejspíš je budete vymýšlet s vidinou cílového
jazyka v pozadí.

> Niekedy v 60-tych (plus-minus) rokoch, ked zlozitost programov dosiahla
> urcitu hranicu, experti dospeli k zaveru, ze problemom su programovacie
> jazyky, ktore maju odlisnu strukturu od jazykov ludskych. A tak zacali
> vznikat ukecane jazyky ako napriklad COBOL. Experti sa mylili - problem
> bol v niecom inom.

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

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

> Takyto nazor - ze jazyk je dolezity - vedie k niecomu opacnemu - dnesny
> programator-absolvent dokaze naprogramovat len to, co mu ponuka jazyk a
> prilahle kniznice a nedokaze prekrocit istu mentalnu hranicu. Moze to 
> byt sposobene aj tym, ze na uz skolach sa vyuka programovania viaze na
> konkretne produkty a jazyky. Tak sa mi mari, ze za mojich mladych cias
> sme sa vseobecne programovanie ucili na abstraktnom jazyku PL/0 (a 
> neskor ako semestralnu pracu sme mali napisat jeho kompilator a 
> interpreter generovaneho p-kodu).

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.

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.

>>   Aby programátor mohl (a uměl) použít určité
>> metody a postupy, tak musí existovat jazyk který je podporuje.

> Paneboze, to snad nemyslite vazne? Ked jazyk nepodporuje komplexne
> cisla, tak to znamena, ze v komplexnych cislach nebudeme pocitat?
> Alebo ak jazyk nepodporuje maticove operacie operacie, tak ich
> vylucime maticove operacie nebudeme pouzivat? Ked neobsahuje OOP,
> tak sa v nom neda objektovo programovat (ako napriklad GTK+)?

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

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

> Kdesi som cital priklad, ze nejaky novozelandsky primitivny kmen ma
> jednoslovny vyraz pre "staru vacicu, ktora vyliezla na strom a znovu z
> neho zliezla" a uplne iny jednoslovny vyraz pre "staru vacicu, ktora 
> vyliezla na strom a ostala na nom". Na zaklade vasej argumentacie  by sa
> dalo tvrdit, ze nase moderne jazyky nedokazu popisat chovanie starej 
> vacice. Dokazu. Len na to potrebuju viac slov.

> A to iste plati o programovacich jazykoch. Su to len nastroje. Niektore
> sikovnejsie, niektore menej. Ale su to len nastroje. A nastroj nesmie 
> urcovat vysledok. Ak to dovolime, ideme do p...pekla.

Nástroj určuje výsledek. Já vám na CNC frézce udělám za pět minut to
co byste pilkou a pilníkem nevyrobil za celý život. A v assembleru
zase nenapíšete systém pro mezinárodní rezervaci letenek.

> Ja vobec nechapem to vyzdvihovanie jazyka - ak potrebujem nieco 
> naprogramovat, tak to naprogramujem (skor ci neskor). Ak pre riesenie 
> nie je moj oblubeny jazyk dostatocne komfortny, tak pouzijem nieco ine
> (nedavno som programoval grafy v PostScripte - tym myslim priamo v 
> jazyku Postscript,  nemyslim tym, ze som niecim generoval PostScript).
> Ale nikdy - opakujem nikdy - sa nestalo, ze by som nieco neurobil len 
> preto, ze to jazyk "nepodporuje".

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.

> Hint: Tu je vhodne miesto na protiargumenty plne TLA ako je  TCO, TTM  a
> vplyv programovacieho jazyka na dosiahnutie ich vysokych hodnot ....

?

>> Typický
>> případ je rozdíl (někdy velmi velký rozdíl) mezi přístupem
>> programátorů či analytiků zvyklých na konkrétní nebo naopak abstraktní
>> datové struktury.
>>
> Nechapem ako. Mohli by ste pojednat trochu obsirnejsie?

Principiální rozdíl je tento:

uvažovaní na úrovni konkrétních struktur: tady budu potřebovat dva
doublewordy a jeden int.

uvažovaní na úrovni abstraktních struktur: tady budu potřebovat tři
numerické proměnné, druhá nekompatibilní s první a třetí jako subtyp
druhé.

Jistě znáte oba přístupy a lidi kteří preferují buď jeden nebo druhý.

>> Ostatně ani Michelangelo by svého Davida nevyrobil bez vynálezu železa
>> na to dláto :-)
> Vyrobil. Pouzil by tvrdsi kamen ako nastroj. Napriklad diamant.

Nevyrobil. Umřel by někde u kolen :-)

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

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

Ales Prochaska