Portál AbcLinuxu, 31. října 2025 06:10
Imho pro člověka zvyklýho na C++ by to mělo být celkem intuitivní až na pár detailů...
1.7.2011 00:32
tomboytom-deviant | skóre: 7
| blog: lojdovo
| .com
Obj-C ? Takze bude KERNEL-ULTRAS applikace pro iPhone? 
I když rozdíly tam jsou.
1.7.2011 01:29
pavlix | skóre: 54
| blog: pavlix
D je programovací jazyk, jehož záměrem bylo „C++ done right“To mi připomíná Subversion („CVS done right.“)...
.
1.7.2011 18:16
pavlix | skóre: 54
| blog: pavlix
#include <stdio.h>
#include <complex.h>
int main(void)
{
double complex a = 2+3*I;
double complex b = 1-2*I;
double complex c = a * b;
printf("%f %f\n", creal(c), cimag(c));
return 0;
}
1.7.2011 23:32
LangPa | skóre: 12
| blog: LangPavel
| Hradec Králové
1.7.2011 07:15
vain | skóre: 16
4.7.2011 08:35
vain | skóre: 16
4.7.2011 22:13
pavlix | skóre: 54
| blog: pavlix
To je sice hezké, ale pořád mi to přijde multiplatformní asi jako pouštět hru pro Windows ve Wine.Což vzhledem ke věcem jako je winelib, nebo i obyčejnému zapouzdření wine do skriptu, není vůbec špatné. Ovšem pokud ta hra bude psána jako multiplatformní (což nevylučuje, že jednou z cílových platforem jsou windows).
1.7.2011 23:32
pavlix | skóre: 54
| blog: pavlix
//) do konce řádku (a to D má), absolutně k ničemu.
1.7.2011 23:34
LangPa | skóre: 12
| blog: LangPavel
| Hradec Králové
1.7.2011 15:34
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
/* Začátek komentáře /* Předchozí komentář */ Konec předchozího komentáře, který ukončí blok komentářů */ Zamýšlený konec komentáře, ve skutečnosti chybavs
/+ Začátek komentáře /* Předchozí komentář */ +/ Konec komentářeBTW: Autor ještě zapomněl zmínit dokumentační komentáře.
char ch; // unsigned UTF-8 znak, hodnota 0xFFUTF-8 znak (čo to vlastne je?) asi nemôže mať hodnotu 0xFF...
1.7.2011 15:22
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
import std.stdio;
void main(){
char ch;
writefln("0x%x", ch);
}
bystrousak@kitakitsune:~/Plocha$ rdmd char_test.d 0xffNěkolik dalších informací třeba v oficiální dokumentaci: Types, Porovnání C++ a D stringů.
může:
http://ideone.com/NGbmt
http://www.eki.ee/letter/chardata.cgi?ucode=00FF
http://www.utf8-chartable.de/
1.7.2011 19:02
pavlix | skóre: 54
| blog: pavlix
assert(mixin("5 + 10") * 2 == 30);
WTH? Tady mixiny jsou asi něco jiného než třeba v Ruby, ne? Já bych to pojmenoval "eval" .
1.7.2011 15:23
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Autor poukazuje na linkovatelnost k objekovým souborům jiného kódu, ale zároveň dodává, že prototypy je nutné obalit do bloku extern C. To ovšem znamená, že se překladač používá pro symboly v objektu jiné názvy, než které používá programátor v D.
Táži se tudíž, jestli specificikace stanovuje name space mangling, nebo jestli to je ponecháno na libovůli překladače, jako to je u C++, pročež není možné míchat knihovny přeložené různými překladači (nebo dokonce jejich verzemi)?
foreach by som určite spomenul i foreach_reverse a mixiny by som ponechal na samostatný diel.
V poslednom príklade sú špatné úvodzovky:
throw new Exception(„second“);
Dík za seriál.
Z vaše výčtu v příkladech vidím jenom kontejnery přímo v jazyce, tady konkrétně hashtable, což považuji naopak za významné pokurvení jazyka, a lehkou zmínku o GC, který, když už teda na něm někdo trvá, lze mít v C++ také (ne, o smart_ptr nemluvím).
Ale třeba to bude v dalších dílech lepší.
IMO, kontejnery v jazyce jsou lepší přístup, ale to je asi věc osobního vkusu
Pro jednodušší programy je to samozřejmě výhoda, syntaxe je přehlednější, pohodlnější a názornější. Ale časem se dostanete do situace, kdy budete potřebovat nějaký kontejner, který v jazyce není. A pak se nutně ty ručně dopsané budou syntaxí lišit od těch standardních. Výhoda kontejnerů ve standardní C++ knihovně je, že si můžu napsat vlastní rb_map, který interně používá RB strom, ale navenek se chová stejně jako standardní std::map, takže v případě potřeby stačí vyměnit typ v deklaraci, přidat jeden #include a na kódu nemusím měnit vůbec nic.
2.7.2011 15:33
pavlix | skóre: 54
| blog: pavlix
A navíc funkčně to můžeš emulovat pomocí interfaces / mixins.
2.7.2011 15:25
pavlix | skóre: 54
| blog: pavlix
4.7.2011 00:09
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
.
4.7.2011 14:31
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
1.7.2011 21:59
pavlix | skóre: 54
| blog: pavlix
) mělo být řešeno přes interface. Ale nerad píšu interface pak funkční class-y a jednu/dvě/tři vnitřní implementace, které budou vždy totožné, můžu neustále kopírovat (to je blbost), nebo napíšu další třeba i „statickou“ třídu. Raději udělám „abstraktní“ objekt místo interface a totožnou funkcionalitu implementuji tam kam patří - v něm .
2.7.2011 15:30
pavlix | skóre: 54
| blog: pavlix
Mají a jsou super, nicméně vícenásobná dědičnost není zlo, ale umožňuje někdy výrazně méně psaní, když to je potřeba.Nevšiml jsem si.
Prostě nežeru myšlenku: „Interface nesmí nikdy obsahovat nějakou implementaci“.Tak to se shodnem. Já neměl namysli nutně pouze abstraktní interface. Ale ve většině případů s ním vystačím. Při dobrém návrhu se dá funkcionalita interface vyhodit do samostatné třídy, takže i absence implementace se dá obejít. Přijde mi to jako menší prasárna než řešit při vícenásobné dědičnosti problémy s vícenásobným předkem.
Chtělo by to jazykovou podporu pro delegaciTo by imho bylo dědičnosti velice podobné (onehdá se o tom vedl flejm). Byla by to vlastně dědičnost, akorát s trochu jinými pravidly přístupu.
Chtělo by to jazykovou podporu pro delegaci, ale to bohužel zatím nikdo nemáNevím přesně jakou formu podpory máte na mysli, ale některé jazyky dovolují rozšiřovat syntax, takže by neměl být problém si tu podporu dodělat.
2.7.2011 17:33
pavlix | skóre: 54
| blog: pavlix
IMHO odstranění vícenásobné dědičnosti je jen první krok směrem k nevyhnutelnému odstranění jakékoli dědičnosti,IMHO vyvráceno praxí.
2.7.2011 22:09
pavlix | skóre: 54
| blog: pavlix
Jsou to právě praktici, kdo zjistili, že dědičnost je mizerný způsob sdílení implementace a že by se jí programátor měl pokud možno vyhýbat.
3.7.2011 09:53
pavlix | skóre: 54
| blog: pavlix
Jo, tvrdím, že odstranění dědičnosti je nevyhnutelné, přináší prostě příliš mnoho problémů. Neřekl jsem, že odstranění vícenásobné dědičnosti vede nevyhnutelně na odstranění jednoduché, ale že to je IMHO první krok. Je ten významový rozdíl tak malý?
Z teoretického i praktického pohledu je vícenásobná dědičnost jen triviálním rozšířením té jednoduché, které přináší výrazně míň problémů, teoretických i praktických, než zavedení dědičnosti vůbec. Jsou nějaké problémy, které dědičnost docela dobře řeší (já vím teda o jednom, GUI toolkity a hierarchie widgetů), ale IMHO ten přínos zdaleka nevyvažuje zápory.
3.7.2011 10:59
alblaho | skóre: 17
| blog: alblog
class A {
B b expose *; // řekněme, že B má metody m1 a m2
C c expose m3, m4;
D d expose * but m5, m6; // řekněme, že D má metody m5, m6 a m7
}
Triviální desugaring vypadá takhle:
class A {
B b;
C c;
D d;
m1() { b.m1(); }
m2() { b.m2(); }
m3() { c.m3(); }
m4() { c.m4(); }
m7() { d.m7(); }
}
Snaha vystavit metodu se stejnou signaturou z víc delegátů by vedla k chybě při překladu. Má to pár zajímavých sémantických problémů: Kdy se inicializují b, c a d? Smí se za běhu změnit? A vynullovat? Jak by se ta změna projevila v ostatních vláknech?
Jedna věc, která se mi líbí na traitech, kterou takovýmihle triviálními delegáty neuděláš: Trait smí deklarovat abstraktní metodu, kterou musí "implementující" třída definovat. Takže je tam ta vazba vlastně obousměrná. Je to užitečné, ale nejsem si jistý, jestli to nemá nějaké vlastní problémy.
Další související věc by byla jazyková podpora pro dependency injection
3.7.2011 12:50
alblaho | skóre: 17
| blog: alblog
class A {
B b = new B() exposing *; // řekněme, že B má metody m1 a m2
C c = new C() exposing m3, m4 {
public int m4 {
// implementing abstract method
return 42;
}
}
}
Aby to bylo konzistentní, tak by metoda m4 asi neměla vidět nic ze symbolů v A. Jenže to právě ty mixed-in metody v Ruby dělají, což? Případně by m4 mohla definovat obalovací třída A, hmmm, máš pravdu, je to zajímavý problém.
Aby se s tím dalo pracovat, tak by to ještě chtělo taková ta implicitní rozhraní, co má Go: třída A podporuje taková rozhraní, pro něž jsou všechny potřebné metody vystavené.Jasně. Existuje totiž jeden rozdíl, o kterém už jsem na ábíčku několikrát mluvil, ale spousta lidí si ho pořád neuvědomuje, rozdíl mezi podtypem a podtřídou. Zdálo by se, že v mém příkladu výše bych nemohl napsat
B b = new A(), protože A přece není podtřídou B. To sice není, ale je jejím podtypem (viz substituční princip Báry Liskovové). To lze zjistit automaticky, jako v tom Go, nebo lze vyžadovat, aby to programátor deklaroval. Nemám vyhraněný názor na to, co je správné.
A k těm abstraktním metodám z traitů, v čem je problém?Já to asi řekl špatně. Traity umožňují něco takového:
trait T {
abstract int m1(); // jenom třída, která má m1, může includovat T
int m2() {
return 2 * m1();
}
}
class X with T { // to je OK
int m1() {
return 1;
}
}
class Y with T { // to je chyba při překladu, Y nemá m1
}
Je to taková rozumnější forma dědičnosti, která netrpí některými problémy (narozdíl od mixinů). Ale máš pravdu, mohli bychom uvažovat abstraktní třídy bez dědičnosti, a ve třídě, která by na někoho takového chtěla delegovat, bychom ty abstraktní metody museli dodefinovat. Ta dodefinovaná metoda by naopak měla přístup k vnějším symbolům, a měli bychom to kompletní.
To možná není špatný nápad. Delegát může mít svůj stav (trait ne; mixin ano, ale ten stav se dědí, zatímco tady by byl zapouzdřený), to je užitečné, vystavit z něj jde jenom metody, kolize je třeba řešit ručně, to by mohlo fungovat.
), eště by to chtělo vymyslet konstruktory, ale to by neměl být takový problém.
Vyměňování za běhu by taky neměl být problém, s tím, že typová kompatibilita by se kontrolovala při compile-time.
Tedy aspoň v současné podobě běžné v C++/Javě/C#, kde volající rozhoduje o tom, jaká třída se vlastně bude instancovat, o tom by měl rozhodovat volaný.
No, jestli považuješ agregaci za jiný druh dědičnosti, tak samozřejmě. Zrovna tak můžeš považovat dědičnost za jiný druh agregace.No já tadyto žonglování s těmihle pojmy celkově moc nemusím... mně to přijde jako buzzwordy. Ono totiž v praxi je "dědičnost" něco jinýho v C++, něco jinýho v Javě a něco jinýho v C# a tak dále. Každá z těhle implementací má svoje problémy, a tím pádem i svoje (různá) řešení. No a pak říkat, že "Návrhový vzor X bych nahradil Y" je takové mnhoznačné, protože v každým jazyce/prostředí by to způsobylo něco jinýho...
o tom by měl rozhodovat volanýKvůli tomu přece není potřeba rušit konstruktory. Nějakou formu kontruktoru mít musíš...
factory, která by jediná mohla používat operátor new, ale to v zásadě nic neřeší a jenom to přidělává bordel. Dependency injection je výborná věc, ale jen na určitou množinu problémů, univerzální řešení to není. Fakt nevím.
Buzzwordy, hmm, a co že toho nejsou plná všechna ta byznys-oryentyd mídia typu ITBiz? OOP byl buzzword, někdy před 20 lety, dneska letí NoSQL, ale dědičnost a agregace? Pojmy mají i svůj význam, proto existují, a že se ti zrovna nechce… no, to není můj problém.Ty pojmy mají svůj význam, ale jen v nějakém konkrétním kontextu. Ne ve filosofické debatě typu "Dědičnost je špatná, měla by se nahradit delegací/agregací/perforací/jánevimčim". Měla by se nahradit v jakém projektu? V linux kernelu? V GUI toolkitu? Ve webovém frameworku? A podobně... Prostě říct, že návrhový vzor X je lepší je jako říct, že operační systém X je lepší. Bez bližšího kontextu to nemá valný smysl.
Konstrukce objektu je hrozně magická operace.Houby magická operace
Je to jen alokace paměti a její inicializace. O co v tomhle případě jde, je nějak vhodně to syntakticky pocukrovat.
Například takhle:
class A
{
private:
B b::(*); // B má metody m1 a m2
C c::(m3,m4)
{
int m4()
{
// implementing abstract method
return 42;
}
}
D d::(^(m1)); // ^(m1) značí vše krom m1, D má metody m1 a m5
public:
A() :b(new B(...)), c(new C(...))
{
//...
d = new D(...);
}
}
Pojmy dědičnost a agregace mají svůj význam v kontextu objektově orientovaných programovacích jazyků.Jo? Takže můžu přístupovat stejným způsobem k třídám v C++, Javě, C# a třeba Objective-C? Neřekl bych...
Ve Smalltalku je AFAIK každá třída potomkem nějaké jiné třídy. A čím potomkem je ta prapůvodní třída, která stojí v kořeni hierarchie dědičnosti?Je bez rodiče. Stejný to je v Object Pascalu - tam mají TObject.
Už chápeš, jakou magii mám na mysli?Ne, to teda nechápu, já tam žádnou magii nevidim...
A agregace a dědičnost jsou dostatečně obecné koncepty na to, abys je mohl aplikovat i na ten Object Pascal, Simulu, Eiffel, Smalltalk, Ruby, Python a já nevím co ještě, i když se ty jazyky od sebe navzájem v jiných ohledech významně liší. (A rozdíl mezi vícenásobnou a jednoduchou dědičností je fakt minimální.)
No dobře, seš prostě Céčkař, zajímá tě implementace a filozofickou stránku věci neřešíš. Já jo, takže mne nejvíc zajímají "hraniční" případy. Konstruktor je takový hraniční případ: Je to metoda/funkce, která dělá něco, co žádná jiná metoda nedělá a dělat nemůže (a to se týká i jazyků s explicitní správou paměti – no i když, nejspíš by sis mohl v C++ ručně alokovat paměť, vyplnit hlavičku objektu, inicializovat všechny položky a pak ten ukazatel přetypovat, ale kdo by to dělal?). Dá se tomu vyhnout? Netoužím po vyloženě čistém jazyku, ale způsob, jak se vytváří objekty a hlavně jak se spojují dohromady do grafu, který tvoří aplikaci, je z praktického hlediska velmi důležitý (proto už jsem tady několikrát zmiňoval DI).
ale způsob, jak se vytváří objekty a hlavně jak se spojují dohromady do grafu, který tvoří aplikaci, je z praktického hlediska velmi důležitý (proto už jsem tady několikrát zmiňoval DI).S tím naprosto souhlasím. Mohli bychom říct, že aplikace je (z tohohle hlediska) nějaký graf objektů, buď to strom, nebo alespoň DAG, v něm jsou objekty rodičovské, potomci, a mezi nima nějaká "dědičnost" ... teď ale nemyslim tu konktrétní dědičnost známou z běžných OOP jazyků, ale obecně jakoukoli dědčinou, ať už se realizuje pomocí "běžné" dědičnosti, pomocí agregace nebo pomocí jánevím čeho. Pak tam samozřejmě existují všelijaké další vazby... Někteří lidé je rádi pojmenovávají... Takže už zbývá "jenom" to, jak to vyjádřit programovacím jazykem. Já bych osobně nejradši jazyk, který by poskytoval co nejvěší volnost a zároveň obsahoval syntaxi pro realizaci co nejvíce možných způsobů těch vazeb. Čili by asi (částečně) obsahoval nějakou meta-syntaxi. V tomhle se mně právě u D libí operator overloading - poskytuje opravdu velkou volnost.
3.7.2011 18:56
Josef Kufner | skóre: 70
Mohli bychom říct, že aplikace je (z tohohle hlediska) nějaký graf objektů, buď to strom, nebo alespoň DAGMohl by to být i graf s cykly s tím, že by pak mezi objekty nebyl vztah částečného uspořádání ale jen předuspořádání.
Přetěžování operátorů s použitím jmenné konvence pro metody se mi docela líbí, pokud teda na přetěžování operátorů přistoupím, a koukám, že chlapci v D se docela snaží i řešit asociativitu (ne jako ve Scale, kde se asociativita operátoru pozná podle toho, jestli je posledním znakem dvojtečka ), to je pěkné.
3.7.2011 19:03
pavlix | skóre: 54
| blog: pavlix
DI to je to, o čem se tak strašně zmateně píše na rootu?To je ono. Mluví se o tom už víc než deset let, ale do světa PHP se to dostalo až teď
3.7.2011 19:52
pavlix | skóre: 54
| blog: pavlix
Vytvoření objektu by mělo být zavolání metody třídy.A proc? Tohle me vzdycky prislo zbytecne svihle. Konstruktory objektu bych nechal jako normalni samostatne funkce (nikoliv metody objektu/trid/cehokoliv), a bylo by po problemu.
3.7.2011 18:07
Josef Kufner | skóre: 70
3.7.2011 19:01
pavlix | skóre: 54
| blog: pavlix
3.7.2011 19:22
Josef Kufner | skóre: 70
3.7.2011 20:05
pavlix | skóre: 54
| blog: pavlix
To, že to bývá instance třídy je spíš použitým jazykem a tím, že se Factory nepoužívá na triviální operace.To je naprosto v pořádku. Mezi náma, metoda __new__ v Pythonu má taky schopnost vracet jiný objekt, než o který si uživatel řekl. Takže taky funguje jako factory funkce dokonce má k dispozici stav třídy, tzn třída funguje jako factory objekt. Ale fakt je, že když chci opravdový factory objekt, vytvářím ho samostatně kvůli čistotě kódu.
Možná žádné lepší řešení není, nevim.
3.7.2011 15:15
Josef Kufner | skóre: 70
Vyjadřovací síla všech programovacích jazyků je stejná, ano.To není pravda.
3.7.2011 18:10
Josef Kufner | skóre: 70
2.7.2011 17:52
LangPa | skóre: 12
| blog: LangPavel
| Hradec Králové
Chtělo by to jazykovou podporu pro delegaci...Pokud jsem to pochopil, tak takovou delegaci umí Delphi (Object Pascal). Funguje to tak, že třída implementuje interface přez nějakou property, která implementuje daný interface. Je ale potřeba co nejdříve (např v konstruktoru) property nastavit na platnou instanci
type
TMyClass = class(TParent, IInterface1)
private
FInterface1: IInterface1;
public
constructor Create;
property Interface1:IInterface1 read FInterface1 implements IInterface1;
end;
Pokud se bavíme o tom, že interface má nějakou implementaci, tak to už není interface ve smyslu, že lze vícenásobně zdědit/implementovat pokud není povolená vícenásobná dědičnost.Parse error.
Pokud implementaci vyhodím do další třídy, tak je to právě to psaní navíc jen abych dostál nemožnosti vícenásobné dědičnost, ale principiálně je to „workaround“ a způsobí právě to, že se více píše.Asi jsem to špatně pochopil, myslel jsem, že „psaním navíc“ bylo myšleno zbytečné opakování kódu. Pokud jde o hlavičku jedné třídy navíc, tak pak beru zpět, že se v tomto shodnem. To mě u vícenásobné dědičnosti či interface opravdu netrápí. Mně osobně spíš jako workaround přijde implementace vícenásobné dědičnosti třeba v C++.
A jiném případě se zas musí zapouzdřovat a zveřejňovat a zas je to více psaní (zapouzdření není vždy ten správný přístup, i když bezpečný). Pokud se použije nějaká názvová konvence a používá se to „přímo“ ve „finální“ třídě, obvykle žádné problémy nenastanou, a efektivita je vyšší a čitelnost či přehlednost to neovlivní.Parse error.
Si prostě myslím, že vícenásobná dědičnost není zlo, zlo je když se používá místo „interface“ a její odstranění považuji za zbytečnou obstrukci jazyka.Nikde jsem nepsal, že je. Jen se mi nelíbí vícenásobná dědičnost à la C++, a tím pádem vícenásobná dědičnost ve všech jazycích, které se budou snažit optimalizovat do stejné míry jako C++.
.. V minulosti to bylo kontroverzní téma, fčul už je to většinou klasifikováno jako zlo, (zlé) jazyky který touto možností nedisponují, závidí .
2.7.2011 22:19
pavlix | skóre: 54
| blog: pavlix
No pokud obsahuje interface nějakou implementaci není to již interface, ale například abstarktní class a tudíž se neimplementuje, ale dědí a pokud nelze dědit vícekráte tak je to stopka, pokud chceme dědit s obou.To už je o něco srozumitelnější. To, že interface má přiřazené už nějaké hotové metody podle mě ještě nutně neimplikuje, že je to abstraktní třída (tzn že to má všechny vlastnosti, co abstraktní třída v daném jazyce). Nejspíš je to mixin.
To psaní: Ano hlavička další třídy, komentáře a volání dané metody a případné nadbytečné předávaní nějakých parametrů - ano to jsem myslelTak kvůli tomu bych se s vícenásobnou dědičností netrápil, pokud nejde implementovat nějak hezky a čistě.
2.7.2011 22:22
pavlix | skóre: 54
| blog: pavlix
No to je druhý případ psaní navíc, class má používat(dědit) třeba dvě třídy a rozhraní obou tříd má být veřejné. Takže pokud nelze dědit vícenásobně, tak se instance class-ů zapouzdří a buď se zveřejní metoda (getter) jednotlivých instancí (což má své nevýhody). Nebo se jednotlivé fce napíší znovu a jejich obsahem je jen provolání jednotlivých fcí zapouzdřených instancí.No... když vezmu dvě zcela nezávisle vytvořené třídy... a chci od obou dědit... tak budu mít docela problém s kolizemi, ne? Stejně nad tím nakonec budu muset postavit nějaký slušný interface, takže mám za to, že toho psaní navíc tak moc nebude a ta efektivita zdaleka jít do háje nemusí.
class A
{
public:
void delej();
};
class B
{
public:
void delej();
};
class C
: public A
, public B
{
public:
using A::delej;
};
C c;
c.delej(); // A::delej()
c.B::delej(); // Explicitně chceme delej z B
Asi si zase nadělám pár nepřátel, ale musím konstatovat, že nechápu všechny ty komentáře typu "super článek". Podle mne je ten článek z didaktického hlediska naopak velmi špatný. Tedy aspoň pokud byl zamýšlen jako výukový.
Článek mi připomněl jeden odstrašující příklad, jak by se učit nemělo, v osobě našeho učitele informatiky na gymnáziu (paradoxně zaměstnance KDM MFF UK). Typická hodina vypadala tak, že přišel, prohlásil: "Tak dneska si probereme pole. Pole se deklarují takhle: ...", napsal na tabuli syntaxi a když jsme měli štěstí, přidal i nějaký příklad. Pak nám dal nějaké zadání a nechal nás, ať se snažíme. Přičemž vůbec nevysvětlil, co to takové pole vlastně je a k čemu slouží. Výsledek? Kdo už Pascal uměl, ten se nic nedozvěděl, kdo ne, stejně neměl šanci to z jeho výkladu pochopit, takže byl odkázán na následný výklad od spolužáků.
Proč o tom mluvím? Protože tento článek funguje přesně stejně. Místo aby se začlo nějakým "filosofickým" úvodem o jazyce jako takovém, autor hned začne bez jakéhokoli systému chrlit úkázky, které ani moc neokomentuje, takže nám nezbývá než se dohadovat, jestli to int[string] je asociativní pole či co, co je to vlastně ten "mixin", proč má "UTF-8" znak maximální hodnotu 255 atd. Prostě jen výčet "podívejte se, co to všechno umí". A stejně jako v předchozím odstavci: kdo jazyk zná, tomu to nic nedá (až na ten příjemný pocit "jo, to znám"), kdo ho nezná, tomu také ne. Prostě to celé působí jako screenshotová "recenze" nové verze distribuce, ne jako výukový článek.
Neberte to jako že vás chci nějak strhat; vlastně jsem se ještě ani nepodíval, kdo je autorem, a záměrně to neudělám, dokud tento komentář neodešlu. Naopak, snažím se vám pomoci, protože nadšené komentáře "super článek" vám nepomohou, ty vás jen utvrdí v přesvědčení, že to děláte skvěle, což bohužel vůbec není pravda. Zkuste se nejdřív zamyslet nad tím, komu je článek vlastně určen, a pak si text procházet ne svýma očima (někoho, kdo jazyk zná a používá), ale očima právě té cílové skupiny (která ho dost možná vidí poprvé). A nepostupujte zdola, tj. od konkrétních ukázek demonstrujících nevysvětlené principy, ale naopak shora, tedy od těch principů, které pak teprve demonstrujete na ukázkách.
Ale neco jsem si presto z clanku odnesl. Ten dort, co kocicka s pejskem pekla byl patrne 'multi-paradigm'Malem jsem smichy spadnul ze zidle.
4.7.2011 14:34
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Filosoficky uvod o jazyce byl v prvni casti, imho dostatecny, prikladum z kodu jsem rozumel, napr. ty hodnoty jsem pochopil jako defaulty, je to zrejme z toho prikladu, zkuste se na nej podivat znovu.
Cili zaver - D jsem neznal, clanek jsem pochopil, tedy spor s vasi tezi. Pokud se chcete naucit programovat, nactete si neco jineho a ja se pripojuji k oslavovatelum a prosim autora, aby styl zachoval
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.