Proč není Scheme čistě funkcionální jazyk?

Radek Miček

Re:Scheme
« Odpověď #15 kdy: 04. 09. 2012, 21:04:11 »
Volil bych staticky typovaný jazyk, neboť dobře využitý silný typový systém může odhalit mnoho chyb ještě před spuštěním programu. Myslím, že OCaml našel docela dobrý kompromis mezi statickou bezpečností a jednoduchostí, proto bych doporučil OCaml.

Nicméně i OCaml má určitá omezení, hlavním z nich je nepodpora paralelního a distribuovaného programování. To se pak řeší buďto knihovnami - např. součástí knihovny ocamlnet je netmulticore - nebo upraveným jazykem JoCaml, který implementuje join-calculus - formalismus pro distribuované programování. Na druhou stranu Haskell je v tomto ohledu mnohem dál: Parallel and Concurrent Programming in Haskell, GPGPU programming with Accelerate.


Re:Scheme
« Odpověď #16 kdy: 04. 09. 2012, 21:11:25 »
hlavním z nich je nepodpora paralelního a distribuovaného programování.
To jsem nevěděl, díky! To je teda v dnešní době docela velká nevýhoda...

Radek Miček

Re:Scheme
« Odpověď #17 kdy: 04. 09. 2012, 21:40:01 »
Citace
To je teda v dnešní době docela velká nevýhoda...

Pro některé aplikace ano. Na druhou stranu i přesto v OCamlu vznikl projekt Plasma (distribuovaný souborový systém, map/reduce systém a databáze).

Doménou OCamlu je symbolický výpočet tj. dokazovače jako Coq, nástroje pro analýzu kódu jako Frama-C nebo pfff a kompilátory. OCaml rozhodně není jazyk pro numerické výpočty.

Logik

  • *****
  • 995
    • Zobrazit profil
    • E-mail
Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #18 kdy: 05. 09. 2012, 13:48:03 »
A co Clojure, když už tu vyjmenováváme ZOO?

ezdiy

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #19 kdy: 08. 09. 2012, 20:13:26 »
Z non-pure funkctionalnich jazyku co se masove pouzivaji je treba zminit jazyk Lua. Semanticky je 1:1 se Scheme, minus continuations, coroutina nekopiruje stav threadu (kazdy stav lze "zavolat" jen jednou).

Jedine co stacilo k uspechu je rozumna syntax (i kdyz takrka absolutni absence syntactic sugar zrovna v tomto pripade jest obeti bohum Minimalismu zbytecne velkou).

Pure haskell je z matematickeho pohledu moc fajn, ale z nejakeho duvodu pouzivaji vsichni OCaml. Procpak asi? :)


Inkvizitor

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #20 kdy: 09. 09. 2012, 07:30:57 »
Pure haskell je z matematickeho pohledu moc fajn, ale z nejakeho duvodu pouzivaji vsichni OCaml. Procpak asi? :)

Kteri vsichni?

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #21 kdy: 09. 09. 2012, 09:19:21 »
Děkuji, to je vše zajímavé. Ještě by mě zajímalo, který funkcionální jazyk byste doporučili, kromě Scheme nebo Lispu.
Haskell, Erlang, Caml (Ocaml), v každém sem si zkusil pár věcí, ale zajíma mě pohled někoho kdo je umí porovnat. Třeba i jen podle sympatií.

Ja by som ti doporucil F#. Je to take menej ukecane Ocaml, neni to ziadna hracka pre teoretikov, ale realne pouzivany jazyk, podporovany vo Visual Studiu ja v tom pisem skoro vsetko dokonca uz aj Webovky vo vlastnom frameworku.

neviem aka je situacia na trhu prace, ale niekto mi hovoril ze v F# sa teraz vo velkom kodia softy na automatizovany mass trading (akcie, komodity, forex) a ze takyto vyvojari zarabaju 300 - 700 tisic USD rocne.

