Vlákno názorů k článku Základy programování ve Squeaku od ondra.novacisko.cz - Oblíbeným omylem všech OOP nováčků je lpění na...

Ten druhy zapis je neco z C# nebo Javy? To by znamenalo dynamicke vytvareni interface v runtime ne?

Z C++. Zprava je ve skutecnosti deklarovana jako:

class zprava: IInterface {
public:
virtual void send(IObject *) = 0;
};
 
class IObject {
public:
 
virtual IInterface *getInterfacePtr(const std::typeinfo &tinfo) {return 0;}
 
template<class Ifc>
Ifc &getInterface() {
  IInterface *ptr = getInterfacePtr(typeid(Ifc));
  if (ptr == 0) throw ... nejaka vyjimka ...
  return static_cast
	(ptr);
}
 
virtual IObject() {}
};

Hlavní myšlenka je v tom, že všechny objekty podědí IObject a ta obsahuje funkci na hledani rozhrani. Pomoci getInterface se zeptam objektu, zda umi nejake rozhrani a pokud ano, zavolam na rozhrani funkci. Pokud ne, hodi to vyjimku. Virtualni funkce getInterface pak musi byt implementovana ve vsechn objektech, da se tam pouzit i dynamic_cast (v příkladu to nemám, bylo by to složitější) a objekt pak pouze implementuje tu funkci jen tam, kde docházi k předávání kompetencí.
Objekt pak může vypadat takto (pro řešení s dynamic_castem)

class MujObjekt: public IObject,
       public zprava1,
       public zprava2,
       public zprava3,....
{....};

nebo

class MujObjekt {
public:
  IInterface *getInterfacePtr(const std::typeinfo &type) {
   if (type == typeid(zprava1) return &objektCoUmiZprava1;
   ...
   ...
   return 0;
  }
};

Rozumim tomu dobre, ze pres tuto prisernost, co jste popsal, jste se dostal k jednoduchemu zapisu ze smalltalku „objekt zprava“?

Tohle vlákno vzniklo proto, že jsem jen upozorňoval, že velmi častou chybou začátečníků je, že něco považují za pravé OOP a něco za nepravé OOP. Většinou v roli prvního příkladu je smalltalk a v druhem buď C++ nebo JAVA. Nejčastějším argumentem je posílání zpráv. A jedním dechem uvádím, že je to pitomost, protože způsob posílání zpráv nedělá z jazyka pravý OOP jazyk, protože pravé OOP vlastně neexistuje.
 
Můžete to chápat i jako pokus o flame :-)
 
V zásadě ale trpíme všichni rozsahem definic. Co už je OOP jazy a co nikoliv? Co už je multithreadový jazyk a co už nikoliv. Předně si myslím, že JAVA není multithreadový jazyk ani proto, že podporuje synchronized. Multithreadový jazyk si představuji něco úplně jiného. A stejně tak OOP jazyk. Javu i C++ považuji za OOP jazyky už proto, že techniky a konstrukce, které se tam používají uznadňují implementovat OOP filozofii. Stejně tak smalltalk to usnadňuje, je objektový jazyk. Ale podobně se lze dívat i na python :-) Programátora nutí myslet objektově. A to je celé. Přesto stejně ve všech těchto jazycích lze programovat procedurálně (po staru). O tom, zda jsou objekty implementované jako místa v paměti, záznamy v tabulkách, a zda se zprávy posílají, volají se metody a jestli objekty mají nebo nemají přístupné atributy (a zda vůbec mají atributy).

Vždycky na jedné straně bude stát náročnost implementace a na druhé straně úplnost (nebo pohodlí) OOP modelu. A tyhle dvě věci jdou prostě proti sobě.

