Názory k článku Joy: radost z programování
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)> Při použití postfixové notace však nejsou závorky ve výrazech nikdy zapotřebí,
Neni pravda. Jeste je treba mit jednu podminku, aby postfixovy (ci prefixovy, to je uplne jedno) zapis nepotreboval zavorky - vsechny operatory musi mit fixni aritu. Napr. Scheme tohle nema (funkce s promennou aritou jsou tam velmi caste) a tedy obsahuje spoustu zavorek. -
Jan H. (neregistrovaný)Postfix notation mi pripada mene vhodna k pouziti, nez mi pripada suffix a to predevsim protoze specificky v tomto konkretnim pripade by se zrejme potencionalne mohlo jednat o to, ze se ale opravdu nejaky ten libovolny znak pridava na uplny a definitivni konec vyrazu, cimz by melo byt zcela jasne Vam a take samozrejme zcela zrejme kazdemu jinemu, ze RPN a dokonce ani postfix notation proste neni vhodnejsi nez suffix.
-
Rejpal (neregistrovaný)
To "n" si tam v jednu fázi vývoje "bežné češtiny" někdo domyslel. V řečtině a latině existují tzv. substantiva třetí deklinace. U těch se kmen leckdy netriviálně liší od prvního pádu jednotného čísla, třeba legio je legie, ale kmen je legion- (třeba "dvě legie" je duae legiones). Nebo voják, miles, má kmen milit-, vojáci jsou milites. Tohle zachovávají i slova přejatá z těchto jazyků, proto máme: Atlantis x bez Alantidy, Mars x bez Marta (týká se spíš boha než planety, cf. anglické "hung" a "hanged", kde druhé s prakticky výhradně týká způsobu popravy, nebo "shone" a "shined", všechny tyto tvary vznikly samozřejmě jazykovým vývojem), Cicero x bez Cicerona, a podobně.
Nicméně slovo "potenciál" pochází z latinského potentia. To je deklinace první, a ani v latině se žádné dodatečné n v souvislosti s tímhle slovem neobjevuje. Stejným metrem bychom mohli mít diferencionální rovnice. Já však ve škole počítal zásadně rovnice diferenciální, diferencionální nikdy. :-) Bohužel tento patvar jakýmsi způsobem pronikl do Pravidel jako povolený. Zde asi nezbývá než apelovat na dobrý vkus všech píšících, tedy pokud ho mají. Přinejmenším vzdělanějším lidem pak totiž tyhle tvary "nesecvakávají", protože si z latiny nic podobného nepamatují. Tito lidé si pak pomyslí o autorovi textu svoje.
-
anonymníClovece vy jste jako encyklopedie, co takto:
Thanks for a clarification, I dunno Latin nor Greek, but I do know "potential" is also the English word (probably took from Latin as you wrote), but as you can see "probably" is widely used, while pontentially isn't. Well, it's interesting. I think everyone should use a one particular unified language. Unfortunatelly, the problem is there isn't such a language although it's serriously needed and should be already developed, by the way are you a linguist? Please tell me how many languages you know about. -
Rejpal (neregistrovaný)Encyklopedie? Mně to spíš přijde jako středoškolské znalosti. :-) A opravdu, o většině z těch věcí jsme na střední škole mluvili. :-) Tomu citátu tak úplně nerozumím. "Potentially" není zas tak neobvyklé, vybavuje se mi třeba kolokace "potentially hazardous". "Probably" určitě nebude synonymum.
-
Jan H. (neregistrovaný)Veci se vsak maji jinak, nez by se mohlo z Vaseho posledniho komentare zdat a totiz realita je nasledujici - suffix obcas muze byt oznacovan chybne s pomoci laikem vydedukovaneho nazvu postfix, nicmene je nutno si uvedomit, ze ve skutecnosti po odborne strance ten jediny korektne uzivani postfix je onen slavny MTA oblibeny a uzivany ve velkem zejmena v tech malych, strednich, stredne rozsahlych a dokonce i v rozsahlejsich firemnich subjektech, coz tedy vlastne muze znamenat v tomto pripade, pokud tomu dobre rozumite jen pouze to jedno jedine, a to - suffix je spravny termin, zatimco postfix neni, coz samozrejme doklada casto uzivany termin suffix v hypertextovem linku pod timto odstavcem, cili pokud drive slovo suffix v technickem materialu zamerenem na programovani popisujicim operatory nebylo, nyni tam (k vasemu prekpaveni) je, kde se tam vzalo? Kdy se tam vzalo? To uz si budete muset umet zjistit sam.
http://209.85.135.104/search?q=cache:kQr9Z4aIhi8J:www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf+operators+suffix&hl=en&ct=clnk&cd=1 -
Michal Vyskocil (neregistrovaný)Proboha přestaňte tu manipulovat s termíny, kterým nerozumíte. To, že umíte najít google článek, kde jsou slova `operator' a `suffix' pohromadě, ještě neznamená, že je k tématu. Ten článek jenom popisuje rozšíření C++ při definic vlastních literálů, s čímž souvisí změny v deklaraci přetěžovaných operátorů, ale nikde tam neoznačují RPN (postfix) notaci jako suffix.
Doporučuji spíše tent link
http://en.wikipedia.org/wiki/Reverse_Polish_notation -
Rejpal (neregistrovaný)
Zaprvé, měl byste častěji psát a cvičit stylistiku. Vaši češtinu jsem luštil několikrát déle, než jak by mi to trvalo u třebas i průměrného textu.
Zadruhé, text, který odkazujete, hovoří o suffixech v prakticky totožném smyslu, jaký se používá v lingvistice, čiže o suffixech jako neoodělitelných součástech tokenů formálního jazyka, třeba
17UL(v jazykovědě pojem "sufix" označuje součást slova, kterou obecně nelze oddělit beze změny jeho významu, stejně jako17není totéž, co17UL).Zřejmě Vás mate fakt, že se v textu hovoří i o operátorech. To je však způsobeno tím, že C++ prakticky všechny nedostatky Cčka co do platných identifikátorů řeší "přetěžováním operátorů", takže je pochopitelné, že na doplnění suffixů do tokenů jazyka vymysleli zrovna operátory (C++kaři tak říkají čemukoli, co je napadne, v Lispu by zase třeba mohla být řeč o reader makrech). V tomto případě se skutečně nejedná o postfixové operátory na syntaktické úrovni, pracující s first-class objekty jazyka (což je běžný význam toho termínu), ale pouze o pomocné funkce, které pomáhají zpracovávat lexikální tokeny.
Pojem "postfix operator" se tedy ani v textu vyskytnout nemůže, kvůli úzkému zaměření textu na lexikální analýzu. Ba co víc, pokud toto je Váš jediný příklad, jen to posiluje moje argumenty. Ani v jazyku a etymologii se člověk nevyhne potřebě kritického myšlení, bohužel. Přesto za tenhle příklad děkuji, je to další ukázka toho, že nedostatečně mocné programovací jazyky člověk nejlépe vylepší adopcí vlastností Lispu.
-
Jan H. (neregistrovaný)Ano, dobre, vzdyt vlastne ja samozrejme souhlasim s Vami v tom, ze ono by tedy nemuselo byt zase az tak naprosto trivialni, co se te vydane psychicke namahy tyce, ze ano, precist si nektery, a zejmena pote jeste navic i porozumet nekteremu konkretnimu, z te jiste rady prispevku, ktere ja pisi zrovna sem na root.cz, zrovna tim jistym stylem a zrovna mne to tak nesmirne bavi - pravdepodobne to bude tim, ze jazyk se opravdu transformuje na tak bezcennou zmet znaku jako tady zcela zamerne pouzivam napriklad i ja a to priznejme si je nejvetsi nesvar hlavne jazyka ceskeho, nebo to bude tim, ze postfixova notace neni ekvivalentni termin s terminem postfix, avsak protoze mam dnes ponekud velice mnoho casu, ktery se, verte mi, timto ponekud velice zvlastnim zpusobem ponekud velice dobre kratil, za coz Vam takto nevsedne rad dekuji, dobre jsem si zde s nekolika kratkymi i dlouhymi, zajimavymi i nudnymi, ceskymi i anglickymi slovy zahral a nasledne Vasi reakci se dosti znacne (ale opravdu) zasmal, uprimne pri tom vsem doufam ze jste tento prispevek lustil jeste dele a ze odepisete neco jeste vice vtipneho - na zaver, uz bych asi jen mohl primichat nahodne vygenerovana slova - do kazde vety alespon 1, aby se to pote nejcechovanejsim cechum jeste lepe cetlo, predevsim lingvistum :-D
-
Rejpal (neregistrovaný)V poho, v porovnání s některými je to ještě docela dobré. :-)
-
anonymníhaha, trefne ! To co jsem se pokousel napodobit je spise na zpusob http://en.wikipedia.org/wiki/Newspeak , ale nektere googlem vyhledane fraze obsahujici ",proste no !" mi spise pripominaji vyjadrovaci neschopnost, nez-li overskilled speakera.
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)> je určeno přesně tím pořadím, jakým program čteme, tj. zleva doprava, neboli opačně, než je tomu u funkcionálních programovacích jazyků založených na lambda kalkulu.
Coz ale spolu nijak zvlast nesouvisi. Jazyky zalozene na lambda kalkulu by mohly byt klidne i postfixove. Koneckoncu by stacilo v implementaci parseru v nejakem interpretu Scheme lehce upravit kod nacitajici seznamy a cely jazyk by se razem zmenil na postfixovy :-). -
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.
-
tyglik (neregistrovaný)Před několika lety zmínil pan Tišnovský tento jazyk v rámci seriálu o programovacím jazyku FORTH a zásobníkových procesorech jen letmo... dneska už je další vývoj jazyka zdá se definitivně odložen... ale inspiraci z něj čerpalo (čerpá) poměrně dost jiných jazyků; kromě těch uvedených v článku třeba dialekty na http://nsl.com/
-
truhla (neregistrovaný)"Při použití postfixové notace však nejsou závorky ve výrazech nikdy zapotřebí, protože se priorita operací vyjadřuje přímo posloupností operátorů."
Už to tady výše zaznělo, tohle je pravda jen tehdy, mají-li operáty fixní aritu. Stejně by totiž šlo argumentovat i u prefixové notace, přičemž víme, že např. prefixový LISP bývá vysmíván jako "Lots of Irritating Superfluous Parentheses".
Jinak ale musím poděkovat za pěkný a teoreticky fundovaný článek. Pojmy jako lambda kalkul či vyčíslitelnost vždycky potěší. -
anonymníNa druhou stranu treba postfix zadny zavorky opravdu nepotrebuje a vyuziva je na string (), pole [] a procedury {}. LISP a podobny maji spis seznamovou notaci, takze ten seznam musi clovek samozrejme nejak uvodit a ukoncit, ale bylo by taky mozny provozovat tyhle jazyky bez zavorek, akorat by clovek na zasobnik musel hodit bud pocet operandu nebo nejakou znacku zacatku parametru pro zvolenou opraci, v PS bych si to prestavil asi jako
begin op1 op2 op3 .... FUNKCE a FUNKCE by si pak cetla ze zasobniku operandy az by narazila na "begin".
LISP by se pak dal zapisovat treba jako
FUNKCE op1 op2 op3 .... end
ale LISP ma urcite dalsi vlastnosti, kde je potraba pracovat se seznamy. -
Pavel Tisnovsky (neregistrovaný)Ja jsem taky nepsal, ze Lisp ci Scheme jsou _ciste_ funkcionalni, uz jenom z toho duvodu, ze maji prirazeni (a tim i promenne). Prave Joy koncept promennych vubec nema (stav si uchovava na zasobniku), takze je z tohoto hlediska "funkcionalnejsi" :-)
Mimochodem, me prvni programy v AutoLISPu byly ciste imperativni - same setq, cond a progn :-) Ale to uz je pekne davno. -
Quasimodo (neregistrovaný)Asi uz starnu a musi se na me hrozne polopaticky, ale z tohoto clanku jsem mel pocit, ze jsem zpatky na fuckulte a zase mi nekdo slozite vysvetluje veci ve sve podstate uplne jednoduche. Cele mi to pripda psane nejak kostrbate a necesky. Tim ani tak nemyslim uzivani cizich slov, ta vetsinou beru jako presne vyjadrovani, ale spise me zarazeji obraty typu "provede vypis". Proc ne jednoduse "vypise"? Nebo proc se namahat s necim jako "vlozeni hodnoty na aktualni vrchol zasobniku"? Takovyto clanek snad budou cist prakticky pouze programatori a tem je zbytecne rikat, ze se hodnota vklada do zasobniku na vrchol a jeste k tomu aktualni. Komentovat kam se neco do zasobniku vlozi ma smysl jen tehdy, kdyby to na vrchol nebylo.
Plus mam pocit, ze prvni priklad je nejaky divny. Jestlize je square definovano jako dup *, tak bych cekal ze [0 1 2 3] [square] map bude mit jako vysledek [0 1 4 9]. Zretelne to tedy dela neco jineho, nez ocekavam a bud ten priklad nechapu, nebo je tu nejaka chybka.
Ale uz se tesim na pokracovani. Treba se dozvim, jak se v takovemto jazyce bez promennych zvlada napriklad vypocet determinantu matice 3x3. To musi byt uplna nirvana... Sice si dokazu predstavit jak to udelat hrubym nasilim, ale z poctu nutnych zasobnikovych operaci me jima hruza. -
Pavel Tisnovsky (neregistrovaný)Diky za nazor. Prave ze jsem zjistil, ze mnoho programatoru zasobnik (nebo nedejboze strom ci dalsi obecnejsi grafove struktury) vubec nezna! Samozrejme to nejsou lidi, co vystudovali IT, ale dneska se programatorem stava vcelku kdokoli (nic proti, znam par lidi s prumyslovkou, kteri jsou na prgani fakt dobri), takze je IMHO dobre nerikat nektere veci moc vagne, ale trosku je upresnit. Ostatne i v dotazech se nekdo ptal, co je to arita - to se snad probira v teorii programovacich jazyku ne? Par lidi - alespon co jsem mel cest videt jejich zdrojaky - si napriklad v Jave vystaci pouze s polem, zadnou dalsi "kontejnerovou" datovou strukturu nepotrebuji :-)
Jinak diky za upozorneni na chybu v textu - nektere casti zdrojaku jsem kopiroval z terminalu, nektere (vcetne poznamek) dopisoval az potom. Definice square je uvedena nize, jde o dup *. -
stalker (neregistrovaný)Nedá mi to a musím s kolegou souhlasit (a to tak starý nejsem :-)).
Ten polopatický tón mi spíš připomněl střední školu, než fuckultu. A zabít několika stránkový článek vysvětlováním postfixové notace proloženým obrázky obstarožních kalkulaček ...
To s těmi poli mě docela překvapuje. Spíš bych čekal, že budou používat výhradně kontejnery, protože to je pohodlnější (minimálně se do nich dá přidávat).
Ještě technické (rejpavé) poznámky. Pro kompozici se používá symbol kolečka uprostřed řádku, ne symbol pro stupeň. Konec prvního odstavce druhé části jsem nějak nepochopil, resp. jsem nepochopil jakou to má souvislost s článkem. Vyvolal ve mně falešné naděje, že snad Joy tyto konstrukty přímo používá (pak by to byl opravdu zajímavý jazyk :-)).
Ale když už to tam je, tak by to mohlo být přesnější, protože pomocí nulové funkce atd. jsou definované částečně rekurzivní funkce a projekce není jedna funkce, ale spočetně mnoho funkcí. A pokud první věta třetího odstavce patří k témuž, tak opravdu nevím jaký je rozdíl mezi kombinace funkcí a kompozice funkcí, ale jednoho z toho by měl být operátor substituce. Naopak tam chybí naprosto zásadní operátor minimalizace.