KapitánRUM

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #22 kdy: 09. 09. 2012, 22:05:00 »
To F# vypadá vážně nadějně a zajímavě!
Sleduju ho už nějakou dobu (dělám v C#) a platy jsou zatraceně velký k vůli mega projektům, který se na tom začínají dělat!
Nejmenovaná CZ společnost se zahraničním vlastníkem na tom chce postavit nový finanční výpočetní systém pro půjčky a padaly tu částky jako 80 pro obyč programátora a 120 tisíc pro vedoucího, kdy se zdá, že ani vyšší cena za člověkohodinu není na překážku.
Mě se to netýká, já se programováním živit nemůžu, ale nemůžu říct, že by se mi nelíbilo přemýšlet o platu 120 tisíc měsíčně.

KapitánRUM

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #23 kdy: 09. 09. 2012, 22:08:55 »
Jo a jednalo se o náboru cca 35-ti programátorů (3 týmy - interní software na vyhodnocování rizik, portál, aplikace pro jejich dealery).
Ostatně společnost, která na poskytování "LEVNÝCH PŮJČEK" vydělává tolik, že by v zimě mohli prachama topit, se netrápí s tím, jestli náklady budou trochu vyšší nebo nižší.

ls

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #24 kdy: 10. 09. 2012, 15:35:17 »
Děkuji, ale Visual Stuio mi nic neříká, myslím že bez něj dožiju.

Radek Miček

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #25 kdy: 10. 09. 2012, 16:57:50 »
Když už jsme u těch IDE, tak pro OCaml bych doporučil TypeRex nebo OcaIDE.

lmb

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #26 kdy: 10. 09. 2012, 19:37:54 »
Z non-pure funkctionalnich jazyku co se masove pouzivaji je treba zminit jazyk Lua. Semanticky je 1:1 se Scheme, minus continuations, coroutina nekopiruje stav threadu (kazdy stav lze "zavolat" jen jednou).

Jedine co stacilo k uspechu je rozumna syntax (i kdyz takrka absolutni absence syntactic sugar zrovna v tomto pripade jest obeti bohum Minimalismu zbytecne velkou).

Pure haskell je z matematickeho pohledu moc fajn, ale z nejakeho duvodu pouzivaji vsichni OCaml. Procpak asi? :)
1) Lua není funkcionální jazyk. Přítomnost pár paradigmat z f. jazyků ho z něj nedělá. Imperativní jazyk s funkcionálními prvky. Stejně jako populárnější Python nebo Ruby.

2) OCaml používanější než Haskell ? Asi žijeme každý na jiné planetě. Zkuste najít srovnatelnou databázi knihoven a aplikací jako je Hackage pro OCaml a hlavně porovnejte jejich aktuálnost a dotaženost. Nebo programátorská fóra a počty příspěvků. Ani se nedivím, že OCaml má ještě menší popularitu. Méně elegantní a konzistentní syntaxe, kompromis v podobě ústupu od ztráty funkcionální čistoty.

jarin

Re:Scheme
« Odpověď #27 kdy: 10. 09. 2012, 21:39:21 »
Můžete mi uvést příklad nejaké funkce ve Scheme se side-effectem  co by v čistém jazyce nešlo, nešlo realizovat?
Nie je to, ze by to neslo, ale "cisty" jazyk to ma oddelene - ako napr. Haskell do monad.
Priklad takej operacie je citanie zo vstupu alebo zapis na vystup.

Pokud bych v C programoval tak, že si napíšu knihovnu funkcí, které pak v programu jen volám a předávám jim hodnoty, jde o funkcionální programování?
Funkcionalne je podla mna hlavne o tom, ze raz napisem a pouzivam stale. Okrem toho je "zvyk" vo funkcionalnych jazykoch nepouzivat napriklad cykly, aj ked cyklus ide implementovat aj vo funkcionalnom jazyku, ale su na to jednoducho lepsie nastroje.

Dovody pre mensiu bezpecnost je napriklad jednoduchsi zapis a jednoduchsie pochopenie zaciatocnikov.

