Programování v jazyce D (4): Funkce a delegáty – pokračování, podmínky, cykly, pole, pointery (diskuse)

[Ladicek]

Se skřípěním zubů bych pochopil i kondicionální kompilaci, ale co je to set cyklů??

[----]

No, soubor cyklů.

[----]

Změněno :)

[jekub]

"Tento příklad vypisuje čísla od 6 až do nekonečna"

nefunguje

[JS]

Zkusil jste to nechat bezet nekonecne dlouho?

[EtDirloth]

netreba

[----]

Omlouvám se, vypadlo mi tam v závorce "true". Nechám opravit, až se vrátím domů. A to bych přísahal, že jsem před zasláním testoval všechny kousky kódu, co v článku jsou :)

[Jardík]

řekl bych, že ani tak nejde o to true jako spíše o to, že do intu jde nacpat nějaká maximální hodnota a tak nekonečna nedosáhnete, ani když to poběží nekonečně dlouho, vždycky to přeteče.

[----]

To je pravda :) Ale nebuďme příliš pedantičtí (v angličtině se takový člověk označuje jako "smartass") - běží to "jakože" do nekonečna.

[----]

Příklad opraven.

[Petr Bravenec]

for (inicializace; podmínka; post-iterace) { ... }

Část „inicializace“ se spustí první. Potom se cyklí, dokud je splněna podmínka.

Opravdu?

[----]

Co je za problém? První se inicializuje, před každou iterací se ověří podmínka, pokud ne, cyklus skončí, jinak se cyklí dál.

[Bystroushaak]

Jsem rád za další díl, každá aktivita okolo D je potěšující, ale dnes se mi to zdálo dost zmatené. Kdybych nevěděl o čem je řeč, tak to nepochopím.

[----]

Něco konkrétního? Abych mohl vylepšit.

[Bystroushaak]

Přišlo mi to takové zmatené. Možná nebylo nejšťastnější toho dát tolik najednou, osobně bych to rozdělil na víc dílů a popsal víc.

[----]

Mým cílem není teď popsat všechno. Souhlasím, že je to možná na jeden díl trochu moc, ale tak to prostě vyšlo. Každopádně různé ty okrajové případy apod. budou popsány v průběhu seriálu. Teď chci jen rozebrat ten základ, a pak se chci pustit do nějaké větší praktické aplikace, na kódu se vše vysvětlí nejlépe, ale zatím je potřeba popsat ten základ a to je na tom všem nejtěžší..

[Josef Kufner]

Od toho jsou předchozí díly seriálu

[Bystroushaak]

Ty jsem samozřejmě četl taky. Spolu s knihou D programming language a oficiálním tutoriálem/manem na stránkách D.

Možná je to tím že sám jsem to docela pitval na několik stánek a tady je to hodně zhuštěně podáno.

[----]

viz příspěvek nahoře. Ale jakákoliv kritika se hodí. Až to bude všechno venku, chci to stáhout, spojit do jednoho celku, provést revizi, vyčistit na základě připomínek a vydat. A přeložit do angličtiny.

[Josef Kufner]

Nečetl jsem to nijak důkladně, spíš jen prolítnul příklady, ale srozumitelné mi to přišlo. Pokud čtenář už pár jazyků jakš takš ovládá, neměl by mít problém. Rozpitvávat to na mnoho stran by byla ztráta času jak pro čtenáře, tak pro autora.

[----]

Počítám se základní znalostí logiky programování, Cčkaři/C++/C#/Java mají výhodu, ale snažím se na tu znalost moc nespoléhat.

[Jardík]

Já bych řekl, že D nepřináší zas tak nic zásadního, kvůli čemu by stálo za to opustit C++. Mám tam assert, static_assert, variadic templates, auto, lambda fce, range-based for, typed enums, mám tu utf8 string literáli, utf-16, utf32 (u8"", u"", U""), naprogramovat assert vyhazující výjimku je otázka několika sekund, ...

[----]

Lambda funkce v C++ nemají automatickou typovou inferenci, closures v C++ nejsou polymorfické, templates v D a v C++ jsou co se týče použitelnosti úplně někde jinde, C++ nemá static if, což je při programování s templates dost zásadní, range-based for je jen alias k obyčejnýmu for, tudíž neumožňuje vlastní počet indexů (např. v D můžu udělat foreach(a, b, c, d, e, f; můj_objekt_definující_správnou_metodu)), auto nefunguje pro návratový hodnoty bez decltype jako v D (v D můžu prostě specifikovat návratový typ jako auto a vůbec se nestarat o nějaký decltype, prostě vracet co chci, kde chci)

[----]

Mimochodem, dva logicky ekvivalentní kusy kódu v C++ a v D http://ideone.com/pLzNu , http://ideone.com/UgZlo

[Bystroushaak]

Lol, ta koncovka u toho C++ příkladu .. http://ideone.com/UgZlo :D

[----]

Vskutku zlo :)

[Bystroushaak]

S velkym 'z' :P

[Luboš Doležel (Doli)]

Já mám pocit, že D představuje to, kam se C++ mohlo dostat, kdyby se na něm opravdu makalo. Standardizace C++ mi připomíná standardizaci OpenGL - trvá to dlouho a je to pak zklamání.

[Program]

Ono spíš C++ zatěžuje zpětná kompatibilita. Ať už byly některé vlastnosti C++ špatné od začátku (pro flejmaře: jiné zase dobré), nebo jsou důsledkem kompatibility s C, či vůbec takový C přístup. C++ se dnes snaží "emulovat" chování vyspělejších jazyků, ale výsledek je hrozně neohrabaný.

[Miloslav Ponkrác]

Každý jazyk v okamžiku prvního standardu začne zastarávat.

