Buducnost informatiky za 5-10 rokov

[Orákulum]

Jo jsem kokot a blbě jsem to překlikal a neprohlíd kua.

[Reklama]

[Mirek Prýmek]

Smrt funkcionálního programování

Rozumím tomu, co chceš říct a jaké jsou k tomu podle tebe důvody. Ale: pokud by došlo k tomu, že by se funkcionální programování stalo opravdu potřebným/chtěným/nejlepším řešením (ať už potřeba masivní paralelizace nebo cokoli jinýho), proč by nemohlo dojít k tomu, že se stávající nebo noví programátoři na FP prostě nepřeškolí. Co tomu brání? Je FP příliš intelektuálně náročné? Zas tak strašný to není, ne? Zvlášť pokud by se objevila nová generace programátorů, kteří by FP používali prakticky od začátku, takže by nemuseli projít tak bolestným mindtwistem...

[perceptron]

Některé knihovny v Javě budou zpoplatněny Oraclem, následně i open source řešení na nich stavějící budou vyžadovat koupi licence.

ktore napriklad? spoplatnia java ee?

Pokud je člověk ale nohama na zemi, tak IT za 10 let bude vypadat úplně stejně jako vypadá dnes a úplně stejně, jako před x desítkami let.

mne to pride ako pozorovanie z takej perspektivy, ze az to nie je pravda. sada dovednosti neni rovnaka: pokial teda nie ste cobolista

[Kolemjdoucí]

proč by nemohlo dojít k tomu, že se stávající nebo noví programátoři na FP prostě nepřeškolí. Co tomu brání? Je FP příliš intelektuálně náročné? Zas tak strašný to není, ne?

Programovací paradigma určují vývojáři hardware a ti z určitých důvodů zvolili paradigma imperativní a přes to nejede vlak. Všechny pokusy o změnu na úrovni politiky v software skončily neúspěchem a takhle selže i funkcionální programování. Zřejmě se ukáže, že stačí do tradičních jazyků zabudovat lambda funkce, map-reduce a podobné vylomeniny a o opravdické funkcionální programování nikdo nestojí.

[Mirek Prýmek]

Programovací paradigma určují vývojáři hardware a ti z určitých důvodů zvolili paradigma imperativní a přes to nejede vlak.

To je imho nevalidní důvod, protože dneska většina jazyků stejně běží na nějakém virtuálním stroji (třeba zásobníkovém), takže ten skutečný hw pod tím to zas tak přímo neovlivňuje.

Nebo jednodušeji: protipříklad: SQL.

Zřejmě se ukáže, že stačí do tradičních jazyků zabudovat lambda funkce, map-reduce a podobné vylomeniny a o opravdické funkcionální programování nikdo nestojí.

No já jsem psal: "pokud by došlo k tomu, že by se funkcionální programování stalo opravdu potřebným/chtěným/nejlepším řešením". Je to hypotetická otázka. (nehádám se s tebou, dost možná budeš mít pravdu, jenom odpovídáš na něco jiného, než jsem se ptal)

[Reklama]

[Kolemjdoucí]

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í :-)
SELECT možná, uživatelské SQL funkce a procedury jsou imperativní.

Hádat se také nebudu, to je lepší vyrazit na pivo ;-)

[Orákulum]

Myslím že přinejmenším u velkých podnikových systémů se funkcionální programování hned tak neuchytí, samozřejmě že u hardwaru to asi bude jinak, třeba nějaká ta grafika a nebo výpočty tak tam to má šanci. IT se už dost fragmentovalo a bude se fragmentovat ještě více, takže to lze vidět různě.

Podívejme se na to ale třeba z hlediska pracovních pozic, třeba velká budoucnost se věští počítačovému vidění, ale zkuste si najít nabídku práce přes nějaký portál kde toto chtějí. V porovnání s běžnými pozicemi různých kodérů PHP/Java/.NET je jich málo, dokonce i databázových specialistů na MSSQL/Oracle je daleko více.

