A už z toho konečně udělají moderní objektovou knihovnu?
To byla řečnická otázka, mě je jasné že ne - ale pak ať se nediví, že je Directy rozválcují...
 
Já osobně pořád ještě ze setrvačnosti používám OpenGL, ale důvodů pro tuto knihovnu je stále méně a méně...

Nerobim sice podobnu pracu, ale opytal som sa ludi, co sa tymto zivia, ci je velky casovy rozdiel vytvorit podobne veci v DX a OpenGL a tvrdia ze nie. Tak neviem v com mas problem ty. Dalsia vec je, ze ked tam spominas Direct-y, zrejme robis projekty na WIN platforme, kde ako vieme Microsoft "SILNE PODPORUJE OpenGL" na ukor svojich DX.

Kyke: S OpenGL na windows problém není - stejně to implementují výrobci grafických karet a ne Microsoft...
pokud jde o rychlost vývoje, tak nemůžu souhlasit - udělat v DirectX totéž co v OpenGL je mnohem rychlejší, tedy pokud to děláš pořádně... pokud jde jen o to "nějak" to rychle napsat, tak už zas tak velký rozdíl není, ale ten OpenGL program je pak hodně těžko spravovatelný
Ti se kterými si se bavil si už možná za posledních pár let vyrobili vlastní knihovny, které jak OGL tak i Directy obalují, takže už to pro ně vyjde nastejno... ale to o jednoduchosti vývoje v OpenGL vs. DirectX nic nevypovídá
 
PS: nechci tady vyvolávat žádný flame, ale funkcionální knihovna typu OpenGL do 21 století prostě nepatří...

Azazel: "S OpenGL na windows problém není - stejně to implementují výrobci grafických karet a ne Microsoft.."
Hmm, takze je to problem:P

Program je spravovatelny tak tezko, jak spatne to napisete, svalovat neco na knihovnu...:)
A z jakeho duvodu funkcionálni knihovna typu OpenGL nepatri do 21stoleti? To by me opravdu zajimalo:P

Kruci: Na linuxu, na macu a prostě všude dodávají ovaldače grafických karet výrobci hardwaru a standardní ovladače v OS nemají zdaleka takový výkon... jestli to považuješ za problém, pak tento problém existoval vždy a všude a nejspíš dále existovat bude...
 
Klíčové slovo je to "funkcionální knihovna" - tj. ani modulární, ani objektová, ale funkcionální a netypová, nevím jestli se zabýváš programováním, ale věř mi, že tohle opravdu do současného programování dávno nepatří...  a vede to na to, že aby se dala taková knihovna rozumně používat, tak si nad ní musí každý udělat nadstavbu - což je spousta zbytečné práce a kvalita bude rozhodně horší než kdyby se to udělalo jednou a pořádně

Je to tak, Azazel má pravdu. Knihovny OpenGL mají zastaralou koncepci. Kdyby na ním byla alespoň nějaká standardní objektová vrstva...

Hmm, ale ja myslel ze se bavime o OpenGL a windows,.. proc tedy rovnou nedelaji DirectX3D vyrobci hardwaru. Vsichni vime, ze co udela vyrobce softwaru, ktery nejlepe vi, jak jeho software funguje, tak by to melo byt efektivnejsi... Nic proti mrkvosorfu:)

"funkcionální knihovna" aano, dnesni svet ma rad objektovy pristup. Zalezi jakym programovanim se zabyvas, protoze "funkcionálních knihovnen" je spousta. Nekde se hodi to jinde zas ono.
A mas pravdu, lze udelat nadstavbu, coz vzhledem k tomu, ze uz se OpenGL pouziva dlouho by mohla nejaka existovat?
Funkcionalni na objektove lze prevest relativne snadno, obracene relativne nemozne. Funkcionalni je universalni, lze upravit dle potreby:)
A nic nikomu nebrani si to udelat poradne, je to spise prepis, pokud delas vetsi projekt tak tohle zabere zanedbatelnou cast(a vetsi firmy to uz maji urcite hotove).
A oni vedi proc maji to delaji funkcionalni:)

PS: napsat ze funkcianalni knihovna nepatri do 21 stoleti a napsat k tomu NO Flame mi prislo vtipne. Ano, dnesni svet smeruje k objektum, ale urcovat co patri a nepatri do 21 stoleti:)

fotoba:nevím jestli mají nebo nemají teorii, ale praxe už jasně prokázala, že objektové programování je výrazně lepší
FFFFFF:To je přesně ono, mě by vůbec nevadilo dvouúrovňové OpenGL- jedna úroveň funkcionální, tj. to co existuje teď- a nad ní další (standardizovaná) objektová knihovna
PS: funkcionální knihovna opravdu do 21 století nepatří ;) a to mi nikdo nevymluví
 

