ugrás a tartalomhoz

IDEs Are a Language Smell

Hidvégi Gábor · 2012. Okt. 31. (Sze), 13.12
Ha a hatékony programozáshoz nagy és sok funkciót biztosító IDE szükséges, akkor ott gondok lehetnek a nyelvvel
 ■
1

Egyetértek azokkal, akik

eddig bírtam szó nélkül · 2012. Okt. 31. (Sze), 15.13
Egyetértek azokkal, akik szerint ez csak trollkodás, a látogatók számának növelése céljából.
Amit elolvastam belőle, annak alapján komplett hülyeség az egész.
2

Ennyi?

Hidvégi Gábor · 2012. Okt. 31. (Sze), 15.31
Vannak esetleg érveid is, vagy ez csak megérzés?
3

Miféle érvekre számítasz

eddig bírtam szó nélkül · 2012. Okt. 31. (Sze), 16.05
Miféle érvekre számítasz mégis, egy nyilvánvaló hülyeség kapcsán?
Senki sem kötelez IDE használatára.
Ha használod, azért teszed, mert kényelmesebb, mint nélküle, nem azért, mert az épp használt nyelvet nem lehet egy vim szintű szövegszerkesztővel használni.
Akit zavar, az fejlesszen assembly-ben, ott viszonylag kevés segítséget nyújt egy IDE.
4

Ő sem azt írja, hogy az

Hidvégi Gábor · 2012. Okt. 31. (Sze), 16.11
Ő sem azt írja, hogy az IDE-ket kell használni, hanem azt, hogy célszerű, mert nélkülük a munkaidőd fele azzal megy el, hogy ezer fájlban kutakodsz, mire megtalálod azt, ami téged érdekel.
5

De ennek mi köze a nyelvhez?

eddig bírtam szó nélkül · 2012. Okt. 31. (Sze), 16.29
De ennek mi köze a nyelvhez?
6

Írja a cikk

Endyl · 2012. Okt. 31. (Sze), 16.56
I can only conclude that the need for an IDE or a heavy "code navigation tool" is a symptom of a deeper problem, if you suffer from tool frustration, it's not necessary your tools that are poor, it may be that your language sucks, or you're not using it correctly.


Tehát ha egy nyelven nem, vagy csak nehezen lehet IDE-ket (is) használva fejleszteni, az nem feltétlenül az IDE hibája. Lehet, hogy a nyelv rossz, vagy te csinálsz valamit rosszul. Mindkettőn érdemes elgondolkodni.
7

Hogy valamit én csinálok

eddig bírtam szó nélkül · 2012. Okt. 31. (Sze), 17.06
Hogy valamit én csinálok rosszul, az belefér.
De ez itt nem egészen azt jelenti, amit te írsz.
Szerintem ez arról szól, hogy "... ha szükséged van IDE v. egyéb, komolyabb eszközre a fejlesztéshez, ... akkor vagy te csinálsz valamit rosszul vagy a nyelvvel van gond". Ezzel viszont nem igazán tudok egyetérteni.
Főként azért nem mert, a kódon belüli navigációhoz szükséges "nehézsúlyú" eszközök általában nem a nyelv, hanem az API, a keretrendszer stb. miatt szükségesek.
A fentivel kb. azt állítja, hogy mondjuk a swing a java része. Holott az már csak egy java-ban írt eszköz.
8

Swing?

Endyl · 2012. Okt. 31. (Sze), 17.46
Ha jól emlékszem, a cikkben egy szó sem esik a Swingről. Inkább arról van szó, hogy javaban hogyan szokás fejleszteni, és hogy ennek eredményeképp rengeteg fájllal és könyvárral kell dolgozni, amik között kutakodni/fejleszteni nagyobb, nem triviális projektek esetében IDE-k és/vagy kód navigációs eszközök nélkül meglehetősen sok időt igényel.
9

Öhjajj... Azért említettem

eddig bírtam szó nélkül · 2012. Okt. 31. (Sze), 17.52
Öhjajj...
Azért említettem _példaképp_ a swinget, mert az kellőképp bonyolult ahhoz, hogy miatta már kedvet érezzen az ember ahhoz, hogy IDE-t használjon a fejlesztéshez.
Holott a swingnek a nyelvhez nincs köze, csak egy keretrendszer.
Ő meg egyre azt erőlteti, hogy a nyelv hibája(amennyiben nem a sajátod), ha IDE-t használsz.
11

A keretrendszerek pont

Hidvégi Gábor · 2012. Okt. 31. (Sze), 18.26
A keretrendszerek pont ugyanazt a filozófiát viszik tovább, mint amit a nyelv kínál, azaz azok is nagy valószínűséggel további ezer objektumot fognak számodra kínálni, megspékelve öröklődéssel és egyéb más nyalánkságokkal.
15

És ezekkel mi a baj? A

BlaZe · 2012. Nov. 1. (Cs), 00.42
És ezekkel mi a baj? A programozási módszertanok már rég lehagyták az "ez az osztály csinálja az univerzum irányítását 13548 db kiajánlott metóduson keresztül" modellt. Már arra készülnek toolok, hogy ellenőrizzék, megfelelően absztrakt és tagolt-e a forrásod, mekkora az osztály, metódus szintű komplexitás stb. A szoftverfejlesztés ebbe az irányba megy, mert ez a hatékonyabb, jobban karbantartható forrást eredményező út, nem a "többezersoros" mammutok gyártása. Hogy ehhez már ajánlott egy jó IDE, az azért ennek fényében természetes.
18

Ezekkel az a baj, hogy

Hidvégi Gábor · 2012. Nov. 1. (Cs), 08.17
Ezekkel az a baj, hogy például az objektumorientált programozás nem használható hatékonyan minden probléma megoldására, viszont az általad említett toolok (feltételezem) azt várják el tőled, hogy ezt a módszert használd, mivel ennek vannak olyan kötöttségei, amit könnyű szoftverrel ellenőrizni. Az IDE-k tudják-e ezt az elemzést kevert vagy csak szimplán procedurális kódra is futtatni?

Egyébként nem kötelező többezer soros mammutokat gyártani egyik programozási paradigma esetén sem, a moduláris programozási elveket már az OO előtt használták.
51

Ezekkel az a baj, hogy

BlaZe · 2012. Nov. 1. (Cs), 15.05
Ezekkel az a baj, hogy például az objektumorientált programozás nem használható hatékonyan minden probléma megoldására

Pl? És miben mérjük a hatékonyságot?

Így hirtelen amire nem feltétlenül célszerű OOP megoldást választani, az pl a kernelközeli programozás. De az üzleti logikák implementálására nem igazán van hatékonyabb programozási paradigma. És azért javarészt ezt végzik a programozók.

Az IDE-k tudják-e ezt az elemzést kevert vagy csak szimplán procedurális kódra is futtatni?

Kevertre (pl PHP) igen, egész pontosan az OOP részére. Procedurális kódra ezeknek viszont nincs túl sok értelme. Ettől még egy c-hez is célszerű IDE-t használni.

Egyébként nem kötelező többezer soros mammutokat gyártani egyik programozási paradigma esetén sem, a moduláris programozási elveket már az OO előtt használták.

Alapvetően pl a Java is egy moduláris nyelv. Package->osztály->metódus. A modularitás a funkcionális elkülönülést biztosítja. Ettől még az üzleti logikát egy láncban kell megvalósítani. 1 fv, 1 feladat. Ha a feladat nagy, a függvény is nagy lesz. Nincsenek igazán hatékony építőkockáid, amiket cserélgethetnél. A függvény B függvényt hívja meg, ezért A függvény működése minden esetben azonos lesz. Ha ettől kicsit eltérőt szeretnél, kell csinálnod egy A' függvényt, ami copy-paste-tel, és sorhalmozással jár. Az OOP erre mást mond, sokkal kezelhetőbb, karbantarthatóbb, továbbfejleszthetőbb, emberileg olvashatóbb programok jönnek létre. És ennek következményeként sok kicsi file, ami szintén jobban tükrözi az ember gondolkodását.

Ezek miatt a mai szoftverfejlesztés elsődleges fejlődési iránya az OOP nyelvek területén van. És szintén ezek miatt jönnek létre az egyre nagyobb tudású IDE-k, kód analizátorok stb.

Így továbbra sem értem, hogy ezzel mi a baj igazából.
52

Object-oriented design patterns in the kernel

complex857 · 2012. Nov. 1. (Cs), 15.20
Így hirtelen amire nem feltétlenül célszerű OOP megoldást választani, az pl a kernelközeli programozás.

Nos vannak akik nem értenének veled egyet: Object-oriented design patterns in the kernel (-:
53

Azt, hogy valamit meg lehet

Hidvégi Gábor · 2012. Nov. 1. (Cs), 15.35
Az, hogy valamit meg lehet csinálni, nem jelenti azt, hogy kell is.
55

nem feltétlenül célszerű !=

BlaZe · 2012. Nov. 1. (Cs), 16.19
nem feltétlenül célszerű != tilos

A kernel pedig nem csak a számítógépekre írt kernelt jelenti, hanem a mikrohw-kre írt programokat is. Ezért volt a feltételes mód. És azért az kétségtelen, hogy az OOP-nek van egy kis többlet memória igénye. Nem véletlenül van pl a Javanak is CLDC specifikációja, amiben szinte alig van valami (előredefiniált) osztály.
54

Ha nem gond, a felvetéseidre

Hidvégi Gábor · 2012. Nov. 1. (Cs), 15.42
Ha nem gond, a felvetéseidre nem most fejtem ki a véleményem. Röviden annyi, hogy az OOP elvek hasznosak, de kizárólag OOP-ben programozni jelentősen korlátozza a gondolkodást, és ezáltal a lehetőségeket.
56

Pedig ez érdekelne kifejtve,

BlaZe · 2012. Nov. 1. (Cs), 16.20
Pedig ez érdekelne kifejtve, hogy mire gondolsz. De akkor türelmes leszek :)
98

Pár példa,

Pepita · 2012. Nov. 5. (H), 02.54
amikre nem lehet OOP:
- A mai ipari felhasználású PLC-k többsége;
- Folyamatirányítási és ~szervezési vezérlések / szabályzások sokasága;
- Kisebb-nagyobb hardverek ROM-ja, FROM, stb....

amikre lehet, de értelmetlen:
- Olyan szoftveres feladatok, amik az adott gép működése során rendkívül sokszor futnak, vagy más okból kritikusan fontos, hogy a lehető legkisebb memória- és prociigénye legyen (pl. kernel);
- Gépközeli nyelven is aránylag könnyen megvalósítható feladatok;
- Ha a továbbfejlesztés csaknem kizárt, mert az pl. a hardver cseréjekor szükséges, és a hardver tartalmazza a szoftvert is (pl. fényképezők, egyéb eszközök.)

Mindkét csoportban a "gépi kód" (assembly és hasonlók) vezet, PLC-khez szokott lenni asztali szoftver, amivel létradiagramozni lehet és / vagy egyszerű (struktúrált) nyelven molyolni, végén transzfer.
105

Azt hiszem, ezekkel az

saxus · 2012. Nov. 7. (Sze), 11.59
Azt hiszem, ezekkel az érvekkel ma már sokan vitatkoznának.
57

Nem teljesen értem

blacksonic · 2012. Nov. 1. (Cs), 16.22
A nem kizárólag OOP-ben programozás alatt mit értesz?
Nekem először a funkcionális programozás jut eszembe, amivel pl. Javascriptben rövid tömör érthető kódot lehet írni. De ilyeneket nem minden nyelvben lehet alaklmazni (pl. parciális függvényhívás)
62

Nem kizárólag OOP pl a C++,

BlaZe · 2012. Nov. 2. (P), 00.01
Nem kizárólag OOP pl a C++, ahol keverten használhatsz OOP-t és procedurális elemeket. Vagy a PHP pl, hogy közel maradjünk a web témához.
66

Sem a PHP sem a C++ nem OOP

saxus · 2012. Nov. 2. (P), 18.48
Sem a PHP sem a C++ nem OOP nyelv, mindketto multiparadigmaju nyelv, imperativ nyelv.

(Mellesleg legtobb nyelv a kevert paradigmak fele halad. .NET/C#-ba sem veletlen toltalk bele a LinQ-t (kis funkcionalis elem, az egyebkent imperativ nyelvben))
12

Másképp

Endyl · 2012. Okt. 31. (Sze), 18.34
Ne csak a Swingen lovagoljunk, hanem vegyünk elő más javaban írt keretrendszert vagy egyéb tetszőleges projektet. Mennyi az esélye, hogy nem többezernyi fájlból fog állni, hanem egyszerű, könnyen átlátható, navigálható öröklődés-, fájl- és könyvtárszerkezettel bír?
Amennyiben ez az esély kellően alacsony, akkor tegyük fel a kérdést: vajon miért így lettek megírva? A nyelv miatt? Vagy csak mert megyünk egymás után vakon (avagy mi csinálunk valamit rosszul, mert lehetne egyszerűbben is)?
Továbbra is érdemes mindkettőn elgondolkodni.

És mivel a cikkben nincs egy az egyben kijelentés, hogy a "tool" használat (és méginkább a "tool"-ból, annak használatából fakadó frusztráltság) rossz nyelvet jelent automatikusan, csak annak lehetőségét, valamint ha mind a két (A nyelv a rossz? Én csinálok valamit rosszul?) kérdésre némi vizsgálódás után nemmel válaszolunk, akkor megnyogudhatunk, hogy nincs mit tenni, így kell ezzel boldogulni, vagy a "tool"-on kell javítani.

Bármelyik esetben okosabbak lettünk valamivel, és ez a lényeg. (És pont ezért nem értem, hogy hol a cikkben a trollkodás.)
14

Hogy kéne kinézzen egy nagy,

BlaZe · 2012. Nov. 1. (Cs), 00.34
Hogy kéne kinézzen egy nagy, komplex project? Hogy kéne nem rengeteg fájlból álljon? A különböző komponensek, libek, toolok minden nyavalyája legyen 1 nagy fileba ömlesztve? Az átláthatóságot nagyban segíti a konfigurációk és egyéb állományok és könyvtárak struktúrált, tagolt felépítése, ezért a sok file.

Egy java, php, c, vagy bármilyen program is 1 forrásból áll, amit lehet notepadben írni, aztán lehet forgatni/nem forgatni, indítani. Ha kicsit bonyolultabb az alkalmazás egy hello worldnél, akkor azért ez a képlet borul mindhárom, sőt az összes nyelv esetén. Az IDE nem arra való, hogy kódoljon helyettünk, hanem hogy támogassa a navigálást, és egy felületen az arcunkba toljon minden számunkra hasznos infót, analizálja a kódunkat, ajánljon fel quick fixeket, kódkiegészítsen stb. Képzelj el egy refaktorálást egy többezer forrásfájlból álló nagyobb rendszeren IDE nélkül. Vagy egy search references feature-t.

IDE nem KELL egy adott nyelvhez. Csak szerencsére van, és akkor használjuk, mert rengeteget segít. Ennek következtében a cikk valóban jó nagy trollkodás lett. Az őskorban én is nyomtam dosnavigator editorban az assembly-t, pascalt, az OOP-t komoly erőforráspazarlásnak gondoltam stb. Nagyon menő volt, de azért már jórég az egyszerűbb php-s oldalakat is IDE-ben csinálom, mert nem kicsit hatékonyabb így a fejlesztés. És ahogy egy rendszer bonyolultsága nő, ez úgy lesz egyre igazabb. Meg hát... debugoljon a cikkíró text editorban ;)

