ugrás a tartalomhoz

The repeated deaths of OOP

MadBence · 2015. Feb. 10. (K), 11.15
Az objektumorientált programozás halála?
 ■
1

Looking at the big picture, I

Joó Ádám · 2015. Feb. 10. (K), 11.19
Looking at the big picture, I can see that object orientation is not a paradigm, but a set of mechanics we can cherry pick. Yet we continue to treat it as if it were a unified concept.

I think this is why "OOP" survived this long. Without a definite definition everyone can agree on, its meaning keeps mutating beyond recognition as we change our programming practices.


Fentieket magam is rendszeresen megfogalmazom az OOP körül folyó viták kapcsán. Ebből is következik, hogy az OOP sosem fog meghalni, talán csak végre felismerjük, hogy sosem létezett.
6

A cím természetesen

MadBence · 2015. Feb. 10. (K), 11.38
A cím természetesen hatásvadász :), az OOP nyilvánvalóan nem zsákutca.
8

És ez mitől nyilvánvaló?

Hidvégi Gábor · 2015. Feb. 10. (K), 11.40
És ez mitől nyilvánvaló?
22

Mert külön-külön mindegyik

Joó Ádám · 2015. Feb. 11. (Sze), 16.01
Mert külön-külön mindegyik alkotóelemét sikerrel használják „nem OOP” nyelvek.
28

Együtt valamiért mégsem a

Hidvégi Gábor · 2015. Feb. 11. (Sze), 16.26
Együtt valamiért mégsem a leghatékonyabb, lásd pl. a Go-ból is kihagyták az öröklődést, de a funkcionális programozásban is legfeljebb egy-kettőt használnak.
35

És honnan tudjuk, hogy

Joó Ádám · 2015. Feb. 11. (Sze), 16.44
És honnan tudjuk, hogy azoknak van igaza, akik kihagynak egy eszközt, és nem azoknak, akik implementálnak? A Goban kivételek, generikus típusok és function overloading sincs. Ebből az elsőt második körben részben mégis behozták, a másodikat lehetséges, hogy egyszer behozzák, a harmadikat meg azért hagyták ki, mert így egyszerűbb a fordító dolga. Ettől bármelyik rossz eszköz lesz?
39

Ha a panic-ra gondolsz, akkor

Hidvégi Gábor · 2015. Feb. 11. (Sze), 16.55
Ha a panic-ra gondolsz, akkor az egy nem ajánlott módszer. Azt is alátámasztották, miért jobb az általuk használt hibakezelés, mint a kivételek. A kivételeket te is kritizáltad korábban, mert lassúak.

Az, hogy kinek van igaza, az idő dönti el. A nyelvekben a fenti eszközök jóideje léteztek, a Gót tudatos tervezés előzte meg, és így döntöttek a kihagyásukról.
43

A kivételeket te is

Joó Ádám · 2015. Feb. 11. (Sze), 17.08
A kivételeket te is kritizáltad korábban, mert lassúak.


Elsősorban nem azért, nekem a statikus analízis hiánya a bajom, de ennek elvi akadálya nincs.

Az, hogy kinek van igaza, az idő dönti el. A nyelvekben a fenti eszközök jóideje léteztek, a Gót tudatos tervezés előzte meg, és így döntöttek a kihagyásukról.


És mielőtt jóideje léteztek, az előtt nem léteztek, így egyelőre az idő már döntött is. Persze ez nem azt jelenti, hogy később nem változhat a felfogásunk, aztán egy idő után újra, csak egy-egy nyelv választásaival nem nagyon lehet bármit is alátámasztani.
64

És mielőtt jóideje léteztek,

Hidvégi Gábor · 2015. Feb. 12. (Cs), 10.13
És mielőtt jóideje léteztek, az előtt nem léteztek, így egyelőre az idő már döntött is.
Ezt az érvelést nem gondolhatod komolyan.

egy-egy nyelv választásaival nem nagyon lehet bármit is alátámasztani
A Go két fő tervezője Rob Pike és Ken Thompson. Rob Pike több mint harminc éve foglalkozik programozási nyelvekkel, és tervezett is párat. Ken Thompson 45 éve alkotta meg a C elődjét, a B-t, majd részt vett a C elkészítésében.

Ezek az emberek pontosan tudják, hogy mit miért tesznek, amikor programozási nyelvről van szó.
65

Ezt az érvelést nem

Joó Ádám · 2015. Feb. 12. (Cs), 10.59
Ezt az érvelést nem gondolhatod komolyan.


Te sem gondolhatod komolyan, hogy véletlenül születtek meg ezek az eszközök.

A Go két fő tervezője Rob Pike és Ken Thompson. Rob Pike több mint harminc éve foglalkozik programozási nyelvekkel, és tervezett is párat. Ken Thompson 45 éve alkotta meg a C elődjét, a B-t, majd részt vett a C elkészítésében.


Ezek a nyelvek mind a Bell Labs egykori csapatának igényei szerint, egy bizonyos felhasználási területhez készültek. Nem is nagyon alkalmasak bizonyos komplexitás fölött karbantartható kód írására.
68

Te sem gondolhatod komolyan,

Hidvégi Gábor · 2015. Feb. 12. (Cs), 11.33
Te sem gondolhatod komolyan, hogy véletlenül születtek meg ezek az eszközök.
Egy szóval sem állítottam. Viszont tudatos tervezési döntés volt, hogy a Góba nem kerültek bele a C++-os sablonok, a kivételkezelés, az öröklődés és társaik. Kipróbálták, nem hozták meg a várt hasznot, így nem emelték bele az eszközkészletbe.

Ezek a nyelvek mind
Nem a B-ről és C-ről beszéltem, hanem a Go-ról. Azokat csak példaként hoztam arra, hogy a Go tervezői már mióta vannak a szakterületen.
71

Viszont tudatos tervezési

Joó Ádám · 2015. Feb. 12. (Cs), 13.11
Viszont tudatos tervezési döntés volt, hogy a Góba nem kerültek bele a C++-os sablonok, a kivételkezelés, az öröklődés és társaik. Kipróbálták, nem hozták meg a várt hasznot, így nem emelték bele az eszközkészletbe.


És tudatos döntés az is, amikor egy új nyelv meg beemeli őket.

Nem a B-ről és C-ről beszéltem, hanem a Go-ról.


A Go pont ugyanúgy egy minimalista nyelv, ahogy a C is az volt a maga idejében.

Azokat csak példaként hoztam arra, hogy a Go tervezői már mióta vannak a szakterületen.


Ez önmagában nem jelent sokat.
87

Ezek a nyelvek mind a Bell

Hidvégi Gábor · 2015. Feb. 13. (P), 11.07
Ezek a nyelvek mind a Bell Labs egykori csapatának igényei szerint, egy bizonyos felhasználási területhez készültek. Nem is nagyon alkalmasak bizonyos komplexitás fölött karbantartható kód írására.
Mi az a komplexitás, aminek a Go a te definícióid szerint nem felel meg és miért? A C-re valóban igaz, hogy nagyobb projektekre nem feltétlenül a legalkalmasabb választás, bár érdekes módon sok linuxos rutinkönyvtárat mégis ebben írnak.
2

