Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: nobody 17. 05. 2015, 13:56:08
-
Jako vyvojar v Django a Node.js jsem se dostal k vyvoji J2EE aplikaci. Po mirnem rozcarovani z portaloveho systemu Liferay me docela zaujal Spring-boot (JHipster) a Play (scala). Jakym smerem myslite ze se bude vyvoj J2EE aplikaci dale vyvijet?
Pred rokem, kdy jsem se poprve setkal s Play frameworkem jsem byl mile prekvapen, nicmene dodnes se v CR evidentne jedna o okrajovou zalezitost a lide (alespon v mem okoli) pouzivaji predevsim kombinaci SpringMVC+Wicket.
-
velke korporacie potrebuju stabilne prostredia - na vela projektoch ide bud klasicke java ee (uz to nie je j2ee; ta skratka je mimo uz asi 5 rokov) kde vladne syntax javy, ejb, kde este zije jsf pripadne jpa. zozeniete na to lopatu a ak nie tak ju rychlo vycvicite lebo do nej nalejete kurzy
detto portlety co je humusacina ale manazeri to pretlacili lebo to predtym pretlacili ini manazeri
alternativne spring lebo ten riesi ramcovo to co java ee. spring mvc je casto pouzivany lebo v nom postavite rest api pred ktore si drbnete lubovolneho javascript frontenda. (a spring boot ide hore lebo bootnete normalnu spring aplikaciu akurat rychlejsie, co sa kombinuje s buzzwordom microservicov)
wicket je zase sice learning curve jak cyp ale mate pomerne rozumne komponentove modely a ked uz mate v teame best practices a custom components tak je to lepsie nez jsf
play a spol su okrajove hlavne kvoli scale: vela manazerov ma dojem ze naprasite priamociary kod ale malokto bude maintainovat kybel znakov prepleteny s funkcionalnym programovanim a ked do toho praskneete async io tak pocet vyvojarov co to poznaju a chcu u vas robit rychlo presiahne vas budget a moznosti
inak v jave trendy asi neopustia istotu java ee, co sa bude menit bude kybel prilahylch techov: mate akku, mate nosql, mate kadejake ine messagequeue, mate integracne veci
-
play a spol su okrajove hlavne kvoli scale: vela manazerov ma dojem ze naprasite priamociary kod ale malokto bude maintainovat kybel znakov prepleteny s funkcionalnym programovanim
Výhodou Scaly je právě to, že tam lze psát mnohem srozumitelnější kód než v Javě.
-
<cite>
Výhodou Scaly je právě to, že tam lze psát mnohem srozumitelnější kód než v Javě.
</cite>
S tim naprosto souhlasim a navic je to moje hlavni motivace proc se Scalu ucit. Nicmene muj nazor asi nesdileji managori a lide z HR, kteri chteji obvykle co nejlevnejsi lopaty.
-
play a spol su okrajove hlavne kvoli scale: vela manazerov ma dojem ze naprasite priamociary kod ale malokto bude maintainovat kybel znakov prepleteny s funkcionalnym programovanim
Výhodou Scaly je právě to, že tam lze psát mnohem srozumitelnější kód než v Javě.
Než v Javě 8?
-
ja mam scalu rad a kod samozrejme ide pisat prehladne. ale oproti jave x-krat neprehladne pretoze viac moznosti = vyssia narocnost (porov. c++), vacsi learning curve, horsie tooly a u nas slaba komunita
naprd je ze scalistov je malo a ked vam z korporatneho teamu vypadne ten jeden co to pozna ovlada a vie nove veci tak mate problem. zato ako sme sa zhodli manageri radsej najmu 3och javakov nez 1 scalistu do istoty a mate zacarovany kruh
ale v scale lakaju viac tie technologie ako syntax
-
Výhodou Scaly je právě to, že tam lze psát mnohem srozumitelnější kód než v Javě.
Než v Javě 8?
Myslím si, že ano. Už takové drobnosti jako je tagování (pro libovolný typ T lze definovat podtyp tvaru T @@ NazevTagu - umožňuje například odlišit id v databázi od počtu prvků, ačkoliv je obojí celé číslo) nebo case classy mohou dost pomoci.
Pak tam je dost věcí, které pomohou, když se používají s mírou. Například implicitní parametry nebo makra.
-
Výhodou Scaly je právě to, že tam lze psát mnohem srozumitelnější kód než v Javě.
Než v Javě 8?
Myslím si, že ano. Už takové drobnosti jako je tagování (pro libovolný typ T lze definovat podtyp tvaru T @@ NazevTagu - umožňuje například odlišit id v databázi od počtu prvků, ačkoliv je obojí celé číslo) nebo case classy mohou dost pomoci.
Pak tam je dost věcí, které pomohou, když se používají s mírou. Například implicitní parametry nebo makra.
Otázka právě je, jestli to je srozumitelnější. Ty podtypy můžou pomoci, ale třeba ty implicitní parametry nebo makra jsou spíš takový posun k C++ nebo Perlu – více možností → větší složitost a větší nároky na programátora. Ve výsledku tedy menší srozumitelnost. Funkcionální a asynchronní peklo je kapitola sama pro sebe (když se to přežene, tak se to fakt číst nedá).
Pokud všechny ty možností programátoři nepoužívají intenzivně každý den, tak je jejich existence spíš na škodu – stráví víc času přemýšlením, co která konstrukce znamená, než kolik ho ušetří tím, že to jde zapsat úsporněji nebo elegantněji.
-
kybel znakov prepleteny s funkcionalnym programovanim
Asi takto na mna posobi scala. Kopec zatvoriek, bodkociarok a ja neviem coho v dlhom slizi riadkov, kde na prvy ani druhy pohlad nie je jasne, vo co go. Pozrite si napr http://www.scala-lang.org/old/node/56.html. Verim, ze je to super, ale prehladne a udrziavatelne mozno tak pre ludi co sa s tym dlhodobo zabavaju (teda nie pre niekoho, kto si precita tutorial). Sice sa scala uchytila, ale podla mna ostane okrajova zalezitost.
-
kybel znakov prepleteny s funkcionalnym programovanim
Asi takto na mna posobi scala. Kopec zatvoriek, bodkociarok a ja neviem coho v dlhom slizi riadkov, kde na prvy ani druhy pohlad nie je jasne, vo co go. Pozrite si napr http://www.scala-lang.org/old/node/56.html. Verim, ze je to super, ale prehladne a udrziavatelne mozno tak pre ludi co sa s tym dlhodobo zabavaju (teda nie pre niekoho, kto si precita tutorial). Sice sa scala uchytila, ale podla mna ostane okrajova zalezitost.
IMO ten odkazovaný příklad (interpret lambda kalkulu se sčítáním) by byl v Javě mnohem méně přehledný.
Scala obsahuje poměrně málo konceptů, tyto koncepty jsou však dostatečně silné, aby pomocí nich šlo vyjádřit mnoho programů (od toho název Scala - škálovatelný jazyk). Hezké je také to, že se Martin Odersky, autor jazyka, snaží počet konceptů dále snižovat.
Osobně jako hlavní negativa vnímám horší typovou inferenci a ústupky, aby Scala dobře fungovala s Javou (nicméně bez nich by se asi neprosadila).
Samozřejmě, souhlasím s tím, co říkají ostatní - a to, že některé vlastnosti jazyka můžete zneužít a vytvořit nečitelné programy (to však není případ odkazovaného programu, ten je snadno čitelný).
-
Co se týče toho Wicketu, tak souhlasím s tím, že má strmější učící křivku, ale to je dáno dvěma věcmi:
1) Má v sobě dost funkcionality - komponenty, modelu, JS/CSS dependencies, package, ...
2) Hlavní problém bývá v tom, uvědomit si, že to _NENÍ_ PHPko převedené do Javy a opatlané spoustou vrstev (jako JSP/JSF). Když se toho člověk zbaví a začne o tom přemýšlet spíš jako o desktopové aplikaci s vykreslováním do browseru, tak má půlku učení za sebou ;)
-
scala ma stale problem pre newbieka ze este len vznikaju best practices a ze tutorialy este stale pisu scala nadsenci ktori sa nevedia casto oprostit od toho hardcore academickeho pristupu (functional programming in scala je napriklad pozadeke vyhul) ked budu dobre best practices (ako ma python) tak moze existovat vela konceptov ale malo odporucanych sposobov ako to implementovat. a samozrejme ked uz sa utrasie binarna kompatibilita a budu normalne vykonne tooly a ide.
dalsia vec je ze ked na pochopenie prikladu potrebujete vediet oop, funkcionalko, monady, inferenciu a generika++ tak to learning curve dviha niekam mimo vesmiru beznych projektov. alebo ak sa v projekte zrazi funkcionalny a oop styl (pripadne v kazdom classe iny) a nahodia implicity je o zabavu ostarane.
Co se týče toho Wicketu, tak souhlasím s tím,
wicket mal problem s dedicnostou (vsetko su inline oddedene classy) a s modelmi kde sa newbiek mohol uvarit na performenci. potom to uz islo lahko. wicket ma fakt elegantnu filozofiu a la swing
-
tutorialy este stale pisu scala nadsenci ktori sa nevedia casto oprostit od toho hardcore academickeho pristupu (functional programming in scala je napriklad pozadeke vyhul)
Pokud přicházíte z jiného funkcionálního jazyka (např. z F#, OCamlu, Haskellu), tak většina věcí z té knihy Functional Programming in Scala vám bude pravděpodobně známa (možná vyjma poslední kapitoly, kde se buduje zjednodušená verze knihovny scalaz-stream). Proto si nemyslím, že by to bylo akademické.
ked budu dobre best practices (ako ma python) tak moze existovat vela konceptov ale malo odporucanych sposobov ako to implementovat.
Lidé kolem scalaz, scalaz-stream a knihy Functional Programming in Scala přejali mnoho best practices z Haskellu, což IMO není špatný výchozí bod.
-
Scala je fajn jazyk, ale co se týče komplexity, nezadá si s C++. Osobně mám raději Clojure, který je (z jazykového hlediska) mnohem jednodušší - byť křivka učení pro většinu lidí bude strmější - jedná se o LISPový jazyk a nejlepší vývojové prostředí je Emacs (heh, Netbeans Platform framework jsem se naučil dřív než kombo Clojure+Emacs!).
Ale do typického korporátního prostředí plného patlalů (téměř) bez základního vzdělání bych to nedával - tohle chce (minimálně "zatím") malý tým motivovaných lidí, ne prostředí, kde o nasazených technologiích rozhodují manažeři, kteří o nich nemají ani páru a používat to budou i lidé, kteří v životě nečetli ani GoF Design Patterns.
Sorry, ale z hlediska hledání zaměstnání v ČR to není nejlepší volba.
Java EE "is here to stay". Jak už zaznělo - korporátní prostředí chce stabilní vývojové prostředí a v naší firmě (za stěnou máme Javisty; já jsem .Neťák) vidím projekty v Java EE 5 (teď je nejnovější 7; Java 8 je stále jen ve verzi SE). Prostě 10 let staré aplikace musí fungovat, když odejde člověk, musí se rychle zaučit nový (nováček v produkci = s*ačka ve verzovacím systému; se s*ačkou v Javě se pracuje mnohem lépe než ve Scale nebo v Clojure - jednoduchý, "bezpečný" (minimálně přítomnost garbage collector nutná), silně staticky typovaný jazyk s dobrým vývojovým prostředím (které podporuje automatický refaktoring) je nutnost). A hlavně žádné časté změny, každá novinka zvyšuje finanční náklady (musí se zaučit stávající lidi + ti, kteří to za 10 let budou udržovat, přijdou do kontaktu s nekonzistentním kódem - někde se bude dělat "po novemu" a jinde "po staru"). Nicméně TOHLE je častá realita běžného života, ne žhavé novinky. Je to úplně jiný svět než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu. A v .Netu to není jiné, já jsem nedávno dostal na stůl úpravu ASP Classic (technologie nevyvíjená snad 15 let!) aplikačky, která stále běží v produkci. V posledních 10 letech se o to nikdo moc nestaral a vystřídala se na tom kupa programátorů, kteří tu technologii v životě neviděli (jako třeba já). Podle toho ten kód vypadá - s*anec jak cyp. Nikdo to nebude přepisovat - dokumentace neexistuje a nejsou peníze na vývoj nové. "Welcome to corporations." Volba technologie není o tom, co chcou lidi dělat a jak chctějí profesně růst, ale jak manažerům vyjdou čísla - ostatně programátoři jsou čísla v položce "náklady" a to ne zrovna malá čísla.
Spring Framework je hodně oblíbený (ale spíš na menších projektech) a byť ke svému běhu potřebuje "jen" Java SE (takže lze využít Java 8), je zaměřený na podobnou klientelu, která by jinak nejspíš sáhla k Java EE (EJB+ESF). Spring 4 rozhodně není o tunách XML kódu a přehnaných složitostech, Spring Boot dokáže dokonale "vykopnout" (funkční aplikačka během pár vteřin), dokumentace je fajn (i pro mě - člověka rozmazleného z MSDN) a hostování na serveru je záležitostí spuštění příkazu "java -jar myKillerApplication.jar". Byl jsem velmi mile překvapen. Když jsem hledal kvalitní hosting pro malou triviální aplikaci (která ale musí běžet furt, jinak přijdu o "reputaci"), zjistil jsem, že ceny cloud serverů jsou velmi podobné cenám lepšího hostingu - tak co bych se (byť i na triviální web) štval s nějakým PHP nebo platil licence za Windows, když mám tohle zadarmo. Radost pracovat. Jenomže tohle je "můj kšeft", můj server (na kterým si dělám co chci já) a náklady jdou z mojí kapsy - úplně jiný svět než korporace.
O Wicketu je též hodně slyšet. Ale je to trochu jiná liga než Spring - Spring chce být kompletní náhrada za Java EE a Spring MVC je MVC framework, Wicket je čistě webový framework s komponentovou architekturou (ne MVC). Wicket je tedy framework na "vyšší úrovni abstrakce" než Spring MVC (což podle mě není dobře, ale názory se různí - JSF je též komponentový fwk). Znáš-li Play, zkus Spring MVC přes Spring Boot. Je to asi tak nejblíž (už jsem zmínil - přes Spring Boot si můžeš vybrat, jestli výstup bude .jar s integrovaným kontejnerem nebo .war - je to otázka drobné změny v pom.xml).
-
A v .Netu to není jiné, já jsem nedávno dostal na stůl úpravu ASP Classic (technologie nevyvíjená snad 15 let!) aplikačky, která stále běží v produkci.
Zrovna .NET na zpětnou kompatibilitu příliš nehraje (a neříkám, zda to je dobře nebo špatně).
-
To sice ne, ale i tak je na tom dost dobře (žádná tragédie se nekoná) a IMHO se to zlepšuje.
-
než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu.
+1
-
Je to úplně jiný svět než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu.
Kdovi jestli tohle neni budoucnost IT. I kdyz se mi to nelibi, tak kolem sebe vidim pristup: "Kasleme na udrzovatelnost aplikace, kasleme na cistotu kodu, kasleme dokonce i na data quality. Hlavne aby to bylo co nejlevnejsi. Byznys nam na tohle stejne nikdy neda penize. Stejne to za 5-7 roku shodime ze skaly a kompletne to cely napiseme znova - a pouzijeme na to uplne jiny framework nez pouzivame ted"
-
Wicket je tedy framework na "vyšší úrovni abstrakce" než Spring MVC (což podle mě není dobře, ale názory se různí - JSF je též komponentový fwk).
No, to je v principu pravda, ale není komponenta jako komponenta ;) V JSF jde o HTML (markup) komponenty, ke kterým se dá případně přifařit nějaká ta Java. U Wicketu je naopak základem strom Java komponent, které k sobě mají "nějak" napojený markup. Přičemž platí, že třída může využívat markup svého rodiče - úžasná věc pro využívání polymorfismu.
-
wicket mal problem s dedicnostou (vsetko su inline oddedene classy)
Ugh???
a s modelmi kde sa newbiek mohol uvarit na performenci.
To ano... ale jak člověk pochopí, k čemu je LoadableDetachableModel, AbstractReadOnlyModel... ;) A teda co se týče performance, tak zrádnější je spíš nevhodné přetěžování isVisible().
-
Ugh???
ze kod wicketu je hlavne v zaciatkoch anonymna trieda v anonymnej triede co teda nie je az taky zvyk v jave :-) (tym myslim pageable views, abstractreadonlymodel a podobne). wicket mal na to samozrejme dizajmove dovody
ale jak člověk pochopí, k čemu je LoadableDetachableModel, AbstractReadOnlyModel..
jj, urcite je to lepsie ale niekedy davno bola k tomu fakt biedna dokumentacia ktora dokola vysvetlovala jednoduche veci a zlozite mlzila
-
Pokud přicházíte z jiného funkcionálního jazyka (např. z F#, OCamlu, Haskellu), tak většina věcí z té knihy Functional Programming in Scala vám bude pravděpodobně známa (možná vyjma poslední kapitoly, kde se buduje zjednodušená verze knihovny scalaz-stream). Proto si nemyslím, že by to bylo akademické.
to je samozrejme pravda
akurat ze ide f# a ocaml a nebodaj milovany haskell ako reklama na krasny ale mimopraxovy jazyk? opat je to o tom ze bud mate nadsencov ktori migruju medzi scalou a inym funkc jazykom a projektuju krasny liberalny projekt a stretavaju sa na konferenciach a potom vesmir enterprajs developerov kde lambda je ten znak z half-life
bolo by dobre keby to bolo naopak
-
Kdovi jestli tohle neni budoucnost IT. I kdyz se mi to nelibi, tak kolem sebe vidim pristup: "Kasleme na udrzovatelnost aplikace, kasleme na cistotu kodu, kasleme dokonce i na data quality. Hlavne aby to bylo co nejlevnejsi. Byznys nam na tohle stejne nikdy neda penize. Stejne to za 5-7 roku shodime ze skaly a kompletne to cely napiseme znova - a pouzijeme na to uplne jiny framework nez pouzivame ted"
Nejen budoucnost, souhlasím s Tebou že do jisté míry i současnost. Existuje mnoho aplikací, především webových UI, jejichž životnost je právě 2-5 let (a tedy max po 3 až 4 letech musíš uvažovat o přepisu). V takovém případě je na místě použít co nejnovější framework a jazyk, ve kterém se rychle píše a kde programy se dají co nejrychleji dostat na server (a třeba i upravit za běhu přímo na produkčním serveru, pokud si to situace žádá). Takový jazyk zcela jistě bude interpretovaný, dynamicky (a klidně slabě) typovaný. Třeba JavaScript pro klient i server nebo JavaScript na klientovi a server v PHP/Pythonu/Ruby. To, že není pořádná podpora IDE ani pro jazyk ani pro framework nemusí být až tak na škodu nebo že se programátoři seznamují s technologií při psaní produkčního kódu nebo že výkon interpretu jazyka je tragický oproti .Netu/Javě.
Priorita takového segmentu trhu je někde jinde a Java EE pro takový segment není zajímavá technologie.
Co se ale dá udělat, tak že se kolem stabilního systému udělají webové služby (WCF Rest, JAX-RS...) a uživatelské rozhraní se "naplácá" v něčem, co jsem popsal výše. Jedná se o "validní" a ne až tak raritní byznys model.
Věci jako PHP (a tuna frameworků), RoR, Node.js ... by tu nebyly, kdyby je nikdo nepoužíval. Ale přístup typu "napatlat to co nejrychleji a nejlevněji" nelze použít na systémy, které mají mít delší životní cyklus než právě několik málo let. Pak je z toho nepřehledný paskvil a náklady na údržbu jsou naprosto nereálné.
-
bolo by dobre keby to bolo naopak
Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?
-
Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?
Já tedy sleduji značný vzestup popularity funkcionálního programování. A je jedno, jestli jde o JavaScript, Javu, PHP nebo jiný jazyk. Na druhou stranu znám spoustu lidí, kterým FP neříká vůbec nic. Žádný závěr bych z toho ale nevyvozoval (a už vůbec ne o shnilosti FP). Každému vyhovuje něco jiného, pro různé úkoly jsou vhodná různá řešení.
-
A je jedno, jestli jde o JavaScript, Javu, PHP nebo jiný jazyk. Na druhou stranu znám spoustu lidí, kterým FP neříká vůbec nic.
Javascript, Java, PHP, C# nemají s funkcionálním programováním společného vůbec nic, jeden z mála funkcionálních je Haskell. Jak je vidět v této oblasti panuje mnoho nejasností.
-
bolo by dobre keby to bolo naopak
Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?
Z 50 rokov sa vacsinu casu riesil vykon na jednom jadre pripadne s jednoduchou paralelizaciou, kde sa praca rozhodi na N vyp. jednotiek tak, ze kazda jednotka dostane 1/N vstupov, ktore potom spracuje v serii. To sa dobre riesi imperativne a programator to ma pod kontrolou, dokaze v pripade potreby robit optimalizacie az na uroven instrukcii, comu sa tazko nieco vyrovna.
Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba. Uz to nie je o tom, ze sa spracuvaju data po castiach a kazda cast bezi v serii. Vdaka funkcionalnemu programovaniu sa da trivialne paralelizovat napriklad spracovanie jednotlivych casti pipeline bez toho, aby sme to museli riesit. Imperativne to ide tiez, ale nepise sa to tak dobre, necita sa to tak dobre a celkovo sa to nespravuje tak dobre.
Preto to tu nie je 50 rokov v takom postaveni, ze by sa to malo sancu presadit. Okrem toho ma cely svet IT zotrvacnost a ta este nejaku dobu podrzi imperativny pristup.
-
Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba.
Od r. 2005 - Pentium D a r. 2006 - Core 2 Duo je multicore všude (na serverech mnohem dříve), tedy uplynulo 10 let a stále kde nic tu nic. Zjevně absence víc procesorů nebyl ten důvod.
-
Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba.
Od r. 2005 - Pentium D a r. 2006 - Core 2 Duo je multicore všude (na serverech mnohem dříve), tedy uplynulo 10 let a stále kde nic tu nic. Zjevně absence víc procesorů nebyl ten důvod.
Omezenost prumerneho programatora a jeho "konzervatismus"? O managementu nemluve.
Navic poradny tooling vznika spis az ted.
-
Nemluve o tom, ze vyrobit ekosystem je beh na hodne dlouhou trat...
-
Tady to vypadá na další flamewar :-D .
V podstatě existují 2 přístupy k návrhu programovacích jazyků (vlastně 3, ale to v poznámce "pod čarou"). Jeden vezme asembler a přidává abstrakci, druhý vezme matematiku (třeba lambda kalkul) a ubírá na abstrakci. Jazyky jako Java, C, C++, C#, Pascal jsou příkladem prvního přístupu. Až do nedávna to v podstatě byla jediná možná volba, pokud člověk nechtěl mít Hello World, který poběží 10 minut a zabere 3x více místa v paměti, než je operační paměť počítače. Haskell je spíše druhý přístup.
Průšvih, který se před pár lety stal, tedy že se narazilo na fyzikální omezení rychlosti procesorů a tedy zvyšování výkonu je snadno možné jen přidáváním více jader/procesorů, znamená zvýšený zájem o funkcionální programování. Funkcionální prvky pronikají do "mainstreamových" jazyků již celkem dlouho - i Java nebo C++ mají v nejnovější verzi lambda výrazy (jazyky jako Python nebo C# je mají už dlouho) atd. Rozhodně to není tak, že by se funkcionální programování za 50 let neprosadilo, tak už se neprosadí. Jen k tomu nebyly podmínky, teď začínají být. Problém je již napsaná spousta aplikací a knihoven, což nelze jen tak zahodit.
----------
Třetí přístup k návrhu programovacích jazyků je vzít Perl, udělat v něm DSL a nechat to samovolně a nekontrolovaně se vyvíjet. Vznikne PHP. :P
-
hlavne teraz skaluju nielen jadra ale aj nodes co v pripade funkcka a dobreho techu znamena paralelizaciu a distribuovatelnost jednym smahom
dalsia vec je ze s threadmi sa sice programovat da uz dlho ale vo velkom je to oser; kolko ludi ovlada vobec principy thread programmingu, thread safe veci a podobne (java ee to vyriesila jednoducho: thready zhola zakazala) a thready sa nezdistribuuju.
funkcionalne konstrukty znamenaju ze o threadoch uvazovat netreba (ak teda neimplementujete akku nad jvm ;-))
a ako hovori pan nekola: niekedy treba multikombo okolnosti. lisp je tu x rokov ale kto ho bude ucit mimo volitelneho seminara a kto sa ho bude ucit ked vsetky firmy idu javu, cpp a php? (a ked este aj mit ho zrusilo z uvodneho kurzu...). na druhej strane skala aspon ukazala cestu ze existuje stabilne jvm a nad nom sa da polyglotne kodit.
alebo clojure ktore zacina byt nahypovane je asi cool nie kvoli emacsu a stallmanovej sexy brade ale kvoli kombu jvm, lighttable, boomu funkcionalka a syntaxi lispu
-
O managementu nemluve.
10 let stačilo zabedněncům na vybudování celého Facebooku i Youtube. To se mi tedy zdá jako dostatečně dlouhá doba.
Zjevně tedy ani čas není ten důvod.
-
O managementu nemluve.
10 let stačilo zabedněncům na vybudování celého Facebooku i Youtube. To se mi tedy zdá jako dostatečně dlouhá doba.
Zjevně tedy ani čas není ten důvod.
Bavime se o tvorbe platformy nebo o tvorbe produktu?
Proste pockej, az machri navykli na predchozi paradigma vymrou.
-
Proste pockej
Tedy důvody neúspěšnosti FP známy nejsou a nezbývá nám než čekat ;)
-
Proste pockej
Tedy důvody neúspěšnosti FP známy nejsou a nezbývá nám než čekat ;)
Jako bych slysel to same o strukturovanych a OOP jazycich od nejakeho kovboje na vrcholu softwareove krize ;)
-
Jako bych slysel to same
Hlasy v tvé hlavě mě tak nějak nezajímají ;) Mimochodem platforma F# existuje 10 let, Haskell dokonce 25 let, to je celá generace programátorů, tedy i nápad s vymřením starých struktur je mimo.
-
Dulezite je, kdo bude nakonec tancit na cim hrobe.
-
ono s tymi vekmi to v sw skoro nic neznamena: pozrite sa na smalltalk a kde je mu koniec
a opat ta clojure: ked pred 3 rokmi o tom nik nepocul zrazu sa dostalo do radaru aspon trochu
-
Javascript, Java, PHP, C# nemají s funkcionálním programováním společného vůbec nic, jeden z mála funkcionálních je Haskell. Jak je vidět v této oblasti panuje mnoho nejasností.
Teď zbývá tvé tvrzení něčím doložit. Jako třeba, že ty jazyky nemají higher-order funkce, bez side efektů nejde programovat, neumožňují rekurzi, monády jsou v nich zcela nemyslitelné...
Nebo jsi nám chtěl sdělit, že ty jazyky nejsou ČISTĚ funkcionální, ale umožňují kombinovat více přístupů?
-
add eMko, samovolný vývoj PHP vedl k převzetí tříd z Javy a zahrnutí funkcionálních prvků z Pythonu. Problém funkcionálního přístupu je ten, že praktické problémy vždy vedou na vymýšlení obezliček, které funkcionální přístup narušují. Viz Javascript a hrůzy typu $(function(x) {})(x), nebo XSLT, který se díky svému funkcionálnímu přístupu neprosadil.
Implementovat cykly rekurzí, jak to dělají funkcionální jazyky vede na množství chyb a horší udržovatelnost programů, lidský mozek má tuším jen 7 pracovních registrů.
je něco jiného když napíšete
class A
def a
b()
def b
x = 1
A.a()
než A(a(b(x=1)))
ve druhém případě vždy musíte v hlavě tahat kontext
Podívejte se na Clojure, která od elegantního funkcionálního lispu dospěla k neelegantním rozšířením syntaxe o procedurální prvky. Procedurální jazyk s prvky funkcionálního jazyka má smysl, ale funkcionální jazyk s prvky procedurálního jazyka je bastard, který narušuje eleganci a čistotu funkcionálního jazyka.
Praktickým ideálem je nyní Dart, který v sobě kombinuje prvky procedurální i funkcionální přirozeně a elegantně.
-
Implementovat cykly rekurzí, jak to dělají funkcionální jazyky vede na množství chyb a horší udržovatelnost programů,
naprostá pitomost
-
Implementovat cykly rekurzí, jak to dělají funkcionální jazyky vede na množství chyb a horší udržovatelnost programů,
naprostá pitomost
Proč je to pitomost? S rekurzí je u spousty jazyků problém, i když návrh algoritmu vypadá elegantně. (hledej...tail recursion, stack size limit atd.
-
Ivane, to s PHP bylo myšleno jako humor. Živelnost a nekonzistence vývoje je na něm velmi znát, což mi nejvíc vadí (+ extrémně krátká doba podpory verzí - 3 roky - když nejsou zpětně kompatibilní) ... no a pak neefektivita téměř všeho. Fakt, že přebírá věci z Javy/Pythonu, není až tak na škodu. .Net taky vykrádal Javu jak se dalo (včetně knihoven, namátkou log4net, NHibernate (v době před Linq to SQL a Entity fwk nebylo nic jiného) atp). Na durhou stranu Javová Stream Library nápadně připomíná Linq, knihovna ModelMapper je převzetí konceptu AutoMapper apod.
Co se týče cyklů a rekurze, podle mě je rekurze jednodušší a na složitější algoritmy čitelnější, ale záleží na zvyku - nejsi-li na to zvyklý, určitě můj názor sdílet nebudeš :-) . Kde rekurze ztrácí na přehlednosti je podle mě pouze jednoduché zpracování prvků kolekce, na složitější věci je IMHO paradoxně mnohem jednodušší - pokud ovšem nenapíšeš 100 a více řádkovou rekurzivní funkci.
Pokud chceš jen projít kolekci prvků a transformovat ji na jinou (běžné použití cyklů v imperativním jazyku), ve funkcionálním jazyce máš většinou funkce jako map/filter/reduce. (V PHP jsou taky - array_map, array_filter, array_reduce.) Tím odpadne většina použití cyklů. Kdyby ještě existovala funkce jako array_foreach (což AFAIK v PHP není), odpadly by téměř všechny. Jinak tohle není jen záležitost funkcionálního programování, mluví se o nich i v knížce GoF Design Patterns (viz interní iterátory).
U rekurze je nepříjemné, že pokud nemáš tzv. koncovou rekurzi (tail-call recursion) a překladač jazyka ji nedokáže optimalizovat (obě podmínky musí být splněny), pak velice rychle zapráskáš zásobník. Nevím, jak velký je u PHP, ale u 64bitových ASP.Net aplikací je 512KB. Dost málo. Proto se většinou nepoužívá jinde než ve škole pro jednoduché algoritmy, mnozí programátoři (ani vysokoškoláci) na ni nejsou zvyklí a když vidí zápis složitějšího algoritmu (kde by rekurze mohla pomoct), tak se toho zápisu spíš leknou.
Clojure, stejně jako Scala, je plná kompromisů. Clojure je poměrně čistý jazyk, ale konstrukce jako loop-recur byly nutné kvůli JVM, které právě optimalizaci koncové rekurze nepodporuje. Stejně tak je potřeba komunikovat s Java knihovnami a proto tam jsou procedurální a objektově orientované prvky. Když je to neúnosné, řeším to tak, že kolem Java knihovny udělám příjemnější rozhraní pro použití v Clojure. Leiningen podporuje kombinované projekty v Clojure/Java celkem slušně. Většinou to nezabere až tolik času - knihovnu místo z Clojure zavolám z Java kódu a rozhraní své funkce si udělám tak, aby bylo snadno zavolatelné z Clojure.
-
Implementovat cykly rekurzí, jak to dělají funkcionální jazyky vede na množství chyb a horší udržovatelnost programů,
naprostá pitomost
Proč je to pitomost? S rekurzí je u spousty jazyků problém, i když návrh algoritmu vypadá elegantně. (hledej...tail recursion, stack size limit atd.
už se mi přihodilo, že jsem musel kvůli omezení hloubky zásobníku implementovat procházení grafu bez použití rekurze, ale řešení s rekurzí bylo kratší, přehlednější, srozumitelnější a tím i udržovatelnější