ugrás a tartalomhoz

A szkriptelés kinyírásával gyorsítaná fel a mobil webet a Google

Hidvégi Gábor · 2015. Okt. 12. (H), 18.19
A HTML egy optimalizált részhalmazára és szabványos widgetekre támaszkodna az új iparági sztenderd
 
1

Nem fog tetszeni

Hidvégi Gábor · 2015. Okt. 12. (H), 19.14
A Google-nek ez a húzása a HTML alapú web és a programozók kőkemény kritikája.

Minden absztrakció hazudik

MadBence frissen beküldött blogmarkja alapján absztrakció esetén figyelmen kívül hagyjuk a nem fontos és irreleváns dolgokat.

A HTML dokumentumok egy rendkívül nagyra hízott DOM fára épülnek, a sok featúra miatt dagadt böngészők közül nálam a chrome és a firefox nagyjából 130-150 megabájt memóriát foglal le úgy, hogy üres lappal indulnak. Az rengeteg!

Első absztrakció: a böngészők elfedik a hardverek közti különbséget. Ennek az ára a fentebb olvasható memóriahasználat. A facebook évekkel ezelőtt elbukott a webes alapú kliensével, azóta nem is próbálkoztak, ráadásul nemrég olvastam, hogy a mobilkliensükből is kénytelenek voltak kiadni egy lite verziót.

Második absztrakció: minden technológiai képletből kihagyják az embert. Ez a legnagyobb hiba.

Az ember mindig többet és többet akar, a nyugati civilizáció erre nevelt minket. Azt hisszük, hogy a több az jobb, és nem vesszük észre, hogy exponenciálisan több problémával szembesülünk nap mint nap.

Nem elég, hogy a böngészők dagadtak, az általunk készített oldalak tele vannak felesleges javascripttel, mert most épp ez a divat. Az alkalmazásokat nagyra nőtt, általános célú keretrendszerekkel készítik el, a legtöbbször ágyúval lőnek verébre. Amikor valaki jQueryt használ, egy újabb absztrakciós rétegen keresztül éri el a hardvert, ami tovább lassítja a futást. Emellett a fejlesztők túlterheltek, és a webes programozás alapjait sem ismerik eléggé.

Megoldás

A Google felismerte, hogy egyrészt túl messzire kerültünk a hardvertől, valamint az átlag programozó (98%) képtelen olyan webes alkalmazást készíteni (mert sem tudása, sem pedig esze sincs hozzá), ami mobil hardveren is jól fut (de akár egy kisebb teljesítményű PC-n), amit nehezít a böngészők automatikus memóriamenedzsmentje. Ezért létrehoztak egy olyan platformot, ahol tudatosan korlátok közé van szorítva az ember állati mohósága.

Itt az ideje elismerni a tévedésünket. Ha a Google is azt mondja, hogy az egyszerűsítés az út, akkor érdemes megfontolnunk nekünk, fejlesztőknek is ugyanezt!
17

Zsákutca

vbence · 2015. Okt. 14. (Sze), 14.56
Szerintem túlbecsülöd a ma használt absztrakciók költségét.

Van ahol valóban sokszorosára növekszik a költség (egy natív megoldáshoz képest), ezek a megoldások általában inkább kényelmi dolgok (említetted a túl al acsony szakmai színvoanlat), vagy a platform megerőszakolásából adódnak (olyan csillivlli dolog lesz az oldalunkon mint tényleg senki másnak). - Az esetek nagy része azonbna nem ilyen. A JIT compilerek és hotspot VM-ek világában 20% sebesség veszteség már soknak számít.

Miután elértük, hogy a weboldalknak ne alternatív mobil verzióik legyenek, hanem alternatív vizuális reprezentációik (reszpontzív felületek). Egy alternatív output készítése a meglévő tartalomból egy lépés a rossz irányba.

Az Apple+adblok témában néhány hete elhangzott több felől is, hogy többségében a hirdetők azok akik lerontják a böngészés minőségét.

Ami nem tetszik a Googlenek szvsz az, hogy a felhasználók sávszélessége és számítókapacitása folyamatosan (gyorsuló mértékben) növekszik, és a web, mint kompetitív közeg ki is használja ezeket a lehtőségeket (nagyobb felbontású képek, videobannerek, parallax scroll). - A tartalom egyre inkább elmegy a rich media irányába a puszta szövegtől, aminek hatékony szkennelése nekik iszonyatos költségekkel jár (JS futtatása pl).
19

A főnököm szokta mondani,

Hidvégi Gábor · 2015. Okt. 14. (Sze), 15.35
A főnököm szokta mondani, hogy a szoftver az olyan, mint a gáz, mindig kihasználja a rendelkezésére álló teret.

Szerintem pedig szinte minden fejlesztő alábecsüli az absztrakciók költségét, mert kimarad belőle az ember.
Tegye fel a kezét, aki nem találkozott még olyannal, hogy felépít egy nagyon szuper objektumstruktúrát, implementálja, aztán az ügyfél olyat kér, hogy lehet átírni az egészet vagy egy részét – mert így alakult az élet.

Egy alternatív output készítése a meglévő tartalomból egy lépés a rossz irányba.
Ezzel nem értek egyet. Mint ahogy másképp kell tálalni nyomtatva a tartalmat, mint on line, a mobil és az asztali nézet között is lehetnek hasonló eltérések. Másképp használják az emberek a különböző médiumokat, ráadásul elég sok eltérés van ahhoz, hogy minden esetben meg lehessen oldani pár egyszerű css definíció átírásával.
24

Szerintem pedig szinte minden

BlaZe · 2015. Okt. 14. (Sze), 21.59
Szerintem pedig szinte minden fejlesztő alábecsüli az absztrakciók költségét, mert kimarad belőle az ember.
Tegye fel a kezét, aki nem találkozott még olyannal, hogy felépít egy nagyon szuper objektumstruktúrát, implementálja, aztán az ügyfél olyat kér, hogy lehet átírni az egészet vagy egy részét – mert így alakult az élet.
Ez project management, tervezési probléma. Hogy jön ez az absztrakciókhoz?
25

A project management fogja

Hidvégi Gábor · 2015. Okt. 14. (Sze), 22.24
A project management fogja implementálni a változtatásokat?
26

A sales munkájának mi köze az

BlaZe · 2015. Okt. 14. (Sze), 23.20
A sales munkájának mi köze az absztrakciókhoz? Ők is olyan munkát végeznek, aminek a vége az lesz, hogy a fejlesztők implementálni fognak.

Valóban, ha újra kell implementálni valamit, annak van költsége. De ennek semmi köze az absztrakciókhoz, ez egy management probléma. Ha ilyenkor a költség a fejlesztő cég oldalán jelentkezik, az meg pláne. Viszont (előre) jól megválasztott absztrakciókkal az ilyen átalakítások költsége jelentősen csökkenthető. De erről már volt szó elég sokat.

Ha visszaemlékszel 10-15 évvel ezelőttre, ugyanaz a böngésző tök máshogy jelenített meg dolgokat linux, meg windows alatt. A különböző típusúakról meg már ne is beszéljünk. Ma már ez kevésbé van jelen. Biztos, hogy rossz irányba mentek a böngészők? Hogy több ramot esznek, az egy dolog. A gépekben is több ram van. Sokkal több. Ez tényleg akkora probléma?
33

Absztrakciók

Hidvégi Gábor · 2015. Okt. 15. (Cs), 09.18
Akkor kezdjük az elején:

A böngésző egy olyan interpreter, ami bármilyen hardveren futva ugyanolyan kimenetet fog produkálni ugyanarra az inputra. Az absztrakció itt az, hogy kivonjuk a hardvert. Ennek az az ára, hogy a böngészőben minden objektumnak és műveletnek jóval nagyobb az erőforrásigénye, mintha ugyanezt natívan valósítanád meg.

Biztos, hogy rossz irányba mentek a böngészők? Hogy több ramot esznek, az egy dolog. A gépekben is több ram van. Sokkal több. Ez tényleg akkora probléma?
Igen, akkora probléma. Hadd idézzek a blogmark szövegéből:
A Google szerdán egy új kezdeményezést jelentette be, aminek célja, hogy jelentős mértékben felgyorsítsa a mobilos webolodalak betöltési és működési sebességét.
A böngészős absztrakció tehát két helyen szivárog: kivonja a hardvert a képletből, ami egy, a PC-knél jóval lassabb és jóval kevesebb memóriával rendelkező mobil eszköznél már észrevehetően lassabban működik, ezt pedig tetézi, hogy az automatikus szemétgyűjtés miatt nincs a kezedben a memóriamenedzsment.

Másrészt kivonja a képletből a programozót, aki
- képzetlen,
- nem tudja és nem is érdekli, hol járjon utána, hol kell rendesen megtanulni programozni,
- a folyamatosan fejlődő technológia és információdömping mellett nem találja a rendezőelveket,
- állandó nyomás alatt van a megrendelőitől,
- ember.

Ez a programozó, engedve a divatnak telerakja a weboldalt mindenféle csilli-villi vacakkal, három jQuery-vel, leteszteli a saját, nyolc gigabájt memóriával rendelkező i7-esén, és csodálkozik, hogy lassú mobilon.


Google-ék csináltak egy újabb absztrakciót, kivonták a programozót a képletből, mert tudják, hogy 99% valószínűséggel nem fog tudni jót alkotni a fentiek miatt.
36

Tehát

Endyl · 2015. Okt. 15. (Cs), 10.58
  • Böngésző vs. vas:

    Tehát a megoldás az, hogy mindenki írja meg assemblyben saját szerver- és kliensoldali alkalmazását (minek az a sok ballaszt)? Mindezt amellett, hogy egész nap mennie kell földet művelni és állatot etetni, mert az élelmiszeriparhoz képest ez sokkal közelebb áll a természethez (és mert minden létező absztrakció az ördög műve).

  • Tudatlan programozók:

    Probléma: túl sok a kontár a szakmában. Megoldás: legyen még egyszerűbb a kontárok dolga. Nehogy bárkinek is eszébe jusson, hogy ez is egy szakma, amihez (és a mögöttes technológiához) nem árt érteni és ahhoz bizony tanulni kell.

  • Absztrakciók:

    Annyira bonyolultra és szivárgóra lett absztrahálva az egész (állítólag), hogy a megoldás nem más, mint az egészből kivonni a megbízhatatlan szakembert az által, hogy az egészre húzunk még egy absztrakciót (ami nyilván még nagyobb lesz, mivel a szakembert kell helyettesítenie konfigurációval), amit más szakemberek írnak (akikre valamilyen csoda folytán a fenti nehezítő körülmények nem hatnak). És mivel ez minden eshetőséget lefed, nyilván pofon egyszerű lesz, és szivárogni sem fog.


Szerintem viszont az absztrakciók nem rosszak. Az a rossz, ha azt hisszük, hogy az éppen aktuális absztrakció örökérvényű és minden olyan újdonságot el kell utasítani, ami miatt netán hozzá kellene nyúlnunk az absztrakciónkhoz, mert akkor uram bocsá' tanulnunk, döntenünk, választanunk kellene, neadjisten újra kell gondolni és újra kell írni az absztrakciónkat.
38

+1 úgy ahogy van

bamegakapa · 2015. Okt. 15. (Cs), 11.18
+1 úgy ahogy van
40

Látom, nagyon a szívedre

Hidvégi Gábor · 2015. Okt. 15. (Cs), 11.50
Látom, nagyon a szívedre vetted, amit írtam. Miért? Miért baj az, ha az absztrakciók számának csökkentése mellett vagyok?
41

Nem vettem a szívemre semmit

Endyl · 2015. Okt. 15. (Cs), 12.18
Nem vettem a szívemre semmit :) A logikai bukfencekre próbáltam rámutatni.

Nem baj, ha csökkenteni kell az absztrakciók számát. Ha annyira nem vetted volna a szívedre, amit írtam, akkor láttad volna, hogy az utolsó bekezdésben azt írtam, hogy az absztrakciókat időről-időre újra kell gondolni, akár az egészet újratervezni, újraírni.

A baj az, ha kőbaltával akarunk fát vágni, mert a motoros fűrész használatát tanulni kell ahhoz, hogy hatékonyan és biztonságosan tudd használni. Holott nem nyerünk vele semmit, mert a kőbaltával is magunkra dönthetjük a fát, vagy okozhatunk vele kárt másnak, ha nem értjük, hogy "hogyan működnek" az éles dolgok, vagy a gravitáció.
56

Természetesen jó dolog amit

Hidvégi Gábor · 2015. Okt. 20. (K), 11.39
Természetesen jó dolog amit írsz, újra kéne tervezni és írni az absztrakciókat, de ki fogja ezt megfizetni? Egy kis szoftvernél még belefér, de ha cseppet is összetettebb, meg fogod csinálni?
59

Tehát ha egy szoftver (legyen

Endyl · 2015. Okt. 20. (K), 12.04
Tehát ha egy szoftver (legyen az kicsi vagy nagy) nincs különböző absztrakciós szintekre bontva, hanem az egész szorosan csatolt, akkor azt a megváltozott körülmények/követelmények esetén nem kell újraírni, csak a lazán csatoltat? Vagy mire akarsz kilyukadni?

Megfizetni meg az fogja, aki szeretné, hogy a megváltozott helyzetben is működjön a szoftver. Akit meg megfizetnek, az meg újraírja. De ez bármilyen területen, bármilyen változás esetén így van. Hacsak nincs valakinél hivatásos jós foglalkoztatva, akinek a segítségével olyan terméket tudnak tervezni, amit soha nem kell módosítani.
45

A mobilomban több ram van, és

BlaZe · 2015. Okt. 16. (P), 00.35
A mobilomban több ram van, és sokkal erősebb proci, mint az asztali gépemben volt 10-15 éve. Pedig már 3 éves darab. Gyorsabb is benne a böngésző. Ez az érv egyszerűen nem állja meg a helyét.

Ettől még persze vannak lassú, rossz weboldalak. De ahogy írod is, ez valójában a hozzá nem értő emberek miatt van. Direkt nem írok programozót. A webes szakma nagy tragédiája, hogy nem tudja kivetni a pistikéket.

Az automatikus szemétgyűjtést nem tudom miért hozod fel a negatív oldalon. Isten óvjon minket attól, hogy el kelljen megint kezdeni memóriakezeléssel foglalkozni. Főleg, hogy a pistikék tegyék... Az is egy közkeletű tévedés, hogy a gc lassú programokat hoz magával. Ez nem igaz, sőt. Nagyobb átlagos reszponzivitást biztosít azon az áron, hogy random időpontban egy pillanatra ez le tud csökkenni. Ugyanis a memória felszabadítása egy baromi drága művelet, aminek a költsége nem jelenik meg a program futásának 99%-ában. Amikor mégis, akkor pedig koncentráltan, optimalizálható módon. Ami miatt ez a tévedés él, hogy sok API, programozó pazarlóan bánik a memóriával. De ez nem a gc hibája. A gc a memóriafoglalás kezelésének ma ismert leghatékonyabb módja, mára már nagyon kihegyezett algoritmusokkal.

Továbbra is azt érzem, hogy az absztrakciót mint fogalmat rosszul értelmezed és használod, de ebbe már nem akarok belemenni, többen is rávilágítottak.
46

Szvsz. csak azt nem érti meg,

inf3rno · 2015. Okt. 16. (P), 03.31
Szvsz. csak azt nem érti meg, hogy a compiler egy oo kódból képes ugyanolyan gyorsat csinálni, mint amit ő procedurálisan összerak, rétegzés ide vagy oda. Plusz mellette még átláthatóbb is lesz a kód. Gondolom ez x éve még nem így volt, és azóta nem jött át neki, hogy változott a világ.
47

Ettől még persze vannak

Poetro · 2015. Okt. 17. (Szo), 12.13
Ettől még persze vannak lassú, rossz weboldalak. De ahogy írod is, ez valójában a hozzá nem értő emberek miatt van. Direkt nem írok programozót.
Miért gondolod, hogy mindenképpen a programozó a hibás? Általában nem ő szabja meg a követelményeket, és választja ki a hardvert. Sokszor a körülmények a programozó ellen vannak, és hiába igyekszik, jelentős javulást nem tud elérni.
48

Általánosságban beszéltünk,

BlaZe · 2015. Okt. 17. (Szo), 23.05
Általánosságban beszéltünk, és a tapasztalat az, hogy a programozók jelentős része nem tud hatékony programot írni. Frameworkök, APIk mentén gondolkodnak, és nem veszik a fáradságot, hogy megismerjék az adott eszköz hogy működik, mik a határai. Ez kiváltképp így van a webes szakmában, pont az említett alacsony belépési küszöb miatt. Nagyon sok webes kódot olyan emberek írnak, akiknek nem sok programozói előképzettségük van.

Az szerintem egy másik dolog, amit mondasz. De ott is valaki hozott döntést, hogy milyen eszközökkel, milyen hardware-en, milyen specifikációjú program fusson. Ezeket a döntéseket szakember bevonása nélkül meghozni értelmetlen. Ha pedig szakember közreműködésével állapítják meg mi legyen, és mégsem teljesíti a non-functional elvárásokat, akkor a) a közreműködő szakember nem volt elég felkészült, b) az implementációt végző programozók nem elég felkészültek, hogy a meghatározott eszközökkel kihozzák az elvártakat. Mindkettő szakember(ek) hibája.

Van még egy nagyon fontos dolog szerintem: a fejlesztés közben nem általános a mérés, ezt valamiért csak kevés cég gondolja, hogy a munka szerves része lenne. Aztán a végén, amikor átadják a programot, kiderül hogy baromi lassú. És akkor jön az, hogy a programozó próbálkozhat, de komoly architekturális változtatások nélkül érdemi változást nem tud elérni.

Én azt gondolom, hogy programozókként mindig jelentős a felelősségünk, hogy egy project sikeres lesz-e, vagy sem. Hiszen mi dolgozunk rajta. Ha látjuk, hogy rossz irányba mennek a dolgok, nyomni kell a csengőt, nem mutogatni utána, hogy dehát a managerek. A managerek célja, hogy a project sikeres legyen, és ehhez mi vagyunk nekik az input. Ha szólunk hogy baj lesz, oda fognak figyelni, mert érdekük.

Picit messzire mentem a kérdésedtől, meg a technikai aspektustól, de szerettem volna rámutatni, hogy programozóként nem csak egy specifikáció->kód konverter vagyunk, nagyon sok ponton tudunk hatni a dolgokra. És hát nekünk se mindegy, hogy x hónap, év munkánk eredménye sikersztori, vagy égés. Úgyhogy érdemes is.
49

Szerintem irreleváns

Hidvégi Gábor · 2015. Okt. 19. (H), 13.01
Szerintem irreleváns információ az, hogy a te mobilod milyen paraméterekkel rendelkezik, mivel egy darabról van szó összesen. Emellett feltételezem, hogy három éve nem a legegyszerűbb, de nem is közepes készüléket vettél, plusz azt se felejtsük el, hogy a hardverek azóta nem fejlődtek túl sokat (egy-két további mag nem oszt, nem szoroz annyit a weben).

Szerintem az a fontos, hogy az átlagembernek milyen mobilja van. Lehet, hogy tökéletesen elégedettek egy kétmagos, egy gigabájt memóriás, 800x480-as felbontású készülékkel.

Biztos te is olvastál olyan cikkeket, ahol bemutatják, a weboldalak is mennyit nőttek az elmúlt években, erről sem szabad elfelejtkezni.

A böngészőkben nem az automatikus szemétgyűjtés az érdekes, hanem az, hogy a memóriamenedzsmentnél nincs választási lehetőséged. Egyszerűen nincs ráhatásod, mikor törlődnek a memóriából a dolgok, és pár kép betöltésével megtelítheted a rendelkezésre álló keretet. Nem véletlen, hogy még mindig népszerűek a mobilos, kvázi natív alkalmazásfejlesztői állások.
50

Ezt most mire válaszul írtad?

BlaZe · 2015. Okt. 19. (H), 21.33
Ezt most mire válaszul írtad? Én amire utaltam, hogy egy átlagos telefonban sokkal erősebb hardware van, mint régen a gépekben volt, jóval több rammal. Mindezt arra válaszul, hogy szerinted a hw a szűk keresztmetszet, és nem bírja el az absztrakciókat. Ez így nem igaz.

A böngészőkben nem az automatikus szemétgyűjtés az érdekes, hanem az, hogy a memóriamenedzsmentnél nincs választási lehetőséged. Egyszerűen nincs ráhatásod, mikor törlődnek a memóriából a dolgok, és pár kép betöltésével megtelítheted a rendelkezésre álló keretet. Nem véletlen, hogy még mindig népszerűek a mobilos, kvázi natív alkalmazásfejlesztői állások.
Ezzel mit szeretnél mondani? Hogy ha betöltesz sok képet, elfogy a memória? Ezen semmilyen memóriakezelés nem segít. Ha a képet nem használja kód, a gc szépen fel fogja szabadítani, ha kell memória. Ha fogja még valami, akkor meg nyilván nem.
51

Arra válaszul írtam, hogy

Hidvégi Gábor · 2015. Okt. 19. (H), 21.57
Arra válaszul írtam, hogy nőhetett a hardver sebessége, de a szoftverek kötetelményei is haladtak vele párhuzamosan, valamint a weboldalak mérete. Nincs (bár lehetne) jobb felhasználói élménye egy mai usernek, mint tizenöt éve. Ráadásul mobilon 2 GHz nem ugyanaz, mint x86-on, valamint a memóriák sebessége sem éri el a PC-két.

A GC-nél az okozza a problémát, hogy nincs ráhatásod, mikor fusson le a szemétgyűjtés. Keressem meg neked a linket, ahol facebook-ék panaszkodnak, miért lehetetlen webes klienst készíteniük?
52

Nincs (bár lehetne) jobb