Létezik hasonló összefüggés, mint amit boncolgat, de nem a nyelv minősége és az IDE hasznossága (szükségessége), hanem a rendszer összetettsége és az IDE hasznossága között. Ez a bejegyzés egy cerkahegyezés, hogy ő Haskell, meg Scala nyelveken programoz. Kb ennyi információtartalma volt. Hát hajrá :) De ha összetett rendszerekhez nyúl, akkor ott is fog "kelleni" IDE. Egy több tíz, százezer kódsorból és sok ember által fejlesztett rendszer esetében ezt semmilyen tökjó nyelven nem lehet megúszni.
21

Mivel mostanság mellőzöm a

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 10.28
Mivel mostanság mellőzöm a web-et, inkább desktopon játszadoztam: wxPython, Qt, Gtk a swing mellé.
Nézz bele a doksijukba! A wxPython-t leszámítva egyik sem függ programnyelvtől, melyik nyelv hibájaként kellene felhozni, hogy macerás a használatuk egy kulturált IDE nélkül?
A Python önmagában nem olyan bonyolult, hogy bármiféle komolyabb fejlesztő környezet kellene hozzá. De ha bedobsz mellé egy Qt jellegű keretrendszert (PyQt, PySide, wx stb), máris nagyon jól jön mondjuk egy eclipse+pydev páros.
És nem hinném, hogy azért, mert hülye vagyok hozzá...
Arról nem beszélve, hogy igazán nagy programrendszerek esetében elég macerás az élet komolyabb IDE nélkül.
Valaha dolgoztam Magic-ben. Amíg egy-egy kisebb alkatrészt kellett átlátni, még elment. De ha egy egész alrendszert... Hát vért izzadtunk vele, pedig ott egy sor programot nem kellett leírni. Csupa-csupa táblázat volt az összes program. (uniPaas néven találod meg az utódját, ha érdekel)
10

Csak egy példa: debugger

saxus · 2012. Okt. 31. (Sze), 18.21
Csak egy példa: debugger csanvas. Kiváncsi lennék, hogy pl. a debuggoláshoz (oké, értem én, PHP-ban nem szokás) mi segítséget tud nyújtani bármilyen nyelv.
28

de

joed · 2012. Nov. 1. (Cs), 13.11
php-ban is szokás debuggolni. képzeld, még teszteket is írunk! Sőt, van egy két elvetemült, aki tesztvezérelten fejleszt. Durva mi?
29

Csak találgatok: nem lehet,

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 13.13
Csak találgatok: nem lehet, hogy PHP kapcsán arra célzott, a többségnek fogalma sincs róla, hogy nem csak echo ...; segítségével lehet debuggolni? ;-)
31

Hadd idézzelek ;)

Endyl · 2012. Nov. 1. (Cs), 13.19
De ennek mi köze a nyelvhez?


Azaz, miért minősíti magát a nyelvet az, hogy Programozó Szomszéd Pistike hogyan használja? Tudtommal a php nem követeli meg, hogy echo-val debuggolj :)
65

Oke, akkor szamoljuk ossze

saxus · 2012. Nov. 2. (P), 18.42
Oke, akkor szamoljuk ossze azon fejlesztok szamat, aki latott mar xdebugot (vagy valami egyebet) azokkal akik nem. Aztan hasonlitsuk ossze, hogy mennyire nyogvenyelos es mennyire elmaradott mas nyelvekhez kepest (Java Hotswap, .NET Edit&Continue), aztan hasonlitsuk ossze az IDE-k altal altalaban szallitott megoldasokat pl. egy Debugger Canvasszal (vagy annak Eclipse-es megfelelojevel).

Egyebkent vicces, hogy emlitet a TDD-t, ahhoz is tool kell (legalabbis nem art). Erdekes modon ez _sem_ a nyelvvel kapcsolatos feature.
13

Egyetértek az első hozzászólással...

T.G · 2012. Okt. 31. (Sze), 23.42
Egyetértek az első hozzászólással, ez a téma tényleg trollkodás.

Ha egy nagy és sok funkciót biztosító IDE nem teszi hatékonyabbá a programozást, akkor ott gondok vannak.
16

completely missing the point

razielanarki · 2012. Nov. 1. (Cs), 02.34
aki trollkodásnak veszi azt nem olvasta végig a cikket:

"But furthermore, because a combination of shortcomings in the Java compiler and Javas OO nature, we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system nagivation rather than programming and code editing."

ezzel mélységesen egyetértek. és a konklúzióval is:

"I can only conclude that the need for an IDE or a heavy "code navigation tool" is a symptom of a deeper problem, if you suffer from tool frustration, it's not necessary your tools that are poor, it may be that your language sucks, or you're not using it correctly."
17

we end up with lots and lots

BlaZe · 2012. Nov. 1. (Cs), 03.20
we end up with lots and lots of small files for every interface and class in our system

Nyilván, de ez nem véletlen. Ráadásul kit érdekel? :) Nem azért trollkodás a bejegyzés, mert nem igaz az a gondolat, hogy az összetettebb rendszereket öngól IDE nélkül fejleszteni OO - vagy ha már célkeresztbe került, akkor Java - nyelven. Azért lesz rengeteg apró file, mert az OO patternek és szemléletmód ezt eredményezik. Már feltéve, hogy jól használják.
you're not using it correctly.
:) És ez nem kismértékű kódolvashatósági, karbantarthatósági, hatékonysági és egyéb előnyökkel jár. Az IDE-k pedig ehhez erős segédeszközök. Vagyis a lényegét lefordítva a bejegyzés azt mondja, hogy azok az eszközök, amik lehetővé teszik nagyobb rendszerekben a mai modern (és nem mellesleg bizonyított) programtervezési minták alkalmazását, azt jelentik, hogy az IDE által támogatott ilyen nyelv rossz. Bleh, hátulról mellbe :) Ha ez nem trollkodás, akkor semmi :) Persze lehet, hogy ezekkel nincs tisztában és őszintén gondolja, de akkor meg ciki ezt kitenni az ablakba.

Egyébként Java programozáshoz sem kell semmi, csak egy editor, egy javac, meg egy java, tehát ez a következtetése önmagában is hülyeség. Egy komoly nagy (pl ami a java kedvelt vadászterülete: rendszerintegrációs) projectben meg mindenféleképp lesz a végén vagy egy csillió egység (config,descriptor,fájl,osztály,függvény, ... tökmindegy), akármilyen nyelven is íródik. Ahhoz meg hasznos lesz egy IDE, ami összefogja a projectet.

Amúgy az IDE miért is ördögtől való, hogy baj van a használatával?
67

Szoval most a cikkironak

saxus · 2012. Nov. 2. (P), 18.51
Szoval most a cikkironak annyi a problemaja, hogy Java alatt sok kis fajl jon letre, mas programozasi nyelvekrol meg meg nem hallott, ahol tobb osztalyt lehet egy fajlba is rakni, emiatt az IDE-k a rosszak. Mi ez, ha nem troll logika? :)
19

Trollok

Hidvégi Gábor · 2012. Nov. 1. (Cs), 08.37
A "trollkodást" emlegetők mintha nem ismernék a szó jelentését. Vegyük a blogban említett példát, a szerző akkor trollkodna, ha odamenne mondjuk a Java weboldalára, és a készítőknek vagy a fórumokon elkezdene írogatni, hogy vacak nyelvet alkottatok, mert IDE nélkül nem lehet nagyobb projekten hatékonyan dolgozni.

Ezzel szemben ő a saját blogján leírja a saját tapasztalatait, amit az évek során gyűjtött össze. Miért nem lehet elfogadni, hogy valaki bizonyos dolgokat máshogy lát? Elképzelhetetlen az, hogy léteznek olyan programozási nyelvek, ahol IDE nélkül is lehet nagy projekteket hatékonyan menedzselni?

Kérdezem a trollkodósoktól, ők próbálták-e már a blogban említett programozási nyelveket? Mindegyikük kijelentéseket, kinyilatkoztatásokat tesz, mintha tévedhetetlen lenne, egy kérdést sem láttam tőlük. Gondolkoztak-e már azon, hogy az általuk használt nyelvek és eszközök és paradigmák mennyire jók, és kerestek-e és keresnek-e (hisz a fejlődés nem áll meg) alternatívákat? Ha nem, akkor végülis kik a trollok?
20

Troll pl. aki tudatosan olyan

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 10.16
Troll pl. aki tudatosan olyan témát vet fel, aminek értelme nincs, ellenben nagyon jó flame alap és semmi más szándéka nincs vele, mint látogatókat gyűjteni a hülyeségéhez.
SZVSZ ebbe a kategóriába sorolható az eredeti iromány szerzője.
("7 éves korom óta programozok" - na ez sokat elmond róla, ha a hét évesen összetákolt valamit programozásnak nevezi :-D)

ui: trollunk (nevezzük így a továbbiakban), ha jól láttam, előszeretettel hivatkozik a Haskell-re. Megnéztem: van hozzá Qt. Használja ezt vi-ból! :-D
Tetézve mindezt Robert C. Martin Clean Code-jában szereplő felszólítással, miszerint használjunk nyugodtan beszédes neveket mindenre (változó, metódus, osztály stb), hiszen a moderni IDE-k pl. a kódkiegészítő funkciójukkal sokat segítenek a gyors gépelésben. Én inkább hiszek Bob bácsinak, mint ennek a ...-nak.
22

A körülmények ismerete nélkül

Hidvégi Gábor · 2012. Nov. 1. (Cs), 10.45
A körülmények ismerete nélkül mi alapján állapítod meg, hogy minek van értelme és minek nincs?

Miért ne programozhatna hét éves kora óta? A Legónak pl. vannak programozható masinái, nekem is volt programozható számológépem (később persze), ismerőseimnek gyerekként volt C64-e, amin próbálkoztak mindenfélével. Természetesen ezeket a Móricka-programokat legtöbb esetben nem lehet összehasonlítani egy felnőtt, dolgozó ember által készített kóddal, de az alapokat nagyon jól el lehet sajátítani már ilyen korán.
58

Uncle Bob

blacksonic · 2012. Nov. 1. (Cs), 16.41
Lehet Uncle Bob nem mond hülyeséget amikor ajánlja az IDEket...én is inkább neki hiszek :)
23

Re Trollok

T.G · 2012. Nov. 1. (Cs), 11.58
Szerintem mindenki azt ír a blogjába amit akar. Engem jobban zavar, hogy a Weblabort árasztja el a butaság! (én erre mondom, hogy trollkodás)

Ez az egész olyan, mintha azt mondanánk, hogy két pont közötti távolságot, ha csak járművel tudjuk megtenni, akkor el kell gondolkozni azon, hogy meg kell-e nekünk tenni ezt a távolságot? (és, hogy okosabbnak tűnjünk, tegyük hozzá, hogy nem feltétlen kell kizárni a jármű használatát, csak gondolkodjunk el rajta, mert a gondolkodás sosem árt:)

Nehogy már azt nevezzük fejlődésnek, hogy olyan nyelvet keressünk, amihez nem kell IDE?!

Azért segédeszköz a segédeszköz, hogy segítsen minket. Nem is értem, hogy miért merül fel, hogy a segédeszközök lennének a probléma forrásai? :)

A fejlődés abba az irányba megy, hogy sok kis apró újrahasznosítható kódot készítsünk. A blogbejegyzéssel szimpatizálók már ezt is megkérdőjelezik? Vagy csak az a baj, hogy a sok újrahasznosítható kódot több fájlban/mappában tároljuk?

Ami vicces, hogy a blog a C++ -t nem is említi, pedig ugye ott még a header és a source is külön van, dupla annyi fájl, mintha ugyanazt Java-ban implementálnák. :) Szerintem nagyon meredek állítás az, hogy a nyelv rossz, mert sok fájlt használ.

De tényleg a legviccesebb az egészben, hogy mindez még úgy hangzik el, hogy akik az IDE-ket támogatják, ők nem akarnak fejlődni… na ez a trollkodás iskolapéldája.

A másik oldal: mindegyik nyelvnek megvannak a maga korlátai, ugyanarra a kérdésre más-más választ adtak, és egyáltalán nem biztos, hogy a legjobbat. Szükséges, hogy a nyelvek is fejlődjenek, illetve tiszta lappal új nyelvek szülessenek. Mindenki érdeke, hogy így történjen. De semmi köze ne legyen mindennek ahhoz, hogy hány fájlból áll az elkészült munka, és hogy a sok fájlhoz kell-e IDE vagy sem?
25

Engem jobban zavar, hogy a