C++ jako jazyk je určen pro případy, kdy maximální rychlost a minimální spotřeba zdrojů a plná kontrola nad programem je prioritou. Z toho vyplývá neohrabanost.

Je snadné implementovat high level featuru v prostředí, kde spotřeba paměti, rychlost kódu ani další atributy nejsou klíčové. U C++ se musí vše implementovat maximálně úsporně – a to kód zanáší.

Když vezmu, co štve v C++ mě, je to toto:

1) Rozlišování . a -> u přístupů. Kompilátor má dostatek kontextu, aby je rozlišil sám. Mohlo se ke všemu přistupovat tečkou a bylo by.

2) Integerové typy jsou příliš závislé na implementaci a to důsledně. Takže si nejste třeba jistí, zda standardní knihovna pro práci se soubory zvládne či nezvládne 64bitovou délku či poizici v souboru, protože je to long, a ten může být cokoli od 32 bitů nahoru.

3) Nerozlišování NULL a celočíselné nuly.

Ostatní věci, které se mi nelíbí v době vzniku C++ nemohly být známy, takže je neuvádím.

Hlavně by se D mělo snažit aby využilo možnost a znalosti o současnosti a vylepšilo co se dá. Zatím se mi zdá, že D se moc nepochlapilo. Škrtlo namespacy, škrtlo vícenásobnou dědičnost, šktlo podporu 16bitových platforem. A řada chování D je minimálně nedomyšlená.

[kralyk z abclinuxu]

1) Tohle je náhodou docela šikovné u smart pointerů, iterátorů a podobných "obalujicích" typů... Bez -> by se muslo použít něco jako smartptr.get().fooBar() a to zavání Javou

2) No to ano, to je problém... Výhodou je portabilita, nevýhodou je, že se to pak musí řešit stylem boost::stdint a podobné... Nicméně C99 a C++11 toto řeší tím, že tento přístup standardizují (viz), což si myslim, že je dobré...

3) Řeší C++11 - nullptr

[Miloslav Ponkrác]

Ad 1) Vymyslel by se jiný syntaktický cukr. A nebo by se staly součástí jazyka přímo.

Ad 2) Pořád si nemohu pomoci, ale skutečně portabilní typy vyřešila geniálně Ada.

Ad 3) Neřeší, protože jakýkoli výraz, parametry metody, atd., která čeká pointer stále přijme celočíselnou nulu.

[kralyk z abclinuxu]

Ad 3) Já myslím, že oni by to třeba i rádi změnili, ale to prostě nepůjde kvůli zpětné kompatibilitě...

[Miloslav Ponkrác]

Taky si to myslím.

[Sten]

Třeba v GCC to bude varování, které půjde převést na chybu, stejně jako je teď používání Céčkových přetypování. Ale kvůli zpětné kompatibilitě samozřejmě bude možné použít i starý přístup.

[----]

"...Z toho vyplývá neohrabanost..."

proč tedy D co se týče neohrabanosti daleko lépe řešeno a přitom v některých případech výkonnostně C++ převyšuje?

"...plná kontrola nad programem je prioritou..."

v D mám nad programem stejnou kontrolu, jako v C++, možná ještě o něco vyšší (díky lepšímu metaprogrammingu, traits apod.)

"...spotřeba paměti, rychlost kódu ani další atributy nejsou klíčové..."

Jak už jsem zmínil, idiomatický D kód umí být stejně rychlý a paměťově náročný jako C++, přitom bezpečnější a kratší; pokud je potřeba opravdu minimální množství runtime kódu, vždycky je možné implementovat si vlastní runtime (např. bez exceptions apod.)

"...škrtlo namespacy..."

Protože byly zbytečné - systém pravých modulů je plně nahrazuje, kromě toho se D kompiluje asi 6x rychleji než C++ díky tomu, že nemá preprocesor.

"...škrtlo vícenásobnou dědičnost..."

Používat OO v prostředí, kde je potřeba vysoký výkon, je kvůli virtuálním metodám apod. blbost, tam kde není třeba vysoký výkon, multiple inheritance se dá vždy nahradit pomocí interfaces a mixinů.

"...škrtlo podporu 16bitových platforem..."

Má dnes smysl podporovat 16bitové platformy? Ne, nemá - hlavně u jazyka jako D, kde je pravděpodobnost použití na 16bitové platformě tak jedna ku tisíci.

"řada chování D je minimálně nedomyšlená"

Pár příkladů?

[Miloslav Ponkrác]

„proč tedy D co se týče neohrabanosti daleko lépe řešeno a přitom v některých případech výkonnostně C++ převyšuje?“

Pokud jste ochoten se vsadit (zadarmo to dělat nebudu), tak Vám klidně na každý Váš D kód napíše C++ ekvivalent, který nebude pomalejší, než D.

Ono C++ se musí umět a zatím všechny důkazy o tom, že C++ je pomalejší než něco (obvykle Java, teď vidím inovaci D) – vznikly z toho, že testující neumí C++.

---

„v D mám nad programem stejnou kontrolu, jako v C++, možná ještě o něco vyšší (díky lepšímu metaprogrammingu, traits apod.)“

Sice nechápu jak metaprogramming, traits a další přispívají k lepší kontrole.

Nicméně C++ je jazyk dělaný na kontrolu každého možného aspektu výsledného kódu, tj. možnost ovlivnit vše co má vliv na výkon, efektivitu, spotřebu prostředků a další. A to je primární cíl a účel C++.

---

„Jak už jsem zmínil, idiomatický D kód umí být stejně rychlý a paměťově náročný jako C++, přitom bezpečnější a kratší; pokud je potřeba opravdu minimální množství runtime kódu, vždycky je možné implementovat si vlastní runtime (např. bez exceptions apod.)“

Viz moje odpověď ad 1)

---