omlouvám se za to podivný pozadí, ani nevim jak jsem to udělal :)

Treba to je svatozar, jako ze se z tebe stal prorok:)
HMMMM, mozna to znamena ze mas pravdu:)

Nestandartizovany chaos do 21 stoleti taky nepatri, a mame ho na kazdem rohu...
Pro me je funkcionalni jako zaklad, ze si s tim mohu delat co chci. Funkcionalni Ruleeez a to mi nikdo nevymluvi(aspon nasledujich 5 minut):)

Zase fanatici objektového programování.

Nikoli, pokud chcete udělat standardní a široce použitelnou knihovnu, jako je třeba OpenGL, tak jí MUSÍTE udělat BEZ OBJEKTU. Proč? Protože jednak spousta jazyků objekty nemá (například C), a jednak proto, že každý objektový programovací jazyk má naprosto jinou vzájemně nekompatibilní koncepci objektů. Museli byste to přišít na jeden konkrétní objektový jazyk - a to jak jistě uznáte by šířku použitelnosti vaší knihovny velmi snížilo.

Takže všechny knihovny na světě, které mají mít univerzální použití se vždy a absolutně vždy dělaly neobjektově - je to jediná možnost jak zajistit univerzální použití knihovny.

A vždy se dá na neobjektové rozhraní napasovat objektová nadstavba - třeba pro každý programovací jazyk trochu jiná, ale není to možné naopak - na objektové rozhraní napasovat neobjektovou nadstavbu.

Tedy neobjektová knihovna je vždy univerzálnější, použitelnější, a tedy lepší, než objektová - pokud vám jde o záruku použitelnosti na každé platformě a v každém programovacím jazyce.

Nechte si proto prosím ty řeči o nemodernosti, protože není objektová, ty lidi, co OpenGL navrhují rozumějí sw inženýrství trochu lépe, než vy.

Azazel: Objektove programovani se nehodi uplne na vsechno, ale mas pravdu, ze pro nektere mene znale problematiky, je to ultimativni ZAKLINADLO na vsechno.

OpenGL jednoznacne patri do 21.stoleti a klidne i jen jako "funkcionální knihovna" a vite proc??? Jelikoz je (narozdil od Direct3D a jemu podobnych) plne MULTIPLATFORMNI !!!

Reci typu "programovani bez objektu, rozhrani bez objektu nepatri do 21.stoleti" jsou opravdu zabavne a odhaduji, ze pochazeji od hosiku, kteri nemaji zadne velke zkusenosti a moc toho nevideli.
Ja bych na zaklade sve zkusenosti mohl prohlasit klidne cosi o tom, ze nadmerne vyuzivani objektu pri programovani neprinasi absolutne nic dobreho - obzvlast tam, kdyz se cpou na mista, kde nemaji co delat.

Viz B2, objektovy prgani = masteni SW bez rozmyslu, coz usetri cas, ale velmi casto za cenu 1/2 vykonu aplikace. Objekty muzou zjednodusit navrh, ale pro aplikace vyzadujici vykon, coz OGL je, jsou naprosto nevhodny.

B2: Naprosto s Vámi souhlasím, a mám stejný názor, že Ti kdo tu volají o nemodernosti OpenGL, a že nepatří do 21. století, protože není objektové, ví o programování nejspíš naprosté minimum. Velmi pochybuji, že bych tento názor kdy slyšel od dobrého, nebo zkušeného programátora.

::: Jednoducho nemame teoriu, ktora by dokazovala, ze proceduralne programovanie a metody jeho navrhu su lepsie/horsie ako napr. obejktovy model.. :::

Teorie v programování nemá žádný podstatný význam, a praxe jasně a nepopiratelně ukazuje, že procedurální programování vede k horším výsledkům než objektový model.

Bohužel obojí se od sebe zase až tak moc neliší a zcela souhlasím s tím, že jde o velmi primitivní, nedokonalé a jen těžko použitelné koncepty.

jjjjj: To naprosto není pravda, objektové programování a objekty nejsou o snížení výkonu. Objekty nesnižují výkon - a objekty nejsou o výkonové ztrátě. Objektový program může mít bez problémů stejnou rychlost a výkon jako neobjektový.

Uznávám ale to, že mastění objektů bez rozmyslu, což se dneska mohutně podporuje, je tragédie.

