Object-Oriented Programming is Bad

https://www.youtube.com/watch?v=QM1iUe6IofM

Roviden, hiaba olvasol disign pattern konyveket,
ez a dolog nem fog ugy mukodni ahogy kene,
csak jobban ussze kuszalod.

Vive la résistance

( enpassant v | 2016. 11. 25., p – 15:16 )

Köszi, nagyon jól összeszedett anyag!

A végével viszont abszolút nem tudok egyetérteni: a hosszú függvény jobb, mint ha sok kicsire bontanánk.

Azért kíváncsi lennék egy több száz soros függvényre, ami egy dologgal foglalkozik.

Még ha egy dologgal foglalkozik is a hosszú, akkor is könnyebb megérteni egy rövid kódot.
Ha látok 5-10 függvény hívást, amiknek a nevei kb. mintha a dokumentáció lenne, azt könnyen megértem, míg ha látok 500 sort mindenféle változókkal, ciklusokkal és függvényhívásokkal, még ha dugig rakom kommentekkel, akkor is nehezen fogom megérteni.
Ha meg szeretném részletesebben megérteni a rövid kódomat, akkor megnézem az adott függvények megvalósítását.

( nydn | 2016. 11. 25., p – 15:18 )

érdekes videó, én is köszi megosztást.

( persicsb | 2016. 11. 25., p – 15:23 )

remélem ez jó kis fikatopik lesz, sub

Ezek alapjan ket dolog fogalmazodott meg bennem azzal kapcsolatban, hogy melyek a jelenlegi OOP kulcsproblemai (_nagyon_ leegyszerusitve):

1. Az adat ("noun") es az algoritmus ("verb") eroszakos osszehazasitasa. Az egyszeru OOP nyelvekben (pl. Java) kotelezoen ossze kell kotni ezt a kettot, es 1:1-ben egymashoz rendelni. Az adat es az algoritmus is ugyanabban az osztalyban lakik. Ha 1:N vagy N:M hozzarendelesre van szukseg, akkor mindenfele kifacsart patterneket kell alkalmazni (pl. Visitor), amitol a kod gyakorlatilag olvashatatlan lesz.

Megoldas: letezik, mixin/trait hasznalata azokban a nyelvekben, ahol elerheto.

2. Object oriented programming helyett tenylegesen Class oriented programming tortenik, vagyis az absztrakcios szintek nem a futasideju objektumokra kepezodnek le, hanem forditasi ideju modulokra. Ez az esetek nagy szazalekaban rossz design-hoz vezet, es hibas absztrakciokhoz.

Erdemes James (Jim) Coplien egy-ket eloadasat vegignezni (peldaul: https://youtu.be/lQQ_CahFVzw?t=32m34s), nagyon hatarozott velemenye van egy-ket dologrol, gondolatebresztonek tokeletes.

Megoldas lehet: peldaul prototype-based nyelvek hasznalata, ebbol gyakorlatilag egyet ismer mindenki, a Javascriptet.

Jelen pillanatban a JVM platformon nem tudok olyan nyelvrol, ami a fenti megoldasokat adna production ready minosegben: az uj (elmult ~10 evben megjelent) nyelvek nagy resze vagy a Javat reszelgeti es a problemak forrasara meg csak meg sem probal megoldast kinalni (pl. Kotlin, Xtend, Ceylon), vagy orbitalis palyara allva gigawattos szuperlezerrel lo a legkisebb legyre is, es intergalaktikus pilotavizsga nelkul meg a kodot sem tudod elolvasni (Scala), vagy egyszeruen csak olyan magasra teszi a bejaratnal a lecet, amit az atlag berprogramozo elete soran sohasem fog megugrani (Clojure).

Nekem az a tippem, hogy a kovetkezo Java egy olyan nyelv lesz, amelyik a fenti ket problemara hatekony, egyszeru, mindenki altal hasznalhato megoldast ad, vegyitve nehany ujra felfedezett dologgal, mint az ADT-k es a pattern matching, es a perzisztens adatstrukturak (nem kizarolagos!) hasznalata. Mindehhez statikusan tipusos (vagy legalabbis a kod forditasanak kotelezo resze valamilyen tipusellenorzes), hogy a nagyvallalati userek is boldogak legyenek. Es persze garbage collected virtualis gepen fut.

Jelen pillanatban ket olyan nyelvrol/kornyezetrol tudok, amely a fentiekhez legkozelebb all: a mar emlitett Javascript, es -meglepo modon - az Erlang. Mivel az Erlang csak nagyon vastag keretes szemuveggel nagyon messzirol nezve OOP, es inkabb celnyelvnek kategorizalhato, marad a Javascript. Persze nem a jelenlegi verzioja, de nem is valamelyik leszarmazottja (amelyikrol tudok, mind a class oriented programminghoz probal visszaterni).

Steve Yegge egyebkent 10 evvel ezelott ugyanerre a kovetkeztetesre jutott (kicsit mas megkozelitessel). Meglepo es mulatsagos? Szerintem az.

De ha tudtok valamirol, amirol en nem, akkor tovabbi otleteket szivesen olvasgatok :)

