@Gerilgfx:

senki sem vitatta azt, hogy a - saját hülyesége folytán - egy időben viszonylag sokat nélkülözött, de azért ebben az esetben kezeld némi fenntartással a magyar wiki szócikket

vagy legalább szörfölj egy kicsit a

__nemzetközi wikipedian__:)

a wikipedia szerint:

a felségének a bátyja ekkoriban a porosz belügyminiszter volt

Ferdinand von Westphalen
de.wikipedia.org/wiki/Ferdinand_von_Westphalen

(bocsi tévedtem nem Marx apósa hanem a sógora volt a porosz belügyminiszter)

+ voltak egyéb igen gazdag rokonok is jelesül Lion Philips (igen, nem tévedés hozzá kötődik a mai __Philips Művek__)

ő volt Karl Marx egyik fő szponzora és hitelezője az 1850-es években (a családi örökség terhére hitelezett a derék Marxnak... Marx szülei ugyanis __gazdagok__ voltak...)

Lion Philips - Relatie met Karl Marx
nl.wikipedia.org/wiki/Lion_Philips#Relatie_met_Karl_Marx

ergo, volt kit fejni

pl. Jenny anyja még egy cselédet is küldött nekik

Helene Demuth
en.wikipedia.org/wiki/Helene_Demuth

akit a derék "emberszerető" Marx valamikor 1850 táján teherbe ejtett

Frederick Demuth
en.wikipedia.org/wiki/Helene_Demuth#Frederick_Demuth

ráadásul letagadta a gyereket és rendkívül "gáláns" módon Engels cimborájára kente az egészet, aki egyszerűen árvaházba rakta a csöppséget... pedig ő felettébb gazdag volt...

summa summarum __személyzetük__ még a legszegényebb periódusban is volt...

A Nathan Mayer Rothschild vonal meglehetősen zavaros azonban azt nem lehet letagadni, hogy __egy városban__ éltek és __rokonok__ voltak...

Nathan Mayer Rothschild - Family
en.wikipedia.org/wiki/Nathan_Mayer_Rothschild#Family

sokak szerint a ő is szponzorálta Marxot...

Did you Know Karl Mark was related to the Rothschilds?
www.youtube.com/watch?v=2fh5aA-77MY

Bejegyzés: Miért bukott el a baloldal?

+1

Bejegyzés: Észak-Korea és a tanulságok

Ez
NAGYON
jó volt.
Grat.

Bejegyzés: Csillapíthatatlan éhség

@Gerilgfx: Nem ugyan azt csinálod.
1. Az egységbe zárással kapsz egy stabil API-t.
2. És emellé általában kapsz öröklődést vagy valamilyen interface rendszert.
3. És polimorfizmust.

Ez nagyon erőteljes API-hoz vezethet, lásd például Java Collection API-t.

Példaként, és ezzel az 1-es pontodra is rácáfoljak, ha objektumok fizikáját modellezed, és mondjuk van mind hajó, mind jármű, mind repülő, akár vonatok is, s többféle fizikai model implementációval, akkor valahogy így updateled az összes entity fizikáját többszálon, Javaban:

entities.parallelStream().forEach(e -> e.tick());

Bejegyzés: Mi a baj az objektumorientált programozással?

@B Tomi: franciaország, és az egyesült királyság erős jóindulattal sem számítható a középeurópai régióhoz. ez a cikk a nato keleteurópai erőinek oroszországgal való szembeállításáról szól. a nem nato skandináv országok szerintem irrelevánsak. oroszország ma már képes 100%-ban az önfenntartásra (minden szempontból, beleértve a hadieszközöket, vagy épp akár a processzorgyártást is). keleteurópa erre nem képes semmilyen szempontból. a számadatok pontatlanok, pontos számadatot nem is lehet, hisz a hadrafogható gépek száma akár egy hónap alatt jelentősen megváltozhat valamilyen irányba. amit ebből a témából amatőr módon ki tudtam hozni, azt kihoztam.

Bejegyzés: A NATO megvéd