Z mojho pohladu je C odlisne hlavne tym, ako v tom ludia pisu a na co je to primarne postavene. Nikto nikomu nebrani programovat v C objektovo alebo funkcionalne. Objektove programovanie by vyzadovalo vela robenia s pointermi, co sa urcite nikomu nechce, ked su jazyky, co to obstaraju "same".
Funkcionalne programovanie v C by vyzadovalo napriklad specialny typ zakladnych struktur ako su polia uz len kvoli dlzke (=nezdielatelny kod s kamosmi atd) a tiez vela predavani pointerov do funkcii. Cast by automaticky riesili templates ako v C++, cast dalsich problemov s uvolnovanim pamati by mozno riesil shared_ptr z C++, ale toto vsetko ide robit aj mechanicky. Najhorsie na tom je, ze keby to clovek robil rucne, tak by sa z toho asi zblaznil alebo by to padalo kvoli chybam, ktore vo funkcionalnych jazykoch ani nemozu nastat. V principe by to ale asi islo.

Podle mě hlavní rozdíl je spíš teoretický. Imperativní program je posloupnost příkazů, které se postupně vykonávají a čistě funkcionální program je výraz (strom), který se redukuje. Redukce probíhá od listů ke kořenu, jinak nezáleží na pořadí (můžu program vyhodnocovat zprava doleva nebo napřeskáčku). "Funkcionální program" v C, tak z prinicpu má trochu jinou sémantiku. Jinak psát "funkcionální programy" v C není problém. Mohl bys používat pouze konstantní proměnné a funkce musí být plně definované svými parametry (když je zavoláš v libovolném místě programu se stejným parametrem, tak musí vrátit stejný výsledek). Ale jak jsem psal sémantika by pořád byla trochu jiná a navíc efektivita takového programu by asi nebyla úplně ideální.

Na druhou stranu se potom ale všechny programy vykonávají na fyzických strojích, které vlastně jenom vykonávají posloupnost příkazů, takže těžko hodnotit co je pořád ještě funkcionální jazyk.

Na druhou

Radek Miček

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #28 kdy: 10. 09. 2012, 22:21:12 »
Citace
Zkuste najít srovnatelnou databázi knihoven a aplikací jako je Hackage pro OCaml a hlavně porovnejte jejich aktuálnost a dotaženost.

Co třeba The Caml Hump? Jako by na Hackage byly všechny knihovny dotažené.

Citace
Méně elegantní a konzistentní syntaxe

V čem je méně konzistentní?

Citace
kompromis v podobě ústupu od ztráty funkcionální čistoty.

Ten kompromis však obšas ušetří psaní. A i v některých knihovnách Haskellu se používá unsafePerformIO.

lmb

Re:Proč není Scheme čistě funkcionální jazyk?
« Odpověď #29 kdy: 10. 09. 2012, 23:46:48 »
Citace
Zkuste najít srovnatelnou databázi knihoven a aplikací jako je Hackage pro OCaml a hlavně porovnejte jejich aktuálnost a dotaženost.

Citace
Co třeba The Caml Hump? Jako by na Hackage byly všechny knihovny dotažené.
O dost slabší co do rozsahu a posledních dat aktualizací, ne ? Nikde jsem nepsal, že knihovny v Hackage jsou všechny dotažené, ale pořád je větší výběr a větší aktivita kolem nich.

Citace
Méně elegantní a konzistentní syntaxe

Citace
V čem je méně konzistentní?
Je toho víc, ale alespoň částečně "řešené" (rozuměj odlišné od standardu) už x-tou verzí OCaml Revised syntax a viz http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial005.html. Pro Haskell nic takového není potřeba.
Citace
kompromis v podobě ústupu od ztráty funkcionální čistoty.

Citace
Ten kompromis však obšas ušetří psaní. A i v některých knihovnách Haskellu se používá unsafePerformIO.
"Ale vy zase mlátíte černochy..." unsafePerformIO Ano, některé z knihoven tento "hack" využívají z důvodů výkonostních nebo FFI komunikace, ale jinak je to velmi okrajová záležitost ke které není důvod se v 99% případů uchýlit a spíš to vyplývá ze špatného návrhu. Kdo ji používá např. k implementaci globálního stavu nebo třeba na memoizaci, tak je to jenom z neznalosti a znásilňování jazyka zvykama z jiných prostředí.

Teď jsem četl že ani poslední verze OCamlu (resp. GC a základní knihovny) stále neumí běh na více jádrech. To je docela tristní  :-\