Vörös posztó

Hidvégi Gábor · 2015. Feb. 10. (K), 11.22
Ezt hiba volt beküldeni.
3

Miért?

MadBence · 2015. Feb. 10. (K), 11.27
Miért?
4

Mert az egész koncepció

Hidvégi Gábor · 2015. Feb. 10. (K), 11.31
Mert az egész koncepció rendkívül ingatag lábakon áll. Lásd öröklődés, amit jobb helyeken már igyekeznek elkerülni, mert több problémát okoz, mint amennyit megold. Emellett ahány embert kérdezel, annyiféleképp definiálják az OOP-t.
5

Elolvastad az írást? Épp

Joó Ádám · 2015. Feb. 10. (K), 11.33
Elolvastad az írást? Épp erről szól.
7

És engem hányszor kívántak

Hidvégi Gábor · 2015. Feb. 10. (K), 11.38
És engem hányszor kívántak már az örök vadászmezőkre, amikor ezt hangoztattam?
23

Az írás arról szól, hogy az

Joó Ádám · 2015. Feb. 11. (Sze), 16.03
Az írás arról szól, hogy az OOP egy rosszul definiált fogalom. Te azt hangoztatod, hogy az OOP rossz módszertan, miközben saját bevallásod szerint sem tudod, hogy mi is az (mert rosszul definiált fogalom).
30

Hogyan lehet egy módszertan

Hidvégi Gábor · 2015. Feb. 11. (Sze), 16.33
Hogyan lehet egy módszertan jó, ha a világon – kis túlzással – nincs két ember, aki meg tudna egyezni róla, hogy mi is az tulajdonképpen?

Az OOP egy rosszul definiált fogalom, melynek alkotóelemei instabilak (lásd öröklődés) és kontraproduktívak (lásd adatok és hozzájuk kötött függvények). Ha valaki számára ez nem elég intő jel, akkor az végtelenül optimista vagy túlságosan konzervatív.
34

Hogyan lehet egy módszertan

Joó Ádám · 2015. Feb. 11. (Sze), 16.40
Hogyan lehet egy módszertan jó, ha a világon – kis túlzással – nincs két ember, aki meg tudna egyezni róla, hogy mi is az tulajdonképpen?


A procedurális programozás sem egy egzakt fogalom. Az eljárás már inkább. Meg a polimorfizmus. Az eljárások jók. A polimorfizmus is.

alkotóelemei instabilak (lásd öröklődés)


Az öröklődés egy implementációs eszköz és nincs vele semmi baj, ha nem mindent azzal akarsz megoldani.

és kontraproduktívak (lásd adatok és hozzájuk kötött függvények)


Ezt még sehogy nem támasztottad alá.
9

OK, döglődik, halott. Mi van

pythonozok · 2015. Feb. 10. (K), 11.41
OK, döglődik, halott.
Mi van helyette?
Azt ne mondjátok, hogy a funkcionális, mert amiben a változó valójában konstans... az nem lesz túl népszerű. :)
Vissza a gyökerekhez, újra elővesszük a procedurális dolgokat?
Vagy merre tovább?
(bocs, nem tudtam végigolvasni az egészet, de átfutva rajta nem láttam, hogy ajánl-e valamit OOP helyett)
10

Procedurális

Hidvégi Gábor · 2015. Feb. 10. (K), 11.46
Nincs egy út. A procedurális programozással nincs semmi gond, közelebb áll a gondolkodáshoz, mint a funkcionális, bár ez utóbbiban is vannak jó ötletek. Szerintem a kettő keveréke lehet a megoldás.

A funkcionális programozásban átestek a ló másik oldalára, amikor egyáltalán nem bíznak a programozóban, és nem engednek meg állapotot tárolni. Ez első és második hallásra is elég vad dolog.

Procedurális programozásban arra kell ügyelni, hogy a függvényeink lehetőleg ne használjanak globális változókat, azaz ugyanolyan paraméterekkel meghívva mindig ugyanazt az eredményt adják vissza.
12

Szerintem soha nem az eszköz

virág · 2015. Feb. 10. (K), 12.43
Szerintem soha nem az eszköz végül a mérvadó, hanem az aki használja... Egy jó szobrászművász egy egyszerű kalapáccsal és vésővel is jó szobrot csinál, egy rosszabb pedig használhat lézert, akkor is a legjobb esetben valami giccs jön ki a keze alól... Valakik Basic-ben is remekműveket írtak és vannak akik Java-ban, vagy C#-ben is borzalmat hoznak össze. Én nem hiszek az eszközök mindenhatóságában.
13

Részben igaz

Hidvégi Gábor · 2015. Feb. 10. (K), 13.02
Az évek során az OOP egyre összetettebbé vált. Először vala az öröklődés, polimorfizmus, zártság. A négyek bandája ezt megfejelte a tervezési mintákkal, amik közül manapság már nem mindegyik kívánatos (pl. singleton). Ez később kiegészült azzal, hogy ha jó OOP programot szeretnél írni, be kell tartanod a SOLID elveit. Aztán bejött a függőségkezelés, tesztelhetőség.

Így a legjobb programozónak is egyre nehezebb dolga van, ha jó OOP programot szeretne megírni. Szerintem sokkal kifizetődőbb a lehető legegyszerűbb szoftver megírására törekedni, és a lehető legkevesebb és legegyszerűbb eszközt használni.
25

Először vala az öröklődés,

Joó Ádám · 2015. Feb. 11. (Sze), 16.17
Először vala az öröklődés, polimorfizmus, zártság.


Ezek közül egyedül a polimorfizmus az, ami nem létezett korábban.

A négyek bandája ezt megfejelte a tervezési mintákkal


A tervezési minták nem az objektumorientált programozás sajátjai.

Ez később kiegészült azzal, hogy ha jó OOP programot szeretnél írni, be kell tartanod a SOLID elveit.


Mert más programozási paradigmák esetén nem kell alkalmazzál bizonyos elveket, hogy jó programot írj?

Aztán bejött a függőségkezelés, tesztelhetőség.


Más programozási paradigmával írt programokat nem kell tesztelni? Amit a polimorfizmus hihetetlenül megkönnyít.

Így a legjobb programozónak is egyre nehezebb dolga van, ha jó OOP programot szeretne megírni.


A programozónak bármilyen paradigma mellett egyre nehezebb dolga van, ha jó programot akar írni, mivel egyre magasabbak az elvárásaink.
32

Bárcsak egyszer elolvasná az

bamegakapa · 2015. Feb. 11. (Sze), 16.39
Bárcsak egyszer elolvasná az ilyeneket és legközelebb eszébe is jutnának, mielőtt belefog a szokásos mantrákba.
44

Mostanában nem először van