@Gerilgfx: A számadatokat értelmezni is tudni kell. Az általad említett 3000 gépbe beletartoznak a helikopterek, szállító- és kiképzőgépek. Vadászgépből ugyanezen forrás szerint 806 van nekik. Ha már autóskártya-szintre egyszerűsítjük az összehasonlítást, ezt kell összevetni a török+francia+lengyel+német+angol+olasz+norvég számokkal: 207+296+99+92+88+79+46=907. Ez még nem az összes európai NATO ország, és még nem számoltunk az itt állomásozó amerikai haderővel és a nem NATO tag skandináv államokkal plusz az orosz eszközök földrajzi eloszlásával.

A NATO oldaláról nem tudom, miért pont ezeket az országokat vizsgáltad, a wikipedia által forrásként megjelölt www.globalfirepower.com/countries-listing.asp listája szerint a NATO-n belül Franciaország, az Egyesült Királyság és Németország is erősebb katonai potenciállal bír. A linkelt honlapon a katonai potenciál tekintetében valóban Oroszország szerepel a második helyen, de itt olyan faktorokat is figyelembe vettek, mint a gazdaság önfenntartósága, nyersanyagok és lakosság. Ezeknek támadóértéke nyilvánvalóan nincsen, csak azt határozza meg hogy egy elhúzódó háborúban gazdasági blokád alatt meddig képesek túlélni.

Bejegyzés: A NATO megvéd

@feamatar: a ,,vagy nem fog objektumként viselkedni'' részt nem úgy értettem, hogy megszeged az oop paradigma szabályait, hanem úgy, hogy ez így nem praktikus, mert így ugyanazt csinálod, mint amit objektum nélkül csinálnál, és ehhez az oop nem praktikus. egy vászondzsekihez tornacipőt is felvehetsz, hisz a dzseki-dresszkód engedélyezi, sőt, előírja a cipő viselését is. de ha tornacipőt akarsz viselni, ahhoz nem kell dzseki. a normálvektort kiszámíthatod függvényben, de ahhoz nem kell oop sem. ha én tornacipőt akarok venni, ahhoz még nem feltétlenül húzok vászondzsekit, de nincs arról szó, hogy a tornacipőhöz ne húzhatnál vászondzsekit, csak épp minek húznál hozzá? a téma túl van tárgyalva, és nem látom, hogy az oop mellett állna bármi olyan tény, amit csak azért ne lehetne itt megvilágítani, mert én csak a c++-on keresztül tudom kontextusba hozni.

Bejegyzés: Mi a baj az objektumorientált programozással?

@Gerilgfx: Megint kérlek próbáld kettéválasztani az objektum orientált programozást a konkrét programozási nyelvtől. A bejegyzésed elvileg nem a C++-ról szól, hanem az OO-ról általánosságban.

Ugyan úgy kértelek, hogy oszt meg, honnét jutottál arra a következtetésre hogy, A "nem kell mindig kiszámolni a normálvektort, csak ha szűkséges. Tehát létrehoztál egy objektumot, amely vagy nem fog objektumként viselkedni többé, ".

Ide másolom a definíciót a Wikipediáról, ha már arra hivatkoztál:
Encapsulation is an Object Oriented Programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse.
Tehát adat és a rajta végezhető függvények összekapcsolása. Nincs szó arról, amit állítasz, hogy a normál vektort ne lehetne épp egy függvényben kiszámítani. Ami a teljes kettes pontodat érvényteleníti.

Kérlek tartsuk a beszélgetést a kettes pontnál, ne hozz be új elemeket. Persze, ha azt nem tudod alátámasztani, megvizsgálhatjuk a többi állításodat is. De mindenképp egyszerre csak egyet.

Bejegyzés: Mi a baj az objektumorientált programozással?

@feamatar: tudom, hogy a java most a legnépszerűbb oop-s nyelv, de mivel azt nem ismerem (sosem használtam, és nem is tervezem használni), így arról nem tudok nyilatkozni semmilyen formában, ezért emeltem ki a c++-t (ha már azzal kapcsolatban is linkeltél).