BlaZe · 2015. Okt. 19. (H), 22.24
Nincs (bár lehetne) jobb felhasználói élménye egy mai usernek, mint tizenöt éve.
Ezt mi alapján írod? Én egyáltalán nem ezt tapasztalom. Nagyságrendekkel jobb a user experience, mint 15 éve. Az asztali gépek is lassan renderelték a weboldalakat, állandóan swappeltek scrollozás közben, és baromira szétesett minden második weboldal minden második browserben az inkompatibilitás miatt. Szerintem az volt a rossz felhasználói élmény. Most mobilon is sokkal reszponzívabb, mint akkor volt asztali gépen. És nem is hullik szét.

A GC-nél az okozza a problémát, hogy nincs ráhatásod, mikor fusson le a szemétgyűjtés.
És ez miért baj? Biztos van olyan környezet, ahol manuálisan nem lehet triggerelni, de alapvetően a GC egy eventre fut le. Ez az event simán lehet explicit GC request is. Hogy jó-e manuálisan triggerelni, az másik dolog. Összességében számtalan előnye van a GC-nek a manuális memória allokációval szemben. Nem véletlenül használják már szinte minden magasabb szintű nyelvben.

Keressem meg neked a linket, ahol facebook-ék panaszkodnak, miért lehetetlen webes klienst készíteniük?
Kíváncsi lennék, ha megtalálod. User felületnél kicsit komolyabb latency SLA-val rendelkező rendszerek működnek GC mellett. Nem hinném, hogy maga a GC intézménye lenne a rossz. Persze vannak különböző megközelítésű és minőségű implementációi. De akkor megint a fejlesztők felelősségéhez kanyarodunk vissza.
53

Betting on html5 was a mistake

complex857 · 2015. Okt. 19. (H), 23.03
Keressem meg neked a linket, ahol facebook-ék panaszkodnak, miért lehetetlen webes klienst készíteniük?

Valóban volt ilyen, Mark Zuckerberg nyilatkozta volt, hogy: "Our Biggest Mistake Was Betting Too Much On HTML5". , majd jelent meg publikáció arról, hogy natív iOS kliens mennyivel gyorsabb mint html5 verzió volt.

Persze mindez nem maradt válasz nélkül azoktól akiknek üzletpolitikája erősen kötődik html5 sikeréhez mint sencha, akik előálltak egy "fastbook" kliens demóval, a videón persze elég meggyőző.

Szóval annak hiszel akinek akarsz (-:
54

Szerintem HG nem erre

BlaZe · 2015. Okt. 19. (H), 23.39
Szerintem HG nem erre gondolt, mert ezek nem a GC-ről szólnak. Hogy a natív alkalmazások reszponzívabbak a HTML5-nél, azon gondolom senki nem lepődött meg. Főleg mivel levették vele a UI szálról a feldolgozást. De Gábor nem emellett érvelt.

Köszi amúgy a linkeket.
55

Ha csak a vasat nézzük és a

inf3rno · 2015. Okt. 20. (K), 03.25
Ha csak a vasat nézzük és a wikipedia-t vesszük alapul, a Moore trv. szerint minden 18. hónapban duplázódik a CPU teljesítmény. Ez pont 1.5 év, szerencsések vagyunk, mert 15 év alatt így 10x duplázódott a teljesítmény és 2^10-ről mindenki tudja, hogy 1024 ezekben a körökben. Nagyjából ennyi hardverben a teljesítmény növekedés 15 évvel ezelőtthöz képest. Nem csak CPU-nál érvényes a dolog, hanem memóriánál, tárhelynél, stb... is. Pont most találtam egy 1.5GB-os Seagate vinyót made in Ireland felirattal, ha kell valakinek múzeumba szívesen elküldöm. :-P

A UE szerintem nagyságrendekkel jobb, mint volt, bár már alig emlékszem a 15 évvel ezelőttiekre. Annyi rémlik, hogy akkor még netscape volt meg msie. Css, js már volt, de még a jquery, prototype.js, stb... előtti idők voltak, és ritka volt az olyan js kód, ami mindkét böngészőben futott. Felhasználóként annyi rémlik, hogy eszeveszett lassú volt minden, ami talán nem csoda, nem volt vas alatta, nem volt sávszél, és így tovább. A mai mobilokon különb a 3G, bár az is nagyon lassú tud lenni. A régi PC-ket a mai mobilokkal összehasonlítani felhasználói élmény terén meg nem éppen fair dolog. Nagyon más a kettő.
57

Moore-törvénynek nevezzük azt

Hidvégi Gábor · 2015. Okt. 20. (K), 11.49
Moore-törvénynek nevezzük azt a tapasztalati megfigyelést a technológiai fejlődésben, mely szerint az integrált áramkörök összetettsége – a legalacsonyabb árú ilyen komponenst figyelembe véve – körülbelül 18 hónaponként megduplázódik
A wikipédiáról. Ennek semmi köze a teljesítményhez, ráadásul egy jóideje már csak a magok számát tudják növelni, ami egyáltalán nem biztosít egyenes arányú teljesítménynövekedést, főleg akkor, ha közös memóriával dolgoznak a magocskák.
61

Na ne mondd már, hogy a user

inf3rno · 2015. Okt. 20. (K), 18.18
Na ne mondd már, hogy a user experience-nek semmi köze a teljesítményhez... Ez nem kicsit nonszensz.
63

Direkt kiemeltem az

Hidvégi Gábor · 2015. Okt. 20. (K), 18.42
Direkt kiemeltem az "összetettsége" szót. Nem jól fogalmaztam, inkább úgy a helyes: a tranzisztorok számával nem nő egyenesen arányossággal a sebesség. Ráadásul nemrég olvastam, hogy azt hiszem 14 nm alá nem nagyon mennek már a chipgyártók, mert nem éri meg, tehát a magméretet fogják növelni valószínűleg a jövőben, aminek van határa.
64

Wikipedia szerint ez az

inf3rno · 2015. Okt. 20. (K), 20.10
Wikipedia szerint ez az ütemterv:
14 nm – 2014
10 nm – 2016-2017
7 nm – 2017-2018
5 nm – 2020-2021


Az összefüggésre azt mondják, hogy nem teljesen lineáris, de azért nagyjából becsülhető belőle a teljesítmény. 5nm-es tranzisztor már ma is létezik, a probléma inkább a tömeggyártásba vitelével van. Gondolom mire lemennek 5nm-ig, addigra lesznek még kisebbek. Nekem egyáltalán nem tűnik úgy, hogy bármi limitálná a dolgokat. Közben meg gőzerővel dolgoznak a kvantum processzoron is. Szóval mire odáig érnénk, hogy tényleges méret korlátba ütköznek, addigra már bejöhetnek azok is.
67

Gazdasági vonzat

vbence · 2015. Okt. 21. (Sze), 09.05
Itt egy érdekes elemzés az Economisttól Moor's Law kapcsán. Igazából rendszeresen írnak róla.

Another thing often overlooked is that Moore’s law has always been as much about reductions in the cost of transistors as about increases in their performance.

Unfortunately, as transistors get smaller, more defects creep in. And, while the cost per transistor is almost inversely proportional to the number of transistors crammed in a chip, there comes a point where the decrease in yield (percentage of good chips on a wafer) begins to outweigh the benefits of the chip’s increasing complexity.

And here’s the crunch: that minimum cost per transistor has been rising since 28nm chips hit the market several years ago [...]
71

Nemrég láttam egy filmet

inf3rno · 2015. Okt. 22. (Cs), 06.54
Nemrég láttam egy filmet erről a tunnelling-ről meg más kvantum effektusokról. Kiderült, hogy az élővilág is használja őket pl enzimeknél, illetve a pontmutációk is így jönnek létre a DNS-en. Tök érdekes terület, egyetemen nem is igazán tanítják. Van egy frankó könyv is róla, csak 100k körül van az ára. :S

Ezekből a kvantum processzorokból meg foton alapú processzorokból szerinted esélyes, hogy egy-két évtizeden belül valami lesz?
72

Pont a múlt héten

vbence · 2015. Okt. 22. (Cs), 09.24
Pont a múlt héten volt erről egy optimista Microsoft jelentés.

Amit én látok, tendenciát, az hogy a számítás egyre inkább datacenterekbe költözik az eszközeinkről, itt pedig rengeteg kihasználatlan lehetőség van.

Jelenleg a legjobb helykihasználás 2 (nagyon ritkán 4) fizikai CPU egy 19 inches rackfiókban. Ennek sokszorosát is el tudom képzelni ugyanebben a méretben.

Ha CPU-intenzív programokról beszélünk, amiket egyszerre sokan használnak (Photoshop), akkor a cloud-szolgáltató felprogramozhat néhány FPGA magot azokkal az algoritmusokkal, amik nagységrendekkel gyorsabbá teszik. Ilyet otthon nem éri meg, nem használnád ki, de egy számító-telepen több nagyságrenddel tudná csökkenteni mondjuk egy gaussian blur kiszámításának (beruházás és energia) költségét.

Következő lépésnek ott az ASIC, ha egy algoritmust ténlyleg sokan használnak.

Egy ilyen környezetben tudom elképzelni a fenti quantum-hagyományos hibrid megoldást. - Persze ennek előfeltétele egy megbízható hálózat, de azon a fronton a meglévő technológiákat sem használjuk ki.
73

Szerintem a Moore törvényét

inf3rno · 2015. Okt. 22. (Cs), 10.18
Szerintem a Moore törvényét nem kell szigorúan csak szilícium chipekre alkalmazni. A te cikkedben is azt írják, hogyha eléri a szilícium a határait, akkor gallium-arzenides vagy grafénos technológiákra át lehet térni. Szóval kapásból van 4 új irány, ahova lehet fejlődni, meg gondolom egy csomó másik, amiről nem tudok, mert nem néztem utána. Valószínűleg a szilícium határai nem jelentik a Moore törvény bedőlését.

Egyébként aksiknál is ugyanezt látom, körülbelül 20-30 kisebb technológiai váltás volt, és mindegyik csak egy kicsivel növelte az aksi energiasűrűségét. Lassan áttérnek lítium-kén alapú aksikra, amiknél az elvi határ sokszorosa a lítiumos aksikénak, de jelenleg még csak kísérleteznek vele. Ha stabilan tudnak hozni vele kicsivel jobbat, mint a régi technológiával, akkor pár év alatt teljesen áttérnek majd rá, és azt fejlesztik tovább. Nincsenek nagy ugrások...

Ha CPU-intenzív programokról beszélünk, amiket egyszerre sokan használnak (Photoshop), akkor a cloud-szolgáltató felprogramozhat néhány FPGA magot azokkal az algoritmusokkal, amik nagységrendekkel gyorsabbá teszik. Ilyet otthon nem éri meg, nem használnád ki, de egy számító-telepen több nagyságrenddel tudná csökkenteni mondjuk egy gaussian blur kiszámításának (beruházás és energia) költségét.


Hát ha megéri majd megvenni az idő különbözetet, akkor ennek tényleg lesz így értelme.

Ja hát az meg a másik, hogy nem hiszem, hogy sokan tartanának folyékony nitrogént itthon azért, hogy menjen a quantum computer, data centerekben viszont teljesen elképzelhető, hogy egy csapatot ráállítanak a témára, ha tényleg hozza majd a számítási kapacitást.
74

Pont most futottam bele egy

inf3rno · 2015. Okt. 23. (P), 18.25
75

Friss írás a hwsw-n a

Hidvégi Gábor · 2015. Nov. 4. (Sze), 09.26
Friss írás a hwsw-n a témában, az intel még a 14nm-es csíkmérettel is szenved.
65

ráadásul egy jóideje már csak

BlaZe · 2015. Okt. 20. (K), 22.11
ráadásul egy jóideje már csak a magok számát tudják növelni
Erről már volt szó korábban, és ez a megállapítás természetesen egyáltalán nem igaz. Jelentősen megváltozott az architektúra, a pipeline, több szintű és egyre gyorsabb lett a cache, egyre hatékonyabb spekulációs algoritmusok segítik a hatékony programvégrehajtást, ezt támogató új utasításokat, sőt utasításkészleteket fejlesztettek ki stb. Ennek megfelelően nagyon jelentős effektív sebességnövekedés volt megfigyelhető a CPU-kban, és úgy egészében véve a számítógépekben. Hoztam neked erre konkrét előadást, ahol ez számokkal is alá volt támasztva. Ráadásul nem egy akárkitől...

ami egyáltalán nem biztosít egyenes arányú teljesítménynövekedést, főleg akkor, ha közös memóriával dolgoznak a magocskák.
Azért a magocskáknak van dedikált cache-e :) És ha ért hozzá a programozó, azt ki is lehet használni. Ha kevésbé ért hozzá, akkor is szerencsére ott vannak a mára már elég okos fordítók, amik igyekeznek az adott CPU képességeit teljeskörűen kihasználni. Persze egy ponton túl nem tudják már helyettesíteni a szakértelmet, ha pl struktúrákról van szó, ott nagyon sok múlik a programozón.

A lényeg, hogy ez egy közkeletű urban legend. A mérnökök nem szarral gurigáznak, és nagyon komoly teljesítménynövekedést tudtak és tudnak elérni.
76

A szoftver olyan, mint a gáz,

Hidvégi Gábor · 2015. Nov. 4. (Sze), 09.29
A szoftver olyan, mint a gáz, mindig kitölti a rendelkezésére álló teret, lásd 69-es hozzászolásom. Ez köszönhető annak, hogy a fejlesztők abban az ostoba hipnózisban élnek, miszerint egy program sosincs kész.
77

Hát ahogy vesszük. Egy idő

inf3rno · 2015. Nov. 4. (Sze), 15.30
Hát ahogy vesszük. Egy idő után el kell engedni, de ott motoszkál az emberben, hogy nem tökéletes. Nyilván soha nem is lesz az.
78

Ez köszönhető annak, hogy a

BlaZe · 2015. Nov. 4. (Sze), 23.49
Ez köszönhető annak, hogy a fejlesztők abban az ostoba hipnózisban élnek, miszerint egy program sosincs kész.
Ez a kép nagyjából választ ad arra, hogy egy program mikor van "kész": ha már retired. Addig változó intenzitással, de foglalkozni kell vele.
79

Igazából akkor sem, mert a

inf3rno · 2015. Nov. 5. (Cs), 09.50
Igazából akkor sem, mert a kivonás inkább azt jelenti, hogy már nem éri meg foglalkozni vele. Attól még ugyanúgy lehetnek benne javítatlan bug-ok.

Érdekes lenne megpróbálni felállítani valami standard-et, ami alapján meg lehet mondani, hogy mikor van kész a kód, mondjuk olyan értelmezésben, hogy hiba mentes, dokumentálva van minden feature, megfelel a fő irányelveknek pl a SOLID, és kellően gyors. Rövid kódoknál lehetséges ilyet csinálni, szóval talán hosszúaknál sem zárja ki semmilyen fizikai törvény.
80

Fejlődés

vbence · 2015. Nov. 5. (Cs), 09.59
Az eszközök folzamatosan fejlődnek, a disztribúciók kidobják a régi függőségeket, hatékonyabb API-k jelennek meg a forrás-nyelvben.

Amíg valahol fut a program addig ki van téve ezeknek a hatásoknak.

Egyik kedvenc megfogalmazásom az evolúcióra: "adapt or die". Amíg a programunkat életben tarjuk addig folyamatos munkát igényel. Abban a pillanatban, hogy letesszük, a konkurencia ki fogja szorítani a létezésből.
81

Egyetértek, és azt hiszem ez

inf3rno · 2015. Nov. 5. (Cs), 10.07
Egyetértek, és azt hiszem ez választ ad a fentiekre is, hosszú kódoknál egy csomó külső függőség van, és a szoftver nem lehet tökéletes, ha ezek a külső függőségei bugosak.
82

Tanulság? Egyszerű szoftvert

Hidvégi Gábor · 2015. Nov. 5. (Cs), 13.31
Tanulság? Egyszerű szoftvert kell írni, a külső függőségektől pedig meg kell szabadulni, mert rugalmatlanná teszik a programot.
83

A külső függőségeket el lehet

inf3rno · 2015. Nov. 5. (Cs), 13.59
A külső függőségeket el lehet fedni adapterrel, akkor nem lesz rugalmatlan, viszont ennek is vannak határai. Ha 20 lib-et használsz egy kis program összerakásához, akkor nem biztos, hogy azzal kell kezdeni, hogy mindegyikhez adaptert írsz...

Nem minden esetben lehet vagy tudsz egyszerű szoftvert írni. Valamikor annyi feature van benne, hogy alapból bonyolult, valamikor meg még nem látod át annyira a problémát és a lehetséges megoldásokat, hogy a legegyszerűbbet válaszd.
84

Időről időre át szoktam

Hidvégi Gábor · 2015. Nov. 5. (Cs), 17.05
Időről időre át szoktam vizsgálni a kódot, és szépen kidobálom belőle a felesleges részeket. A fő munkám például most kevesebb, mint fele akkora, mint amikor átvettem.
85

Tudnál konkrét példát

inf3rno · 2015. Nov. 5. (Cs), 17.27
Tudnál konkrét példát mutatni? Ez érdekesen hangzik. :-)
86

Ezt el tudnád adni olyannak,

BlaZe · 2015. Nov. 6. (P), 01.42
Ezt el tudnád adni olyannak, aki a költségeket viseli? :)
87

Ezt csinálom nyolc éve,

Hidvégi Gábor · 2015. Nov. 6. (P), 11.05
Ezt csinálom nyolc éve, egy-két apróság kivételével saját fejlesztés az egész.
88

Leszámítva olyan apróságokat

Joó Ádám · 2015. Nov. 7. (Szo), 01.59
Leszámítva olyan apróságokat mint a kernel, init-, SSH-, NTP-, syslog- és cron-démonok, web-, levelező- és adatbázisszerver, illetve a programozási nyelv fordítója és futtatókörnyezete, beleértve a sok száz programkönyvtárat, amit ezek használnak :)
89

Érdekes módon ezek az általad

Hidvégi Gábor · 2015. Nov. 7. (Szo), 03.15
Érdekes módon ezek az általad felsorolt, egyébként C-ben írt programok rendkívül stabilan működnek évek óta. A gond csak és kizárólag a külső JS és PHP kódokkal volt, amit szépen egyesével lecseréltünk sajátra, azóta minden úgy megy, ahogy kell, villámgyorsz, szóval holiday.
90

Ezt csak azért látod így,

Joó Ádám · 2015. Nov. 7. (Szo), 04.50
Ezt csak azért látod így, mert nem üzemeltetsz szervert: általában hetente több alkalommal érkeznek hibajavítások ezekhez a stabilnak mondott programokhoz :)
91

Többnyire

BlaZe · 2015. Nov. 7. (Szo), 10.06
Többnyire :)

Meglévő és működő külső függőség sajátra cserélése kifejezetten nem jó döntés. Míg egy aktívan fejlesztett külső libben a hibajavítások gyorsan megtörténnek, számodra többnyire csak egy verzió upgrade+teszt. Valamint jó eséllyel nem te leszel az első aki belefut a hibába, így vagy nem is tapasztalod meg, vagy ha igen, jó eséllyel javítva van már. Saját fejlesztésnél minden hibát te találsz meg először, neked kell analizálni, javítani, tesztelni, integrálni, semmi külső segítséged stb. A kettő költsége nem összehasonlítható, ráadásul se a saját lib fejlesztgetése, se a bugfix nem teremt business valuet a megbízónak. Persze lehetnek speciális esetek, amikor neki kell állni valamit lecserélni sajátra, de azt nagyon jól alá kell tudni támasztani, és egyáltalán nem jó általánosan ebbe az irányba menni.
92

Ezzel nem értek egyet, amit

Hidvégi Gábor · 2015. Nov. 8. (V), 11.46
Ezzel nem értek egyet, amit lecseréltünk, ott pont az ellenkezőjét tapasztaltuk annak, amit írsz.

Erre a legjobb példa a kliens, amit anno az Ext.js 1.0-val kezdtünk. Ez egyrészt piszok lassú volt, másrészt rendkívül összetett, emiatt tele volt bugokkal, mert túl sok minden épült egymásra.

Miután átírtam, húsz-harmincszoros gyorsulást tapasztaltunk, ami már a nagyon feltűnő kategória. Emellett a kód jóval kisebb lett, mert csak és kizárólag azt csinálja, amire nekünk szükségünk van, míg a külső libek sok általános feladatot tudnak elvégezni. Így a kódbázis az 500kb Ext.js plusz 200kb saját fejlesztésről lecsökkent 100kb (!) saját kódra.
93

Igen, ez pont egy olyan

BlaZe · 2015. Nov. 9. (H), 23.27
Igen, ez pont egy olyan non-functional requirement (legyen gyorsabb, legyen kisebb a kód), amit írtam is, hogy létezik. De ez egy kiragadott példa, semmiképp nem érdemes ez alapján általánosítani. És ennek a váltásnak az implementálása egy olyan plusz költség volt a megrendelőtöknek, ami nem teremtett neki business valuet, viszont pénzébe került. Mivel írod, hogy 8 éve csinálod, gondolom nem is kis pénzébe :)

Hogy nézzünk egy másik, komplexebb példát, mi kb ilyen külső függőségekkel dolgozunk: DI és high-level application frameworkök, messaging libek (JMS és low-level messaging), ORM, distributed cache implementációk, HA libek, különböző domain standard és belső céges apik különböző rendszerekhez való kapcsolódáshoz, alkalmazások indításához, leállításához, telepítéséhez, template engine config generáláshoz, test és mocking frameworkök, runtime performance méréshez api stb. Szerinted mi történne a projectünkkel, ha ezeket mind nekünk kéne megírni? :) És milyen mennyiségű specialistát kéne a projecten alkalmazni, hogy ez hatékony legyen? Nyilván látszik, hogy ez így nem működne a valóságban. Ha meg még bugot is kéne vadászni benne, akkor meg pláne.

Utóbbi példa kicsit közelebb áll egy átlagos valós alkalmazás függőségeihez. Emiatt mondom, hogy nem éri meg (általában) saját frameworköt fejleszteni.

Meg az is látszik, hogy az írjunk egyszerű alkalmazásokat jól hangzik, de a való életben sokszor elég komplexek az igények már technológia oldalon is (HA, elosztott állapotok pl). És akkor erre jön még rá a business...
94