Hidvégi Gábor · 2015. Feb. 11. (Sze), 17.22
Mostanában nem először van olyan érzésem, mintha megpróbálnál félremagyarázni dolgokat. Ez nem nehéz, ha kiemelünk valamit a szövegkörnyezetéből.

Ezek közül egyedül a polimorfizmus az, ami nem létezett korábban.
Ez a fentire egy jó példa. Eredetileg így szólt: "Az évek során az OOP egyre összetettebbé vált. Először vala az öröklődés, polimorfizmus, zártság." Ezek az elvek együtt az OOP-ben jelentek meg a Simula 67-ben és a Smalltalkban.

A tervezési minták nem az objektumorientált programozás sajátjai.
Nyilván. De ha elolvasod a wikipédia cikkét, először az OOP-vel kapcsolatban merült fel, de igazán ismertté a fogalmat a négyek tették, és általában az OOP-vel kapcsolatban említik.

Az újabb és újabb elveket nagyon meg kell szűrni, mert nem feltétlenül lesz tőlük egyszerűbb a program, lásd függőségkezelés. A legcélszerűbb egyszerűségre törekedni, mert egyszerű programban lehet a legkevesebbet hibázni.
47

Mostanában nem először van

Joó Ádám · 2015. Feb. 11. (Sze), 17.55
Mostanában nem először van olyan érzésem, mintha megpróbálnál félremagyarázni dolgokat. … Ez a fentire egy jó példa.


Nincs ilyen szándékom, de nem is látom, hogy hol tennék ilyet.

Ezek az elvek együtt az OOP-ben jelentek meg a Simula 67-ben


Az öröklődés tisztán procedurális nyelvekben is létezik, egyszer majd utánajárok, hol jelent meg először. A zártság alatt nem tudom, mit értesz, ez is egy aluldefiniált fogalom.

először az OOP-vel kapcsolatban merült fel, de igazán ismertté a fogalmat a négyek tették, és általában az OOP-vel kapcsolatban említik.


Az, hogy a négyek írtak egy könyvet pár példával és adtak egy jól hangzó nevet a dolognak, és tették mindezt OOP környezetben, teljesen irreleváns. Ha nem létezne OOP, előbb-utóbbi valaki akkor is írt volna a kódszervezésben viszatérő mintákról.

Az újabb és újabb elveket nagyon meg kell szűrni, mert nem feltétlenül lesz tőlük egyszerűbb a program


Igen, és ezt a szűrést folyamatosan végzi a szakma, például ilyen vitákon keresztül, mint ez. És ennek ellenére ezek az elvek élnek és alkalmazzák őket. Valószínűleg azért, mert beváltak.
51

Öröklődés procedurális

pythonozok · 2015. Feb. 11. (Sze), 18.41
Öröklődés procedurális programban? Ehhez kérhetek példát?
52

struct a { int

Joó Ádám · 2015. Feb. 11. (Sze), 19.55
struct a {
    int foo;
};

struct b {
    struct a;
    int bar;
};
53

Hát ezt elég nagy

pythonozok · 2015. Feb. 11. (Sze), 21.03
Hát ezt elég nagy jóindulattal nevezhetjük csak öröklődésnek.
54

Miért? Tudja azt, amit az

MadBence · 2015. Feb. 11. (Sze), 21.35
Miért? Tudja azt, amit az öröklődés, a memóriaképét örökli. Ráadásul még polimorizmust is tud, nevezetesen ha akarom a-nak látszik, ha akarom b-nek.
55

Hogy látszik "a"-nak a

pythonozok · 2015. Feb. 11. (Sze), 21.39
Hogy látszik "a"-nak a "b"?
Ilyen alapon már az "a" definíciója is öröklődést tartalmaz, hiszen ott van benne egy int típusú változó...
56

#include <stdio.h> struct A

MadBence · 2015. Feb. 11. (Sze), 21.54
#include <stdio.h>
struct A {
  int foo;
};
struct B {
  struct A a;
  int bar;
};
int main() {
  struct B b = {.a = {.foo = 1}, .bar = 2};
  printf("foo: %d bar: %d\n", ((struct A*)&b)->foo, b.bar);
  // és amúgy tényleg int-ből "örököl"
  printf("int... %d\n", *(int*)&b);
}
57

Ha B örökölne A-tól, akkor a

pythonozok · 2015. Feb. 11. (Sze), 22.14
Ha B örökölne A-tól, akkor a b->foo hivatkozás működhetne minden trükközés nélkül. Így csak azért tud működni, mert nem az "ojjektumra" hivatkozol, hanem a memóriában elfoglalt címére. Amennyiben bekerülne B definíciójába, a "struct A a;" elé valami más változó, máris hibás lenne amit írtál. És ugye egy adatstruktúra nincs kőbe vésve, bármikor változhat a szerkezete, ezért nem ajánlott az effajta hivatkozás. (és számold hozzá, hogy van vagy húsz éve, hogy utoljára C-vel foglalkoztam! ;) )
58

Az, hogy az öröklődés nyelvi

MadBence · 2015. Feb. 11. (Sze), 22.32
Az, hogy az öröklődés nyelvi szinten hogy jelenik meg, az a nyelv dolga, az öröklődés, mint mechanizmus megoldható. Te kérdezted hogyan lehet :) (és gyakorlatilag a lefele kasztolás teljesen biztonságos, ha tényleg helyesen kasztolható). Amúgy ha nem csinálod feltűnően, akkor észre sem lehet venni:
#include <stdio.h>
struct A {
  int foo;
};
struct B {
  struct A a;
  int bar;
};

void printFoo(struct A *a) {
  printf("foo: %d\n", a->foo);
}
void printBar(struct B *b) {
  printf("bar: %d\n", b->bar);
}

int main() {
  struct B b = {.a = {.foo = 1}, .bar = 2};
  printFoo(&b);
  printBar(&b);
}
Mondjuk dob rá warningot, de ki figyel azokra :)
73

Vigyázz, én nem ezt írtam,

Joó Ádám · 2015. Feb. 12. (Cs), 13.19
Vigyázz, én nem ezt írtam, nem véletlen hagytam ki a struct a adattag nevét a kódrészletben.

Szabványos C-ben valóban így lehetséges.

Mondjuk dob rá warningot, de ki figyel azokra :)


Ha explicit kasztolod az argumentumot, akkor nem fog.
72

Ha B örökölne A-tól, akkor a

Joó Ádám · 2015. Feb. 12. (Cs), 13.15
Ha B örökölne A-tól, akkor a b->foo hivatkozás működhetne minden trükközés nélkül.


Működik. Ez egy viszonylag elterjedt kiegészítés a fordítókban. A C11 pedig már ha jól tudom, kanonizálta is.
81

Ha ez így, ebben a formában