„Protože byly zbytečné - systém pravých modulů je plně nahrazuje, kromě toho se D kompiluje asi 6x rychleji než C++ díky tomu, že nemá preprocesor.“

Samozřejmě, že je nepotřebuje – jako cokoli co D nemá. A pokud by to neplatilo platí předchozí věta. Protože co D nemá je nepotřebné. Jak jinak.

Jak rychle se program kompiluje mě vcelku nezajímá. Doby kdy na tom záleželo jsou v zásadě pryč. S inkrementální kompilací v C++ je vše co potřebuji do sekundy, když vyvíjím. Jestli se to urychlí na šestinu sekundy mi je vcelku opravdu fuk. A jestli je délka kompilace release verze minutu, nebo půl hodiny mi je jedno, tak ocením spíše max. optimalizaci.

---

„Používat OO v prostředí, kde je potřeba vysoký výkon, je kvůli virtuálním metodám apod. blbost, tam kde není třeba vysoký výkon, multiple inheritance se dá vždy nahradit pomocí interfaces a mixinů.“

Já vím, že D nedokáže jiné, než virtuální metody. I proto je dost diskutabilní použití D v té rychlosti a efektivitě, kterou tu předhazujete na začátku. Prostě v rámci rychlosti, kdybyste to chtěl rozjet na max. Vás D donutí nepoužívat objekty. A jste na tom z hlediska luxusu hůře než C++ a musíte programovat low level na rozdíl od C++.

Vícenásobná dědičnost není plně nahraditelná ani interfacy ani mixiny ani jejich kombinací.

---

„Má dnes smysl podporovat 16bitové platformy? Ne, nemá - hlavně u jazyka jako D, kde je pravděpodobnost použití na 16bitové platformě tak jedna ku tisíci.“

V době, kdy se houfně přechází na mobilní platformy, kdy použití embedded věcí se rozšiřuje jako rakovina – to smysl má. Ne všude je ARM a ne všude je to ekonomické.

C++ s tím nemá problém.

---

„Pár příkladů?“

Dal jsem jich dost v různých příspěvcích pod tímto článkem. Některé máte i o několik odstavců výše.

[----]

"Pokud jste ochoten se vsadit (zadarmo to dělat nebudu), tak Vám klidně na každý Váš D kód napíše C++ ekvivalent, který nebude pomalejší, než D."

Řekl jsem snad, že C++ je pomalejší? Řekl jsem, že D umí být stejně rychlé, a to je rozdíl.

"Samozřejmě, že je nepotřebuje – jako cokoli co D nemá. A pokud by to neplatilo platí předchozí věta. Protože co D nemá je nepotřebné. Jak jinak."

K tomuto vyvození jsi došel jde?

"Já vím, že D nedokáže jiné, než virtuální metody. I proto je dost diskutabilní použití D v té rychlosti a efektivitě, kterou tu předhazujete na začátku. Prostě v rámci rychlosti, kdybyste to chtěl rozjet na max. Vás D donutí nepoužívat objekty. A jste na tom z hlediska luxusu hůře než C++ a musíte programovat low level na rozdíl od C++."

Další blbost - D samozřejmě umí i nevirtuální metody (viz. "final", buď může být final celá třída, v tom případě nebudou žádné virtuální metody, nebo může být final jen samotná metoda)

[Miloslav Ponkrác]

„Řekl jsem snad, že C++ je pomalejší? Řekl jsem, že D umí být stejně rychlé, a to je rozdíl.“

Alzheimer je sviňa, já Vás ocituji: “proč tedy D co se týče neohrabanosti daleko lépe řešeno a přitom v některých případech výkonnostně C++ převyšuje?“

---

„K tomuto vyvození jsi došel jde?“

K tomu, že Vy i jiní argumentujete, že „D to nemá, protože nepotřebuje“.

---

„Další blbost - D samozřejmě umí i nevirtuální metody (viz. "final", buď může být final celá třída, v tom případě nebudou žádné virtuální metody, nebo může být final jen samotná metoda)“

Aha, získal jsem v tom případě nový náhled na čistotu syntaxe programovacího jazyka. Nalepit final a zamezit tak potomkování jen proto, že potřebuji dosáhnout nevirtuální metodu. Ehm ehm, to čisté D.

[----]

Nevidím tu problém - pokud má být veřejná metoda nevirtuální, udělá se final a nepřepisuje se (to neplatí pro private metody, které se mohou přepisovat, i když jsou final, tam se to hodí); jinak jsou metody virtuální s tím, že D kompilátor zná hierarchii třídy, tudíž má prostor k další optimalizaci.

[Sten]

Řekl jsem snad, že C++ je pomalejší? Řekl jsem, že D umí být stejně rychlé, a to je rozdíl.

proč tedy D co se týče neohrabanosti daleko lépe řešeno a přitom v některých případech výkonnostně C++ převyšuje?

[----]

Všimni si toho "některých".

[Sten]

Toho jsem si právě všiml, a tak by mě zajímalo: kterých?

[----]

