Můžete si napsat VM dle libosti, načež se zjistí že to byla opět slepá cesta a budete k tomu chtít JIT a JIT je komplikovaná forma preprocesoru pro imperativní programování :-)
...to ale nijak neodporuje FP. Když mám v Erlangu deset tisíc procesů, tak samozřejmě každej z nich funguje imperativním způsobem (a dokonce je naprogramovanej imperativním způsobem). Nevidím v tom striktní buď - anebo (narozdíl od FP vs. OOP).
Pokud by se FP mělo začít používat, tak proto, co
reálně přináší, ne pro to, aby nějaká světlá strana síly porazila temnou, aby zvítězil nějaký superčistý akademický koncept. Přínos FP je hlavně v tom, že ja jasné, jakými cestičkami plynou data, kde je jaké API, co s čím souvisí a tímpádem co může běžet paralelně na druhém konci planety. Narozdíl od OOP, které o izolaci sice hodně mluví, ale ještě nikdo ji nikdy v reálu neviděl.
Napřed musí někdo (konečně) nahlas říci, že OOP skutečně není ta legendární stříbrná kulka řešící všechny problémy IT
Tak oni to všichni FP-programátoři říkají celkem hlasitě, ale zatím jsou považovaní za nerdy mezi nerdy*. Ono se není moc čemu divit, když každá první hodina programování začíná výkladem toho, co je to objekt
Celý to je prostě jenom o tom, jestli reálná potřebnost FP někdy převáží nedostatek FP-programátorů. A to se imho rozhodne čistě mimo-IT jevy a procesy
*
https://plus.google.com/109540561880466469418/posts/UQkQB7DMqQ4Stejně si ale nedovedu představit, jak bude při funkcionálním programování prováděno pochopení systému, když člověk přijde na novou pracovní pozici a má alespoň to OOP tak si projde třídy v hierarchii a snadno najde ty kusy kódu, které mohou být znovu použity, ale pokud někde "ve vzduchu" visí nějaká funkce která něco dělá, jak se o ní člověk dozví? Tohle je problém i klasických procedurálních neobjektových jazyků. Částečně to samozřejmě řeší moduly, takže asi v F# budou věci v assembly, nevím jestli to má i namespacy, nedíval jsem se, ty by ale situaci taky zlepšily. Ale možná, že ve funcionálním paradigmatu duplikace kódu tolik nevadí, netuším, možná je spíš pozitivní - když se změní funkce na které závisí několik pomyslných stromů volání, tak se musí všechny otestovat, a když by jedna funkce ovlivňovala několik modulů rozdělených mezi jednotlivé týmy, no nevím nevím.
Např. Erlang má moduly, Elixir má navíc i namespacy. Ale v tom bych ten zásadní Rozdíl neviděl. Spíš v organizaci kódu. V FP je to taková fordovská výrobní linka - jasné vstupy a jasné výstupy každé části, jasná větvení a slučování. Oproti tomu v OOP je to často taková pavučina - kdokoli se rozmyslí, šáhne odkudkoli kamkoli. Proto se mluví o tom, že pokud se začne používat opravdová masivní paralelizace, bude FP stát za řeč.
Zobrazit příspěvky