PS: V tomto ohledu mě dost mrzí vývoj některých běžných jazyků. Například v C++0× jsou některé věci dobré, ale chybí dodělání věcí, které souvisí s OOP, například třídní proměnné, základní typy jako objekty, atd. Java vyloženě trpí neexistencí destruktorů, jako přesné vymezení existence objektu (objekt existuje od teď … až do někdy).
PSS: Překvapuje mě, že úpravou jednoho jazyka vzniká jiný jazyk, podle Vašich slov. Jenže opět trpíme rozsahem definic. Co je jazyk a co už není? Patří do jazyku jeho standardní knihovna? Tohle je třeba spor… má být v C++ podpora multithreadingu? Nebo si vystačíme s knihovní funkcí? Já zvládnu z C++ udělat multithreadový jazyk pomocí své knihovny.
 
Když protlačím svou (výše uvedenou) úpravu jazyka do standardních knihoven, bude z toho jazyk s úlnějším OOP modelem? Jiný příklad. Má být v C++ zaveden GC? Já tvrdím že ne. Já zvládnu napsat GC v současném C++ a nepotřebuju žádnou buildin podporu. A vo tom to je. Potřebujeme jazyk na vyšší úrovni abstrakce, aby jsme ocenili úplný OOP model? Já ho nepotřebuju, ale chápu, že někdo bez toho nemůže v noci spát. Kolik ho to bude stát výkonu. Kolik zbytečného kódu se kvůli tomu napíše a v runtime vykoná?

Jasně, říká se tomu matfyzácka slepota. Konečně, celý svět lze zabalit do jedné definice
 
42

No a? Ale o to přece vůbec nejde. Napadlo mne, že nejste matfyzák, protože byste neměl takový zmatek se slovem defince.
Obecně se neříká objektové jazyky, ale objektově ORIENTOVANÉ jazyky. Orientují se na objektové programování. Je mi srdečně jedno, jak moc úplný je OOP model který jazyk používý. Většina současných OOPL (Object Oriented Programming Languages) implementují naprostou většinu z filozofie OOP. Je na Vás, abyste si vybral, co Vám vyhovuje co do výkonu, či rychlosti vývoje.
Jen jsem chtěl podotknout, že způsob komunikace mezi objekty nic neříká o úplnosti modelu OOP. V naprostý většina totiž volání metod vystačuje, a jen puntíčkář bude zkoumat technické pozadí implementace dívat se, zda zápis 100 factorial v nějakém bufferu vytvoří zprávu, kterou pak předá do jiného buffer a následně předá řízení oslovenému objektu, který jí z bufferu vyzvedne a provede … a bude tomu říkat zasílání zpráv.

Opakujete se. Protože konstruktor OOP nezná (konstruktor chápán v kontextu jazyka C++, nebo aspoň tak chápu Váš termín), nemohu toto považovat za důkaz, že Objective C: „implementuje přímo, čistě a jednoduše naprostou většinu z filozofie OOP“

Ale blbost. To je jako byste řekl, že důkazem, že dřevo hoří je pokus, při kterém se prokázalo, že voda nejde zapálit. Si říkejte co chcete, ale jste vedle.
 
Zaprvé, konstruktor je funkce třídy, jehož jediným úkolem je inicializovat instanci třídy. Lepší by bylo, kdyby se to implementovalo tovární funkcí „createInstance“, na objektu třídy. Jenže z implementačních důvodů tyto jazyky nemají třídy chápány jako objekty, ale spíš jako šablony objektů. Proto konstruktor. Technické řešení vyplývající ze způsobu implementace OOP.
 