az egységbe zárást tekintve maradhatunk a wikipedia definíciójánál (isten ments, hogy újakat akarjak kitalálni helyette). nézd meg alaposan az általad linkelt cpp forrást az állításaidra - sőt, legyen ez a forrás az én állításaimra is, vegyük úgy, hogy ez a vektorok oop kezelését ügyesen bemutatja minden szemszögből.

-van három féle kiszámítás a vektor hosszára (vagy legalábbis én annyi félét látok), aztán mégegyszer majdnem ugyanez 3d-ben. ezek objektumokba vannak bugyolálva. maga az a tény, hogy oop-t használtál, és a koordinátákhoz nem egy egyszerű pointert, meghosszabbította, és elbonyolította a kódot, növelte a bonyolultsági fokát feleslegesen. nyilván azért van háromszor implementálva, hogy ahol lehet, kihagyják a gyökvonást. ez a számítógép szintjén dolgozva nagyban gyorsítja a működést, csak ezzel a procerudális nyelvek hardverközeli gondolkodásához próbáltál lenyúlni olyan módon, hogy az egész egy olyan objektumbugyiban van benne, amivel már feleslegesen elégeted az órajeleket, és feltoltad a bonyolultságot.

-ráadásul a dolgok a header fájlban vannak implementálva (elég nagy gányolás, ráadásul így a bináris kódjuk többszörösen beszúródik)

-mindenféle logika mentén eltárolt értékekhez külön-külön függvények vannak implementálva feleslegesen, kizárólag azért, mert OOP koncepcióba kellett kényszeríteni az egész kódot (van, ahol a saját adattípusát, van, ahol sima floatot használ a műveletekhez). Később aztán az idvec2 mellé behoz mégegy idvec3-mat, ami ugyanez, csak 3 dimenzióban, és az egyikből áthozni a másikba az adatot szexuális kifejezéssel élve a seggből szájba tipikus esete

-az egész koncepció kényszeredetten objektumosít, mindenféle kétbetűs butaság kedvéért külön függvényt kell implementálni (pl skalár szorzat), és ha épp az adatot valahogy máshol/máshogy tároltad le, akkor hozhatod össze az egészet

-ebben a kódban látszik, hogy a készítők mindent attribútumokká gyúrtak, amit csak bírtak, ezt épp te bizonyítod ezzel az examplevel, úgyhogy én már nem is törném magam, hogy más linkeket keressek hasonló kódra (gyaníthatóan majdnem mind ilyesmi lenne). persze megengedhetjük - és miért ne tehetnénk - főleg, ha még a nyelv is megengedi (a c++ megengedi), hogy ne legyen attribútum az, ami oda nem annyira való. ha te azt mondod, hogy az objektumorientáltság azt mondja, hogy dobjuk ki az oop esszenciáit akkor, amikor nincs értelme, akkor tegyük fel, hogy úgy van. NA DE akkor viszont elkezdődik a classok leeresztése, az oda nem illő attribútumok kiszórása a classekből. ezzel az általad linkelt doom3-mas vektor classokból konkrétan egy betű sem fog maradni, minden rövid, egyszerű C kóddá fog szétpottyanni, egy egyszerű függvénylistává rövid implementációkkal, pointerekkel, ami a sebesség, az egyszerűség, a használhatóságra igencsak jótékony hatással lenne, például jó néhány esetben ki lehetne hagyni az értékadásokat, inicializálásokat, a memory managert, a stacken való felesleges objektumzsonglőrködést a mókából, ráadásul még a headerből is ki lehetne írtani a kódot, ami a cachehasználatra is jótékony hatással lenne valamelyest. (persze utána nem lehetne a+=b módszerrel vektorokat összeadni, hanem le kéne írni kézzel a függvény nevét - nyilvánvalóan szerencsétlen kóder, aki ezt így megcsináltatta valakivel, azt hitte, hogy ezzel majd egyszerűbbé válik a vektorok használata az egész kódban, pedig pont, hogy ezzel rákosította be az egészet, lehet, hogy pont maga JC volt az, nem lepne meg). ennek a kódnak a létezését tehát egyetlen dolog teszi lehetővé - méghozzá az a törekvés, hogy mindenből attribútum legyen, hisz máskülönben azt a maradék egészen kicsi létjogosultságát is elveszti.