És ennek a váltásnak az

Hidvégi Gábor · 2015. Nov. 10. (K), 12.19
És ennek a váltásnak az implementálása egy olyan plusz költség volt a megrendelőtöknek, ami nem teremtett neki business valuet, viszont pénzébe került.
Egyértelműen teremtett, hisz fele akkora kódot fele annyi idő debugolni. Ráadásul az API-k is egyszerűsödtek, a dokumentáció is egyszerűsödött.

Utóbbi példa kicsit közelebb áll egy átlagos valós alkalmazás függőségeihez.
Ezt a következtetést miből vontad le? Egy átlagos magyar cég alkalmazottja vagy? Mekkora cég az, hány dolgozóval? Az itthoni cégek nagyjából fele még rendes informatikával sem rendelkezik, Word-öt használnak meg Excelt és Gmailt, és mindig következő évben derül ki, hogy előző évben nyereségesek vagy veszteségesek voltak.
96

És ennek a váltásnak az

BlaZe · 2015. Nov. 11. (Sze), 01.33
És ennek a váltásnak az implementálása egy olyan plusz költség volt a megrendelőtöknek, ami nem teremtett neki business valuet, viszont pénzébe került.
Hm, visszaolvasva nem igazán ezt akartam írni :) Amire ki akartam lyukadni, hogy addig se business funkciókat fejlesztettetek, amire igazából a megrendelő a pénzét akarja áldozni, hanem hogy használhatóvá tegyétek az alkalmazást, ha jól értem. De ezt igazából nem a példádra akartam kihegyezni, csak hogy a megrendelő szemszögéből a saját bármi farigcsálása, ami nem pl egy gomb felrakása amit ő kért, kb így néz ki. Legtöbbször amúgy nem azért készülnek céges belső frameworkök, mert igény van rá, hanem mert a programozó valami izgalmasra is vágyik. Aztán az eredmény tipikusan meg sem közelíti az off the shelf megoldásokét, plusz szenved a korábban említett karbantartási problémáktól.

Ezt a következtetést miből vontad le? Egy átlagos magyar cég alkalmazottja vagy? Mekkora cég az, hány dolgozóval?
Már nem, de voltam. Kis cégnél, nagyobb cégnél, kis projecten, nagy projecten. Számtalan írást lehet olvasni hogyan tudja kinyírni az IT projecteket a meleg víz újrafeltalálása, és közelről is láttam ilyen miatt elúszni projectet. Nem azt mondtam amúgy, hogy tipikusan így néz ki egy application stack mint nálunk, hanem hogy jellemzően olyan igényeket kell kiszolgálni, amit praktikusan csak külső függőségekkel lehet/érdemes.

Az itthoni cégek nagyjából fele még rendes informatikával sem rendelkezik, Word-öt használnak meg Excelt és Gmailt, és mindig következő évben derül ki, hogy előző évben nyereségesek vagy veszteségesek voltak.
Hát, tipikusan nem ezek a cégek generálják az IT megrendeléseket :)
97

Hm, visszaolvasva nem igazán

Hidvégi Gábor · 2015. Nov. 11. (Sze), 10.02
Hm, visszaolvasva nem igazán ezt akartam írni :) Amire ki akartam lyukadni, hogy addig se business funkciókat fejlesztettetek
Értettem én, hogy mire gondoltál, és arra írtam a választ. Persze, nyilvánvalóan izgalmas volt hatékonyságra kihegyezni a programot, de a fejlesztés nem öncélú volt, hanem az általunk használt keretrendszer nem felelt meg a követelményeknek. Amikor például egy számla gyűjtőoldalt szerettünk volna megjeleníteni többszáz elemmel, csak a HTML renderelése bő 600ms volt – képzelheted, hogy milyen lehetett ezen a hibakeresés, -javítás. Ezt vittem le 30 ms környékére.

»Az itthoni cégek nagyjából fele még rendes informatikával sem rendelkezik (...)«
Hát, tipikusan nem ezek a cégek generálják az IT megrendeléseket :)
Ez nagy baj, ugyanis óriási veszteségek érik őket emiatt, hisz így képtelenség előre tervezni.
98

Már nem, de voltam. Kis

inf3rno · 2015. Nov. 11. (Sze), 22.03
Már nem, de voltam. Kis cégnél, nagyobb cégnél, kis projecten, nagy projecten. Számtalan írást lehet olvasni hogyan tudja kinyírni az IT projecteket a meleg víz újrafeltalálása, és közelről is láttam ilyen miatt elúszni projectet.


+1, szerintem ezek tipikusan hobbi projekteknek jók, ha van létező keretrendszer, és tűrhető a minősége, akkor jobb azt használni, különben sosem végzel a tényleges projekttel, a megrendelő meg nem azért fizet, hogy kiéld a hobbidat. Keretrendszert írni baromi időigényes, és általában csak sokadik átgondolásra sikerül olyanra, mint amilyenre szeretnéd.
99

És akkor itt jutunk el a

Hidvégi Gábor · 2015. Nov. 12. (Cs), 10.10
És akkor itt jutunk el a 48-as hozzászólásig, miszerint azért lesz (a weben) középszerű vagy gyenge programozó a nagy többség, mert kis megerőltetés helyett általános keretrendszert használnak.
100

Vagy mert esetleg nincs

BlaZe · 2015. Nov. 12. (Cs), 10.37
Vagy mert esetleg nincs előképzettségük, nem is képzik magukat és emiatt nem tudnak előrébb lépni a karrierjükben egy komplexebb project felé. Plusz a webes rendszerek többsége ugyanarra a kaptafára megy. A tudás nincs ingyen, és ez sajnos egy olyan szakma, hogy csak a napi feladatokkal nem jő el a kánaán :)

Tovább megyek, a keretrendszerek pont abban (is) segítenek, hogy ne a rutin feladatokkal kelljen állandóan foglalkozni, vagyis összességében pont az ellenkezője igaz.
101

eheh... már megint ez az általánosítás, ráadásul így... eheh

pp · 2015. Nov. 13. (P), 00.36
Ha ránézel egy normális eloszlásra, akkor láthatod, hogy a nagytöbbség mindig középre és valamelyik oldalra esik. Ez a normális eloszlás sajátja.

A mondatod ugyan úgy igaz lenne, ha azt mondanád, hogy ezért van az, hogy azért lesz (a weben) középszerű vagy erős programozó a nagy többség, mert... és ide tetszőleges érvet tehetsz, mert az eleje nem azért lesz igaz, ami az érv, hanem mert ez a normális eloszlás sajátja. És ezért van olyan kevés nagyon értelmes ember is, mert ez is a normális eloszlás sajátja... de ezt csak kevesen értik ugye... :D

Szóval az érvelésed mintája így néz ki:

[mindig igaz állítás, független a felvázolt indoktól], mert [és tetszőleges érv, mert ugye az előző, úgy általában igaz.]

pp
105

Feltételezem, hogy a Gauss

Hidvégi Gábor · 2015. Nov. 13. (P), 15.34
Feltételezem, hogy a Gauss görbére célzol, az alapján viszont nagyjából ugyanannyi gyenge programozónak kell lennie, mint erősnek.

Viszont ha megnézek mondjuk száz weboldalt (frontend oldalon, mert, ugye, az látszik ki), akkor elég hamar az derül ki, hogy többségükben olyanok készítik azokat, akiknek fogalmuk sincs a szakmáról. Például ott is JS-t használnak, ahol nem kéne, az oldal lassú (a sok scripttől), nincsenek tisztában az alapokkal (változódeklarációk, gyorstárazás helyett n-szer lefuttatják elemek keresésére a $('.elem') függvényt), a stílusdeklarációk túl bonyolultak stb.

Megfigyelésem szerint nagyjából ilyen az eloszlás:

109

Egy pillanatig sem vitatnám,

pp · 2015. Nov. 13. (P), 20.56
Egy pillanatig sem vitatnám, hogy súlyos előítéletekkel rendelkezel. (azt meg álmomban sem gondoltam, hogy azt le is rajzolod.)

Én azt vitatom, hogy az általd leírt két dolog összefüggene.

Ezt nem cáfoltad, és magyarázatot se adtál arra, hogy miért gondolod azt, amit gondolsz.

Te akkor jó programozó vagy, mert nem használsz keretrendszert?
Te attól vagy jó programozó, hogy nem használsz keretrendszert?

Azt tudod, hogy a PHP is egy keretrendszer? Tehát akkor a logikádat követve, ettől Te nem lehetnél jó programozó, sőt a középmezőnybe kéne tartoznod.

pp
110

Szerintem több ponton is

inf3rno · 2015. Nov. 13. (P), 21.56
Szerintem több ponton is sántít a rajzod. Miből gondolod, hogy a gagyi weboldalak száma és a rossz programozók száma közötti összefüggést az egyenes arányosság írja le? Miből gondolod, hogy a felmérésed reprezentatív volt? Miből gondolod, hogy az értékelési szempontjaid objektívek?
95

És ennek a váltásnak az

Joó Ádám · 2015. Nov. 10. (K), 15.23
És ennek a váltásnak az implementálása egy olyan plusz költség volt a megrendelőtöknek, ami nem teremtett neki business valuet, viszont pénzébe került.


Speed is a feature!
102

Most akkor újra lehet írni dolgokat, vagy sem?

Endyl · 2015. Nov. 13. (P), 11.28
Természetesen jó dolog amit írsz, újra kéne tervezni és írni az absztrakciókat, de ki fogja ezt megfizetni? Egy kis szoftvernél még belefér, de ha cseppet is összetettebb, meg fogod csinálni?

vö.
Tanulság? Egyszerű szoftvert kell írni, a külső függőségektől pedig meg kell szabadulni, mert rugalmatlanná teszik a programot.

plusz
Időről időre át szoktam vizsgálni a kódot, és szépen kidobálom belőle a felesleges részeket.
103

Neki újra lehet, de nekünk

inf3rno · 2015. Nov. 13. (P), 13.43
Neki újra lehet, de nekünk tilos. Nem világos? Handicappel indulunk...
104

Nem értem a kérdésed és nem

Hidvégi Gábor · 2015. Nov. 13. (P), 15.17
Nem értem a kérdésed és nem látom az ellentmondást. Az első kérdésem hozzád (és a többi fejlesztőhöz) szólt, míg a két kijelentésem pedig az én gyakorlatomról.
106

A hozzám intézett kérdésedben

Endyl · 2015. Nov. 13. (P), 15.50
A hozzám intézett kérdésedben kételkedsz abban, hogy absztrakciókat újra lehetne írni (hogy volna rá idő/pénz), ugyanakkor a másik szálban arra buzdítasz mindenkit, hogy írja újra a külső függőségeket házon belül (amik bizonyos problémák absztrakt és/vagy egzakt megoldásai), mert az sokkal jobb és bőven megéri. Most akkor tényleg megéri dolgok újraírására időt/pénzt fordítani, vagy sem?

Azt állítod, hogy te nyolc éve ezt csinálod (az nem derült ki, hogy ez a teljes projekt ideje, vagy az újraírással (is) töltött időtartam). Szóval akkor a te projekted ezt megengedi (láthatólag nem is csak apró dolgok átdolgozásával (minden külső js és php függőség átírása?)), abban viszont kételkedsz, hogy máshol ez lehetséges? Vagy úgy gondolod, hogy egyből meg lehet találni egy folyamatosan változó világban egy potenciálisan változó kritériumú problémára az optimális megoldást? Vagy ez csak a te gyakorlatoddal lehetséges?

Szerintem ideje lenne a fejlesztési módszertanodról minimum egy könyvet írnod, mert az elmondásaid alapján (nekem eddig legalábbis ez a benyomásom), azt követve tetszőleges problémára belátható időn belül, külső, instabil függőségektől mentes, a lehető legrugalmasabb, teljesen moduláris megoldást lehet írni úgy, hogy az elkészülte után már csak alig-alig kell hozzányúlni. Egy ilyen megoldás biztos kasszasiker lenne.
107

Én sehol sem kételkedtem,

Hidvégi Gábor · 2015. Nov. 13. (P), 16.41
Én sehol sem kételkedtem, hanem feltettem a kérdést, hogy például számodra (vagy bárki más számára) belefér-e?

Minden (nem egyértelmű) absztrakció szivárog, és ez nagyon jól látszik a külső függőségek példáján is. Az általunk készített program egy tipikus kliens-szerver alkalmazás, aminek a kliensét én készítettem.

Az ext.js 1.0-val kezdtem el dolgozni az elején, mert pont arra találták ki, amire szükségünk volt. Viszont ahogy kezdtek bonyolódni a dolgok, egyre több elemből álló űrlapokat kellett készíteni, a megjelenítés sebessége exponenciálisan csökkent, továbbá bizonyos elemek kódja annyira összetett volt, hogy rendkívül sok idő volt az egyre gyakrabban előjövő keretrendszer-hibák javítása.

Így megérte rászánni az időt a saját kliens elkészítésére, ami jóval kisebb (hetede az eredetinek, amibe beleszámolom az ext.js-t is), és látványosan gyorsabb. Az mellékszál, hogy egy szerelmi bánatomban, szabadidőmben írtam újra, hogy felejtsek, később, miután átvettem a backend-et, már tudatosan, alátámasztva kértem a főnökömtől a php kódok racionalizálásának a lehetőségét.

Ez is bőven kifizetődött, mert a kód, mint korábban jeleztem, méretben fele-harmada lett az eredetinek, egy űrlap elkészítése jóval kevesebb munkával jár, és persze jóval egyszerűbb a hibakeresés.

Minden külső függőség egy bizonytalansági tényező, egy absztrakció, amikor feltételezed, hogy az mindig elérhető lesz, és ugyanúgy fog működni.

Az ext.js API-ját például szinte mindegyik verzióváltáskor átírták, néha drasztikusan. Egy nyílt forráskódú projektet bármikor otthagyhatnak a fejlesztői, nagyjából fordítottan arányosan a méretével/elterjedtségével.

Házon belül a hibákat sokkal könnyebben és gyorsabban javítjuk, mint ha ugyanezt be kéne küldeni a githubra, ott elbírálják, letesztelik, aztán egyszercsak élesítik.

A harmadik féltől való függés kiszolgáltatottá tesz, annál inkább, minél több van belőle. Erre példának a gázfűtést szoktam felhozni: régen, amikor vastag csövekben áramlott a melegvíz, a fizika törvényei mozgatták a közeget. Ma, a vékony csövek mellé a kazánba keringetőszivattyút kell tenni, ami azt jelenti, hogy ha nincs áram, meleg sem lesz. Idén már kétszer kellett emiatt moziba mennem.

Vagy úgy gondolod, hogy egyből meg lehet találni egy folyamatosan változó világban egy potenciálisan változó kritériumú problémára az optimális megoldást? Vagy ez csak a te gyakorlatoddal lehetséges?
Nem lehet megtalálni elsőre, ezt magam is látom, nekünk sem sikerült. De ha valaki az egyszerűségre törekszik, minél kevesebb absztrakcióval dolgozik, annál könnyebb és olcsóbb lesz a munka.
108

"De ha valaki az

pp · 2015. Nov. 13. (P), 19.52
"De ha valaki az egyszerűségre törekszik, minél kevesebb absztrakcióval dolgozik, annál könnyebb és olcsóbb lesz a munka."

Hogyan lesz absztrakció nélkül egyszerű a kódod? Nincs benne egy függvény se? Vagy csak egy pár több oldalas spagetti kód?

btw ciklust se használsz?

Mert az is egy absztrakció. (gondolom ha már ilyen régóta vagy a szakmában, te is kódoltál olyan processzorra, amiben nem volt ciklus, így tudod, hogy az is csak egy absztrakció, egy komplex valaminek a magasabb nyelvi megvalósítása. Függvény sincs csak subrutin, mert a függvény is egy absztrakció, egy bizonyos subrutin megvalósítása magasabb nyelvi elemekkel)

pp
112

Úgy tűnik, valamit

Hidvégi Gábor · 2015. Nov. 14. (Szo), 01.15
Úgy tűnik, valamit félreértettél. Még idézed is:
minél kevesebb absztrakcióval dolgozik
Aztán pedig ezt írod:
Hogyan lesz absztrakció nélkül egyszerű a kódod?
A "minél kevesebb" mióta egyenlő a "nélkül"-lel? Miért ne tudnám, hogy a függvény és a ciklus is egy absztrakció (Blaze-zel valamelyik vitámban még azt is leírtam már korábban, hogy a függvényhívás miért drága, de ezt már nem fogom megkeresni: nem csak egy szimpla goto, hanem memóriát kell foglalni a függvény belső változóinak, aztán a végén fel is kell szabadítani; ezért is tartom hülyeségnek JS-ben a funkcionális programozást).

A számomra fölösleges absztrakciók például az objektumok, de ezt már számtalanszor kifejtettem.
113

(Blaze-zel valamelyik

BlaZe · 2015. Nov. 14. (Szo), 04.26
(Blaze-zel valamelyik vitámban még azt is leírtam már korábban, hogy a függvényhívás miért drága, de ezt már nem fogom megkeresni: nem csak egy szimpla goto, hanem memóriát kell foglalni a függvény belső változóinak, aztán a végén fel is kell szabadítani;
Hm, az nem úgy van véletlenül, hogy a belső változók a stacken jönnek létre és emiatt az allokálásuk és a felszabadításuk elég olcsó művelet? ;) Meg van olyan is, hogy a heapen allokáláshoz se kell mallocot, vagy hasonlót hívni. Pl a JVM elég olcsón foglalja a memóriát (kb növel egy pointert). Vagy az argumentumokra gondolsz? Mióta 64 bites CPU-ink vannak "temérdek" registerrel, az első hat paraméter regiszterben kerül átadásra (linux alatt natív programok esetében, de pl JVM is hasonlót generál). Annál több paramétert úgyse nagyon adunk át, nem igaz? :) Természetesen van költsége a függvényhívásnak, de nem ez, és szerencsére nem ekkora. Az indirect jump (virtual call) lehet drága, mert ott tippelnie kell a CPU-nak hol fog folytatódni a program (unconditional branch). Ha nem találja el, akkor pipeline flush van, aminek költsége ugye függ a pipeline méretétől. Ez a Sandy Bridge esetében 16 CPU cycle. De ezekkel amúgy se kell foglalkozz, mert erre ott van a fordító, ami olyan kódot fog legyártani a programodból, amire rá sem ismernél. De még a ciklusaid is teljesen máshogy fognak kinézni. Legyen az akár AOT, akár JIT. Amit jó észben tartani viszont, hogy a hosszú függvényekkel jól alá tudsz rúgni az optimalizációnak. JIT esetében mindenképp.

Hogy JS ezt hogy csinálja pontosan, azt nem tudom. De nagyobb összeget mernék rá tenni, hogy nem foglalgatnak memóriát a belső változóknak...
116

Majd ha lesz időm, lemérem,

Hidvégi Gábor · 2015. Nov. 14. (Szo), 11.50
Majd ha lesz időm, lemérem, hogy C-ben mekkora a különbség, a linkelt hozzászólásomban az adott feladatban, Javascriptben tízszeres volt. Mindenesetre nem véletlen szoktak a fordítók pl. ciklusokat inline optimalizálni.

Az általad felsorolt részletekkel nem foglalkozom, hisz webes programozó vagyok, JS-sel és PHP-val birkózom, amelyekben erre nincs is lehetőség. Ha bármit leírok, azt ennek fényében kell feldolgozni.
122

~ 2 ns

BlaZe · 2015. Nov. 15. (V), 04.09
Majd ha lesz időm, lemérem, hogy C-ben mekkora a különbség
Akkor megspórolok neked egy kis időt: durván 2 ns a függvényhívás maga (nálam, i7 mobile), amit súlyosbíthat, ha visszatéréskor már valahonnan a cacheből kell visszatöltse a visszatérési címet és az %rbp-t a függvényből kilépéskor, mert flusholni kellett a store buffert. Ha megfelelő mennyiségű memória írást végez a hívott függvény, akkor ez előfordulhat (meg több más esetben is), de ezesetben természeteseten az inline-olt verzió is blockolódni fog a store buffer flushon. Úgyhogy ez a probléma valójában önmagában nem igazán kimérhető.

Amit biztosra lehet mondani, hogy legalább 2 ns-t veszítesz egy függvényhíváson. Hogy ez 1 ms latencyként jelentkezzen, kb félmillió függvényhívást kell ledarálni. Az azért nem kevés, és ott valószínűleg lesz más, ami mellett ez az érték eltörpül...

Kb ennyi értelme is van ilyen mikrooptimalizálásokkal foglalkozni egy átlagos kódban (ahol tisztán assemblyre fordul a kódunk). Ami viszont biztos, hogy az olvashatóságot, karbantarthatóságot jelentősen rontja, az optimalizáció szintjével (architekturális->mikrooptimalizáció) a ráfordítandó idő exponenciálisan nő, a nyereség ugyanígy csökken.

Mindenesetre nem véletlen szoktak a fordítók pl. ciklusokat inline optimalizálni.
Valóban nem véletlenül, de mit akarsz ezzel mondani? Ezzel pont azt támasztod alá, amit mondtam: felesleges erőlködni, a fordító úgyis jobban tudja nálad. Pláne, ha JIT.

Az általad felsorolt részletekkel nem foglalkozom, hisz webes programozó vagyok, JS-sel és PHP-val birkózom, amelyekben erre nincs is lehetőség. Ha bármit leírok, azt ennek fényében kell feldolgozni.
A goto, illetve a gyakran hozott c példáid azért nem erre utaltak :) Amúgy az absztrakciókra, OOP-ra vonatkozó minden elméletedet is így kell érteni (JS és PHP)?
123

Ez az egész függvényesdi csak

Hidvégi Gábor · 2015. Nov. 15. (V), 11.55
Ez az egész függvényesdi csak arra szolgál bizonyítékként, hogy minden absztrakció szivárog, és minél több van, annál inkább.

