Webová aplikácia v PHP

[Ivan Nový]

Hele, ty nečteš vůbec na co odpovídáš, že? FP tu je dlouho. Multiprocesorové zpracování je tu dlouho. A přesto se to do mainstreamu nijak neprosadilo (ve specializovaných use cases ano) a nic nenasvědčuje tomu, že by se to mělo změnit.

Mainstream dosud multiprocesorové zpracování v běžných mainstreamových aplikacích nepotřeboval, nyní se to pomalu mění a díky tomu se změní paradigma programování. Jinak vše už tu dávno bylo, jen hw dorůstá do možností a principů sw dávno vymyšlených.

Jinak typické multiprocesorové zpracování, které se prosadilo v mainstreamu, aniž by to běžní programátoři zaznamenali, jsou grafické karty.

[Reklama]

[Ivan Nový]

To ale není ono, čtyři až 16 procesorů manuálně řídit zvládnete, půjde ale o tisíce až desetisíce procesorů řízených jediným třeba 100 řádkovým programem v běžné aplikaci tvořené běžnými programátory.

Tak urcite, kazdej beznej blogisek nebo tuhle appku na kterou se ptal tazatal budeme resit na superpocitacich :-)

Za 5 let běžná apka bude vybavena doménovou umělou inteligencí, a na tu budete potřebovat kvůli paralelismu zpracování architekturu podobnou dnešním grafickým kartám. Bude to mainstream.
 

[gll]

Hele, ty nečteš vůbec na co odpovídáš, že? FP tu je dlouho. Multiprocesorové zpracování je tu dlouho. A přesto se to do mainstreamu nijak neprosadilo (ve specializovaných use cases ano) a nic nenasvědčuje tomu, že by se to mělo změnit.

parallelStream lze považovat za funkcionální.

v C++ třeba

http://thrust.github.io/

nejjednodušší parallelizace je použitím parallelního map nebo reduce.

[Kit]

Jinak typické multiprocesorové zpracování, které se prosadilo v mainstreamu, aniž by to běžní programátoři zaznamenali, jsou grafické karty.

A co obyčejná roura? Běžně ji používám pro zvýšení výkonu aplikace, protože umí využít více procesorových jader. Máme ji k dispozici už několik desetiletí. Jednotlivé procesy jsou funkcionálními jednotkami, které sériovým řazením vytvoří aplikaci.

[zboj]

Koukám další frikulín co naprosto nic netuší o historii a honí si nad tím, jak programuje v tom "moderním" FP a ne v "zastaralém" OOP Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?

Osobně preferuji OOP, OOP se prosadilo, aby se v C nemusely volit názvy jako tmp_xbs_stuff_create(). Do té doby to byla jen univerzitní hříčka, která vznikla stejně jako FP někdy dávno v minulosti. Ostatně všechny koncepty vznikly někdy v pozdních šedesátých letech a začátku let sedumdesátých.

FP se prosadí zase kvůli multiprocesorovému zpracování a čtení údajů (výsledků z jiných procesorů) z více zdrojů najednou v jednom proudu. Ovšem problém FP je zase pojmenování funkcí, takže to zase povede na konstrukt logická_entita.operace(parametry)

Tak ono to FP pokradmu proniká do mainstreamových (vesměs OOP) jazyků. Jistě se prosadí, ale tak nějak postupně a nenápadně...

[Reklama]

[Ivan Nový]

Koukám další frikulín co naprosto nic netuší o historii a honí si nad tím, jak programuje v tom "moderním" FP a ne v "zastaralém" OOP Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?

Osobně preferuji OOP, OOP se prosadilo, aby se v C nemusely volit názvy jako tmp_xbs_stuff_create(). Do té doby to byla jen univerzitní hříčka, která vznikla stejně jako FP někdy dávno v minulosti. Ostatně všechny koncepty vznikly někdy v pozdních šedesátých letech a začátku let sedumdesátých.

FP se prosadí zase kvůli multiprocesorovému zpracování a čtení údajů (výsledků z jiných procesorů) z více zdrojů najednou v jednom proudu. Ovšem problém FP je zase pojmenování funkcí, takže to zase povede na konstrukt logická_entita.operace(parametry)

Tak ono to FP pokradmu proniká do mainstreamových (vesměs OOP) jazyků. Jistě se prosadí, ale tak nějak postupně a nenápadně...

Tak ono i prosazování OOP do praxe byl velmi klopotný proces a plný kompromisů. Pamětníci vědí :-)))

[zboj]

Koukám další frikulín co naprosto nic netuší o historii a honí si nad tím, jak programuje v tom "moderním" FP a ne v "zastaralém" OOP Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?