Za druhé, vyplývajícího z funkce konstruktoru je, že konstruktor nemůže a ani není určen k inicializaci jiného objektu, než objektu, který vzniká instanciací třídy. A navíc konstruktor je chápan jako členská funkce instance, ne třídy. Má zvláštní postavení hlavně proto, že je spouštěn na nezkonstruovaný objekt, což může v některých jazycích, ktere objekty mapují přímo do paměti problém, proto se používá konstruktor, aby po vytvoření objektu byl objekt zkonstruován. Prostě když už nic jiného, tak účelem konstruktoru je zvalidovat přidělený paměťový prostor, asi jako bagr, který přijede na rozorané pole, aby tam udělal základy domu.
To vy chcete je tovární funkci, která zkonstruuje jiný objekt. Ale ten objekt se zkonstruuje voláním jeho konstruktoru. Cítíte ten rozdíl? V C++ konkrétně se vytvoření instance skládá ze dvou kroků, neprve přidělení paměti a následně zavoláním konstruktoru na tu paměť. Vůbec netuším, co by mělo znamena, že konstruktor má vytvořit jiný objekt. Asi jako když matka porodí dítě a to se po porodu rozhodne stát psem.
Ukažte mi použití vašeho konstruktoru, abyste mi vyvrátil pocit, že tomu rozumíte jak koza petrželi.

Přesně tohle jsem chtěl po vás. Abyste byl konkrétnější :-)

Cyklus nekonečný = nekonečný cyklus.
Vážený pane, když nevíte, co znamená svoboda, tak to fakt nemá cenu. Svoboda znamená, že k výchozího stavu se do libovolného konečného stavu dostanete pomocí několika kroku a libovolnou cestou. Nesvoboda znamená, že do některých konečných stavů se buď vůbec nedostanete, nebo vás to bude stát obrovskové úsilí a budete mít velmi omezený výběr cest.
Považuji jazyky automaticky dělající určité věci za programátora za nesvobodné, protože jejich automatické nástroje nelze deaktivovat. Pokud se budu 10× objektu číslo ptát na faktoriál, tak 10× se bude někde v pozadí vyhodnocovat odesílání zprávy a hledat se program, který bude počítat zadanou úlohu, zatímco rychlejší cesta by byloa vyhodnotit to jednou a pak to vyřešit. Jistěže existují optimalizace, cache a buh ví co, ale to je asi jako když evropská unie látá problémy regulací dalšími regulacemi.
Zkuste ve smalltalku napsat program pro kompresi LZW. Určitě to zvládnete, ale porovnejte výslednou výkonnost s nativním řešení(třeba v C). A to je přesně ta nesvobodam protože vy pak už nemáte jinou možnost, než to napsat v nativu a připojit to jako externí modul, jelikož Vám ten jazyk nedává jinou možnost.
Tím neříkám, že svoboda je lepší. I svoboda má svou cenu. Někdo prostě radši má nástroje k dispozici a vybere si cestu, která mu nejlíp vyhovuje. Jiný si řekne, že to nechá na někom jiném a k cíli se nechá vést za ručičku.
Nezapomeňte že cílem všech jazyků je říct lidsky pochopitelnou formou počítači, co má udělat. U některých jazyků to ale znamená, že jednoduché sdělení bude znamenat obrovskou záťež pro celý stroj. V jiných jazycích budete toho muset hodně namluvit, aby počítač pochopil, co chcete udělat. Já osobně považuji to druhé za svobodnější prostředí, než to první.

<ironie>Takze cistej strojak nebo assembler je taky jeste dost svobodny (i kdyz v nem se neda udelat napriklad „zmrseny“ ELF file)?</ironie>

Od kdy je nativním jazykem počítačů Cčko?

Já bych tedy byl dost opatrný v používání slova svoboda v souvislosti s programovacími jazyky. Co se týká řešení, tak už tady bylo řečeno, že všechny jazyky, o který se tu nejmenovitě bavíme, jsou turingovsky úplné. Tudíž i množstvím cest se neliší.

Liší se tak akorát efektivitou běhu, což je implementační problém, nikoli problém jazyka a případně efektivitou programování či čitelností kódu.

No Cčko je nativní vícéméně od té doby, co C bylo vymyšleno tak, aby převod do strojáku byl víceméně 1:1 Rozhodně pro překlad a běh nepotřebujete virtuální stroj, ani JIT compiler. Tím je myšleno nativní. A já tim ani nemyslel jazyk, ale výsledný kód, který je ve strojáku „as-is“. Proto se v něm do dnes vyvýjejí operační systémy.