Van amikkel egyetértek, csak azokra válaszolnék, amikkel nem.

1. Az adat ("noun") es az algoritmus ("verb") eroszakos osszehazasitasa. Az egyszeru OOP nyelvekben (pl. Java) kotelezoen ossze kell kotni ezt a kettot, es 1:1-ben egymashoz rendelni.

Nem kell kötelezően összekötni a kettőt. Könnyen csinálhatsz csak adat osztályt és csak funkciókat tartalmazó osztályt. Ha így csinálod, akkor igazából az OO egyik lényegét veszted el és gyakorlatilag csak procedurális vagy funkcionális paradigmát használsz.

vagy orbitalis palyara allva gigawattos szuperlezerrel lo a legkisebb legyre is, es intergalaktikus pilotavizsga nelkul meg a kodot sem tudod elolvasni (Scala)

Nagyon nagy az eszközkészlete, ez igaz. Ez nem jelenti azt, hogy minden eszközt mindig kell használni. Azt sem, hogy egy-egy eszközt ne lehetne jól, érthetően használni. Lehetnek olyan megoldások, amik bonyolultnak tűnnek, pedig nem azok, csak akik nem ismerik, azoknak bonyolultnak tűnnek. Természetesen itt is lehetnek olyan megoldások is, amik valóban túl vannak bonyolítva, de ez nem azt jelenti, hogy ne lehetne egyszerűbben is megoldani. Sokak szerint a villás kulcskészlet is túl bonyolult, egy francia kulccsal is mindent meg lehet oldani és sokkal egyszerűbb. Ha valamit nem ismerünk, akkor bonyolultnak tűnik.

Ahogy mondani szoktak, az igazi programozo barmilyen nyelven tud FORTRAN-ban programozni :)

A villaskulcskeszlettel pedig csak annyi a problema, hogy az ember a szuper eszkozeivel a kezeben hajlamos elfeledkezni arrol, hogy neha nincs szukseg tizenotfele meretu/tipusu csavarra, mert a problema megoldasahoz eleg egy kalapacs es par darab szog is.

Ez persze szemelyes velemeny, de en azt vettem eszre magamon Scalaban kodolas kozben, hogy sokkal tobbet altalanositok, mint kellene, es a vegen az egy szem println("hello world")-bol egy komplex tipusokkal korbebastyazott printelo architektura szuletik teljesen feleslegesen.

Ahogy mondani szoktak, az igazi programozo barmilyen nyelven tud FORTRAN-ban programozni :)

;) Így igaz!

A kalapács is ott van az eszközkészlet között. Amit és ahogyan a Java-ban (és még sok nyelvet itt fel lehet sorolni) meg lehet oldani, azt ugyanúgy vagy nagyon hasonlóan, ugyanazon vagy nagyon hasonló eszközökkel meg lehet oldani Scala-ban is. Az, hogy vannak egyéb eszközök is, amikkel szebben, jobban, gyorsabban meg lehet oldani a problémát, az szerintem nem hátrány, hanem előny.

A végéhez pedig csak ennyit: A hiba nem az Ön eszközében van! ;)

"Nem az a kérdés, hogy OOP, vagy nem OOP, hanem hogy mi kellene helyette.

A cikk főleg rizsát tartalmazott (trollkodás), megoldások helyett."

+1

Kétségtelen, hogy az OOP-nek vannak hátrányai és problémái, de az szintén kétségtelen, hogy minden másnak is, csak mások.

És még ha is kérdés, hogyha esetleg meg is mondanák, hogy melyik az az egy paradigma "to rule them all", akkor mi legyen azzal a mértéktelen mennyiségű létező kóddal, ami már benne van a világban.

Nem az a kérdés, hogy OOP, vagy nem OOP, hanem hogy mi kellene helyette.
A cikk főleg rizsát tartalmazott (trollkodás), megoldások helyett.