-ezzel a kóddal mindenképp kidobod a fürdővízzel a gyereket: vagy az oop miatt lesz szar az egész, vagy ha rendesen meg akarod csinálni, akkor oop nélkülivé válik az egész, tehát eleve megy a szemétbe az egész kód.

-nem mondom, C-ben is lehet olyan fatális szörnyűségeket elkövetni, mint ez a kód. ha ezt 1:1 c-be átírod, akkor is szar marad, de csak akkor nyílik meg a lehetőség arra, hogy normálisan megcsináld.

és elfogytak az egy hozzászólásban legépelhető karakterek, azt hiszem, hogy az általad bemutatott kódrészlettel bemutattam minden aspektusát annak, hogy mi az, ami szerintem végzetesen bajos az oop-vel, tök jó, hogy ezt hoztad fel példának, mert ennél jobb állatorvosi lovat szeirntem keresve sem találhattam volna.

Bejegyzés: Mi a baj az objektumorientált programozással?

@Gerilgfx: Válaszod első mondata még az OOPre vonatkozik, míg a második már a C++ra. Ezt így nem feltétlen tudom értelmezni.

Javaslom maradjunk az OOP kritikájánál, hisz arról szól a bejegyzésed, nem a C++ kritikájáról.

Én mellékeltem 3 linket, amik demonstrálják, hogy OOP nem jelenti azt, hogy egy objektumon minden attribútumként lenne tárolva. Te esetleg alá tudnád támasztani valamivel az állításod?

Érdekelne például mi a forrásod az egységbe zárásra, mert a te értelmezésedet én még soha nem hallottam.

Bejegyzés: Mi a baj az objektumorientált programozással?

@Gabor_V: általánosítanom kellett.

Bejegyzés: A liberális mamutszakértő

Kevered a liberálist a szabadbölcsésszel.

Szófosó szagértegető neonácit ismerek, meg teljesen technokrata és gyakorlatias liberálist is.

Bejegyzés: A liberális mamutszakértő

@feamatar: köszönöm, de dolgoztam már több alkalommal oop-vel, nem azért, mert úgy akartam, hanem mert muszáj volt (és korábban pedig 5-ösre vizsgáztam c++-ból, mert az is muszáj volt). ennyi nekem épp elég volt ahhoz, hogy véglegesen ítéletet mondhassak felette, és a piac is ítéletet mondott felette akkor, amikor a cpp népszerűsége üstökösként kezdett lehuzanni (pl tiobe index). hamarosan holt nyelv lesz.

Bejegyzés: Mi a baj az objektumorientált programozással?

@Gerilgfx: Javasolnam olvass kicsit OOProl, mielott irni kezdesz rola.

"a hosszát kiszámolni a classba helyezett függvény segítségével pedig nem más, mint csendes elismerése annak, hogy csak procedurális megoldással lehet ezt a problémát rendesen megoldani. csak épp a vektor pointere helyett a compiler az objektum pointerét zsonglőrködi át, de maga a problémára már effektíve egy procedurális megoldás született. " - Amit leirsz az az OOP egyik alapeleme, az encapsulation. Az adatot és a hozza tartozo fuggvenyeket egysegbe zarjuk. Az, hogy ez gepi kodra hogy fordul az mellekes.

Itt van egy alapozo C++ tutorial, hogy megertsd:
www.cplusplus.com/doc/tutorial/classes/

Vagy a vektoros peldad C++ illetve Java nyelven:
github.com/TTimo/doom3.gpl/blob/master/neo/idlib/math/Vector.h
github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/math/Vector3f.java

Bejegyzés: Mi a baj az objektumorientált programozással?

@feamatar: az ember azért fejleszt, hogy implementáljon valamit. ez egy egyszerű példa, ahol a paradigma követése már kizárólag rossz alternatívákat eredményez.

1. a hosszot kiszámolni mindig nyilvánvalóan rossz megoldás, mert hasztalanul elégeti a sebességet. ebben egyet is értünk, a cikk is felhívja rá a figyelmet - csakhogy az objektumorientált ezt követelné meg, és nem pedig azt, hogy külön függvényt írj rá.

