Názory k článku Haskell a funkcionální programování (1)

je to reakce na predmet i015 na fi? no nebylo by to poprve, co se na tomhle serveru zacal serial na "podporu v uceni", jen tak dal!

ps:
i015 = uvod do funkcionalniho programovani
fi = mu brno, fakulta informatity, www.fi.muni.cz

--chita

Jelikoz autora znam ze skoly, tak to rozhodne nema nic spolecneho s FI MUNI, ale s kat. 456 na FEI VSB-TU v Ostrave. Konkretne to je predmet 456-026 Uvod do programovacich jazyku :)
viz. http://www.cs.vsb.cz/benes/vyuka/udpj/

No, kdyz mi po zkousce prisel e-mail, ze "Musel jsem snizit hranici bodoveho hodnoceni na 1/3 aby mohla 1/3 projit." me srdce zaplesalo, neb mich 12 ze 30 stacilo :-). Bez ohledu na to, vsak musim rici, ze funkcionalni programovani ma neco do sebe. Mnoho lidi vsak rezignuje hned na prvni prednasce, protoze prednasejici nebyl schopen zodpovedet uspokojive otazku: "K cemu je to dobre?". Tim apeluji na autora clanku, aby se mi pokusil na tuto otazku odpovedet a nejlepe podat i konkretni priklad. Treba, co presne se to v tom haskelu u toho Ericksonu dela? btw. clanek se libyl, tak platim ;-)

Ja to tusil, ze to bude mit neco spolecneho s navrhem IO - a taky ze jo, LavaHDL, Truth... Doufam, ze si nekdo vzpomene tohle vyuzit v realne praxi a muzu se ucit dalsi jazyk... Jinak si autore dohodte do seznamu jazyku i Esterel - www.esterel.org.

Egh, mel jsem za to, ze autor je pan Benes, jak nekdo uvedl odkaz na jeho stranky...Takze priste se nebudu unahlovat a budu cist clanky az do konce vcetne autora. Slibuji...

LavaHDL: hlavně že používají překladač z programu Microsoft Research :-) (viz http://www.xilinx.com/labs/lava/)

No mne 11 bodov stacilo len na kolvac, s cim absolutne nie som spokojny ... haskell ma daco do seba, pokial by to malo dajake rozumne prakticke vyuzitie, urcite by som sa do toho "ponoril viac", nie ako doteraz, ze som navstivil zopar prednasok I015 na FI MUNI ...

Poprve co ja vzpominam to byly Regularni vyrazy. :-)
Jinac Haskell je super...
Asi si zapisu i I014 - Funkcionalni programovani.
Clanek OK, jen tak dale..
--Kg

Hezky:)!! Jen tak dal, budu cist:)

Clanek se mi taky velice libi, az na obcasne nucene pouziti AutoLISPu jsem s funkcionalnim programovanim moc nekamaradil. Na pythonovske konferenci sem tam nekdo o Haskellu basni, tak snad konecne poznam, proc se jim tak libi. :-)

čau, taky se chci blejsknout :)), že už mám 2 roky za sebou přednášku "Programování II" na MFF UK a pár drobností jsem již v Prologu a Haskellu napsal :) Líbí se mi hlavně Prolog...

V tom ukázkovém qsortu je drobná chyba, dávám vám to za domácí úkol ;-)

Neni mi zcela jasne, jakou maji funkcionalni jazyky vyhodu oproti jazyce Python. Vsechny vyhody, ktere jsou v clanku popsany, podle me plati i pro nej (snad krome toho lineho vyhodnocovani, ktere by se muselo udelat pres eval a take mozna zdrojak vyjde trosku delsi), a navic ma jednu - je take imperativni.

Python je shit. Kdyz jsem si o nem zacal cist, zdal se mi kozi, ale pak ty jeho spraseny "objekty" a dalsi praseciny. Fuj. Jasne ze i v hroznysovi se da neco udelat (v bezny praxi beznych lidi asi vic nez ve funkcionalnich jazycich), ale je to pomalu takovy patlani jako v perlu.