Nejedná se o jazyk samotný (tam záleží hlavně na kompilátoru apod.) ale třeba: 1) D má výkonný CTFE; spousta věcí se dá zpracovat mimo runtime; C++ sice nějakou podporu taky má, ale je to omezené. 2) Standardní knihovna - hlavně při práci se stringy; slices mohou být dost efektivní. 3) Paralelizace - D má paralelní cykly (viz např. http://dlang.org/phobos/std_parallelism.html#parallel ). Ono by asi toto vše šlo naprogramovat i v C++ (pokud nejsou potřeba např. traits, nemyslím type traits, ale static reflection, které C++ do velké míry nemá), ale nebylo by to zdaleka tak jednoduché a praktické.

[----]

"Dal jsem jich dost v různých příspěvcích pod tímto článkem. Některé máte i o několik odstavců výše."

Nic konkrétního tu nevidím. Jen samé plky o ničem. Že ty budeš z té "staré" generace českých programátorů, co si myslí, že ví všechno nejlíp?

[Josef Kufner]

Vícenásobná dědičnost není plně nahraditelná ani interfacy ani mixiny ani jejich kombinací.

Například kdy?

[Miloslav Ponkrác]

Třeba v okamžiku, kdy potřebujete podědit více tříd s implementacemi metod v předcích a zároveň potřebujete aby nová třída byla přetypovatelná na kteréhokoli předka, tedy byla typem všech předků.

[----]

A něco konkrétního by nebylo? :P

[----]

Mimochodem, pouze poznámka; odkdy je ne-OO kód vždy low-level? Procedurální kód může být též high level, v D se ještě přidává funkcionální paradigma.

[Sten]

v D mám nad programem stejnou kontrolu, jako v C++, možná ještě o něco vyšší (díky lepšímu metaprogrammingu, traits apod.)

Tak to chci vidět, jak naimplementujete v D třístavovou logiku, kterou používá třeba SQL, pro objekt, který nemá defaultní konstruktor, pokud teda nechcete všechno cpát na haldu jak Java. V C++ buď sáhnete po Boost.Optional nebo si něco podobného napíšete za pár minut.

[----]

D umožňuje dát třídy i na stack; pomocí klíčového slova "scope".

[Sten]

To vím, ale to vám pro implementaci té třístavové logiky nepomůže

[----]

Lepší je se zeptat - co tomu oproti C++ brání? Řekl bych de facto nic. Co se týče boost::optional; nevidím jediný důvod, proč by to samé nešlo implementovat i v D; resp. D už to má, v podobě Nullable - http://dlang.org/phobos/std_typecons.html#Nullable

[Sten]

Rozdíl mezi Nullable a Boost.Optional je poměrně zásadní: Nullable je u tříd jenom takový větší pointer, zatímco Boost.Optional ukládá samotnou instanci do prostoru vyhrazeného uvnitř sebe. Pokud např. použijete jiné alokátory (třeba sdílenou paměť nebo lock-free per-thread buffery), Boost.Optional stačí uložit tam a uloží tam rovnou i svůj objekt, zatímco objekt v Nullable budete muset složitě honit, aby se do té vyhrazené paměti taky dostal.

[----]

To jde v D také celkem snadno implementovat. Emplace a je to.

[kralyk z abclinuxu]

Já mám pocit, že D představuje to, kam se C++ mohlo dostat, kdyby se na něm opravdu makalo. Standardizace C++ mi připomíná standardizaci OpenGL - trvá to dlouho a je to pak zklamání.

Souhlasím, nicméně u toho D bych zas viděl jako potenciální problém velký "rozmach" tohoto jazyka.

Co jsem tak koukal, oproti C++ má D brutální množství speciálních výrazů, hlavně teda klíčových slov, případně různých speciálních položek objektů a jejich členů. Například množství klíčových slov pro parametr funkce. Nebo všechny ty Object.op* při operator overloadingu. A tak dále. Přijde mi hodně náročný tohle všechno zvládnout.

Autoři D v mnoha ohledech kritzují C++ pro přílišnou složitost, nerozumím tedy tomu, proč, ač na jedné straně složitost snižují, na straně druhé sami přidávají hafo dosti složitých featur, u kterých není jisté, jestli je někdo někdy vůbec bude používat.

[Bystroushaak]

No, budu doufat že jsem nadprůměrně inteligentní, protože já s těmi featurami problém nemám :D

Autoři jazyka hodně dají na průkaznost toho, co program bude opravdu dělat, k čemuž se právě různé rozšířené parametry používají. Trochu si tím tak škrtají o funkcionální jazyky (pokud se tedy ošklivě nepletu, začal jsem se jimi zabývat relativně nedávno).

[----]

Ano, má dost klíčových slov apod. ale dohromady to všechno sedí, nic se nekryje jako v C++ a hlavně je gramatika jazyka nezávislá na kontextu, takže se dá parsovat bez přítomnosti celého frontendu, což věci dost zjednodušuje.

Co se týče těch featur - většinou je používám, a problém s nimi nemám. Všechno je dobře integrované.

[kralyk z abclinuxu]

Ok... no dost možná to je tím, že ten jazyk zatím málo znám.

Jinak další věc, která by mě zajímala, je stabilita standardu. U C++ je tahle stabilita snad příliš silná, u D jsem trochu na rozpacích - rozdíl mezi D1 a D2 byl značný. Dá se očekávat za pár let další taková změna, nebo to byla jen porodní bolest jazyka?

[----]

Mluvil jsem o tomto samém s jedním z autorů (Andrei Alexandrescu) a říkal, že se D3 neplánuje. Co se týče stability standardu, ještě není stabilní, nicméně aktuální featury už by se neměly měnit, možná něco přibude; pracuje se na stabilizaci. Standardní knihovna stabilní ještě není (přibude nový I/O modul apod.). Nicméně, pokud se něco ve standardní knihovně nahradí, stará se označí jako "deprecated" a autoři programů mají několik měsíců čas si svůj program zaktualizovat.

Btw, co se týče D1 vs D2; ten rozdíl není tak markantní, jak se říká. Sice toho hodně přibylo, ale D2 stále obsahuje de facto celý subset D1 (kromě některých věcí, jako že v D2 jsou string literály vždycky imutabilní, změny v template systému, tranzitivní const apod.). Zmigrovat kód z D1 na D2 není až takový problém, hlavně se jedná o přepsání některých výrazů.

[Martin Petr]

... pokud se něco ve standardní knihovně nahradí, stará se označí jako "deprecated" a autoři programů mají několik měsíců čas si svůj program zaktualizovat.

Tohle bohužel v žádném případě není řešení problému.

Zpětná kompatibilita.

Zpětná kompatibilita.

Zpětná kompatibilita.

Jazyk, který ji nerespektuje, nemá nejmenší šanci se pro sadit jako něco více než jazyk pro hobby projekty.

I teď po letech se smutkem sleduju, jak se ještě stále nevyřešilo "schizma" mezi Python2 a Python3 částí pythoního světa. Ten jazyk mám opravdu moc rád, ale vždycky, když v něm chci něco začít něco psát, tak mě tahle jeho bipolarita odrazuje.

[----]

Ale zpětná kompatibilita je featura stabilního jazyka. Vzhledem k tomu, že nejméně standardní knihovna D2 není ještě stabilní verzí, tak se dělají změny. :) Až bude vše API-stabilní (počítám, že max do roka tomu tak bude) tak může být i zpětná kompatibilita.

