Funkcionální jazyky.

[Radek Miček]

Což mi přehlednější nepřijde... jiná věc je, že v haskellu na to potřebujete IO

Na to narážím - místo klasického skládání funkcí (.) budete potřebovat Kleisliho skládání (>=>), podobně ani použití eval nebude tak jednoduché, když budete chtít výsledek vytisknout.

celkově složitostí jednoho konkrétním programu přehlednost jazyka nezměříte, zvlášť když jde o tak specifickou věc jako interpret daného jazyka.

Souhlasím. Nicméně, když se podíváte na kód, který dělá vedlejší efekty (např. práce s DB, grafická uživatelská rozhraní), tak IMO situace nebude o nic lepší.

Tak nikdo vám nebrání používat Haskell jako procedurální jazyk

Otázkou je, zda to momentálně jde lépe (tj., zda existují rozšířené a podporované knihovny)?

[Reklama]

[--,_O_,--]

Otázkou je, zda to momentálně jde lépe (tj., zda existují rozšířené a podporované knihovny)?

Tak ono toho až tolik potřeba neni, funkcionální struktury pořád používat můžete a na flow control máte funkce/procedury.

[Kit]

Těch závorek není víc než v jiném jazyce. Srovnej:

Kód: [Vybrat]

funkce(par1, par2) a

Kód: [Vybrat]

(funkce par1 par2) -  závorka navíc tam není a ještě ušetříš čárku.

Taky se u jazyků jako C dlouhý jednořádkový příšery moc často nepoužívaj. U Lispu to je to problém, protože to často ani jinak nejde.

To jako vážně? Málokdo v C/C++ dodržuje maximum 80 sloupců - alespoň podle toho, jaké zrůdy občas vidím. V Lispu je dlouhý zápis příznakem, že se taková funkce či makro má rozdělit. Kromě toho není problém lámat a odsazovat řádky téměř kdekoli a jakkoli - viz zápis v prvním příspěvku.

Programy v C/C++ mají v sobě hromady balastu. Když se ty závorky přepočítají, vychází to téměř stejně jako v Lispu. Jen jsou ty závorky v Lispu víc vidět.

[atarist]

Proc by nebylo , forever je jen makro postaveny nad loop-recur, -> je taky makro (to ted z hlavy nedam, jak je interne delany).

Tomu rozumím, nechce se Vám psát boilerplate nativně v Clojure tak to zmáknete pomocí maker jinak, až se to nebezpečně blíží imperativnímu programování :-)

Ono by se nemělo jen tak říkat "ve funkcionálním programování nesmí být smyčky". To je sice pravda ve chvíli, kdy je tam nějaká řídicí proměnná (tedy mutable objekt) nebo něco podobného, ale proč ne u nekonečné smyčky, což přesně je REPL? Navíc ještě REPL není funkce, takže se těžko funkcionálně implementuje

[Franta <xkucf03/>]

je dobré připomenout, že celý LISP je možné vytvořit jen ze čtyř funkcí a tří speciálních forem, to se potom polepí dohromady makry

