Omezená dědičnost (je něco lepšího než OOP?)

[Mirek Prýmek]

vybrat jeden konkrétní algoritmus původně použitý v Javě a pak chtít po implementátorech ve všech možných i nemožných jazycích ten algoritmus používat mi přijde zrovna třeba pro funkcionální jazyky jako dost velký podraz.

v CLBG* to není algoritmus, spíš problém, ne? Algoritmy jsou afaik různé. Když už v tom hledat nějaký podraz, tak že jsou to víceméně výpočetní problémy - třeba takový Erlang v nich vyloženě nemá šanci, takže dopadá špatně i když je to jinak skvělý jazyk.

* to je skoro jak LGBT

[Reklama]

[Inkvizitor]

v CLBG* to není algoritmus, spíš problém, ne? Algoritmy jsou afaik různé.

Pokud to dobře chápu, tak nikoliv - cituju ze stránky problému n-body:

We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

Each program should model the orbits of Jovian planets, using the same simple symplectic-integrator - see the Java program.

Když už v tom hledat nějaký podraz, tak že jsou to víceméně výpočetní problémy - třeba takový Erlang v nich vyloženě nemá šanci, takže dopadá špatně i když je to jinak skvělý jazyk.

No já jsem ani tak neměl na mysli nějaký vědomý podraz nebo konkrétně Haskell (byť poznámka Radka Mička byla validní a Haskellu se důvodně týkala). Jde spíš o to, že pokud se mají vysokoúrovňové jazyky a zvláště FP posunout dál, budou asi muset hledat jiné cesty než kopírovat C či Javu.

[noef]

... Jde spíš o to, že pokud se mají vysokoúrovňové jazyky a zvláště FP posunout dál, budou asi muset hledat jiné cesty než kopírovat C či Javu.

Pusobi to na me tak, ze zrovna na hry by se FP poustet nemelo. Resp. ne do te doby, nez budou optimalizace na urovni stavajicich prekladacu/virtualnich stroju (tzn. ze prekladac bude opravdu spolehlive transformovat funkcionalni veci na imperativni). IMO zacit by se melo tam, kde trochu horsi vykon je vyvazen rychlejsim vyvojem. Velmi podobna pozice jakou mela Java - ma (melo) to maly vykon, ale vyvoj je velmi svizny, takze to vyvazi ty nevyhody: $ za vyvoj >> $ za hw => radeji koupime lepsi/vic hw.

[JSH]

Pusobi to na me tak, ze zrovna na hry by se FP poustet nemelo. Resp. ne do te doby, nez budou optimalizace na urovni stavajicich prekladacu/virtualnich stroju (tzn. ze prekladac bude opravdu spolehlive transformovat funkcionalni veci na imperativni). IMO zacit by se melo tam, kde trochu horsi vykon je vyvazen rychlejsim vyvojem. Velmi podobna pozice jakou mela Java - ma (melo) to maly vykon, ale vyvoj je velmi svizny, takze to vyvazi ty nevyhody: $ za vyvoj >> $ za hw => radeji koupime lepsi/vic hw.

Problém není v převodu funkcionálního na imperativní kód. To už překladače zvládají poměrně dobře. Problém je převod imperativních programátorů na funkcionální, stačí si přečíst místní diskuzi. Většina programátorů je bez měnitelného stavu totálně ztracená a z toho se odvíjí zbytek. Funkcionální řešení nevymyslí a pokud ho někdo vymyslí za ně, tak ho stejně nepoberou. Naučit se myslet jinak je nadlouho.
A pak je tady taky drobnější problém s tím, že většína existujících nástrojů staví na imperativním přístupu. Setrvačnost udělá hodně.

[v]

Pusobi to na me tak, ze zrovna na hry by se FP poustet nemelo. Resp. ne do te doby, nez budou optimalizace na urovni stavajicich prekladacu/virtualnich stroju (tzn. ze prekladac bude opravdu spolehlive transformovat funkcionalni veci na imperativni). IMO zacit by se melo tam, kde trochu horsi vykon je vyvazen rychlejsim vyvojem. Velmi podobna pozice jakou mela Java - ma (melo) to maly vykon, ale vyvoj je velmi svizny, takze to vyvazi ty nevyhody: $ za vyvoj >> $ za hw => radeji koupime lepsi/vic hw.