Benne van a cikkben is (Procedural programming), a videóban pedig még jobban kifejti, a példás videóban további adalékkal szolgál és részletesen bemutatja példákon keresztül.

( NevemTeve | 2016. 11. 27., v – 14:28 )

Off: bizonyára értékes gondolatok vannak benne, ha írásban lenne, valószínűleg elolvasnám.

Ilyen témákra a video mint médium teljesen alkalmatlan.

Elfogadom, hogy vannak akik számára alkalmatlan, de a számtalan konferencia és hasonló videó azt bizonyítja, hogy sokak számára nagyon is jó ez a formátum. Ráadásul még a szakmai szövegértésed is javul, ha sok ilyet hallgatsz.

vért izzadva túlbonyolított példakódok, amiket az OOP ellenesek valaha is ki tudnak találni :)

Már bocs, de ezt a négy kódot az OOP nagyszerűségére hozták létre és mutatták be előadásokon OOP rajongók (mesterek, de semmiképpen sem ellenesek), annak bemutatására, hogyan kell az OOP-t jól alkalmazni.

"Elfogadom, hogy vannak akik számára alkalmatlan, de a számtalan konferencia és hasonló videó azt bizonyítja, hogy sokak számára nagyon is jó ez a formátum."

Nem lehet benne keresni, nem lehet a példakódokat kimásolni, nem lehet belőle idézni, nem lehet a trükkös részeket lassabban olvasni, nem lehet stbstb.
Aludva rá egyet én már inkább afelé hajlok, hogy your argument is invalid, ha videóban teszed közzé.

Számtalan projekt OOP-ben készül, ami azt bizonyítja, hogy sokak számárá nagyon is jó az a paradigma :)

"Már bocs, de ezt a négy kódot az OOP nagyszerűségére hozták létre"

Sajnos nem jutottam el a példakódokig.

Nem lehet benne keresni, nem lehet a példakódokat kimásolni, nem lehet belőle idézni, nem lehet a trükkös részeket lassabban olvasni, nem lehet stbstb.

Gondolom emiatt filmeket sem nézel, csak könyveket olvasol.
Ez egy más műfaj, mások az előnyei, hátrányai. Egyik sem helyettesíti a másikat. Egyik műfaj lehet jobb valakinek, a másik másoknak. (Én mind a kettőt szeretem.) Szíved joga, ha valamelyiket nem fogyasztod, de így lemaradsz egy csomó jó, értékes dologról.

Hogy jönnek ide a filmek?
Nézek filmeket, de azokban történeteket mesélnek, nem programkódokat magyaráznak.

"Ez egy más műfaj, mások az előnyei, hátrányai."

Előnyei? Ez a videó egymást követő statikus képekből áll, amelyek nagyrészt szöveget vagy programkódot tartalmaznak...

Hogy jönnek ide a filmek?

~Nem lehet benne keresni, nem lehet a szövegeket kimásolni, nem lehet belőle idézni, nem lehet a trükkös részeket lassabban olvasni, nem lehet stbstb. Szemben a(z elektronikus) könyvekkel.

Egyébként a Downsub-bal letöltheted az előadást szövegesen és így máris mindent meg tudsz csinálni, amiket írtál.

Előnyei?

Általában kevesebb idő ugyanazt megnézni, mint elolvasni. Egész más élményt ad egy videó, mint egy cikk (pl. számít a hangsúly, hanglejtés, mire mennyi időt fordít). Vannak olyan előadók, akiket különösen szeretek, pl. Venkat Subramanian. Tőle ezerszer inkább megnézek bármit, mint elolvasnám.

Az igazság valahol középen van. Én is szeretek előadásokat, videó tutorialokat nézni, de programozói cuccoknál az előadás után szívesen látnám ugyanazt leirva, cikként, like, railscasts-asciicasts. Ugyanaz, csak szövegben, közbe szúrt illusztrációkkal. It's that simple.

--
Blog | @hron84
Üzemeltető macik

Nincs középen az igazság! ;)

Ez az én álláspontom:

1. Ha csak leírva van egy jó cikk, az nagyon jó.
2. Ha csak videón van egy jó előadás, az szintén nagyon jó.
3. Ha videón is megvan és le is van írva, az meg a legjobb.

Ezzel szemben van az az álláspont, hogy
2. Ha csak videón van egy jó előadás, az nem ér semmit.

Ebben a szálban erről megy a vita.