Lehet, hogy a te i7-eseden 2ns-be kerül egy függvényhívás, ha Javában vagy C-ben dolgozol, de egy magasabb szintű nyelvben, mint a PHP vagy a JS, már jóval többe kerül, mint a mellékelt ábra is mutatja.

Tehát ezek miatt egyértelműen célszerű csökkenteni az absztrakciók számát, bármelyik programozási nyelvről van szó.
124

A fenti commentem arra volt

BlaZe · 2015. Nov. 15. (V), 13.50
A fenti commentem arra volt válasz, amit írtál, hogy mekkora az overhead C-ben. Gondoltam érdekel.

PHP-hoz itt van egy kis mérés. Bár ez sokminden mást is csinál, ami befolyásolhatja a mérést, de kiindulási alapnak jó. Ezer hívásnál 6-700us volt a költsége az összes hívásnak, egy mezítlábas PHP-n. Ezek után érdemes feltenni a kérdést, hogy mennyibe fáj pl az összes DB művelet, a network latency (20-50ms pingek simán előfordulnak). Mondjuk azt hogy mindenestül a requesttől számítva 50ms múlva ott a response a usernél. Ez azért nem olyan rossz :) Erre 1%-ot optimalizáltál, amiből a user semmit nem fog észrevenni. Ha kicsit erőforrásigényesebb a válasz előállítása, akkor még ennyi sincs a nyereség. Mindezt úgy érted el, hogy a kódod jelentős olvashatósági, karbantarthatósági és tesztelhetőségi visszafejlődésen ment keresztül.

A másik gondolat, hogy optimalizációt csak mérések alapján, lépésről lépésre végzünk. Ha a mérések nem állnak rendelkezésre, az eredmény megjósolhatatlan sebességváltozás (nem egyértelműen növekedés) lesz, megjósolhatatlan költségen. Lehet volt ilyened, ezt te tudod. Annyi még, hogy a roundtrip latency mérsékelten használható input az optimalizációhoz.

Én is írtam már neked, meg most inf3rno is, hogy súlyosan félreérted Joel írását. Egy szóval nem mondja, hogy kerülni kell az absztrakciókat. Azt mondja, hogy érteni kell, és úgy használni.
125

A fenti commentem arra volt

Hidvégi Gábor · 2015. Nov. 15. (V), 14.13
A fenti commentem arra volt válasz, amit írtál, hogy mekkora az overhead C-ben. Gondoltam érdekel
Tudom, és köszönöm.

Ha kicsit erőforrásigényesebb a válasz előállítása, akkor még ennyi sincs a nyereség.
Ez is nyilvánvaló. Az egész függvényesdivel – ismétlem – az volt a célom, hogy az absztrakciók szivárgását bizonyítsam. JS-ben és PHP-ben, ebben a két magasszintű nyelvben emiatt nem látom értelmét a túlzott használatuknak, lásd akarmi.forEach(function() { formának.

A másik gondolat, hogy optimalizációt csak mérések alapján, lépésről lépésre végzünk.
Ez is nyilvánvaló, de erről itt szó sem volt. És itt van Occam borotvája, ami alapján jobb a for ciklus, mint a .forEach.

súlyosan félreérted Joel írását. Egy szóval nem mondja, hogy kerülni kell az absztrakciókat
Nincs itt semmiféle félreértés. Nem ő mondja, hanem én, mert ez következik belőle.
130

Ez is nyilvánvaló. Az egész

inf3rno · 2015. Nov. 15. (V), 15.06
Ez is nyilvánvaló. Az egész függvényesdivel – ismétlem – az volt a célom, hogy az absztrakciók szivárgását bizonyítsam.


Ha valóban az volt a célod, hogy a függvény hívások többlet idejével bizonyítsad, hogy mennyire károsak a szivárgó absztrakciók, akkor csúnyán felsültél. Én inkább valami olyasmivel hozakodtam volna elő, ha már a funkcionális programozást szapuljuk, hogy mindig oda kell tenni a callback végére a .bind(this)-t, ami ha lemarad, akkor komoly zűr van, és nálam elég gyakran lemarad. Szóval emiatt error prone a dolog.

Azzal mi is egyetértünk, hogy az absztrakciók szivárognak.

Egy szóval nem mondja, hogy kerülni kell az absztrakciókat
Nincs itt semmiféle félreértés. Nem ő mondja, hanem én, mert ez következik belőle.


Én is erre jutottam, viszont a többség álláspontja nem ez. A többség azt mondja, hogy lehet használni az absztrakciókat, csak ésszel kell tenni, és fel kell mérni ennek a lehetséges hatásait. Nem szeretem az ilyen távoli analógiákat, de pl ha van egy darab vas, amit át akarsz vágni, akkor választhatsz vasfűrészt és kínlódhatsz vele egy órát, vagy választhatsz flex-et eszköznek, amivel egy perc alatt megvan az egész, de ha ész nélkül használod nem betartva a munkavédelmi előírásokat, akkor komolyan megsérülhetsz tőle. Ugyanígy az absztrakciók és keretrendszerek is eszközök, amik plusz veszélyforrást jelentenek, ha nem tudod, hogy mit csinálsz. A megoldás nem az, hogy kerülni kell őket, hanem az, hogy meg kell tanulni használni őket, és felismerni, hogy mikor van rájuk szükség, és mikor ártanak többet, mint használnak.
132

Az egész függvényesdivel –

BlaZe · 2015. Nov. 15. (V), 16.08
Az egész függvényesdivel – ismétlem – az volt a célom, hogy az absztrakciók szivárgását bizonyítsam.
Akkor rossz volt a példád a sebességgel. Az nem azt bizonyítja, hogy az absztrakciók szivárognak, hanem hogy minden műveletnek költsége van. A függvényhívásnak akkora, hogy gyakorlatilag extrém eseteket leszámítva nincs értelme vele foglalkozni.

Azt senki nem vitatja, hogy az absztrakciók mögött részletesebb implementáció van, amit adott esetben ismerni és érteni kell (én azt se mondanám feltétlenül, hogy mindig). De ettől még nem kell kerülni. Pláne, hogy ha helyes absztrakciókat használsz, akkor a programod valójában semmit nem fog tudni a külső függőségéről, csak ott lesz, és használja. Mi kb egy éve így cseréltünk distributed cachet az alkalmazásainkban. Csak a konfigurációt kellett módosítani, és a megfelelő absztrakció mögött megvalósítani a tényleges hívásokat. Absztrakciók nélkül ez őrületes nagy munka lett volna.

Hogy hozzak PHP példát is, egyszer egy működő xls exportálást kellett lecserélnem xlsx-re, hogy nagy adatmennyiségeket is támogasson. Eredetileg valami PEAR-es libet használtam, de az xlsx-be befulladt, és normális találat híján ott én is lecseréltem egy specifikus saját implementációra. Viszont az alkalmazáshoz egy betűt nem kellett hozzányúlni, csak kicseréltem az implementációt egy interface mögött. Itt is absztrakciók nélkül jóval nagyobb munka, a megrendelőnek pedig nagyobb költség lett volna. Tehát az állításod cáfolva ;)

Occam borotvája nem tudom hogy kerül ide, de a foreach egyértelműen szemléletesebb szerintem, mint a for ciklus, legalábbis legtöbb esetben.

Nincs itt semmiféle félreértés. Nem ő mondja, hanem én, mert ez következik belőle.
Szerintem meg a fenti példám elég egyértelműen bizonyítja, hogy nem érdemes ökölszabályként kerülni az absztrakciókat.
128

Gyártottam valami fapados

inf3rno · 2015. Nov. 15. (V), 14.44
Gyártottam valami fapados kódot js-ra, csak hogy nagyságrendileg képben legyünk ezzel kapcsolatban. Ha esetleg elvi hiba van benne, pl. optimalizálja a fordító, és ténylegesen nem történik függvény hívás vagy tulajdonsághoz való hozzáférés.

var cnt = 500000;

var ffactory = function (i){
	return function (){return i;};
};
var fmap = {};
var pmap = {};
for (var i=0; i<cnt; ++i) {
	fmap[i] = ffactory(i);
	pmap[i] = i;
}

var d1 = new Date();
for (var i=0; i<cnt; ++i)
	var x = fmap[i]();
var d2 = new Date();
for (var i=0; i<cnt; ++i)
	var x = pmap[i];
var d3 = new Date();

var ms = (d2-d1)-(d3-d2);
console.log(cnt + " function calls in " + ms + " msecs");

var ns = ms*1000*1000;
var nspfc = ns/cnt;
console.log(nspfc + " ns per function call");
Ezek alapján firefoxban 24ns, operaban 270ns, chrome-ban 220ns, msie-ben 150ns, node (4.2.1) 176ns egy függvény hívás. Ha a 200ns-t vesszük alapul, akkor 1ms kb 5000 hívásnak felel meg ennél a processzornál, ami itt 4000 pont körül van.

Egy másik gépen a processzor 1400 pont körül van, az arra vonatkozó adatok: firefox 66ns, opera ?, chrome 368ns, msie 330ns, node (0.12.6): 94ns. Érdekes, hogy a régi nodejs gyorsabb ebben a tesztben. Ha a 333ns-t vesszük alapul, akkor 1ms kb 3000 hívásnak felel meg ennél a processzornál.

A mobilomon (1GHz Cortex-A5 processzor, talán 3 éves lehet, baromi lassú) kipróbáltam firefox for androiddal, 362ns volt egy függvény hívás. Nem igazán lehet összehasonlítani, mert a benchmarkok már nem nézik az ennyire gyenge processzorokat, meg a firefox is más, mint egy normál gépen. Talán ha win10-et tennék rá, de az meg kizárt.

Ha azt nézzük, hogy egy CPU pontszámért hány js függvény hívást tud csinálni egy msec alatt, akkor az erősebb processzornál 1.25 call/point, a gyengébb processzornál meg 2.15 call/point. A processzor pontszámai és a js hívási sebessége tehát (nagy valószínűséggel) korrelálnak, de nincs egyenes arányosság köztük, a gyengébb processzor relatíve gyorsabb volt. Ennek hardveres és szoftveres okai is lehetnek, pl újabb processzor típus, újabb operációs rendszer, stb. Több eltérő processzoron végzett méréssel lehetne csak kideríteni.

Szvsz, egyáltalán nem ez lesz a szűk keresztmetszet, sokezer hívást kellene végrehajtani, hogy bármi látható lassulást tapasztaljunk. Sokkal inkább a DOM manipuláció, AJAX hívások, animációk, és így tovább, ami lassít. Semmi értelme a függvény hívások miatt csökkenteni az absztrakciók számát. Kevés eredményt lehet csak elérni rengeteg plusz munkával.
114

Úgy tűnik, valamit Te

pp · 2015. Nov. 14. (Szo), 05.22
Úgy tűnik, valamit Te értettél félre.

Valamivel úgy tudok kevesebbel tenni valamit, hogy a jelentős része nélkül teszem azt amit teszek.

Az állításodból következik, hogy akkor lesz a legegyszerűbb a programkód, ha nincs benne absztrakció.

"A számomra fölösleges absztrakciók például az objektumok, de ezt már számtalanszor kifejtettem."

Te akkor nem minden absztrakcióra, csak a felesleges absztrakciókra gondoltál? Úgy viszont a mondatod úgy szólna, hogy "akkor lesz valami egyszerű, ha a felesleges dolgokat elhagyjuk", aminek semmi köze az absztrakcióhoz, és nem mond semmi újat.

pp
115

Valamivel úgy tudok

Hidvégi Gábor · 2015. Nov. 14. (Szo), 11.47
Valamivel úgy tudok kevesebbel tenni valamit, hogy a jelentős része nélkül teszem azt amit teszek
Miért kéne drasztikusan csökkenteni bármit is? Annak sosem lesz jó vége, én ilyet nem tennék, és nem is tanácsolnék senkinek.

Az állításodból következik, hogy akkor lesz a legegyszerűbb a programkód, ha nincs benne absztrakció.
Ez biztos nincs így. Ismered a számítógépet, nem kell magyarázni, hogy teljesen máshogy működik, mint az emberi agy. Azzal kezdtem valamelyik absztrakciós megjegyzésemet, hogy minden nem triviális absztrakció szivárog. Ebből jön a kérdés, hogy mi a triviális? Szerintem az, amivel már tudjuk szimulálni a gondolkodásunkat, és ezt számomra kielégítik a függvények és az egyszerű adattípusok és a tetszőleges index-szel rendelkező tömbök. Ezekkel - véleményem szerint - minden feladat elvégezhető hatékonyan.

Mert hogyan gondolkodom? Leütöm az "A" billentyűt. Veszek fél kiló lisztet. Elmegyek a postára. Befizetem a csekket.

Függvény - paraméter.

Az objektumokban való gondolkodás túlbonyolítja a dolgokat, mert előbb-utóbb jön a moralizálás, hogy nekem van egy csengőmegnyomó metódusom, vagy a csengő nyomódik meg?

aminek semmi köze az absztrakcióhoz, és nem mond semmi újat
Miért kéne mindig újat mondani? Te mi újat mondtál eddig?
111

Nem tudom lejött e, de az

inf3rno · 2015. Nov. 13. (P), 22.03
Nem tudom lejött e, de az absztrakcióknak pont az a lényege, hogy elfedje az alacsony szintű dolgokat, amik miatt nem hogy nem egyszerű, hanem egyenesen átláthatatlan a kód. Ha megfelelő mennyiségű absztrakciót használsz, akkor első ránézésre látni, hogy mit csinál a kód. Ha kíváncsi vagy arra, hogy hogyan csinálja, akkor meg mélyebbre ásol. Ennyi a történet.
117

The law of leaky abstractions

inf3rno · 2015. Nov. 14. (Szo), 12.53
The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.
http://joelonsoftware.com/articles/LeakyAbstractions.html

Nekem az jött le, hogy mivel az ext1-nek számodra leaky volt az absztrakciója (mivel túl lassú volt), ezért írtál egy saját megoldást (gondolom kevesebb absztrakcióval), ami gyorsabb lett. Ezzel nincs semmi gond.

Azt viszont nem értem, hogy ez alapján az egy minta alapján hogyan lehet kategórikusan kijelenteni, hogy minden webes (PHP, js) keretrendszer rossz, és a legjobb, ha magad írod meg a kódot minden alkalommal, mert az a tuti, és úgy elkerülheted a magas absztrakciós szintű dolgokat nyilván nem kevés többlet kóddal, munkával. Az sem fér a fejembe, hogy az OOP használata szerinted miért túlzás, és mi az a szivárgó absztrakció, amiért számodra használhatatlan eszköznek minősül.

Joel Spolsky csak arról ír, hogy bizonyos mértékű szivárgás mindig velejárója az absztrakciók használatának. Nem arról, hogy emiatt teljes mértékben kerülni kellene őket, és minimalizálni a használatukat. Ezt a részét csak te tetted hozzá.
119

Azt viszont nem értem, hogy

Hidvégi Gábor · 2015. Nov. 14. (Szo), 14.21
Azt viszont nem értem, hogy ez alapján az egy minta alapján hogyan lehet kategórikusan kijelenteni
Már ezer példában vázoltam, hogy minden absztrakció szivárog. Az absztrakció információelvonás, azaz abból indulok ki, hogy valamilyen feltétel teljesül. Az ext.js-nél abból indultak ki, hogy mindenki Móricka-űrlapokat készít öt elemmel, és akkor használható lesz a rendszerük. Amint nem teljesül ez a feltétel, borul a bili, és nagy a baj.

Minél több az absztrakció, ha baj lesz, az annál nagyobb. Mint a 118-ban írom, nem önmagukkal a keretrendszerekkel van baj, hanem azzal, ha csak azokkal dolgozik az ember, és nem jár utána, mi van a háttérben, mi hogyan működik valójában.

Az OOP-ben az adatok és a függvények túl szorosan vannak csatolva, ha ez nem lenne gond, nem terjednének annyira a funkcionális módszerek. Erre a legjobb példa maga az internet, ahol minden website-ot felfoghatunk egy objektumnak, itt az adatok és a rajtuk munkát végző függvények (GET, POST kérések - ez még rendben, de az igazi bűnös a JS) egymáshoz vannak láncolva. Ezért van az, hogy weboldalakból adatot kinyerni leginkább csak böngészővel lehet, ami viszont luxus, hisz a böngésző mögé ember kell, viszont a weboldalak exponenciálisan növekvő száma miatt már csak gépileg lehet feldolgozni ezt a tömérdek információt. Arra viszont a web a jelenlegi formájában alkalmatlan.

Nem arról, hogy emiatt teljes mértékben kerülni kellene őket, és minimalizálni a használatukat. Ezt a részét csak te tetted hozzá.
Ilyet én sehol sem állítottam. Csak annyit, hogy egyszerűsíteni kell és csökkenteni az absztrakciók számát.
120

Már ezer példában vázoltam,

inf3rno · 2015. Nov. 14. (Szo), 19.50
Már ezer példában vázoltam, hogy minden absztrakció szivárog. Az absztrakció információelvonás, azaz abból indulok ki, hogy valamilyen feltétel teljesül. Az ext.js-nél abból indultak ki, hogy mindenki Móricka-űrlapokat készít öt elemmel, és akkor használható lesz a rendszerük. Amint nem teljesül ez a feltétel, borul a bili, és nagy a baj.


Ez csak arra bizonyíték, hogyha rosszul választod meg a használt keretrendszert, akkor az hosszú távon nem lesz működőképes, nem pedig arra, hogy nem érdemes keretrendszereket használni.

Minél több az absztrakció, ha baj lesz, az annál nagyobb. Mint a 118-ban írom, nem önmagukkal a keretrendszerekkel van baj, hanem azzal, ha csak azokkal dolgozik az ember, és nem jár utána, mi van a háttérben, mi hogyan működik valójában.


Senki nem mondta, hogy ezt meg kell spórolni.

Visszaolvastam kicsit. Én is úgy gondolom, hogy nem kellene mindent jquery-vel és hasonló keretrendszerekkel megoldani, ha van rá egyszerű és hasonló idő alatt lekódolható megoldás. A keretrendszerek és az absztrakciók általában ott segítenek a legtöbbet, hogy bonyolult kódoknál elfedik a részleteket, és így jóval kevesebb és könnyebben átlátható kód elég ugyanannak a feature-nek a lefejlesztéséhez. Máshogy fogalmazva nő a termelékenység a használatukkal. Ennek az ára, hogy nehezebb debuggolni, mert több tucat függvényhíváson, ill. absztrakciós rétegen keresztül kell nyomonkövetni, hogy hol keletkezett maga a hiba. Ezen lehet könnyíteni teszt vezérelt fejlesztéssel, aminél a hibák nagy része azonnal kiderül, és nem kell keresni a forrásukat, mert szinte kizárólag az éppen fejlesztett kódnál van.

Azzal is egyetértek, hogy maga a DOM egy hibás elképzelés. Sokkal szerencsésebb lett volna valamilyen adatstruktúrát használni ilyen hibrid objektum/adatstruktúra helyett, aminek se füle, se farka.

Erre a legjobb példa maga az internet, ahol minden website-ot felfoghatunk egy objektumnak, itt az adatok és a rajtuk munkát végző függvények (GET, POST kérések - ez még rendben, de az igazi bűnös a JS) egymáshoz vannak láncolva.
Ezért van az, hogy weboldalakból adatot kinyerni leginkább csak böngészővel lehet, ami viszont luxus, hisz a böngésző mögé ember kell, viszont a weboldalak exponenciálisan növekvő száma miatt már csak gépileg lehet feldolgozni ezt a tömérdek információt. Arra viszont a web a jelenlegi formájában alkalmatlan.

Adatot te is bármikor kinyerhetsz weblapokból, elég string-ként beolvasni a HTTP választ. Információt már egy fokkal nehezebb kinyerni, de a google azt is elég jól megoldja. Az információ kinyerése nem a js miatt nehézkes, hanem mert a HTML-t nem erre találták ki. Nevezhetjük leaky abstraction-nek a te szavajárásoddal. Hogy jön mindez az OOP-hez? A webes get(resource) megközelítés erősen procedurális, szóval leginkább sehogy.

Az OOP-ben az adatok és a függvények túl szorosan vannak csatolva, ha ez nem lenne gond, nem terjednének annyira a funkcionális módszerek.

Miből gondolod, hogy emiatt terjednek (ha egyáltalán terjednek) a funkcionális módszerek? Jó lenne valami bizonyítékot is látni erre.
121

Információt már egy fokkal

Max Logan · 2015. Nov. 14. (Szo), 21.32
Információt már egy fokkal nehezebb kinyerni, de a google azt is elég jól megoldja.
Maradjunk annyiban, hogy a Google elég szarul oldja meg. Az más kérdés, hogy statisztikai alapon valamennyire használható a találati lista, de a jótól a Google nagyon messze van, és ez leginkább a HTML alapú webnek köszönhető.
127

A szívemből szóltál.

Hidvégi Gábor · 2015. Nov. 15. (V), 14.27
A szívemből szóltál.
126

Ez csak arra bizonyíték,

Hidvégi Gábor · 2015. Nov. 15. (V), 14.27
Ez csak arra bizonyíték, hogyha rosszul választod meg a használt keretrendszert, akkor az hosszú távon nem lesz működőképes
Ha így van, ez épp elég indok a kerülésükre. Én legalábbis nem úgy dolgozom, hogy megcsinálok valamit, és aztán elfelejtkezek róla, a megrendelőim sem azért készíttetnek el velem egy oldalt, mert csak rövidtávon szeretnének pénzt keresni vele.

Vannak pro és kontra érvek, rengeteg. Ha megvan a tudásom, egy jQuery függvényt simán lecserélek egy kézzel írottra, ha úgy alakul, bármit is optimalizálni kell – egy átlag weboldalnál ezt meg is tehetem nyugodtan. De ha egy nagyobb munkáról van szó, és mondjuk nagyon ráépül egy keretrendszerre, már jóval nehezebb az egyes részek átírása, hisz az alapokban kell túrkálni. Vagy sikerül, vagy rámborul az egész.

Hogy jön mindez az OOP-hez?
Minden website olyan, mint egy objektum: adatok (HTML kód) és a hozzájuk tartozó metódusok (GET és POST kérések, amelyek jóesetben a HTML-be vannak égetve, rossz esetben JS állítja elő őket). Ráadásul az adatok és a megjelenésük teljesen szorosan vannak csatolva, így az információ kinyerése nehézkes, ráadásul minden weboldalon egyedi.

Miből gondolod, hogy emiatt terjednek (ha egyáltalán terjednek) a funkcionális módszerek?
A JS kódokban elszaporodó akarmi.forEach, akarmi.each-ekből gondolom, a PHP-ban megjelent lambda függvényekről, a blogmarkokban egyre több funkcionális témájú írásokról stb.
129

Ha így van, ez épp elég indok

inf3rno · 2015. Nov. 15. (V), 14.55
Ha így van, ez épp elég indok a kerülésükre.

Neked lehet, mások inkább megtanulják, hogy melyik eszköz mire alkalmas, és igyekeznek a megfelelő eszközöket összeválogatni a projekteikhez.

Én legalábbis nem úgy dolgozom, hogy megcsinálok valamit, és aztán elfelejtkezek róla, a megrendelőim sem azért készíttetnek el velem egy oldalt, mert csak rövidtávon szeretnének pénzt keresni vele.

Különösen jó lehet a memóriád, vagy kevés projekten dolgozol egyszerre. Nekem pár hónap után már nem sok fogalmam van arról, hogy egy-egy projekt kódja konkrétan hogyan nézett ki és milyen logikát követett.

De ha egy nagyobb munkáról van szó, és mondjuk nagyon ráépül egy keretrendszerre, már jóval nehezebb az egyes részek átírása, hisz az alapokban kell túrkálni. Vagy sikerül, vagy rámborul az egész.

Szvsz. ilyenkor ugyanúgy megteheted, hogy a szűk keresztmetszetnél vanillajs-re váltasz, a maradékot meg hagyod olyanra, amilyen. Felesleges az egészet átírni.

Minden website olyan, mint egy objektum: adatok (HTML kód) és a hozzájuk tartozó metódusok (GET és POST kérések, amelyek jóesetben a HTML-be vannak égetve, rossz esetben JS állítja elő őket). Ráadásul az adatok és a megjelenésük teljesen szorosan vannak csatolva, így az információ kinyerése nehézkes, ráadásul minden weboldalon egyedi.

Szóval te egy analógiára alapozva mondod azt, hogy rossz az OOP, nem magát az eszközt vizsgálod. Nincs több kérdésem.

A JS kódokban elszaporodó akarmi.forEach, akarmi.each-ekből gondolom, a PHP-ban megjelent lambda függvényekről, a blogmarkokban egyre több funkcionális témájú írásokról stb.

Ez csak azt a részt támasztja alá (nem reprezentatív felméréssel), hogy terjednek, azt nem, hogy miért.
66

Köszi a linkeket. Gyorsan

BlaZe · 2015. Okt. 20. (K), 23.11
Köszi a linkeket. Gyorsan utánanézve V8 alatt is komoly GC algoritmus van már, a hivatkozott cikk szerint már elérhető parallel sweeping GC algoritmus (biztos vannak itt jópáran, akiknek bővebb infója van a V8 alatti GC-ről). Akkor ebben pl pont tud segíteni a több mag, weben is.

Az érdekes egyébként az, hogy a GC jelentősen tudja csökkenteni a memória töredezettségét, vagyis hatékonyabb memóriakihasználást tesz lehetővé. Nem csak annyiról van szó, hogy nem kell vacakolnunk a memória foglalásával, felszabadításával. Ez akár jelentős sebességnövekedéssel is tud járni. Azonban többek között ennek az ára az az akadás, amire hivatkoznak, mint a GC hibája. Kérdés, hogy ezt széles körben elérhető (értsd ingyenes) VM-ekben mikor tudják kiküszöbölni.

Összességében a GC-re is igaz, ami mindenre. Van előnye is, meg hátránya is. Ha egy programnak nem fér bele, akkor váltani kell. Vagy olyan programot írni, amit jobban szeret a GC. Ha ez lehetséges JS alapú appoknál, weboldalaknál.
68

régiek

Gixx · 2015. Okt. 21. (Sze), 11.21
Köszi a linkeket, csak az a bajom, hogy az összes közül a legfrissebb is holnap lesz két éves. Vagyis 2013-as. Mi is volt 2013 októberben mobil fronton?

- Android 4.3
- Google Chrome 30
- iOS 5
- leginkább iPhone 4S

Ilyen szemszögből a "miért lassú" kérdésre nem igazán tudom minden tekintetben elfogadni ezeket, habár tudom, hogy technikai oldalról sok minden ma is helytálló. De mint egész, már nem áll össze szerintem.

Technikai dolgokban a google keresőben mindig bekapcsolom, hogy csak az utóbbi 1 hónap vagy 1 év tartalmai között keressen. Szerintem érdemes használni, sok mindent ki lehet vele szűrni.
69

Releváns

Hidvégi Gábor · 2015. Okt. 21. (Sze), 13.28
A relevancia nem feltétlenül arányos a megjelenési dátummal. A döntéshez több kérdést is fel kell tenni, néhányat elég könnyen meg lehet válaszolni:

- mennyit fejlődtek a mobil hardverek sebességben az utóbbi két évben?

Megnyitottam egy pár tesztet a mobilarénán átlagos okostelefonokról 2015 és 2013 őszéről, az eltérés nagyjából 40%-os.

- milyen gyakran cserélik le az emberek a telefonjaikat?

Itt is az átlagos az érdekes (tehát az iPhone-osok nem). Blaze egy fentebbi hozzászólásában írta, hogy három éves a telefonja, pedig ő biztosan megtehetné. Erről sajnos nincs adatom, de valószínűnek tartom, hogy amíg elfogadhatóan működik egy mobil, nem fognak helyette újat venni.

- mennyit fejlődtek a böngészők?

Ehhez végeztem egy tesztet a Google Chrome 30-as és 44-es változatával (többször is lefuttattam, pár ms eltérés volt az egyes esetek között), a Sunspider 1.0.2-t.

30-ason 795ms
44-esen 1138ms

alatt futott le, azaz 43%-kal lassabban. Tehát amit nyertünk a réven, elvesztettük a vámon.
70

Na ez így már korrekt

Gixx · 2015. Okt. 21. (Sze), 14.38
Köszi a választ, és a befektetett energiát, de tényleg. Egyből naprakészebb, és egyben hasznosabb is lett minden linkelt információ :)
20

