OOP megy a szemétbe?

"De nem én találom ki ezeket."

Nem hát, hanem egy képzetlen, földbuta, beképzelt ökör, aki janosen-nek hivatja magát és két kézzel szórja a baromságokat. De a legrosszabb, hogy vannak segédei is.

"Biztosan megoldható procedurálisan is, jó kis spagetti kóddal."

Érdemes lenne utánanézned, hogy mi is az a spagetti kód.

A probléma az, hogy a feltételezésed téves következtetéseken alapul. Illetve az egész OOP-vel kapcsolatban nagyon komoly tévedésekben élsz.

"ha a programkód generálás olyan magas szintre jut, mint az várható"

És ki mit vár? Ezen a ponton a nagy többség irreálisan sokat remél a nagy nyelvi modellektől, és a gépi tanulástól.

"akor talán maguk a programozási nyelvek is megváltozhatnak"

Nyitott ajtókat döngetsz, mert a programozási nyelvek folyamatosan változnak. Új nyelvek jönnek létre, régi nyelvek szorulnak perifériákra, illetve a meglévő nyelvek is komoly fejlődésen mennek keresztül. Elég csak a C++-t megnézni: olyan szinten változott a nyelv, hogy egy '90-es évek eleji, Borland C++-ban írt program 99%, hogy le sem fordulna a mai legfrissebb GCC alatt. Illetve ugyanez visszafelé is igaz.

"akár meg is szűnhet a használatuk"

Akár egy élien invázió is jöhet holnap...

"Ugye, az OOP egy emberközeli paradigma, de ami jó az embernek, az nem feltétlenül jó a gépnek."

Ez egyrészt téves, másrészt meg "nesze semmi, fogd meg jól". Az OOP semmivel nem emberközelibb, mint pl. a procedurális programozás. Az, hogy a tankönyvek - a könnyebb érthetőség kedvéért - szeretik a kicsit esetlen kutyás-macskás példával illusztrálni, az csak azért van, hogy jobban érthető legyen a tanulók számára, és semmi köze nincs az OOP létrejöttéhez.

Az meg, hogy mi a jó a gépnek, értelmetlen. A gép nem egy szentimentális haver, akinek a lelkét ápolni kellene. Neki minden jó, amit fel tud dolgozni. Az egyes programozási nyelvek, illetve pontosabban a fordítók pedig mindent átalakítanak neki úgy, hogy "jó legyen", azaz gépi kóddá.

De tudom, te mire gondolsz. Arra, hogy mi az, ami közelebb áll a gépi logikához, és mi az, ami nem. Nos, groteszk módon pont, hogy az MI az, ami rémesen távol áll a gépi logikától. Mesterséges idegsejtek működését emulálni, és ezekkel tanítóminták alapján, valószínűségi alapon döntéseket hozni? Pont ez az, ami nagyon távol áll a tiszta gépies logikától.

"az OOP nagyon erőforrásigényes"

A "nagyon" szó meglehetősen szubjektív fogalom. Az erőforrásigénye tényleg potenciálisan nagyobb, mint pl. a procedurális paradigma szerint készült programoké, bár ebben azért a programozó kompetenciájának is van némi ráhatása.

"valószinűleg ki fogják szorítani más, hatékonyabb paradigmák"

Az a baj, hogy te a hatékonyságot mindössze a felhasznált RAM függvényének tekinted. Közben meg baromira nincs így. A hatékonysághoz hozzá tartozik az is, hogy egy feladatot mekkora ráfordítással lehet megoldani. Szerinted miért nem kódolunk mindent ma is Assemblyben? Hiszen potenciálisan az abban készült szoftvereknek a legkisebb az erőforrásfelhasználása. Azért, mert a fejlesztés költsége és ideje nagyon komoly szempontok. A hardver pedig egyre olcsóbb. A Commodore 64 kezdetben egy kisebb vagyonba került, ás összesen 64 kB RAM-ja volt. Meg egy 1 MHz-es procija. Ott tényleg kulcskérdés volt, hogy mindent a lehető leggyorsabban, a legkisebb RAM felhasználásával megoldj. (Abba most ne menjünk bele, hogy a nagyon egyszerű programocskákat leszámítva már ez a kettő is egymással ellentétes folyamat...) Ott tényleg volt, hogy minden egyes bájt számított. De ma már a processzorok számítási kapacitása ennek a többezerszerese, a munkamemória pedig pár majdnem a milliószorosa. Szép dolog, és egyáltalán nem elbagatelizálandó az optimalizálás, de ma már nem kifizetődő a végletekig optimalizálni valamit, mert egyszerűen anélkül is megfelelő teljesítményt lehet elérni, a fejlesztési idő pedig így a töredéke.

"A hatékonyabb azt jelenti, hogy beéri kevesebb erőforrással"

Nem, nem azt jelenti. Ez csak egyik lehetséges aspektusa a hatékonyságnak. (És mint írtam, már itt is van egy jókora belső ellentmondás, ugyanis a memóriaigény, és a processzorigény egymással ellentétben van.) Hatékonyság alatt érthetjük még a fejlesztés gyorsaságát és költségeit, a kód újrafelhasználhatóságát, a kód továbbfejlesztésének egyszerűségét, a hibatűrését, stb, stb. Te ezek közül egyetlenegyet ragadtál ki, és végig azon lovagolsz. Azt az egyet, amelyik ma már messze nem a leglényegesebb.

"Az OOP-t alapvetően azért találták ki, hogy a gyengébb képességű programozók is használhatóak legyenek"

Pont, hogy nem.

Az OOP-t azért találták ki, hogy a kód könnyebben karbantartható legyen, és hogy a fejlesztést felgyorsítsák.

Pont, hogy az OOP-hez kell nagyobb tudás, és pont, hogy a gyengébb programozók azok, akiknek hatalmas nehézségeik vannak az OOP-vel.

#10 "Eleve mára kiderült, hogy a Delphi zsákutca."

Dehogy volt az. Egy vitathatatlanul lényeges eleme volt a RAD fejlesztőeszközök fejlődésének. Mint ahogy a Visual Basic is. Ezek alapozták meg az összes RAD IDE létrejöttét, amik nélkül manem igazán lenne elképzelhető modern szoftverfejlesztés.

Attól, hogy mostanra a perifériákra szorult, nem azt jelenti, hogy zsákutca lett volna, hanem azt, hogy más technikák túlhaladák azt.

(Bár tapasztalatom, hogy ha a divatot és fintorgást leszámítjuk, Delphiben sem kevésbé hatékony fejleszteni, mint akármi másban.)

#35 Most tévedtem ide és öröm volt olvasni, hogy mennyire szívemből beszéltél :)

Senior Softver Engineer kolléga.