pythonozok · 2015. Feb. 12. (Cs), 18.46
Ha ez így, ebben a formában működik... Számomra legalábbis hajmeresztő. ;) (és most szigorúan C-ről beszélünk, ugye? Tehát nem C#, C++, egyéb mutációk)

update: linuxon, az ubuntu 14.04-ben lévő gcc-vel nem is fordul le úgy, ahogy mondod. Amíg csak a deklaráció van, addig elfogadja, bár dob rá egy warningot, miszerint
warning: declaration does not declare anything [enabled by default]

Ha viszont hivatkozni próbálok a b-be ágyazott a foo tagjára, arra már error jön. Persze rég nem játszottam C-vel, lehet, hogy én rontom el.
82

Próbáld a -std=c11 vagy

Joó Ádám · 2015. Feb. 12. (Cs), 21.44
Próbáld az -std=c11 vagy -fms-extensions flaggel.
88

»A négyek bandája ezt

Hidvégi Gábor · 2016. Már. 19. (Szo), 10.37
»A négyek bandája ezt megfejelte a tervezési mintákkal«

A tervezési minták nem az objektumorientált programozás sajátjai.

Patterns by Type

Ha elolvasod a linkelt bekezdést, világossá válik, hogy azokat objektumokra és osztályokra képzelték el és ajánlják alkalmazásra a négyek. Ha procedurálisan vagy funkcionálisan dolgozunk, ezek nagy részének vagy egészének semmi értelme nincsen.

Az OOP tervezési minták egyébként valóban szükségesek, ha valaki objektumorientáltan programozik, mert nélkülük kezelhetetlenné válik a szoftver.
89

Software design patterns. És

BlaZe · 2016. Már. 19. (Szo), 11.30
Software design patterns. És akkor ezt most itt le is zártuk remélem.
90

Ezt most nem értem, ugyanezt

Hidvégi Gábor · 2016. Már. 19. (Szo), 22.14
Ezt most nem értem, ugyanezt linkeltem én is.
91

Tekintsd úgy, hogy

BlaZe · 2016. Már. 19. (Szo), 22.47
Tekintsd úgy, hogy kijavítottam a linked, hogy ne legyen félrevezető azon olvasóknak, akik még nem csömörlöttek meg ettől a témától. Persze így már semmi értelme a hozzászólásodnak. Meg amúgy se, egy 1 éves kommentre válaszoltál, hogy megint előrángasd a gumicsontot.

Tegyünk itt pontot erre a szálra légy szíves.
24

A funkcionális programozásban

Joó Ádám · 2015. Feb. 11. (Sze), 16.08
A funkcionális programozásban átestek a ló másik oldalára, amikor egyáltalán nem bíznak a programozóban, és nem engednek meg állapotot tárolni. Ez első és második hallásra is elég vad dolog.


Nem a ló túloldalára estek át, ez a funkcionális programozás matematikai gyökerei miatt adott. A gyakorlatban az állapotváltozások minimalizálása és lokalizálása a cél.

Procedurális programozásban arra kell ügyelni, hogy a függvényeink lehetőleg ne használjanak globális változókat, azaz ugyanolyan paraméterekkel meghívva mindig ugyanazt az eredményt adják vissza.


Az állapot lokalizálása adatstruktúrákba az objektumorientált programozás alapja, szemben a klasszikus procedurális megközelítéssel, ahol az alkalmazás globális változóit módosítják az eljárások. Just sayin’.
46

Az állapot lokalizálása

Hidvégi Gábor · 2015. Feb. 11. (Sze), 17.50
Az állapot lokalizálása adatstruktúrákba az objektumorientált programozás alapja, szemben a klasszikus procedurális megközelítéssel, ahol az alkalmazás globális változóit módosítják az eljárások.
Ezen már gondolkodtam, hogy tulajdonképpen mi a különbség a globális változó módosításán és a lokalizáláson, aztán a másolat módosításán? Végeredményben semmi, procedurálisban is készíthetsz másolatot a globálisról, és aztán azzal dolgozol.
49

Nem értem a dolgot a

Joó Ádám · 2015. Feb. 11. (Sze), 18.14
Nem értem a dolgot a másolással. Hatókörökről van szó. A globális változókhoz mindenki hozzáfér, a lokális változókhoz csak az, akinek átadod őket.
11

Minden évben megjelenik

virág · 2015. Feb. 10. (K), 12.39
Minden évben megjelenik egy-két ilyen témájú cikk, egy kicsit unalmas.
14

Egyrészt évente

Hidvégi Gábor · 2015. Feb. 10. (K), 13.04
Egyrészt évente egyszer-kétszer ki lehet bírni, másodrészt nem muszáj elolvasni ezeket, harmadrészt az OOP halálával az ilyen cikkek is el fognak tűnni (tehát érdemes siettetni).
15

OOP még mindig jobb, mint a

pythonozok · 2015. Feb. 10. (K), 13.20
OOP még mindig jobb, mint a káosz... (procedurális programozás javarészt káoszt eredményezett)
16

Ez nem igaz, lásd 12-es

Hidvégi Gábor · 2015. Feb. 10. (K), 13.35
Ez nem igaz, lásd 12-es hozzászólás. A 13-asból pedig következik, hogy az OOP még nagyobb káoszt okoz.

Kicsit kifejtem, hogy érthető legyen: procedurális programozásban alapesetben az egyetlen szervező erő a függvény vagy az eljárás. Ez a későbbiekben kiegészül a függőségkezeléssel (globális változók).

OOP-ben bejönnek az OOP alapjai (öröklődés, polimorfizmus, zártság), a programtervezési minták, a névterek, a SOLID és a függőségkezelés.
17

No offense, de egyre inkább

pythonozok · 2015. Feb. 10. (K), 13.47
No offense, de egyre inkább olyan érzésem van, hogy nem érted az OOP alapjait sem, ezért küzdesz ellene minden lehetséges és lehetetlen eszközzel...
Amiket felsoroltál, azok akkor növelik a káoszt, ha hozzá nem értő (a művészet más kategória!) kezekbe kerül az eszköz.
Szerintem.
18

Lehet

Hidvégi Gábor · 2015. Feb. 10. (K), 14.46
Nem zárom ki, hogy igazad van, és tényleg nem értem az OOP alapjait sem, de nem hiszem, hogy így lenne. Csak kicsit olyan a helyzet az OOP földjén, mint egy mesebeli országban, ahol azt mondják, hogy jól mennek a dolgok, folyamatos fejlődés van, aztán mégis sorban vezetnek be újabb és újabb adókat, hogy ezt a látszatot fenn lehessen tartani. Ugyanígy kerülnek be az újabb és újabb rendezőelvek az objektumorientált programokba, és csak akkor lehetsz jó szakember, ha ezeket használod is.

Én nem azt állítom, hogy az OOP egyes részegységei per se rosszak lennének, de egyben az egész már túlságosan elbonyolítja a szoftvert.

Eleve az hibás koncepció, hogy az adatok és a rajtuk műveleteket végző függvények összetartoznak, mert rugalmatlan lesz a szerkezet. Sok OOP-s küzd a coupling ellen, pedig eleve úgy kezdenek, hogy összerendelik ezt a két független halmazt.
29

Nem zárom ki, hogy igazad

Joó Ádám · 2015. Feb. 11. (Sze), 16.30
Nem zárom ki, hogy igazad van, és tényleg nem értem az OOP alapjait sem


Szerintem nincs elég széles látóköröd, mert kevés nyelvet ismersz, illetve nem nagyon ismered a programozási nyelvek történetét. Ez látszik abból, amikor például a névtereket vagy más konstrukciókat objektumorientáltnak nevezel.

Ugyanígy kerülnek be az újabb és újabb rendezőelvek az objektumorientált programokba, és csak akkor lehetsz jó szakember, ha ezeket használod is.


Úgy gondolod, hogy az újabb és újabb rendezőelvek csak az objektumorientált programozás sajátjai? Hogy más paradigmák teljesek, tökéletesek, és már nincs hova fejlődjenek?

Én nem azt állítom, hogy az OOP egyes részegységei per se rosszak lennének, de egyben az egész már túlságosan elbonyolítja a szoftvert.


Egyiket sem kötelező használni, mindig azért használsz egy konstrukciót, mert valamilyen előnyöd származik belőle, például egyszerűbbé teszi a kódod.

Eleve az hibás koncepció, hogy az adatok és a rajtuk műveleteket végző függvények összetartoznak, mert rugalmatlan lesz a szerkezet.


Az nem rugalmatlanság, ha a fordító nem enged gyököt vonni egy sztringből.
37

Ez látszik abból, amikor

Hidvégi Gábor · 2015. Feb. 11. (Sze), 16.49
Ez látszik abból, amikor például a névtereket vagy más konstrukciókat objektumorientáltnak nevezel
A névterek nem mások, mint egy prefix, és ebben megegyeznek az OOP implicit első paraméterével (objektum->akármi, this->valami). Egy tőről fakadnak.

Úgy gondolod, hogy az újabb és újabb rendezőelvek csak az objektumorientált programozás sajátjai? Hogy más paradigmák teljesek, tökéletesek, és már nincs hova fejlődjenek?
A kevesebb néha több. A fejlődés nem mindig abból áll, hogy hozzátoldozgatunk valamit a meglévőkhöz.

Az nem rugalmatlanság, ha a fordító nem enged gyököt vonni egy sztringből.
Nem erről van szó, és erre már hoztam példát korábban. Van mondjuk egy asszociatív tömböd, amiből le tudod generálni az oldal menüjét lenyíló almenükkel. A következő feladat, hogy a tartalom tetején lévő breadcrumbot elkészítsd. OOP-ben két választásod lehet:
1, kiegészíted a menü osztályt úgy, hogy tudjon breadcrumbot is készíteni, így megfelelsz a Single Responsibility elvnek
2, készítesz egy másik osztályt, amibe ugyancsak letöltöd a fenti adatokat (vagy egy részüket), és ebből lesz a morzsa

Ha viszont külön kezeled a függvényeket és az adatokat, akkor a fenti dilemmával sosem találkozol.
40

A névterek nem mások, mint

Joó Ádám · 2015. Feb. 11. (Sze), 16.57
A névterek nem mások, mint egy prefix, és ebben megegyeznek az OOP implicit első paraméterével (objektum->akármi, this->valami). Egy tőről fakadnak.


Semmi közük egymáshoz. Az objektum->akármi az ugyanaz, mint az akármi(objektum) polimorf függvényhívás, egy futásidejű konstrukció. A névterek, ahogy mondod, egyszerű prefixek, csak fordítási időben léteznek.

A példádban a választási lehetőségek pedig önkényesek, az adott eszközökkel úgy szervezed a kódot, ahogy te akarod. És egész biztos, hogy a breadcrumb generálásnak nem a szájt szerkezetét tároló osztályban a helye.
45

Teljesen lényegtelen, hogy mi

Hidvégi Gábor · 2015. Feb. 11. (Sze), 17.38
Teljesen lényegtelen, hogy mi a névterek és az OO "fizikai" megvalósítása, futás- vagy fordítási időben helyettesítünk be bármit. Mi az OOP egyik definíciója (nem jut eszembe jobb szó)? Adatok és rajtuk műveleteket végző függvények. Mi a névterek definíciója? "In general, a namespace is a container for a set of identifiers (also known as symbols, names)" A névtérben lehetnek változók (szimbólumok) és függvények. Ezért írtam, hogy egy tőről fakadnak, és nem is látom különösebb értelmét emiatt egymás mellett használni őket.

És egész biztos, hogy a breadcrumb generálásnak nem a szájt szerkezetét tároló osztályban a helye.
Na, emiatt írtam, hogy rugalmatlan az OOP, mert megszabja, hogy mit hogyan kell csinálni.

Sokkal flexibilisebb feladatban gondolkodni. Van egy feladat (generáljuk le a menü és a breadcrumb HTML kódját), vannak adataink (az asszociatív tömb) és vannak függvényeink. A program célja, hogy végrehajtsa a feladatokat az adatokon a meglévő függvényekkel.

Ha egy függvény csak egy adatcsoporton használható, de mégis szükség van rá másik osztályban, akkor mindenféle trükkökre, átszervezésre vagy kódmásolásra van szükség. Így az OOP nem épp a legjobb eszköz a kódújrahasznosítás jegyében.
48

Teljesen lényegtelen, hogy mi

Joó Ádám · 2015. Feb. 11. (Sze), 18.10
Teljesen lényegtelen, hogy mi a névterek és az OO "fizikai" megvalósítása, futás- vagy fordítási időben helyettesítünk be bármit.


De nem az! A névterek csak azért vannak, hogy ne kelljen kilométerhosszú nevekkel dolgozni. A futó programban nem léteznek. Az objektumok adatstruktúrák, a metódusok paraméterei.

Mi az OOP egyik definíciója (nem jut eszembe jobb szó)? Adatok és rajtuk műveleteket végző függvények.


Ez minden program definíciója.

Na, emiatt írtam, hogy rugalmatlan az OOP, mert megszabja, hogy mit hogyan kell csinálni.


Nem szabja meg, te döntöd el, hogy hogyan szervezed a kódot. Ettől még procedurális kódban is vannak egyértelműen rossz megoldások (egy függvény két teljesen különböző feladattal).

Ha egy függvény csak egy adatcsoporton használható, de mégis szükség van rá másik osztályban, akkor mindenféle trükkökre, átszervezésre vagy kódmásolásra van szükség.


Ha egy függvény bizonyos típusú adatokat fogad, akkor tényleg át kell szervezni a kódot, ha más adatokat is kell fogadjon. De ez megintcsak nem az OOP sajátja.
42

Névterek

Poetro · 2015. Feb. 11. (Sze), 17.03
Névterek olyan leginkább funkcionális nyelvekben is vannak mint a Haskell, Erlang, amiket nem lehet OOP nyelveknek nevezni.
27

a névterek Mi köze a

Joó Ádám · 2015. Feb. 11. (Sze), 16.20
a névterek


Mi köze a névtereknek az objektumorientáltsághoz? (Az égvilágon semmi.)
19

Köszi, hogy eldöntöd

virág · 2015. Feb. 10. (K), 14.52
Köszi, hogy eldöntöd helyettem, hogy mit bírjak ki és mit ne, meg mit nem muszáj elolvasnom, mit unjak és mit ne :D Az "OOP halála" szerintem unalmas, mivel teljesen értelmetlen...nem maga a gondolat, mert bármin el lehet filozofálni, én például nagyszerűen tudok a tehenek és vérnyulak repülési szokásairól gondolkodni - hanem a gyakorlatban értelmetlen. Akit annyira zavar az OOP, nyugodtan fejleszthet procedurálisan, vagy kitalálhat új dolgokat ha tud, ha meg péládul vezető pozícióban van, akkor akár éles projekteket is csinálhat OOP nélkül...Az ég világon semmi nem akadályozza meg ebben, ha te nem szereted az OOP-t, akkor ne használd, senki nem kényszerít rá, kivéve ha nem vagy vezető és megmondják mit kell használnod. De ezek a próféciák az OOP haláláról...viccesek, soha nem értettem meg azokat az önjelölt megmondóembereket, akik mindenáron meg akarják másoknak mondani, hogy mi a tuti. Node, hagyjuk is ezt, nem érdemel ez a téma ennyi betűt :) Én amúgy szeretem az OOP-t és a nem OOP-t is, a Linuxot és a Windowsot is és tartózkdok minden ilyen felesleges hitvitától, mert uncsi... bocs, de elnézést kérek előre tőled, hogy unom :D és igaz ami igaz: ha unom, akkor nem kellett volna leírnom, ha nem akartam volna kritikát! Ez igaz, elismerem!
20