Miután elértük, hogy a

inf3rno · 2015. Okt. 14. (Sze), 17.10
Miután elértük, hogy a weboldalknak ne alternatív mobil verzióik legyenek, hanem alternatív vizuális reprezentációik (reszpontzív felületek). Egy alternatív output készítése a meglévő tartalomból egy lépés a rossz irányba.


A mi szemszögünkből mindenképp, senki sem szeret kétszer dolgozni.
2

Kicsit mókásnak találom a

MadBence · 2015. Okt. 12. (H), 19.41
Kicsit mókásnak találom a címet, a egyik githubos példában pl. ennyi js fájl töltődik be:
<script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script>
  <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script>
  <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script>
  <script async custom-element="amp-fit-text" src="https://cdn.ampproject.org/v0/amp-fit-text-0.1.js"></script>
  <script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
  <script async custom-element="amp-instagram" src="https://cdn.ampproject.org/v0/amp-instagram-0.1.js"></script>
  <script async custom-element="amp-image-lightbox" src="https://cdn.ampproject.org/v0/amp-image-lightbox-0.1.js"></script>
  <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script>
  <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script>
  <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>
  <script async src="https://cdn.ampproject.org/v0.js"></script>
  <script async src="./viewer-integr.js"></script>
3

Kérdés, mi lesz a vége, ha

Hidvégi Gábor · 2015. Okt. 12. (H), 19.56
Kérdés, mi lesz a vége, ha mindig hozzáteszik az aktuális divat scriptjeit? Meddig engedik nőni?
4

Két pillantás után ez az

inf3rno · 2015. Okt. 12. (H), 20.00
Két pillantás után ez az ötlet szerintem már most halott. Dehát google, csinálják csak.
5

Pontosan ez jutott eszembe.

kmARC · 2015. Okt. 13. (K), 10.09
Pontosan ez jutott eszembe. Két hónap múlva kijön a FB valami hasonló elvekre építkező, de sokkal jobb megoldással.
6

Hacsak

zzrek · 2015. Okt. 13. (K), 12.30
Hacsak nem csinálnak némi furfangot.
Mondjuk az alapszkripteket és alaphtml/css-eket eleve beépítik a chrome-okba, valamint kijelentik, hogy a keresőben a "mobilbarát" az az ilyen visszaegyszerűsített oldal.
7

Mondjuk az alapszkripteket és

Poetro · 2015. Okt. 13. (K), 12.48
Mondjuk az alapszkripteket és alaphtml/css-eket eleve beépítik a chrome-okba

Ezalatt mit értesz? A böngészőkben alapból elég sok CSS és JS van beépítve pár tucat API formájában és rengeteg alap CSS tulajdonság a különböző elemeknek és azok shadow-dom-jának. Rengeteg elem eleve egy "Web Component" (button, audio, video, details), amikhez kapcsolódik HTML, CSS, JS
10

betöltés, renderelés

zzrek · 2015. Okt. 13. (K), 19.08
Nahát, nem gondoltam, hogy mondjuk a button a böngészőben html/css elemként shadow dom alapon van definiálva (mondjuk divekből van összerakva?), bár talán logikus (és egyben lehangoló, mert nem épp optimális teljesítmény szempontjából). Érdekes.
A hozzászólásomban arra gondoltam, amit a cikk ír: "betöltésük és renderelésük csak akkor történik meg, ha láthatóvá válnak a képernyőn". A "betöltés alatt"-ot úgy értettem, hogy valamilyen távoli helyről tölti be. Ezt lehetne megspórolni, ha semmi ilyen elemet nem kell betölteni, mert uniformizálva el van tárolva eleve a böngésző kódjában (akár bitmapként, a különféle lehetséges változatok). Az alapszkriptek beépítettségét is így gondoltam: nem google hosted lib formában, nem gyorstárazva, hanem eleve a böngészőben, szóval nem kell "betölteni".
Bár a cikk lehet, hogy a memóriába történő betöltést ért "betöltés" alatt.
12

Nahát, nem gondoltam, hogy

Poetro · 2015. Okt. 13. (K), 20.36
Nahát, nem gondoltam, hogy mondjuk a button a böngészőben html/css elemként shadow dom alapon van definiálva (mondjuk divekből van összerakva?), bár talán logikus (és egyben lehangoló, mert nem épp optimális teljesítmény szempontjából).

Azt nem hiszem, hogy minden böngészőben így lenne, de Operában és Chrome-ban például Shadow DOM-mal van megoldva még az <input type="submit"> is.
13

Hát ha tehetnék, akkor

MadBence · 2015. Okt. 14. (Sze), 00.08
Hát ha tehetnék, akkor gondolom más böngészőben is így oldanák meg :)
9

Miért?

Hidvégi Gábor · 2015. Okt. 13. (K), 17.06
Miért?
11

Szerintem nem fogják más

inf3rno · 2015. Okt. 13. (K), 19.27
Szerintem nem fogják más böngészők támogatni, nagyon sok új webes technológiával előfordult már ugyanez. Ha csak néhány új HTML5 tag-et okéztak volna le a W3C-nél, akkor más lenne a helyzet. A másik ok, amiért szerintem bukásra van ítélve, hogy megkötik a fejlesztők kezét azzal, hogy nem támogatják az egyedi js-t, de egyelőre nem világos, hogy ezt tényleg így gondolták e. Mindenesetre én nem látok ebben az egészben sok jövőt.
14

A web a jelenlegi formájában

Hidvégi Gábor · 2015. Okt. 14. (Sze), 11.52
A web a jelenlegi formájában túl bonyolult, erre jó példa, hogy DOM elem megtalálására jelenleg van vagy nyolc függvény, ehelyett mindenki a jQuery-féle egy gyűrű mind fölött megoldást favorizálja - teljesen jogosan. Ezt a kezdeményezést nagyjából így kell elképzelni.

A többségnek szerintem elég lesz ez az egyszerűsített változat, akinek pedig több az igénye, az használhat rendese böngészőt.
15

A jQuery-féle egy gyűrű mind

bamegakapa · 2015. Okt. 14. (Sze), 12.25
A jQuery-féle egy gyűrű mind fölött favorizálóinak ott lenne a querySelectorAll. Nincs ebben semmi bonyolult.

Egyébként a weben jelenleg is túl alacsony a belépési küszöb, pont ez vezet az ilyen problémákhoz.
16

Az alacsony belépési küszöb

Hidvégi Gábor · 2015. Okt. 14. (Sze), 13.44
Az alacsony belépési küszöb problémájával egyetértek, de van itt ezer más is, például nincs egy központi könyvtár, Encyclopedia Galactica, ahol el lehet kezdeni a tanulást.
18

Én az MDN-t használom, nincs

bamegakapa · 2015. Okt. 14. (Sze), 14.56
Én az MDN-t használom, nincs vele bajom.
21

A web a jelenlegi formájában

inf3rno · 2015. Okt. 14. (Sze), 17.13
A web a jelenlegi formájában túl bonyolult, erre jó példa, hogy DOM elem megtalálására jelenleg van vagy nyolc függvény, ehelyett mindenki a jQuery-féle egy gyűrű mind fölött megoldást favorizálja - teljesen jogosan.


Ha követnéd a csiripeket, akkor látnád, hogy nem így van: https://github.com/eorroe/NodeList.js A DOM rosszul tervezett, egyszerűen ezért nem használja senki natívan. A másik, hogy nem egységes böngészőnként, legalábbis amikor a jquery elindult, akkor egyáltalán nem volt az.
23

Az általad írt példában is az

Hidvégi Gábor · 2015. Okt. 14. (Sze), 20.53
Az általad írt példában is az Egy gyűrű mind fölött = használjunk egy függvényt egy feladatra megoldást ajánlják.

A megoldás egyébként szerintem az lenne, ha XPath-ot használhatnánk az elemek kiválasztására, annál jobbat még senki sem talált ki az elmúlt bő tizenöt évben.
27

Sokkal többről van szó, de ma

inf3rno · 2015. Okt. 14. (Sze), 23.36
Sokkal többről van szó, de ma nincs kedvem oldalakat írni.
28

Tehát az Egy gyűrű rossz,

bamegakapa · 2015. Okt. 15. (Cs), 00.17
Tehát az Egy gyűrű rossz, kivéve, ha az XPath az az Egy gyűrű :).

Használhatod egyébként elemek kiválasztására, van document.evaluate, legalábbis pár éve még volt, amikor dolgoznom kellett vele. Leszámítva persze, hogy az IE nem támogatja, de a Google-nak volt egy Wicked Good XPath nevű projektje, az megoldotta.

Én nem tapsikoltam örömömben tőle (azóta is görcsbe rándul a gyomrom), de biztos van, akinek az XPath tetszik.
31

Nekem nincs bajom sem az

inf3rno · 2015. Okt. 15. (Cs), 01.12
Nekem nincs bajom sem az xpath-el, sem a css selectorokkal. Az utóbbit nyilván gyakrabban használom, mert css-t is írok.
32

Sokszor elgondolkodom, hogy

Hidvégi Gábor · 2015. Okt. 15. (Cs), 08.46
Sokszor elgondolkodom, hogy szándékosan szoktad félreértni, amit írok, vagy pedig tényleg nem megy át a dolog?

Korábban ugyanis ezt írtam (te is válaszoltál rá, tehát biztosan olvastad):
ehelyett mindenki a jQuery-féle egy gyűrű mind fölött megoldást favorizálja - teljesen jogosan
Tehát akkor, hogy világos legyen: egy feladat elvégzéséhez szerintem egy függvény kell.

Az XPath mellett az szól, hogy már megvan bő tizenöt éve, ráadásul jóval többet tud, mint amit eddig bármelyik js könyvtár vagy natív függvény implementált.
34

Aham, így már tiszta sor. Az

bamegakapa · 2015. Okt. 15. (Cs), 09.30
Aham, így már tiszta sor. Az Egy gyűrű jó. De akkor még mindig nem értem, mi a baj a DOM-mal (legalábbis e tekintetben), hiszen a feladatra ott van az egy függvény, a querySelectorAll. Vannak más függvények, amik másra jók, meg vannak, amik alacsonyabb szintű dolgok, és azoknak is megvan a szerepük. Akinek nem kell, nem használja.

A weboldalak nem azért lassúak, mert a DOM-ban sokféle függvényt lehet hívni. Az XPath és a vele bandázó többi XML-es őrület (<- szubjektív vélemény) aztán meg szintén nem az egyszerűségéről híres, ha már a bonyolultsággal volt a bajod.
35

A DOM-mal ebből a szempontból

Hidvégi Gábor · 2015. Okt. 15. (Cs), 10.28
A DOM-mal ebből a szempontból nincs baj, a gond a választás szabadsága. Az embereknek láthatóan nincs szükségük rá, különben nem használná boldog-boldogtalan a jQueryt. Mindenféle döntési helyzet nehéz, márpedig ha nyolcféle közül kell kiválasztanod a megfelelőt, sokkal rosszabb, mintha van rá egy.

A weboldalak azért lassúak, mert például a jQuery egy újabb absztrakciós réteg a böngésző fölött, a fejlesztők sokmindent javascripttel oldanak meg ott is, ahol ez nem szükséges (jQuery-vel), rengeteg reklám, amit szintén javascripttel töltenek be sok-sok domain-ről, nem tudják, hogy mi mennyire hatékony js-ben stb.

A DOM-mal az a baj, hogy túlterhelt, erre kiváló példa, amit már korábban mértem, a data-* attribútumok használata. Alapból 20-30-szor lassabbak annál, mintha globális változóból olvasnád ki ugyanazt az értéket, amikor pedig jQuery-t használsz ugyanerre a feladatra, a különbség ezerszeres.

De mit lehet tenni, ha a túlterhelt fejlesztő mindenhol azt látja, hogy így csinálják? Egyszerűsíteni kell, kivenni a kezéből a döntés szabadságát à la Google : )

Ezzel mondjuk ebben a formában nem értek egyet – bár jobb, mint a jelenlegi helyzet –, szerintem inkább ki kéne dobni a sok ballasztot a JS-ből és a HTML-ből.
37

Mindenféle döntési helyzet

Endyl · 2015. Okt. 15. (Cs), 11.11
Mindenféle döntési helyzet nehéz, márpedig ha nyolcféle közül kell kiválasztanod a megfelelőt, sokkal rosszabb, mintha van rá egy.


És az komolyan probléma egy szakmában, hogy tanulni kell és döntéseket kell hozni? Az építészek, az orvosok, stb. hogyan képesek elvégezni a munkájukat? Gyanítom esetükben is több lehetőség közül kell választani és nincs egy csodamódszer, ami mindent megold. Illetve van; a tanulás és gondolkodás kombója. Aki erre nem képes, az inkább bízza olyanra az adott területet, aki szeretne elmélyedni benne, és cserébe foglalkozzon azzal, aminek ő szeretne a szakembere lenni.
39

Az építészeknél, orvosoknál

Hidvégi Gábor · 2015. Okt. 15. (Cs), 11.44
Az építészeknél, orvosoknál van egy nagyon komoly szűrő, először egy felvételi, aztán egy diploma, a mi szakmánkban nincs ilyen.

A legtöbb webes programozó kontár. Ettől függetlenül ha a fenti szöveggel odaállítasz hozzá:

"Drága barátom, kezdj el tanulni és gondolkodni, ha nem megy, menj el kapálni!", akkor ki fog nevetni, és folytatja tovább azt, amit eddig, hisz működik és fizetnek érte.

Én továbbra is azt mondom, hogy csökkenteni kell a választási lehetőségek számát. Neked mi a javaslatod?
42

Szerintem az embereket

Endyl · 2015. Okt. 15. (Cs), 13.11
Szerintem az embereket kellene okosítani, nem a technológiát butítani. A fordítottja csak tüneti kezelés; előbb-utóbb fel fogja ütni a fejét a probléma más formában (azt is mondhatnánk, hogy szivárog az absztrakció).
43

Okosítani?

Hidvégi Gábor · 2015. Okt. 15. (Cs), 13.21
Az internet segítségével? Hogyan? Mindenki a maga igazát hajtogatja, nincs egy Encyclopedia Galactica vagy egy Birodalmi Könyvtár.
44

Okosítani

Endyl · 2015. Okt. 15. (Cs), 13.53
Egyrészt nem az internet az egyetlen információforrás, másrészt jelenleg az internet az Encyclopedia Galactica. De mivel a probléma nem feltétlenül és nem csak az informatikában gyökeredzik, ezért nem is az a megoldás, hogy mindenkit megtanítunk tisztességesen programozni. Az okosítást messzebbről kell kezdeni; mondjuk az iskolarendszernél, ahol az adatok (szükségtelen) magoltatása helyett gondolkodásra kéne tanítani az embereket. Arra, hogy a tudást tudják alkalmazni, és adott esetben a zajból kiszűrni. Ez a téma nyilván nagyobb léptékű, minthogy itt megtaláljuk a megoldást, de szívesen beszélgetek róla. Szerintem ebben az irányban kell keresgélni, nem bárminek is a butításában.

Persze ettől még lesznek hibás leírások, illetve bővülni fog a tudásunk, ami elavulttá tesz korábbi anyagokat (amiknek a javítására, frissítére is törekedni kell), de épp ezért fontos, hogy az emberek megtanulják a kritikus, logikus gondolkodást, hogy képesek legyenek kiszűrni a selejtet.

Az régen rossz, ha csak arra vagyunk képesek, hogy vakon kövessük az Egy Igaz Utat.
179

Nem állítottam sehol, hogy a