[Miloslav Ponkrác]

Python 3 by mohl udělat jednoduchou věc: Ohlásit že od teď až navždy je zpětná kompatibilita svatá.

[Martin Petr]

To bych uvítal, i když to nevidím reálně.

Ovšem to nemění nic na faktu, že existuje obrovské množství kódu (logicky mnohem větší množství kódu, než které bylo napsáno od vydání Pythonu 3), do kterého bylo investováno nehorázné množství času a peněz. Co s ním, až začne stará větev interpreteru zaostávat? U hobby projektů není problém, ve firmách už to tak růžově nevidím... Pythonu by to mohlo v očích managorů a dalších docela dost ublížit, protože kdo ví, co se ještě s Pythonem může udát v budoucnosti. A ani bych se jim jim upřímně řečeno nedivil.

[Josef Kufner]

Ono je lepší, když se zpětná kompatibilita drží jen vrámci major verze (tedy 3.inf je zpětně kompatibilní s 3.0), protože jinak není jak odstranit zastaralé či chybně navržené části jazyka, jak je vidět u C++ a pak to vypadá jak hovniválova kulička.

Mezi major verzemi pak stačí jen dobře popsat nekompatibilní změny, umožnit instalaci obou verzí současně a třeba i nechat ve zdrojáku tuhle verzi zapsat, aby překladač mohl včas zakřičet (ať už warning nebo error).

[kralyk z abclinuxu]

Donbře, jenže tohle měli vývojáři Pythonu ohlásit dřív, než bylo pozdě. Kdyby prostě už mnohem dířv ohlásili, že kompatibilita bude udržována jen v rámci major verzí, mohly se na to vývojáři i distribuce lépe přípravit a nebyl by to takovej šílenej zmatek jako to je. Mohl se od začátku zavést nějaký stabilní mechanismus, jakým skript řekne, kterou chce verzi a informuje se o tom, co je v systému isntalování a nějak na to může reagovat. Afaik takhle to je v .NET a není to blbej nápad.

Přijde mi, že D se potenciálně řítí do přesně stejných problémů. Jestliže dnes nemají zcela jasno v tom, jestli za 5 let náhodou nepřijdou s D3 a porušením kompatibility, tak je to dost špatný pro nasazení jazyka.

[Miloslav Ponkrác]

To není. Neznám jediný jazyk, který by se nekompatibilně měnil mezi major verzemi a přežil by střednědobý horizont.

Ono totiž v jazyce, který nezaručuje nekompatibilní změny se seriózně programovat nedá.

Každé změna syntaxe jazyka znamená, že Vás léty odladěný kód je opět v alfaverzi. A můžete znovu testovat, ladit, zkoušet a je velké riziko skrytých chyb.

Takže jazyky, které nezaručují zpětnou kompatibilitu se uvaří na tom, že mnoho projektů drží jednu, dvě i několik major verzí pozadu. A bytí a nebytí takového programovacího jazyka záleží na tom, kolik major verzí pozadu bude schopen a jak dlouho udržovat.

Přežijí dlouhodobě jen ty jazyky, které zpětnou kompatibilitu zaručují.

Zkuste si představit třeba v unixech, že se nekompatibilně změní shell. Najednou se prostě změní syntaxe sh a bude to fungovat jinak. Nebo že programovací jazyk C se nekompatibilně změní a ať si Linus znovu přepisuje těch pár desítek miliónů řádek kernelu, ať si je znovu otestuje, hledá chyby. Zastaví se na půl roku veškerá práce na linux kernelu a bude se dělat jen to. Jakmile to Céčko udělá podruhé, první co Linux udělá je, že najde jiný programovací jazyk, který tyhle excesy nebude dělat.

Řada projektů má milióny řádek. Pro takové projekty nemůžete nekompatibilně měnit jazyk. A pokud ano, je jisté, že jazyk má utrum. Ty náklady mu nikdo nedaruje.

Chcete-li udělat nekompatibilní změny, je lépe založit nový jazyk. Ovšem je třeba ho do detailů promyslet a není to sranda. Mnoho jazyků trpí tím, že se autor uchrtí na jeden aspekt jazyka a ostatní stojí za starou bačkoru.

[Josef Kufner]

To není. Neznám jediný jazyk, který by se nekompatibilně měnil mezi major verzemi a přežil by střednědobý horizont.

PHP.

[Miloslav Ponkrác]

Od roku 1997, což je možné považovat za začátek doby kdy se PHP/FI přestalo prezentovat jako sada separátních funkcí a přepsalo se do programovacího jazyka není zase tak dávno.

Jazyk D je jen o 2 roky mladší.

[Josef Kufner]

