Nem hibás az OOP szemlélet?
- Joe Armstrong, az Erlang programozási nyelv feltalálója szerint "Az objektumorientált nyelvek problémája, hogy egy implicit környezetet is magukkal hoznak. Egy banánt kértem, de kaptam egy a kezében banánt tartó gorillát meg köré az egész dzsungelt."
- Paul Graham szerint az OOP célja, hogy egyfajta csordaszellemet képezzen, amely megakadályozza, hogy középszerű programozók középszerű cégeiknek túl nagy károkat okozzanak. Mindezt annak az árán, hogy cserébe lelassítja azoknak a programozóknak a munkáját, akik jobb vagy kompaktabb technikákat is ismernek.
- Részletes cikkében Lawrence Krubner végigveszi az objektumorientált programozás tizenkét aspektusát, és bebizonyítja, hogy más nyelvekhez hasonlítva (lisp, funkcionális nyelvek stb.) az OOP nyelveknek nincsenek különleges erősségeik, viszont szükségtelen komplexitást hordoznak magukkal.
- Rob Pike, aki részt vett az UTF-8 és a Go megalkotásában, az objektumorientáltságot a programozás római számainak nevezte. Azt mondta, hogy az adatszerkezetekről és az algoritmusokról az adattípusokra helyezi át a hangsúlyt. Továbbá idézi egy Java professzor példáját, aki egy egyszerű keresőtábla helyett hat osztály létrehozásával oldott meg egy feladatot.
#9 "mi az olcsóbb a hardver vagy a programozó?"
Aztán így születnek azok a rendszerek, amiknek az erőforrásigénye a reálisan indokoltnak az 5-10-szerese.
Nem mellékesen: jó programozó kell, meg jó menedzsment, és akkor nem fog tovább tartani a fejlesztés. ;-)
"Viszont ma már a hardver lényegesen olcsóbb, memória szinte korlátlan, a CPU gyors."
Ez egy bizonyos szintig igaz. Mondjuk egy bérszámfejtő szoftvernél, ahol 15 alkalmazott adatait kell kezelni, teljesen irreleváns. Amikor az adatok száma milliós nagyságrendű, akkor már lényeges tud lenni, hogy x, vagy 4x idő alatt fut-e le.
"De ez ma már igen ritka."
Annyira azért nem. ;-)
"Pont az OOP az ahol bejön az, hogy mi az olcsóbb a hardver vagy a programozó? Az OOP esetén tény, hogy egy-egy híváskor több adatot kell mozgatni, mint ha valami más megközelítést használnák. Viszont ma már a hardver lényegesen olcsóbb, memória szinte korlátlan, a CPU gyors."
És ha egy alkalmazás tízezer gépen fut, akkor szerinted tényleg olcsóbb, gazdaságosabb a tízezer gép hardverének bővítése mint egy nyomorult, silány fejlesztő munkaviszonyának megszüntetése?
12: Többször mondtuk, hogy az agyatlanságoddal húzz el innen.
"És ha egy alkalmazás tízezer gépen fut, akkor szerinted tényleg olcsóbb, gazdaságosabb a tízezer gép hardverének bővítése mint egy nyomorult, silány fejlesztő munkaviszonyának megszüntetése?" Remélem ezt nem komolyan gondolod. Egyszerűen hülye vagy az informatikához. Nálad kimaradt kb. 30 év az informatikából. Igen így működik a világ. Ld. windows, linux és a rájuk írt alkalmazások, programok. Ennyire ostoba hogyan lehetsz? De tényleg.
#12 egy bohóc, aki kb 40 évvel ezelőtt volt valahol rendszergazda.
Csak azóta a világ kicsit továbblépett.
" Igen így működik a világ."
A hülyék szerint.
A világ valójában meglehetősen árnyalt.
A hozzád hasonló suttyók onfelmentő dumája az, hogy vegyen jobb hardvert meg tobb RAM-ot a gépbe. Ti valójában csak áttoljátok a saját szarotokat a felhasználó/megrendelő asztalára.
"Valamelyik kérdésben az IBM360-at dicsőítette,"
Csak addig szopogass lovacskát, amíg ez a kijelentésed igazzá nem válik.
"az meg 1960-as évek eleje volt."
Fiatal suhanc lehetsz te is mint a másik szenilis vénember, aki az 50 éves tapasztalatairól hinti itt a dumáit.
15: Akkor nézzük. OOP-vel a fejlesztés 10 000 munkaóra (több fejlesztő közös munkájával), OOP nélkül ugyanez a program legalább 30 000 munkaóra. (Nagy projektek esetén a szakirodalom 1:3 szorzót mond).
Vegyünk egy átlag USA programozót, erre a most elérhető források éves kb. 89 000 USD fizetést írnak. Egy évben egy programozó kb. 160-180 munkanapot tölt programozással, a többi idő továbbképzés, szabadság, etegség stb. (szintén szakirodalmi adat). Ez azt jelenti, hogy éves átlag 1360 órát tud "hasznosan" dolgozni. A munkáltatójána is vannak költségei, meg némi hasznot is szeretne. Ez azt jelenti, hogy legalább 15%-al többet kell termelni ez kb. 105 000 USD/év. Egy óra ez esetben kb. 77 USD-re jön ki (ennyibe kerül legalább a cégnek, és nem számoltuk az irodát, eszközöket stb. ezzel egyből felmegy legalább 80 USD-re /ez legalább kerek szám/).
10 000 órás fejlesztés 800 000 USD-t fog jelenteni. 30 000 órás fejleszét 2 400 000 USD-t fog jelenteni. Legyen ebből eladva 1 000 darab, ez esetben az egyik változat 800 USD a másik változat 2 400 USD. Az eltérés 1600 USD Kérdés, hogy a felhasználónak megéri-e ha ezért picit több RAM-ot és eggyel nagyobb procit kell vennie? Bőven meg fogja érni. És ezek most csak ilyen nagyon durva becslések, szakirodamli adatok alapján. Egy 16GB-os RAM modul most kb. 60-90 USD. (rákerestem most a neten).
De ha hazai számokat nézek is hasonló lesz az arány.
És igen innen látszik, hogy nálad kimaradt 40 év. Mert 50 éve nem lehetett ilyen olcsón memóriát és CPU-t kapni. Akkor a mérleg még a másik irányba dőlt. Most 1600 USD-ért nagyon brutális eltérést lehet egy gépbe bepakolni (nem 1600USD-ert ekll gépet venni, hanem egy "kisebb" és egy "nagyobb" gép közti különbség ennyi). És mielőtt kicsavarnád a szavakat (ahogy szoktad). Ezek "normál" felhasználású gépek, nem gamer, és nem embed systems. Mert azok speciális területek és azoknál egy kicsit másképpen állnak a számok. És nem szuper komputerek, és a big data teteje. Ezt csak azért írom, mert ebbe fogsz belekötni te i*n legnagyobb b*rma.
"Mert 50 éve nem lehetett ilyen olcsón memóriát és CPU-t kapni. "
Te birg, a komolyabb rendszerek felhasználóinak száma milliós, de legalább szézezres nagyságrendű. Minden egyes kliens 50 USD-s koltése, az már tízezer gép esetén is fél millió dollár.
De nem is ez a lényeg, hanem az, hogy a bloatware, a tákolt szar létjogosultságát nem lehet a hardver olcsóságával indokolni.
Két dolog biztos, hogy nincs a foldon, és nem is lesz soha. Túl szép nő és túl gyors számítógép.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!