Hidvégi Gábor · 2016. Már. 17. (Cs), 14.26
Nem állítottam sehol, hogy a technológiát butítani kéne. A kedvenc példám erre a DOM csomópontok keresése, amire jelenleg nagyjából nyolc függvény létezik, ezek kiválthatóak egy darabbal.
180

DOM csomópontok

Poetro · 2016. Már. 17. (Cs), 14.32
Mik azok a DOM csomópontok? Tudtommal a DOM-ban csak elemeket lehet keresni, azokat pedig azonosító, osztály, név, típus, valamint CSS kiválasztó segítségével.
181

Szerintem a node-okat

bamegakapa · 2016. Már. 17. (Cs), 14.44
Szerintem a node-okat fordítja így. Bár az elemek is node-ok, de keresni elemeket lehet.
182

node jelentése. Hívhatjuk

Hidvégi Gábor · 2016. Már. 17. (Cs), 15.18
node jelentése. Hívhatjuk elemnek is, lényegtelen.
183

Nem lényegtelen, mert a

inf3rno · 2016. Már. 17. (Cs), 19.54
Nem lényegtelen, mert a TextNode nem element, és ezért nem kereshető.
184

XPath segítségével azok is

Hidvégi Gábor · 2016. Már. 18. (P), 09.55
XPath segítségével azok is kereshetőek.
177

Videó

Hidvégi Gábor · 2016. Már. 16. (Sze), 17.50
The paradox of choice. A válasz: igen, minél nagyobb a választási lehetőségek száma, annál nehezebb jó döntést hozni, és ez sokakat teljesen megbénít.
178

Ez a videó semmi lényegi

Endyl · 2016. Már. 16. (Sze), 19.04
Ez a videó semmi lényegi újdonságot nem mondott az eddigiekkel kapcsolatban. Én sem tudok rá olyat válaszolni, amit már le ne írtam volna, így csak idézem magam:
Az régen rossz, ha csak arra vagyunk képesek, hogy vakon kövessük az Egy Igaz Utat.

Amíg nincs újabb érdemi érv, részemről ez a téma le van zárva.
29

A NodeList.js-el én is

bamegakapa · 2015. Okt. 15. (Cs), 00.20
A NodeList.js-el én is szimpatizálok. A jQuery fő előnye mindig az volt, hogy elfedte a böngészők különbségeit, erre ma szerencsésebb projektekben kevésbé van szükség.
30

+1, eleve ott indul, hogy

inf3rno · 2015. Okt. 15. (Cs), 01.06
+1, eleve ott indul, hogy settert és gettert használ, ami azt jelenti, hogy ES5 kompatibilis böngészőknél működik csak. nem kell visszafele kompatibilisnek lennie. az ES5 kompatibilis böngészők meg nagyjából ugyanúgy működnek leszámítva pár apróságot. az igazán jó az lenne, ha a NodeList-et alapból beletákolnák a DOM-ba a böngésző gyártók és nem kellene vanillajs-ben állandóan mindenhez ciklust használni.

NodeList-nél is van elvi lehetőség rá, hogy elfedjük a különbségeket, csak bele kellene írni a getter-es, setter-es kódba, hogy egy-egy speciális property-t böngészőnként máshogy kezeljenek. ezt talán bele is lehetne írni valami pluginos formában. majd megnézem mennyire lassítana úgy. nekem amúgy úgy jött le, hogy a srác nagy valószínűséggel nem támogatná, hogy jquery2 legyen a libből, és fork lenne belőle, de majd kiderül. holnap ha lesz időm, akkor megtákolom a kódját, hogy nodejs kompatibilis legyen, és browserify-al lehessen használni.
8

Ha ez bejön...

Gixx · 2015. Okt. 13. (K), 14.01
...akkor kicsit olyan szájíze lesz, mint a játékkonzolra fejlesztésnek: mindenki egyazon keretbe van zárva, hozd ki belőle a legtöbbet. Mondjuk nekem ez nagyon tetszik, és biztos sokat lehet majd belőle tanulni.

Jelenleg annyira nagy a szabadság, hogy képtelenség mindennel lépést tartani, legalábbis én nem tudok, így aztán sokszor a kevésbé lényeges dolgok esetében megelégszek a 3rd party cuccokkal is.
22

Nem vagy egyedül. Annyi

inf3rno · 2015. Okt. 14. (Sze), 17.15
Nem vagy egyedül. Annyi keretrendszer van egy-egy témában, hogy már a válogatás közöttük is nehezen megy.
60

Nem akarok kontárkodni...

Gixx · 2015. Okt. 20. (K), 17.52
...de átnézve a hozzászólásokat, mintha mindenki csak a kezdeményezés egyik felét látná meg belőle: a működési sebesség részt.

A Google szerdán egy új kezdeményezést jelentette be, aminek célja, hogy jelentős mértékben felgyorsítsa a mobilos webolodalak betöltési és működési sebességét.


Engem jobban izgat a betöltési sebesség, amit szerintem csak a kisebbik részben befolyásol a sok flinc-flanc extra fájl. A mai telefonok szerintem már elég erősek, hogy felvegyék a versenyt az asztali számítógéppel WiFi-n, de az EDGE hálózaton akkor is lassan töltődik be, ha 16 magos proci várja az animálást...

Innen nézve pedig én kifejezetten örülnék, ha a böngésző már eleve tudná azokat a dolgokat, amit szerintem a legtöbb fejlesztő ténylegesen kihasznál egy-egy keretrendszerből, így azokat már le se kellene tölteni...

Átnézve a hobbi kódjaimat rájöttem, hogy én csak azért használok jQuery-t, hogy csak ennyit gépeljek

$('.something').each(function(){ 
    var element = $(this);
    /* ... */ 
});
ennyi helyett

var stuff = document.querySelectorAll('.something');

for(var i in stuff) {
  var element = stuff[i];
  /* ... */
}
mégha nem is teljesen ekvivalens a kettő. Pedig a jQuery révén is csak a DOM-ot manipulálnám a végén...

Minden másra az MDL-t használom, ami szintén Google termék, így elég valószínű, hogy ezt valamilyen módon tartalmazná a tervük...
62

Elvileg a NodeList pont

inf3rno · 2015. Okt. 20. (K), 18.20
Elvileg a NodeList pont annyit tud, hogy az alsó kódot a fenti formára hozza 200 sor kóddal.
118

Válasz a 109-re

Hidvégi Gábor · 2015. Nov. 14. (Szo), 13.39
Mivel kevés már a hely, itt válaszolok.

Ezt nem cáfoltad, és magyarázatot se adtál arra, hogy miért gondolod azt, amit gondolsz.
Olvasd el a 105-ös második bekezdését, ott van a magyarázat. De akkor jobban kifejtem, a legkisebbtől a legnagyobb felé haladva.

Szinte bármelyik weboldal forrását megnézed, elég hamar kiderül, hogy a készítője nem igazán érti az összefüggéseket. Kezdve a sok javascriptben generált tartalommal, amire az esetek 99%-ában semmi szükség, hisz ugyanazt meg lehet csinálni szerveroldalon, másrészt a natív HTML feldolgozása minden esetben gyorsabb, mint bármilyen scriptnyelvben. Ezzel mondjuk a bevételek és a nyereség 1-2%-ától esnek el, ami elsőre nem hallatszik soknak, de ha mellé tesszük, hogy a banki kamatok most ugyanezen a szinten vannak, onnantól kezdve már elég nagy a felelősség. És ha valaki ért hozzá, tudja, hogy szinte nulla plusz munkával járna rendesen megcsinálni.

Ugyancsak a hozzánemértést tükrözi, amit a jQuery-t használó oldalak 99%-ában látok, például ID helyett classneveket használnak egyedi azonosítóknak, egy függvényen belül nem chache-elik a függvények eredményeit (jQuery selectorok), jQuery-t használnak ott is, ahol nem kéne, mert nem ismerik a böngészők működését. Ennek következtében az oldalak indokolatlanul lassúak.

Erre egy jó példa az egyik általam látogatott videosite, ami a gépemen használhatatlanul lassú. Tudni kell, hogy alapból nem erőgépen dolgozom, egy Atomos gépen, egyrészt az alacsony fogyasztás, másrészt az alacsony sebesség miatt. Visszatérve a videókra, van egy kényelmi szolgáltatás, hogy a videó nagy képe alatt van hat-hét kis képkocka, és ha a nagy kép felett viszem az egeret, akkor ezeket a kisképeket nagyítja ki, így nyerhetek betekintést az egészbe.

A feladat tehát egyszerű, onmousemove-re, el kel végezni egy matematikai műveletet, és a megfelelő képet meg kell jeleníteni. Ez az eredeti site-on jelenleg 50%-os processzorterhelést okoz, azaz 0,66 GHz-nyi folyamatos tekerés. Egyszer ezen felhúztam magam, és írtam két scriptet: PHP-ban leszedtem az oldal tartalmát, és készítettem belőle saját HTML-t, majd írtam hozzá egy scriptet, ami a fenti műveleteket elvégzi. Az eredmény: 5%-os processzorterheltség, azaz tízszer gyorsabb működés. Persze még ezen is lehetne finomítani, de fölösleges. Ja, és persze JS 1.3 meg DOM 1.0 függvényeket használtam, tök alapokat, tehát még azon sem kell izgulnom, hogy valamelyik böngészőn nem megy.

Mindezt egy 12-es Operán készítettem és teszteltem, ami egy két vagy három éves darab, még a régi motorral, azaz már ismeri az újabb szabványokat, de szerencsére jó lassú. Emiatt szoktam dilettancia-mérőnek használni, mert ha valami ezen nem jól jelenik meg vagy lassú, az az esetek 99%-ában a készítő hozzá nem értését tükrözi, lásd fenti eset.

Ennél jobb példa az origó meg az index, tragédia, amit ott művelnek, pedig biztos nem minimálbéren vannak bejelentve az alkalmazottak. Az origón kikapcsolt JS mellett nem jelenik meg a képek többsége, az index pedig tetűlassú és következetlen.

Amikor pár éve írtam az AJAX kihívásai című bejegyzésemet, a végén nagyjából azt írtam, hogy nem ajánlom a használatát, mert mivel az interneten nincs rendes követendő példa, a tipikus hibákat mindenki el fogja követni, mert nem egyértelmű, hogyan lehet jól elkészíteni egy ilyen oldalt.

Azóta a helyzet nem változott, az AJAX-os oldalak usability gondokkal küzdenek, erre kiváló példa a Facebook, ami egyrészt indokolatlanul lassú, másrészt több modul rajzoló eljárása is többféleképp van megírva, például az ajánlott oldalaké, így nem konzisztens a működése.

Önmagukban a keretrendszerek ezért nem bűnösek, mindig az ember a szűk keresztmetszet. Aki eleve keretrendszerrel kezd, egy csomó tudnivaló híján lesz, ami a fentiek alapján egyértelmű.

A legtöbb programozó a számára ismeretlen dolgokat copy-paste-eli, ahelyett, hogy megértené. Én is így dolgoztam jóideig, de aztán egyszer amikor egy animációt kértek tőlem, felmerült bennem a kérdés, hogy ezért az egy featúráért tegyek be egy jQuery-t az oldalba? Akkor inkább utánajárok, hogyan is működik, pedig sosem szerettem a matekot. Aztán elég gyorsan kiderült, hogy jóval egyszerűbb, mint gondoltam, egy egyszerű attribútum-animáló függvényt kihoztam egy kilobájtból.

Mindig is szkeptikus voltam a keretrendszerekkel kapcsolatban, de ez után főleg. Hogyan tudok úgy jót alkotni, hogy ha nem ismerem, mi hogyan működik? Mi van, ha lassú valami, alaptudás nélkül hogyan nyúlhatok bele a keretrendszerbe, hogyan tudom mellőzni?

Te akkor jó programozó vagy, mert nem használsz keretrendszert?
Jobb vagyok annál, aki csak azt használ, mert én anélkül is tudok dolgozni, ennyi előnyöm van.

Te attól vagy jó programozó, hogy nem használsz keretrendszert?
Nem, hanem attól, hogy utánajárok a dolgoknak. De ehhez félre kellett tennem a kereteket.

Azt tudod, hogy a PHP is egy keretrendszer? Tehát akkor a logikádat követve, ettől Te nem lehetnél jó programozó
Meg fogsz lepődni, erre én is rájöttem, és emiatt kezdtem el a C-vel foglalkozni, hogy megértsem a PHP működését. Emiatt örültem darevish cikkének, mert így tudom, hogyan kell elkezdeni PHP kiterjesztést írni, ha több kraft kell.
131

Válasz a 130-ra

Hidvégi Gábor · 2015. Nov. 15. (V), 15.58
Itt válaszlok a 130-ra, mert ott már elfogyott a hely.

Ha valóban az volt a célod, hogy a függvény hívások többlet idejével bizonyítsad, hogy mennyire károsak a szivárgó absztrakciók, akkor csúnyán felsültél.
Pedig napnál is világosabb, és nem értem, miért nem esik le neked is. Blaze gépén C-ben egy függvényhívás 2ns, a tieden mondjuk 3; JS-ben ugyanez – és most vegyük a legjobb esetet – 24 ms (te mérted), azaz minimum nyolcszor lassabb a scriptben hívott függvény, mint a (kvázi) natív. Ennyibe kerülnek az absztrakciók, rosszabb esetben százszoros a különbség.

A felsülésről pedig annyit, hogy kikérem magamnak ezt a hangnemet, amit mostanában megengedsz velem szemben. Én nem gúnyolódok rajtad, hanem megpróbálom máshogy megfogalmazni a mondanivalómat, érvelni. Ezt súlyosbítja, hogy moderátor vagy a weblaboron. Szerinted normális, hogy így beszéljünk egymással?
133

Blaze gépén C-ben egy

BlaZe · 2015. Nov. 15. (V), 16.24
Blaze gépén C-ben egy függvényhívás 2ns, a tieden mondjuk 3; JS-ben ugyanez – és most vegyük a legjobb esetet – 24 ms (te mérted), azaz minimum nyolcszor lassabb a scriptben hívott függvény, mint a (kvázi) natív. Ennyibe kerülnek az absztrakciók, rosszabb esetben százszoros a különbség.
És mégis egy ilyen magas absztrakciókat használó nyelven dolgozol, mint a PHP. Ha ez baj, akkor miért? Ádám írta pár napja, hogy speed is a feature. Egyetértek, de továbbgondolnám: meeting SLA is a feature. Az annál jobb teljesítményre optimalizálás (plusz erőforrásokkal) pénzégetés. Lehet mondani, hogy weben a user felé ez az SLA kicsit virtuális dolog, de valójában létezik, mint tudjuk. A látogatónak kell elég gyors legyen a válasz, és ez megoldható PHP-val, ezért használod. Mert általában elég egyszerű a serveroldali feladat (a gép számára). Ha ez megvan, és több látogató érkezik, akkor meg lehet skálázni, ami weboldalnál tipikusan olcsóbb, mint a kódot optimalizálni.
135

Egyetértek, de

inf3rno · 2015. Nov. 15. (V), 19.12
Egyetértek, de továbbgondolnám: meeting SLA is a feature.

A látogatónak kell elég gyors legyen a válasz, és ez megoldható PHP-val, ezért használod. Mert általában elég egyszerű a serveroldali feladat (a gép számára). Ha ez megvan, és több látogató érkezik, akkor meg lehet skálázni, ami weboldalnál tipikusan olcsóbb, mint a kódot optimalizálni.


+1, a felhasználói sebességgel szemben támasztott elvárásoknak kell megfelelni. A túl sok optimalizálás, mint arra rámutattál, feleslegesen végzett munka, ami még akár le is ronthatja a kód minőségét és ezzel csökkentheti a karbantarthatóságot.
134

Pedig napnál is világosabb,

inf3rno · 2015. Nov. 15. (V), 19.05
Pedig napnál is világosabb, és nem értem, miért nem esik le neked is. Blaze gépén C-ben egy függvényhívás 2ns, a tieden mondjuk 3; JS-ben ugyanez – és most vegyük a legjobb esetet – 24 ms (te mérted), azaz minimum nyolcszor lassabb a scriptben hívott függvény, mint a (kvázi) natív. Ennyibe kerülnek az absztrakciók, rosszabb esetben százszoros a különbség.


Én nem mértem 24ms-t, 24ns-t esetleg. A lényeg egyáltalán nem azon volt, hogy 8 vagy 10x különbség van C és js között, hanem azon, hogy ez számít e bármit egy átlag js kódnál. A válasz az, hogy nem, mert a js-nél nem követelmény az a fajta sebesség, ami a C-ben igen. Ha megmaradunk a webnél, ahogy javasoltad, akkor egy átlag js kódnál kb 50msec, ami érzékelhető idő kiesés egy felhasználónak. Ehhez tabletnél a legrosszabb esetben is 50*3000 függvény hívás kellett a méréseim alapján. Az sem állja meg a helyét, hogy mobilon annyira gyenge a CPU, hogy annál már próblémát okoznának a függvény hívások. A Firefox-ok esetében 24, 66, 362ns voltak az idők rendre PC, tablet és mobil között. A tabletnél kb 3000 fgv hívást tudott 1 msec alatt a lassú böngészőknél, szóval a 6x lassabb mobil esetében kb 500 fgv hívást tudhat. Ez még mindig 50 * 500 = 25000 js függvényhívást jelent érezhető lassulás nélkül. Nem jellemző, hogy egy művelet ennyi függvény hívással járna, főleg nem, ha mobilra optimalizálunk, tehát nagyon extrém módon elgányolt kódnál lehet csak ez a szűk keresztmetszet. A személyes tapasztalatom is az, hogy a DOM műveletek, hosszú listák megjelenítése sokkal jobban lassítják a mobilt, mint bármi, amit a js a háttérben végez.

A felsülésről pedig annyit, hogy kikérem magamnak ezt a hangnemet, amit mostanában megengedsz velem szemben. Én nem gúnyolódok rajtad, hanem megpróbálom máshogy megfogalmazni a mondanivalómat, érvelni. Ezt súlyosbítja, hogy moderátor vagy a weblaboron. Szerinted normális, hogy így beszéljünk egymással?


Nem igazán értem mire gondolsz. Szerintem normális. De ha már itt tartunk, akkor a többieket kérdem, szerintetek is tűrhetetlen a hangnem, amit megengedek magamnak?
136

Válasz a 132-re

Hidvégi Gábor · 2015. Nov. 16. (H), 14.16
Ez egy válasz a 132-es hozzászólásra, mert ott elfogyott a hely.

Akkor rossz volt a példád a sebességgel. Az nem azt bizonyítja, hogy az absztrakciók szivárognak, hanem hogy minden műveletnek költsége van.
Srácok (Blaze és inf3rno), vagy nagyon elbeszélünk egymás mellet, vagy valaki valamit nagyon nem ért.

A processzor olyan, mint egy húsdaráló, amibe biteket töltünk. De mivel alapvetően nem darálni szeretnék rajta, hanem értelmes műveleteket végezni, ezért absztrakciókat vezettek be. A gépi kód értelmezhetetlen az emberek számára, ezért először Assemblyben programoztak, majd egy további absztrakciót vezettek be a C-vel. A processzorban nincsenek olyan típusú változók, mint a C-ben, de függvények sem, de ezt elfedik előlünk a fordítók. Viszont ennek ára van, amit sebességcsökkenésben fizetünk meg, ezeknél az absztrakcióknál ez a szivárgás.

És akkor el is érkeztünk e blogmarkhoz, hadd idézzek az AMP projekt címlapjáról:
For many, reading on the mobile web is a slow, clunky and frustrating experience
A cég által Accelerate Mobile Pages-nek (AMP) hívott projekt mindezt gyakorlatilag a weboldalakon futó egyedi szkriptek teljes mellőzésével érné el
Magyarul google-ék kivesznek egy absztrakciós szintet, hogy mobilon használható oldalakat lehessen készíteni. A böngészőjük két év alatt 40%-ot lassult, és valószínűleg nincs is benne több tartalék. Visszavonulót fújtak.

Viszont az alkalmazáshoz egy betűt nem kellett hozzányúlni, csak kicseréltem az implementációt egy interface mögött. Itt is absztrakciók nélkül jóval nagyobb munka, a megrendelőnek pedig nagyobb költség lett volna. Tehát az állításod cáfolva ;)
Szerencséd volt. Én már láttam jópár céget bedőlni, akiknek dolgoztam, mert mondjuk elfelejtettek marketingre félretenni pénzt, vagy jött egy konkurencia, és azzal nem voltak képesek versenyezni. Mi van akkor, ha a te esetedben is ez történt volna mondjuk egy évvel az indulás után? Így nem lett volna szükség az XLS gyártó cseréjére, azaz felesleges lett volna az absztrakció, hívhattad volna közvetlenül az XLS api függvényeit.

Szóval ez, hogy minden függőséget absztrakciók mögé rejtünk, anélkül, hogy ismernénk a jövőt, számomra kimeríti a premature optimization fogalmát. Szerintem egy problémával akkor kell foglalkozni, ha felmerül. Szóval ha nem jól alakultak volna a dolgok, a felelős te lettél volna azért, mert olyan featúrát tettél bele a projektbe és fizettettél ki a megrendelővel (cserélhető XLS gyártó), amire senki nem kért. Úgyhogy nem olyan egyszerű a döntés, hogy legyen-e absztrakció vagy sem.

Occam borotvája nem tudom hogy kerül ide, de a foreach egyértelműen szemléletesebb szerintem, mint a for ciklus
Nem ez volt a lényeg. Ha megnézed, honnan idéztem, Poetro funkcionális kódjával hasonlítottam össze egy általam írd procedurálisat. Én for ciklust használtam, ő függvényeket, az eltérés sebességben tízszeres volt a ciklus javára, erre utaltam e blogmark vitájában egy csomószor.
137

Srácok (Blaze és inf3rno),