Hidvégi Gábor · 2012. Nov. 1. (Cs), 12.42
Engem jobban zavar, hogy a Weblabort árasztja el a butaság!
Mi a butaság? Ha a jelenlegi ismereteid tükrében valamit annak tartasz, az valóban azt jelenti, igazad van? Ha egy ókori egyiptominak azt mondtad volna, hogy a Nap nem istenség, mit mondott volna rá? Azt, hogy butaság, és esetleg trollnak tartott volna.

Ez az egész olyan, mintha azt mondanánk, hogy két pont közötti távolságot, ha csak járművel tudjuk megtenni, akkor el kell gondolkozni azon, hogy meg kell-e nekünk tenni ezt a távolságot?
Szerintem félreértetted. A cikk azt mondja, hogy ha két pont közti távolságot meg lehet tenni gyalog is, akkor miért használjunk járművet?

Nehogy már azt nevezzük fejlődésnek, hogy olyan nyelvet keressünk, amihez nem kell IDE?!
Tévedsz. A cikk írója annyit állít, hogy vannak olyan nyelvek, ahol nem feltétlenül kell IDE a hatékony fejlesztéshez.

Nem is értem, hogy miért merül fel, hogy a segédeszközök lennének a probléma forrásai? :)
Tévedsz. A cikk írója azt állítja, hogy a segédeszközök szükségessége a probléma mutatói.

Szerintem nagyon meredek állítás az, hogy a nyelv rossz, mert sok fájlt használ.
Ilyet senki sem állított, de az is lehet, hogy félreértettem valamit. A magam részéről inkább úgy gondolom, hogy vannak olyan programozási paradigmák, mint például az OOP, amelyek olyan gondolkodási módot erőltetnek (ha egy teljes projektet ilyen módon szeretnél megvalósítani) a használóira ("minden objektum"), aminek az eredménye a sok fájl lehet nagy rendszerek esetében. Javában tudtommal nem is lehet máshogy programozni, ráadásul sok alapfunkció is már rengeteg include-dal jár.

mindez még úgy hangzik el, hogy akik az IDE-ket támogatják, ők nem akarnak fejlődni
Végigolvastam ismét a cikket, valamint az itteni hozzászólásokat, de ilyet senki sem állított.
26

"mindez még úgy hangzik el,

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 12.52
"mindez még úgy hangzik el, hogy akik az IDE-ket támogatják, ők nem akarnak fejlődni"
Végigolvastam ismét a cikket, valamint az itteni hozzászólásokat, de ilyet senki sem állított.

Szerintem ezt te írtad itt picivel feljebb.
27

Nem ezt írtam.

Hidvégi Gábor · 2012. Nov. 1. (Cs), 13.10
Nem ezt írtam. Idézem:
Kérdezem a trollkodósoktól [...] Gondolkoztak-e már azon, hogy az általuk használt nyelvek és eszközök és paradigmák mennyire jók, és kerestek-e és keresnek-e (hisz a fejlődés nem áll meg) alternatívákat?
33

OOP?

T.G · 2012. Nov. 1. (Cs), 13.28
Tényleg még ott tartunk, hogy az OOP jó-e vagy sem? Mert ha igen, akkor azt hiszem nincs több kérdésem...
35

OOP

Hidvégi Gábor · 2012. Nov. 1. (Cs), 13.41
Hol olvastad, hogy pálcát török az OOP felett?
39

Tehát?

T.G · 2012. Nov. 1. (Cs), 13.54
Hát én már tényleg nem tudom, hogy mit is akarsz kihozni ebből a témából?
1. vannak nagy rendszerek
2. a nagy rendszereknél OOP-t használhatunk
3. nagy OOP rendszereknél sok fájl van
4. sok fájl esetén nagy segítség az IDE
Most akkor melyik állítással nem értesz egyet? Merthogy szerintem ezek triviális állítások és a vége az, hogy szükség van IDE-kre.
76

Kimaradt

Hidvégi Gábor · 2012. Nov. 4. (V), 15.53
Ne haragudj, ezt a hozzászólást nem vettem észre. A válaszom a 75-ös elején van.
99

Na ez az

Pepita · 2012. Nov. 5. (H), 03.18
Csak most olvastam a témát és - eddig - ez a bejegyzés az, ami leginkább tükrözi az én véleményem is. Egy pici pontosítással:
Nehogy már azt nevezzük fejlődésnek, hogy olyan nyelvet keressünk, amihez nem kell IDE?!
Itt megjegyezném, hogy olyan - ma használatos - nyelvet én nem is ismerek, amihez IDE kell. Csak olyat, amihez kb. butaság nem használni.

Ezzel együtt szerintem nem troll sem a cikk, sem az itteni kommentek (eddig a pontig). Mindenki elmondta a véleményét, ott, ahol jónak látta. Ami szerinted (vagy szerintem) butaság, az még nem trollkodás, akkor sem, ha erőltetik. Csak akkor, ha semmi más célt nem szolgál, kizárólag azt, hogy a trollra figyelj.
24

IDEs Are a Language Smell...

presidento · 2012. Nov. 1. (Cs), 12.09
Egyetértek a fordítottjával: Ha egy nyelvhez nincs elérhető és sok funkciót biztosító IDE, akkor ott gondok lehetnek a nyelvvel.

A JavaScript esetén a nyelvet kellett megújítani ahhoz, hogy lehessen hozzá jó IDE-t készíteni, lásd Dart (Google) és TypeScript (Microsoft).
30

Kik a trollok?

Endyl · 2012. Nov. 1. (Cs), 13.14
Akik trollkodással vádolják a cikket (vagy a hozzászólásokat), kérem idézzenek belőle, hogy ki, hol állítja a következő "trollkodó" dolgokat:

- ha egy nyelven való fejlesztést megkönnyít egy IDE használata, az csakis rossz nyelv lehet
- akik IDE-t használnak, azok egyértelműen rossz, buta emberek és visszafogják a fejlődést

Véleményem szerint a cikkíró csak megosztotta tapasztalatát, véleményét, amire ha nem flame-elési vágyból ugrunk rá (olyan dolgokat adva mások szájába, amit nem mondtak/írtak), hanem gondolkodni, fejlődni szeretnénk (akár meglévő elvek megkérdőjelezésével, mert ugye számtalan korábbi tudományos és gondolkodási paradigma, bevett szokás dőlt már meg idővel, holott az volt előtte az egyetlen igaz út), akkor talán a gondolkodásra felhívó cikkeknek is helye van a weblaboron (sőt, szerintem ez a célja, de szóljatok, ha rosszul tudom).

És mint korábban írtam, mivel a cikk nem mond ítéletet senkiről látatlanban (csak kérdéseket vet fel), ezért ha azon elgondolkodva, hogy rossz-e a nyelv (vagy a mögöttes szemléletmód), vagy amire, amilyen módon használjuk, arra jutunk, hogy nem, nincs ezekkel semmi gond, akkor megnyugodhatunk, mert minden a legnagyobb rendben van. Ha viszont valamit észreveszünk, amin akár javíthatnánk is, akkor megint csak jól jártunk.

Mi ezen a felháborító trollkodás, aminek nincs helye a weblaboron?
32

Egyetértek

Hidvégi Gábor · 2012. Nov. 1. (Cs), 13.25
a gondolkodásra felhívó cikkeknek is helye van a weblaboron (sőt, szerintem ez a célja
Az általam beküldött blogmarkok nagy részében pontosan ez a célom. Nem állítom, hogy az irományok mindenben száz százalékig megállják a helyüket, de általában vége igen. Érdemes ismerni alternatívákat, mert például nem minden nyelv vagy programozási módszer alkalmas minden probléma hatékony megoldására.
34

Legalább az eredeti poszt

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 13.32
Legalább az eredeti poszt címét olvasd el, fordítsd le és próbáld értelmezni!
(bocs, egyszer felkerestem azt az oldalt, újabb kattintásokat nem adok neki...)
36

És te megpróbáltad?

Endyl · 2012. Nov. 1. (Cs), 13.42
In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem.

A kiemelés tőlem van. Tehát ha le akarom fordítani az "IDEs Are a Language Smell" címet akkor a következőre jutok (amit Gábor is írt):

Ha a hatékony programozáshoz nagy és sok funkciót biztosító IDE szükséges, akkor ott gondok lehetnek a nyelvvel


Kiemelés ismét tőlem. Tehát senki sem állítja, hogy IDE := rossz nyelv, IDE használó := rossz, buta ember.

Tehát továbbra sem tudsz, akarsz idézni az állításaidat alátámasztó dolgot, mégis te dobálózol trollkodással. Érdekes hozzáállás.
38

A poszt címe ennyi: "IDEs Are

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 13.47
A poszt címe ennyi: "IDEs Are a Language Smell".
(language és nem code)
De mint mondottam volt, nem vagyok hajlandó mégegyszer meglátogatni, akkor beleolvastam, szerintem hülyeséget írt, pont.

ui: ha kicsit körülnézel a magyar fórumokon, nem én vagyok az egyetlen, aki szerint a "cikk" szimplán egy kattintásgyűjtő trollkodás, nincs mögötte valós gondolat.
43

Én sem mondtam, hogy más lenne a címe :)

Endyl · 2012. Nov. 1. (Cs), 14.12
Viszont a "smell" (code vagy language, nem számít) nem azt jelenti, hogy valami automatikusan rossz, hanem hogy figyeljünk fel rá ("érezzük meg"), mert baj lehet, nem pedig baj van.

A többmilliárd légy nem tévedhet elve pedig nem fog meggyőzni. Egy, az állításaidat alátámasztó idézet meggyőzne, akár innen, akár az eredeti oldalról. De ha nem, hát nem. Nekem hasznos volt, neked nem.

ui.: Azt írod beleolvastál, nem pedig elolvastad, részletesen értelmezted. Én a vita (és nem vitatkozás, flame-elés, mert van különbség) kedvéért legalább ötször elolvastam, átolvastam, hogy hátha bennem van a hiba, és írt isteni kinyilatkoztatást a fent említett troll dolgokról, de nem találtam olyat. Viszont az ellenkezőjére tudok/tudtam idézni.
44

Mindegy, hosszú...

eddig bírtam szó nélkül · 2012. Nov. 1. (Cs), 14.19
Mindegy, hosszú...
37

mégis te dobálózol

Hidvégi Gábor · 2012. Nov. 1. (Cs), 13.45
mégis te dobálózol trollkodással. Érdekes hozzáállás.
Tisztelettel kérek mindenkit, hogy óvatosan fogalmazzon, mert nagyon könnyen személyeskedésbe mehet át a vita, aminek semmi értelme.
42

Vita

Endyl · 2012. Nov. 1. (Cs), 14.06
Egy nem személyeskedő vitában az is elvárható, hogy érveket, tényeket, állításainkat alátámasztó idézeteket írjunk, szerintem.
45

Természetesen, de ha a másik

Hidvégi Gábor · 2012. Nov. 1. (Cs), 14.30
Természetesen, de ha a másik nem veszi fel a kesztyűt, szerintem attól még neked ugyanúgy semlegesnek kell maradnod.
50

Nem állítottam senkiről, hogy troll lenne

Endyl · 2012. Nov. 1. (Cs), 14.59
Csak megkérdőjeleztem a hozzáállását ehhez a témához. Egyébként senki személyével nincs itt bajom :)
40

A cikk egyetlen

tgr · 2012. Nov. 1. (Cs), 13.59
A cikk egyetlen tisztességesen megfogalmazott érve az, hogy az IDE-k egyik funkciója a navigálás a kódban, és ezt a sok fájlt követelő nyelvek teszik szükségessé - ez pedig hülyeség. A navigálást a kód mérete teszi szükségessé, egy százezer soros fájl éppúgy navigálhatatlan kézzel, mint ezer százsoros. Az IDE-k többi fő funkciójával (syntax highlight, code completion, dokumentáció megjelenítése, refaktorálás, intelligens keresés, snippetek, formázás stb) nem is foglalkozik.
48

IDE

Hidvégi Gábor · 2012. Nov. 1. (Cs), 14.42
Az Integrated Developer Environment azért integrált, mert beépített funkciókkal támogat bizonyos nyelveken történő fejlesztést. Az általad felsoroltakból emiatt a syntax highlight, code completion, snippetek és a formázás szimplán szövegszerkesztői feladat, a dokumentáció megjelenítése, a refaktorálás és az intelligens keresés pedig mind az adott nyelvhez igazodik (és ettől lesz IDE az a szövegszerkesztő, amit használsz). A cikk végeredményben ezekből az intelligens kereséssel foglalkozik (= navigálás a kódban), amire azért van szükség, mert bizonyos programozási technikák (például a polimorfizmus) ezt nehézkessé tehetik (és ehhez nem szükséges százezer soros kód).
63

Viszonylag kevéssé tűnik

tgr · 2012. Nov. 2. (P), 13.33
Viszonylag kevéssé tűnik hasznosnak az a syntax highlight/code comletion/snippet/formázás, ami nem igazodik az adott nyelvhez.
100

Miért, szerintem

Pepita · 2012. Nov. 5. (H), 03.33
a (titkár)lányoknak leginkább az tetszik, ha az egyik betű ciklámen, másik királykék, harmadik narancssárga, ..., és mindez nyelvtől független, úgysem értik... Kiegészíteni pedig a T-vel kezdődőt tangabugyira kell, az M-et találjátok ki!

(Meguntam a sok troll-vádat, hát itt egy troll-komment. :))
106

Miért mindig csak a kódszerkesztés...

saxus · 2012. Nov. 7. (Sze), 12.11
...vagy integrált debugger, profiler, unit testing, modellező eszközök, deployment, DB túrást segítő eszközök, Vagy integrált SCM és bugtracker követés, stb.

Vegyük már észre, hogy egy IDE nem attól ide, hogy egy túlhízlalt szövegszerkesztő, hanem azért, mert egy integrált fejlesztői környezet. A fejlesztés meg nem csak arról szól, hogy ontjuk magunkból a kódot ezerrel.
109

Anno a Turbo(Borland)

eddig bírtam szó nélkül · 2012. Nov. 7. (Sze), 12.54
Anno a Turbo(Borland) C/Pascal környezetét már IDE-nek nevezték, ha jól emlkészem. Pedig azok tényleg csak "túlhizlalt" szövegszerkesztők voltak. ;-)
111