Co mi ovsem na nizkourovnosti Cecka zacina dost citelně chybět, je podpora VLIW obecně, konkrétně MMX, SSE a SSE2. Už to, že v céčku nejde pracovat s flagy (asi kvůli přenositelnosti) některé algoritmy neumožňuje čistě napsat (vícebajtová aritmetika například, tj. sekvence ADD, ADC, ADC, ADC, ADC…) ale nějaká možnost použít výše uvedenu instrukční sadu – to by jazyku jako C slušelo :-)

Až bude někdy sledovat optimalizovaný kód několika do sebe vnořených šablon, uvidíte tam věcí :-) Záleží na schopnostech překladače. Pokud implementujete vícebajtové sčítání s přenosem jedničky „rozumě“, může to překladač pochopit a přeložit jako ADD, ADC,ADC

Nějak mi uniká, co tím vlastně chcete říci. C není žádným suprémem v oblasti lidské pochopitelnosti, ani programátorské svobody, ani rychlosti kódu. Smalltalk je rozhodně lidsky pochopitelnější, jednodušší a čistší jazyk, než C. Pokud jde o programátorskou svobodu, tak tady asi konkurenci nemá Forth – můžete si v něm udělat cokoli, jakkoli, za ručičku Vás tu určitě žádný překladač nevede – ovšem se všemi důsledky, jež z toho plynou. A pokud jde o efektivitu kódu, tak – nepočítám-li Assembler – tady (pro někoho možná kupoodivu) vítězí Fortran. Vím, je nesmysl porovnávat v tomto ohledu jazyky, když je to záležitost překladačů, ale filosofie jazyka má na návrh jeho překladače a možnosti optimalisace poměrně velký vliv. No a že Smalltalk podporuje objektový přístup lépe, než C++, to je prostě fakt – C++ = „objektový assembler“. Já jsem žil ovšem vždycky v přesvědčení, že tak to taky bylo myšleno. Flame by IMHO mohl vzniknout na téma „je lépe objektový Smalltalk nebo Lisp (CLOS)“, kde oba jazyky nabízejí luxusní nástroje pro OOP, ale každý to realizuje úplně jinak. Smalltalk je 1. liga v OOP, CLOS je 1. liga v OOP, ale C++ – to určitě první objektová liga není.
Jinými slovy – že dáváte přednost C++ je sice hezké, ale je to věc, jež má tu zajímavou vlastnost, že z ní o Smalltalku a OOP vůbec nic neplyne. :-)

Chtěl jsem říct, že posílání zpráv nemusí nutně znamenat, že si objekty zasílají datagramy :-)

Myslím, že se tady míchá svoboda (volnost) jazyku s jeho účelem. Smalltalk vznikl jako vyšší jazyk pro řešení rozsáhlých abstraktních úloh, čehož je komprese LZW přesným opakem. Komprimovat nikdy nebylo smyslem Smalltalku. Naopak jde o typickou výpočetně a datově jednoduchou úlohu, pro kterou jsou přímo určeny jazyky assembler a C.
Užití nevhodných jazyků pro řešení specifických úloh není v praxi neobvyklou chybou.

Co kdo povazuje za svobodu a upresneni jejiho vykladu v dane situaci muze byt na miste. Dotazujici se muze ujistovat, zde svoboda neni vice zamenovana napriklad za zbozne prani. Zaroven se ujistete, zda Vase svoboda neni jen Vasim zboznym pranim.
Co se tyka implementace LZW, tak jste to trefil – ano, mame ruzne kese, zname a mame JIT pro runtime preklady a dalsi nastroje a metody, ktere dokazi zdanlive neefektivni jazyk ucinit efektivnim a mnohdy efektivnejsim nez v pripade, ze by to programator psal v cecku nebo strojaku. Pokud mam dnes dobry jazyk, tak zitra muzu mit i dobrou implementaci prekladu toho jazyka pro prislusny stroj. Nadcasovost jazyka nepovazujte za chybu, to by byla chyba.