Köszi, hogy eldöntöd

Hidvégi Gábor · 2015. Feb. 10. (K), 15.15
Köszi, hogy eldöntöd helyettem, hogyan fejleszthetek nyugodtan, ha zavar az OOP : ) Aki annyira szereti az OOP-t, nyugodtan dolgozhat vele, de ne vegye már zokon, ha kritizálják vagy temetik ezt a paradigmát, hisz semmi sem állandó, csak a változás. Százötven éve a vasútnak sem volt nagyon alternatívája, aztán nézd meg, mára hova jutott. Én is unom a node.js blogmarkokat, no, és akkor mi van? Másokat meg érdekel. Nem vagyunk egyformák és szólásszabadság van.
21

vasút... lásd Déli

pythonozok · 2015. Feb. 10. (K), 15.38
vasút... lásd Déli pályaudvar! ;)
31

Százötven éve a vasútnak sem

Joó Ádám · 2015. Feb. 11. (Sze), 16.35
Százötven éve a vasútnak sem volt nagyon alternatívája, aztán nézd meg, mára hova jutott.


430 km/h-val halad és teljesen környezetbarát? :)
33

Környezetbarát? Melyik? ;)

pythonozok · 2015. Feb. 11. (Sze), 16.39
Környezetbarát? Melyik? ;)
36

