Vyvoj J2EE aplikaci

[eMko]

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. 

[Reklama]

[perceptron]

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

[m]

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.

[Ondra Satai Nekola]

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.

[m]

Proste pockej

Tedy důvody neúspěšnosti FP známy nejsou a nezbývá nám než čekat

[Reklama]

[Ondra Satai Nekola]

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

[m]

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.

[Ondra Satai Nekola]

Dulezite je, kdo bude nakonec tancit na cim hrobe.

[perceptron]

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

[tdvorak]

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ů?

[Ivan Nový]

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ě.

[v]

Implementovat cykly rekurzí, jak to dělají funkcionální jazyky vede na množství chyb a horší udržovatelnost programů,

naprostá pitomost

[ue]

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.

[eMko]

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.

[v]

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ší