Je dost možné, že nové technologie které přijdou a které v konečném důsledku ovlivní celý svět nebude obecně příliš mnoho lidí používat. Někdo třeba udělá novou službu která se rozšíří stejně jako Facebook nebo Twitter a použije k tomu funkcionální programování nebo já nevím třeba nějakou vymakanou umělou inteligenci, ale naprostá většina programátorů zůstanou patlalové, minimálně to tak zůstane dokud se všude bude vyučovat jako první jazy Java nebo třeba C#.

Vůbec třeba do dnes nebyl vyřešen konflikt mezi objektovým a relačním modelem, ne na všechno se hodí objekty. A tak vznikají srandy jako Linq nebo alespoň lokální kopie dat v SQLite, případně jiné zhůvěřilosti. Je asi pravda, že funkcionální programování řeší mnohé problémy OOP, prostě zmizí, nevzniká takový boiler plate tak jako ve staticky typovaných objektově orientovaných jazycích.

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

[Pavel Tišnovský]

Smrt funkcionálního programování

Rozumím tomu, co chceš říct a jaké jsou k tomu podle tebe důvody. Ale: pokud by došlo k tomu, že by se funkcionální programování stalo opravdu potřebným/chtěným/nejlepším řešením (ať už potřeba masivní paralelizace nebo cokoli jinýho), proč by nemohlo dojít k tomu, že se stávající nebo noví programátoři na FP prostě nepřeškolí. Co tomu brání? Je FP příliš intelektuálně náročné? Zas tak strašný to není, ne? Zvlášť pokud by se objevila nová generace programátorů, kteří by FP používali prakticky od začátku, takže by nemuseli projít tak bolestným mindtwistem...

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 (a při pohledu na zatím všechna ORM to je spíš naopak, když už dneska mám rýpavou náladu :-)

[Pavel Tišnovský]

Vůbec třeba do dnes nebyl vyřešen konflikt mezi objektovým a relačním modelem, ne na všechno se hodí objekty.

No právě. Já teď i několikrát za den pendluji mezi Clojure a Javou, takže vidím, jak zcela odlišný přístup k řešení volím v jednotlivých jazycích, resp. v různých paradigmatech. V Javě je to klasika - funkcionalita schovaná do tříd (metod), hierarchie, použití základních datových struktur většinou taky "schované". V Clojure (a jiných FP to velmi pravděpodobně bude podobné) je ḱód tvořen základními funkcemi a jejich kompozicemi operujícími nad základními datovými strukturami - v podstatě si skoro pořád vystačím s vektorem a mapou :-) semtam nějaká ta množina. Navíc to má blíž k relačnímu modelu, když už je ho tedy zapotřebí použít při komunikaci s SQL DB.

[Orákulum]

Jedním z možných přístupů pro ty co nechtějí moc přemýšlet je nepoužívat objektovost k reprezentaci problémové domény, ale pouze jako nástroj pro sdílení společných částí kódu. Například když budu mít "skripty" na přidání položky objednávky a třeba smazání zákazníka, tak oba dědí ze společné třídy která obsahuje společný kód jako třeba vytvoření konekšny, transakci, odchytání chyb a podobně a ve které se volají abstraktní metody které se definují až v potomku a teprve tam se třeba píše SQL nebo něco volá, tak vůbec k tomu konfliktu nedojde. Pokud to navíc není dělané statickými metodami ale jako objekt tak vlastně každá instance je funkční objekt který se vytvoří, nahází se do něj v konstruktoru parametry, pak se zavolá a nakonec se vybere výsledek a objekt zahodí, takže de facto funguje funkcionálně.