Pedig abban már volt

Poetro · 2012. Nov. 7. (Sze), 12.58
Pedig abban már volt profiler, debugger, majd később remote debugger is. Na meg volt benne fordító és futtató is.
112

Profiler szerintem nem volt

eddig bírtam szó nélkül · 2012. Nov. 7. (Sze), 13.13
Profiler szerintem nem volt az elsőkben, amikor még Turbo volt a Borland, csak kb. 2.0-tól, illetve Pascal-nal 5.5/6.0-tól.
De lehet, hogy én emlékszem rosszul.
113

Profilerre én se emlékszem,

saxus · 2012. Nov. 7. (Sze), 15.27
Profilerre én se emlékszem, azok inkább új-keletű huncutságok szerintem.
41

IDE

Poetro · 2012. Nov. 1. (Cs), 14.00
Az alapvető probléma az, hogy sokan nem is gondolkoznak el azon, hogy mi is az IDE.
IDEs present a single program in which all development is done. This program typically provides many features for authoring, modifying, compiling, deploying and debugging software.

Tehát ha mondjuk egy Turbo Pascal-t használsz, annak felületével, akkor te egy IDE-t használsz, mert abban szerkeszted, debuggolod, fordítod és futtatod az alkalmazásodat. De ha egy Vim-et felruházol parancsokkal, amivel tudod az alkalmazásodat fordítani futtatni, tesztelni, deployolni, debuggolni, akkor te lényegében te egy IDE-t hoztál létre. Ugyan ez igaz minden szerkesztő alkalmazásra, sőt, manapság nem is nagyon léteznek alkalmazások, amikben ezt nem lehet megtenni, ezáltal szinte minden szerkesztő program pár beállítással IDE-vé alakítható. Ha valaki tényleg olyan alkalmazást használ, ami ezekkel a képességekkel nem rendelkezik, akkor mondható el róla, hogy nem IDE. Szerintem ezek után az egész vita okafogyottá válik.
46

Jó nézőpont

dropout · 2012. Nov. 1. (Cs), 14.31
Én még annyival tágítanám a definiciót, hogy linuxon például a gcc toolchain is végülis egy IDE. Persze a cikk szerzőjének korlátozott értelmezése és mondanivalója ettől független, mert külön definiálja, hogy neki mit jelent a fogalom.
47

These two wonderful languages

Poetro · 2012. Nov. 1. (Cs), 14.33
These two wonderful languages have taught me one thing: if the language is good enough, an IDE is strictly not needed as long as you have good support for syntax highlighting and parens matching in the case of clojure, or indentation in the case of Haskell.

Most belenéztem egy komolyabb Haskell alkalmazás kódjába (történesen a Darcs verziókezelőjébe), és azért ezt az állítást megkérdőjelezem. A kód maga több mint 200 fájl. Aki ezt fejben tudja tartani, annak azért gratulálok.
49

Egy fecske nem csinál nyarat

Hidvégi Gábor · 2012. Nov. 1. (Cs), 14.47
Múltkor a Peugeot-mban elromlott a fék, ergo minden francia autó rossz.

Mindent lehet jól és rosszul is csinálni. Egy múltkori fórumtéma alapján olvastam újra Felhő cikkét, és abban az első példa szerintem tárgyi tévedés, mert procedurális programozásban nem szükséges ilyen kóddal megvalósítani azt a funkciót, vannak rá sokkal jobb eszközök.
59

kiváncsi lennék, hogy honnan

Tyrael · 2012. Nov. 1. (Cs), 18.17
kiváncsi lennék, hogy honnan halászod össze ezeket a blogpostokat.
eleve te szüröd át és választod ki ezeket, vagy valahol már összegyűjti valaki a minden elfogadott best practice-szel szembemenő véleményeket?

a témához: szerintem az IDE ugyanolyan velejárója a programozás fejlődésének, mint az egyre magasabb szintű/menedzselt programozási nyelvek terjedése.
ugyanígy régebben az autók/repülők/minden elműködtek mindenféle elektronika nélkül.

Tyrael
60

valahol már összegyűjti

Hidvégi Gábor · 2012. Nov. 1. (Cs), 19.09
valahol már összegyűjti valaki a minden elfogadott best practice-szel szembemenő véleményeket
Egymilliárd kínai nem tévedhet.
61

Te most tulképp akkor az OOP

BlaZe · 2012. Nov. 1. (Cs), 23.59
Te most tulképp akkor az OOP ellen érvelsz ezzel a posttal? Nem teljesen értelek. Mert a bejegyzés tömény, nettó hülyeség.

Nem azért szeretjük az OOP-t, meg a patterneket, mert mások azt mondják, hogy jó, hanem mert a sokéves tapasztalatunk is azt támasztja alá, hogy ez a helyes irány. És járulékos jóságként egyszerűbbé teszik a fejlesztés számokkal mérését, illetve a céges szabályokhoz igazodást is stb. Legtöbben fejlesztettünk nem keveset procedurális nyelven is, úgyhogy szerintem van összehasonlítási alapunk, ami alapján azt mondhatjuk, hogy ez így jobb, színesebb, szagosabb. Utoljára kb 8-10 éve volt divat értetlenkedni az OOP létjogosultságán. Azóta legalább 2 olyan nyelv is kinőtte magát használhatóságilag is, plusz épültek rájuk olyan toolok, ami nagyon egyértelműen eldöntötte ezt a vitát.
64

Mindenkinek, aki ismét leállt

Joó Ádám · 2012. Nov. 2. (P), 17.32
Mindenkinek, aki ismét leállt pro vagy kontra az objektumorientáltságról veszekedni: az állományok és sorok számának növekedése nem az objektumorientált szemlélet következménye.

Az objektumorientáltság különböző programozási paradigmák összessége: modularitás, adattípusok, összetétel, absztrakció, egységbezárás, öröklődés és polimorfizmus. Ezek közül mindegyik használható és használandó bármely típusos, strukturált nyelven. Az egyetlen kivétel, valójában tehát az, amit az objektumorientáltság a világnak adott, a polimorfizmus.

Kérdem hát, ez utóbbi mennyiben járul hozzá a kód méretének növekedéséhez? Nem inkább arról van szó, hogy a fősodor nyelvei (PHP, Java, C/C++, JavaScript stb.) nem adnak elég tömör eszközöket egy új típus vagy egy algoritmus definiálásánál ahhoz, hogy ne képernyőnyi, önálló állományba kívánkozó kódot kelljen hozzájuk megírni?

Itt van a cikk szerzőjének igazsága: egy valóban típusos vagy egy funkcionális nyelv ilyen eszközöket ad, és ezért lesz tömörebb a kód. De mindennek semmi köze az objektumorientáltsághoz.
68

Már jóideje foglalkozom a

Hidvégi Gábor · 2012. Nov. 2. (P), 19.14
Már jóideje foglalkozom a felmerült témákkal, mert szeretném pontosan megérteni a működésüket. Az OO-val kapcsolatban én is hasonló következtetésre jutottam tegnap este, igazad van abban, amit leírtál, mint ahogy Blaze-nek is összességében, köszönöm, hogy vettétek a fáradságot, és leírtátok a véleményeteket.

Nem tudom, miért fáj az egyeseknek a cikk konklúziója? Mivel emberek alkották a programozási nyelveket, miért ne lehetnének hibásak vagy tökéletlen eszközeik?

Az OOP nyújtotta szabályrendszer átlagos programozóknál valóban rengeteg előnyt nyújt, megakadályozza őket, hogy egy csomó alaphibát elkövessenek. Egy nagyon jó programozót viszont abban akadályoz meg, hogy jó programot írhasson, hisz csak korlátokat állít elé.
Figyelembe véve az átlagos és a nagyon programozók arányát, az OOP felé billen a mérleg nyelve, ezen valóban nincs mit vitázni.

Ami érdekes még, amit Blaze említett, hogy az OOP eszközeinek használata mérhetővé tesz bizonyos dolgokat. Ez és a különböző, rutinfeladatok elvégzését segítő könyvtárak, library-k elterjedése (továbbá ide lehet sorolni a CSS3 újításait, amelyek jelentősen egyszerűsítik egy website kinézetének és animációjának elkészítését), nyilvánvalóan látszik az irány az automatizált szoftverkészítés felé.

Szerintem belátható időn belül ugyanúgy "gyárakban" készül minden program, amelyek nem feltétlenül lesznek kicsik és gyorsak, de hatékonyságban és fejlesztési időben verni fogják az emberek által készített társaikat. A hagyományos gyárakkal szemben itt viszont először a kulimunkát fogják programokkal elvégeztetni, és elég lesz pár magasan kvalifikált mérnök a kóceráj működtetéséhez.
70

Gyárak

complex857 · 2012. Nov. 3. (Szo), 13.09
Szerintem belátható időn belül ugyanúgy "gyárakban" készül minden program, amelyek nem feltétlenül lesznek kicsik és gyorsak, de hatékonyságban és fejlesztési időben verni fogják az emberek által készített társaikat.

Amennyire én ismerem a törtenelmet, ezt a progarm generáló program ötletet nagyjából 10 évent újra és újra elpróbálják és újra és újra elbuknak vele (CASE eszközök, "Majd generálunk kódot UML-ből"...). Ha emlékeim nem csalnak elösször a "No silver bullet" esszében (Mythical Man Month), kerül elő az "essencial complexity" fogalma aholis Fred Brooks megkülömbözteti a software gyártásban előforduló komplexitast aszerint, hogy a konkrét feladat lényegéből adódik-e a nehézség, vagy mert az eszközeink nem igazán alkalmasak a feladatra.
Az eszközöket lehet csiszolni a végtelenségig és minden bizonnyal kell is, szerintem ide tartozhat az, hogy egyes részeket deklaratívan írhatunk le ahelyett, hogy imperatíve magyaráznánk a gépnek.
De a feladat minden kis nüanszát lefedő "tervrajzot" (ha már gyár analógia) nem lehet megúszni. Ennek a tervrajznak a software gyártásban a forráskód felel meg jelenlegi allapotok szerint, legyen az bárhogy is reprezentálva (pl. smalltalk környezetek object browserjei nem fárasztották/fárasztják a felhasználóit fileokkal, a lényeg szempontjából édesmindegy, hogy miképp vannak rögzítve). Nemrég láttam egy remek előadást ebben a témában, érdemes megnézni.
72

Jelen

Hidvégi Gábor · 2012. Nov. 4. (V), 14.49
Az, hogy most nemtudjuk megvalósítani a szoftvergyárakat, nem jelenti azt, hogy ez nem is lehetséges. Egyébként ez részben már ma is megvan, gondolj csak arra, hogy ha saját wikit szeretnél, letöltöd a mediawiki.org-ról, kicsit módosítasz a konfigurációs fájlon, és már írhatod is a bejegyzéseket. Idő kérdése, hogy az ilyen nagyobb szoftverkomponensek is tudjanak egymással kommunikálni, azaz, ahogy az előadásban is említi az emberke, az ismételhető feladatok elvégzése könnyebbé, automatizálhatóvá válik.

A programozón kívül mindenkinek érdeke, hogy az emberi tényezőt minél inkább kiiktassák a munkafolyamatból, hisz pénzbe kerül a képzése, rengeteg idő, amíg megtanul jól dolgozni, pénzbe kerül a "fenntartása", pénzbe kerülnek a hibái. Az más kérdés, hogy az emberiség növekedési üteme mellett mindenféle gépesítés és szoftveresítés nagyon komoly társadalmi problémákat vetít előre.
101

Jövő

Pepita · 2012. Nov. 5. (H), 03.56
Ha sikerül a jólfejlett szoftvergyár és ezzel azonos mértékben fejlődik az AI - hát akkor megnézhetjük magunkat...
Nem mint fejlesztők, hanem mint emberiség. Mert kényelmesebb lesz a nagy-nagy rendszereinkre rábízni a saját energiaellátásukat, alkatrészcseréjüket, továbbfejlesztésüket -> idővel szépen kitalálja, hogy az ember a legnagyobb kártevő a földön és nincs szüksége rá a saját működése biztosításához...

Nemrég olvastam Zsoldos Péter Ellenpont c. sci-fi-jét, talán a 80-as években írta, meglepően jó könyv. A Plutón egy robotkolónia "él" már vagy 600 éve ember nélkül (nem is ismeri), de végül felkutatja a katasztrófa túlélőit. Érdekes, hogy ha nem tekintem a szerző akkori technikai elgondolásait (pl. fogyasztási nagyságrendek, "rövid út"), akkor nagyon is lehetséges - mármint a sztori.

Szóval ez a kérdés érdekesebb, mint a kiinduló cikk, de még az "életveszély" és a társadalmi problémák előtt szintén komoly gazdasági fejtörést (gondot) is okozna. Az sem jó (gazdaságilag), ha valami hirtelen egy nagyságrenddel olcsóbb (és gyorsabb) lesz...
73

"Nem tudom, miért fáj az

BlaZe · 2012. Nov. 4. (V), 14.51
"Nem tudom, miért fáj az egyeseknek a cikk konklúziója? Mivel emberek alkották a programozási nyelveket, miért ne lehetnének hibásak vagy tökéletlen eszközeik?"

Nem fáj, csak butaság :) Mi köze egy nyelv minőségének ahhoz, hogy sok file-ból áll, vagy nem? És miért lenne rossz egy nyelv azért, mert IDE-vel jól támogatható és erre kimondottan gyúrnak is?

Az OOP nyújtotta szabályrendszer átlagos programozóknál valóban rengeteg előnyt nyújt, megakadályozza őket, hogy egy csomó alaphibát elkövessenek. Egy nagyon jó programozót viszont abban akadályoz meg, hogy jó programot írhasson, hisz csak korlátokat állít elé.