To:x86
Ani NAHODOU! Objektove programovanie je lahsie z hladiska pouzitelnosti, ale z hladiska navrhu vyzaduje obrovske analyticke schopnosti od programatora: rozdelit menitelne od nemenitelneho, navrh ortogonalnych interfacov z ktorych prameni vysoko modularny design... Toto nezvlada 90% programatorov v OOP a vysledok je aky??? ...staci sa pozriet do akehokolvek projektu... zmaska TOTALNYCH hackov ktore dokazuju ze dany jedinec navrh OOP absolutne nezvlada... howg!

x86: Já tedy programuju už osmnáct let, vyzkoušel jsem už leccos, a praxe mám za sebou až hrůza. Ale říci, že procedurální programování vede k horším výsledkům, než objektové - bych se neodvážil. A ani jsem to nikdy v praxi nepozoroval.

Naopak - kvalita výsledků je velmi závislá na zkušenostech, schopnostech a analytickém citu toho, kdo navrhuje architekturu programu. V malých programech je to sám programátor, ve větších většinou analytik. A je úplně jedno, jakým paradigmatem je to naprogramováno - jestli procedurálně, objektově, funkcionálně, nebo jinak.

Nesmíte si o objektovém programování myslet to co není - je to sice in, je kolem toho velká reklama, ale ve skutečnosti je to prachobyčejně jen jedna z dalších metod programování - nic víc a nic míň. Není třeba z toho dělat co není.

Naopak, při přebírání kódů od dnešních programátorských rychlokvašek bych kolikrát dal nevím co, aby to napsali bez objektů - ono totiž při špatném návrhu rozvržení objektů už nejde nic zachránit - prakticky se to musí přepsat. Zatímco při špatném návrhu procedurálním je to na 100% ještě dobře použitelné. Objektový návrh se dá tak dokonale poslat do WC a tak dobře zamotat, že se s tím už skoro nikdo neporadí.

Dnes bohužel programuje každý kdo předtím napsal úspěšně program "Hello world" a jde okamžitě do praxe. A dobrý objektový návrh chce větší zkušenosti, ale to tihle lidé nezvládají, ale ví, že musí dělat a objekty. Naštěstí se objevily "návrhové vzory", které mohou pomoci lidem bez citu pro sw vývoj, takže alespoň díky bohu za to, ale vše se tím nezachrání.

Poznámka: Autor tohoto příspěvku používá objekty dnes a denně a na 99% jinak, než objektově neprogramuje. Není ovšem fanatik a je si vědom plusů a mínusů objektového programování.

Praxi máme asi tak stejnou, já jen o malinko delší. Výhody objektového programování vidím v tom, že především nemá proti procedurálnímu žádné nevýhody (uvažuji o objektech tak, jak je vidí C++, už třeba proto, že v C++ jsou možné oba modely) a potom v tom, že donutí i ty největší prasiče alespoň trochu se zamyslet nad tím, co dělají. Vlastně... ty největší prasiče to stejně nedonutí. Takže řekněme, že objektový koncept poněkud snižuje stupeň prasení.

Jakmile byste vytvářel jen trochu větší systém procedurálním způsobem, stejně nakonec dospějete k něčemu, co bude objektový model připomínat nebo jím přímo bude. Nebo dostanete neudržovatelný chumáč kódu (což se patrně stane stejně, ale o něco později).

bender: To záleží na metodice. Pokud používáte trvalý refactoring a vůbec principy XP, nemusíte mít na začátku žádný úžasný design, dokonce samo zadání může být vcelku vágní (a kdy není?).

Ono je to vcelku fuk. Nakonec stejně bojujete s hovadným zcela nepřehledným zmaštěným rozbředlým všechno-ovlivňuje-vše kódem, který si žije svým vlastním životem. OOP, XP a různé metodiky ten okamžik jen oddalují, doufejme, že na dobu, kdy už vy budete v jiné firmě či na jiném projektu. Tzv. moderní programování není místnost několika s tmavými kouty, to je prostě tma plná nestvůr, v níž snad kdesi daleko bliká nepatrné světélko - nebo alespoň občas věříte, že snad bliká.

No, tak to, jsem ještě, jednou, kdysi, zkoušel, programovat, v objektovém programování, v Baltíku, nebo v BALTazaru, teď, už nevím přesně, a ty bylo, objektové programování, ale to, jsem myslím, moc nepochopil, a to jsme, kdysi, nejradši, programovali, BASICu, na počítači Commodore 64, s 1 MHz, procesorem a 64 KiloBajty Operační paměti, a pak, jsem taky, rád, jestli, to je teda, Procedurální programování, tak to jsem docela, rád programoval, v programu QBASIC, v Operačním systému MS-DOS 6.22, asi nějaká verze EN, ale, program Baltazar, nebo jestli, to byl, už Baltík, jestli, to je, tak to, úžasné, objektové programování, tak to, jsem nikdy, moc nepochopil, a pak, už mě, to přestalo, bavit, prostě no!

