Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: jjack 29. 04. 2017, 17:50:45
-
Vsimol som si, ze mnoho ludi nedoporucuje PHP na vyvoj velkych webovych aplikacii. Niesom expert a preto by som sa chcel spytat, preco je to tak? Su tam nejake problemy s vykonom samotneho PHP, alebo si ludia myslia, ze je PHP stale ten jazyk, ktorym bol pred par rokmi? PHP 7 mi pripada celkom fajn - featury ako moznost deklaracie skalarnych typov a navratovych hodnot tomu dost pomohli.
Samozrejme existuje mnoho zaujimavych/modernych programovacich jazykov ako napriklad Elixir alebo Go, lenze zacinat start-up v nejakom taktomto jazyku by bolo asi sialenstvo (minimalne preto, ze je velmi problematicke ziskat dostatok dobrych programatorov v tychto jazykoch).
Okrem PHP tu este existuje moznost zacat pisat webovu aplikaciu v Jave, alebo v Node.js. Java mi pripada mierne legacy a vyvoj v nej nieje prave najpohodlnejsi (v porovnani s PHP). Node.js je fajn, ale pisat v nom celu aplikaciu mi pripada opat nemotorne. Radsej by som Node.js pouzil v kombinacii s PHP tam, kde potrebujem aby bola aplikacia real-timeova - chat, notifikacie, aj ked dnes uz nieje problem pisat to priamo v PHP (websockety pomocou ratchet, reactphp).
-
Ked niekto robi velku webovu aplikaciu, tak volba jazyka je posledna vec, ktora ho trapi na zaciatku. Vacsinou sa riesia poziadavky a architektura. Potom sa to napasuje na nejaky existujuci znamy vzor (alebo technologiu) alebo sa navrhne riesenie vlastne (comu sa vacsinou snazi kazdy rozumny vyhnut, ale ked musis...).
-
Vsimol som si, ze mnoho ludi nedoporucuje PHP na vyvoj velkych webovych aplikacii. Niesom expert a preto by som sa chcel spytat, preco je to tak? Su tam nejake problemy s vykonom samotneho PHP, alebo si ludia myslia, ze je PHP stale ten jazyk, ktorym bol pred par rokmi? PHP 7 mi pripada celkom fajn - featury ako moznost deklaracie skalarnych typov a navratovych hodnot tomu dost pomohli.
S PHP problémy nejsou, jen jsou mírné problémy s některými zdejšími diskutujícími, kteří PHP neznají a prosazují svůj oblíbený jazyk.
Uvedené featury nepoužívám, neboť mé skripty musí fungovat souběžně na verzích 5.3 a 7.0. I tak je PHP moderním jazykem, který má skvělý ekosystém.
-
Za chvíli tu bude flame :-D
PHP měl velmi chaotickou koncepci vývoje a projekty v PHP mají v průměru obecně nižší úroveň. Ekosystém není tak bohatý. Navíc PHP se hodí hlavně na weby. Jiné jazyky mohou být univerzálnější. Výkon nic moc.
Podle mě je optimální java nebo jazyky postavený nad jvm. Ekosystém je tam ohromný, možnosti uplatnění značné, moderní trendy si může člověk nadávkovat dle libosti (výběrem daného jvm jazyka). Akorát je těžší se v tom ekosystému vyznat.
Nejlepší je si na to přijít sám - sám si najít vhodný jazyk pro svoje potřeby a naturel.
-
Za chvíli tu bude flame :-D
PHP měl velmi chaotickou koncepci vývoje a projekty v PHP mají v průměru obecně nižší úroveň. Ekosystém není tak bohatý. Navíc PHP se hodí hlavně na weby. Jiné jazyky mohou být univerzálnější. Výkon nic moc.
Když někdo neumí PHP používat, tak ten výkon bude slabý. V Javě je to podobné. Ten, kdo s těmito jazyky umí zacházet, nemá s výkonem problém.
-
jak píše yad, jazyk je naprosto nepodstatný, často během vývoje se jazyk změní či se nejprve udělá prototyp a pak stabilní řešení v něčem jiném.
PHP pro velké aplikace má jednu obrovskou nevýhodu, není to strktně typový jazyk a má automatické konverze primitivních typů, tím je aplikace náchylná k řadě zákeřných chyb a nedá se dobře použít statická analýza kódu.
Podívej na český internetu, v php je slevomat, damejidlo, heureka, mall nebo root (ikdyž všichni tři využívají části v jiném jazyku pro výkonnost nebo pohodlnost, či jak lákadlo pro programátory). V .NET je třeba alza.
Pokud navrhuješ aplikaci, zapomeň na jazyky, běžně jazyk nechám na volbě prvního programátora, který na tom začne dělat, pokud se jedná o velkou aplikaci, stejně ve finále v ní nezůstane ani kousek původního kódu.
-
Za chvíli tu bude flame :-D
Na flame predsa nieje nic zle. Akonahle zacne flame, tak diskusia naberie na obratkach a padne tam mnoho nazorov. Niektore vecne, niektore skreslene, ale rozumny clovek si z toho snad dokaze vytiahnut to podstatne a overit si, ci je to pravda. V podstate taky brainstorming bez pravidiel :)
Podle mě je optimální java nebo jazyky postavený nad jvm. Ekosystém je tam ohromný, možnosti uplatnění značné, moderní trendy si může člověk nadávkovat dle libosti (výběrem daného jvm jazyka). Akorát je těžší se v tom ekosystému vyznat.
JVM je dnes asi najlepsia volba. Moj problem s Javou, resp. s Java svetom bol vzdy v tom, ze bolo tazke naskocit do toho ekosystemu (Java samotna je jednoduchy jazyk ako kazdy iny). Pri PHP je dnes vsetko v podstate jasne, pokial chcem nejaky framework, tak je zrejme idealny Laravel, s nim dostanem Eloquent ORM a ako server pouzijem s najvacsou pravdepodobnostou Apache (pripadne Nginx). Ako je to pri jave (pripadne inych JVM jazykoch)?
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)?
PHP pro velké aplikace má jednu obrovskou nevýhodu, není to strktně typový jazyk a má automatické konverze primitivních typů, tím je aplikace náchylná k řadě zákeřných chyb a nedá se dobře použít statická analýza kódu.
Mam pocit, ze toto sa prave riesilo v PHP 7. Minimalne po zadefinovani strict_types sa to bude stazovat v situacii, ked metoda ocakava vstup typu int a miesto toho dostane retazec "10". Takze konecne mame aj v PHP istotu, ze ked chceme na vstupe int, tak mozeme pocitat s tym, ze sa do tej metody nic ine nedostane. Pre vyrazy typu 5 + "10" to zial stale neplati.
Suhlasim, jazyk je iba nastroj, ale niekedy prave vyber spravneho programovaci jazyka dokaze usetrit mnoho komplikacii.
Dakujem.
-
Podle mě je optimální java nebo jazyky postavený nad jvm. Ekosystém je tam ohromný, možnosti uplatnění značné, moderní trendy si může člověk nadávkovat dle libosti (výběrem daného jvm jazyka). Akorát je těžší se v tom ekosystému vyznat.
Nejlepší je si na to přijít sám - sám si najít vhodný jazyk pro svoje potřeby a naturel.
Které JVM jazyky mají budoucnost? Přijde mi, že popularita alternativních JVM jazyků trochu upadá. Neřeší problém pomalého startu JVM. Nevyhnete se používání Java knihoven a luštění Java chybových hlášek. Zkoušel jsem Clojure, pěkný jazyk, ale použitelnost snižuje fakt, že běží nad JVM. I překladač Clojurescriptu je kvůli tomu pomalý. Ekosystém týkající se webu má PHP minimálně srovnatelný.
-
PHPko je v pohode, jazyk je jen nastroj. Potrebujes wireframes, potrebujes user stories atd. Pak potrebujes nekoho kdo ti zacne navrhovat frontend, tim zacnes prichazet na potrebu API a pak teprve zacnes resit KDO ti zacne psat backend - a tam ti jazyk prijde tak nejak sam. Tak treba https://weather.com/ - prijde ti to jako dostatecne velky projekt, aby to dokazalo, ze v PHP lze delat i celkem velke veci ktere funguji rychle a spolehlive? Co treba https://www.boston.gov/ , http://www.mtv.co.uk/ atd.
Myslis, ze udelas neco vetsiho?
-
Podle mě je optimální java nebo jazyky postavený nad jvm. Ekosystém je tam ohromný, možnosti uplatnění značné,
(https://i.imgur.com/y41pi4n.jpg)
-
Tady to zase perlí...
Neřeší problém pomalého startu JVM.
Jasně, on se totiž pro každý web request pouští extra JVM, takže start JVM je u webových aplikací ten největší problém, že?
Nevyhnete se používání Java knihoven a luštění Java chybových hlášek.
Java knihovny jsou právě výhoda - najdeš knihovnu prakticky na cokoliv. A přesto, že dělám v Javě docela dlouho, tak nechápu, co to mají být ty "Java chybové hlášky" které se musí luštit.
PHPko je v pohode, jazyk je jen nastroj.
Však sekyra je taky jen nástroj, tak proč řešit, že je tupá, což? Já teda radši používám nástroj vhodný pro daný účel. PHPko je super pro jednoduché věci, jako třeba ten weather.com. Ale používat ho na složitější věci je jako používat tu tupou sekeru. Jde to, ale dost se nadřeš a občas ti skočí a usekneš si prst.
Pokud navrhuješ aplikaci, zapomeň na jazyky, běžně jazyk nechám na volbě prvního programátora, který na tom začne dělat, pokud se jedná o velkou aplikaci, stejně ve finále v ní nezůstane ani kousek původního kódu.
No to by ses divil :D Možná nezůstane přesně v té podobě, trochu se přepíše, ale předělat aplikaci třeba z PHP do Javy se dá těžko dělat nějakými postupnými iteracemi, to musíš vzít a přepsat a to je drahý, hodně drahý. Znám jednu aplikaci, kde byla na startu zvolená technologie, která už tenkrát byla za horizontem (JSP + Spring MVC) a dneska je z hlediska vývoje technologií a požadavků na tu aplikaci silně nevhodná. Sice servisní vrstva může zůstat jak je, musí se přepsat "jen" ten frontend a ta aplikace není moc velká, ale stejně je to darda.
-
jak píše yad, jazyk je naprosto nepodstatný, často během vývoje se jazyk změní či se nejprve udělá prototyp a pak stabilní řešení v něčem jiném.
No nevim nevim, podoba stacku na kterym se bude stavet je zasadni volba a rozhodne by to nemelo byt na libovuli prvniho programatora s k tomu sedne. To by se mohlo stat, ze za pet let budes muset udrzovat aplikace ve vsech trendy jazycich, o ktery tvuj dev team zavadil(a ze jich za posledni dobu bylo kvanta). Jako stejne modni problem vidim trebas nosql databaze, neni moc lidi/projektu co je pouziva opravnene.
Vem v potaz potencionalni implementace stejnyho problemu pomoci:
- apache + php
- apache+python
- apache+perl
Ale co tydle? Implementovat pujde stejna mnozina rozhrani, ale samotna implementace bude velmi velmi odlisna.;
- C + asm
- glassfish + j2ee
- yaws+erlang
PHP pro velké aplikace má jednu obrovskou nevýhodu, není to strktně typový jazyk a má automatické konverze primitivních typů, tím je aplikace náchylná k řadě zákeřných chyb a nedá se dobře použít statická analýza kódu.
Dalsi takovej co veri, ze ho compile time kontrola ochrani : )
Pokud navrhuješ aplikaci, zapomeň na jazyky, běžně jazyk nechám na volbě prvního programátora, který na tom začne dělat, pokud se jedná o velkou aplikaci, stejně ve finále v ní nezůstane ani kousek původního kódu.
Doufam, ze delas jen weby.
-
No to by ses divil :D Možná nezůstane přesně v té podobě, trochu se přepíše, ale předělat aplikaci třeba z PHP do Javy se dá těžko dělat nějakými postupnými iteracemi, to musíš vzít a přepsat a to je drahý, hodně drahý. Znám jednu aplikaci, kde byla na startu zvolená technologie, která už tenkrát byla za horizontem (JSP + Spring MVC) a dneska je z hlediska vývoje technologií a požadavků na tu aplikaci silně nevhodná. Sice servisní vrstva může zůstat jak je, musí se přepsat "jen" ten frontend a ta aplikace není moc velká, ale stejně je to darda.
Ja si vzpominam jak redhat prepisoval c# do javy.. http://lpeer.blogspot.ie/2010/04/switching-from-c-to-java.html
-
Tady to zase perlí...
Neřeší problém pomalého startu JVM.
Jasně, on se totiž pro každý web request pouští extra JVM, takže start JVM je u webových aplikací ten největší problém, že?
Když spouštíte testy po každé změně, tak to vadí.
Nevyhnete se používání Java knihoven a luštění Java chybových hlášek.
Java knihovny jsou právě výhoda - najdeš knihovnu prakticky na cokoliv. A přesto, že dělám v Javě docela dlouho, tak nechápu, co to mají být ty "Java chybové hlášky" které se musí luštit.
Příklad nějaké knihovny, ke které neexistuje ekvivalent jinde?
Psal jsem o chybových hláškách v jiných JVM jazycích, ne Javě. Chybové hlášky v Clojure vadí i jiným.
https://www.reddit.com/r/Clojure/comments/2x1viz/why_are_clojure_error_messages_so_awful/
-
Však sekyra je taky jen nástroj, tak proč řešit, že je tupá, což? Já teda radši používám nástroj vhodný pro daný účel. PHPko je super pro jednoduché věci, jako třeba ten weather.com. Ale používat ho na složitější věci je jako používat tu tupou sekeru. Jde to, ale dost se nadřeš a občas ti skočí a usekneš si prst.
Dokazes nejak definovat ty velky a slozitejsi veci?
Tve prirovnani neni dobre. Lepsi je toto: PHP je ostra sekyrka. Vsak ne kazdy potrebuje dvoumuznou motorovou pilu protoze by denne kacel Arbol del Tule.
-
Dalsi takovej co veri, ze ho compile time kontrola ochrani : )
Nic není stoprocentní. Výhoda compile time není ani tak v nějaké super ochraně jako v tom, že velkou část chyb zjistím rychle a ne až se pustí všechny testy.
Dokazes nejak definovat ty velky a slozitejsi veci?
Vyhledej nejbližší osobu vládnoucí českým jazykem, nebo přinejhorším výkladový slovník, a nech si vysvětlit/přečti význam slov "velký" a "složitý". Pokud ti jde o měřítko, tak teď třeba dělám na projektu kde jen frontend má přes milion řádků Java kódu a přes sto tisíc řádek HTML. A to rozhodně nepovažuji za nějak moc velký projekt.
-
celé jsem to nečetl, takže nevím, co se řeší, ale:
v PHP dělám docela dlouho, už od verze 4.x a ostatní jazyky jsem tak nějak ingoroval, protože mne živí hlavně PHP a můj programovací svět se již několik let točí jen a jen okolo ekosystému PHP. Ale třeba před týdnem jsem nenápadně začal pokukovat po Pythonu a když jsem se do něj trošku položil, tak mě překvapilo, jak moc mi najednou PHP přijde tupé, těžkopádné a omezené.
Pokud chceš dělat weby, záleží, co to má být, co umíš a co chceš používat. Facebook je třeba jedna z největších webových aplikací eva (přimhouříme očka) a je taky od začátku psaná v PHP (beru jádro, ne dnešní javascriptovej bordel okolo).
Vyhovuje ti psát weby v PHP, užívej ho. Vyhovuje ti psát weby v Ruby? Používej je. Vyhovuje ti udělat si vlastní server v C a psát webovky záhadným způsobem v C? Tak di do toho.
-
Dalsi takovej co veri, ze ho compile time kontrola ochrani : )
Nic není stoprocentní. Výhoda compile time není ani tak v nějaké super ochraně jako v tom, že velkou část chyb zjistím rychle a ne až se pustí všechny testy.
Testy jsou pro mne nezbytným doplňkem kompilace a tu necelou sekundu navíc si při testování jednotky klidně počkám.
-
Pokud chceš dělat weby, záleží, co to má být, co umíš a co chceš používat. Facebook je třeba jedna z největších webových aplikací eva (přimhouříme očka) a je taky od začátku psaná v PHP (beru jádro, ne dnešní javascriptovej bordel okolo).
On Python je sice univerzálnější, o něco čistší, ale k PHP nemá moc daleko.
-
Vyhledej nejbližší osobu vládnoucí českým jazykem, nebo přinejhorším výkladový slovník, a nech si vysvětlit/přečti význam slov "velký" a "složitý".
Vis, ony zrovna terminy jako "velky" nebo "slozity" neni moc lehke definovat absolutne, jsou dost relativni.
Ackoliv treba takovy Lomnicak je docela vysokej kopec(minimalne v porovnani s nasima kopeckama) tak v porovnani s jinama je to vlastne takovej prcek.
Pokud ti jde o měřítko, tak teď třeba dělám na projektu kde jen frontend má přes milion řádků Java kódu a přes sto tisíc řádek HTML. A to rozhodně nepovažuji za nějak moc velký projekt.
Weather.com bude dle meho odborneho nahledu a znamych dat mit na backendu nekde mezi pulmega a mega radku kodu. V ČR vidim jen par projektu u nichz bych so mohl myslet, ze maji vic pageloads nez tento projekt. Jak rikam: ne kazdy pise internetovy bankovnictvi, ne kazdej pise ridici SW pro jaderne elektrarny. Jestli si myslis, ze Java je jedine spravne a univerzalni reseni na vse tak nemas pravdu. Neni.
-
On Python je sice univerzálnější, o něco čistší, ale k PHP nemá moc daleko.
Souhlasím, už teď se mi v Pythonu pár věcí nezdá. Nevím ale, jestli je to tím, že jsem třeba navyklej z jiných jazyků.
-
Pokusím se o bonmot: Hlavním problémem PHP je, že se porovnává s Javou.
Takové diskuse byly zajímavé někdy v roce 2002 (jo, to byly časy...), ale dnes je to prostě absurdní.
-
Navíc, pokud chcete porovnávat programovací jazyky, tak by to mělo být syntaxe jazyka X vs. syntaxe jazyka Y. Ne jejich rychlost v nějakém jednom konkrétním případě. To je totiž už porovnávání jejich implementace, nebo jejich překladače.
Takhle se příznivci/odpůrci jazyků X vs. Y nikdy nedomluví. A nic na tom nezmění fakt, že je ta implementace třebas jediná na světě a jinou vybrat nelze.
Když někdo píše, že se X hodí více na něco než Y, tak to není pravda. Moderní programovací jazyky jsou dostatečně univerzální všechny! Jen jejich aktuální implementace se možná na něco hodí více. Mělo by se to začít tady trochu rozlišovat.... podle mě.
-
Ja tohle taky nikdy nechapal, ale asi jen proto, ze jsem nikdy nemusel. Chapu, ze v nekterych situacich je pred zacatkem projektu vyber jazyka podstatny.
-
Takhle se příznivci/odpůrci jazyků X vs. Y nikdy nedomluví. A nic na tom nezmění fakt, že je ta implementace třebas jediná na světě a jinou vybrat nelze.
Když je pro nějaký jazyk z jeho podstaty skoro nemožné napsat překladač schopný generovat tak optimalizovaný kód jako GCC, tak mi přijde v pořádku prohlásit, že je pomalejší než C.
-
On Python je sice univerzálnější, o něco čistší, ale k PHP nemá moc daleko.
Jsou to oba skriptovací jazyky, ale imho moc podobné si teda nejsou.
-
Když někdo píše, že se X hodí více na něco než Y, tak to není pravda. Moderní programovací jazyky jsou dostatečně univerzální všechny! Jen jejich aktuální implementace se možná na něco hodí více. Mělo by se to začít tady trochu rozlišovat.... podle mě.
Nedovedu si dost dobře představit, že bych PHP použil na vědeckotechnické nebo finanční výpočty. Ostatně ani Javu ne. Naopak se oba jazyky skvěle hodí pro práci s textem a kolekcemi. Pro generování HTML však zase oba jazyky kulhají a je nutné je doplňovat nějakými šablonovacími systémy. 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í.
-
On Python je sice univerzálnější, o něco čistší, ale k PHP nemá moc daleko.
Jsou to oba skriptovací jazyky, ale imho moc podobné si teda nejsou.
Podoba sice není patrná na první pohled, ale rozdílný zápis programů ještě neznamená, že ty jazyky nejsou podobné.
-
Pro generování HTML však zase oba jazyky kulhají a je nutné je doplňovat nějakými šablonovacími systémy. 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í.
Problem je v tom, ze PHP je samo o sobe sablonovaci system. A to dost blbej, takze se pouzivaj ruzny hacky a frejmworky, aby se nereklo, ze je na tom PHP tak blbe.
-
Pro generování HTML však zase oba jazyky kulhají a je nutné je doplňovat nějakými šablonovacími systémy. 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í.
Problem je v tom, ze PHP je samo o sobe sablonovaci system. A to dost blbej, takze se pouzivaj ruzny hacky a frejmworky, aby se nereklo, ze je na tom PHP tak blbe.
To je jako byste řekl, že v Javě se používají různé hacky - například návrhové vzory, aby se tam zavedlo dynamické typování.
Věc se má tak, že PHP bylo vždy pragmatické a časem nasávalo koncepty, i někdy trochu módní, z jiných jazyků, OOP z Javy, základy FP z Pythonu, některé věci z Perlu, ... Což dnes Java dělá taky, když se její logický čistý návrh porušuje například generátory a novými prvky FP, čímž se Java zase multiparadigmatickým pojetím blíží i Pythonu.
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.
-
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.
-
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.
-
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ě
-
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.
-
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.
-
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?
-
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á :D
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 :D Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?
-
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 :D 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)
-
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().
-
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 :D :D :D
-
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 :D :D :D
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ě.
-
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? ;)
-
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.
-
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 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 :-)
-
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.
-
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.
-
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.
-
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.
-
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 :D 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ě...
-
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 :D 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í :-)))
-
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 :D 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...
-
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.
-
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.
-
Jo, pamatuju, byla to směs OO a procedur...
Dnes je to něco jiného?
-
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.
-
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é.
-
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.
-
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.
-
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.
-
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.
Záleží na tom, jakou funkci chtějí volat. Simple Factory se nejlépe implementuje právě jako funkce. Je to však důvodem pro umístění do nějaké statické třídy? Není lepší namespace?
Na druhou stranu si mnoho používaných statických metod koleduje o vytvoření regulérních objektů. Ušetří se tím spousta psaní a projekt je pak přehlednější. Nemusí to být vždy stylem Active Recordu - data v tom objektu být nemusí. Stačí konfigurace jako v Data Mapperu.
-
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.
Záleží na tom, jakou funkci chtějí volat. Simple Factory se nejlépe implementuje právě jako funkce. Je to však důvodem pro umístění do nějaké statické třídy? Není lepší namespace?
Na druhou stranu si mnoho používaných statických metod koleduje o vytvoření regulérních objektů. Ušetří se tím spousta psaní a projekt je pak přehlednější. Nemusí to být vždy stylem Active Recordu - data v tom objektu být nemusí. Stačí konfigurace jako v Data Mapperu.
Pokud vytvoření instance ušetří opakované psaní mnoha parametrů, tak má smysl. Ale ne všechny statické metody mají mnoho parametrů.
-
Pokud vytvoření instance ušetří opakované psaní mnoha parametrů, tak má smysl. Ale ne všechny statické metody mají mnoho parametrů.
Vytvoření instance typicky sníží počet parametrů metod o jeden oproti použití statických metod. Je to však jen jeden z mnoha benefitů vytvoření instance. Statické metody bývají poměrně nevýhodné, až na výjimky je vnímám spíš jako klacky pod nohy.
-
Pokud vytvoření instance ušetří opakované psaní mnoha parametrů, tak má smysl. Ale ne všechny statické metody mají mnoho parametrů.
Vytvoření instance typicky sníží počet parametrů metod o jeden oproti použití statických metod. Je to však jen jeden z mnoha benefitů vytvoření instance. Statické metody bývají poměrně nevýhodné, až na výjimky je vnímám spíš jako klacky pod nohy.
Ty neměnné parametry zadáte konstruktoru. Pokud konstruktor nemá parametry, tak k vytváření instance nevidím důvod.
-
Vytvoření instance typicky sníží počet parametrů metod o jeden oproti použití statických metod. Je to však jen jeden z mnoha benefitů vytvoření instance. Statické metody bývají poměrně nevýhodné, až na výjimky je vnímám spíš jako klacky pod nohy.
Ty neměnné parametry zadáte konstruktoru. Pokud konstruktor nemá parametry, tak k vytváření instance nevidím důvod.
Mám důvod. Například psaní testů, které se se statickými metodami píší hodně blbě.
Konstruktor obvykle mívá nejméně jeden parametr. Jinak ten konstruktor nemá moc velký smysl.