Itt mire gondolsz? Szerintem ahogy Ádám is írta feljebb, semmi ilyesmi különbség nincs az OO és a procedurális programozás között. Sőt, ha úgy tetszik, az OO nagyon sarkítva sok pici procedurális program. A global scope, vagy namespace a class maga, vannak benne függvények (metódusok), amik kapnak paramétereket. Az OO inkább egyfajta programozási, de főleg tervezési szemléletet ad. És szerintem ez az igazi előnye a procedurális programozással szemben. Procedurális nyelven igazából inkább csak funkcionális szinten tudsz tervezni, OO-ban pedig megvalósítási szinten is. Tudsz az alkalmazásodba tervezni valamiket, amiknek vannak tulajdonságaik és képesek valami funkciót ellátni, illetve definiált kapcsolatban állnak más valamikkel. Még azelőtt, hogy valódi kódot egy betűt is leírtál volna. Ez azért szerintem nem kötöttség, hanem lehetőség :)

Szerintem belátható időn belül ugyanúgy "gyárakban" készül minden program, amelyek nem feltétlenül lesznek kicsik és gyorsak, de hatékonyságban és fejlesztési időben verni fogják az emberek által készített társaikat.


Nem akarom elrontani az utópisztikus képedet :), de itt vissza kell kanyarodni kicsit a böngészős száladhoz: a gépeknek nincs intelligenciája. Vagyis csak emberek által definiált szabályok szerint, emberek által definiált működést tudnak megvalósítani. Lehet dobozokat (valamiket) definiálni, és azokat összefűzni egy működő egységgé, de ezt hatékonyan csak egy intelligenciával bíró entitás tudja megvalósítani, a tudomány mai állása szerint ez pedig jelenleg csak az ember. És ma tulajdonképpen ez történik: javarészt előre gyártott dobozokból építgetünk fel egész programokat, ezt hívjuk kód újrahasznosításnak. És vannak azért olyan szkeptikus vélemények is, hogy az AI képes lesz-e valaha hasonló eredményeket felmutatni, mint az emberi intelligencia.

A hagyományos gyárakkal szemben itt viszont először a kulimunkát fogják programokkal elvégeztetni, és elég lesz pár magasan kvalifikált mérnök a kóceráj működtetéséhez.


Ez az idő viszont már rég eljött :) Vannak seniorok, architectek, és az implementáció lényegét végző juniorok, még nem seniorok.
74

De, tképp fáj! Konkrétan

eddig bírtam szó nélkül · 2012. Nov. 4. (V), 14.59
De, tképp fáj! Konkrétan azért, mert úgy sejtem, az eredeti iromány szerzője nagyon is tisztában van vele, hogy hülyeséget írt, csak az oldala forgalmát akarta kissé megnövelni. (leír valami kapitális ökörséget, a netes fórumok ezt felkapják és terjed, mint a futótűz, benne a hivatkozással)
75

A cikk írója azt állítja,

Hidvégi Gábor · 2012. Nov. 4. (V), 15.50
A cikk írója azt állítja, hogy vannak olyan nyelvek, amelyekkel jóval egyszerűbb a munka, és nem igényelnek IDE-t ugyanazokhoz a feladatokhoz, mint például a java.

Az "Itt mire gondolsz?"-ra reagálva:
Az OOP az az Ádám által is felsorolt programozási technikák összessége. Ha egy egészen egyszerű programot is szeretnél OOP-vel megírni, minimum létre kell hozni egy osztályt, és annak a metódusait kell hívogatnod, míg pusztán procedurális programozás esetén elég megírnod egy függvényt (vagy csak a parancsok sorozatát).

Egy teljesen analóg példa: az F1 versenyzők 300 felett száguldoznak elég nagy hatékonysággal, de ha kimennek egy autópályára, ott nekik is 130 a megengedett - a nagy többség miatt. Funkcionális programozásban bármit megtehetsz, szabad a terep, míg OOP-ben már vannak szabályok. Viszont erre írtam a következőt: "Figyelembe véve az átlagos és a nagyon programozók arányát, az OOP felé billen a mérleg nyelve, ezen valóban nincs mit vitázni."
77

Ha egy egészen egyszerű

BlaZe · 2012. Nov. 4. (V), 16.20
Ha egy egészen egyszerű programot is szeretnél OOP-vel megírni, minimum létre kell hozni egy osztályt, és annak a metódusait kell hívogatnod, míg pusztán procedurális programozás esetén elég megírnod egy függvényt (vagy csak a parancsok sorozatát).


Ez így értelmetlen, ne haragudj :) Hello world c-ben:
#include <stdio.h>

int main() 
{
         printf("Hello World");

         return 0;
}
Javaban:
class HelloWorld
{
  public static void main(String args[])
  {
     System.out.println("hello world");
  }
}
Most akkor kinek mi az egyszerűbb? :) Valami gyakorlati példával többre mennénk. Így csak azt érzem, hogy van egy masszív fujj OOP benned, de ez nem érv. Mondhatod, hogy ez nálad szubjektív, mert nem tetszik és kész, vagy hozhatsz érveket. Vagy annyiban hagyhatjuk, csak ha már idecibáltál egy ilyen témát, én kíváncsi lennék konkrét példára, tapasztalatra, mert szeretem, ha tágítják a látóterem :) De egy class deklarálása csupán deklaráció, ahogy egy függvényé is.

Funkcionális programozásban bármit megtehetsz, szabad a terep, míg OOP-ben már vannak szabályok.


Erre lennék kíváncsi konkrétabban. Ez jól hangzik, de mit jelent valójában? :)

Egy teljesen analóg példa: az F1 versenyzők 300 felett száguldoznak elég nagy hatékonysággal, de ha kimennek egy autópályára, ott nekik is 130 a megengedett - a nagy többség miatt.


Vagyis a funkcionálisan programozók jobbak, mint az OO programozók, akiket le kell korlátozni, hogy működőt csináljanak? Ez elég érdekes gondolatmenet :) Én ennek a vitának kapcsán 2 dolgot érzek. Egyik, hogy nincs igazán tapasztalatod az OO programozásban, tervezésben, illetve ha dolgoztál így, nem jól fogtad meg a dolgot és szenvedtél miatta. Ezt azért érzem, mert olyan érveket hozol fel, amik a gyakorlatban nem állják meg a helyüket. A másik, hogy a vita kicsit elapadt az érveid miatt, mert ezek gyakorlatilag "csak" típusú érvek, tehát nem érvek.
80

Mint korábban írtam,

Hidvégi Gábor · 2012. Nov. 4. (V), 18.14
Mint korábban írtam, szeretném megérteni a különböző éppen használt programozási elveket, ebből következik, hogy hiányos ismereteim miatt tehetek olyan kijelentéseket, amelyek nem állják meg a helyüket.

Azt is írtam már korábban (hadd ne keressem meg, másik fórumbejegyzésben), hogy az OOP-nek az utóbbi húsz évben, amióta programozással foglalkozom, nekiszaladtam már párszor (Pascal, PHP, Javascript nyelveken), de egyszer sem éreztem, hogy bármilyen pluszt hozott volna a procedurálishoz képest, a programjaim nem lettek jobbak tőlük.

kíváncsi lennék konkrét példára, tapasztalatra
Az utóbbi tizenkét évben foglalkozom webes programozással (PHP, JS), és mindenféle IDE nélkül teljesen jól tudok dolgozni. Ehhez persze érdemes figyelembe venni a legnagyobb projektet, amin dolgoztam, ez jelenleg egy összességében kb. húszezer soros webes alkalmazás (PHP+JS). Nem tudom, hogy ez mennyire nagy vagy kicsi.

»Funkcionális programozásban bármit megtehetsz, szabad a terep, míg OOP-ben már vannak szabályok.«

Erre lennék kíváncsi konkrétabban. Ez jól hangzik, de mit jelent valójában? :)

Mint írtam, OOP-ben bármit szeretnél csinálni, létre kell hoznod egy osztályt. Ez korlátozza a gondolkodást, mert csak osztályokban gondolkodhatsz, íme, erről egy szórakoztató olvasmány.

Vagyis a funkcionálisan programozók jobbak, mint az OO programozók, akiket le kell korlátozni, hogy működőt csináljanak?
Nem értetted meg a példát. A funkcionális programozók jobbak lehetnek, mert nem köti meg semmi a kezüket. Egy OO programot könnyű "túltervezetté" (overengineer) tenni, erre tökéletes példa az ExtJS (JS alapú alkalmazásfejlesztő rendszer): egy kombóbox benne kb. hat vagy hét öröklődésen keresztül készül el (nem emlékszem pontosan, de kb. így: alapobjektum -> eseménykezelő -> űrlapelem wrapper -> beviteli mező wrapper -> kép wrapper -> kombóbox), és több, mint 600 sorból áll ez az objektumláncolat. Mivel ezzel állandó gond volt, fogtam, írtam egyet a nulláról, kétszáz sorból megoldottam, többet tud, és gyorsabb a futása.
81

PHP-ban csak osztályok

Joó Ádám · 2012. Nov. 4. (V), 18.28
PHP-ban csak osztályok képében tudsz új típust létrehozni. Ha nem írsz osztályokat, akkor ezek szerint minden adatot skalárként, sztringként, tömbként írsz le. Nem érzed a típusellenőrzés hiányát? Nem zavar, hogy minden eljárás elején kézzel kell ellenőrizd a paraméterek olyan tulajdonságait, amelyeket az interpreter maga is tudna?
83

Nem

Hidvégi Gábor · 2012. Nov. 4. (V), 18.41
Nem, csak a szükséges helyeken szoktam ellenőrzést végezni.
86

Így viszont nem tudod

Joó Ádám · 2012. Nov. 4. (V), 18.58
Így viszont nem tudod újrahasznosítani a kódot, amit írsz, mert csak az adott alkalmazás adott pontján működik helyesen, és ott is csak addig, amíg nem módosítod a hívó kódot.
88

Akkor viszont nem teljesen

Hidvégi Gábor · 2012. Nov. 4. (V), 19.15
Akkor viszont nem teljesen értem, amit írsz (a 81-essel kezdődően). Az általam készített szoftver úgy működik, hogy van egy bemenő adat, azt megrágom, és kiköpöm a kimenő adatokat. Ha a köztes folyamatban bármely részfunkciót több helyen fel kell használni, akkor kiteszem külön függvényekbe.
91

De ha olyan függvényt írsz,

Joó Ádám · 2012. Nov. 4. (V), 19.32
De ha olyan függvényt írsz, ami újrahasznosítható, akkor nem hagyatkozhatsz arra, hogy a hívó kód megfelelő paramétereket ad át, tehát neked kell a függvényen belül ellenőrizned azokat (például hogy egy valószínűségi változót váró függvény 0 és 1 közötti értéket kap). Saját típusok használatakor a fordító/értelmező ezt maga megteszi (az előbbi esetben ez gyorsabb futáshoz is vezet).
102

Többnyire "OOPárti" vagyok, de

Pepita · 2012. Nov. 5. (H), 04.13
- csak a vita kedvéért - az utóbbi esetben viszont akár lassabb is lehet. És mi volna a baj azzal, hogy az ellenőrzés a fv belsejében van? Ha több ilyen ellenőrzés kell ("valószám"), akkor az ellenőrzést is kiteszi egy külön fv-be. Végeredményben majdnem azt elérheted procedurálisan is, mint OOP, csak sokkal kisebb "mélységnél" veszted el az emberi szemmel való átláthatóságot.
Viszont ha egy OOP alkalmazást a végletekig optimalizálsz (a procira, nem a szemedre!), akkor végül egy struktúrált, néhány fv-ből és rengeteg fv-hívásból álló kódot kapsz, távolról sem OOP-t.
104

Szerintem nem jól érted, amit

BlaZe · 2012. Nov. 5. (H), 11.10
Szerintem nem jól érted, amit Ádám mondott :)

Viszont ha egy OOP alkalmazást a végletekig optimalizálsz (a procira, nem a szemedre!), akkor végül egy struktúrált, néhány fv-ből és rengeteg fv-hívásból álló kódot kapsz, távolról sem OOP-t.


Ennek viszont nincs értelme. Procira nem tudsz csak nagyon alacsony szintű kódot optimalizálni. De igazából már azt is megteszik a compilerek, pl pipelining. Egy mai jó nyelvnek a compilere is sokat optimalizál. Főleg, ha beépített nyelvi elemeket használsz, amire Ádám is utalt. És vannak az olyan megoldások is, mint pl a JIT, amik nem kicsit teker(het)ik meg a kód teljesítményét a frekventált helyeken.

De azért már régóta tudjuk, hogy olcsóbb a hardware, mint a fejlesztési idő, ezért használhatunk legtöbb helyen OOP-t. Ahol annyira fontos a sebesség, pl realtime alkalmazásoknál, ott azt úgy is tervezik. De ez még nem zárja ki az OOP-t. Futnak elég komoly trading alkalmazások pl Javaban, és ha valahol, ott aztán kell a teljesítmény. Pedig OOP, és még csak nem is natív nyelv. Elvileg :) De ott már bejön a GC tuning is, meg minden.
108

Valójában minden pointerekre

saxus · 2012. Nov. 7. (Sze), 12.31
Valójában minden pointerekre meg "gotora" fordul le. Akkor most dobjuk ki a procedurális nyelveket is? :)
85

az OOP-nek az utóbbi húsz

BlaZe · 2012. Nov. 4. (V), 18.56
az OOP-nek az utóbbi húsz évben, amióta programozással foglalkozom, nekiszaladtam már párszor (Pascal, PHP, Javascript nyelveken), de egyszer sem éreztem, hogy bármilyen pluszt hozott volna a procedurálishoz képest, a programjaim nem lettek jobbak tőlük.


Az én tapasztalataim szerint, akinek ilyen tapasztalata van, OOP-n általában classokba sűrített procedurális programozást ért. Érdemes megnézni az OOP patterneket, akkor talán tisztul a kép.

Vagy gondolkozz el azon, hogy pl amire Ádám utalt előbb mennyivel egyszerűbb, és mennyivel biztonságosabb:
interface Field
{
  void validate() throws FieldValidationFailedException;
}

class Form
{
  List<Field> fields;

  public void validate() throws FieldValidationFailedException
  {
     for ( Iterator<Field> iterator = fields.iterator(); iterator.next(); )
     {
       fields.next().validate; // itt FieldValidationFailedException jön ugye
     }
  }
}


// ->
Form form = new Form().addField(new FieldEmail("email")).addField( new AddressField() ) ...

