“15 éve programozom. A közelmúltban kezdett igazán megfogni iparágunkban a hatékonyság, az egyszerűség és a kiválóság iránti törődés hiánya, egészen addig a pontig, hogy lehangolódtam a saját karrierem és általában az IT miatt.
A modern autók, mondjuk a vita kedvéért, 98%-ában működnek annak, ami a jelenlegi motorkonstrukcióval fizikailag lehetséges. A modern épületek éppen annyi anyagot használnak fel, hogy az adott körülmények között teljesítsék funkciójukat és biztonságosak maradjanak. Minden repülö konvergál az optimális mérethez/formához/terheléshez, és alapvetően ugyanúgy néz ki.
Csak szoftveresen elfogadható, ha egy program a lehetséges teljesítmény 1%-án vagy akár 0,01%-án fut. Úgy tűnik, mindenki rendben van vele. Az emberek gyakran még büszkék is arra, hogy mennyire nem hatékony, „miért aggódjunk, a számítógépek elég gyorsak”:
*@tveastman: Van egy Python programom, amit minden nap futtatok, 1,5 másodpercig tart. Hat órát töltöttem az újraírással Rust-ban, most 0,06 másodperc. Ez a hatékonyságnövekedés azt jelenti, hogy 41 év, 24 nap múlva behozom az időmet amit programozással töltöttem :-)*
Valószínűleg hallottad már ezt a mantrát: „A programozói idő drágább, mint a számítógép ideje.” Ez alapvetően azt jelenti, hogy soha nem látott mértékben pazaroljuk el a számítógépeket. Veszel-e autót, ha 100 litert eszik 100 kilométeren? Mit szólnál 1000 literhez? A számítógépekkel mindig ezt tesszük.
**Minden elviselhetetlenül lassú**
Nézz körül: hordozható számítógépeink ezerszer erősebbek, mint azok, amelyek az embert a Holdra vitték. Ennek ellenére minden második weboldal küzd a zökkenőmentes, 60 képkocka/mp sebességű görgetés fenntartásával a legújabb, csúcskategóriás MacBook Pro. Kényelmesen játszhatok, nézhetek 4K videókat, de nem görgethetek weboldalakat? Ez hogy van rendben?
A Google Inbox, a Google által írt webalkalmazás, amely a Google által kreált Chrome böngészőben fut, 13 másodpercet vesz igénybe a közepes méretű e-mailek megnyitásához.
A tartalom megjelenítése helyett üres fehér dobozokat is animál, mert csak így lehet bármit is animálni egy weboldalon megfelelő teljesítménnyel. Nem, a tisztességes nem azt jelenti, hogy 60 képkocka/másodperc, hanem „olyan gyors, amennyire ez a weboldal csak tud”. Kíváncsi vagyok a webes közösség válaszára, amikor a 120 Hz-es kijelzők általánossá válnak. Ez a szar már most alig éri el a 60 Hz-et.
A Windows 10 frissítése 30 percet vesz igénybe . Mit csinálhat ilyen sokáig? Ennyi idő elég ahhoz, hogy teljesen formázzam az SSD-meghajtómat, letöltsek egy friss buildet, és 5-ször egymás után telepítsem.
*Pavel Fatin: A szerkesztőben való gépelés viszonylag egyszerű folyamat, így még a 286 PC is elég gördülékeny gépelési élményt tudott nyújtani.*
A modern szövegszerkesztők nagyobb késleltetéssel rendelkeznek, mint a 42 éves E-Mac. Szövegszerkesztők! Mi lehet egyszerűbb? Minden egyes billentyűleütésnél csak egy apró téglalap alakú területet kell frissítenie, és a modern szövegszerkesztők ezt nem tudják 16 ms alatt megtenni. Nagyon sok idő. NAGYON. Egy 3D-s játék képes az egész képernyőt több százezer (!!!) poligonnal megtölteni ugyanazon 16 ms alatt, valamint feldolgozni a bemenetet, újraszámolni a világot és dinamikusan betölteni/kirakni az erőforrásokat. Hogy-hogy?
Általános tendencia, hogy nem kapunk gyorsabb szoftvereket több funkcióval. Egyre gyorsabb hardvert kapunk, amely lassabban fut, ugyanazokkal a funkciókkal. Minden a lehetséges sebesség alatt működik. Gondolkozott már azon, hogy miért van szüksége telefonjának 30-60 másodpercre a rendszerindításhoz? Miért nem indul el mondjuk egy másodperc alatt? Ennek nincsenek fizikai korlátai. Ezt szívesen látnám. Szívesen látnám, ha elérnék és feltárnák a határokat, és az általunk elért teljesítmény minden darabját értelmes módon hasznosítanák valami értelmes dologra.
**Minden HATTTTTTALMAS**
És akkor van puffadás. A webalkalmazások akár 10-szer gyorsabban is megnyílhatnak, ha egyszerűen letiltják az összes hirdetést. A Google arra kér mindenkit, hogy ne löje magát lábon az AMP kezdeményezéssel – egy technológiai megoldás egy olyan problémára, amelyhez nincs szükség semmiféle technológiára, csak egy kis józan észre. Ha eltávolítjuk a “dagadást”, az internet őrült gyorssá válik. Mennyire kell okosnak lenni, hogy ezt megértsd?
Egy alkalmazás nélküli Android rendszer csaknem 6 GB-ot foglal el. Gondolj cask bele egy pillanatra, milyen obszcén HATALMAS ez a szám. Mi van ott, HD filmek? Azt hiszem, ez alapvetően kód: kernel, illesztőprogramok. Természetesen néhány karakterlánc és erőforrás is, de ezek nem lehetnek nagyok. Szóval, hány driver kell egy telefonhoz?
A Windows 95 30 MB volt. Ma ennél nehezebb weboldalaink vannak! A Windows 10 4 GB-os, ami 133-szor akkora. De vajon 133-szor jobb? Úgy értem, funkcionálisan alapvetően ugyanazok. Igen, van Cortana, de kétlem, hogy 3970 MB-ot vesz igénybe. De bármi legyen is a Windows 10, az Android valóban ennek 150%-a?
A Google billentyűzetalkalmazása rutinszerűen 150 MB-ot fogyaszt. Valóban ötször bonyolultabb egy olyan alkalmazás, amely 30 billentyűt rajzol egy képernyőre, mint az egész Windows 95? A Google alkalmazás, amely alapvetően csak egy csomag a Google Internetes Keresőhöz, 350 MB! Google Play-szolgáltatások, amelyeket nem használok (nem veszek ott könyveket, zenéket vagy videókat) – 300 MB, amelyek csak ott vannak, és nem tudom törölni.
Mindez körülbelül 1 GB-ot hagy a fényképeim számára, miután telepítettem az összes alapvető (közösségi, chat-, térkép-, taxi-, banki stb.) alkalmazást. És ez játék és zene nélkül! Emlékszel azokra az időkre, amikor egy operációs rendszer, az alkalmazások és az összes adat elfért egy hajlékonylemezen?
Az asztali ToDo (emlékeztetők) alkalmazás valószínűleg Electron nyelven íródott, így van benne egy felhasználói felület az Xbox 360 vezérlőhöz, képes 3D grafikát renderelni, hangot lejátszani és fényképeket készíteni webkamerájával.
Az egyszerű szöveges csevegés betöltési sebességéről és memóriafogyasztásáról híres. Igen, a Slacket valóban erőforrás-igényes alkalmazásnak kell tekinteni. Úgy értem, chatroom és barebone szövegszerkesztő, ezek állítólag a két kevésbé igényes alkalmazás az egész világon. Üdvözöljük 2018-ban.
Legalább működik, mondhatni. Nos, a nagyobb nem azt jelenti, hogy jobb. A nagyobb azt jelenti, hogy valaki elvesztette az irányítást. A nagyobb azt jelenti, hogy nem tudjuk, mi történik. A nagyobb komplexitási adót, teljesítményadót, megbízhatósági adót jelent. Ez nem norma, és nem is szabad normává válnia. A túlsúlyos alkalmazásoknak piros zászlót kell jelenteniük. Azt kell jelenteniük, hogy fuss messzire tőlem.
**Minden rohad**
Egy 16 GB-os Android telefon 3 éve teljesen rendben volt. Manapság az Android 8.1-el alig használható, mert minden egyes alkalmazás legalább kétszer akkora lett, minden látható ok nélkül. Nincsenek további funkciók. Nem gyorsabbak vagy optimalizáltabbak. Nem néznek ki másként. Csak… nőnek?
Az iPhone 4s-t iOS 5-tel adták ki, de alig tudja futtatni az iOS 9-et. És ez nem azért van, mert az iOS 9 sokkal jobb – alapvetően ugyanaz. De az új hardverük gyorsabb, ezért lassabbra tették a szoftvereket. Ne aggódjon – izgalmas új képességekkel rendelkezik, mint például… ugyanazon alkalmazások futtatása ugyanolyan sebességgel! Nem tom.
Az iOS 11 megszüntette a 32 bites alkalmazások támogatását. Ez azt jelenti, hogy ha a fejlesztő nincs jelen az iOS 11 kiadásakor, vagy nem hajlandó visszamenni, és frissíteni egy valaha tökéletes alkalmazást, akkor valószínűleg soha többé nem fogja látni az alkalmazását.
*@jckarter: A DOS-os programot nagyjából minden 80-as évek óta gyártott számítógépen módosítatlanul futtatni lehet. Egy JavaScript-alkalmazás megszakadhat a holnapi Chrome-frissítéssel.*
A ma működő weboldalak 10 év múlva (valószínűleg hamarabb) nem lesznek kompatibilisek egyetlen böngészővel sem.
“Minden erőfeszítést megtesz ahhoz, hogy helyen maradj.” De mi értelme van? Lehet, hogy alkalmanként annyira élvezem, hogy veszek egy új telefont és új MacBookot, mint a bárki más, de csak azért, hogy ugyanazokat az alkalmazásokat tudjam futtatni, amelyek éppen lassabbak lettek?
Szerintem ennél jobban is teljesíthetünk, és kell is teljesítenünk. Mindenki azzal van elfoglalva, hogy dolgokat építsen most, mára, ritkán holnapra. De jó lenne, ha lenne olyan dolog is, ami ennél kicsit tovább bírja.
**Minnél rosszabb annál jobb**
Ezen a ponton senki nem ért semmit. Nem is akarnak. Csak kidobjuk az alig megsült szart, reméljük a legjobbakat, és „startup wisdom”-nak nevezzük.
A weboldalak frissítést kérnek, ha bármi baj van. Kinek van ideje rájönni, mi történt?
Bármely webalkalmazás folyamatosan „véletlenszerű” JS-hibákat produkál, még kompatibilis böngészőkön is.
Az egész weboldal/SQL adatbázis architektúra arra az előfeltevésre épül (remélhetőleg), hogy senki sem fog hozzányúlni az Ön adataihoz, miközben a megjelenített weboldalt nézi.
A legtöbb együttműködésen alapuló megvalósítás a „legjobb erőfeszítés”, és számos olyan közös élethelyzettel rendelkezik, amelyek során adatvesztésre kerül sor. Láttad már ezt a kérdést „melyik verziót akarja megtartani?” Úgy értem, ma olyan alacsony a léc, hogy a felhasználók örülnének legalább egy ilyen ablaknak.
És nem, az én világomban egy olyan alkalmazás, amely azt mondja: „Tönkre fogom tenni a munkáid egy részét, de legalább kiválaszthatod, hogy melyiket” az nem oké.
A Linux úgy van tervezve, hogy megöljön random folyamatokat. És mégis ez a legnépszerűbb szerveroldali operációs rendszer.
Minden eszközöm rendszeresen meghibásodik így vagy úgy. A Dell monitoromat időnként újra kell indítani, mert szoftver van benne. Airdrop? Szerencsés vagy, ha észleli a készülékedet, különben mit tegyek? Bluetooth? A specifikáció annyira összetett, hogy az eszközök nem beszélnek egymással, és a rendszeres visszaállítás a legjobb megoldás.
És nem is nyúlok az Internet of Thingshez. Annyira túl van a vicces határon, hogy nem is tudom, mit tegyek hozzá.
Büszke akarok lenni a munkámra. Működőképes, stabil dolgokat szeretnék készíteni. Ehhez meg kell értenünk, hogy mit építünk be és ki, és ez lehetetlen megtenni a duzzadó, túltervezett rendszerekben.
A programozás ugyanaz a káosz
Csak úgy tűnik, már senkit sem érdekel a minőségi, gyors, hatékony, tartós, alapos építés. Még akkor is, ha a hatékony megoldások már régóta ismertek, ugyanazokkal a problémákkal küzdünk: csomagkezelés, build rendszerek, fordítók, nyelvi tervezés, IDE-k.
A build rendszerek eredendően megbízhatatlanok, és időnként teljes tisztítást igényelnek, bár az érvénytelenítéshez minden információ rendelkezésre áll. Semmi sem akadályoz meg bennünket abban, hogy az építési folyamatokat megbízhatóvá, kiszámíthatóvá és 100%-ban reprodukálhatóvá tegyük. Csak senki nem tartja fontosnak. Az NPM évek óta „néha működik” állapotban maradt.
*@przemyslawdabek : Nekem úgy tűnik, hogy rm -rf node_modulesez a munkafolyamat elengedhetetlen része a Node.js/JavaScript projektek fejlesztésénél.*
És a build idők? Senki sem gondolja, hogy a percekig vagy akár órákig működő compiler probléma lenne. Mi történt azzal, hogy „a programozó ideje fontosabb”? Szinte az összes compiler, elő- és utófeldolgozók jelentős, néha katasztrofális extra időt adnak a buildhez anélkül, hogy arányosan jelentős előnyöket biztosítanának.
Azt várnánk a programozóktól, hogy többnyire racionális döntéseket hozzanak, de néha ennek pont az ellenkezőjét teszik. Például a Hadoop használata akkor is, ha lassabb, mintha ugyanazt a feladatot egyetlen desktopon futtatná.
A gépi tanulás és az „AI” a szoftvereket a találgatásokra helyezte át azokban az időkben, amikor a legtöbb számítógép eleve nem is elég megbízható.
*@rakhim : Amikor egy alkalmazást vagy szolgáltatást „AI-alapúnak” vagy „ML-alapúnak” írnak le, akkor azt úgy olvasom, hogy „megbízhatatlan, kiszámíthatatlan és lehetetlen megindokolni a viselkedését”. Igyekszem elkerülni az „AI”-t, mert azt akarom, hogy a számítógépek az ellenkezője legyenek: megbízhatóak, kiszámíthatóak, ésszerűek.*
Virtuális gépeket helyeztünk a Linuxba, majd a Dockert a virtuális gépekbe, egyszerűen azért, mert senki sem tudta felszámolni a legtöbb program, nyelv és környezet által okozott zűrzavart. A szart takaróval takarjuk le, hogy ne foglalkozzunk vele. Az „single binary” például továbbra is HATALMAS értékesítési pont a Go számára. Nincs rendetlenség == siker.
És a függőségek (dependencies)? Az emberek könnyen hozzáadnak túltervezett „teljes csomagmegoldásokat”, hogy megoldják a legegyszerűbb problémákat anélkül, hogy figyelembe vennék a költségeket. És ezek a függőségek más függőségeket is hoznak. A végén egy kusza ágú fát kapsz, amely valami a horror történet (olyan nagy és konfliktusokkal teli OMG) és a vígjáték (nem indokolt, hogy ezeket belefoglaljuk, de itt vannak) keveréke.
A programok nem működnek évekig újraindítás nélkül. Néha még pár nap is túl nagy kérés. Véletlen dolgok történnek, és senki sem tudja, miért.
Ami még rosszabb, senkinek nincs ideje megállni és rájönni, mi történt. Miért is tennénk, ha mindig meg tudod vásárolni a kiutat. Pörgessen egy másik AWS-példányt. Indítsa újra a folyamatot. Dobja el és állítsa vissza a teljes adatbázist. Írj egy watchdog-ot, amely 20 percenként újraindítja az elromlott alkalmazást. Tartalmazza többször ugyanazokat az erőforrásokat, tömörítse és szállítsa. Gyorsan haladj, ne javíts.
Ez nem mérnöki munka. Ez csak lusta programozás. A mérnöki tevékenység a teljesítmény, a struktúra és az általad felépített korlátok mélyreható megértése. A rosszul megírt dolgok és a rosszul megírt dolgok kombinálása szigorúan ellenkezik ezzel. A fejlődéshez meg kell értenünk, mit és miért teszünk.
**Elakadtunk vele**
Tehát minden csak egy halom alig működő kód, amelyet a korábban megírt, alig működő kód tetejére raknak. Mérete és összetettsége folyamatosan növekszik, csökkentve a változás esélyét.
Az egészséges ökoszisztéma érdekében vissza kell térni, és újra meg újra kell látogatnia. Meg kell, hogy időnként kidobjunk dolgokat jobbakra cseréljük.
De kinek van erre ideje? Nem láttunk új operációs rendszer kernelt mi, vagy 25 éve? Túl bonyolult ahhoz, hogy mostanra egyszerűen átírjuk. A böngészők mára annyira tele vannak szélsőséges esetekkel és történelmi precedensekkel, hogy senki sem meri a semmiből újraírni a layout engine-t.
A haladás mai definíciója, hogy vagy több olajat dob a tűzbe:
*@sahrizv:*
*2014 – El kell fogadnunk a #mikroszolgáltatásokat, hogy megoldjunk minden monolith problémát.*
*2016 – El kell fogadnunk a #dockert a mikroszolgáltatásokkal kapcsolatos összes probléma megoldásához.*
*2018 – El kell fogadnunk a #kubernetes alkalmazást, hogy megoldjuk a dockerrel kapcsolatos összes problémát*
vagy újra feltalálja a kereket:
*@dr_c0d3:*
*2000: Írjon 100 sornyi XML-t, hogy „deklaratívan” konfigurálja a szervleteket és az EJB-ket.*
*2018: Írjon 100 sornyi YAML-t a mikroszolgáltatások „deklaratív” konfigurálásához.*
*Az XML-nek legalább sémája volt…*
Abban vagyunk, amink van, és soha senki nem fog megmenteni minket.
Az üzleti világot meg nem érdekli
A felhasználókat sem. Csak azt tanulták meg, hogy elvárják, amit mi nyújtani tudunk. Mi (mérnökök) azt mondjuk, hogy minden Android-alkalmazás 350 MB-ot vesz igénybe? Oké, élni fognak vele. Azt mondjuk, nem tudjuk biztosítani a sima görgetést? Oké, meg fognak tanulni élni egy dadogó telefonnal. Azt mondjuk, “ha nem működik, indítsa újra”? Újraindítanak. Hiszen nincs más választásuk.
Nincs verseny sem. Mindenki ugyanazokat a lassú, dagadt, megbízhatatlan termékeket készíti. A minőség időnkénti előrelépése versenyelőnyt jelent (iPhone/iOS vs. más okostelefonok, Chrome vs. egyéb böngészők), és mindenkit összerendeződésre kényszerít, de nem sokáig.
Mérnökként tehát az a küldetésünk, hogy megmutassuk a világnak, mi lehetséges a mai számítógépekkel a teljesítmény, a megbízhatóság, a minőség és a használhatóság terén. Ha mi kimutatjuk törődésünk, az emberek hajlandóak tanulni. És rajtunk kívül nincs más, aki megmutassa nekik, hogy ez nagyon is lehetséges. Bárcsak érdekelne ez minket.
**Nem minden rossz**
Vannak olyan reménysugarak, amelyek bizonyítják, hogy a legmodernebb fejlesztésekhez képest sem lehetetlen fejlődni.
A Martin Thompson által végzett munka (LMAX Disruptor, SBE, Aeron) lenyűgöző, üdítően egyszerű és hatékony.
Raph Levien Xi szerkesztője úgy tűnik, hogy a megfelelő elvek figyelembevételével készült.
Jonathan Blow- nak van egy nyelve, amelyet egyedül fejleszt a játékához, és amely másodpercenként 500 000 sort képes lefordítani a laptopján. Ez hideg fordítás, nincs köztes gyorsítótár, nincs dagadó build.
Nem kell zseninek lenned ahhoz, hogy gyors programokat írj. Nincs varázstrükk. Az egyetlen dolog, amire szükség van, hogy ne építsünk egy hatalmas vacakhalom tetejére, mint a modern toolchain.
**Jobb világkiáltvány**
Haladást akarok látni. Változást akarok. Azt akarom, hogy a legmodernebb szoftverfejlesztés fejlődjön, ne csak álljon. Nem akarom újra és újra feltalálni ugyanazt a cuccot, kevésbé teljesítőképes és minden alkalommal egyre duzzadóbb. Szeretnék valamiben hinni, méltó végcélt, jobb jövőt, mint amink van, és olyan mérnökök közösségét akarom, akik osztják ezt a jövőképet.
Ami ma van, az nem haladás. A rossz alapokra halmozott mindenféle eszközökkel alig érjük el az üzleti célokat. Megrekedtünk a helyi optimumban, és senki sem akar elköltözni. Még csak nem is jó hely, felfújt és nem hatékony. Csak valahogy megszoktuk.
Szóval ki akarom mondani: ahol ma tartunk, az baromság. Mérnökként jobban tudunk, és jobban is kell, és fogunk is tenni. Jobb eszközeink lehetnek, jobb alkalmazásokat készíthetünk, gyorsabban, kiszámíthatóbban, megbízhatóbban, kevesebb erőforrás felhasználásával (nagyságrendekkel kevesebb!). Mélységében meg kell értenünk, mit és miért teszünk. Ugyanígy kell a munkát elvégezni is: megbízhatóan, kiszámíthatóan, a legjobb minőségben. Büszkék lehetünk – és kell is – a munkánkra. Nem csak „hát a körülményekhez képest” – semmi hát!
Remélem nem vagyok ezzel egyedül. Remélem, vannak olyanok, akik ugyanezt szeretnék tenni. Örülnék, ha legalább elkezdenénk beszélni arról, milyen abszurdan rossz a jelenlegi helyzetünk a szoftveriparban. Aztán talán kitaláljuk, hogyan szálljunk ki.
*-Nikita*”
Forrás: https://tonsky.me/blog/disenchantment/
Fordítás: Jacareadam
31 comments
> Virtuális gépeket helyeztünk a Linuxba, majd a Dockert a virtuális gépekbe, egyszerűen azért, mert senki sem tudta felszámolni a legtöbb program, nyelv és környezet által okozott zűrzavart. A szart takaróval takarjuk le, hogy ne foglalkozzunk vele.
Az eletem osszefoglalva. Az utolso mondat ugy altalaban is.
Tldr: régen minden jobb volt
Nem jutottam sokáig, de van pár fordítási baki benne.
A “planes”-nél szerintem repülőgépekre gondol, síkokkal semmi értelme a mondatnak.
A “minden más weboldal” is nagyon tükörfordítás…
Köszi hogy ezt magyarul is közzétetted, bár a fordítás minősége hagy maga után némi kívánnivalót (mintegy illusztrálja saját maga tartalmát…).
Köszönöm, hogy lefordítottad, nagyon tanulságos cikk, és sok igazság van sajnos benne. :/
Én értem a szöveget mert szakmabeli vagyok, de nagyon kíváncsi vagyok hogy a nem technikai emberek ebből mennyit értenek meg és mi a véleményük, szóval légyszi írjátok meg! 🙂
csak egy nyamvadt apróság:
A Win 95 800*600-ra volt (kb. de max 1024*768) optimalizálva, egy Androidos telónak meg 4K-n kell tolnia a kontentet, csak a képpontokból eredő méretváltozást nézd meg, köszi…
​
​
Persze van igazság a lusta fejlesztésben is, de most ha nincs kinyalva a user feneke, akkor kuka az egész…
Szóval lényegében, nem fordítanak arra energiát, hogy minél kisebb legyen egy adott szoftver, mert akármekkorára bővíthetőek a hardveres elemek manapság?
Kábé olyan ez, mintha egy gyógyszerész azon akadna ki, hogy nem mindenkinek személyre szabottan gyártanak gyógyszereket, hanem bemész a gyógyszertárba, és kapsz egy tömegterméket, aminek a lehetséges mellékhatásait oldalakon keresztül taglalják, a lista végén általában a “spontán érrendszeri összeomlással”, ami ugye halált jelent.
Lehetne mindent tökéletesre csinálni, csak az nem lenne mindenkinek elérhető, így aztán emberek tömegeinek a mostani felállás a legjobb esélye arra, hogy számára is elérhető közelségbe kerüljön a “jó-jó, nem tökéletes, de jobb mintha nem lenne”.
Sok igazság van benne. Felhasználóként én is sokszor gondolkodtam ezen, majd munkahelyen npm-el a fél univerzumot behúzom függőségként.
Azért megvédeném magunkat annyiból, hogy jelenleg a felhasználói igény általában a kényelem majd gyorsaság és a biztonság, illetve ez sok cégnél költség és idő hatékonyság is.
Lehetne gyorsabb, hatékonyabb szoftvereket írni de az több idő lesz, és több pénz amit a felhasználó fog a végén megfizetni így vagy úgy.
Spotify asztali alkalmazását electronnal készítették amivel elég egyszer megírni és megy több OP rendszeren is. Lehetett volna jobbra is de akkor nem ennyi lenne a havidíj.
A legtöbb embernek meg a jelenlegi megoldás is megfelel.
Ha az emberek gyorsaságot és biztonságot akarnának akkor a Linux lenne a legnépszerűbb OP rendszer, egyszerűen legtöbbszor a kényelmes elég.
>Veszel-e autót, ha 100 litert eszik 100 kilométeren? Mit szólnál 1000 literhez? A számítógépekkel mindig ezt tesszük.
Ha ingyen, alanyi jogon kapnál másodpercenként 10 ezer liter benzint, és semmiféle negatív következménye nem lenne annak, hogy elégeted (káros égéstremékek, stb) akkor foglalkoznál vele, hogy 100 vagy 1000 litert fogyaszt, ha cserébe úgy megy, mint az álom? Ugye, nem – és a számítógépek ezt teszik, felfoghatatlan számítási teljesítményt nyújtanak fillérekért, szóval annyira nem kell foglalkozni vele, hogy egy átlagos CPU teljesítményének 5%-át használó alkalmazást tudsz-e úgy optimalizálni, hogy csak 4,5%-ot egyen, senkinek nem fog feltűnni.
Viszont ami tényleg probléma, hogy sokszor mint ha nem ez lenne a szűk keresztmetszet, hanem valami megmagyarázhatatlan egyéb dolog teszi lassúvá és döcögőssé például a weboldalakat. Például egy tök egyszerű Vodafone online ügyfélszolgálat oldalon már önmagában egy egyszerű bejelentkezés 4 másodpercet vesz igénybe, amire semmi értelmezhető magyarázat nincs, és tökre érdekelne ilyenkor, hogy mi zajlik a háttérben.
Projekt manager örökzöld: “Ez csak egy carryover!”
A George rant szerzője vagyok. Mérnökinformatikusként végeztem, tudok assembly-ben meg C-ben programozni mikrokontrollereket… Elég durva ebből a perspektívából belegondolni, hogy mit ki lehet hozni akár egy Arduino-ból, ami 2kB RAM-mal, és 32kB program memóriával rendlekezik…
Aztán leülök a gép elé, elindítom a Teams-et, egyből bezabál 900MB RAM-ot, mert egy Electron app, ami azt jelenti, hogy valójában egy egész Chromium instance-ot indít magának, és valójában egy weboldal, ami natív programnak próbálja tettetni magát… Kibaszott lassú, a chat-ek között váltani másodpercekbe telik, ha üzenetet gépelek, akad. Mindezt 16GB RAM-mal, és viszonylag modern i7 processzorral, 4 mag, 8 szál, 3.5 GHz.
900MB RAM-ot zabál a Teams, szimplán miután megnyitottam, és azt a Microsoft adta ki, ahol azért lenne szakértelem… A Windows XP korában összesen 512 MB RAM-ból vígan elvoltam, 1GHz-s egymagos procival ugyanúgy tudtam Skype-olni, internetezni, videót vágni (mondjuk nem HD-ban, csak 480p-ben, de akkoris)…
Most 16GB RAM-om van, és rendszeresen ki van maxolva, és a SATA III-as SSD sávszélességét gyakran kimaxolja a swappolás.
Nemrég elővettem egy régi XP-s gépem, mechanikus HDD-vel, gondoltam kipróbálom az élményt, hátha csak az idő szépítette meg az emléket… Lófaszt, egy frissen telepített XP sok helyen gyorsabbnak érződik a 15 éves hardveren, mint most a Win 10.
Itt egy releváns de vicces talk a témában, hogy miért futtatunk minden szart browser-ben, 15 absztrakciós rétegen át… 2014-ben adta elő a csávó, egy disztopikus jövőt írt le benne, de egész szépen haladunk felé.
[https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript)
>A Windows 10 4 GB-os
Ez mondjuk nekem lenyűgöző még úgy is hogy mennyivel nagyobb korábbiaknál. De a Win 10 valószíűleg az egyik legbonyolultabb szoftvercsomag a világon. És így is elég pici.
Az egész cikkről meg a következő jut eszembe: [https://xkcd.com/1205/](https://xkcd.com/1205/)
Edit: Ja és az AI-ról alkotott véleményét egyáltalán nem osztom. De meggyőzhető vagyok, ha tud nekem írni olyan megbízható, kiszámítható, ésszerű (saját szavai) és esetleg még egyszerű programot ami képes mondjuk egy fotó alapján megmondani hogy mi van rajta (Google Reverse Image Search), vagy mondjuk speech to text-et (youtube, webex, Google Assistant, Siri, meg még ezer más alkalmazás csinál ilyet), vagy esetleg autót vezet (Tesla FSD) akkor elfogadom hogy az AI értelmetlen.
Köszönjük a kontrollmániásoknak meg az akarnok én tudom, és mindenkinél jobban embereknek, hogy építik nekünk a szart. És köszönjük mindenki másnak, aki viszi a zászlót és hirdet az igét anélkül, hogy tudná miafaszról beszél.
Köszönjük az upvote szajhulásnak is.
Kiváló cikk. Örülök, hogy nem csak mi gondolkozunk ezen. Vagy hasonlón. 30 éve masszírozzuk a szart, csak egyre bonyolultabban. A 90es években 2 ember elég volt egy hatékony fejlesztéshez, ma vagy polihisztorokat alkalmazunk, vagy egy kisebb fejlesztő csapatot. És funkcióját tekintve ugyanaz a végeredmény.
Illetve mégsem. Manapság a design agyon nyomja a funkciót.
De nem hiszem, hogy a fejlesztők lennének a lusták. Az igazi fejlesztő ma is szívből dolgozik, a teremtés örömével. A szarkupac, amire építeni kell, illetve a rövid határidők ennyit engednek.
Az IoT szerintem nagyon jó irány. Vissza az alapokhoz. Kis erőforrások, remélhetőleg e miatt optimalizált végeredménnyel. De nyilván ez nem minden feladatra megoldás.
Egészen érdekes írásnak tűnt az elejénél, aztán valahogy amikor megérkeztünk a linuxhoz, build rendszerekhez és VMekhez teljesen elvesztette nálam a valóságalapját.
Szerintem az író itt életében nem látott rendesen összeillesztett – akár hibrid/multi cloudon alapuló – CICD folyamot, csak összetákolt, összekókányolt szarokat.
Tény, hogy belegondolva minden build iszonyat erőforrásokat emészt fel, aminek az eredménye legtöbbször egy SUCCESS/FAIL, de ez önmagában nem jelenti azt, hogy ezek a technológiai megoldások feleslegesek és eredendően használhatatlanok…
több haskell programozót mindenhova
Jaj hogy elvezem az ilyen nagyokosokat.
Ha ez tenyleg igy menne, es tenyleg leszarom dilettansok epitenek mindent, akkor mi akadalyozza meg a cikk irojat abban, hogy felvegyen 5 neki megfelelo mernokot, es barmelyik lenezett szoftvert ujrairja ahogy szerinte jo, csak nyilvan tizcsillioszor hatekonyabbra. Tenyleg elhiszi barki ezt a hulyeseget, hogy ha igaz lenne amit ir akkor nem lenne mar egy szupergyors Slack/Teams, egy szuperul megirt szerver framework amihez nem kell se docker se k8s, es egy instance-on kiszolgalja a vilagot ketszer, pedig egy szamologepen fut?
Szoval vagy az van, hogy a teljes ipar hulye, a csavo egy zseni, es hamarosan irto gazdag lesz vaaaagy durvan egyszerusit es alulbecsuli a hasonlo termekek komplexitasat.
Szerintem ez egy elég komplex probléma. Az egész ott kezdődik, hogy a userek egyszerűen nincsenek tisztában azzal, hogy mennyi munka egy rendesen működő kódot megírni, pláne optimalizálni. Ezért egyszerűen nem is hajlandóak nagyon pénzt adni érte, cserébe a hardvert viszont valamilyen oknál fogva (talán mert az fizikailag kézzel foghatóbb) hajlandóak pár évente százezres nagyságrendben cserélni. Így a szoftver fejlesztő cégek is sajnos ráálltak arra, hogy nem baj ha optimalizálatlan az egész, majd úgy is vesznek új hardvert aztán meg van oldva a probléma. Szemlélet váltásnak kéne történnie, azt meg tudjuk, hogy nehezen megy.
Egyrészt az összehasonlítás az elején nagyon sántít… A mai napig elmondhatatlan mennyiségű használhatatlan, szar, autó készül, amit aztán nyomorék autoszerelők segítségével 5 év alatt tacsra vágnak az emberek. Abba a gennyfesztiválba ami meg építkezés/ felújjítás címszóval zajlik szerte a világban meg bele se menjünk. Csak az elmúlt 3 évből van vagy 10 story-m ahol az ismerőseim inkább vért hánytak volna csak a szakival ne talákoztak volna aki összebaszta a házukat.
De ezt félre téve ez valóban van programozásban is. Szerintem ezért:
– Iszonyatos mennyiségű pénz ömlik ebbe az iparba, és még annál is több ingyen hitel és ‘kockázati tőke’. Dollármilliárdok mennek a semmire, mert volt a fiók alján és ha nem költjük el idén, nem adják jövőre. Miközben az egész világ a piacod és ha még szar is amit csinálsz lesz egy csomó retardált aki megveszi ha eleget költesz marketingre. Naná hogy a teljesítmény meg a jó kód nem számít ha egyszerűen nincs meg rá az igény sem a felhasználói oldalról sem a management oldalról.
– Az AGILE többet ártott a programozói világnak, mint bármi az elmúlt 30 évben. Az ötlet, hogy a megrendelő és a mangament évekig(!) toporoghat egy helyben 100 felé mozgatva a tervet amit követni kéne, miközben elhitetjük velük, hogy megyünk valahova a modern kor legaljasabb faszsága volt. Egy tucat projektet láttam szétesni, mert soha nem volt semmilyen hosszútávú cél amit el kéne érni. Két hetente vállon veregettük egymást, hogy mekkora királyok vagyunk, az ügyfél kapott 2 új gombot amit nyomogathatott, és mint egy reteradált labrador elhitte, hogy ez most jó neki. Évek telnek el így mire rájön, hogy az eredeti business visszi még mindig a hátán a cégét és a 3 csapat programozó akit felvett nem keresett neki egy kurva forintot se.
vacakhalmok tetejére építkezni?
*** laughs in jenkins ***
A fordítás az pusztulatosan fostos.
A tartalom viszont nagyon ott van 🙁
Én meg emlékszem a Turbo Pascalra. Gyakorlatilag mire levetted az ujjad a build gombról, el is készült.
Ma egy laptopon programozok, összehasonlítani azzal a PC XT-vel, amit a Turbo Pascal használt teljesen értelmetlen. És mégis, amikor megnyit egy projektet (a PCIe 4.0 SSD-ről, aminek valami 6GB/s az olvasási sebessége) eldünnyög tíz-húsz-negyven másodpercig, akár több, mint egy percig, hogy ő most indexel. 48GB memória, Tiger Lake H CPU. Arcom letettem.
Előrebocsájtom, hogy gépészmérnök vagyok, és csak messziről ugatom a programozást. Szóval bare with me, de engem is bosszant a sok lassan működő program.
Egy sztori egy képzeletbeli cégről, ami nem történt meg: Volt egy aránylag jól működő C program, amit a fejlesztők a sima irodai laptopjukon max. 5 perc alatt fordítottak, a végeredmény <10 MB. A program nem volt rossz, persze pár dolgot lehetett volna rajta polírozni, de a teljesítményt hozta.
Management jön, teljes újraírást, mert ez szar, elavult. Az új program annyira lassan fordult, hogy minden fejlesztőnek brutál workstation laptopokat vettek, mert ezekkel csak 4-6 óra volt egy fordítás, de mondjuk mellette mást nem igen tudtál csinálni rajta. Aztán lettek szerverek beüzemelve, amik fordítanak, így már csak 20-40 perc egy fordítás.
Eredmény: egy <10 MB program, ami körülbelül 3 évnyi fejlesztés után lett azon a szinten, mint a régi. Csak ugye sokkal nehezebben fordul, és a toolchain sokkal szarabb és lassabb.
Költői kérdés: mi lett volna, ha ezt az irgalmatlan időt, energiát és pénzt a régi polírozására fordítjuk, és mondjuk csak a gyengén működő 20%-át írjuk újra a régi toolchainben?
Plusz szerintem az is probléma, hogy az egyszerű usernek nincs baseline-ja, amihez hasonlítsa a teljesítményt. Ha egy win10 frissítés 500 MB, és fél óráig tart, akkor elfogadja, mert nincs mihez hasonlítania. Ha az autója 25 litert enne, akkor elég hamar feltűnne, hogy baj van, mert a kollégája/szomszédja/akárki autója csak 6-ot eszik. Ha egy bolt ugyanazt a cuccot árulná csak kétszeres áron, hamar rájönne, hogy át van baszva. Itt viszont mihez hasonlítsa?
Másik dolog, amin felbasztam magam a játékok terén az a Just cause 4 volt. Nem túl erős a gépem, de ez olyan szarul futott és olyan okádékul nézett ki, hogy inkább le is töröltem. Hasonló játékok elfogadhatóan futnak, de ez még úgy is akadt, hogy mellette úgy nézett ki, mintha 2003-ból származna. Hát mi a fasz?
Amúgy a George app monjonle. Én is használom, és tényleg kurva nagy visszalépés.
Senkinek nincs ideje Adamtol es Evatol kezdve programokat irni, ott a hatarido meg a jira legyel kesz, ezzel es ezzel kell dolgoznod amit a ceg hasznal. Gyorsan kell megoldani a problemat, hogy az uzlet tudjon haladni, nincs ido minden libraryt ujrairni sot a tudas sincs meg hozza. Vannak ebben a szovegben igazsagok de egyaltalan nem eletszeru.
Én azt belezném ki, aki 500 mb-os egér drivert ír. Elsősorban a perverz kapitalista hozzáállást és kényszereket, illetve evvel összefüggésben az alulfizetett indiai programozókat hibáztatom.
Én inkább írok 10 lassan futó de az üzleti problémát megoldó szoftvert mint egy gyorsat ami nem is azt csinálja amit kell.
Részben egyetértek az írással. Valóban azt látom, hogy a fejlesztők legalább fele elég életlen kés a fiókban. Még csak nem is értik az általuk írt kód performancia impaktját, nem értik átfogóan a rendszert amibe fejlesztenek. Megcsinálják ami a feladat és kész. A szoftverek minőségromlása pedig szerintem jórészt annak tudható be, hogy a cégek nem végeznek szisztematikus tesztelést. Időnyomás van, tolni kell kifelé az új feature-öket és nincs idő még 30% időt rászánni, hogy automatikus tesztet írjunk, ami pirosan virít, ha a jövőben ez a funkció elromlik. A Facebook ahogy egyre inkább csinál mindent is, a régi dolgok folyamatosan elromlanak. Ha egy ilyen giga cég nem képes ezt rendesen csinálni, akkor a többi cégtől mit várunk? Majd jelentik a hibát és akkor kijavítjuk, ha kritikus.
A másik része a dolgonak, hogy a szoftverekkel szembeni elvárás egyre csak nő. A Google keyboard-dal sem csak karaktereket pötyögsz be. Vannak emoji-k, GIF-ek, amiket el kell tárolni, van benne spell checker, eltárolja a nem ismert, de általad gépelt szavakat, tudsz neki diktálni, stb. A szövegszerkesztőben is van minden. Szntax highlighting, code formatter, code analyzer, plugin manager, meg ilyenek. Már nem csak annyit tudnak, hogy bepötyögöd az ASCII karaktereket és elmenti egy txt-be.
Az applikációkkal szemben pedig elvárás, hogy cross-platformak legyenek, mindenen is fussanak. Viszont az operációs rendszerek futtató környezete eltér egymástól. (Vannak törekvések némi kompatibilitásra, de alapból egy natív Android alkalmazást nem tudsz futtatni Linuxon, Mac-en vagy Windows-on). Más a kernel, más a megjelenítő library, stb, így ha minden platformon natív alkalmazást szeretnél kiadni, akkor azt kb annyiszor le kell programozni, utána meg karbantartani. Ezért megy abba az irányba az egész, hogy łrunk egy webapp-ot és mellé csomagolunk egy böngészőt, és “fut mindenen”. Nyilván nem ennyire triviális, de sokkal kisebb a szívás vele, mintha minden platformon lenne natív alkalmazás.
Azért elég sok féligazság, illetve tévedés van ebben a “rant”-ben. Ami egyik felhasználónak bloat, az a másiknak alapfunkcionalitás. S mindig egyszerübb a 100 feature-t tartalmazó programhoz hozzáadni egyet, amire egy új felhasználónak szűksége van, mintsem lefejleszteni egy olyan programot, ami csak azt az 53 featuret tartalmazza, amire éppen annak az embernek szüksége van. Az eredmény? Lesz egy program 101 feature-rel, ahol mindegyik feature-re senkinek sincs szüksége. Cserébe mindenki boldog, kevesebb munkával és költséggel sikerült megoldani mindenki problémáját.