Problém není v převodu funkcionálního na imperativní kód. To už překladače zvládají poměrně dobře. Problém je převod imperativních programátorů na funkcionální, stačí si přečíst místní diskuzi. Většina programátorů je bez měnitelného stavu totálně ztracená a z toho se odvíjí zbytek. Funkcionální řešení nevymyslí a pokud ho někdo vymyslí za ně, tak ho stejně nepoberou. Naučit se myslet jinak je nadlouho.
A pak je tady taky drobnější problém s tím, že většína existujících nástrojů staví na imperativním přístupu. Setrvačnost udělá hodně.

proč by ale měli programovat funkcionálně? co tím získají? viz benchmark

[Reklama]

[Mirek Prýmek]

proč by ale měli programovat funkcionálně? co tím získají? viz benchmark

Ten benchmark moc nevypovídá o ničem z reálného světa. Vypovídá o tom, o čem vypovídá - takže např. pokud chceš počítat fraktály, je Haskell super! A fakt chceš počítat fraktály?

Co získají? V některých doménách, kam FP sedne jak prcka na nočník*, můžou získat hodně: přehledný, udržovatelný, čistý kód s malými nároky na hw a na množství programátorů. To není málo. Ale náklady jsou taky velké: nedostatek (-> cena) lidí, mladé nástroje, nevyzrálý ekosystém, u některých jazyků neexistující komerční podpora. Jestli u konkrétního projektu výhody převýší nebo nepřevýší náklady, to si holt už každý musí rozmyslet sám. Podle mě se FP může docela dobře hodit pro malý tým dobrých programátorů - dobře si to promyslí a rychle se dostanou k cíli, neztrácí čas balastem.

* co to všechno je, to ať si každý posoudí sám. Podle mě by do toho mohlo spadat víceméně všechno, kde jde o nějaké streamové a transakční zpracování, plus některé věci event-driven. Počet těchto domén bude imho narůstat - všechny ty internety, IoTy a tak...

[Mirek Prýmek]

Pokud to dobře chápu, tak nikoliv - cituju ze stránky problému n-body:

We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

Each program should model the orbits of Jovian planets, using the same simple symplectic-integrator - see the Java program.

Aha, díky. Tak buď žiju v omylu, nebo je tenhle jeden problém výjimka

Jde spíš o to, že pokud se mají vysokoúrovňové jazyky a zvláště FP posunout dál, budou asi muset hledat jiné cesty než kopírovat C či Javu.

Zatím to vypadá spíš tak, že mainstreamové jazyky se snaží do sebe FP nějak aspoň zčásti vcucnout. Kdyby to dopadlo tak, že by se třeba z F# stal jazyk, ve kterém by se dalo slušné psát, měl by širší základnu a slušnou podporu, takže by nikdo o Haskell, Erlang atd. zájem neměl, tak bych se třeba já ani moc nezlobil. Pořád lepší než drátem do voka dominance C++

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

[noef]

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

Nekteri rikaji, ze se Scala stane dalsi Javou (osobne tak optimisticky nejsem, myslim ze je prilis "slozita" pro bezne pohodlne Javisty). Bohuzel kvuli omezenim JVM se ten typovy system rozhodne nemuze rovnat treba Haskellu (a to s nim mam zkusenosti jen z maleho skolniho projektu).

Cim dele si ctu tuto diskuzi (nechce se mi az verit te vyspelosti prekladacu/runtimu), tim vice mam nutkani se navratit ke zkoumani Haskellu po vecerech . Nejaky tip na video kurzy/prednasky?

[v]

proč by ale měli programovat funkcionálně? co tím získají? viz benchmark

Ten benchmark moc nevypovídá o ničem z reálného světa. Vypovídá o tom, o čem vypovídá - takže např. pokud chceš počítat fraktály, je Haskell super! A fakt chceš počítat fraktály?