try
{
  form.validate();
  form.process();
}
catch( FieldValidationException ex )
{
  // ouch
}
// <-
ennél:
// ->
valid = valid && validateEmail( request.getParameter( "email" );
valid = valid && validateAddressZip( request.getParameter( "addressZip" );
valid = valid && validateAddressCity( request.getParameter( "addressCity" );
...

if ( $valid )
{
  process();
}
else
{
  // ouch
}
// <-
A lényeg mindkettőben a // -> // <- között van. Lehetne még tekerni rajta, ez csak szemléltetés.

Mint írtam, OOP-ben bármit szeretnél csinálni, létre kell hoznod egy osztályt. Ez korlátozza a gondolkodást, mert csak osztályokban gondolkodhatsz


Procedurálisban meg kizárólag függvények (eljárások) vannak. Tehát az korlátozza a programozót, mert nem gondolkodhat objektumokban (valamikben), csak blackboxokban, ami bemenetre kimenetet hoz létre.

Nem értetted meg a példát. A funkcionális programozók jobbak lehetnek, mert nem köti meg semmi a kezüket.


De, pl az OO hiánya :) Lásd fent.

Az ExtJS-t én nem ismerem, így nem tudom mennyire van igazad, de az, hogy pl egy combo kirakása végigmegy egy pár ősosztályon, az nem jelenti azt, hogy lassabb, rosszabb lesz. Csak azt, hogy könnyebben adsz hozzá új input típust.
90

Blaze, nem tudod, mennyire

Hidvégi Gábor · 2012. Nov. 4. (V), 19.24
Blaze, nem tudod, mennyire megtisztelsz a türelmeddel, és igyekszem megérteni, amit írsz, néha nem megy azonnal, mert rengeteg gondolat kavarog a fejemben.

Az általad írt rossz (második) példában a problémát én az Ádám által megadott módon szoktam megoldani, kinézetre nagyon hasonló lenne a te első példádhoz.
92

Ha valaki hasznosnak találja

BlaZe · 2012. Nov. 4. (V), 19.52
Ha valaki hasznosnak találja az itt leírtakat, akkor már megéri beszélnünk róla. Én pl annak tartom.

A második megoldással az a baj, hogy le kell írni a validációt. És ha valaminek nem írod le a validációját, attól még felhasználhatod, pedig nincs ellenőrizve. Valójában ezt a gondolatot tovább kell vinni, hogy érthetőbb legyen:

public class Controller
{
  public void processPost( Form form ) 
  {
    try
    {
      validate();
      doProcess( form ); 
    }
    catch ( FieldValidationFailedException ex )
    {
      // hibakezeles
    }
  }

  protected abstract void doProcess( Form form );
}
Itt már ez a pici framework biztosítja, hogy az aktuális Controller implementációdban lévő doProcess() metódusodban csak ellenőrzött bemeneti értéket kaphatsz. Illetve mondhatsz form.render()-t, form.setFormLayoutRenderer()-t, aggathatsz rá saját validátorokat, amik már pl üzleti logika alapján validálnak: form.addValidator( new AddressValidator() ). Sőt, mondhatod azt is, hogy doProcess előtt nyitsz egy tranzakciót, sikeres lefutás esetén commit, exception esetén rollback stb... És akkor már ott vagy, hogy egy ilyen egyszerű pici frameworkkel is csak az üzleti logikára kell koncentrálj a doProcess()-ben.
93

Számomra nagyon hasznos volt

Hidvégi Gábor · 2012. Nov. 4. (V), 20.03
Számomra nagyon hasznos volt az egész, egyrészt hozzáértők véleményét olvashattam a felmerült kérdéseimre/felvetéseimre, másrészt volt pár link, amiken további érdekes vitákat olvastam.

Köszönöm mindenkinek a válaszokat, különösen a példákat, igyekszem azok fényében átgondolni a dolgokat.
87

A funkcionális programozók

Joó Ádám · 2012. Nov. 4. (V), 19.09
A funkcionális programozók jobbak lehetnek, mert nem köti meg semmi a kezüket.


(Procedurálisra gondolsz, a funkcionális más.)

A jó programozó tudja, hogy mikor milyen paradigmát használjon. Az objektumorientáltság nem vallás, hanem bevált gyakorlat.
107

Nem tudom, hogy ez mennyire

saxus · 2012. Nov. 7. (Sze), 12.29
Nem tudom, hogy ez mennyire nagy vagy kicsi.


Kicsi. Nagyon kicsi. Nagy projekt az 1M loc felett indul. Egyébként olyan érzésem van, hogy te kevered a funkcionális (pl. Scheme, Lisp...) és az imperatív procedurális nyelveket (C, Pascal, stb.) nyelveket.
69

Az öröklődés is OOP elem. A

tgr · 2012. Nov. 3. (Szo), 00.10
Az öröklődés is OOP elem. A népszerű nyelvek egyébként, ahogy már többször elhangzott, próbálják átvenni a népszerű elemeket minden paradigmából (pl. a PHP-ben viszonylag friss funkcionális elem az anonim függvény és a closure, és rövidesen generátorok is lesznek, a Harmony-ban lesznek osztályok, a Python dekorátorok az aspektus-orientált paradigmából származnak stb).

Ami a méret növekedését illeti, egy tízezer soros kód ugyanúgy nem áttekinthető eszközök nélkül, mint egy százezer soros; a Java kétségkívül egy bőbeszédű nyelv, de aligha ezen múlik, hogy szükség van-e IDE-re, még ha csak a navigációs képességeket nézzük is.

A cikk egyetlen érvényes pontja szvsz az, hogy a debugger az imperatív paradigmák sajátsága, és egy valódi funkcionális nyelvben nincs rá szükség, illetve nem is teljesen értelmezhető (helyette a kiértékelési fa bejárásában segíthetnek az IDE-k).

A Java amúgy miért nem valóban típusos?
78

Az öröklődés is OOP

Joó Ádám · 2012. Nov. 4. (V), 17.05
Az öröklődés is OOP elem.


Öröklődés nélkül a polimorfizmusnak nincs értelme.

Ami a méret növekedését illeti, egy tízezer soros kód ugyanúgy nem áttekinthető eszközök nélkül, mint egy százezer soros


De az a kód, ami A nyelven tízezer soros és áttekinthetetlen, az B nyelven, ezer sorban már áttekinthető. A nyelvek felelőssége, hogy a mindenkori jellemző kódállomány kezeléséhez megfelelő eszközöket biztosítsanak. Az egyre újabb és újabb nyelvi eszközök megjelenését mindig a folyamatosan növekvő komplexitás hajtotta.

a Java kétségkívül egy bőbeszédű nyelv, de aligha ezen múlik, hogy szükség van-e IDE-re, még ha csak a navigációs képességeket nézzük is.


Ha egy nyelv bőbeszédű, vagy nem ad elég magas szintű eszközöket, akkor a kód hosszabb, amit nehezebb kezelni, szerintem ezzel nem lehet vitatkozni. Például Javában egy egysoros map átadásához létre kell hoznom egy teljes új osztályt, ráadásul a hívás helyétől messze, ami sokkal nehezebben áttekinthetővé teszi a kódot.

A Java amúgy miért nem valóban típusos?


Csak osztályokat tudok létrehozni, amik kilógnak a beépített típusok közül. Nem tudok létrehozni például saját skalár típust, hozzárendelt értéktartománnyal.
103

Ha egy nyelv bőbeszédű, vagy

tgr · 2012. Nov. 5. (H), 11.07
Ha egy nyelv bőbeszédű, vagy nem ad elég magas szintű eszközöket, akkor a kód hosszabb, amit nehezebb kezelni, szerintem ezzel nem lehet vitatkozni.


Azzal viszont igen, hogy egy reális bonyolultságú feladat (nem hello world) magas szintű eszközökkel kezelhető méreten belül marad. Ezer sorból funkcionális nyelven sem raksz össze egy komplett alkalmazást.
71

Mindenkinek, aki ismét leállt

BlaZe · 2012. Nov. 4. (V), 14.27
Mindenkinek, aki ismét leállt pro vagy kontra az objektumorientáltságról veszekedni: az állományok és sorok számának növekedése nem az objektumorientált szemlélet következménye.

Az objektumorientáltság különböző programozási paradigmák összessége: modularitás, adattípusok, összetétel, absztrakció, egységbezárás, öröklődés és polimorfizmus. Ezek közül mindegyik használható és használandó bármely típusos, strukturált nyelven. Az egyetlen kivétel, valójában tehát az, amit az objektumorientáltság a világnak adott, a polimorfizmus.


Igen is, meg nem is. Nyilván egy procedurális nyelven is növekedik a kódmennyiség, viszont ami különbség, hogy a procedurális programozás igazából csak az implementációt ismeri, egy jó OO kód alapja pedig az absztrakció (interface->abstract class->bővebb abstract class ... -> implementáció -> implementáció kibővítése ...), jóval több a definiálás, öröklődés stb. Hogy a sorok számában ez hoz-e növekedést, azon lehet vitatkozni, bár szerintem ez nem is érdekes. Az eredeti bejegyzés felvetésében a file-ok mennyiségén van a hangsúly, ez pedig egyértelműen igaz. De bennem továbbra is kérdés, hogy ez miért baj, miért kéne bárminek is a minőségét mérni azzal, hogy hány file-ból áll? Ki az, aki ma egy komolyabb rendszert IDE nélkül akar megcsinálni? Ha meg van IDE, akkor miért ne használnánk ki a tudását?

Sőt, ha már a kód minőségének mérésénél tartunk, a jelenlegi elvek ezzel pont szembe mennek: minél kisebb egy adott programegység (osztály, metódus) mérete, annál jobbnak tartják, mert annál definiáltabb, vagyis átláthatóbb, karbantarthatóbb az egység működése (code complexity).
79

a procedurális programozás

Joó Ádám · 2012. Nov. 4. (V), 17.08
a procedurális programozás igazából csak az implementációt ismeri, egy jó OO kód alapja pedig az absztrakció (interface->abstract class->bővebb abstract class ... -> implementáció -> implementáció kibővítése ...)


Ez nem így van, ahogy fent is írtam, az objektumorientáltság egyetlen újdonsága a polimorfizmus volt. Az absztrakciót nem az OOP találta fel, bármennyire is fáj (az eljárás mint olyan az absztrakciók ősapja).
82

Szerintem egy dologról

BlaZe · 2012. Nov. 4. (V), 18.29
Szerintem egy dologról beszélünk. Ahogy te is írtad, a poliformizmust az OOP vezette be a programozásba. Amiről én beszélek, az pedig pont ez. Procedurális nyelvben nem igazán létezik az, hogy definiálok valamit egy absztrakciós szinten, amit majd valahol valaki(k) implementál(nak) és a program a használt implementáció szerint működik. Ha egy procedurális nyelven megírsz egy függvényt, az a függvény úgy működik, azt csinálja és pont. Ha más működést akarsz, azt a függvényt újra meg kell írnod (más néven). És ez az egész hívási láncot érinti. Ez az, amiről lényegében mindketten beszéltünk.

Amiért én írtam a fentit, hogy ennek az absztrakciónak a következménye, hogy mivel (nagy általánosságban) minden class/interface külön file, igaz a blog felvetése, miszerint az OO kód több filet generál. Hogy sorban több, vagy kevesebb ugyanaz a funkcionalitás OO, mint procedurális megvalósításban, az már kérdéses. Ha sok a hasonló funkcionalitás, akkor szerintem elképzelhető, hogy a polimorfizmus miatt sorban pont kevesebb lesz az OO kód. De szerintem ez igazából nem lényeges, mert továbbra sem a mérettől lesz jó, vagy nem jó egy kód, vagy egy programozási nyelv.
84

Procedurális nyelvben nem

Joó Ádám · 2012. Nov. 4. (V), 18.42
Procedurális nyelvben nem igazán létezik az, hogy definiálok valamit egy absztrakciós szinten, amit majd valahol valaki(k) implementál(nak) és a program a használt implementáció szerint működik. Ha egy procedurális nyelven megírsz egy függvényt, az a függvény úgy működik, azt csinálja és pont. Ha más működést akarsz, azt a függvényt újra meg kell írnod (más néven).
typedef int (*interface)(int);

void map(int *array, unsigned int length, interface implementation) {
    unsigned int i;

    for (i = 0; i < length; i++) {
        array[i] = implementation(array[i]);
    }
}

int increment(int number) {
    return number + 1;
}

int square(int number) {
    return number * number;
}
:)

De szerintem ez igazából nem lényeges, mert továbbra sem a mérettől lesz jó, vagy nem jó egy kód, vagy egy programozási nyelv.


Pedig azért nem írunk üzleti alkalmazást gépi kódban, mert azon az absztrakciós szinten kezelhetetlen a kód mérete.
89

Ok nyertél, sejtettem, hogy

BlaZe · 2012. Nov. 4. (V), 19.18
Ok nyertél, sejtettem, hogy ezt be fogod húzni, vagy valami egyéb függvény átadást :) De ez azért nem teljesen az, mint amiről beszélünk. Főleg, ha ezt n szinten képzeled el.

Pedig azért nem írunk üzleti alkalmazást gépi kódban, mert azon az absztrakciós szinten kezelhetetlen a kód mérete.


:) Egyrészt. De főleg azért, mert a gépi kód olvashatatlan "azon az absztrakciós szinten", ahol az üzleti logikát implementáljuk, és ez főleg nem a méretén múlik. Már assemblyben is írtunk macrokat stb. Ebben azért a mai nyelvekben nincs igazán nagy különbség. Aki ismeri a nyelvet és a szintaktikát, az ha ránéz egy jó kódra megérti a működését. És ez a lényeg, ebben mérjük a kód minőségét, nem abban, hogy 20, vagy 30 sor egy logika megvalósítása. Illetve van pl code complexity, de ez már más téma.
94

De ez azért nem teljesen az,

Joó Ádám · 2012. Nov. 4. (V), 20.11
De ez azért nem teljesen az, mint amiről beszélünk. Főleg, ha ezt n szinten képzeled el.


Nyilván, nem véletlen, hogy az algoritmusok polimorfizmusa után megjelent az adatoké is. Csak zavaró, ha hetven év nyelvi fejlődését húszénak tudjuk be.