bender
Ano je vela ludi co navrh v OOP moc nezvlada, ale ber to tak, ze nie kazdy musi byt hned programator rozsiahlich projektov, mas vela "lepicov" roznych malich plikacii vyskladanych z komponent ktore mu dala nejaka kniznica, alebo SW, ktory je v podstate jednorazovy. Ale aj su objekty dobre navrhnute tak vedia usetrit vela prace a davaju ohromne moznosti, my vo firme pouzivame objekty aj na realtime systemy a na pomalost sa nemozem stazovat. Framework sa zacal buduvat pred siedmimi rokmi a za ten cas sa nemenil ziadny interface(mam na mysli ziadna nekompatibilne zmena, len pridavanie funkcionality o ktorej sa predtym nevedelo). OOP sa tam vyuziva hodne koli niektorym svojim vlastnostiam a bez objektov by ten kod nebol ani zdaleka tak prehladny.

OOP je: Prehlednejsi, pro vetsi projekty rychlejsi na vyvoj, udrzovatelnejsi, lepe se v nem hledaji a opravuji chyby a predevsim umoznuje tymovou praci rozdelenim projektu na uzavrene podprojekty. Na druhou stranu tezko budete nejaky paralelni vypocet primo v procesoru s pomoci SSE nebo podobne obalovat objektem.
 
To ze je casto efektivnejsi nutne neznamena ze je lepsi. To je totez jak kdybyste rekli ze cervene vino je lepsi nez bile, protoze ... proc vlastne?
 
Jestli je neco lepsi, jsou to OO jazyky, protoze dovoluji psat oba typy kodu (s jistou urovni abstrakce), ovsem jazyk a typ programovani je neco naprosto jineho.

x86: Ne ne ne, objektový model prasení nezabrání - mimochodem znáte tu starou větu praktiků "Jsou lidé, kteří programují ve Fortranu v každém programovacím jazyce?" - a o tom to je.

Samozřejmě, že každý větší systém má objektové rysy - chca nechca. Jinak to ani dost dobře nejde. Nicméně objektové rysy vůbec neznamená použití objektů a tříd definovaných jazykem.

Chtěl jsem prostě nepsat, že dnešní preferování objektového programování nemusí vykazovat u začátečníků moc dobrý výsledek. Je naprosto fajn, když začátečník pracuje nad dobrou objektovou knihovnou, ale ať proboha nenavrhuje objektovou architekturu programu! Prostě to většinou nezvládne.

Objektový koncept nesnižuje stupeň prasení - pokud jej vezme do ruky začátečník. Ano, pokud vezme objektový koncept do ruky zkušený člověk - výhody jsou super. Ale pokud začátečník navrhuje objektový koncept - divil byste se co všechno jde vymyslet a do jakých věcí se lze dostat.

Jinak k metodě XP - jsem přesvědčen, že metoda XP není vhodná pro každý sw projekt. Že právě tam, kde je potřeba především promyšlený design a na tom to stojí a padá (typicky u složitějších sofistikovaných knihoven, kde nejvíc záleží na dobře trefeném interface, nebo u aplikací, kde vymačkáváte maximum výkonu z počítače a a potřebujete už od začátku promyšlený návrh) přináší XP metoda výrazné zdražení celého sw vývoje a značné prodloužení doby vývoje.

Jinak řečeno, XP metoda je vhodná právě tam, kde návrh sw není až tak obtížný a lze jej snadno iterativní a refaktorovacími metodama iterovat - což ale zdaleka nelze vždy bez ztráty kvality.

Jinak s tím hovadem, se kterým postupně bojujete i s místy plnými stínů v každé aplikaci jenom souhlasím. Veškeré metody sw inženýrství není nic jiného, než situace o něco zlepšit, ale ideálního stavu se těžko dosahuje - už díky nepředvídatelnosti požadavků na sw v další verzi.

fotoba: Proč myslíte, že v kernel space nemá co dělat objektový kód? Proč se tam tedy čím dál více objevuje - a čím novější a modernější systém, tím více objektového kódu je ho v kernel space? Mnoho ovladačů je psáno v C++, mnoho kernelů také. Proč? Protože objektové programování je naprosto, ale úplně stejně rychlé a může generovat naprosto stejně rychlý a výkonný kód jako neobjektové programování.

