A szkriptelés kinyírásával gyorsítaná fel a mobil webet a Google
A HTML egy optimalizált részhalmazára és szabványos widgetekre támaszkodna az új iparági sztenderd
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
chikk:
XAML bemutatása
Hojtsy Gábor:
Két éves a PHPinfo - interjú a készítőkkel
Bártházi András:
CSS alapjai VII.
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | 1 | 2 | 3 | 4 | 5 |
Nem fog tetszeni
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!
Zsákutca
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).
A főnököm szokta mondani,
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.
Szerintem pedig szinte minden
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.
A project management fogja
A sales munkájának mi köze az
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?
Absztrakciók
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.
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.
Tehát
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).
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.
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.
+1 úgy ahogy van
Látom, nagyon a szívedre
Nem vettem a szívemre semmit
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ó.
Természetesen jó dolog amit
Tehát ha egy szoftver (legyen
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.
A mobilomban több ram van, és
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.
Szvsz. csak azt nem érti meg,
Ettől még persze vannak
Általánosságban beszéltünk,
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.
Szerintem irreleváns
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.
Ezt most mire válaszul írtad?
Arra válaszul írtam, hogy
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?
Nincs (bár lehetne) jobb
Betting on html5 was a mistake
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 (-:
Szerintem HG nem erre
Köszi amúgy a linkeket.
Ha csak a vasat nézzük és a
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ő.
Moore-törvénynek nevezzük azt
Na ne mondd már, hogy a user
Direkt kiemeltem az
Wikipedia szerint ez az
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.
Gazdasági vonzat
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 [...]
Nemrég láttam egy filmet
Ezekből a kvantum processzorokból meg foton alapú processzorokból szerinted esélyes, hogy egy-két évtizeden belül valami lesz?
Pont a múlt héten
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.
Szerintem a Moore törvényé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...
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.
Pont most futottam bele egy
Friss írás a hwsw-n a
ráadásul egy jóideje már csak
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.
A szoftver olyan, mint a gáz,
Hát ahogy vesszük. Egy idő
Ez köszönhető annak, hogy a
Igazából akkor sem, mert a
É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.
Fejlődés
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.
Egyetértek, és azt hiszem ez
Tanulság? Egyszerű szoftvert
A külső függőségeket el lehet
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.
Időről időre át szoktam
Tudnál konkrét példát
Ezt el tudnád adni olyannak,
Ezt csinálom nyolc éve,
Leszámítva olyan apróságokat
Érdekes módon ezek az általad
Ezt csak azért látod így,
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.
Ezzel nem értek egyet, amit
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.
Igen, ez pont egy olyan
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...
És ennek a váltásnak az
És ennek a váltásnak az
Hm, visszaolvasva nem igazán
Hát, tipikusan nem ezek a cégek generálják az IT megrendeléseket :)
Már nem, de voltam. Kis
+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.
És akkor itt jutunk el a
Vagy mert esetleg nincs
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.
eheh... már megint ez az általánosítás, ráadásul így... eheh
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
Feltételezem, hogy a Gauss
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:
Egy pillanatig sem vitatnám,
É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
Szerintem több ponton is
És ennek a váltásnak az
Speed is a feature!
Most akkor újra lehet írni dolgokat, vagy sem?
vö.
plusz
Neki újra lehet, de nekünk
Nem értem a kérdésed és nem
A hozzám intézett kérdésedben
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.
Én sehol sem kételkedtem,
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.
"De ha valaki az
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
Úgy tűnik, valamit
A számomra fölösleges absztrakciók például az objektumok, de ezt már számtalanszor kifejtettem.
(Blaze-zel valamelyik
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...
Majd ha lesz időm, lemérem,
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.
~ 2 ns
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.
Ez az egész függvényesdi csak
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ó.
A fenti commentem arra volt
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.
A fenti commentem arra volt
akarmi.forEach(function() {formának.forciklus, mint a.forEach.Ez is nyilvánvaló. Az egész
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.
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.
Az egész függvényesdivel –
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.
Gyártottam valami fapados
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.
Úgy tűnik, valamit Te
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
Valamivel úgy tudok
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?
Nem tudom lejött e, de az
The law of leaky abstractions
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á.
Azt viszont nem értem, hogy
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.
Már ezer példában vázoltam,
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.
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.
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.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.
Információt már egy fokkal
A szívemből szóltál.
Ez csak arra bizonyíték,
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.
Ha így van, ez épp elég indok
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.
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.
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.
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.
Ez csak azt a részt támasztja alá (nem reprezentatív felméréssel), hogy terjednek, azt nem, hogy miért.
Linkek
További problémák: nem lehet mérni az FPS-t, nincs hozzáférés a GPU-hoz, a görgetés macerás.
A végére pedig a legjobb: sem a mobil hardver, sem pedig a böngészők nem igazán fejlődnek évek óta (hogy négy vagy tizenkét magod van, a weben nem oszt, nem szoroz).
Köszi a linkeket. Gyorsan
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.
régiek
- 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.
Releváns
- 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.
Na ez így már korrekt
Miután elértük, hogy a
A mi szemszögünkből mindenképp, senki sem szeret kétszer dolgozni.
Kicsit mókásnak találom a
Kérdés, mi lesz a vége, ha
Két pillantás után ez az
Pontosan ez jutott eszembe.
Hacsak
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.
Mondjuk az alapszkripteket és
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
betöltés, renderelés
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.
Nahát, nem gondoltam, hogy
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.Hát ha tehetnék, akkor
Miért?
Szerintem nem fogják más
A web a jelenlegi formájában
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.
A jQuery-féle egy gyűrű mind
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.
Az alacsony belépési küszöb
Én az MDN-t használom, nincs
A web a jelenlegi formájában
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.
Az általad írt példában is az
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.
Sokkal többről van szó, de ma
Tehát az Egy gyűrű rossz,
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.
Nekem nincs bajom sem az
Sokszor elgondolkodom, hogy
Korábban ugyanis ezt írtam (te is válaszoltál rá, tehát biztosan olvastad):
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.
Aham, így már tiszta sor. Az
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.
A DOM-mal ebből a szempontból
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.
Mindenféle döntési helyzet
É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.
Az építészeknél, orvosoknál
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?
Szerintem az embereket
Okosítani?
Okosítani
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.
Nem állítottam sehol, hogy a
DOM csomópontok
Szerintem a node-okat
node jelentése. Hívhatjuk
Nem lényegtelen, mert a
XPath segítségével azok is
Videó
Ez a videó semmi lényegi
Amíg nincs újabb érdemi érv, részemről ez a téma le van zárva.
A NodeList.js-el én is
+1, eleve ott indul, hogy
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.
Ha ez bejön...
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.
Nem vagy egyedül. Annyi
Nem akarok kontárkodni...
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
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...
Elvileg a NodeList pont
Válasz a 109-re
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?
Válasz a 130-ra
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?
Blaze gépén C-ben egy
Egyetértek, de
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.
Pedig napnál is világosabb,
É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.
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?
Válasz a 132-re
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:
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.
Srácok (Blaze és inf3rno),
Elméletben minden
Elméletben minden
A Google szerdán egy új
Amit ők csinálnak ugyanúgy js-t használ.
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.
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! :-)
De egy szót nem mond arról,
Hogy egyértelmű legyen:
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.
Amire nem írtam semmit, azzal egyetértek. Te viszont a legfontosabbra nem válaszoltál (AMP).
Dehogynem, az oldal közepén
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.
Blaze, az itt adott első két
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:
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:
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.
Részletek
É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).
Lécci modd, hogy csak viccelsz!!!
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ó:
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á.
Miért? A mai, valódi
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.
Mi értelme lenne egy köztes
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.
Én még nem írtam
(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)
+1
Ez most mire +1? :) Mert
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.
Gondolom optimizáció
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.
O.K. (amikor ezzel
A GCC-ből indultam ki, aminek
Off
Igen
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)
Egymilliárd légy
É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 : )
De miért az egymilliárd légy
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.
De miért az egymilliárd légy
Az "egymilliárd légy" analógiája laikusokra vonatkozik, itt meg szakemberekről van szó...
"az absztrakciók számát a
Nekem ez még mindig sántít valahol, bár kezdek én is megtérni. xD
Arra gondoltál már, hogy
Személy szerint sok dologról
Gábor, hidd el, tényleg az
Egy korábbi beszélgetésben
Nem vagy egyedül, én is így vagyok ezzel. És sokan mások is, akik már nem fognak ide visszajönni.
Sokakban él az a tévképzet,
$ gcc inline.c -S -masm=intel, mutatom a lényeget:$ gcc inline.c -O2 -S -masm=intel, mutatom a lényeget:select * from tableparancsot 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.Blaze, az itt adott első két
[...]
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.
Absztrakció (Wikipédia) Az
Absztrakció (Hidvégi Gábor): Az absztrakció szó jelentése: tegyünk úgy, mintha valami így és így lenne.
A kettő ekvivalens.
Azért írom neked, mert ezt válaszoltad nekem:
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.
a Google kivett egy
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.
A lényegen nem változtat,
Nyilván így is fog szivárogni, de a mostanihoz mérten elhanyagolható módon.
Nyilván így is fog
Én ebben nem lennék annyira biztos, pláne, ha igaz egy korábbi blogmarkodban lévő részlet:
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:
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.
Félreérted, a Google
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.
És minek ehhez AMP?
Mutass egy, azaz 1 darab
És itt kezdődik a szivárgó
Mindig szükségesek voltak
Szóval ez, hogy minden
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.