Těch 15 let ale není nijak málo, tedy spíš to je 17, protože PHP2 bylo zveřejněno už v roce 1995. Vlastně je to skoro celá historie webu (první server byl v roce 1990, W3C vzniklo v roce 1993). A v současné době se PHP opravdu masově používá, narozdíl od D.

Btw, C++ vzniklo v roce 1983 a první norma až v roce 1998. Vezmeme-li v úvahu, že tehdy se spolu s tím teprve vynalézalo prakticky použitelné objektově orientované programovaní (první byla Simula v 1967 a Smalltalk je ze 70. let, ale ani jeden z nich se moc nechytnul), tak můžem těch 10 let navíc, co C++ má, v klidu zanedbat, neboť tvůrci novějších jazyků už mají k dobru návod a hromadu zkušeností.

[Miloslav Ponkrác]

„hlavně je gramatika jazyka nezávislá na kontextu“

Jak by řekli v Big Bang Theory: Is that relevant factor?

Mě osobně vůbec nezajímá, jestli kompilátoru parsování jazyka dá víc práce.

Selský rozum mi říká, že jazyk je primárně pro programátory a ne pro ulehčování práce tvůrcům kompilátorů.

Ostatně stejně vzniknul Pascal – Wirth taky navrhoval jak je príma parsování. A pak člověk přemýšlel kde dát středník a kde ne, protože to v duchu taky musel pársovat za kompilátor.

Pokud nějaký jazyk je propagován tím, že se dobře parsuje, dám si k němu automaticky mínus, protože to znamená nedostatek argumentů pro jazyk. A pokud je před to použito ještě slovo „hlavně se to dobře parsuje“, pak palec dolů a dál se tím nezabývám.

To jak bych se choval normálně. Vždy se rozhoduji pouze podle toho, co to pro mě jako programátora znamená, to, jestli se bude parser jazyka dělat tak či onak je mimo moje zorné pole a nezajímá mě to. Navíc jazyk používá milióny programátorů ale jen pár lidí bude psát parser.

Mimochodem, D je asi první jazyk, který nemá nic jako rozdělení řádky typu \

Zato si nezapomněli přidat, že znak 0x00, nebo znak 0x1A, kdekoli se vyskytne ve zdrojáku, ukončí parsing. Opravdu velmi čistý parsing. Skvělý. (Sarkasmus)

Nicméně D znám, a před několika lety jsem ho testoval, zda se nevybodnout na C++ a nepřejít. A velmi rychle mi došlo, že D je jako když pejsek s kočičkou vařili dort. Jsou tam dobré věci, ale nalepené bez rozmyslu. C a C++ jsou daleko konzistentnější jazyky a logičtěji postavené. Just my opinion.

Upřímně, já kdybych překopával C++, přidal bych do něj prvky Ady z hlediska typů a high level věci bych opsal z nějakého high level jazyka. Leccos by dopadlo podobně jako v D, ale zachoval bych vícenásobnou dědičnost.

Navíc D je stále v procesu, že se přeorává, možná někdy v budoucnu bude jasná norma. Pak teprve bude čas na hodnocení. Dokud se stále uvažuje, že nějaké .sort zmizí, je to stále alfa verze jazyka.

Je škoda, že D nevyužil možnosti oproti C++ lépe zpracovat tradiční typy snad kromě fixnutí na konkrétní velikosti.

Vůbec mám pocit, že se řešilo pouze high level.

[Josef Kufner]

Zato si nezapomněli přidat, že znak 0x00, nebo znak 0x1A, kdekoli se vyskytne ve zdrojáku, ukončí parsing. Opravdu velmi čistý parsing. Skvělý. (Sarkasmus)

Tohle má PHP taky, akorát lepší: __halt_compiler().

[Miloslav Ponkrác]

A assembler má často slovo end, za kterým se vše ignoruje.

V TeXu máte \bye.

Stejně tak jako Pascal je vše mezi begin a end a co je za tím se ignoruje.

Ovšem novátorské je použití netisknutelných znaků.

A navíc je to okořeněno tím, že třeba znak 0x00 na začátku zdrojáku být může, to neznamená nutně konec zdrojáku. Tam to může být třeba BOM znak, který to akceptuje.

Fakt vrchol čistoty a promyšlenosti.

[Bystroushaak]

Jak by řekli v Big Bang Theory: Is that relevant factor?

Pro programátora to přeci také znamená usnadnění. Když porovnám šablony v C++ a v D, je to obrovský rozdíl co se týče snadnosti čtení.

Jsou tam dobré věci, ale nalepené bez rozmyslu.

Ne. Ve skutečnosti tam nic takového není a všechno má svůj smysl. V konferencích se vedou diskuze o všem, co se přidává/mění a vše musí být odůvodněné podstatnými argumenty.

Když jsem četl knihu od Andreie Alexandrescu, měl jsem silný pocit osvícení, jelikož vysvětluje prakticky všechno, kde se to vzalo a proč. D tak na mě naopak působí jako úžasně konzistentní jazyk, kde nic není jen tak pro dobrý pocit a nad vším se přemýšlelo.

Nicméně D znám, a před několika lety jsem ho testoval, zda se nevybodnout na C++ a nepřejít.

D před pár lety a D dnes je docela podstatný rozdíl.

Mimochodem, D je asi první jazyk, který nemá nic jako rozdělení řádky typu \

Jak jsem to četl, napadlo mě že je to fakt nevýhoda, ale když jsem se pak snažil vymyslet nějaký příklad kde je to nutné použít, tak jsem na nic nepřišel, takže se rád nechám osvítit.

[Miloslav Ponkrác]

„Pro programátora to přeci také znamená usnadnění. Když porovnám šablony v C++ a v D, je to obrovský rozdíl co se týče snadnosti čtení.“

Ale řeč byla o způsobu parsování.

---