Co získají? V některých doménách, kam FP sedne jak prcka na nočník*, můžou získat hodně: přehledný, udržovatelný, čistý kód s malými nároky na hw a na množství programátorů. To není málo. Ale náklady jsou taky velké: nedostatek (-> cena) lidí, mladé nástroje, nevyzrálý ekosystém, u některých jazyků neexistující komerční podpora. Jestli u konkrétního projektu výhody převýší nebo nepřevýší náklady, to si holt už každý musí rozmyslet sám. Podle mě se FP může docela dobře hodit pro malý tým dobrých programátorů - dobře si to promyslí a rychle se dostanou k cíli, neztrácí čas balastem.

* co to všechno je, to ať si každý posoudí sám. Podle mě by do toho mohlo spadat víceméně všechno, kde jde o nějaké streamové a transakční zpracování, plus některé věci event-driven. Počet těchto domén bude imho narůstat - všechny ty internety, IoTy a tak...

to asi platí i o LISPu, ty jejich makra jsou prý velmi schopné, IMHO jsme v bezpečí, FP se neprosadí

[v]

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

Nekteri rikaji, ze se Scala stane dalsi Javou (osobne tak optimisticky nejsem, myslim ze je prilis "slozita" pro bezne pohodlne Javisty). Bohuzel kvuli omezenim JVM se ten typovy system rozhodne nemuze rovnat treba Haskellu (a to s nim mam zkusenosti jen z maleho skolniho projektu).

Cim dele si ctu tuto diskuzi (nechce se mi az verit te vyspelosti prekladacu/runtimu), tim vice mam nutkani se navratit ke zkoumani Haskellu po vecerech . Nejaky tip na video kurzy/prednasky?

tip na studijní materiály nemám, ale jestli se rozhodnete vyzkoušet Haskell na implementaci překladače, tak začněte knhovnou Parsec, je těžko k uvěření, že to je zadarmo
STM monáda a forkIO je taky docel super
vůbec GHC Haskell je asi nejlepší současný "programovací systém" (krom výpočetně náročných věcí, ale s GPU to prý taky nějak umí)

[Mirek Prýmek]

Nejaky tip na video kurzy/prednasky?

Nestačí learnyouahaskell.com + cvičně si něco napsat? Videa přímo o Haskellu neporadím (nedělám v něm, jenom mě tak baví se na něho občas kouknout - taky po večerech ), ale docela mě baví videa z tohodle channelu: https://www.youtube.com/channel/UC_QIfHvN9auy2CoOdSfMWDw

to asi platí i o LISPu, ty jejich makra jsou prý velmi schopné

Asi jo, ale když já ty závorky prostě nemůžu, krvácí mi z toho oči Pravděpodobně stejně silnej, nebo o něco málo slabší makrosystém má Elixir: http://elixir-lang.org/getting-started/meta/macros.html

[BoneFlute]

... mladé nástroje, nevyzrálý ekosystém, ...

https://www.haskell.org/cabal/ bylo pro mě nádherné mlsání.

[Mirek Prýmek]

(krom výpočetně náročných věcí, ale s GPU to prý taky nějak umí)

Co, GPU, ale bindingy Rka! https://plus.google.com/+JohnCook/posts/dp8sN7B4bzS

[Inkvizitor]

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

Nekteri rikaji, ze se Scala stane dalsi Javou (osobne tak optimisticky nejsem, myslim ze je prilis "slozita" pro bezne pohodlne Javisty). Bohuzel kvuli omezenim JVM se ten typovy system rozhodne nemuze rovnat treba Haskellu (a to s nim mam zkusenosti jen z maleho skolniho projektu).

Cim dele si ctu tuto diskuzi (nechce se mi az verit te vyspelosti prekladacu/runtimu), tim vice mam nutkani se navratit ke zkoumani Haskellu po vecerech . Nejaky tip na video kurzy/prednasky?

IMO docela dobrý kurs s online materiály je třeba: http://www.cis.upenn.edu/~cis194/lectures.html

A nejlepší souhrn materiálů co znám je zde: https://gist.github.com/leroux/6395804

[Radek Miček]

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

Bohuzel kvuli omezenim JVM se ten typovy system rozhodne nemuze rovnat treba Haskellu.

Nad JVM nebo CLR můžete postavit jazyky se silnějšími typovými systémy než má Haskell.

Ostatně Scala nemá ostře slabší typový systém než Haskell. Na rozdíl od Haskellu má Scala navíc podtypový polymorfismus. Důsledkem toho je slabší typová inference.