Je otázka, kde je ten správný poměr. Některé jazyky mají velmi mnoho jazykových konstrukcí (C++, Perl). Opačný extrém je asi ten Lisp. Taková Java je někde mezi tím resp. spíš směrem k Lispu – je to taky relativně jednoduchý jazyk s málo konstrukcemi (i když přibývají – např. lambdy v a všechno ostatní se řeší ne makry, ale knihovnami, tzn. třídami a metodami. Což třeba mně osobně dost vyhovuje (mj. online dokumentace, skvělá podpora v IDE…). Stěžovat si na ukecanost Javy podle mého není moc na místě – stačí používat vhodné knihovny/frameworky nebo si rozvrhnout vlastní kód tak, abych nemusel opakovat stejné úkoly pořád dokola. Když to programátor neudělá, tak může psát stejně otrocký kód i v C++, Perlu, Lispu… a mít program na spoustu řádků, který se špatně udržuje.

[Reklama]

[--,_O_,--]

To jako vážně? Málokdo v C/C++ dodržuje maximum 80 sloupců - alespoň podle toho, jaké zrůdy občas vidím. V Lispu je dlouhý zápis příznakem, že se taková funkce či makro má rozdělit. Kromě toho není problém lámat a odsazovat řádky téměř kdekoli a jakkoli - viz zápis v prvním příspěvku.

Programy v C/C++ mají v sobě hromady balastu. Když se ty závorky přepočítají, vychází to téměř stejně jako v Lispu. Jen jsou ty závorky v Lispu víc vidět.

...lepší výraz pro to co jsem myslel by asi byl "jednovýrazové". Přehlednost s jedním typem závorek vs 2-3 typy je diametrálně odlišná, navíc procedurální jazyky častěji dávají příkazy "pod sebe" (logicky i vizuálně), což s přehledností taky pomáhá. Lisp je možná přehlednější, než si spoustu lidí myslí, ale C-like jazyky jsou pořád přehlednější.

[Kit]

...lepší výraz pro to co jsem myslel by asi byl "jednovýrazové". Přehlednost s jedním typem závorek vs 2-3 typy je diametrálně odlišná, navíc procedurální jazyky častěji dávají příkazy "pod sebe" (logicky i vizuálně), což s přehledností taky pomáhá. Lisp je možná přehlednější, než si spoustu lidí myslí, ale C-like jazyky jsou pořád přehlednější.

V Lispu se příkazy také dávají "pod sebe". Jenže pokud jsou všechny funkce jednořádkové, odsazování ztrácí na významu.

Otázkou je, zda je přehlednější aplikace v Lispu na 5000 řádek nebo aplikace v C-like jazyku na 30000 řádek.

[Radek Miček]

Stěžovat si na ukecanost Javy podle mého není moc na místě

Myslím, že to je na místě. Jednak programy v Javě obsahují zbytečný syntaktický balast (návod na jeho odstranění - viz prezentace C# light). Dalším problémem je, že řada konceptů jde v Javě vyjádřit pouze značně složitě nebo vůbec - například asynchronní kód, modularita (kvůli tomu, že Java má pouze nominální podtypový polymorfismus) nebo binární metody (metoda má argument stejného typu jako this a platí to i v podtřídách; důsledkem je, že podtřídy nejsou nutně podtypy).

[atarist]

...lepší výraz pro to co jsem myslel by asi byl "jednovýrazové". Přehlednost s jedním typem závorek vs 2-3 typy je diametrálně odlišná, navíc procedurální jazyky častěji dávají příkazy "pod sebe" (logicky i vizuálně), což s přehledností taky pomáhá. Lisp je možná přehlednější, než si spoustu lidí myslí, ale C-like jazyky jsou pořád přehlednější.

Jenze v Clojure, o kterem je toto tema, se taky extenzivne pouzivaji tri typy zavorek (samozrejme pro jine ucely). S tou citelnosti si nejsem tak jisty, co je objektivne lepsi, zrovna C s milionem corner casu moc nevynika. To uz je lepsi porovnani napriklad s Pascalem ci Luou, kde jsou "prikazove zavorky".

Ale dulezitejsi je jina vec - hlavne uzaviraci zavorky jsou v podstate v LISPu/Clojure prakticky bezvyznamne, proto se taky davaji na stejny radek za posledni cast vyrazu, na rozdil od C/Javy, kde to lidi vetsinou mlati na nove radky (a proto maji taky vertikalni hustotu kodu dost mizernou, coz se jeste nasobi horsimi moznostmi refaktoringu). Taky jsem kdysi mel snahu psat v LISPu podobne jako v cecku (tj. neco jako navrhuje puvodni tazatel), ale je to skutecne blbost.

[Kit]

Jednak programy v Javě obsahují zbytečný syntaktický balast (návod na jeho odstranění - viz prezentace C# light)...

Zajímavá prezentace. Silně mi připomíná můj vlastní metajazyk, který jsem si napsal pro Vim a který mi napsaný text (ne nepodobný C# light) on-line překládá do konkrétního programovacího jazyka.

[Franta <xkucf03/>]

Jednak programy v Javě obsahují zbytečný syntaktický balast (návod na jeho odstranění - viz prezentace C# light)...

Zajímavá prezentace.

Tolik zbytečných slajdů (přes 70?) o zbytečnosti getterů/setterů/properties, to je opravdu výkon, čekal bych, že se tam dozvím něco zajímavějšího než mlácení slámy. Ale co taky čekat od lidí ze světa C#, že?

Silně mi připomíná můj vlastní metajazyk, který jsem si napsal pro Vim a který mi napsaný text (ne nepodobný C# light) on-line překládá do konkrétního programovacího jazyka.

Taky jsem o něčem takovém uvažoval, dokonce bych si rád napsal vlastní dokonalý jazyk, asi jako každý programátor :-) Ale zatím na to nedošlo.

Pro Javu existuje Lombok, který ti psaní getterů/setterů a spousty dalších věcí ušetří (logovače, toString, líné gettery atd.).

[podlesh]

Jednak programy v Javě obsahují zbytečný syntaktický balast (návod na jeho odstranění - viz prezentace C# light)...

Zajímavá prezentace.

Tolik zbytečných slajdů (přes 70?) o zbytečnosti getterů/setterů/properties, to je opravdu výkon, čekal bych, že se tam dozvím něco zajímavějšího než mlácení slámy. Ale co taky čekat od lidí ze světa C#, že?

Zhruba polovina těch věcí (ne-li víc) je v podstatě Groovy...

[k]

[je dobré připomenout, že celý LISP je možné vytvořit jen ze čtyř funkcí a tří speciálních forem, to se potom polepí dohromady makry ]

To je jistě zábavné a rozumím Vám, ale v praxi se tento přístup neosvědčil, nýbrž čas od času se vezme oblíbená sada takovýchto maker a přetaví se do nového jazyka.

Stěžovat si na ukecanost Javy podle mého není moc na místě

Stěžovat si na ukecanost Javy je správné neboť je to pravda a všichni to ví, jazyk Java má od samého počátku několik vážných pochybení, naštěstí ne zas tak moc.

návod na jeho odstranění - viz prezentace C# light

C# light je příznačné myšlení Hurvínků neprogramátorů co se ještě v životě nesetkali s reálným větším projektem a proto mají zdání že je toho v C# zbytečně mnoho. Připadá mi to jako když plavčík co byl nejdál v Tróji v ZOO vymýšlí plavidlo na cestu do Yokohamy.

Otázkou je, zda je přehlednější aplikace v Lispu na 5000 řádek nebo aplikace v C-like jazyku na 30000 řádek.

Je to dobrá otázka. To že nějaký jazyk spotřebuje méně řádek neznamená že bude přehlednější, není to samosebou. Namátkou Perl.

[Radek Miček]

návod na jeho odstranění - viz prezentace C# light

C# light je příznačné myšlení Hurvínků neprogramátorů co se ještě v životě nesetkali s reálným větším projektem a proto mají zdání že je toho v C# zbytečně mnoho.

C# 6 už tu cestu nastoupil a zdá se, že C# 7 v ní bude pokračovat. Například algebraické datové typy

Kód: [Vybrat]

abstract class Expr;
class X() : Expr;
class Const(double Value) : Expr;
class Add(Expr Left, Expr Right) : Expr;
class Mult(Expr Left, Expr Right) : Expr;
class Neg(Expr Value) : Expr;

nebo stručná syntax pro n-tice patří k velmi žádaným vylepšením.

Na druhé straně má C# podobné problémy s modularitou jako Java a nevypadá to, že by v blízké době zmizely (jsou dány běhovým prostředím).

[Mirek Prýmek]

C# light je příznačné myšlení Hurvínků neprogramátorů co se ještě v životě nesetkali s reálným větším projektem a proto mají zdání že je toho v C# zbytečně mnoho. Připadá mi to jako když plavčík co byl nejdál v Tróji v ZOO vymýšlí plavidlo na cestu do Yokohamy.

Sám seš Hurvínek. Podívej se na autora těch slajdů a pak třeba na autora http://fsharpforfunandprofit.com/ ty Hurvínku...