Modelovat doménu se někdy vyplatí, někdy nevyplatí. Takový přístup zase může vést k jiné srandě, a sice že se camraj objekty které mají jenom membery a nemají skoro žádnou funkcionalitu, leda tak třeba inicializaci ale žádnou logiku, takže fungují jak struktury. Čím blbější je programátor, tím lepší je vyhýbat se OOP pokud to jen jde, a OOP použít jen pro podporu procedurálního programování. Třeba v C++ nadefinovat pěkné pomocné třídy s přetíženými operátory (třeba matice, různé tabulky atp.), ale samotnou logiku řešit procedurálně. Hodně kódu lze ušetřit už tím, že pro filtraci tabulky se použije jeden řádek namísto procházení na místě ručně. Taky v C# a Javě jdou samozřejmě použít generics/templaty, hlavně ať to ale nesouvisí s doménou. Linq je celkem luxus vynález, ale ani u něj není jistá jeho budoucnost...

[Mirek Prýmek]

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/UQkQB7DMqQ4

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

[Mirek Prýmek]

P.S. když říkám OOP, tak tím myslím "to, co se obvykle OOP nazývá". Jinak totiž Erlang je de facto jeden z nejčistějších skutečně OOP jazyků, jaký existuje

[meh]

Je dost možné, že nové technologie které přijdou a které v konečném důsledku ovlivní celý svět nebude obecně příliš mnoho lidí používat.

samozrejme. staci se kouknout do serialu prichod hackeru kolik lidi skakalo kolem eniacu.

[Kolemjdoucí]

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.

Reálně přináší přehlednější kód pro některé druhy úloh. Budoucnost ukáže zda je ten to přínos dostatečný nebo nedostatečný pro větší rozšíření.

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

Masivní paralelizaci brání užívání konceptu globálních a statických proměnných. OOP s tím nesouvisí. Jakmile v projektu zlikvidujete globální/statické proměnné, masivní paralelizaci nestojí nic v cestě a to s i bez OOP.

[Mirek Prýmek]

Masivní paralelizaci brání užívání konceptu globálních a statických proměnných. OOP s tím nesouvisí. Jakmile v projektu zlikvidujete globální/statické proměnné, masivní paralelizaci nestojí nic v cestě a to s i bez OOP.

Nejen. Ještě důležitější je imutabilita. Jestliže v OOP někam předám odkaz na objekt, tak už si nikdy nemůžu být jistý, že si ho neuložil a nehrábne do něj ve chvíli, kdy se mi to nebude hodit. Můžu samozřejmě projít kód a podívat se, jestli si odkaz ukládá, ale znamená to zanořit se do stromu volání tak hluboko, jak hluboko se odkaz předává. A výsledek tohodle zkoumání bude platit jenom do první úpravy kódu. U FP tohle neexistuje.

Další věc je, že u FP můžu předávat libovolnou část stavu. Např. (tohle je jenom ilustrace, nechytejte mě za slovo prosím) mám stav o deseti položkých, jedna z nich je pole. Když chci ke všem položkám v poli přičíst jedničku, udělám to v FP mapem a jsem si stoprocentně jistej, že je to paralelizovatelné. V OOP budu nejspíš provádět nějakou operaci nad celým objektem, takže to paralelizovatelné (automaticky) není. Jasně, i v OOP to můžu udělat stylem getPole, map, setPole, ale bude to porušení zásad OOP a tímpádem to většina lidí tak neudělá a ten, kdo to udělá, bude čelit výhradám kolegů, že neumí OOP. Nebo to celé obalím metodou zvysOJednickuPole, ale tím se pořád dostanu do stejného problému, jenom na jiné úrovni - v tu chvíli bude objekt blokován na jiné operace. To opět v FP není, protože když dělám nějakou operaci na jedné části stavu, můžu s klidem paralelně dělat jinou na jiné části. Zase: jde to udělat i v OOP, ale nevede to k pěknému kódu. Rozdíl je prostě v to, že v FP vždycky jasně vím, jaká operace se dělá s jakou částí dat, v OOP to musím složitě zjišťovat, zamykat, odemykat, prostě napsat nějaký explicitní boilerplate. Čím víc ho je, tím víc je kód nečitelný.