Vlákno názorů k článku Joy: radost z programování od Martin Soukup - Počítač má ulehčovat práci člověku, tak ať se...
-
tisnik (neregistrovaný)Kazdy programovaci jazyk vas k necemu nuti - k nejake zmene pri prevodu myslenek do zdrojoveho kodu. Snad nejvice se cloveku prispusobil Cobol, ale vysledkem byl peknej humus:-) Prechod na postfixovou nebo prefixovou notaci je IMHO docela snadny a nekterym jazykum tak doda na eleganci, cistote kodu atd. Nehlede na to, ze postfix (RPN) zvladnou i bezne ucetni - viz hodne oblibene kalkulatory od HP a naopak - vas oblibeny programovaci jazyk s velkou pravdepodobnosti stejne neni na 100% infixovy.
-
anonymní> Snad nejvice se cloveku prispusobil Cobol, ale vysledkem byl peknej humus:-)
Hmmm??? No ja si zas naopak myslim, ze COBOL nie je humus :-))) To o nom akurat tak hovoria ludia z akademickej pody, ktori v nom nikdy nerobili. Co potom poviete na SQL alebo ABAP? Tiez humus?
COBOL, SQL a ABAP su prakticke jazyky urcene na pracu s datami, takze su to jazyky inej kategorie ako jazyk tu spominany, ktory je akademicky a mozno prakticky pouzitelny na riadenie pristrojov. -
Miloš (neregistrovaný)Bryan Higman napsal ve své Studii programovacích jazyků z roku 1970, že COBOL bere ohled na lidi, kteří chápou výraz "MOVE X TO Y ADD BALANCE TO OLDTOTAL GIVING NEWTOTAL", ale nejsou schopni pochopit totéž pro "X=Y; NEWTOTAL=OLDTOTAL+BALANCE".
Že měl do značné míry pravdu jsem pochopil, když jsem viděl některé "výtvory" přeučených Cobolistů v jiném jazyce.
Celý COBOL byl založen na představě, že pokud bude programovací jazyk co nejvíce připomínat jazyk přirozený, bude programování hračkou. Poněkud se zapomnělo na to, že přirozený jazyk je tu k jinému účelu a k vyjádření algoritmů je tím nejméně vhodným prostředkem.
Ani SQL není zdaleka nejvhodnějším dotazovacím jazykem a etabloval se spíše z historických důvodů. Naštěstí tam už výše zmíněná snaha tak daleko nešla. -
Hodně záleží v čem člověk začne. Z basicu a assambleru na spectru jsem nechápal, jak je možné psát v Pascalu bez GOTO. Pro Pascalistu je C kód chaos. A první měsíc, kdy jsem přecházel z FoxPro na SQL jsem si nechápal, jak je možné existovat bez cyklu. Učebnici COBOLu jsem zavřel po deseti stránkách s pocitem blaha, že tohle mne minulo :) a více už jsem jí neotevřel. -
MikRom (neregistrovaný)> Učebnici COBOLu jsem zavřel po deseti stránkách s pocitem blaha, že tohle mne minulo :) a více už jsem jí neotevřel.
No to mas pravdu, ucit sa COBOL len tak nema zmysel. Neni to jazyk na nejake bastlenie doma. Nerobi to špás a okrem toho kompilatory su len komercne a prehnane drahe, takze myslim, ze aj toto velmi brzdi dnesny zaujem sirokej verejnosti a robi tento jazyk nepristupnym. Videl som sice aj nejaky OpenSource, ale neviem v akom stadiu je. Pretoze Cobol prisne zachovava spatnu kompatibilitu je to dost rozsiahly jazyk a napisat kompilator nie je hracka.
COBOL sa ma zmysel ucit, len ked ho budes pouzivat v praci. -
V nekterych pripadech by se cykly hodily, je jich minimum, ale jsou. Sice pri navrhu SQL byl cyklus vyrazen s tim, ze od toho je klientska aplikace, nicmene nakonec se do SQL dostal zadnimi vratky. Jednak v ulozenych procedurach diky kurzorum (coz je takove externi reseni), pak celkem prirozene SRF generovane funkce (napr. funkce generate_series, a pak jeste v analytickych funkcich a v CTE.
cyklus v SQL (PostgreSQL) SELECT 'Hello ' || to_char(i, '99') FROM generate_series(1,10) g(i);
Tyhle vymozenosti ale prisly az par let pote, co jsem si na SQL zvykal.
-
V teto jednoduche variante je zarucene. Poradi se rozhodi pouze v pripade, ze by se funkce generate_series pouzila nekde v poddotazu v kombinaci s ORDER. Jinak vsechny vestavene funkce nemaji zadne vedlejsi efekty, takze v tom by nemel byt problem. Neco jineho jsou vlastni funkce, kde se pri trose dobre vule da napsat funkce, kde zalezi na poradi. Potom se ale tak jako tak uz pouzivaji ulozene procedury a neni duvod proc by se nepouzil proceduralni FOR IN. Obecne SQL konstatuje, ze poradi je urceno pouze pokud se pouzije ORDER BY. Pokud databaze nezpracovava dotaz paralelne, tak neni moc prilezitosti k prohozeni poradi vuci fyzickemu ulozeni. Viz MySQL MyISAM, ktere typicky vraci stejne sety aniz by se pouzil ORDER BY. PostgreSQL to nezaruci, protoze UPDATE neni fakticky UPDATE, ale INSERT, cimz se zmeni fyzicke poradi dat. 8.3 ma zajimavou vlastnost, kdy LIMIT bez ORDER BY je ovlivnen skutecnosti, ze druha session nacetla nejaka vhodna data. Kdyz si reknu o jeden radek aniz bych specifikoval odkud, tak dostanu ten, ktery je zrovna v cache. To je ale relativne vyjimka. Navic materializovane tabulky ziskane SRF funkcemi mi nikdo dalsi neovlivni, jsou viditelne pouze v mem kontextu, v nich funguje jakasi pipe. Pridavam na konec a ctu ze zacatku, cimz se za normalnich okolnosti udrzuje poradi.
-
mikrom (neregistrovaný)> No jo, ale v tom SQL ten cyklus fakt chybi.
No a prave preto sa pouziva Embedded SQL v programovacich jazykoch - programovat len v samotnom SQL je utrpenie. Ja napriklad pouzivam COBOL + ESQL. Ked mam napriklad urobit SQL UDF (uzivatesku funkciu) ovela radsej robim externu SQL UDF, t.j. v inom jazyku ako SQL, napriklad v COBOLe /da sa napr. aj v Jave/ ako by som UDF pisal priamo v SQL.
Externa UDF sa mi totiz da bez problemov debugovat a SQL debugovat neviem. Na upresnenie - pracujem na IBM iSeries (aka AS/400) s databazou DB2. Mozno inde je to s programovanim v SQL ruzovejsie :-) -
Oracle ma debugger SQL funkci snad odjakziva, v roce 2001 jsem pracne rozchazel debugger v MSSQL (ale rozchodil), PostgreSQL od lonskeho roku. Jinak SQL ze zacatku dost boli, zvlast kdyz clovek uz neco napsal. Cela 90 leta byly nejvetsi bestsellery "SQL pro Cobolisty", kde se donekonecna vysvetlovalo, ze SQL neni COBOL :) - doporucuju clanky Joe Celka, ktery je spickovy odbornik na SQL a pritom byvaly cobolista.
Na druhou stranu dost casto byli cobolisti v ... nezaslouzene, ponevadz se migrovalo z COBOL databazi do SQL zpusobem 1:1, a SQL databaze chteji neco jineho nez stare COBOL db, a psat SQL ve spatne navrzene databazi je utrpeni. -
MikRom (neregistrovaný)Debugovanie SQL: V iSeries DB2 UDB je to tak, ze ked sa vytvori SQL-funkcia, system z nej vygeneruje C-program. Pri debugovani potom vidis ten vygenerovany C-zdrojak a nie SQL a ten C-zdrojak je omnoho komplikovanejsi ako bolo to povodne SQL :-) Naopak, pri pouziti ESQL v nejakom host-jazyku (COBOL, C,...) netreba nikdy priamo debugovat SQL, debuguje sa len host-jazyk. Prislusne SQL-SELECTy sa daju lahko vyskusat a staci si v overit len to ci prislusny FETCH naplnil ocakavane hosdnoty do host-premennych. To je dovod, preco radsej pisem v ESQL + host_jazyku ako v samotnom SQL.
COBOL nie je to najhorsie na databazu. Pouzivaju sa i divokejsie jazyky: RPG a PL/1.
SAP je relativne moderny system a ma jazyk ABAP, s ktorym som bol tiez konfrontovany a je to podla mna vylepseny COBOL + ESQL. -
Petr (neregistrovaný)Embedded SQL ma smysl pouze u neceho, co je z principu staticke a nemenne (resp. menene jen v cyklu maintenance). Normalni SQL muzu dostat na vstupu, muzu ho mit v konfiguraci, muzu ho dynamicky generovat z komponentu atd. Mnoho komercnich nastroju (napriklad na generovani reportu) vezme SQL text jako vstup. V zadnem z techto pripadu Embedded SQL proste nepouziju.
Formulovano z druheho konce potravniho retezce: Tam, kde z principu mam moznost provadet operace nad vracenym result setem, na neexistenci cyklu nenarazim. Ale nekam se proste nedostanu. -
MikRom (neregistrovaný)MOVE X TO Y sluzi na skopirovanie datoveho pola X do pola Y. Je to dost silna instrukcia, lebo ak polia X a Y su rozneho typu vykona sa automaticky typecasting. Mozno takto kopirovat aj cele datove struktury. Existuje este MOVE CORRESPONDING ktory kopiruje rovnomenne prvky struktury X do prvkov struktury Y.
Ak X a Y su len ciselne polia, mozes tiez napisat COMPUTE x = y :-)))
Co sa tyka tych verbalne popisanych aritmetickych operacii
ADD BALANCE TO OLDTOTAL GIVING NEWTOTAL
tak to je naozaj blbost. Bolo to zahrnute do jazyka v naivnej predstave aky sa priblizil ludskej reci. Drzia to tam zrejme len z dovodu spatnej kompatibility.
Kazdy kto v COBOLe programuje napise radsej
COMPUTE newtotal = oldtotal + balance
Co sa teda tyka aritmetiky je to dost exoticke, ze pred kazdu operaciu treba dat COMPUTE.
COBOL neni pre ludi, ktori potrebuju pisat zlozite algoritmy ale je pre ludi, ktori sa musia starat o mnozstvo dat.
Na druhej strane je ale COBOL velmi prisne standardizovany, a zachovava spatnu kompatibilitu - ja sa bezne stretavam s 15-rocnymi programami. A pri praci s databazou je COBOL velmi rychly.
Co sa tyka programatorov v COBOLe, tak to mas ako aj inde:-)
Myslim, ze v dnesnej dobe sa v COBOLe primarne jedna asi viac o udrziavanie starych aplikacii ako o pisanie novych. Preto mnohi programatori nepracuju na plny uvazok len v COBOLe, ale musia programovat aj v inych jazykoch, takze maju sirsi rozhlad.
Ano, navrh jazyka je zastaraly. Nechcem ho nijako zvlast obhajovat, ale je tu a musi sa s nim pracovat. To ze je tak dlho tu, ma zrejme svoje opodstatnenie. Nie je to ale ziadna tragedia, jak to z toho robia mnohi akademici. -
tom (neregistrovaný)Lua interne taky funguje na principu zasobnikoveho automatu (viz. jeji rozhrani v C pro pridavani vlastnich funkci, pripadne popis instrukci bytecode). Mate pravdu v tom, ze konkretne Lua je moc pekna technologie - syntakticky cisty proceduralni jazyk s relativne silnymi knihovnami a velmi jednoduchym zpusobem rozsireni o vlastni nativni funkce zabalena do prekvapive maleho footprintu. Na druhou stranu nebyt schopny programovat v jine nez infixove syntaxi neni pro vyvojare (skriptujici power-user?) dobra vizitka.
-
BruXy (neregistrovaný)Kdysi davno, kdyz jsem chodil asi do 5. tridy, tak nam pani ucitelka rekla at si z domova vezmeme kalkulacku, protoze se s ni budeme neco ucit. Doma mel fotr to HPcko s postfixovou notaci, dostal jsem kratnou nalejvarnu, jak se s tim zachazi a jel jsem jako drak. Vubec jsem si tehdy neuvedomoval, ze se jedna o neco neobvykleho a zavorky mi vubec nechybely.