Bármelyik, amelyik nem éget

Joó Ádám · 2015. Feb. 11. (Sze), 16.46
Bármelyik, amelyik nem éget szénhidrogént, szemben a közúti járművekkel :)
38

És ettől kezdve a minden

pythonozok · 2015. Feb. 11. (Sze), 16.55
És ettől kezdve a minden relatív kategóriába csúsztunk. Ami nem dízel manapság, az többnyire sok áramot igényel. Áram előállítása nem szennyez? (csak azt próbáltam jelezni, hogy ennyire nem egyszerű a dolog, de ne offoljuk szét a témát ;) )
41

Áram előállítása nem

Joó Ádám · 2015. Feb. 11. (Sze), 17.00
Áram előállítása nem szennyez?


Ez csak azon múlik, hogyan állítod elő, de ennek semmi köze ahhoz, hogy az áram felhasználása nem szennyez. Nagyon káros ez a fajta gondolkodás az élet minden területén (főleg amikor megjelenik a törvényhozásban).
50

Politikába nem mennék bele,

pythonozok · 2015. Feb. 11. (Sze), 18.38
Politikába nem mennék bele, pedig erre tudnék írni ezt-azt.
62

Nem 0

Pepita · 2015. Feb. 12. (Cs), 09.02
Azért a "nem szennyez" erős túlzás.
És igenis fontos az előállítás is.
Mi lenne, ha egy dízel áramfejlesztő termelné az áramot a vonathoz, pl Kínában? :)
63

Rosszabb

Hidvégi Gábor · 2015. Feb. 12. (Cs), 10.01
Szénerőmű termeli.
67

És igenis fontos az

Joó Ádám · 2015. Feb. 12. (Cs), 11.06
És igenis fontos az előállítás is.


Persze, hogy fontos, de ettől még a fogyasztás nem szennyez. Lehetséges a környezetbarát előállítás, a szabályzón múlik, hogy megköveteli-e.
70

Jelenleg nem igazán

Hidvégi Gábor · 2015. Feb. 12. (Cs), 11.39
Jelenleg nem igazán lehetséges környezetbarát előállítás, az előállított energiasűrűséggel arányosan nő a környezetterhelés.
74

Ha felülsz a biciklire és

Joó Ádám · 2015. Feb. 12. (Cs), 13.21
Ha felülsz a biciklire és tekered a dinamót, az semmilyen környezetterheléssel nem jár. Lehetséges? Lehetséges. QED.
75

Az állításod igaz lenne, ha

Hidvégi Gábor · 2015. Feb. 12. (Cs), 13.32
Az állításod igaz lenne, ha egymillió évvel ezelőtt élnénk, az akkori népességszámban, gyűjtögető életmódot.

Mennyi a víz egy nagy adag steakben?

Ha belevesszük, hogy mennyi a járulékos költség (öntözéshez használt dízelolaj, műtrágyák, műtrágyák előállítása, késztermékek szállítása), kiderül, hogy a dinamó tekerése eléggé környezetterhelő.
76

Most ugyanazt a logikát

Joó Ádám · 2015. Feb. 12. (Cs), 14.27
Most ugyanazt a logikát alkalmazod, mint az előbb. Abból, hogy az élelmiszer előállítása gazdaságossági erők miatt ma sokszor környezetterhelő, nem következik, hogy törvényszerűen az.

Az öntözéshez nem kötelező dízelt használni, trágyázni nem kötelező műtrágyával, és az előállítás sem kötelezően környezetterhelő. A környezetterhelés egy externália, amit megfelelő törvényi szabályozással fel lehet számolni.

A vízfogyasztás egyébként a legdühítőbb hülyeség, amit a haragoszöld környezetvédők kiabálnak. Mintha azzal, hogy öntözöl, kevesebb víz maradna a bolygón.
79

Ez egy kicsit összetettebb