Hlavne nema clovek tak zajimavej pocit, jako kdyz si neco pise LISPu nebo necem podobnym (na Haskel se teprve vrhnu).

Co jsou spraseny objekty? ;-)

Abych se priznal, v LISPu jsem psal jen jednou a rychle jsem toho zas nechal. Ze bych mel zajimavej pocit, to snad ani ne, spis jsem se porad nemohl dopocitat zavorek a v praxi si tak ozkousel, ze LISP skutecne znamena "Lost In Stupid Parenthesis" :-)

Lost ... jsem napsal jako komentar k clanku na Rootu "Gimp - Script-fu (skriptování nebo bojové umění?)" a malem jsem byl sezran. Ale chce to jen editor, co ty zavorky umi zvyraznovat a vejde se mu hodne radku na stranku.

Nam zas rekli, ze vzhledem k tomu, ze se nadbytecny zavorky na konci programu ignorujou, je dobry kazdej zdrojak ukoncovat nejak takto:

))))))))))))))))))))))))))))))))))))))))))

:-D

Anebo take "Lots of Irritating Superfluous Parentheses" :-) (viz hacker jargon file).

Gratuluji, prave se vam podarilo nepochopit, o cem vlastne funkcionalni jazyky jsou a jak se lisi od proceduralnich.

Fakt pekne, fakt. Tesim se na pokracovani. O Haskellu nam povidali ve skole, v praxi jsme ale pouzivali hlavne Gofer, pokud si vzpominam, a pak jeste CAML???

Ta chyba v prikladu je schvalne, abyste si overil, ze davame pozor? :-D

Co som sa z LISPu naucil.




1) Nauci vas to strukturovat program. Ked nemate cykly,



iba rekurziu, musite si kazdy cyklus nazvat.




2) Nauci vas to ocenit a pouzivat taku klasiku, ako su zoznamy. Velakrat je lepsie pouzit zoznam na mieste,



kde sa spravidla pouziva pole.




3) Spravidla ma funkcionalny jazyk mensie naroky na



interpretaciu nez proceduralny => idealne pre makra etc.



Tie makra nemusia byt primarne urcene pre uzivatelov,



staci, ked to umozni vam ako autorovi menit funkcnost programu bez nutnosti rekompilovat.

Teda nikdy jsem nic takovyho nevidel, takze mozna placam, ale rekl bych, ze tam je porad chyba (2) :-) Jestli ne, tak sorry...

qsort [] = []
qsort (x:xs) = qsort mensi ++ [x] ++ vesti_rovno
^-tady v tom radku je preklep