„Ne. Ve skutečnosti tam nic takového není a všechno má svůj smysl. V konferencích se vedou diskuze o všem, co se přidává/mění a vše musí být odůvodněné podstatnými argumenty.“

To ovšem chce úvodní parametr zvaný „jaké budou priority D“. Ono totiž nic není dobře ani špatně, je to jenom jakou zvolíte matematickou optimalizační funkci.

Proto mě překvapuje neustálé šití do C++, protože priritou D rozhodně nemohlo být nahrazení C++, protože D na to nemá parametry ani potřebné featury. Tudíž předpokládám, že prioritou D je něco jiného.

Pro řadu lidí může být D pěkný jazyk, a nebo se jim může strašně líbit – což beru. Ale pokud se D bude prezentovat srovnáváním s C++, tak to prohraje. Ne proto, že by byl špatný, ale protože se instaluje do pozice „toho druhého jazyka“ a jak známo, tahle pozice se strašně špatně obhajuje. Pokud bude D maličko lepší, než C++ hypoteticky, tak to nestojí nikomu za to zabývat se D. Teprve kdyby něčím doslova omráčil zhruba stejným rozdílem jako byl rozdíl mezi C a C++ by D zvítězil.

Myslím, že srovnáváním s C++ si jazyk škodí a možná i proto bude mít problém.

---

„Když jsem četl knihu od Andreie Alexandrescu, měl jsem silný pocit osvícení, jelikož vysvětluje prakticky všechno, kde se to vzalo a proč. D tak na mě naopak působí jako úžasně konzistentní jazyk, kde nic není jen tak pro dobrý pocit a nad vším se přemýšlelo.“

Alexandrescu psal i pro C++. Jeho knihy pro mě byly přínosné, ale jako jeden ze směrů.

---

„D před pár lety a D dnes je docela podstatný rozdíl.“

Principiálně nijak výrazný.

---

„Jak jsem to četl, napadlo mě že je to fakt nevýhoda, ale když jsem se pak snažil vymyslet nějaký příklad kde je to nutné použít, tak jsem na nic nepřišel, takže se rád nechám osvítit.“

Když na tom trváte, já Vám to tedy řeknu: Na to abyste jeden řádek mohl rozdělit do více řádků.

[Bystroushaak]

Když na tom trváte, já Vám to tedy řeknu: Na to abyste jeden řádek mohl rozdělit do více řádků.

To mě samozřejmě také napadlo, ale jaký je konkrétní příklad?

String můžu rozdělit následovně:

string a = "dloooouhy string......................"
           "pokracovani, ktere se mi neveslo na predchozi radek";

Ostatní výrazy lze oddělit prostě pokračováním na dalším řádku.

Možná u názvu superdlouhé funkce? Ale to by byla zase úžasná prasárna. Tak fakt nevím.

[kralyk z abclinuxu]

Afaik v C++ to je dobrý maximálně tak na definici víceřádkových maker, což už je imho samo o sobě prasárna...

[Sten]

Prasárna to být nemusí, běžně se dělá třeba:

#define METHOD(params) \
    doSomething(params, __FILE__, __LINE__)

[kralyk z abclinuxu]

No mně se to nelíbí, ale tak ono to je subjektivní...

Mimochodem, hodnota makra __FILE__ je na kompilátoru, není standardizována (může tam být cesta absolutní, relativní,... je to dost nahouby makro)... Pokud člověk používá například cmake, je lepší něco jako

foreach(i ${my_sources})
  set_property(SOURCE ${i} PROPERTY COMPILE_DEFINITIONS MY_FILE="${i}")
endforeach(i)

a v ostatních systémech obdobně... To jen tak naokraj.

[----]

btw, __FILE__, __LINE___, __DATE__ a __TIME__ jsou v D standardizovány :) Je to dobrý na debugování.

[Sten]

__FILE__ obsahuje cestu, pomocí které kompilátor daný soubor našel, takže pokud na příkazové řádce dostal relativní cestu, je relativní.

Ta property nefunguje správně, protože hodnota __FILE__ odpovídá cestě k aktuálnímu souboru (který může být includovaný).

[----]

"Jak by řekli v Big Bang Theory: Is that relevant factor?"

Samozřejmě že je - závislost gramatiky na kontextu je z hlediska čistoty jazyka špatně, ale hlavně to dost ztěžuje interoperabilitu s tím jazykem z jiných jazyků - je v podstatě nemožné bez celého frontendu C++ kompilátoru podporovat C++ z jiného jazyka, oproti C. Kromě gramatiky závislé na kontextu je toto dáno špatnou specifikací C++ ABI, kde není definován např. name mangling, takže každý vendor si toto dělá jinak. Kromě toho více parsování == pomalejší kompilace.

Ta analogie s Pascalem je naprosto irelevantní - D je syntakticky daleko čistší jazyk než C++ a běžnému uživateli dává daleko více smysl. Jak už dole Bystroushaak zmínil, např. při template metaprogrammingu, což je z velké části dáno i jednoznačně definovanou syntaxí.

"Mimochodem, D je asi první jazyk, který nemá nic jako rozdělení řádky typu \"

Jediné místo, kde se tohle v C/C++ hodilo, jsou makra preprocesoru. V D je to naprosto zbytečné.

"Nicméně D znám, a před několika lety jsem ho testoval, zda se nevybodnout na C++ a nepřejít. A velmi rychle mi došlo, že D je jako když pejsek s kočičkou vařili dort. Jsou tam dobré věci, ale nalepené bez rozmyslu. C a C++ jsou daleko konzistentnější jazyky a logičtěji postavené. Just my opinion."

Aha, před pár lety. Tudíž opravdu aktuální a relevantní informace, že?