OOP je metodika, nic víc a nic míň. Když se na to podíváte kriticky, stejně zjistíte, že naprosto každý kernel každého operačního systému je nakonec programován objektovou metodikou. Sice je třeba psán v neobjektovém C, případně asm, nebo třeba jiném jazyce, ale principy architekturu kernelu jsou většinou pojaty zcela přesně v duchu OOP metodiky a také objektově ve zdrojovém kódu opsány.

Rozumně pojatými objekty lze naprogramovat jakýkoli kernel OS včetně realtimového.

fotoba
Mozno nevyuzivame moznosti tych systemov na plno, ale pre nase potreby to staci. Pouzivame VxWorks a programy sa robia v RT verzii Rational Rose, ake su moznosti tejto kombinacie netusim, ja robim s RT len kratko, ale viem ze pre nase potreby staci dostat sa pod 1ms, mozno desiatky, alebo stovky microsekund a to sa z objektamy da hravo dosiahnut. A urcite viem, ze robit spravu a udrzbu kodu takehoto rozsahu bez objektov by bolo vyrazne zlozitejsie.

fotoba
To je sice mozne, ale v nasom pripade je sme limitovany schopnostami HW a uz nemame vela moznosti na zrychlovanie to by sa muselo prejst na ine materialy. Na hranice SW sme zatial nenarazili a nemyslim, ze niekedy bude SW limitujucim faktorom. Ked sa to stane bude nutne hladat ine riesenia, ale tu bolo vela casu venovane navrhu kvalitneho frameworku, ktory vyrazne zrychluje dalsi vyvoj a neverim, ze by molo mozne bez objektov dosiahnut taku vysoku efektivitu prace programatorov(tento aspekt priamo suvysi s tym ze kod je prehladny a lahko udrzovatelny)

Pěkná diskuse se tu rozběhla :) no nic, vrátím se trochu k tématu: prošel jsem si návrh OpenGL 3.0 a i přes mé původní výtky musím říct, že se pohybuje správným směrem. Tj. odstraňuje některé nejmarkantnější designové chyby. Takže aspoň něco...

Miloslav Ponkrác: V kernel space predevsim nema co delat pouziti objektu jazyka, a to proto ze kernel vyzaduje specialni metodu linkovani a objekty by to znemoznili. Jinak ano, na rade mist je v kernelu napr. linuxu pouzit objektovy navrh a kdyby tam nebyl, vyrazne by to zkomplikovalo vyvoj. Na rade jinych mist neni a cpat ho tam by byla katastrofa.

To, co hlavne snizuje vykon aplikace, je nadrazeni objektovosti efektivite. Jednoduchy priklad: potrebuji inkrementovat promennou. Objektovost rika, ze bych mel zavolat metodu objektu. Efektivita rika, ze pokud si nejsem sakra jisty, ze to kompilator vyoptimalizuje, tak musim pristoupit primo k promenne (nebo pouzit makro). Idealni samozrejme je kdyz si mohu byt jisty ...

to hkmaly: ad první odstavec - raději nekomentuji, linkování objektů je věc, která nikomu v kernel space ještě nezabránila použít objekty. a proto také existují kernely operačních systémů, které bez problémů objekty v kernel space používají

ad druhý odstavec: to si nevybereš - mnohé prasárny a programy zase skončily proto, že efektivitu nadřadily architektuře - tedy třeba objektovosti. například celý problém roku 2000 - Y2K - vznikl jen na základě nadřazení efektivity čemukoli jinému a toto vyzdvihování efektivity stálo pár miliard dolarů.

ale jinak s druhým odstavcem pravdu nemáš - staří praktici vědí, že optimalizovat se má, jen když je důvod - a ten je při dobrém návrhu a architektuře programu (nejlépe objektové) jen málokdy a jen u malého zlomečku kódu. daleko více, než uvažováním nad blbostmi s efektivitou implementace (tedy objektů) se 1000x víc vyplatí a projeví na efektivitě výběr dobrých algoritmů a dobře navržená architektura (a jak znovu píšu nejlépe objektová) a taky dobře navržené datové struktury programu.

Jinak dobrý jazyk a dobrý kompilátor/interpretr je od toho, aby optimalizoval, takže klidně se může stát, že přímá inkrementace proměnné a zavolání metody, která tu inkrementaci provede vyjde z kompilátoru naprosto totožně - stejně rychle a efektivně. A o tom, jestli to kompilátor vyoptimalizuje se není potřeba příliš bát - vyoptimalizuje.