where
mensi = [ y...
vetsi = [ y...
^- a v tomhle radku by melo bejt vetsi_rovno = [... ne?

Existuje funkcionalni jazyk ML http://www.dina.kvl.dk/~sestoft/mosml.html
Ktery ma mimo jine binding na OpenGL a Gtk+ a melo by byt mozne zkompilovat ho mimo jine na Javovsky bytecode a tedy pouzit z Javy.

Jinak kdyz clovek jen trochu pochopi system funkcionalnich programovacich jazyku, tak je pak dost jednoduchy resit dost slozite problemy - treba zjednodusovani boolenovskych vyrazu na 160 radek vcetne komentaru.

Funkcionalni programovani asi moc nikoho zivit nebude, ale kdyz nekoho bavi premyslet...tak to je zabava.

Tak shrnu chyby v prokladu qsortu:
qsort [] = []
qsort (x:xs) = qsort mensi ++ [x] ++ qsort vetsi
> na druhou cast seznamu musime rekurzivne zavolat znova qsort a ten seznam se musi i spravne jmenovat - druha cast je v promenne vetsi!
__where
____mensi = [ y | y <- xs, y < x]
____vetsi = [ y | y odszeni je dulezite!

btw: na MFF UK taky zacina prednet "programovani II", ale zacina se prologem, nasleduje lisp a az na konci je haskell a ukaze se tento NADHERNY zapis qsortu.

Jestli si vzpominate na strilecku Abuse, tak ta mela pod DOSem (nevim jak jeji linuxova verze) adresare plny lispovskejch programku, kde se volala grafika a hudba. Jestli to v tom bylo napsany cely nevim, mozna jo, ale tehdy, kdyz jsem se LISP ucil na zkousku tak mi to docela zvedlo naladu. Tak to jen na okraj k "k cemu to je".

a) k cemu to je: vzhledem k tomu, ze kazdy program v ciste funcionalnim jazyce (pozn.: LISP neni ciste funckcionalni ale
kombinace imperativniho a funkcionalniho) je vyraz, MUZEME PROGRAM
SNADNO VERIFIKOVAT, tedy dokazat jeho spravnost

b)Gofer: mam za to, ze jde o interpret jiste formy Haskellu

c)pouziti: ano, pouziva se na makra, nemusi mit nizsi naroky za behu, ovsem interpret funckionalniho jazyka byva pomerne maly,
tedy je snadne ho nekam zabudovat

ja sa tu nejdem hadam k comu to je, svoj zmysel to ma a LISP a jeho dialekty (scheme a podobne) su silne vyuzivane aj v komercnej sfere, ale samozrejeme hlavne na akademickej pode a myslim, ze nikomu nazaskodi nejaky ten funkcionalny jazyk ovladat a vediet o com to je. V kazdom pripade musim povedat, ze velmi rad programujem v takychto jazykoch je to celkom zabavne ak vas uz cecko a podobne omrzelo. Osobne odporucam Scheme ;-).

Bylo by prosím možno upřesnit výrok:

>U aplikací, kde hraje rychlost provádění výsledného
>kódu hlavní roli, bude asi vždy lepší použít jazyk jako
>C.

Logicky vzato, při vyšší míře abstrakce a deklarativním přístupu by překladač měl mít více informací o záměru autora, což by mu mělo umožnit generovat efektivnější kód. Naopak v C je obecně dost těžké (někdy i pro kolegu vývojáře;-) zjistit, co přesně měl autor kódu na mysli a je tedy nutné s kódem zacházet mnohem opatrněji.

Proč tedy tvrdíte, že je tomu naopak? Nemáte spíše na mysli kvalitu běžně dostupných překladačů, které jsou v případě C velmi propracované?

Pane kolego, platí takový velmi neexaktní ale velmi fungující "zákon": Čím vyšší míra abstrakce, tím snadnější programování a méně efektivní kód.

Nejefektivnější kód napíšete v assembleru, v C je to horší, ale pořád slušné při rozumné míře abstrakce (možná vám to nepřipadne, ale když já byl odchován FORTRANem), ještě horší v Pascalu, mnohem horší v OOP, atd.

A ještě něco - překladači je čerta starého po tom, "co přesně měl autor kódu na mysli", ten převede přesně to, co autor napsal. A pokud ne, pryč s ním!

Ale asm si musí optimalizovat programátor. V C optimalizuje překladač. A kdo je v tom asi lepší :-)???

Ciste funkcionalni jakzyky jako je Haskell maji problem s tim jak vyjadrit stav neceho, prave protoze v nich nejsou promnenne. A svet kolem nas ma mnoho stavu, proto nejsou na vsechno vhodne. Stav lze reprezentovat pomoci predavani hodnoty mezi funkcema ktere ho mohou zmenit nebo pomoci 'continuacion' nebo 'monad', takove programy nejsou trivialni viz:
http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html#marktoberdorf
Jinak soucasna implementace Haskellu tez neni zrovna moc vykonna:
http://www.bagley.org/~doug/shootout/craps.pl(na rozdil od jinych funkcionalnich jazyku viz. ocaml)

V listingu quick sortu ma asi byt
qsort (x:xs) = qsort mensi ++ [x] ++ vesti_rovno
qsort (x:xs) = qsort mensi ++ [x] ++ qsort vesti_rovno
nezbehne to napr. na takomto vstupe:
qsort [9,4,5,3,4,7,3,4]

Sice 3 roky po, ale predsa ;)