Webová aplikácia v PHP

[3ugeene]

No, nemyslim si, ze je to to same. PHP bylo puvodne vytvoreno prave pouze jako sablonovaci system pro pridani dynamickych dat do statickeho HTML, to, ze se pak zaclo pouzivat jako 'plnohodnotny' jazyk, kde najednou plno veci strasne nevyhovovalo, uz je vec druha.

Java byla od zacatku brana jako plnohodnotny programovaci jazyk.


Ale jinak samozrejme chapu, co myslite a souhlasim.

[Reklama]

[Kit]

Generování HTML přímo v PHP má nevýhodu v tom, že snadno může vzniknout nevalidní dokument. Naštěstí to browsery zpravidla zpracují bez větších potíží. I proto raději používám externí šablony, které mi validitu zajistí a s výhodou se dá využít i dědičnost a rekurze.

[3ugeene]

no, nevalidní dokument jen tak vzniknout nemůže, pokud je neodpovídá standardům, tak udělal něco špatně programátor, ne PHP (většinou). S tím se setkávám dnes a denně

[Kit]

no, nevalidní dokument jen tak vzniknout nemůže, pokud je neodpovídá standardům, tak udělal něco špatně programátor, ne PHP (většinou). S tím se setkávám dnes a denně

Když někdo rozdělí funkci pro generování otevírací značky a zavírací značky, typicky u začátku a konce dokumentu, tak se to občas stává.

PHP je v tom samozřejmě bez viny. Obvykle za to mohou chybné návyky programátora.

[Kentus]

PHP je v tom samozřejmě bez viny. Obvykle za to mohou chybné návyky programátora.

Které se ale naučil právě používáním PHP.

[Reklama]

[Kit]

PHP je v tom samozřejmě bez viny. Obvykle za to mohou chybné návyky programátora.

Které se ale naučil právě používáním PHP.

Používání Perlu, C# nebo Javy vede k chybným návykům, používání běžných IDE vede k chybným návykům,... Za chybné návyky může stroj nebo si za ně programátor může sám?

[Lemming]

Weather.com bude dle meho odborneho nahledu a znamych dat mit na backendu nekde mezi pulmega a mega radku kodu.

Jenže tady mluvíme a já jsem mluvil o frontendu.

V ČR vidim jen par projektu u nichz bych so mohl myslet, ze maji vic pageloads nez tento projekt.

Zátěž (pageloads) je zas jiný rozměr.

Jestli si myslis, ze Java je jedine spravne a univerzalni reseni na vse tak nemas pravdu. Neni.

Není, psal jsem to už před několika příspěvky, gratuluji, že jsi konečně dospěl k témuž jako já

Výsledná aplikace bývá tedy obvykle slepencem mnoha jazyků, často doménově specifických, z nichž každý dělá jen to, na co se opravdu hodí.

Ano, EL je čiré zlo. Proto mám rád Wicket, který funguje bez berličky dalšího jazyka.

Až se do mainstreamu prosadí čisté FP jazyky, budou zase zpětně nasávat prvky OOP, protože si je vynutí tlak programátorské veřejnosti.

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?

[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)

[Kit]

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.

Ty dlouhé názvy mi také vadily. V OOP se pro pojmenování čehokoli dá obvykle vystačit s jedním slovem. Stačí umět používat zapouzdření objektů a doplnit namespaces.

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)

To se časem také srovná, až se programátoři ve FP naučí účelně používat namespaces. Vlastně jen byla odstraněna mezivrstva pro pojmenování tříd, takže místo ns.class.method() je ns.ns.function().

[Lemming]

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.

Jasně, multiprocesorové zpracování je totiž horká novinka

[Ivan Nový]

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.

Jasně, multiprocesorové zpracování je totiž horká novinka

V masovém nasazení ano. Dosud se používalo masivně jen v grafických kartách a od nich byla většina programátorů odstíněna grafickými knihovnami. S rozvojem AI a masivními maticovými výpočty v běžných aplikacích vzrostou nároky na organizaci multiprocesorových operací, které budou distribuované po síti. I IoT zařízení nebudou často zcela autonomní, ale výpočet bude probíhat distribuovaně v roji IoT zařízení, kdy roj bude inteligentně reagovat na změnu vnějšího prostředí. Zabývat se detailní komunikací s jednotlivými členy roje bude obtížné a těžko predikovatelné, proto bude vhodné využívat principů FP, které umožňují výpočet rozdělit, aniž by distribuce výpočtu musela být řízena manuálně. FP umožní členům roje serializovat požadavky plynoucí z roje a reagovat na ně sekvenčně.

[Lemming]

V masovém nasazení ano. Dosud se používalo masivně jen v grafických kartách...

Hele, a o multicore CPU jsi už slyšel?

[Ivan Nový]

V masovém nasazení ano. Dosud se používalo masivně jen v grafických kartách...

Hele, a o multicore CPU jsi už slyšel?

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.

[Lemming]

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.

[to_je_jedno]

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 :-)