"Navíc D je stále v procesu, že se přeorává, možná někdy v budoucnu bude jasná norma. Pak teprve bude čas na hodnocení. Dokud se stále uvažuje, že nějaké .sort zmizí, je to stále alfa verze jazyka."

Nepřekopává se - jazyk je de facto daný v TDPL (ještě se později přidala podpora SIMD a krátké syntaxe lambda funkcí, ale to jsou jen přídavky a nerozbíjí kompatibilitu se starým kódem). Co se týče .sort, to už je deprecated, a má dávno náhradu v knihovně - je tam ZATÍM pro kompatibilitu se starším kódem.

"Vůbec mám pocit, že se řešilo pouze high level."

D je primárně high level jazyk, ale umožňuje systémové programování stejně jako C - existuje kompletní kernel napsaný v D, jen si napsali vlastní minimální runtime.

[Miloslav Ponkrác]

„Samozřejmě že je - závislost gramatiky na kontextu je z hlediska čistoty jazyka špatně“

Ale s prominutím, mně je nějaký hypotetická čistota u kloaky. Bez urážky. Tím to nemyslím zle.

Mně zajímá jediné: Je jazyk praktický? Je jazyk udržovatelný? Má standard a záruky kompatibility do budoucna? Jaké jsou pro něho nástroje?

---

„ale hlavně to dost ztěžuje interoperabilitu s tím jazykem z jiných jazyků - je v podstatě nemožné bez celého frontendu C++ kompilátoru podporovat C++ z jiného jazyka, oproti C.“

To je naprosto správně. Protože podporovat jeden jazyk z jiného znamená ten první zmrvit a očesat a zjednodušit.

---

„Kromě gramatiky závislé na kontextu je toto dáno špatnou specifikací C++ ABI, kde není definován např. name mangling, takže každý vendor si toto dělá jinak. Kromě toho více parsování == pomalejší kompilace.“

Nedefinování C++ ABI = možnost efektivnější kompilace a hledání cesty k efektivnější implementaci do budoucna.

Rychlost kompilace není u C++ ani tak daná syntaxí jazyka, protože parsing je zlomeček toho co kompilátor dělá. Kompilaci spíše zdržují includy, a to díky diskovým přístupům, ale to není věcí toho zda je gramatika závislá na kontextu.

---

„Ta analogie s Pascalem je naprosto irelevantní - D je syntakticky daleko čistší jazyk než C++ a běžnému uživateli dává daleko více smysl.“

Kdybych byl jedovatý, řekl bych, že běžný uživatel moc toho v C++ ani D nenaprogramuje.

Já souhlasím, že C++ má nectnosti, sem tam špinavou syntaxi. Není dokonalé.

Stejně tak jako bude D těsná kamizola, až se standardizuje a po pár letech si autoři začnou rvát vlasy, proč některé featury neudělali maličko jinak.

Ale znovu. Nečistou syntaxi bych kritizoval třeba u Perlu, kde ta prasečina se opravdu blíží write only kódu. U normálně udržovatelné syntaxe běžných jazyků to není nic moc co by mě zajímalo.

[Sten]

Kompilaci spíše zdržují includy, a to díky diskovým přístupům, ale to není věcí toho zda je gramatika závislá na kontextu.

A ty řeší precompiled headers, což je možné právě díky té neexistenci standardizovaného ABI.

[Sten]

D je syntakticky daleko čistší jazyk než C++

No zrovna Déčkové operátory jsou zářný příklad, jak se to dělat nemá.

Jak už dole Bystroushaak zmínil, např. při template metaprogrammingu, což je z velké části dáno i jednoznačně definovanou syntaxí.

V C++ mají šablony taky jednoznačně danou syntaxi A míchání parametrů šablon a funkcí v definicích bych nazval všelijak, jen ne přehledné.

[Josef Kufner]

Ono když se podíváš na jakékoliv složitější použití šablon v C++, tak to má do přehledného daleko. Dokumentace k Boostu obsahuje "pěkných" ukázek hromadu.

[Sten]

To nevyvracím, ale syntaxe Déčka to teda moc nevylepšila, nehledě na to, že spoustu dost podstatných věcí neumožňuje, jako třeba specializaci jinde, než je definice (což je potřeba pro šablonovanou serializaci).

[----]

Samozřejmě že vylepšila; některé věci se dají v D zapsat v polovině kódu v porovnání s C++, syntaxe je čistší a není dvojznačná. Kromě toho, jakákoliv C++ template se dá přepsat v D. Myslím, že Andrei Alexandrescu je jeden z lidí, o kterém se dá říct, že C++ templates opravdu rozumí a zná jejich nedostatky, a ty byly v D opraveny.

[Sten]

No zrovna používání kulatých závorek pro parametry šablon i funkcí IMO dvojznačné je (samozřejmě ne pro kompilátor, ale to není ani v C++).

Specializace v jiném souboru, než je definice, v D na rozdíl od C++ nejde. Podle mě je to bug, podle vývojářů D je to feature.

[----]

Od C++11 lze v C++ zapsat if (x<a<b>>>y<c<d>>) .. to je podle mě dvojznačné. Kulaté závorky jsou OK. Co se týče specializace - vždy se to dá udělat, i když trochu jinak. Vzhledem k tomu, že templates jsou založené na parosvání textu, je to v kombinaci s moduly jasné, že to nejde stejně, jako v C++. Ale věci, jako template mixins apod., tomu dost pomáhají.

[kralyk z abclinuxu]

s/ke vždy na stacku/je vždy na stacku

[spam]

Thanks for this great post, I find it very interesting and very well thought out and put together. I look forward to reading your work in the future custom cabinets des moines

[spam]

Awesome! Learned alot thanks so much keep posting more. breastaugmentationclevelandoh.com

[spam]

Awesome! Learned alot thanks so much keep posting more. vancouver wa wedding videographer