De főleg azért, mert a gépi kód olvashatatlan "azon az absztrakciós szinten", ahol az üzleti logikát implementáljuk, és ez főleg nem a méretén múlik.


Ezt hogy érted?

Már assemblyben is írtunk macrokat stb.


Nem véletlen, hogy gépi kódot és nem assembly-t írtam. Egy makró új absztrakciós szintet vezet be, és épp a tömörebb kód végett találták ki. Az egyre magasabb szintű nyelvek pedig mind egyre kifinomultabb makrók a gépi kód fölött.

És ez a lényeg, ebben mérjük a kód minőségét, nem abban, hogy 20, vagy 30 sor egy logika megvalósítása.


A kódét igen, a méret mellett egyébként, hisz a redundáns kódot sem tartjuk jó minőségűnek. A nyelv esetében azonban fontos, hogy a lehető legtömörebben fejezze ki, amit kell. Ez egyébként a természetes nyelvek esetében is igaz.
95

Csak zavaró, ha hetven év

BlaZe · 2012. Nov. 4. (V), 21.54
Csak zavaró, ha hetven év nyelvi fejlődését húszénak tudjuk be.

Erről szó sem volt.

Ezt hogy érted?


Arra, hogy ha egy programozó 
echo 'Hello, world!';
helyett 
section	.data

msg	db	"Hello, world!",0xa
...
push	dword msg
call	_echo
sorokat látna, tuti becsokizna :) És ez a legegyszerűbb eset, ráadásul csak a hívás. És még csak nem is gépi kód, csak az itt furán mutatna (meg ahhoz kicsit komolyan kéne guglizni :))
96

Erről szó sem volt. Sokan

Joó Ádám · 2012. Nov. 4. (V), 22.22
Erről szó sem volt.


Sokan vannak, akik azt hiszik, a szép új világot a Java jelenti és hozta el a világnak.

A másik felvetésre: Az Intel és a GNU assembly szintakszis elég ocsmányak, de ez nem a dolog természetéből fakad. Semmi akadálya jól olvasható, a magas szintű nyelveket követő szintakszisú assembly nyelvet írni (létezik is). A gond az, hogy a processzor által nyújtott műveletek annyira elemiek, hogy egy üzleti alkalmazás követhetetlen velük. Itt lép képbe a strukturálás és az absztrakciók.
97

Sokan vannak, akik azt

BlaZe · 2012. Nov. 4. (V), 23.19
Sokan vannak, akik azt hiszik, a szép új világot a Java jelenti és hozta el a világnak.

Az azért kétségtelen, hogy egy nagyon komoly hatású nyelv, hozott (elismertett) pár dolgot a mainstream programozásba (VM, platformfüggetlenség, pure OOP), amiknek a létjogosultságáról, de legalábbis hatékonyságáról korábban azért voltak viták a szakmán belül. És tegyük hozzá, a Java is kínlódott vele eleinte. Ma pedig a Java sikeressége miatt más nyelvek is egyre inkább építenek ezekre. De hát nyilván előtte is volt élet, és a Javaba is összelapátoltak sok más nyelvből jó ötleteket. De a Java se véletlenül van itt már közel 20 éve, na :)

A C-re meg hatványozottan igaz ugyanez. Elképesztő, hogy már 40 éve (pont idén 40) itt van, és még mindig az egyik legnépszerűbb programozási nyelv.

A másik felvetésre: Az Intel és a GNU assembly szintakszis elég ocsmányak, de ez nem a dolog természetéből fakad. Semmi akadálya jól olvasható, a magas szintű nyelveket követő szintakszisú assembly nyelvet írni (létezik is).

Összetöröd a nosztalgikus érzéseimet :) Én imádtam assemblyben programozni. De az tény, hogy nem túl valószínű, hogy találkozunk még valaha. Mostanában épp egy nagyon szűk erőforrású mobiltelefon chippel dolgozok, de már ez is Java. Lassan a vasalóban is Java fog futni :)
110

Egységbe zárás

saxus · 2012. Nov. 7. (Sze), 12.55
Azért van még egy-két előnye.
class NetworkCredentials
{
  private string _username;
  public string Username { 
    get { return _username; }
    set { 
      if (string.IsNullOrEmpty(value))
        throw new InvalidArgumentException("value");

      _username = value;
    }

  private string _password;
  public string Password {
    get { return _password; }
    set { 
      if (string.IsNullOrEmpty(value))
        throw new InvalidArgumentException("value");

      _password = value;
    }


  public NetworkCredentials(string username, string password)
  {    
    Username = username;
    Password = password;
  }
}

class SecureDownloader
{
   public static byte[] Download(NetworkCredentials creds, string url)
   {
      if (creds == null) throw new ArgumentNullException("creds");
      if (string.IsNullOrEmpty(url) throw new ArgumentException("...");

      ...
   }
}
Oké, nem kevés kód a NetworkCredentials osztály létrehozása. Viszont van egy olyan előnye, hogy képes megvédeni magát az érvénytelen adatoktól és a SecureDownloader biztos lehet abban, hogy (ha kap) egy NetworkCredentials-t, akkor csak és kizárólag olyat fog kapni, amiben érvényes adatok vannak. Persze, lehet, hogy mi figyelünk arra, hogy mindig legyen username meg password. Vajon, aki használja a programot az is figyelni fogja? (Egyébként össze lehet vetni a megoldás hülyebiztosságát azzal, ha pl. egy PHP-s array-t adnank at ehelyett...)

Hibaellenőrzés meg mindenhova kell. Pont két hete volt erre egy nagyon jó példa: egyik user egy törölt szállítási módot bökött ki egy rendeléshez (hogy a használt ügyviteli rendszer miért enged ilyet kiválasztani, azt hagyjuk...), ami a webre való szinkronizáláskor dobott egy exceptiont, mondván, hogy nem érvényes szállítási mód.

(Ilyen enumszerű képződményekre - miután nincs rá nyelvi elem - szoktam használni PHP-ben ilyesmiket:
class Valami
{
   const X = 1;
   const Y = 2;

   public static function validate($value)
   {
      return in_array($value, array(valami::X, valami::Y));
   }
}
Mennyivel tisztább, szárazabb élmény egy helyre kigyűjtve, mint mindenhol külön-külön (mennyire tipikus).

Persze, lehetne így is:

define('Valami_X', 1);
define('Valami_Y', 2);

function Valami_validate($value)
{
  return in_array($value, array(Valami_X, Valami_Y));
}
Végeredményben nem különbözik. Azonban van egy kis különbség aközött, hogy tudjuk, hogy az X,Y az a valami-nek a része és a validate függvény is ahhoz tartozik, ezzel logikailag egységbe van foglalva. (A fájlok nem logikai egységek a -legtöbb- programnyelv szempontjából! A fájlok csupán azért vannak, hogy kezelhető legyen a kód.)

Arról nem is beszélve, hogy ha leírom, hogy Valami:: akkor egy normálsi IDE már ajánlja fel, hogy mik vannak.
114

Itt most mire válaszoltál?

Joó Ádám · 2012. Nov. 7. (Sze), 16.39
Itt most mire válaszoltál?
115

Arra, hogy azért van más is a

saxus · 2012. Nov. 7. (Sze), 21.37
Arra, hogy azért van más is a polimorfizmuson kívül, ami nagy hasznosság az objektum-orientált programozásnál. Példa mondjuk leginkább Hidvégi Gábornak szól.
116

Sejtettem, köszönöm.

Hidvégi Gábor · 2012. Nov. 7. (Sze), 22.41
Sejtettem, köszönöm.
117

C-ben is működik az

Joó Ádám · 2012. Nov. 8. (Cs), 02.51
C-ben is működik az egységbezárás, átlátszatlan típusokkal. A második példádban pedig csak azért kell osztályt használj, mert a PHP gyengén típusos, és nincs benne felsorolás.
119

Szerintem kevered az

saxus · 2012. Nov. 9. (P), 01.36
Szerintem kevered az adatrejtés elvét az egységbezárással.
120

Szerintem pedig nem

Joó Ádám · 2012. Nov. 9. (P), 22.03
Szerintem pedig nem egyértelmű fogalmak. Ha így érzed, akkor te mit értesz egységbezárás alatt?
121

Maguk a fogalmak

saxus · 2012. Nov. 10. (Szo), 22.51
Maguk a fogalmak egyértelműek, csak én nem adtam rossz példákat - azok inkább az adatrejtés elvére vonatkoznak. (Csodálom, hogy nem vette észre senki :) Bár jobban belegondolva az egységbezárás és az adatrejtés többnyire kéz a kézben jár.

Egységbe zárás azt jelenti, hogy nem választjuk el az adatokat és az azokkal dolgozó függvényeket, hanem egy egységben (osztály) kezeljük. (Pl. Complex osztály tartalmazza az azokon végzett műveleteket.) Ezt C-ben nem tudod megoldani, mert nincs olyan, hogy egység.

Adatrejtés meg azt jelenti, hogy az adatmezőidet elrejted a külvilág elől és csak ellenőrzött függvényhívásokon keresztül éred el. (Bár személyes véleményem az, hogy pl. Java-ból naaaaaagyon hiányzik a property fogalma, ami C#-ban nagyon-nagyon sok felesleges kódtól szabadítja meg az embert, valamint a setter/getterek is sokkal-sokkal átláthatóbbak.)

C-ben ezt sem tudod jól kivitelezni, mert vagy mindent elrejtesz vagy mindent megmutatsz. Készíthetsz függvényeket, amelyek visszaadják egy opaque struct egy mezőjét, de akkor már sérül az egységbezárás elve, hiszen ez a függvény nem a struct része.

Zárójelesen hozzátenném azonban, hogy egy OOP nyelvben is rendszeresen előfordul, hogy hébe-hóba meg sértjük az adatrejtés (pl. reflection, friend class C++-ban, internal láthatóság és friend assembly, bár utóbbin el lehet vitatkozni, hiszen a .NET Assembly egy újabb egység) és az egységbezárás ("helper" osztályok a komplexitás csökkentésére) elvét, de azonban ezekre rendszerint van valamilyen kontrollált megoldás.
122

Maguk a fogalmak

Joó Ádám · 2012. Nov. 11. (V), 02.37
Maguk a fogalmak egyértelműek, csak én nem adtam rossz példákat - azok inkább az adatrejtés elvére vonatkoznak. (Csodálom, hogy nem vette észre senki :)


Én láttam, hogy az adatrejtésre adtál példákat, ezért úgy gondoltam, hogy az egységbezárást az adatrejtés elvének egy lehetséges megvalósításaként értelmezed. A vonatkozó Wikipédia szócikk egyik értelmezése ez.

Egységbe zárás azt jelenti, hogy nem választjuk el az adatokat és az azokkal dolgozó függvényeket, hanem egy egységben (osztály) kezeljük. (Pl. Complex osztály tartalmazza az azokon végzett műveleteket.) Ezt C-ben nem tudod megoldani, mert nincs olyan, hogy egység.


De, C-ben is van egység, compilation unit a neve. De az osztályok szerepét ebből a szempontból a struktúrák tökéletesen betöltik, hisz a struct a-hoz írt függvényt nem tudom meghívni struct b-re (sajnos C-ben a paraméterek nem részei a kézjegynek, ezért meg kell különböztetni a függvényeket, de ez tervezési hiba, nem a paradigma sajátsága). Az pedig, hogy a függvényt a struktúra definícióban adom-e meg, aligha képezi tárgyát az egységbezárás elvének (C++-ban például a tagfüggvény definícióját az osztályon kívül adom meg).

C-ben ezt sem tudod jól kivitelezni, mert vagy mindent elrejtesz vagy mindent megmutatsz.


Ez sem igaz:
/* implementation.c */

#include <stdlib.h>

struct implementation {
    int public;
    int private;
};

struct interface *construct_interface() {
    struct implementation *implementation = malloc(sizeof (struct implementation));
    
    implementation->public  = 0;
    implementation->private = 42;
    
    return (struct interface *) implementation;
}
/* interface.h */

struct interface {
    int public;
};

struct interface *construct_interface();
/* test.c */

#include "interface.h"

int main() {
    struct interface *interface = construct_interface();
    
    interface->public  = 1;
    interface->private = 2; /* error: ‘struct interface’ has no member named ‘private’ */
    
    return 0;
}
Zárójelesen hozzátenném azonban, hogy egy OOP nyelvben is rendszeresen előfordul, hogy hébe-hóba meg sértjük az adatrejtés … és az egységbezárás … elvét


Ezért elv és nem törvény :)
123

Az pedig, hogy a függvényt a

saxus · 2012. Nov. 11. (V), 04.15
Az pedig, hogy a függvényt a struktúra definícióban adom-e meg, aligha képezi tárgyát az egységbezárás elvének (C++-ban például a tagfüggvény definícióját az osztályon kívül adom meg).


Félreérted: nem arról van szó, hogy az implementáció és a deklaráció elkülönül-e vagy sem, hanem arról, hogy egy egységed van. Maguk az adatokhoz tartozó műveletek nem kapcsolódnak sehogy sem a structhoz, teljesen önálló kicsi egységeket alkotnak.

Ez sem igaz


Ok, jogos, nem tudtam, hogy forwarded delcaration-nak meg lehet adni törzset. Bár azért tegyük hozzá, hogy normális OOP esetén alapból mindent rejtesz és csak a megfelelő setter/getteren keresztül (ami jobb esetben property, rosszabb esetben függvény) érsz el mindent.

hisz a struct a-hoz írt függvényt nem tudom meghívni struct b-re


(b*)(void*) ;)
125

Félreérted: nem arról van

Joó Ádám · 2012. Nov. 11. (V), 16.38
Félreérted: nem arról van szó, hogy az implementáció és a deklaráció elkülönül-e vagy sem, hanem arról, hogy egy egységed van. Maguk az adatokhoz tartozó műveletek nem kapcsolódnak sehogy sem a structhoz, teljesen önálló kicsi egységeket alkotnak.


Mitől tartod őket egységnek más nyelvekben? A C forráskódban fizikailag a függvények önállóan jelennek meg, a típusrendszer azonban hozzáköti őket a struktúrához. C++-ban ugyanehhez kapok szintaktikai édesítőszert: a tagfüggvényeket ugyanúgy a rejtett this paraméter típusa köti egy struktúrához.

Bár azért tegyük hozzá, hogy normális OOP esetén alapból mindent rejtesz és csak a megfelelő setter/getteren keresztül (ami jobb esetben property, rosszabb esetben függvény) érsz el mindent.


Itt csak arra reagáltam, hogy nem mindent vagy semmit kell elrejts, illetve megmutass. Persze, normális esetben a lekérdezéshez és a beállításhoz függvényt írsz, ami, ahogy fent írtam, nem sérti az egységbezárást, mert ahhoz a struktúrához tartozik.

(b*)(void*) ;)


Ugyanígy egy privát tagváltozó is kiolvasható C++-ban :) A típusrendszer arra való, hogy segítse a fejlesztőt, nem arra, hogy bármiben megakadályozza :)
127