Hidvégi Gábor · 2015. Feb. 12. (Cs), 15.13
Ez egy kicsit összetettebb annál, mint ahogy elsőre látszik.

1, Hétmilliárdan vagyunk, és folyamatosan szaporodunk. Ha ebben a pillanatban minden országban bevezetnék az egykepolitikát, még akkor is évekig vagy évtizedekig nőne a népesség száma a tehetetlenség miatt.

2, A növekvő népességet egyre több élelemmel kell ellátni. A művelhető földterület mérete maximált, sőt mindjárt látod, hogy csökken. Ebből kell kihozni a legjobbat, amit a termésátlagok növelésével, műtrágyázással lehet elérni, aminek az ára az, hogy egyre jobban kiszipolyozzuk a talajt, a talajvizet szennyezzük, s ezt utána tisztítani kell. A víztisztítás energiába kerül.

3, Az erdők kivágásával lehet növelni a termőterületet, de ez egyrészt maximált, másrészt az erdők rendkívül fontosak a vízgazdálkodás szempontjából. A fák képesek jól megkötni a talajt, a haszonnövények nem, ez utóbbiak esetében folyamatos a föld belemosódása a talajvízbe (a vikingek többek között emiatt haltak ki Grönlandról, de ugyanez megy jelenleg Ausztráliában az ősbozót feltörésével és helyükre legelők telepítésével, de az emberiség egyik bölcsőjének mondott Termékeny Félhold, a Tigris és Eufrátesz köze is ma már sivatag). Emellett a fák hidegen tartják a vizet, ahol kivágják a fákat, a kisebb folyóvizek felmelegednek és elpárolognak.

4, A globális felmelegedés miatt egyre kiszámíthatatlanabb az időjárás, az özönvízszerű esőzések a 3-as pontban említett földpusztulást erősítik.

5, Amelyik csapadék a tengerekbe/óceánokba hullik, az elveszett, mert rendkívül drága lepárolni.


Az állításaid, bár igazak, de legfeljebb az ősközösségben működhetnek. Túl sokan vagyunk ehhez, természetes módszerekkel nem lehetne a szükséges termésátlagot elérni. Az éhező pedig kinyírja a legokosabb programozót is, ha túl szeretne élni.
83

A fenti okozati lánc

Joó Ádám · 2015. Feb. 12. (Cs), 22.39
A fenti okozati lánc logikusnak tűnik, de az alapfelvetésed nincs rendben, a konklúziód pedig… nos hát…

Hétmilliárdan vagyunk, és folyamatosan szaporodunk.


A harmadik világ népei szaporodnak, a fejlett társadalmak születésszáma egyre hanyatlik.

Itt akár le is zárhatnánk a növekvő élelemszükségletre felépített érvelésed vizsgálatát, de ne menjünk el amellett sem, hogy a művelésre alkalmas földterületnek töredékét hasznosítjuk csak művelésre, hogy technológiailag vagyunk hozzá elég fejlettek, hogy művelésre alkalmassá tegyünk meglévő területeket vagy akár létrehozzunk újakat, és hogy az élelmezésnek nem a földművelés az egyetlen lehetséges forrása.

Amelyik csapadék a tengerekbe/óceánokba hullik, az elveszett, mert rendkívül drága lepárolni.


Még szerencse, hogy a Földnek erről senki nem szólt, és a vízkör működik pár milliárd éve :)
85

környezet terhelés

Pepita · 2015. Feb. 13. (P), 08.34
Érdekes ahogy vitatkoztok, egy fontos dolgot viszont mindketten figyelmen kívül hagytatok.
A terhelés mértéke kizárólag az egyes embereken múlik. Mert gyakorlatilag semmiből sincs felesleg, ha valamit nem veszünk meg, azt nem gyártják.
Innen nézve csak nekünk, fogyasztóknak van hatásunk a problémára. Nekünk kell környezet tudatosan élni.
86

Teljesen mindegy, hogy

Hidvégi Gábor · 2015. Feb. 13. (P), 10.07
Teljesen mindegy, hogy hanyadik világ népei szaporodnak, ha az összlétszám nő, akkor több élelemre is van szükség. Mint írtam, nem lehet minden földterületet élelemforrásként használni, mert a haszonnövények mellett a vízkészlet csökken, erdők szükségesek a jó vízgazdálkodáshoz.

Ami a fenti felsorolásból kimaradt, az a szikesedés, ami ugyancsak a felhasználható termőterület méretét csökkenti, és jelentősen hozzájárul az emberiség.

A földművelésen kívül fehérjeforrásunk a halgazdálkodás, pontosabban annak a hiánya. Itt egyrészt nincs olyan tapasztalata az emberiségnek, mint a háziállatokkal, azaz jelentősen kisebb hatékonysággal és nagyobb környezetterheléssel tudunk halakat fenntartható módon tenyészteni. Másrészt évtizedes probléma, hogy a világtengereket túlhalásszák, és eljutottunk egy olyan szintre, hogy óriási területen nem képes a halpopuláció megújulni, szinten maradni.

»Amelyik csapadék a tengerekbe/óceánokba hullik, az elveszett, mert rendkívül drága lepárolni.«

Még szerencse, hogy a Földnek erről senki nem szólt, és a vízkör működik pár milliárd éve :)
A globális felmelegedéssel nőt a viharok, heves esőzések száma. Ezt a vizet nehezebb megtartani, mert hirtelen jön és nagy mennyiségű. Mint fentebb írtam, a talaj tengerbe való mosása is felgyorsult, és emellett a mezőgazdasági területek növekedésével a folyók vízgyűjtő területe is csökkent. Így csak közvetve, de igaz, amit írtam.

Ajánlott olvasmány Jared Diamondtól az Összeomlás.
26

Szerintem ez másról szól.

Joó Ádám · 2015. Feb. 11. (Sze), 16.18
Szerintem ez másról szól.
59

Weblabor