BlaZe · 2015. Nov. 16. (H), 16.45
Srácok (Blaze és inf3rno), vagy nagyon elbeszélünk egymás mellet, vagy valaki valamit nagyon nem ért.
Szerintem te érted félre Joel cikkét, amire hivatkozol. Ő azt írja, hogy bár az absztrakciók célja az, hogy azok implementációival egyáltalán ne kelljen foglalkozzunk, ez nem mindig állja meg a helyét, mert időnként bele kell lássunk a működésébe, hogy az absztrakciót használó kód helyesen, vagy hatékonyan működjön. Innen jön a leaky, miszerint az absztrakció mögé leszivárognak az implementációs részletek, és az absztrakció nem biztosítja azt a teljes blackbox viselkedést, amire szánták. De egy szót nem mond arról, hogy azért leaky egy absztrakció, mert költsége van. És simán lehet, hogy nincs is. Ezt csak te gondoltad hozzá, ezért tűnik úgy, hogy nem értjük egymást.

A processzorban nincsenek olyan típusú változók, mint a C-ben, de függvények sem, de ezt elfedik előlünk a fordítók. Viszont ennek ára van, amit sebességcsökkenésben fizetünk meg
Ezt kifejtenéd? Vagy nem egyre gondolunk, vagy nem teljes az egyetértés :)

Ezeknél az absztrakcióknál ez a szivárgás.
Nem, az a szivárgás, hogyha az absztrakciók mögött ki szeretnéd hozni a gépből a maximumot, akkor értened kell annak a működését. Pl nagyméretű mátrixok szorzásánál ismerned kell a cache működését, hogy a CPUnak minél kevesebb időt kelljen várnia az adatokra a full cache miss miatt. De nem annak van költsége, hogy egy memória címre azt mondod C-ben, hogy azt intként szeretnéd kezelni. 2 int összeadása úgyis egy add assembly utasításra fog lefordulni. Ennek önmagában nincs plusz költsége.

jött egy konkurencia, és azzal nem voltak képesek versenyezni. Mi van akkor, ha a te esetedben is ez történt volna mondjuk egy évvel az indulás után? Így nem lett volna szükség az XLS gyártó cseréjére, azaz felesleges lett volna az absztrakció, hívhattad volna közvetlenül az XLS api függvényeit.
És mit nyertem volna vele? A kód nagyobb és bonyolultabb lett volna, a tesztelhetőség sokkal rosszabb, az absztrakciós szintek keverednek, ami elvonja a figyelmet amikor egy specifikus, adott szinten lévő problémával kell foglalkozni.

Szóval ez, hogy minden függőséget absztrakciók mögé rejtünk, anélkül, hogy ismernénk a jövőt, számomra kimeríti a premature optimization fogalmát. Szerintem egy problémával akkor kell foglalkozni, ha felmerül.
Szerintem meg business logicban semmi keresnivalója külső függőségnek.

Szóval ha nem jól alakultak volna a dolgok, a felelős te lettél volna azért, mert olyan featúrát tettél bele a projektbe és fizettettél ki a megrendelővel (cserélhető XLS gyártó), amire senki nem kért. Úgyhogy nem olyan egyszerű a döntés, hogy legyen-e absztrakció vagy sem.
Miből gondolod, hogy ennek plusz költsége kell legyen? Egyik hozott példám sem járt költséggel, sőt.

Én for ciklust használtam, ő függvényeket, az eltérés sebességben tízszeres volt a ciklus javára, erre utaltam e blogmark vitájában egy csomószor.
Ez kontextus nélkül irreleváns. Lassú? Optimalizálni kell. Nem? Akkor belefér.
139

Elméletben minden

inf3rno · 2015. Nov. 16. (H), 17.36
Elméletben minden absztrakciónak van plusz költsége, a gyakorlatban meg ha csak annyi, hogy néhány új függvényt meg osztályt hozol létre, akkor az nullának tekinthető. Nem tudom Gábor miért erre hegyezte ki a témát, egyáltalán nem általános igazság, hogy a leaky abstraction jelentős lassulást eredményez. Szerintem sokkal gyakoribbak lehetnek a kezeletlen kivételek, amik alsóbb szintekről jönnek, vagy a több szint mélységben lévő bugok, amiket nehéz felderíteni, ha nem érted az alacsony szintű kód működését, és csak az absztrakcióra van szükséged, stb... A performancia kérdés inkább akkor jöhet be, ha a rétegeket valami költséges kommunikációs csatorna választja el egymástól, pl HTTP, websocket, stb. vagy ha jelentős sebességbeli növekedést okoz, ha egyszerre hajtunk végre több alacsony szintű műveletet, pl DOM optimalizáció, vagy soros/párhuzamos HTTP kérések. Biztos lehet még egyéb példákat is találni erre, most így hirtelen ennyi jutott eszembe.
141

Elméletben minden

Hidvégi Gábor · 2015. Nov. 16. (H), 18.09
Elméletben minden absztrakciónak van plusz költsége, a gyakorlatban meg ha csak annyi, hogy néhány új függvényt meg osztályt hozol létre, akkor az nullának tekinthető. Nem tudom Gábor miért erre hegyezte ki a témát, egyáltalán nem általános igazság, hogy a leaky abstraction jelentős lassulást eredményez


A Google szerdán egy új kezdeményezést jelentette be, aminek célja, hogy jelentős mértékben felgyorsítsa a mobilos webolodalak betöltési és működési sebességét. A cég által Accelerate Mobile Pages-nek (AMP) hívott projekt mindezt gyakorlatilag a weboldalakon futó egyedi szkriptek teljes mellőzésével érné, és új, az alap HTML-ben nem definiált elemek bevezetésével érné el.
142

A Google szerdán egy új

inf3rno · 2015. Nov. 16. (H), 19.03
A Google szerdán egy új kezdeményezést jelentette be, aminek célja, hogy jelentős mértékben felgyorsítsa a mobilos webolodalak betöltési és működési sebességét. A cég által Accelerate Mobile Pages-nek (AMP) hívott projekt mindezt gyakorlatilag a weboldalakon futó egyedi szkriptek teljes mellőzésével érné, és új, az alap HTML-ben nem definiált elemek bevezetésével érné el.


Amit ők csinálnak ugyanúgy js-t használ.

Az AMP-alapú oldalak gyakorlatilag csak egyetlen JavaScript-könyvtárat töltenek be, aminek feladata az standard és bővítette AMP vezérlők működésének biztosítása. Utóbbiak a mobil weblapokban egyedi HTML tagek segítségével kerülhetnek felhasználásra, ahol azonban semmilyen egyedi szkript és más műveleti kód nem kapcsolódhat hozzájuk. A vezérlők működtetése és interaktívvá tétele ehelyett az AMP könyvtár feladata.


Annyi történt, hogy nem engednek a felhasználóknak egyedi js kódot betenni, hanem rákényszerítik őket a google framework limitált eszközkészletének a használatára. Nyilván ha kisebb területet fedünk le az absztrakciónkkal, akkor kevésbé fog szivárogni, és csökkennek a mellékhatásai, ami jelen esetben gyorsulást eredményezhet. Nagyjából ennyi köze van a témához.

Magyarul google-ék kivesznek egy absztrakciós szintet, hogy mobilon használható oldalakat lehessen készíteni.


Nem tűnt el egy absztrakciós szint sem. Annyi történt, hogy a js kódból nem lehet bekonfigurálni az egészet, csak HTML-ből. Így kénytelenek leszünk szerver oldalra tenni a projekthez tartozó absztrakciós szinteket, ahelyett, hogy kliens oldali js-be tennénk őket. Ez minimális sebesség növekedést jelent majd kliens oldalon, viszont a funkcionalitásban annyira fapados lesz, hogy aki kicsit is komolyabb mobil oldalt akar, az biztosan nem fogja használni.

A google szerintem abban a kényszerképzetben szenved, hogy csak ők tudnak gyors mobil oldalt csinálni, és ezért jobb, ha mindenki az ő kódjukat használja. A másik tévedésük, hogy az egyedi js kód miatt lassúak a mobil oldalak. A problémát nem az egyedi js kód okozza, hanem az, ha a kód írója inkompetens, rosszul választja meg az eszközöket, és/vagy nem foglalkozik a sebességre történő optimalizációval, illetve nem érdekli, hogy mobilon mennyire gyors az oldal. Az érdektelenségen az sem segít, ha a google csinál egy új framework-öt, mert akit nem érdekel a mobil oldal sebessége, az úgysem fogja használni, akinek meg nem elég a szűkös eszközkészlet, amit felajánlanak, az szintén nem fogja használni. Ezek miatt a tévedések miatt szerintem bukás lesz a projekt vége. Ennyi a véleményem, amit továbbra is fenntartok, a jövő majd eldönti, hogy kinek van igaza. Mindenesetre mióta követem a webes technológiákat, azóta nem egy hasonló projektet láttam már nagy hype-al megjelenni, aztán ugyanolyan gyorsan eltűnni szinte az összes böngészőgyártótól.

Legalább ez a leaky abstraction téma érdekes volt. Nem hiszem, hogy utánaolvastam volna, ha nem írod, kösz! :-)
140

De egy szót nem mond arról,

Hidvégi Gábor · 2015. Nov. 16. (H), 18.02
De egy szót nem mond arról, hogy azért leaky egy absztrakció, mert költsége van.
Dehogynem, az oldal közepén lévő "All non-trivial abstractions, to some degree, are leaky." alatt lévő felsorolás első kettő és az ötödik pontja pont a költségekről szól.

Hogy egyértelmű legyen:
iterating over a large two-dimensional array can have radically different performance if you do it horizontally rather than vertically
Itt, ugye az történik, hogy ha egymás után lévő értékeken iterálsz végig a memóriában, akkor a memóriamutatót csak eggyel kell minden esetben növelni, de ha sorok közt kell ugrálni, akkor mondjuk nem biztos, hogy benne lesz a cache-ben a következő érték, és lassú lesz.

Ugyanez a helyzet a függvényhívásoknál, 2ns a költségük, mert bár csak annyit kell csinálni, hogy a stack-ben a pointert át kell tenni, de az nem ingyenes. Tehát a performancia-költség is szivárgás.

A processzorban nincsenek olyan típusú változók, mint a C-ben, de függvények sem, de ezt elfedik előlünk a fordítók. Viszont ennek ára van, amit sebességcsökkenésben fizetünk meg
Itt arra gondoltam, hogy a processzorban van épp az aktuális parancs, valamint pár regiszter, amelyekben az operációs rendszer "bitmélységének" megfelelő nagyságú adatot lehet tárolni, például memóriacímeket. A processzor egy csőből szedi az adatokat. A processzor magától nem tudja megkülönböztetni az integer és a float számokat, és karakterláncokat sem kezel. Ezek már mind absztrakciók eredményei.

az a szivárgás, hogyha az absztrakciók mögött ki szeretnéd hozni a gépből a maximumot, akkor értened kell annak a működését
Mivel már túl messze vagyunk a vastól, lehetetlenség kihozni a maximumot egy általános processzorból. Kíváncsi lennék, hogy mekkora eltérés lenne a két eset között: 1, ha mondjuk van tízmilliárd utasításunk egymás után, és ezeket folyamatosan lapátoljuk be a processzorba, 2, ugyanennyi utasítás, de mondjuk minden századik egy feltételes ugrás.

Miből gondolod, hogy ennek plusz költsége kell legyen? Egyik hozott példám sem járt költséggel, sőt.
Az absztrakciókat meg kellett tervezni, meg kellett valósítani.

Ez kontextus nélkül irreleváns. Lassú? Optimalizálni kell. Nem? Akkor belefér.
Nem, nem, nem és nem! Ne implementációban gondolkodj! A for ciklushoz képest már ennyit szivárog a funkcionális megközelítés magas szintű nyelvekben. Ennyi a mondanivaló, nincs optimalizálás, példa volt. És mit nyertünk vele? Semmit. Rákérdeztem, hogy mire használják a funkcionális programozást, a válasz: adatfeldolgozásra, ami tipikus iteratív művelet.

Amire nem írtam semmit, azzal egyetértek. Te viszont a legfontosabbra nem válaszoltál (AMP).
143

Dehogynem, az oldal közepén

BlaZe · 2015. Nov. 16. (H), 20.09
Dehogynem, az oldal közepén lévő "All non-trivial abstractions, to some degree, are leaky." alatt lévő felsorolás első kettő és az ötödik pontja pont a költségekről szól.
De ez nem azt jelenti, hogy az absztrakció költséges :) Absztrakció nélkül is optimalizálni kell, hogy gyors legyen.

Itt, ugye az történik, hogy ha egymás után lévő értékeken iterálsz végig a memóriában, akkor a memóriamutatót csak eggyel kell minden esetben növelni, de ha sorok közt kell ugrálni, akkor mondjuk nem biztos, hogy benne lesz a cache-ben a következő érték, és lassú lesz.
És ez melyik absztrakció költsége? Assemblyben ez nem ugyanígy van szerinted? Ez sem az absztrakció költsége, hanem így működnek a cache-ek. Ami nincs cacheben, azt lassabb elérni. Én is pont ugyanezt a példát hoztam amúgy :)

Ugyanez a helyzet a függvényhívásoknál, 2ns a költségük, mert bár csak annyit kell csinálni, hogy a stack-ben a pointert át kell tenni, de az nem ingyenes. Tehát a performancia-költség is szivárgás.
Nem, ez a CPU overheadje, amikor branchelnie kell, majd onnan visszatérnie. Semmi köze a C függvény absztrakciójához.

A processzor magától nem tudja megkülönböztetni az integer és a float számokat, és karakterláncokat sem kezel. Ezek már mind absztrakciók eredményei
Viszont a processzornak vannak lebegőpontos utasításai, és a kódod arra fog fordulni. Itt ami történik, hogy a fordító a típusnak megfelelő specifikus utasításra fordít pl egy összeadást. Ennek semmi költsége. A string egy másik eset, ott nincs mivel összehasonlítani, hisz nem létezik CPU szinten, ezért ennek a költségéről beszélni értelmetlen.

Mivel már túl messze vagyunk a vastól, lehetetlenség kihozni a maximumot egy általános processzorból. Kíváncsi lennék, hogy mekkora eltérés lenne a két eset között: 1, ha mondjuk van tízmilliárd utasításunk egymás után, és ezeket folyamatosan lapátoljuk be a processzorba, 2, ugyanennyi utasítás, de mondjuk minden századik egy feltételes ugrás.
Az attól függ, hogy mennyire kiszámítható patternt követ a feltétel. Ha nagy szálékban megjósolható, akkor hasonló teljesítménye lesz, mint az elsőnek. A plusz feltétel utasításnak magának is van 1-2 ciklus költsége. A kérdés úgy korrekt, hogy ha mindkét esetben van feltétel, az egyikben mindig ugyanúgy kerül kiértékelésre, a másik esetben meg máshogy választ branchet a CPU. Ha ez a másik egy teljesen random eset, akkor az eltérés elég nagy lesz.

Az absztrakciókat meg kellett tervezni, meg kellett valósítani.
Semmivel nem több, mint belegányolni a függőséget a business logicba. Főleg a mai okos IDE-kkel. Viszont nyersz vele sokmindent.

A for ciklushoz képest már ennyit szivárog a funkcionális megközelítés magas szintű nyelvekben. Ennyi a mondanivaló, nincs optimalizálás, példa volt.
Hm, akkor írom másképp: ha az overheadje jelentéktelen a teljes futási időhöz képest, akkor nem mindegy? Ha jelentős, akkor kerülni kell, ki kell szedni. Pont EZ a premature optimisation amúgy, amit most írtál.

AMP: nem tudok rá érdemben reagálni, mert a böngők lelkivilágától már nagyon messze kerültem. Amire reagáltam, az a rengeteg antipattern, amit érvként, opcióként felhoztál.
144

Blaze, az itt adott első két

Hidvégi Gábor · 2016. Jan. 12. (K), 17.57
Blaze, az itt adott első két válaszod alapján nekem úgy tűnik, nem vagy teljesen tisztában az absztrakció szó jelentésével.

Maradjunk a processzoros példánál. A processzor egy rendkívül buta valami, ami bitsorozatokkal dolgozik. Van egy bejövő bitsorozat, ennek az egyik része adat, a másik része az utasítás. Elvégzi az utasításnak megfelelő műveletet, majd egy bitsort kiír a memóriába.

Az assembly programozás kényelmesebb a gépi kód írásánál, de még mindig elég nehézkes, ezért jött a C. C kódból előbb assemblyt állít elő a fordító, majd pedig gépi kódot.

És itt kezd el érdekes lenni a dolog: a processzor számára az, hogy függvény, nem mond semmit, ez egy absztrakció. Amikor egy C függvényt meghívunk, a stack-ben lefoglalunk számára egy adott mennyiségű memóriát, majd a végén ezt felszabadítjuk. Még akkor is, ha ez csak egy pointer arrébbtolásával jár, pár műveletnek le kell futnia, egy memóriacímet írni kell. Ezeket a C fordító teszi helyettünk be a kódba, és semmi ráhatásunk nincs.

Vegyük a következő kódot, aminek semmi értelme, de jól szemléltet:

function adder(int a) {
  int b = 5;

  a = a + b;
  return a;
}
int c = 1;

c = adder(c);
c = adder(c);
c = adder(c);
(c == 16)


És itt szivárog az absztrakció. Az absztrakció szó jelentése: tegyünk úgy, mintha valami így és így lenne. Jelen esetben úgy teszünk, mintha a függvényhívás a processzor számára egy triviális dolog lenne. Ennek az az ára, hogy számunkra láthatatlan műveleteket is el kell végeznie, amik eredménye, hogy ugyanazt a műveletsort függvény nélkül meghívva gyorsabban fut le a program:
int c = 1;
c = c + 5;
c = c + 5;
c = c + 5;


Tehát a számítógépben az absztrakciókért sebességgel fizetünk, ez a szivárgás. Egy bizonyos szint fölött viszont már a program komplexitása is nő, amit csak integrált fejlesztői környezettel lehet kezelni, lásd OOP.
145

Részletek

vbence · 2016. Jan. 12. (K), 23.55
A fenti példát egy mai fordító inlinene-ná fogja alkítani, vagyis gyakorlatilag a második kódrészleted fog már gépi kódra fordulni. Vagyis az sem, mert az szintén triviálisan optimalizálható. Ami meg aztán, mivel nem kezdesz semmit az ertedménnyel egy egyszerű return-re lesz optimalizálva.

Értem én, hogy ez csak egy példa, de ha megfelelő bonyolultságú, nem triviálisan optimalizálható példát írnál fel, akkor látszana az abcsztrakció előnye is, vaqgyis hogy karbantarható kódot eredményez.

Off: "A processzor egy rendkívül buta valami" - értem én, hogy szónoki túlzás, de egy mai átlagos cpu egy elképzelhetetlenül bonyolult valami. A fenti egyszerüsítés olyan, mintha a buborék rendezés algoritmusát ismerve elég képzettnek érezné magát valaki, hogy a quicksort műveletigényéről nyilatkozzon (mondván, a végén a rendezés az csak rendezés).
146

Lécci modd, hogy csak viccelsz!!!

pp · 2016. Jan. 13. (Sze), 00.26
C kódból előbb assemblyt állít elő a fordító, majd pedig gépi kódot.


Ebben Te egészen biztos vagy? (gondolom igen, a kérdés költői)

Nézzünk egy életszerű példát a Te semmi értelme kódod helyett:

nincs absztrakció:

c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
c = c + 5;
absztrakció, ami szivárog.

for(var i = 0; i < 15; i++) {
  c = c + 5;
}
És akkor ahogy Te mondanád (irónia on)
plusz egy változó!!!!! memória túlhasználat!!!!
rengeteg plusz elágazás és változóinkrementálás!!!! soronként!!! pluszegy!!!!

Arról ne is beszéljünk, hogy az a fránya fordító - ami nem tudod, hogy mit csinál (ezt be is bizonyítottad) - által generált kód nem egy memóriacímről fogja beolvasni minduntalan az i változó értékét, hanem az is lehet, hogy egy regiszterbe rakja és ott incrementálgatja!!! áááá mekkora szivárgásmár!!! hány processzorciklusidő elfecsérlésének elpazarlása már ez!!!! Arról ne is beszéljünk, ha a c változóval is így tesz esetleg!!!! félelmetes veszteségek az absztrakció szivárgásnövelésében!!!!

Jó tudni, hogy vannak komoly szakemberek, akik az első megoldást használják, ugye Gábor, Te mindig azt használod, mert az gyorsabb!? Kopipészt, igaz?!
(irónia off)

Tényleg csak hátrányai lennének az absztrakciónak?

Nyolcvanas években is már túlhaladott volt az az álláspont amit erőltetsz, nemhogy kétezertizenhatban.

Senki nem vitatja, hogy az első, absztrakció nélküli kód a gyorsabb, de nem hinném, hogy pusztán ezért erőltetni kéne azt.

pp
btw tudtad, hogy ha z80-ban a c+5 helyett c+500000-t írsz akkor tök más nem csak a gépi kód, hanem az assembly is? És itt vagy használsz absztrakciót (igen assemblyben is volt már), vagy egy karbantarthatatlan kódot állítasz elő, amiben senki nem látja át, hogy Te most 500000-el növeled egy változó értékét. Ja és kétlem a fentiek után, hogy Te gyorsabb kódot írnál mint azok aki a fordító kódját írták, vagy a C nyelvű implementációnál gyorsabb lesz amit Te valaha is összeraksz. De hajrá.
149

Miért? A mai, valódi

Há.Zé. · 2016. Jan. 13. (Sze), 08.50
Miért? A mai, valódi binárist előállító fordítók (szerinted?) hogy működnek?
Az utolsó, amit még elég közelről ismertem, az dokumentáltan úgy működött, hogy előbb assembly, és abból a bináris. Sajnos elég rég volt, később már COBOLT-t is olyat használtam, ami nem gépikódot gyártott, hanem valami interpreter számára állított elő köztes kódot.
150

Mi értelme lenne egy köztes

BlaZe · 2016. Jan. 14. (Cs), 00.29
Mi értelme lenne egy köztes assemblyt fordítani, ha az gyakorlatilag egy olvasható gépi kód? Ezért van, hogy assemblyben tudunk debugolni, vagy viszonylag egyszerűen megjeleníteni assembly nyelven a futtatott kódot. Legyen az c, vagy akár java is.

