BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

3442 | #1c40 | ^ | Idézet | Tue, 01 May 2012 01:53:57 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Nem a magasszintű programozás lényegét nem értem, hanem az OOP szentesítését.

De, láthatóan nem érted. Az OOP alapkoncepciója az volt, hogy te a világot modellezed le és nem függvényeket meg változókat tutujgatsz. Hogy neked egy Ajtó osztályú objektumod van, ami INyitható, és ebből kifolyólag van kinyit meg bezár metódusa (megjegyzem, a tisztán OOP nyelvekben, pl. SmallTalk eleve nem metódushívásokról, hanem üzenetváltásról beszélnek; ez a metódushívás ez a C++/Java/C# vonal - és leágazásainak - sajátossága).

De ugyanezt az utat figyeltem meg pl. a játékok szerkesztőfelületeiben is. Pl. a Half-Life pályaszerkesztőjében max odáig mentek el. hogy van mondjuk egy tujának látszó feltextúrázott poligonhalom a prefabricated listában, oszt' csókolom. Ma meg ott tartunk, hogy leraksz egy fa objektumot, akkor az faként fog viselkedni. Ha egy olajoshordót, akkor meg olajoshordóként fog viselkedni. Stb.

De ha nem tetszik, hát istenem, kódolj ASM-ben vagy baszki, kódolj haskellben, aztán írj meg mindent matekul. Az OOP egy jó eszköz arra, hogy sok feladatot absztraktul meg tudj oldani és a világot egyszerűen lemodellezni. Attól, hogy te ezt a tételt elvből elutasítod, hogy szerinted ez lehetetlen azzal sajnos nem tudok mit kezdeni.

És breaking news: nincs az OOP szentesítve. Nem véletlen, hogy az utóbbi 10 év a programozási nyelvek fejlődésénél jellemzően az, hogy a funkcprogban jellemző elemeket emelik át a meglévő imperatív elemek mellé (legyen az OOP sima imperatív nyelv), mint pl. closure vagy .NET-ben a LinQ. Pont azért, mert az OOP sem csodaszer és nem ad mindenre megoldást. SQL-t is ezért használunk, mert jó nyelv arra, hogy relációs algebra segítségével megfogalmazzunk kérdéseket. Absztrakt módon. Persze, mondanom sem kell, sokkal optimálisabb lenne az adott feladathoz C-ben megírva, csak nincs az az isten, aki megfizeti azt a pöcsölést.

Hozzáteszem, van még egy másik irány is, ami főleg az utóbbi években a többmagos és kísérleti sokmagos CPU-kkal jelent meg, az pedig a párhuzamos programozás és kérdései. Nem véletlen, hogy egyre többször kerül elő az erlang modellje valamint, hogy a C#5-ben is az async dolgokat erősítik.

De ezeket már mind leírtam, csak te trollkodsz itt kiragadott félmondatok alapján. :)

TCH írta/wrote:
Ez a mentalitás vezetett a winfosvisztáig, amikor a kernelt is fosnetben akarták megírni...

*ásít*. Te is tudod jól, hogy ott az Intel is kellően beszopatta az MS-t. Egyébként nem a kernelt akarták újraírni .NET-ben, (az a singularity, de az csak egy kutatási projekt), hanem a felhasználói programokat akarták abban írni. Mivelhogy valakinek volt esze az MS-nél és rájöttek, hogy a C eredetileg rendszerprogramozásra szánt nyelv, C++-ból meg sokminden hiányzik (nézted már miket raktak a C++11-be? :) closures, GC, stl::threading, async, épp csak még mindig az a gond a C++-al, hogy nem képes tisztulni és ragaszkodik a C-s gyökerekhez) és terveztek egy nyelvet, ami magas szintű alkalmazásfejlesztéshez jó.

Másrészt igen, igazad van, menjünk vissza a középkorba, ne kutassunk soha semmit, hogy mi mire jó. Nem is értem, miért kellett pl. feltalálni egy csomó dolgot, ami teszi magától a dolgát és nem kell hozzá emberi erő. Roppant felháborító, hogy egy mosógép működésébe nincs beleszólásom, csak kiválasztom a programot, berakom a ruhát és tisztára mossa nekem :(