vbence · 2015. Feb. 11. (Sze), 23.56
Ez a téma a Weblabor szomorú realitása :(
60

Elolvastad a cikket? Egy

MadBence · 2015. Feb. 12. (Cs), 00.06
Elolvastad a cikket? Egy rossz szót nem szól az oop eszközeiről (talán csak annyit, hogy nem tökéletesek, ami történetesen igaz), arról szól, hogy a funkcionális(abb) megközelítés gyakran jóval karbantarthatóbb szoftvert eredményez.
61

Nem csak a cikk

vbence · 2015. Feb. 12. (Cs), 00.30
A "second death" közepéig olvastam el, akkor vált világossá, hogy egy síma rantról van szó.
66

Én sem értem, hogy miért csak

Joó Ádám · 2015. Feb. 12. (Cs), 11.01
Én sem értem, hogy miért csak erről akarnak beszélni az emberek, elég unalmas már, de hát nyilván erre van igényük, hisz tele a webfejlesztés világa izgalmasabbnál izgalmasabb újdonságokkal, ezekről mégsem beszél senki.
69

Azért ez egy nagyon súlyos

Hidvégi Gábor · 2015. Feb. 12. (Cs), 11.37
Azért ez egy nagyon súlyos kérdés, és erre neked nap mint nap van rálátásod, amikor élesíted ki az álláshirdetéseket. A "programozót keresünk"-ben általában elvárás az OOP szemlélet; namost, ha senki sem tudja pontosan, hogy mi az OOP, akkor mit várnak el tulajdonképp a munkaadók? Mit tudnak nyújtani a munkavállalók? Ez olyan, mintha nem beszélnének egy nyelvet.
77

Mégis úgy tűnik, hogy

Joó Ádám · 2015. Feb. 12. (Cs), 14.37
Mégis úgy tűnik, hogy működik. Értelmezd úgy, hogy ismerd azokat az eszközöket, amikről beszélni szoktunk.

De itt csak annyit akartam jelezni, hogy a Weblaboron az lesz téma, amit a közösség témává tesz. Értetlenül állok az előtt, hogy megjelenhet egy HTML5, véglegesedhet egy HTTP/2, érkezhet egy Swift úgy, hogy senki sincs, aki hírt küldjön és beszélgetést kezdeményezzen róla.

Ellenben rendszeresen éri a Weblabort kritika azért, mert egy tag folyton ugyanazon pörög, egy csomó másik meg beszáll együtt pörögni.

Furcsa, na.
78

A kérdést már én is feltettem

Hidvégi Gábor · 2015. Feb. 12. (Cs), 14.57
A kérdést már én is feltettem korábban, hogy mi akadályoz meg bárkit abban, hogy beküldjön egy blogmarkot? Még bookmarklet is van hozzá.

És a másik problémakör: oké, hogy én mindig mondom a hülyeségeimet, de tényleg ott van az ellentábor, aki meg a magáét. Most akkor ki a jobb/különb? Kinek van igaza? Van igazság? Mindenben tévednék? Mindenben tévedne az ellentábor?
84

TLDR: Nem furcsa, na.

bamegakapa · 2015. Feb. 13. (P), 00.34
De itt csak annyit akartam jelezni, hogy a Weblaboron az lesz téma, amit a közösség témává tesz.

Ellenben rendszeresen éri a Weblabort kritika azért, mert egy tag folyton ugyanazon pörög, egy csomó másik meg beszáll együtt pörögni.


Mint rendszeres kritizáló, megszólítottnak érzem magam. Hadd osszam meg a megfigyeléseimet (némileg kívülről, mint marginális és sokáig readonly fórumtag). Kiindulási pontom az lesz, hogy volt idő, amikor a Weblabor virágzott (naprakész témák, számos hozzáértő - számomra többen szakmai példaképek), illetve jelenleg nem virágzik. Ha ezt elfogadjuk, akkor nyilván valami történt útközben. Az emberek már nincsenek itt vagy nem tartják indokoltnak, hogy szóljanak. Akik itt vannak, azok se kezdeményeznek társalgást friss témákban. Miért vajon?

Továbbra sem akarnám egy tag nyakába varrni az egészet. Úgy vélem, az a közösség legalább annyira hibás, amely nem képes korrigálni tagjainak hibás viselkedését, amely nem képes megvédeni magát saját tagjainak egójától. Hülyén hangozhat, de ez minden emberi közösségben elengedhetetlen és nem arról szól, hogy ki kell vágni egyébként használható tudással rendelkező, értelmes tagokat, hanem segíteni kell nekik, hogy a közösségért (ezáltal önmagukért is) és ne saját vélt céljaikért, (szándékukon kívül) a közösség ellen dolgozzanak.

Furán hangozhat az is, hogy komolyan gondolom, egyetlen ember ekkora hatással bírhat. A kulcsszó a rendszeresség. Tegyük fel, valaki elég kitartó, és majd minden topikban képes saját képzelt kereszteshadjáratát folytatni huzamosabb ideig. Minden érdekes beszélgetést ugyanazzá a parttalan flamewarrá alakít, hisz az ilyesmire nyilván sokan ugranak, változó okokból. Van aki tényleg ezen a szinten van, van aki csak tanítani akarja a plebset, s önmagát is besározza, miközben a dagonyából igyekszik kirángatni őket. A közösség (beleértve a moderátorokat) pedig számomra ismeretlen okokból, gondolom félreértelmezett liberalizmusból ezt hagyja. Ennek (értelemszerűen) lesznek maradandó hatásai. Az ember ugyanis felhasználja a tapasztalatait döntéseihez.

A Weblaboron azt tapasztalja az egyszeri olvasó, hogy bizonyos témák egyfajta tiltólistán vannak. Mostanra a lista igen bőséges (HTML5, AJAX, OOP, Node.js, stb.) és lefedi a modern webes eszköztár egy jelentős részét. Évek tapasztalatai támasztják alá, hogy aki ezen (igen tág) témakörökbe sorolható, vagy valamilyen módon ezekkel kapcsolatba hozható kérdésben megnyilvánul itt, az offtopik ranteket triggerel, a számtalanszor lefutott köröket váltja ki újra és újra. Ha szeretnél a Single Responsibility Principle-ről, a Decorator mintáról vagy akár a Haskellről eszmét cserélni, 2-3 hozzászóláson belül már kezdődik is a "Miért rossz az OOP" (hogy jön a Haskellhez az OOP? bár tudnám). Ahogy az idő telik, szép lassan mindenki megtanulja: inkább maradj csöndben, hagyd a francba, menj máshová. Így válik a Weblabor azon hellyé, ahol "úgyis csak lefikáznak minden új és érdekes dolgot" (idézet nem tőlem), egyetlen ember hozzáállása pedig a Weblabor közösségének hozzáállásává.

És akkor itt vagyunk, most, s a főmoderátor nem érti (bár gondolom érti), az emberek miért nem beszélnek a modern web vívmányairól egy ilyen izgalmas és fontos korszakban. Legalábbis itt miért nem. Az a baj, hogy a bizalmat elveszíteni könnyű, visszaállítani eredeti formájára szinte lehetetlen.

Gábort egyébként kedvelem, nem akarom "bántani", ehhez amúgy is már rég késő. Megelőzni már nincs mit. Kérdés, hogyan lehet újra kialakítani a reflexet a célközönségben: ha olvasol valami érdekesről a modern webbel kapcsolatban, merüljön fel benned, hogy a Weblaboron osztod meg vagy kezdeményezel beszélgetést róla.
80

Valahogy azért lezajlanak az

BlaZe · 2015. Feb. 12. (Cs), 15.40
Valahogy azért lezajlanak az interjúk, és értjük egymást. Akkor is, ha nem ugyanaz az anyanyelvünk. Az OOP nem egy egzakt valami. Mint ahogy a programozás sem. Mégis elvárás a programozó jelöltektől, hogy tudjanak programozni... Pár kérdéssel jól mérhető, hogy a jelölt érti-e a motivációját, és tudja-e alkalmazni a mögöttes szemléletet, elméletet.