Mitől tartod őket egységnek

saxus · 2012. Nov. 12. (H), 04.09
Mitől tartod őket egységnek más nyelvekben?


Hogy nem egy függvénynek adod át azt, amivel dolgozol, hanem az objektumon végzel műveletet. A tagfüggvény a típus része.

Ugyanígy egy privát tagváltozó is kiolvasható C++-ban :)


Nyilván Java-ban és .NET-ben is ott a Reflection első szinten.

A típusrendszer arra való, hogy segítse a fejlesztőt


És itt jön be az, hogy egy OOP nyelvben egy jó IDE-ben ha egy objektum/osztály neve után nyomok egy ./::/->/[] jelet, akkor nekem az IDE egyből dobja fel, hogy mi az, ami az adott objektumhoz tartozik/mit tudok az adott objektummal művelni.

nem arra, hogy bármiben megakadályozza :)


Ami azt illeti, de: megakadályozza, hogy hülyeséget vagy nem kívánt dolgot csináljon. Nem feltétlen azt, aki írja, lehet, hogy más kollégát vagy egy 256.-ként odakerülőt kell megakadályozni valamiben.
129

Hogy nem egy függvénynek adod

Joó Ádám · 2012. Nov. 12. (H), 13.39
Hogy nem egy függvénynek adod át azt, amivel dolgozol, hanem az objektumon végzel műveletet. A tagfüggvény a típus része.


Itt csak magamat tudnám ismételni: attól, hogy más szintakszissal hívok egy függvényt, attól az még csak egy függvény marad.

És itt jön be az, hogy egy OOP nyelvben egy jó IDE-ben ha egy objektum/osztály neve után nyomok egy ./::/->/[] jelet, akkor nekem az IDE egyből dobja fel, hogy mi az, ami az adott objektumhoz tartozik/mit tudok az adott objektummal művelni.


A hozzá tartozó függvényeket ugyanúgy fel lehet dobni.

Ami azt illeti, de: megakadályozza, hogy hülyeséget vagy nem kívánt dolgot csináljon. Nem feltétlen azt, aki írja, lehet, hogy más kollégát vagy egy 256.-ként odakerülőt kell megakadályozni valamiben.


Nem: segít elkerülni a véletlen hibákat, de nem akadályoz akkor, ha jelzem neki, hogy tudom, mit csinálok.
130

Itt csak magamat tudnám

saxus · 2012. Nov. 12. (H), 17.28
Itt csak magamat tudnám ismételni: attól, hogy más szintakszissal hívok egy függvényt, attól az még csak egy függvény marad.


De itt nem csak szintaktikai különbségről van szó, hanem gondolkodásbeli különbségről is. Nagyon sokan azért nem értik az OOP-t, mert továbbra is függvényekben gondolkodnak ahelyett, hogy tagfüggvényekben (vagy sokkal inkább helyesebben: metódusokban és üzenetváltásokban*) és típusokban gondolkodna.

* Rendben van, C++ nem ezt az utat járja és ez végigvonul a Java, C#, stb. vonulaton is.

A hozzá tartozó függvényeket ugyanúgy fel lehet dobni.


Mégis hogy? :) Van egy char* a -m, amiben egy stringet tárolok. Hogyan dobatom fel az IDE-vel, hogy mik az ehhez tartozó szövegmanipuláló függvények? :)
131

Mégis hogy? :) Van egy char*

Joó Ádám · 2012. Nov. 12. (H), 20.27
Mégis hogy? :) Van egy char* a -m, amiben egy stringet tárolok. Hogyan dobatom fel az IDE-vel, hogy mik az ehhez tartozó szövegmanipuláló függvények?


Leírod a változót, megnyomod a gyorsbillentyűt, és az IDE feldobja azokat a függvényeket, amik ilyen típusú paramétert várnak. Ha kiválasztod, beszúrja a helyére, majd megadod az esetleges további paramétereket.
132

Messages

complex857 · 2012. Nov. 13. (K), 12.10
Anno Alan Key írta:
I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages...


Lehet ha "üzenet"ként hivatkoznánk ezekre jobban elkülönülnének ezek a fogalmak.
Azhogy egy-egy object milyen üzeneteket ért, éshogy milyen metódusai vannak eleve nem szükségszerűen egy és ugyanaz (lésd még __call(), method_missing, __getattr__, doesNotUnderstand).
133

Igen, az alapvető probléma

saxus · 2012. Nov. 13. (K), 14.51
Igen, az alapvető probléma az, hogy amit mi OOP nyelveknek hívunk azok nem feltétlen OOP nyelvek, csak OO programozást (is) támogató nyelvek. Ld. C++.

Érdemes utánanézni pl. az Actor modellnek, ahol minden objektum egy önálló kis zárt "programként" (természetesen nem OS szintű thread vagy process-ként kell elképzelni) fut, és csak üzenetváltásokkal lehet kommunikálni egymással. Más világ első nekifutásra.
134

Más, vannak előnyei,

BlaZe · 2012. Nov. 13. (K), 15.57
Más, vannak előnyei, hátrányai is. Pl nagyon laza kötést ad az egyes objektumok között, ami azért nem feltétlenül segíti pl a program karbantarthatóságát, navigálhatóságát. De jelenleg is használjuk ezt a modellt, csak kicsit másképp. Eseményeket, vagy üzeneteket tudunk küldeni célzott objektumoknak (nevezzük inkább destinationnek), pl message queuekkal. Az üzenetküldés 1 szinttel feljebb, rendszer, vagy komponens szintre lett emelve. Szerintem azért ez így hatékonyabb is, nem véletlenül így terjedt el.

Pl: AMQP XMPP JMS És még kismillió implementáció és protokoll. Pl egy job tábla is egy message queue, és ilyesmit weben is gyakran használunk. Érdemes ismerni ezeket, ahol lehet (async requestek, pl keresések), nagyon jó eszköz a terhelés kontrollálására (párhuzamos requestek sorosítása). Meg nem nyitott zárójel bezárva :)
135

Amikről te beszélsz az

saxus · 2012. Nov. 14. (Sze), 07.40
Amikről te beszélsz az sokkal-sokkal-sokkal magasabb szint, mint ami pl. Erlangban van. Erlangban pl.

Itt magának az objektumnak van üzenetlistája (látszólag, valójában ezt az egészet megoldja jól a runtime, hogy optimális legyen). Ennek köszönhető, hogy egy objektum egyszerre mindig csak egy "hívást" kezel, emiatt nincs érvénytelen állapota (nincs lock!), stb. Ez teszi pl. az Erlangot jól skálázhatóvá. De ez nem okoz lazább kötéseket, hisz ez nyelvi szinten működik.

Csak ez egy egész más megközelítés, mint amin a C++ elindult).

Ami inkább laza kötést ad, az az, amikor mindent Interface-kon keresztül intézel, hiszen elrejti a mögöttes objektum valódi típusát (bár ez a cél) valamint a delegáltak (eseménykezelők, .NET-ben) használata. Bár ezen helyeken általában ez a cél, hogy az egyes modulok, részegységek között laza kötést alakítsunk ki, hogy egymással cserélhetőek legyenek.
136

Amikről te beszélsz az

BlaZe · 2012. Nov. 14. (Sze), 09.12
Amikről te beszélsz az sokkal-sokkal-sokkal magasabb szint, mint ami pl. Erlangban van. Erlangban pl.

Igen, ezt írtam.

Itt magának az objektumnak van üzenetlistája (látszólag, valójában ezt az egészet megoldja jól a runtime, hogy optimális legyen). Ennek köszönhető, hogy egy objektum egyszerre mindig csak egy "hívást" kezel, emiatt nincs érvénytelen állapota (nincs lock!), stb. Ez teszi pl. az Erlangot jól skálázhatóvá. De ez nem okoz lazább kötéseket, hisz ez nyelvi szinten működik.

De, definíció szerint lazább kötéseket okoz, enélkül nem lenne skálázható. És ne hívjuk objektumnak, hívjuk processnek, mert ez félreértésekre adhat okot (az Erlang nem OOP nyelv). Erlangban processeket tudsz indítani, és a processek közötti üzenetcserére vezetett be nyelvi eszközöket. Ez azért más, mint amit te mondasz. Ha úgy lenne, az egy nagyon durva bottleneck lenne, illetve konkrétan agyonvágná a többszálúságot, amiről azért nincs szó.

Csak ez egy egész más megközelítés, mint amin a C++ elindult).

Nagyon, más nyelvcsaládba is tartoznak.

Lazább kötés alatt itt egyébként azt értem, hogy nem egy pontosan beazonosítható része fog lefutni a programnak, igazából nem is kell tudd, nem is érdekel mi fogja fogadni az üzeneted. Megmondod melyik processnek és milyen üzenetet küldesz, majd megadod a paramétereket. Ami paraméterek függvényében akár más blokkba is beeshet a fogadó oldalon, de erről nem feltétlenül tudsz. És ez a laza kötés okozza a skálázhatóságot. Ezért írtam az előző hozzászólásomat, hogy erre van mód nyelvfüggetlenül is, mert ez valóban nagyon hatékony eszköz a skálázásra. És a vicc kedvéért van olyan XMPP és AMQP implementáció, amit Erlangban írtak :)
137

És ne hívjuk objektumnak,

saxus · 2012. Nov. 14. (Sze), 11.59
És ne hívjuk objektumnak, hívjuk processnek, mert ez félreértésekre adhat okot


Na most aki magyarázott nekem az erlangról az pont azt mondta, hogy azért ne hívjuk processeknek, mert mindenki az OS processekkel fogja azonosítani és félre fogja érteni :)

Egyébként maga a nyelv AFAIK actor-nak hívja.
138

Na most aki magyarázott nekem

BlaZe · 2012. Nov. 14. (Sze), 12.53
Na most aki magyarázott nekem az erlangról az pont azt mondta, hogy azért ne hívjuk processeknek, mert mindenki az OS processekkel fogja azonosítani és félre fogja érteni :)

Hát az könnyen lehet :) Bár attól azért nem áll olyan messze:

(Aside: the term "process" is usually used when the threads of execution share no data with each other and the term "thread" when they share data in some way. Threads of execution in Erlang share no data, that's why we call them processes)
139

És lassan fentről lefelé

BlaZe · 2012. Nov. 14. (Sze), 12.54
És lassan fentről lefelé olvassuk a szavakat ;)
124

Bár személyes véleményem az,

BlaZe · 2012. Nov. 11. (V), 15.24
Bár személyes véleményem az, hogy pl. Java-ból naaaaaagyon hiányzik a property fogalma, ami C#-ban nagyon-nagyon sok felesleges kódtól szabadítja meg az embert, valamint a setter/getterek is sokkal-sokkal átláthatóbbak.)


Megoldható javaban is, csak nem a core nyelv része. Bár szerintem hótmindegy, hisz a gyakorlatban ezeket úgyis az IDE generálja :) Úgyhogy én ezt nem igazán értettem sosem. A POJO azért POJO, mert pont ezt a funkciót látja el. Illetve ezzel pont megsértenéd az egységbezárás elvét, ezért van ez leszavazva javaban.
126

Bár szerintem hótmindegy,

saxus · 2012. Nov. 12. (H), 03.59
Bár szerintem hótmindegy, hisz a gyakorlatban ezeket úgyis az IDE generálja :)


Pont ez a bajom vele, rengeteg generált kód. C# esetén is a CSC odagenerál neked egy valag kódot (valójában nagyon hasonlóra fordul le, mint Java-ban), viszont a lényeges különbség, hogy magában a kódban egy jóval tömörebb, áttekinthetőbb és szemantikailag kifejezőbb nyelvi elem szerepel. Csak egy példa a triviális esetekre:
public int Foo { get; set; }
vs.
private int foo;

public int getFoo() {
  return foo;
}

public void setFoo(int foo) {
  this.foo = foo;
}
(Igen, tudom, vannak rá workaroundok, pl. Project Lombok, de azért szerintem érezhető a különbség. Továbbá a kevésbé triviális eseteknél is kifejezőbb az összetartozás.)
128

A 2 megközelítés között

BlaZe · 2012. Nov. 12. (H), 11.01
A 2 megközelítés között elméleti és gyakorlati különbség is van. A C# gyakorlatilag kiajánl a nagyvilágnak egy belső propertyt (itt azért érdemes elgondolkodni az egységbezáráson szerintem), a Javas megoldás pedig metódusokat ajánl ki, amik történetesen egy az egyben piszkálnak valami belső adatot, de ehhez semmi köze a külvilágnak. Illetve javaban eldöntheted, hogy az osztályon belül magához a propertyhez akarsz hozzáférni, vagy belül is a getter/setteren keresztül akarod piszkálni valami okból kifolyólag. Ha ezt így akarod definiálni C#-ban is, az is kb ennyi sor.

De nekem igazából egyik megoldással sincs semmi bajom. Javanál az IDE, vagy valami legenerálja egyszer ezeket a metódusokat, aztán nem is járok arra többet, C#-ban meg ilyen és kész, az se fáj.
118

Kontraszt

BlaZe · 2012. Nov. 8. (Cs), 09.27
Egy kicsit praktikusabb megközelítésű post a témában itt