2. a hosszát kiszámolni a classba helyezett függvény segítségével pedig nem más, mint csendes elismerése annak, hogy csak procedurális megoldással lehet ezt a problémát rendesen megoldani. csak épp a vektor pointere helyett a compiler az objektum pointerét zsonglőrködi át, de maga a problémára már effektíve egy procedurális megoldás született. a helyzet problematikája akkor fog kicsúcsosodni, ha folytatod a kódot: az oop itt annyit tett, hogy a koncepciójára hivatkozva egy függvényt az adatok mellé implementáltatott, tehát ezt a függvényt innentől kezdve lehet átmásolni vagy több objektumhoz, vagy öröklés útján lehet összehackelni egymással az esetlegesen össze sem illő osztályokat CSAK azért, hogy ezeket a függvényeket (amelyek csak ideológiai okok miatt lettek classek részeivé) máshonnan is el lehessen érni.
az oop lényege a valódi világ leképezése lenne, amelyet ezen a példán el is bukik, hisz csak hagyományos megoldások koncepcióba erőszakolásával lehet bármiféle eredményt elérni, de mindenféleképpen sokkal roszabb az eredmény (vagy lasabb kódot csinál, és/vagy kényelmetlenebb használni, és/vagy sokkal tovább tart csinálni, és/vagy sokkal hoszabb kódot eredményez bármiféle előny nélkül).

Bejegyzés: Mi a baj az objektumorientált programozással?

@Gerilgfx: "Tehát létrehoztál egy objektumot, amely vagy nem fog objektumként viselkedni többé, " -> ez az allitas ami nem igaz. Az ugyanis, hogy egy vektor objektum eltarolja a hosszat, vagy biztosit egy fuggvenyt ami kiszamolja, netan cacheli az erteket az implementacios kerdes, nincs koze ay objektum-orientalt paradigmahoz.

Bejegyzés: Mi a baj az objektumorientált programozással?

@feamatar: kedves feamatar, a hozzászólásban leírtakra ott van a magyarázat cikkben minden esetben, például konkrétan a vektoros példával kapcsolatban leírtakra is elég nyilvánvalóan le van írva - még az is, hogy csak akkor kell kiszámolni, ha szűkség van rá, méghozzá szinte ugyanazokat a szavakat használva, mint a hozzászólásban. Így aztán nem tudom mire vélni a hozzászólást.

Illetve dehogynem, tisztában vagyok vele, hogy ez már-már szinte egy átideologizált téma sokaknak, és ezért vigyázni is kell azzal, hogyan nyújtjuk-alakítjuk a fogalom határait, mint ahogy ez a politikában így van: ,,uraim, önök addig mennek jobbra, amíg megérkeznek balra''.

Bejegyzés: Mi a baj az objektumorientált programozással?

Tisztelt gerilgfx, a számos hiba közül, ami a bejegyzésben van, hadd emeljem ki a teljesen hibás vektoros példát.

A példának semmi értelme nincs. Objektum orientált programozás elsősorban az adat és a hozzájuk tartozó metódusok egységbe zárásáról szól, reprezentációról szó sincs.

A vektoros példa esetén, az objektum nem köteles a vektor hosszát állandóan fejben tartani, elég, ha akkor számolja ki ha arra szükség van. S persze a kettő között még van egy-kettő opció.

Ezenkívül nem mennék bele, hogy az objektum orientáltság egy tág fogalom. Mivel Önnek az írása alapján hiányzik a tágabb tudása a programozási paradigmákról, tanácsolnám hogy olvasson utána milyen nagy különbségek vannak e módszernek az implementálásába a különböző nyelvekben.

Bejegyzés: Mi a baj az objektumorientált programozással?

@Zalai Béla: köszönöm, de jótanácsot csak olyanoktól fogadok el, akiknek sikerült

Bejegyzés: CEU - Magyarország legjobb egyeteme

Nem a felsőoktatással van baj, Gergely. Fogalmazni és helyesen írni az általános iskolában kellett volna megtanulnia.

Bejegyzés: CEU - Magyarország legjobb egyeteme