Osobně preferuji OOP, OOP se prosadilo, aby se v C nemusely volit názvy jako tmp_xbs_stuff_create(). Do té doby to byla jen univerzitní hříčka, která vznikla stejně jako FP někdy dávno v minulosti. Ostatně všechny koncepty vznikly někdy v pozdních šedesátých letech a začátku let sedumdesátých.

FP se prosadí zase kvůli multiprocesorovému zpracování a čtení údajů (výsledků z jiných procesorů) z více zdrojů najednou v jednom proudu. Ovšem problém FP je zase pojmenování funkcí, takže to zase povede na konstrukt logická_entita.operace(parametry)

Tak ono to FP pokradmu proniká do mainstreamových (vesměs OOP) jazyků. Jistě se prosadí, ale tak nějak postupně a nenápadně...

Tak ono i prosazování OOP do praxe byl velmi klopotný proces a plný kompromisů. Pamětníci vědí :-)))

Jo, pamatuju, byla to směs OO a procedur...

[to_je_jedno]

Za 5 let běžná apka bude vybavena doménovou umělou inteligencí, a na tu budete potřebovat kvůli paralelismu zpracování architekturu podobnou dnešním grafickým kartám. Bude to mainstream.

Jak dlouho nam tvrdi, ze ted uz konecne je ten cas kdy ipv6 bude do x let mainstream? Mas prilis vlhke sny.

[Ivan Nový]

Za 5 let běžná apka bude vybavena doménovou umělou inteligencí, a na tu budete potřebovat kvůli paralelismu zpracování architekturu podobnou dnešním grafickým kartám. Bude to mainstream.

Jak dlouho nam tvrdi, ze ted uz konecne je ten cas kdy ipv6 bude do x let mainstream? Mas prilis vlhke sny.

Největší zpátečníci svým založením jsou admini, většinou to dělají nekreativní typy, cíleně se brání každé změně, proto ještě IP6 není běžné. Jinak je to příležitost pro vás, vymyslet reálné uplatnění této technologie a udělat z toho ten mainstream.

[gll]

Jo, pamatuju, byla to směs OO a procedur...

Dnes je to něco jiného?

[balki]

Dajme tomu, ze si chcem rozsirit obzory a naucit sa nejaky rozumny framework, ktory je dostatocne moderny na pisanie real-time webovych aplikacii a clovek pri pisani v nom nebude pomyslat na samovrazdu. Co to bude? Co si tak pamatam, tak naposledy som dospel k tomu, ze najrozumnejsi vstup do sveta Java frameworkov je Spring boot. Stale to plati? Pripadne existuje nejaka jednoducha cesta ako zacat s Javou na webe (a idealne sa vyhnut vsetkym tym enterprise molochom typu Java EE, Spring MVC)?

Odporucam zrovna to spring MVC v kombinacii so spring boot s embednutym jetty.  Vyhnut sa spring MVC je ako vyliat si dieta aj s vanickou. (Nieco ako v ruby ignorovat rails).  Su aj rozne experimenty typu spark, ale je mozne si webservisy pisat na kolene. No spring MVC  dost pomaha pri robote a velmi neotravuje.

[Kit]

Jo, pamatuju, byla to směs OO a procedur...

Dnes je to něco jiného?

Pokud někdo používá třídy jako namespace pro statické metody, tak je to stejné.

[Ivan Nový]

Jo, pamatuju, byla to směs OO a procedur...

Dnes je to něco jiného?

Pokud někdo používá třídy jako namespace pro statické metody, tak je to stejné.

Jen díky tomu se v praxi OOP ujalo.

[Kit]

Jo, pamatuju, byla to směs OO a procedur...

Dnes je to něco jiného?

Pokud někdo používá třídy jako namespace pro statické metody, tak je to stejné.

Jen díky tomu se v praxi OOP ujalo.

No jo, ale to je jen přechodový krok k opravdovému OOP. Statické metody mají jen velmi omezenou použitelnost.

[gll]

No jo, ale to je jen přechodový krok k opravdovému OOP. Statické metody mají jen velmi omezenou použitelnost.

Souhlasím, že statické metody jsou zbytečnost. Dají se zapsat jako funkce mimo třídu. Nic jako "opravdové OOP" neexistuje. Existují jen jazykové featury usnadňující řešení určitých problémů a komplikující řešení jiných. Nechci začínat flame, ale myslím, že slepá víra v paradigmata škodí. Uživatelé tebou vytvořených knihoven ti nepoděkují, když místo zavolání jedné funkce budou nuceni vytvářet nějaké instance.