A fordító tipikusan csinál egy, vagy több object filet, ami(k)ből a linker egy futtatható verziót linkel össze. Ez mind bináris file.
151

Én még nem írtam

Há.Zé. · 2016. Jan. 14. (Cs), 05.22
Én még nem írtam fordítóprogramot, nem tudom, mi a konkrét oka, de az tény, hogy amit ilyen közelről megismertem az előbb assemblyre fordított és abból készített ú.n. object file-t, amiből aztán egy linkernek nevezett program rakta össze a végterméket, ami ma sem feltétlenül futtatható bináris ;)
(Közvetlenül nem futtatható mind. Pl. libek)
https://en.m.wikipedia.org/wiki/Multi-pass_compiler
Itt említenek valami hasonlót.
(Bocs a mobilos linkért)
152

+1

vbence · 2016. Jan. 14. (Cs), 10.04
#include <stdio.h>

main() {
    printf("Hello, world!\n");
    return 0;
}
gcc -S sample.c
	.file	"sample.c"
	.section	.rodata
.LC0:
	.string	"Hello, world!"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$.LC0, %edi
	call	puts
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Debian 4.9.2-10) 4.9.2"
	.section	.note.GNU-stack,"",@progbits
153

Ez most mire +1? :) Mert

Há.Zé. · 2016. Jan. 14. (Cs), 10.23
Ez most mire +1? :)
Mert önmagában a tény, hogy képes olvasható assembly kódot előállítani, lehet csak egy szolgáltatás. Ettől még lehet, hogy a fordítás egy menetben történik.
('sszameg! Már arra sem emlékszem, ki volt a szerzője annak a hetvenes-nyolcvanas években kiadott könyvnek, ami kifejezetten a fordítók működéséről szólt, felvázolva, hogy lehet 3. generációs compilert írni. :((( )
Régebben azt hiszem, részben a takarékosság miatt volt így: az assembler ott volt készen, csak a neki szánt kódot kellett előállítani, ami valamiért egyszerűbb volt, mint közvetlenül gépi kódra fordítani.
154

Gondolom optimizáció

vbence · 2016. Jan. 14. (Cs), 12.24
A gcc családban vannak más frontend nyelvek is, az asm optimizáció pedig platformspecifikus.

A neten egybehangzóan ehhez hasonló ábrákkal találkozik az ember.

Más fordítók, az LLVM például bytekódra fordít, amiből később lesz platformspecifikus kód (nem feltétlenül JIT-en keresztül, mint a java). Az iOS fejlesztőkészletben például ha jól tudom LLVM alapon történik a fordítás.
155

O.K. (amikor ezzel

Há.Zé. · 2016. Jan. 14. (Cs), 14.09
O.K. (amikor ezzel foglalkoztam, Assembly-t még nem volt divat fordítóval optimalizálni és hát platform se volt túl sok... IBM/Rnn gépek, amiken a mai mainframe-ek rendszerének őse futott ;) )
156

A GCC-ből indultam ki, aminek

Hidvégi Gábor · 2016. Jan. 27. (Sze), 20.55
A GCC-ből indultam ki, aminek a működési elvét vbence linkelte, ezek után el lehet dönteni, hogy ki nem ismeri a fordítókat. Egyébként is lényegtelen, hogy hány lépésben készül a forrásból gépi kód, a példán nem változtat.

Tényleg csak hátrányai lennének az absztrakciónak?
Én semmi ilyet nem állítottam. Csak annyit, hogy egyrészt minden absztrakció szivárog, másrészt az absztrakciók ára a számítógépeken sebességvesztéssel jár, valamint a programon belüli absztrakciók a program komplexitásának a növelésével. Ez utóbbi több hibát és megnövekedett fejlesztési és karbantartási időket hoz. Ezekből következik, hogy az absztrakciók számát a minimumon kell tartani, azaz minél egyszerűbb egy program, annál jobb.
157

Off

T.G · 2016. Jan. 27. (Sze), 21.06
Szerinted a Weblabor fórumain eddig hányszor írtad le, hogy „az absztrakciók számát a minimumon kell tartani” és szerinted hány embert tudtál erről meggyőzni? Mivel számomra úgy tűnik, hogy tényleg baromi sok energiát fektetsz ebbe a „prófétaságba”, gondolom már te is gondolkodtál a hatékonyságodon. Megkérdezhetem, hogy szerinted ez a „küldetés” jelenlegi állapotában sikeresnek mondható-e?
159

Igen

Hidvégi Gábor · 2016. Jan. 27. (Sze), 21.35
Változást a fejekben csak kitartó munkával lehet elérni. Én elmondom tízszer, hogy "az absztrakciók számát a minimumon kell tartani", mert ez az igazság, de ha mindenhol máshol ennek az ellenkezőjét olvassák, akkor folytatni kell az ismétlést.
161

engem meggyőztél

solkprog · 2016. Jan. 27. (Sze), 22.42
köszönöm, engem meggyőztél.

Sikerült annyiszor mondanod hogy elhiszem neked hogy nem te tévedsz, hanem “mindenki”, gyakorlatilag a komplett szakma, többek között én is.
Mostantól félredobom az összes tapasztalatom, és elhiszem neked hogy "az absztrakciók számát a minimumon kell tartani”. Én is tévedtem mikor a saját méréseim, és tapasztalatom szerint nem erre jutottam. Innentől visszadobom a code review-kat ha valaki OOP-ben írta a kódját. Sőt lehet hogy írok rá egy script-et hogy ha szerepel a pull request kódjában a "class" szó akkor rögtön visszadobja a request-et.
Köszönöm a kitartó fáradságos munkádat, én megtértem.

(ez az "ez az igazságra" mondatodra volt válasz)
163

Egymilliárd légy

Hidvégi Gábor · 2016. Jan. 28. (Cs), 11.39
De miért az egymilliárd légy nem tévedhet elvén gondolkozol, dolgozol? Még szerencse, hogy nem a középkorban élünk, mert akkor, ha azt állítottam volna, hogy a Föld kerek (mint azt már az ókori görögök bebizonyították), akkor elevenen égettek volna el.

Én nem azt mondom, hogy dobjuk ki azonnal az OOP-t, a takarítást kicsiben kell kezdeni. Erre kiváló példa a getter és setter függvények esete, amikről elég hamar bebizonyosodott, hogy sok hasznuk nincs, cserébe növelik mind a kód, mind pedig a kódértelmező kompexitását. Természetesen ezeket nem kötelező használni, de ettől függetlenül a kódértelmezőben ott maradnak.

Szép lassan így meg lehet szabadulni a fölöslegtől. A fenti gondolatmenetet folytatva érdemes felülvizsgálni, van-e értelme a publikus adattagoknak? Ha például van egy objektumunk, aminek a belső adatait csak függvényeken keresztül érhetjük el, akkor nagyon egyszerűen valósíthatjuk meg az elérési jogosultságaikat. Így a későbbiekben fel sem merülnek senkiben, hogy ha vannak publikus adattagok, azoknál bevezessünk-e olyan flag-eket, amivel csak olvashatóvá lehet őket tenni. Ismét megszabadulhatunk egy absztrakciótól.

Nem csak a fordítóprogramok egyszerűsödnének és gyorsulnának (valamint PHP esetében a futás is) a fentiekkel, hanem az adott nyelv könnyebben lenne megtanulható.

Ha figyeled a trendeket, szép lassan jön be például a funkcionális felfogás, így várható, hogy az OOP mint paradigma a háttérbe fog szorulni. Az más kérdés, hogy ettől nekünk jobb lesz-e, hisz racionális érveket nem látok a változások mögött.

Ez az igazság : )
170

De miért az egymilliárd légy

bamegakapa · 2016. Jan. 28. (Cs), 14.24
De miért az egymilliárd légy nem tévedhet elvén gondolkozol, dolgozol? Még szerencse, hogy nem a középkorban élünk, mert akkor, ha azt állítottam volna, hogy a Föld kerek (mint azt már az ókori görögök bebizonyították), akkor elevenen égettek volna el.

Hagyjuk már ezt az ökörséget. Azért mert prédikálsz valami ostobaságot, ami nem egyezik a többség véleményével, még rohadtul nem leszel hirtelen Galilei... Ha megégetnek, az azért lesz, mert nem bírtak már elviselni.
172

De miért az egymilliárd légy

inf3rno · 2016. Jan. 28. (Cs), 23.36
De miért az egymilliárd légy nem tévedhet elvén gondolkozol, dolgozol?


Az "egymilliárd légy" analógiája laikusokra vonatkozik, itt meg szakemberekről van szó...
160

"az absztrakciók számát a

inf3rno · 2016. Jan. 27. (Sze), 22.42
"az absztrakciók számát a minimumon kell tartani" = gépi kódban kell programozni, mert minden ami fölötte van (programnyelvek, stb.) absztrakció

Nekem ez még mindig sántít valahol, bár kezdek én is megtérni. xD
162

Arra gondoltál már, hogy

Joó Ádám · 2016. Jan. 27. (Sze), 22.48
Arra gondoltál már, hogy vajon ez a leghatékonyabb módja a célod elérésének? Személy szerint sok dologról vagyok hasonló véleménnyel, mint te, de nemhogy nem szólok hozzá melletted, már saját felindulásból sem kockáztatok kritikát megfogalmazni bizonyos iparági tendenciákkal kapcsolatban, mert a hosszú évek óta folytatott hadjáratod eredménye az, hogy a kritika maga vesztette el a hitelét ezen a fórumon. Szerintem nem vagyok egyedül ezzel.
166

Személy szerint sok dologról

Hidvégi Gábor · 2016. Jan. 28. (Cs), 12.31
Személy szerint sok dologról vagyok hasonló véleménnyel, mint te, de nemhogy nem szólok hozzá melletted
Csak magaddal tolsz ki, ha hagyod, hogy a dolgok ne úgy menjenek, ahogy szerinted a legjobb. Egyébként sem értek egyet azzal, hogy a kritika hitelét vesztette a fórumon.
171

Gábor, hidd el, tényleg az

Há.Zé. · 2016. Jan. 28. (Cs), 15.09
Gábor, hidd el, tényleg az van amit Ádám ír. Sok dolog van, amiben egyetértünk veled, de ez a Don Quijote szereped nagyon nem tesz jót a kommunikációnak.
169

Egy korábbi beszélgetésben

bamegakapa · 2016. Jan. 28. (Cs), 14.20
Egy korábbi beszélgetésben fel is hoztuk Gábornak, hogy rohadtul kontraproduktív, amit csinál.

Nem vagy egyedül, én is így vagyok ezzel. És sokan mások is, akik már nem fognak ide visszajönni.
147

Sokakban él az a tévképzet,

MadBence · 2016. Jan. 13. (Sze), 00.52
Sokakban él az a tévképzet, miszerint a program, amit futtatni szeretnénk az az, amit megírtunk.
/* inline.c */
int add(int a) {
  int b = 5;
  a = a + b;
  return a;
}

int main() {
  return add(add(add(5)));
}
Lefordítom: $ gcc inline.c -S -masm=intel, mutatom a lényeget:
main:
	push	rbp
	mov	rbp, rsp
	mov	edi, 5
	call	add
	mov	edi, eax
	call	add
	mov	edi, eax
	call	add
	pop	rbp
	ret
Lefordítom rendesen: $ gcc inline.c -O2 -S -masm=intel, mutatom a lényeget:
main:
	mov	eax, 20
	ret
És itt szivárog az absztrakció. Az absztrakció szó jelentése: tegyünk úgy, mintha valami így és így lenne. Jelen esetben úgy teszünk, mintha a függvényhívás a processzor számára egy triviális dolog lenne.
Speciel a processzornak a függvényhívás egy triviális dolog, de egyébként jogos: az absztrakció nincs mindig ingyen. És ezzel szerintem mindenki (minden valamire való szakmabeli) tisztában van. Viszont sokkal kényelmesebb (és produktívabb) egy select * from table parancsot lefuttatni az adatbázison, mint ha én ott helyben kifejteném az egészet egészen addig, amíg már ott nem tartok, hogy milyen feszültségekkel kell a diszk olvasófejét vezérelni ahhoz, hogy jó biteket olvassak be.
148

Blaze, az itt adott első két

BlaZe · 2016. Jan. 13. (Sze), 01.16
Blaze, az itt adott első két válaszod alapján nekem úgy tűnik, nem vagy teljesen tisztában az absztrakció szó jelentésével.

[...]

Az absztrakció szó jelentése: tegyünk úgy, mintha valami így és így lenne.

Tudom, hogy a mai keresők használhatatlanok, de erre pl elég hamar elég jó találatokat kapsz. Az absztrakció nagyon nem ezt jelenti. Sőt, még annál is jobban nem ezt jelenti.

A többire már reagáltak érdemben. Értem a példát, bár több helyen is hibás, ahogy arra rá is mutattak. Azt mondjuk nem értem, hogy ezt miért írod nekem.

Tehát a számítógépben az absztrakciókért sebességgel fizetünk
Mellette, ellene is tudok példát hozni.

...ez a szivárgás
Tévedés. Ebben a példában a szivárgás az, hogy ismerned kell az absztrakció mögötti implementációt (pl cache méret), ha optimalizálni akarsz. Az, hogy egy műveletnek költsége van, az nem absztrakció szivárgás :) Minden művelet absztrakció, az összeadás is.

Egy bizonyos szint fölött viszont már a program komplexitása is nő, amit csak integrált fejlesztői környezettel lehet kezelni, lásd OOP.
Nem értem az összefüggéseket ebben a mondatban. IDE nélkül is lehet bármilyen programot fejleszteni. Csak lassabb. Arra való az IDE, hogy hatékony legyél. Akár OOP, akár procedurális, funkcionális. Akinek a hatékonyság nem fontos, az ne használjon IDE-t.
158

Absztrakció (Wikipédia) Az

Hidvégi Gábor · 2016. Jan. 27. (Sze), 21.27
Absztrakció (Wikipédia)
Az absztrakció szót hétköznapi használatában szokásosan elvonatkoztatásnak fordítják, és a lényeges és lényegtelen tulajdonságok elválasztását, a lényeges tulajdonságok kiemelését és a lényegtelen tulajdonságok figyelmen kívül hagyását értik rajta.


Absztrakció (Hidvégi Gábor): Az absztrakció szó jelentése: tegyünk úgy, mintha valami így és így lenne.

A kettő ekvivalens.

Az absztrakció nagyon nem ezt jelenti. Sőt, még annál is jobban nem ezt jelenti.
Akkor mit?

A többire már reagáltak érdemben. Értem a példát, bár több helyen is hibás, ahogy arra rá is mutattak. Azt mondjuk nem értem, hogy ezt miért írod nekem.
Igen, pp is leírta: "Senki nem vitatja, hogy az első, absztrakció nélküli kód a gyorsabb".

Azért írom neked, mert ezt válaszoltad nekem:
De egy szót nem mond arról, hogy azért leaky egy absztrakció, mert költsége van. És simán lehet, hogy nincs is.
Számítógépen az adott programnyelv fölötti (vagy alatti, ki honnan nézi) minden absztrakcióért sebességgel fizetünk.

Az, hogy egy műveletnek költsége van, az nem absztrakció szivárgás :)
Természetesen minden műveletnek van költsége, csak nem mindegy, hogy mennyi.

IDE nélkül is lehet bármilyen programot fejleszteni. Csak lassabb. Arra való az IDE, hogy hatékony legyél.
Azért lassabb a fejlesztés, mert túl magas absztrakciós szintre jutottunk. Nem elég, hogy OOP, és minden szét van szórva ezer kis osztályba, bejönnek újabb rétegek, mint például a Dependency Inversion és társaik. Ezt a komplexitást az emberek már nem tudják kezelni, és jobb nem lesz.

Vissza az 1-es hozzászóláshoz: a Google kivett egy absztrakciós réteget (JS), hogy egyszerűbbé tegye a fejlesztést és gyorsabbá a futást. Ezt kellett bizonyítani.
164

a Google kivett egy

Endyl · 2016. Jan. 28. (Cs), 11.48
a Google kivett egy absztrakciós réteget (JS), hogy egyszerűbbé tegye a fejlesztést és gyorsabbá a futást. Ezt kellett bizonyítani.

Nem vették ki a js-t, csak annyit mondtak (többek között), hogy ők jobb js kódot tudnak írni, mint az átlag webfejlesztő (bár erre ugyanannyi a garancia, mint bármilyen más nyílt forrású projektnél). Ez a legideálisabb esetben is csak ugyanannyi "absztrakciós réteget" jelent, mint eddig. De inkább többet, mert az általuk implementált funkcionalitás is egy absztrakció, amit a fejlesztőnek meg kell tanulnia használni, és kezdődhet is a szivárgás :). A rettegett, harmadik féltől való függésről meg ne is beszéljünk.
165

A lényegen nem változtat,

Hidvégi Gábor · 2016. Jan. 28. (Cs), 12.28
A lényegen nem változtat, amit leírtál. A fejlesztőknek korlátozott elemkészlettel lehet gazdálkodniuk, amik előre meghatározott módon működnek. Hogy ezt a háttérben a Google JS-sel vagy natív kóddal oldja meg, nem számít, mert az AMP-os oldalakon a fejlesztők scripteket nem írhatnak.

Nyilván így is fog szivárogni, de a mostanihoz mérten elhanyagolható módon.
167

Nyilván így is fog

Endyl · 2016. Jan. 28. (Cs), 12.49
Nyilván így is fog szivárogni, de a mostanihoz mérten elhanyagolható módon.

Én ebben nem lennék annyira biztos, pláne, ha igaz egy korábbi blogmarkodban lévő részlet:
Google has rolled out a competitor to Instant Articles, which it calls Accelerated Mobile Pages. AMP is a special subset of HTML designed to be fast on mobile devices.

Why not just serve regular HTML without stuffing it full of useless crap? The question is left unanswered.

The AMP project is ostentatiously open source, and all kinds of publishers have signed on. Out of an abundance of love for the mobile web, Google has volunteered to run the infrastructure, especially the user tracking parts of it.

Jeremy Keith pointed out to me that the page describing AMP is technically infinite in size. If you open it in Chrome, it will keep downloading the same 3.4 megabyte carousel video forever.

If you open it in Safari, where the carousel is broken, the page still manages to fill 4 megabytes.


Valamint:
Hogy ezt a háttérben a Google JS-sel vagy natív kóddal oldja meg, nem számít

Akkor, ha a Google absztrahál, az jó, gyorsít, és alig szivárog, ha más, akkor már egy C függvény is vérlázító szivárgás?

Valamint az AMP-s oldalakon is írnak szkripteket fejlesztők, csak nem azok, akik az adott oldalt fejlesztik, hanem akik az AMP-t.
168

Félreérted, a Google

Hidvégi Gábor · 2016. Jan. 28. (Cs), 13.33
Félreérted, a Google programozói ugyanolyan átlagosak, mint a legtöbb fejlesztő a Földön, ugyanolyan gyatra kódokat készítenek, vagy rosszabbat, lásd Angular.

Teljesen más a két helyzet. Most egy böngészőben egy webfejlesztő azt csinál, amit akar: ezer forrásból tölt be adatokat, épp aktuális keretrendszereket használ, amik ugyancsak nem a gyorsaságukról híresek, tehát bármikor fejreállíthatja a rendszert, és ezt meg is teszi a legtöbb esetben, mert teljes a szabadsága.

(Az új fejlesztések, mint pl. a HTTP 2.0 vagy az, hogy a scriptek több processzormagon fussanak, csak időlegesen oldják meg a sebességproblémákat, rövid időn belül, miután elterjedtek, 100%-ig ki fogják használni a fejlesztők ezeket az erőforrásokat.)

Az AMP oldalakon ezzel szemben korlátozott a fejlesztők szabadsága, használhatnak előre elkészített elemeket, megszabott eseményekkel. Nyilván telerakhatod reklámokkal, ami ugyanúgy megöli a gépet, de erre kicsi az esély.
173

És minek ehhez AMP?

inf3rno · 2016. Jan. 28. (Cs), 23.41
És minek ehhez AMP? Mondhatjuk azt, hogy ezentúl a mobil oldalakon csak bootstrap-et használunk, aztán ennyi. Ehhez felesleges feltalálni a spanyolviaszt.
174

Mutass egy, azaz 1 darab

Hidvégi Gábor · 2016. Jan. 29. (P), 14.42
Mutass egy, azaz 1 darab embert a hétmilliárdból, aki megrendelői kérésre nem tesz be egy kis javascriptet!
175

És itt kezdődik a szivárgó

inf3rno · 2016. Jan. 30. (Szo), 00.19
És itt kezdődik a szivárgó absztrakció problémája, nevezetesen, hogy az AMP, bootstrap, stb. nem fed le minden megrendelői igényt. És ugye a megrendelő fizet nekünk, nem a google, hogy használjuk az AMP-t. Legalábbis tegnap még így volt...
176

Mindig szükségesek voltak

Hidvégi Gábor · 2016. Jan. 30. (Szo), 11.08
Mindig szükségesek voltak ahhoz korlátok, hogy az ember nagyot alkosson. Például nem értem, egy caroussel galériához miért szükséges egy sornyi javascript is, amikor natív HTML-ben meg lehet írni erőlködés nélkül.
138

Szóval ez, hogy minden

inf3rno · 2015. Nov. 16. (H), 17.18
Szóval ez, hogy minden függőséget absztrakciók mögé rejtünk, anélkül, hogy ismernénk a jövőt, számomra kimeríti a premature optimization fogalmát.


A (premature) optimization tudtommal arra irányul, hogy gyorsabb legyen a kód, absztrakciók bevezetésével viszont biztosan lassabb lesz, és amit te javasolsz, hogy a lehető legkevesebb absztrakciót használjunk annak érdekében, hogy gyors legyen a kód számít premature optimization-nek. Szerintem inkább overengineering-re gondoltál a felesleges absztrakciók bevezetésével kapcsolatban, ami valóban előfordulhat.