Programovací jazyk D

14.3.2011 19:34 | Přečteno: 4173× | Názory | poslední úprava: 7.10.2012 20:38

Nudil jsem se, tak jsem sepsal něco o programovacím jazyku D. Není to ani tak článek o D, jako spíš můj názor na něj a ostatní programovací jazyky.

Před pár lety, když jsem ještě chodil na střední školu nám mistr na praxi vyprávěl o tom jak před dlouhou dobou dělal pro nějakou rodinu elektriku v baráku. Jelikož byl poctivý řemeslník, rozuměl své práci a odvedl jí dobře, pozvali ho na kafe a povídali si s ním. Tenkrát ho zaujalo, že měli uprostřed obýváku na zemi položený velký a dlouhý trám, který všichni přeskakovali a dělali jako kdyby tam nebyl. Nejdříve se na to ze slušnosti nechtěl zeptat, ale jelikož to byl zvídavý člověk, vrtalo mu to hlavou a nakonec neodolal a vznesl dotaz proč že to mají ten trám uprostřed obýváku, když jim tam překáží. Dostalo se mu odpovědi že už tam tak ležel když dům někdy před dvaceti lety koupili. Bylo mu to trochu divné, tak se zeptal proč ho nikdo z nich neodstranil. "My ho tam nedali," řekla mu paní domu a brala celou věc za vyřízenou.

Nevím nakolik je tenhle příběh pravdivý a nakolik si ho mistr tenkrát vymyslel, ale úplně stejné mi to přijde s programovacími jazyky. Existuje 1337 programovacích jazyků, jeden dementnější než druhý. Více/méně všechny široce používané si s sebou táhnou podivné dědictví různých trámů, které jsou navršené v obývácích a nutí programátora je podlejzat, přeskakovat a snažit se aby náhodou nějaký neshodil. Často se přitom nejedná o nic jiného, než o dementní syntaxi, kterou by šlo lehce vyřešit, kdyby se ovšem někomu chtělo daný trám odnést a poslat do prdele členy rodiny kteří si budou stěžovat že bez něj to už není ono.

Je opravdu obdivuhodné, že jednou za čas se mezi tvůrci najde někdo, kdo dokáže myslet trochu jinak než většina a odstranit většinu trámů, ba co víc, dokonce ještě vybílit zdi a přidat pohodlnou sedací soupravu, na které je vskutku radost sedět. Mezi tyto tvůrce patří kromě Guida van Rossuma (tvůrce jazyka python) i Walter Bright.

C++ fucking sucks

Na začátku jsem se naučil pascal. Byla to doba kdy jsem na programování měl jen jeden názor - fuck yeah! Později jsem nakousl PHP, naučil se python, absolvoval rok basicu, dva roky středoškolské výuky s C++, dva semestry vysokoškolských kurzů javy, semestr C/C++, semestr JavaScriptu/PHP a semestr C#. Během té doby jsem si škrtl i o různé obskurní jazyky, ale většinou se jednalo o věci které ani nemá cenu zmiňovat a už jsem je prakticky zapomněl a navíc si procvičoval dovednosti snad ve všem, kromě pascalu. Pokaždé když jsem v té době měl vytvořit nějaký kompilovaný program, připadalo mi, že cokoliv v čem bych ho dokázal napsat stojí za naprostou vyližprdel. Bylo to jako kdybych si zkoušel kabáty a žádný mi nesedl. V jednom jsem mohl nemohl roztáhnout ruce, ve druhém je zase dát k sobě a třetí se nedal dopnout.

Během té doby jsem strávil několik večerů hledáním na netu. Na IRC se mi smáli, že dokonalý jazyk neexistuje, že nemá cenu se namáhat, ale stejně jsem googlil a zkoušel. Když už jsem byl jen kousek od toho to vzdát, vzpomněl jsem si, že kdysi dávno, když jsem byl ještě totální IRC nováček, vyskytoval se na mém prvním kanálu člověk pod nickem DarkCraft, který si pochvaloval D. Trochu jsem zagooglil a zjistil jsem, že zrovna před nedávnem vyšla revoluční, druhá verze - D2.

Pustil jsem se do čtení a zjistil jsem, že Walter Bright měl podobný názor jako já - C++ smrdí. Nezískal ten názor tím že by si ho zkusil na střední/vysoké škole, ale poté co pracoval dlouhá léta jako programátor a mimo jiné si napsal vlastní, komerčně úspěšný kompilátor C++. I ten největší C++lover snad musí uznat, že nejspíš věděl o čem mluvil. Walter si uvědomil, že C++ má pošahanou syntaxi a navíc programátorovi hází trámy pod nohy, proto se rozhodl vytvořit nový, lepší jazyk. Jelikož se jeho firma jmenovala DigitalMars, pojmenoval jej Mars. S tím jak se komunita jazyka Mars rozrůstala, začali se objevovat lidé, kterým se jazyk líbil a začali ho místo Mars nazývat prostě D, aby dali najevo že se jedná o něco lepšího jak C++. Postupně se tento název ujal natolik, že i samotný Walter ho přijal za vlastní a v dnešní době už se na původní jméno prakticky zapomnělo.

D

Jazyk D je systémový, kompilovaný programovací jazyk. Je to také jediný kompilovaný jazyk ve kterém mě skutečně baví programovat, podobně jako třeba v pythonu. Žádné kreténské .h soubory, rozdíly mezi definicí metody v těle třídy a za třídou, dementní stringy, couty a ciny, makra jak ze středověku a podivné erorry při používání šablon. Naopak - spousta vychytávek jako jsou asociativní pole, pohodlné foreach, moduly, ucházející API, porovnávání polí operátorem porovnání (==), nikoliv pomocí obskurních metod z jakéhosi API, vlastní operátor pro porovnání referencí (is), operátor pro spojování polí a strigů (~), plná podpora UTF atp..

Nevím jak bych měl tento pocit z D přiblížit někomu kdo v něm nikdy nedělal, proto se prostě budete muset spokojit s tím, že o něm prohlásím že je skutečně příjemný a promyšlený, s minimem trámů které by bylo třeba přeskakovat a podlejzat. D mě baví - proto jsem o něm založil české stránky a napsal tento článek.

Pokud se mi podařilo navodit ve vás pocit že D není úplně marný, zkuste se podívat na czwiki4d, popřípadě další odkazy které jsem uvedl:

• czwiki4d [cz] - mé stránky obsahující české informace o D, jedná se o dokuwiki, takže pokud má někdo zájem, můžu mu zřídit účet
• Programovací jazyk D - Wikipedie [cz] - záznam na české wikipedii, přidával jsem tam nějaké ty informace, ale stejně se z toho nic moc nedozvíte
• Programovací jazyk D [cz] - jakýsi studentský projekt obsahující slajdy a nějakou dokumentaci, bohužel 4 roky neaktualizovaný..
• D Programming Language - Digital Mars [en] - oficiální stránky jazyka, dokumentace, diskuzní fóra, maillisty, tipy a triky, bugtrack atp..
• D (programming language) - Wikipedia [en] - velice podrobná stránka na anglické wikipedii, doporučuji!

Heh, "závěr"

Na závěr bych se chci zmínit o excelentní knize The D programming Language. Dá se sehnat i v elektronické verzi (oficiálně i neoficiálně), osobně jsem si koupil k vánocům papírovou. Četl jsem už několik knih o programování a programovacích jazycích (mimo jiné třeba Programovací jazyk C od Kernighana a Ritchieho), ale žádná mě ani zdaleka nenadchla tak jako tato.

Rozdíl mezi touhle knihou a běžnými příručkami je asi takový, jako mezi čerstvě vystudovanou učitelkou češtiny která u nás ve čtvrťáku po půl roce vyhořela (prý odešla radši učit na mateřskou školku) a pánem v důchodu, který nastoupil po ní. Nejen že dokázal podat češtinu zajímavým způsobem (!!!), ale navíc to pro něj byl koníček a uměl vysvětlit i kde se to v našem jazyce vzalo, proč to vzniklo a jak se to rozšířilo..

       

Komentáře

[ocaL]

Až na to někdo naportuje Qt4, tak možná, ale takhle je mi to čistě prakticky úplně k hovnu

[Bystroushaak]

Teď se pustím na tenký led, ale nemá náhodou Qt4 nějaké C knihovny? Pokud ano, D umí používat C ABI a pokud se ošklivě nepletu, tak i API (jen je nutné předělat .h soubory na interface).

[ocaL]

No já jsem hlavně zřejmě trubka - QtD

[kralyk z abclinuxu]

Je otázka, jak moc to je/není aktuální.

[Kemr]

Qt 4.5 a skoro rok na to nikdo nešáhl...

[____]

Qt je moc založené na C++ na to, aby se dalo exportovat do C.

[Polivka]

To by bylo odporny, vsechny ty zavislosti na tride QObject apod. poceckovat. Na cecky az moc velka abstrakce...

[____]

Viděl jsi někdy GObject, který leží pod GTK+?

[Polivka]

Právě že jo

[pozortucnak]

Viděl jse zdrojové kódy qt4pas? Není to sice kompletní Qt framework...

I se svými chabými znalostmi C/C++ mám odvahu tvrdit, že je to čistý C wrapper...

http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html

[____]

A já tvrdím, že je to mimo, protože jsem tam žádné zdrojové soubory čistě v C nepotkal.

[pozortucnak]

No dobře, tak je to C/C++ wrapper...

Co asi znamená

C_EXPORT QLabelH QLabel_create(QWidgetH parent, unsigned int f)
{
	return (QLabelH) new QLabel((QWidget*)parent, (Qt::WindowFlags)f);
}

?

Myslím že tuto funkce bych teoreticky mohl použít v C, ale jak jsem již psal, mé znalosti C/C++ jsou skutečně chabé...

[ocaL]

Jinak, nic nemá na Ruby, jeho syntakticky čisté konstrukce jako "5.times { ... }" nic nepřekoná...

[Bystroushaak]

Hm, kdyby ruby nemělo bloky ukončené naprosto dementním klíčovým slovem end, tak bych i souhlasil že je to jazyk který stojí za to se učit, takhle jsem spíš pro python.

Jinak v pythonu to jde do jisté míry pomocí *, například print 5 * "xe", na složitější věci je podle všeho nutné používat xrange.

[Lumen]

To ukončení bloku klíč. slovem end nebo slož. závorkou } je IMHO velký plus pro vizuální orientaci v kódu. V Pythonu mě naopak to neoznačení s*re, protože se lze při víceúrovňovém vnořování snadno splést v odsazení a jinak validní kód se chová jinak než autor zamýšlel.

Jinak v pythonu to jde do jisté míry pomocí *, například print 5 * "xe", na složitější věci je podle všeho nutné používat xrange.

Tak tady jste zcela mimo mísu. Nejdřív si přečtěte co metoda Fixnum#times dělá. Ta je pythonnímu list.__mul__ na hony vzdálená.

[____]

Dokud v editoru nejsou vodící linky či jiná pomůcka s obdobnou funkcí, orientace je v tahu v obou případech. Mně se zase nelíbí, že explicitní ukončování bloků kód vertikálně prodlužuje a rozptyluje pozornost.

Nakonec, slyšel jste někdy něco o tom, že kód, který potřebuje více než tři úrovně odsazení, je špatně napsaný? Chcete-li, můžete si tuhle poučku rozšířit na čtyři úrovně, protože v OOP bývá ještě jedno odsazení navíc pro třídu.

[Lumen]

Dokud v editoru nejsou vodící linky či jiná pomůcka s obdobnou funkcí, orientace je v tahu v obou případech.

Nesouhlas. Když píšete nový kód, tak jsou oba případy srovnatelný. Pokud se ale ke kódu vracíte, za účelem doplnit/opravit, tak v Ruby se hned chytíte toho ukončujícího end nebo }, ale v Pythonu musíte znovu pátrat po odsazení ukončující blok jako na začátku.

Nakonec, slyšel jste někdy něco o tom, že kód, který potřebuje více než tři úrovně odsazení, je špatně napsaný? Chcete-li, můžete si tuhle poučku rozšířit na čtyři úrovně, protože v OOP bývá ještě jedno odsazení navíc pro třídu.

To nelze brát úplně doslova. Stejně jako že funkce nesmí být delší než jednu stránku v editoru. Praxe je ale trošku o něčem jiném a slepě dodržovat takové poučky může vést ke zbytečnému tříštění kódu. Tyto poučky jsou hlavně pro začátečníky, aby je vedly k určité disciplíně a nenaučili se hned prasit.

[____]

Nesouhlas. Když píšete nový kód, tak jsou oba případy srovnatelný. Pokud se ale ke kódu vracíte, za účelem doplnit/opravit, tak v Ruby se hned chytíte toho ukončujícího end nebo }.

Nesouhlas. Pouze pokud editor vysvicuje přiléhající závorky nebo vyznačuje bloky (např. kate).

To nelze brát úplně doslova. Stejně jako že funkce nesmí být delší než jednu stránku v editoru. Praxe je ale trošku o něčem jiném a slepě dodržovat takové poučky může vést ke zbytečnému tříštění kódu. Tyto poučky jsou hlavně pro začátečníky, aby je vedly k určité disciplíně a nenaučili se hned prasit.

Lze to brát doslova, co by to nešlo. :) A pochybuju, že autor poučky o odsazení měl na mysli začátečníky, když v té době byli programátoři spíše okrajová sekta lidí. Jde spíše o obecně dobrou praktiku, která stojí za dodržování nezávisle od toho, jak dlouho kdo na jaké úrovni programuje.

[rADOn]

… Pokud se ale ke kódu vracíte, za účelem doplnit/opravit, tak v Ruby se hned chytíte toho ukončujícího end nebo }, ale v Pythonu musíte znovu pátrat po odsazení ukončující blok jako na začátku.…

Někteří nepátrají, ale prostě kouknou na #endif, #endfor etc. blok. Jak složité… Apropo, mě se líbí jak střídmost a přehlednost C, tak ukecaný ale vypovídající koncový bloky v php. Ale holý  end mi přijde jako to nejhorší z obou - víc písmenek aniž by v tom bylo víc informace

Tyto poučky jsou hlavně pro začátečníky, aby je vedly k určité disciplíně a nenaučili se hned prasit.

Zlatá slova. Ale neříkej je moc nahlas, začátečník může být nablízku

[____]

Pokud to je ironie, tak ji beru.

[ocaL]

Díky za argument. Málokdo umí tolika slovy říct tak málo (resp. nic)

[____]

Mně Ruby přijde syntakticky naprosto odporné, o něco víc než Perl.

[Lumen]

Jj, není potřeba se rozhodovat jen podle racionálních důvodů …

[____]

Dobře, ještě jinak: špatně se to čte.

[xxx]

Asi takhlen, vsechny tyhle vychytavky jsou super. Dokud programujete sam. Prusvih tehlech veci je, ze nejaky problem (i trivialni) lze vyresit prilis mnoha zpusoby. Takze v momente kdy dostanete cizi kod, tak zabijete spoustu casu tim, ze se ucite coding style vaseho predchudce.

Dlasi sranda nastava v okamziku, kdy jste program pochopili, a chcete ho modifikovat. Pokud to udelate vasim stylem, a ne tak jak vas predchudce, tak jste prave prichystal peklo pro vaseho nastupce.

Takze prvni co u tehlech nestriktnich jazyku udelate pri nutnosti spoluprace vice lidi je, ze vychytavka jako 5.times zakazete, nebo zakazate vsechny ostatni metody pro dosazeni stejneho cile.

[Bystroushaak]

A nebo zavedete nutnost komentovat potenciálně nepochopitelné bloky projektu?

[xxx]

To nefunguje. Kazdy ma to potencionalne nepochopitelne nekde jinde. A pokud ma programator osvojenou nejakou specialitku (5.times misto for, kazdemu dojde, ale jsou mnohem zakernejsi vychytavky), tak to bude presne to, co mu prijde jako uplne jasne, a komentovat to rozhodne nebude.

Tenhle problem maji samozrejme vsechny jazyky, ale cim volnejsi jazyk je, tim vetsi tenhle problem je.

[JS]

Prusvih tehlech veci je, ze nejaky problem (i trivialni) lze vyresit prilis mnoha zpusoby. Takze v momente kdy dostanete cizi kod, tak zabijete spoustu casu tim, ze se ucite coding style vaseho predchudce.

A on tenhle problem nejaky jazyk uspesne resi? Respektive, je ten problem vubec resitelny?

Mozna reknete Java. A ja reknu, ze Java jen ten problem premistila ze zabudovane syntaxe/semantiky programovaciho jazyka do patternu a frameworku.

IMHO, ten problem je v Turing-complete jazycich neresitelny.

[kralyk z abclinuxu]

Uznávám, že mnohé věci jsou v C++ řešeny divně, nešikovně nebo úplně chybí.
Nadruhou stranu porovnávat pole jedním operátorem mi přijde hovadina. Schovává se v tom složitost - je to jediný příkaz, ale přitom má složitost jako for. Krom toho, různé druhy polí se různě porovnávají...

Ale nejsem zas nějaký C++ fanatik a D bych klidně zkusil. Už jsem po něm párkrát pokukoval, stejně jako po Objective-C.

[Ladicek]

Nadruhou stranu porovnávat pole jedním operátorem mi přijde hovadina. Schovává se v tom složitost - je to jediný příkaz, ale přitom má složitost jako for.

Složitost se schovává už v takových věcech, jako je alokace paměti. Takže na rozumných polích nevidím nic špatného.

Ostatně tenhle argument by se dal použít proti jakémukoli přetěžování operátorů, tedy i vůči C++, pravda?

[kralyk z abclinuxu]

U alokace se přímo udává velikost, u C++-style alkoace (new typ[velikost]) to je vůbec hezky vidět, takže tam bych problém neviděl.
A přetěžování operátorů si člověk píše sám, takže taknějak ví, co dělaj...

[Ladicek]

Narážím na úplně jinou věc, totiž že alokátory paměti typicky nemají konstantní složitost. (Paradoxně neplatí pro řízená prostředí typu Java, ale to je teď vedlejší.)

No, takže tady to víš taky, není rozdíl.

[qiRzT]

Složitost se schovává už v takových věcech, jako je alokace paměti.

Mezi složitostí za alokací paměti a složitostí při porovnávání pole je propastný principeilní rozdíl.

Takže na rozumných polích nevidím nic špatného.

Ostatně tenhle argument by se dal použít proti jakémukoli přetěžování operátorů, tedy i vůči C++, pravda?

Taky na tom nevidím nic špatného, ale nebylo lepší jazyk navrhnout s dobrým mechanismem pro přetěžování operátorů a tuhle funkčnost udělat až v samotném jazyce?

[Ladicek]

Ten propastný principielní rozdíl mi vysvětli. Skrývá se tam složitost nebo ne? To je jediný přednesený argument.

[qiRzT]

Jednou je složitost daná algoritmem, podruhé tím, že to vede na syscall, který obsluhuje operační systém, čili jednou je to složitost algoritmu, podruhé programu. V prvním případě může programátor přmýšlet nad tím, jak a jestli vůbec operaci provést, v druhém pouze jestli ji provést nebo ne.

[Ladicek]

Ono to nevede ani tak na syscall (tedy ne přímo a zdaleka ne vždycky), jako spíš do standardní knihovny. Stejně jako to porovnání polí. Obojí se dá pro konkrétní problém, kde není potřeba obecné řešení a stačí něco specifičtějšího, reimplementovat.

A existují mimochodem modely pro analýzu složitosti, které s tím počítají, takže to rozlišení bych bral s rezervou.

[qiRzT]

OK, dobře, asi ten rozdíl není tak propastný, ale pořád je v tom, že jednou ta složitost vychází z podstaty problému, podruhé z technických prostředků použitých pro realizaci programu.

[Ladicek]

Já to beru, pokud jsi jeden z těch, kdo tvrdí, že algoritmy nejsou od toho, aby se spouštěly, ale od toho, aby se dokázala jejich správnost

[qiRzT]

Myslím, že algoritmy jsou k obojímu

[Ladicek]

Jo, k těm operátorům: Přetěžování operátorů v D je a pokud teď dobře koukám do zdrojáků, tak je porovnávání polí skutečně implementováno v knihovně.

[Martin Petr]

C++ sice fucking sucks, to je svatá pravda, ale na rozdíl od D jej někdo používá.

[Polivka]

Konformní ovčan alert!

[Martin Petr]

Když už něco "nového", tak Haskell, Erlang, Lisp, i když i z toho už jsem vyrostl. Na D nic nekonformního nevidím, kromě té okrajovosti tedy.

[Bedňa]

Keď už niečo iné ako c++, tak u++, D je fajn, ale kvalitu návrhu u++ ťažko niečo porazí.

[pc2005]

ad python, ono to povinné odsazování bloků zrovna programování nezrychluje.

Jinak s tím, že by stačilo upravit parser a syntaxe by se skokově zvýšila souhlasím. Takové VHDL by to potřebovalo jako sůl.

U toho jazyka D na wikipedii se mi líbí zápis funkcí pro různé typy parametrů, ale nějaký klíčový slova se mě moc nelíběj (imho bych taky pak měl problém, kdybych psal třeba v pure C ).

Mě osobně připadá vrchol elegance perl bez referencí. Tam jde program zapsat brutálně úsporným způsobem. Teprve u těch referencí se už začíná objevovat ne moc hezká syntaxe. Ale pořád se to ještě dá.

[Bystroushaak]

VHDL by potřebovalo zapomenout a znova vymyslet, tentokrát dobře..

[pc2005]

+1. Nejlepší pak je když člověk píše v Xilinxáckým softu hardware i software a software má všechny výhody eclipse a hardware má tak maximálně editor na úrovni notepadu.

[poky74]

Musím souhlasit, právě dělám na jednou hodně velkém projektu, který je právě v D, návrh toho jazyka je opravdu dobrý.

Rozhodoval jsem se, jesti to napsat v C nebo D, vsadil jsem na garbage collector a času to uspoří opravdu hodně.

Dčku fandím, pokud by v budoucnu byl čas, rád bych se zasloužil o nějakou českou dokumentací, snad se někdy ozvu ohledně pomoci an té wikině

[Lumen]

Viděl jsem budoucnost a ta patří funkcionálním jazykům typu Haskell nebo Erlang. D je jen další z nekonečné řady variant "vylepšené, zjednodušené C/C++", ale stále svázané všemi důsledky imperativního paradigmatu. Referenční transparentnost k eliminaci chyb v čím dál komplexnějším software, snadnost paralelizace s masivním nástupem vícejádrových procesorů - na to nemají imperativní jazyky odpověď.

Kdo pochybuje o "reálné praktičnosti" čistě funkcionálního jazyka jakým je třeba Haskell, ať zavítá např. na Hackage a možná změní názor.

Mimochodem implementace GHC nabízí jak interpretr pro snadné prototypování tak výkonný kompiler do nativního strojového kódu, který co do efektivity překvapivě moc nezaostává za GNU gcc (rychlost běhu i paměťové nároky - cca dvojnásobek).

[Bystroushaak]

Sure, naprogramuj mi v tom ovladač hardware, nebo operační systém. Tj totiž to, co se v D dá pořád docela v pohodě udělat.

[Radek Miček]

Existuje operační systém House, který je napsán v Haskellu. Dialekt Haskellu zvaný Habit se mj. zaměřuje také na systémové programování.

[Bystroushaak]

Ok.

[:::]

a me v tom naprogramuj nasobeni matic 1000x1000...

btw. da se takova matice v haskellu vubec nejak *efektivne* representovat? (tj ne pomoci spojovyho seznamu)

[Radek Miček]

Haskell má pole.

[Lumen]

Nevím co si představuješ pod efektivně, ale haskell má už celkem dlouho modifikovatelná pole, která jsou implementačně velmi podobná polím např. v C. Viz. článek o výkonných polích na haskell.org .

Mimochodem na násobení matic o 1e6 prvcích typu Double bohatě stačí ty "neefektivní" spojové seznamy. Pokud to teda není v nějaké kritické smyčce, kde záleží na každém taktu CPU.

[:::]

Nevím co si představuješ pod efektivně, ale haskell má už celkem dlouho modifikovatelná pole, která jsou implementačně velmi podobná polím např. v C. Viz. článek o výkonných polích na haskell.org .

zajimavy, ale pouziva to monady, takze by ses v podstate musel "prepnout z haskellu" a naprogramovat to imperativne... Ale samozrejme lepsi nez nic...

Mimochodem na násobení matic o 1e6 prvcích typu Double bohatě stačí ty "neefektivní" spojové seznamy. Pokud to teda není v nějaké kritické smyčce, kde záleží na každém taktu CPU.

no to nasobeni matic se obvykle pouziva pri simulacich a je potreba je opakovat hodnekrat... ale i kdybys mel pocitac kterej to zvladne dost rychle pri implementaci spojovym seznamem tak to neznamena ze by to nebyla mega prasarna... ;)

[Radek Miček]

zajimavy, ale pouziva to monady, takze by ses v podstate musel "prepnout z haskellu" a naprogramovat to imperativne... Ale samozrejme lepsi nez nic...

Při násobení matic si vystačíte s poli, která se nemění, takže monádu používat nemusíte. Ještě dodám, že lepší balíček pro pole je vector.

[Ladicek]

Viděl jsem minulost a ta říká, že lidi, kteří tvrdí, že viděli budoucnost, jsou lháři

[____]

Viděl jsem budoucnost a řekl jsem si, že už je na čase přestat fetovat.

[petko]

Ja po tom poskulujem uz dost dlho, ale v poslednej dobe ma zaujalo mono a c#. Nezere to tolko pamate ako java, aplikacie rychlo startuju+da sa zbavit JITovania pri kazdom behu aplikacie a oproti D to ma tu vyhodu, ze je okolo toho cela .net komunita (kniznice atd.).

[Bystroushaak]

Určitě, C# má spoustu výhod, ale chce .net (mono), tedy několikasetmegabajtovou (tak tohle slovo bude skoro určitě napsaný blbě :P) obludu. Jazyky jako C/C++/D tuhle potřebu nemaj.

[____]

Rozhodně se nejedná o "několik set megabajtů." Koukám se na Mono v Archu, nainstalované chce 140 MiB. Kdyby se ti to zdálo hodně, připomeň si, kolik dnes stojí jeden gigabajt. Na Windows je pak .Net v současnosti prakticky standardní součástí systému, tak o velikosti ani nemá smysl rozmýšlet.

Jazyky jako C/C++/D si prozměnu tahají jiné obludy, pokud se nejedná o triviální projektíky. Jaký je v tom rozdíl? Pokud se na to podívám z určitého úhlu, .Net přináší do Windows alespoň část výhod centralizovaných balíčků. Podstatná část toho, co by programátor kdy chtěl, je uložená v rozsáhlé system-wide knihovně.

[Bystroushaak]

Tahají si obludy (make, automake a bůh ví co), ale na straně programátora. Přijde mi poněkud blbé říct uživateli - nainstaluj si náš shit a zaser si jím systém. Operační systém si v něm taky tak nenapíšeš.

Jinak já jsem v C# dělal a dost se mi líbilo, jen je to prostě jiná kategorie, podobně jako třeba java.

[____]

Jestli přemýšlíš o svém software a jeho závislostech jako o sračce, bude asi něco špatně.

Částečně napíšu — Singularity. Jakmile se v něčem na nižší úrovni povede vytvořit infrastrukturu exportující nejnutnější API do chráněného prostředí vyššího jazyka, je vyhráno

[petko]

Ano ale otazne je, co v tom D uz mas. Zakladne mono ma podla ich stranky 3.7 MB. To je skoro nic ked si zoberes, ze to je velkost jednej mensej fotky. Zober si kolko MB potrebuje taka Qt bez GUI (+vsetky zavislosti) a pamatovo nie je na tom lepsie. Ked zacnes k D zhanat nejake kniznice, tiez to bude cez niekolko mega (a mozno sa mylim, ale neverim ze nie).

[Let_Me_Be]

D nevzniklo proto protoze se v C++ blbe programuje, ale proto ze se pro C++ blbe programuje kompilator. Proto vznikl jazyk D, pro ktery se dobre dela kompilator (podobny zamer ma i GO).

Hezke na tom je to ze pak je mnohem jednodussi delat komplexni optimalizace. Horsi je to obvykle s navrhem samotneho jazyka, ktery to obvykle odnese slabymi vyrazovymi prostredky nebo desnou syntaxi.

Jinak trochu mi unikaji vytky smerem k C++, vsechno co si popsal v C++ je.

[Bystroushaak]

Pravda. Možná jsem to nenapsal úplně jasně, uznávám že z věty

Walter si uvědomil, že C++ má pošahanou syntaxi a navíc programátorovi hází trámy pod nohy, proto se rozhodl vytvořit nový, lepší jazyk.

není úplně jasné že mu to došlo při psaní kompilátoru (který se programuje blbě hlavně kvůli té syntaxi).

[Bystroushaak]

Jinak trochu mi unikaji vytky smerem k C++, vsechno co si popsal v C++ je.

Tím myslítš ty výhody D? Ano, je to tam, ale není to pohodlné.

Jinak možná je to dané mojí nevědomostí, zkus popsat nějaké konkrétní příklady.

[Let_Me_Be]

Nejake konkretni priklady nepohodlnosti?

Kdyz z toho vytahnu napriklad to porovnavani poli tak to prece jde uplne normalne:

valarray<int> x,y; if (x == y) {}

Sice nemame is, ale ty dva znaky navic urcite nikoho nezabiji:

int x; int &y = x, &z = x; if (&y == &z) {}

[Bystroushaak]

Jo, v D se to dá udělat i takhle. Nedělá se to tak, protože to je pěkně na hovno - přehlednost to má jinde než

int[] x, y; if (x == y) { .. }

popřípadě

if (x is y) { .. }

O nějaké intuitivitě nejspíš taky mluvit nejde. Nechápu proč se proti tomu nebouří víc lidí. Osobně cítím silnou potřebu věci vylepšovat, nářadí si taky upravuju podle sebe aby se mi s ním pohodlně pracovalo, celý životní prostor okolo mě vylepšuju aby byl pohodlnější, praktičtější, tak proč ne programovací jazyk?

[Mrkva]

Však ale

if (&x == &y)

dělá přesně to, co je napsané v kódu, tedy porovnává adresy. Stejně jako

if (x is y)

ale z tohohle to není až tak zřejmé.

[Bystroushaak]

No, vždyť já tvrdím to samé. Jasné to je každému, kdo ví co dělá operátor is, tedy že porovnává reference (adresy objektů a vůbec všeho).

[qiRzT]

Stejně můžeš říct, že if (&x == &y) je jasné každému, kdo ví, co dělá operátor &.

[Bystroushaak]

Vždyť já netvrdím opak, pouze že je to méně přehledné (různé operace nad pointery bývají občas pěkně divoké).

[qiRzT]

Zrovna tohle je IMHO otázka zvyku a vkusu.

(různé operace nad pointery bývají občas pěkně divoké).

To jo (když se přidají pointery na funkce, je to dobrej zmatek), ale to není tenhle případ.

[Let_Me_Be]

Problem je v tom, ze lide se pro svoje pohodli vzdavaji dulezitych vlastnosti.

Mozna mi neco unika, ale fakt nevidim zadny fatalni rozdil mezi valarray<int> x; a int[] x;. To same plati pro if (&x == &y) a if (x is y). is je uznavam intuitivnejsi/citelnejsi, ale rozdil je minimalni. Pokud nekdo nerozumi &x == &y tak neovlada ani zaklady Cecka.

[Bystroushaak]

Jakých důležitých vlastností? D pointery podporuje, ale snaží se od nich programátora odstínit, pokud to není nutné. Fatální rozdíl v tom samozřejmě není, ale je to rozhodně méně přehledné.

[pht]

Mně přijde zbytečné zavádět na to 2 separátní operátory. Tam, kde mi to je putna, což je většina případů, mi stačí normální porovnání objektů (a to zahrnuje i případ kdy porovnám objekt se sebou samým).

if (x == y) ...

Tam kde mi záleží na tom, jestli jsou stejné adresy v paměti tak můžu použít něco jako

if (x.getAddress() == y.getAddress()) ... 

S tímhle je ten program čitelný i bez toho abych vůbec potřeboval znát nějaké is.

[Bystroushaak]

Nic přímo proti vám, ale co mají všichni proti is? Je to jeden operátor, jehož funkci si dokáže zapamatovat pravděpodobně i retardovaný žák základní školy pro "speciální" děti. Vážně to není tak složité jak to zde zřejmě mnohým připadá. Zvyšuje přehlednost, což se o použití operátoru reference a použití metody říct nedá.

if (x.getAddress() == y.getAddress()) ...

Tohle je přesně ten trám o kterém jsem psal - místo dvou písmen is budu psát 6x delší název metody, navíc dvakrát. Vizuálně to prostě přehlednější není.

[qiRzT]

Já to vidím asi takle - každý objekt múže mít mraky vlastností, které chceme porovnávat. Identita je jen jednou z nich. Budeme pro každou zavádět nový operátor? Mě prostě přijde zbytečný. Kdejaký editor umí automaticky doplňovat, takže s tím psaním navíc to nevidím tak strašně. Krom toho, pokud x a z jsou objekty, tak stačí přetížit operátor == a je to skoro totéž. Nebo si napsat metodu is.

C++ má mnoho trámů, ale tohle mi přijde jen jako syntactic sugar, nic zásadního.

[Bystroushaak]

D porovnává operátorem is libovolné reference, nikoli jen objekty. Operátor is můžete použít u polí/stringů/objektů/struktur/whatever.

Jinak syntactic sugar .. pro mě jako pro programátora je zásadní jen minimum parametrů jazyka a hlavně syntactic sugar. Kdyby na syntaxi nezáviselo, mohl bych to klidně programovat rovnou v asm, nebo třeba v C a vytvářet si tam vlastní objekty (struktury obsahující data a pointery na fce).

Syntaxe šetří můj čas a nervy. Když mám číst zdroják v D, čtu ho. Když mám číst C++, musím ho luštit.

[xxx]

Jinak syntactic sugar .. pro mě jako pro programátora je zásadní jen minimum parametrů jazyka a hlavně syntactic sugar.

Číst kód po lidech, kteří si libují v "syntactic sugar" je často dost utrpení.

[Bystroushaak]

I pokud je syntactic sugar běžně používanou a k tomu použití vymyšlenou součástí jazyka?

[qiRzT]

D porovnává operátorem is libovolné reference, nikoli jen objekty. Operátor is můžete použít u polí/stringů/objektů/struktur/whatever.

To ale právě dělá i zápis &x == &y, což je, stejně jako x is y, triviální výraz. Míra přehlednosti je IMHO v tomhle případě zcela subjektivní.

Jinak syntactic sugar .. pro mě jako pro programátora je zásadní jen minimum parametrů jazyka a hlavně syntactic sugar. Kdyby na syntaxi nezáviselo, mohl bych to klidně programovat rovnou v asm, nebo třeba v C a vytvářet si tam vlastní objekty (struktury obsahující data a pointery na fce).

Minimum parametrů - co to znamená? Mezi assemblerem a C je větší rozdíl než jen to, že se v C snáz píše. C poskytuje větší abstrakci. Pokud ten operátor is dělá totéž jako &x == &y, tak další abstrakci nepřináší. Podobně jako operátor pro celočíselnou mocninu nepřináší žádnou další abstrakci oproti násobení. Jen zjednodušuje zápis.

Nesnažím se hájit C++, nedostatků má dost (např. - matně si vzpomínám, že mi nešlo udělta nějakou operaci se šablonama, která mi přišla naprosto logická - nějak to souviselo s tím, že šablony jsou takový chytřejší makra, ale přesně už si to nepamatuju.). Jednoduchá syntaxe je samozřejmě přínos, ale zrovna tohle mi přijde nezajímavý. Spíš jako bys k tomu trámu jen přidal schůdky.

[Bystroushaak]

To ale právě dělá i zápis &x == &y, což je, stejně jako x is y, triviální výraz. Míra přehlednosti je IMHO v tomhle případě zcela subjektivní.

To na co jsem reagoval byla ta metoda getAdress - jinak souhlasím že je to subjektivní, v tomhle případě se nejedná o nic jiného než syntaktický cukr.

Tím minimem jsem myslel třeba rychlost, velikost binárky, garbage collector, objektový model a to zdali je k dispozici opensource překladač a pro jaké architektury. V podstatě nevím co dál by mě mělo na jazyku zajímat, kromě syntaxe.

[Ladicek]

Abych parafrázoval: Když si odmyslím implementační vlastnosti a sémantiku, nevím, co dál by mě mělo na jazyku zajímat kromě syntaxe. Což je samozřejmě pravda

[Bedňa]

Jazyk v 21storočí založený na * & je fakt hnus Čo sa mám vŕtať v pamäti a nerobiť priamo z objektami, potom žiadna správa pamäte nebude fungovať poriadne. Kód je neprehľadný, často sa robia chyby, pomalý vývoj. Každý jazyk/framework, ktorý niečo z toho odstráni je prínosom.

[Ladicek]

Já s tím souhlasím a v žádném případě nepodceňuju význam syntaxe (mimochodem, ta pascalská je co se ukazatelů týče asi tisíckrát lepší než ta céčkovská), ale zase není úplně úchvatný nápad vylejvat s vaničkou i dítě…

[kralyk z abclinuxu]

mimochodem, ta pascalská je co se ukazatelů týče asi tisíckrát lepší než ta céčkovská

To jako že ta stříška místo hvězdičky je takovým přínosem? (Krom toho, že se blbě píše)

[Ladicek]

Mhm, a víš v Céčku, co znamená a*b? V Pascalu jo.

[kralyk z abclinuxu]

Mhm, a víš v Céčku, co znamená a*b?

Pokud vim, co je a a b, vim i co je a*b.

[Ladicek]

Fakt paráda, místo aby na dvě různé věci byly dvě různé syntaktické konstrukce, budu radši zjišťovat, co jsou jednotlivé operandy zač. Operátor pro zjištění adresy taky koliduje s jiným operátorem, asi aby byla větší zábava.

A že je to optimalizované pro Araby, o tom ani nemluvím. a: ^b čtu hezky zleva a je ukazatel na b. b *a čtu, no, zprava (a protože K. a R. měli hvězdičky v oblibě, když budu chtít deklarovat těch ukazatelů víc, napíšu si hvězdičku pro každý zvlášť). Ale to už se netýká jenom ukazatelů, ale vůbec celé koncepce céčkové syntaxe.

[kralyk z abclinuxu]

Fakt paráda, místo aby na dvě různé věci byly dvě různé syntaktické konstrukce, budu radši zjišťovat, co jsou jednotlivé operandy zač.

Když ten kód píšeš, tak to zjišťovat nepotřebuješ, protože to víš.
A když kód čteš (po sobě nebo po někom), tak to chceš zjišťovat tak jako tak.
Krom toho, v syntaxi a * b by hvězdička měla smysl pointeru pouze v deklaraci (čili a by byl typ), a deklaraci od výkonného kódu člověk pozná.

K tomu čtení zleva/zprava, myslim si, že to je prakticky jedno. V Pascalu zas máš tu nevýhodu, že když chceš přidat další proměnnou stejného typu, musíš to cpát kamsi doprostřed řádky. V C to připojíš celkom logicky nakonec..., ale imho to je opravdu celkem jedno...

[Ladicek]

Prostě nutný kontext je širší než by bylo potřeba. Když se do toho zamotají ukazatele na funkce, ukazatele na funkce vracející ukazatele, ukazatele na funkce vracející ukazatele na funkce atd., je z toho odporné porno, ve kterém musí člověk postupovat podle stránku dlouhého algoritmu, aby takovou deklaraci dešifroval.

A jako bonus se tím komplikuje parsování. Fuj, to jsem si zase jednou zanadával.

[kralyk z abclinuxu]

Širší kontext? V Pascalu je samotná řádka a * b taky nicneříkající. K jejímu pochopení v C o nic širší kontext nepotřebuješ. A při práci s ukazately na funkce afaik vůbec ani hvězdičku nepotřebuješ. Zanadával sis - to bezpochyby ano, jen nechápu na co

[Ladicek]

Ne, v Pascalu jen při pohledu na tenhle výraz vím, že jde o násobení. Tohle je, pravda, problém spíš pro autora parseru než pro programátora s rozumným IDE (nebo aspoň ctags), ale jako ukázka to poslouží.

Mimochodem, že deklarace ukazatele a dereference se zapisují stejně (*identifikátor) je taky hnusné.

Že nechápeš, na co nadávám, je pochopitelné, protože to je jenom syntaxe. O té můžeš vždycky říct, že je to jedno (a ono je, akorát že různé aspekty syntaxe v různých lidech vyvolávají různě silné nepříjemné pocity, o čemž bys zrovna ty mohl dlouze vyprávět ).

[kralyk z abclinuxu]

Že nechápeš, na co nadávám, je pochopitelné, protože to je jenom syntaxe. O té můžeš vždycky říct, že je to jedno (a ono je, akorát že různé aspekty syntaxe v různých lidech vyvolávají různě silné nepříjemné pocity, o čemž bys zrovna ty mohl dlouze vyprávět ).

Jo jo, s tím souhlasím. Je to o osobních preferencích...

[kralyk z abclinuxu]

Jazyk v 21storočí založený na * & je fakt hnus Čo sa mám vŕtať v pamäti a nerobiť priamo z objektami, potom žiadna správa pamäte nebude fungovať poriadne.

Žádná správe paměti nefunguje pořádně. Všechno je jen určitý druh kompromisu.

[Bedňa]

Nemáš pravdu.

[kralyk z abclinuxu]

Ok, která správa paměti "funguje pořádně"?

[Bedňa]

Čítaj od: 3. Trocha filozofie a politicky nekorektních názorů

[elviin]

Jazyk v 21storočí založený na * & je fakt hnus ...

Clearly, if your code has new operations, delete operations, and pointer arithmetic all over the place, you are going to mess up somewhere and get leaks, stray pointers, etc.
Bjarne Stroustrup's C++ Style and Technique FAQ

[qiRzT]

To na co jsem reagoval byla ta metoda getAdress

Zavolat metodu objektu, nebo na objekt použít unární operátor mi přijde, z tohodle pohledu, ještě víc jedno. To že jednou to má víc pímenek hravě vyřeší automatické doplňování.

[JS]

To že jednou to má víc pímenek hravě vyřeší automatické doplňování.

Jeste by to pak ovsem chtelo automaticke cteni. Ja ten argument, ze vic pismenek vubec nevadi, zkratka neberu.

[qiRzT]

Že to vůbec nevadí bych neřek, ale taky to neberu jako argument pro zavedení nového operátoru.

[pht]

Nic přímo proti vám, ale co mají všichni proti is? Je to jeden operátor, jehož funkci si dokáže zapamatovat pravděpodobně i retardovaný žák základní školy pro "speciální" děti.

No nevím, já bych si třeba pod "is" uměl představit "is a", tj.

if (x is Comparable) ...

Ten operátor prostě vyžaduje konkrétní znalosti, a čím víc věcí které člověk "musí" znát, tím hůř.

Tohle je přesně ten trám o kterém jsem psal - místo dvou písmen is budu psát 6x delší název metody, navíc dvakrát. Vizuálně to prostě přehlednější není.

Je to delší ale jednodušeji se to čte. Ten záměr z toho prostě čiší, což se o "is" nedá říct. Nevím, jestli znáte programming by intention, ale tohle je přímo modelový případ.

A dále: jednak normální IDE takové věci umí dovodit, takže píšete: x.gA TAB == y. TAB

A jednak jestli je to o 6 znaků delší je mi fakt putna, protože píšu to jednou a číst se to bude 100x. Důležité je jak se to rychle dá přečíst a ne napsat.

[kralyk z abclinuxu]

Je to delší ale jednodušeji se to čte.

No to bych neřekl.
Když vidím &A, tak hned vím, že to je adresa A, jsou to dva znaky.
Kdežto A.getAddress() musím pečlivě zjistit, jestli to není třeba A.getAdress().

Kód v programovacím jazyku prostě není beletrie.

[pht]

Když vidím &A, tak hned vím, že to je adresa A, jsou to dva znaky.

To právě hned nevíte, protože si to musíte přeložit. Děláte to rychle a často tak si to ani neuvědomujete, ale děláte to. U getAddress si nic překládat nemusíte.

Kdežto A.getAddress() musím pečlivě zjistit, jestli to není třeba A.getAdress().

To taky ne, protože ten kdo si dá práci s getAddress nebude hned vedle toho definovat getAdress - ví že by to bylo nečitelné.

Kód v programovacím jazyku prostě není beletrie.

Ale je. Čím lépe se to čte, tím lépe se tomu porozumí. Tím lépe se do toho může hrabat a tím méně je v tom chyb. Na to se přišlo už dávno.

[kralyk z abclinuxu]

To právě hned nevíte, protože si to musíte přeložit. Děláte to rychle a často tak si to ani neuvědomujete, ale děláte to.

Ten význam chápu přímo. Podobně jako operátory v matematice - tam se člověk každou chvíli setkává s novými operátory.

To taky ne, protože ten kdo si dá práci s getAddress nebude hned vedle toho definovat getAdress - ví že by to bylo nečitelné.

Řekl jsi, že to je systémově definované.
Čili v podstatě všechny objekty/typy by dědily .getAddress(), takže vedle sebe to nebude. Krom toho často člověk používá kód někoho jiného, a co já vim, co tam kdo definoval...
Btw. myslel jsem, že dědičnost nemáš rád..?

Ale je. Čím lépe se to čte, tím lépe se tomu porozumí.

Není to beletrie. Programovací kód je mnohem podobnější matematickým zápisům než beletrii. Má určité bloky, které jsou nějak strukturované, mají mezi sebou určité vztahy a dělí se na podbloky. Ty automaticky předpokládáš, že víc písmenek = lepší čitelnost. Nevím, odkud tento automatický předpoklad bereš, je to nesmysl.
Užitečné to může být tak maximálně pro někoho, kdo ten jazyk nezná. Ten, kdo s tím jazykem už chvíli pracuje, příliš písmenek překáží.

[pht]

Podobně jako operátory v matematice - tam se člověk každou chvíli setkává s novými operátory.

Programování není matematika.

Čili v podstatě všechny objekty/typy by dědily .getAddress(), takže vedle sebe to nebude.

To je jedno na jaké úrovni to je, nikdo normální nedělá funkci prntf když existuje nebezpečí záměny s printf.

Krom toho často člověk používá kód někoho jiného, a co já vim, co tam kdo definoval...

Jak píšou jiní nemůžu ovlivnit, ale pokud dostanu do rukou takovej humus, kde se překlep může odkazovat na úplně jinou funkci, tak to nejprv přejmenuju na něco normálního.

Btw. myslel jsem, že dědičnost nemáš rád..?

WTF - pokud myslíš debatu o dědění implementace, tak to je poněkud jiný případ.

Programovací kód je mnohem podobnější matematickým zápisům než beletrii

Programování není matematika.

Ty automaticky předpokládáš, že víc písmenek = lepší čitelnost. Nevím, odkud tento automatický předpoklad bereš, je to nesmysl.

Víc písmenek rozhodně nestačí, je potřeba aby ty písmanka dávaly smysl, a ten smysl musí odpovídat záměru programátora. (Programming by intention - najdi si o tom něco.) A beru to ze zkušenosti svojí i jiných (kteří o tom napsali knihy).

[kralyk z abclinuxu]

Programování není matematika.

Však jsem taky nic takového neřekl. Řekl jsem, že to je matematice strukturou blíž než beletrii, a za tím si stojím.

To je jedno na jaké úrovni to je, nikdo normální nedělá funkci prntf když existuje nebezpečí záměny s printf.

Čím méně možností, kde nadělat chyby, tím lépe.

(Programming by intention - najdi si o tom něco.) A beru to ze zkušenosti svojí i jiných (kteří o tom napsali knihy).

Děkuji, nechci. To, že někdo o tom napsal knihy nevypovídá vůbec nic o vhodnosti té metody. Já preferuju kód, který nemusím číst, nebo jen minimálně, kód, kde je jeho struktura vidět hned, ne až po přelouskání stránky vytržené z románu.

Ale pokud si někdo myslí, že angličtina je na programování vhodnější než programovací jazyky, tak prosím...

[pht]

Čím méně možností, kde nadělat chyby, tím lépe.

S tím nelze než souhlasit.

Děkuji, nechci. To, že někdo o tom napsal knihy nevypovídá vůbec nic o vhodnosti té metody. Já preferuju kód, který nemusím číst, nebo jen minimálně, kód, kde je jeho struktura vidět hned, ne až po přelouskání stránky vytržené z románu.

Ony ty knihy jsou docela dobré, ale budiž. Co preferuješ je mi v kontextu téhle debaty jedno... (míněno bez urážky).

[:::]

Programování není matematika.

jasne ze je

[Let_Me_Be]

http://imgs.xkcd.com/comics/purity.png

[kralyk z abclinuxu]

Tam kde mi záleží na tom, jestli jsou stejné adresy v paměti tak můžu použít něco jako

if (x.getAddress() == y.getAddress()) ... 

S tímhle je ten program čitelný i bez toho abych vůbec potřeboval znát nějaké is.

1) Je to nechutně dlouhé.
2) Jak by taková metoda getAddress() asi byla implementována? V C++ by to moc nemělo smysl. Nevím jak v D nebo jinde...
3) Je to funkce objektu, takže každej by si to pojmenoval jinak. Někdo by to pojmenoval getAddress(), někdo GetAddress(), někdo getAddr(), no prostě by v tom byl zmatek.

[pht]

1) viz výše

2) Může to být implementováno systémem, pojem adresa v paměti je přece systémová věc.

3) Jednak existují rozumné konvence a jednak to může být předdefinovaná metoda/atribut každého typu, takže se tím programátor nemusí vůbec zabývat.

Ostatně & v C++ je na tom úplně stejně, je to předdefinovaný atribut který implementuje systém, kdyby se to místo toho jmenovalo franta tak by to fungovalo úplně stejně.

[kralyk z abclinuxu]

Jednak existují rozumné konvence a jednak to může být předdefinovaná metoda/atribut každého typu, takže se tím programátor nemusí vůbec zabývat.

No jo, to by ale znamenalo, že některé/některá jména členských funkcí jsou "zakázaná". To mně přijde vyloženě jako zmatečné řešení, když A.x je pro některá x uživatelská funkce a pro jiná x systémový operátor.
To už je mnohem šikovnější si zapamatovat jeden nebo několik operátorů, vždyť on to není vůbec problém.

[Ladicek]

No, když těch takových "není problém" je víc, tak to docela problém být začíná. Čím víc rozsypaného čaje, tím hůř. (Helou, Heskl!)

Ada má hezkou věc pro metadata, říká se jí atributy (viz http://en.wikibooks.org/wiki/Ada_Programming/Attributes), problém je, že se z toho nikdo nechce poučit.

[pht]

A.x je pro některá x uživatelská funkce a pro jiná x systémový operátor

A.x je metoda, a některé x implementuje systém. To je to samé jako když printf implementuje systém a jiné funkce ne.

[kralyk z abclinuxu]

"Implementuje systém"?
Operátor adresy, tedy &, implementuje kompilátor, kdežto funkci printf() implementuje standardní knihovna. Já vůbec knihovnu libc použít nemusím, můžu použít jinou a funkci printf() něčím nahradit, což se taky v praxi děje.

Ať už by se ta getAddress() implementovala na kterékoli z těch dvou úrovní, vždy to bude mít oproti operátoru dost nevýhod.

[pht]

Implementuje systém = neimplementuje programátor. Je jedno jestli to je kompilátor, nebo runtime. Proti operátoru to nemá technicky absolutně žádnou nevýhodu, protože ten princip je stejný jako u operátoru. Je to zrovna to samé jestli se píše Add(a,b) nebo a.Add(b) nebo +(a,b) nebo a+b.

[kralyk z abclinuxu]

Je jedno jestli to je kompilátor, nebo runtime.

No to není jedno.
Protože knihovny jazyka si můžu volit, můžu požít alternativní, můžu si printf() zadefinovat úplně jinak. Kdežto když je to standardně v kompilátoru, tak je to v daném jazyku skutečně napevno a neměnné.

Je to zrovna to samé jestli se píše Add(a,b) nebo a.Add(b) nebo +(a,b) nebo a+b.

Pokud by a.Add(b) bylo implementováno v kompilátoru, tak by se mi nelíbil zmatek vytvořený tím, že by některá jména členských funkcí byla zakázaná. Pokud by to bylo implementováno mimo kompilátor, nelíbíl by se mi zmatek při použití jiných knihoven.

[pht]

Kdežto když je to standardně v kompilátoru, tak je to v daném jazyku skutečně napevno a neměnné.

Já říkám že to implementuje systém nějak, to neznamená že to nemůže implementovat někdo jinak. Pokud si udělám vlastní alokátor tak si tu adresu můžu třeba navolit jak chci.

Pokud by a.Add(b) bylo implementováno v kompilátoru, tak by se mi nelíbil zmatek vytvořený tím, že by některá jména členských funkcí byla zakázaná. Pokud by to bylo implementováno mimo kompilátor, nelíbíl by se mi zmatek při použití jiných knihoven.

Zakázané? Nechápu. A zmatek v tom nevidím. a.Add(b) je technicky to samé jako a.+(b) neboli a+b a kde a jak se to implementuje si můžeš najít. Jediný rozdíl je to slovo místo symbolu. Myslím, že považuješ operátory za něco magického, ale ve skutečnosti jsou to jen divně pojmenované funkce / metody.

[kralyk z abclinuxu]

Zakázané? Nechápu. A zmatek v tom nevidím.

Tím myslím tu situaci s tím .getAddress(). Když bude mít každý objekt by-default členskou funkci .getAddress(), tak už nemůžu definovat takovou svoji. Vem si třeba například když budeu implementovat socket, potom by člověk čekal, že socket.getAddress() vratí adresu přiřazenou k socket, a vono ne. Nebo třeba kontakt ve správě kontaktů, člověk by čekal, že ceontact.getAddress() vrátí poštovní adresu, a vono to je něco úplně jinýho. (To jsou jen příklady, existuje jistě spousta dalších). Prostě zmatek...

a.Add(b) je technicky to samé jako a.+(b) neboli a+b a kde a jak se to implementuje si můžeš najít. Jediný rozdíl je to slovo místo symbolu.

Já vim, že to je to samé a nepovažuju operátory za nic magického...
Pokud by ta implicitní členská funkce byla přetížitelné, bylo by to opravdu to samé jako s těma operátorama, no ale ono už tak je celkem úchylné, že operátor adresy jde v C++ přetížit
No a nelíbí se mi to množství písmenek, ale tak to je asi věc názoru...

[kralyk z abclinuxu]

eh, to jsem zas nasekal překlepů... :/

[pht]

Vem si třeba například když budeu implementovat socket, potom by člověk čekal, že socket.getAddress() vratí adresu přiřazenou k socket, a vono ne. Nebo třeba kontakt ve správě kontaktů, člověk by čekal, že ceontact.getAddress()

No ok, tak to může být matoucí - to jsem jen tak nastřelil. Můžeš si tam domyslet něco lepšího třeba socket.memoryAddress ... whatever... nebo viz jak to řeší ta Ada...

Pokud by ta implicitní členská funkce byla přetížitelné, bylo by to opravdu to samé jako s těma operátorama

Tak to může být a nemusí, zrovna u adresy bych to asi nedoporučoval, u aritmetických operací se to v jistých rozumných případech dá tolerovat.

už tak je celkem úchylné, že operátor adresy jde v C++ přetížit

Ano.

No a nelíbí se mi to množství písmenek, ale tak to je asi věc názoru...

aka. f u cn rd ths, u r gd cmp pgm

Dovolím si střelit od boku, ale "nelíbí se mi množství písmen" = "nechce se mi to psát" ? Pak jsou 2 řešení 1) nauč se psát rychleji 2) nech si od ide doplňovat slova a konstrukce.

[kralyk z abclinuxu]

Dovolím si střelit od boku, ale "nelíbí se mi množství písmen" = "nechce se mi to psát" ?

To by mi ani tak nevadilo, spíš mi to pak přijde hrozně nepřehledný. Čili kvůli čtení než kvůli psaní. Samozřejmš příliš málo písmenek je druhý extrém...

[Let_Me_Be]

Tak ono taky psat &other == this na zacatek kazde implementace operatoru == je docela standard.

[pht]

To ano, ale na tom je hezké zejména to, že mě to jako uživatele toho operátoru právě vůbec nemusí zajímat. "Hloupý" operátor to vůbec nemusí dělat, "chytrý" může ale oba budou mít stejné výsledky.

[Josef Kufner]

A co takový Javascript? (resp. ECMA script či QtScript)

Pokud se zapomene na webové prohlížeče a jejich "krásnou" kompatibilitu, tak je to velmi pěkný funkcionální jazyk. Chce to sice jako podklad kus kódu v C++ (QtScript), ale i tak se to pro určité aplikace může velmi hodit a značně rozšířit jejich možnosti.

[zulu]

V podstatě souhlasím, v některých ohledech si mi D líbí, a C++ mě naopak se.. štve. Ale ty, když víš kulový a velkolepě to demonstruješ, budeš něco namachrovaně komentovat? Trapné.

[poky74]

"Kecy jsou levné. Ukaž mi kód."

Narozdíl od tebe, který opravdu jenom namachrovaně komentuje, autor se jal o tom jazyku informovat a pracuje na wiki. Ty jsi vrchol trapnosti.

(A já jsem asi zase nakrmil trolla ).

[zulu]

autor se jal o tom jazyku informovat

OK, ale takovým stylem, on?

A já jsem asi zase nakrmil trolla

Ne, myslel jsem to vážně.

[Bystroushaak]

Ale ty, když víš kulový a velkolepě to demonstruješ, budeš něco namachrovaně komentovat?

Když už jsem spáchal zločin namachrovaného komentování, dovolím si ještě i nějakou tu ignorantskou aroganci; Jo, protože můžu a chci. Problém?

[zulu]

protože můžu a chci

Samozřejmě můžeš a pochopitelně chceš, ale akorát se ztrapňuješ. Kdo tě ještě nezná, ten to brzy pozná.

[kralyk z abclinuxu]

Samozřejmě můžeš a pochopitelně chceš, ale akorát se ztrapňuješ. Kdo tě ještě nezná, ten to brzy pozná.

To je možná tak tvůj názor. A nevím, co jeho publikováním chceš dokázat...

[Bystroushaak]

Samozřejmě můžeš a pochopitelně chceš, ale akorát se ztrapňuješ. Kdo tě ještě nezná, ten to brzy pozná.

Blah blah. Něco jiného než prázdné kecy, třeba konstruktivní kritika, nebo návrh jak něco udělat líp by nebylo? Pokud ne, ztrácím tu s tebou čas.

[Senior Database Programmer]

Ja frcim na Groovy. Ten tu este nebol spomenuty...

[dejvik]

Jak je na tom jazyk D s rychlostí? V porovnání třeba s C++? Dal by se v tom bezbolestně napsat 3D engine nad OpenGL, který by byl rychlý?

Mohl bych to pak portout na ARM phone? (Android/iPhone/Meego)

[____]

gcc (gdc) a LLVM (ldc) kompilery pro D samozřejmě ARM podporují, ale jsou, co se týče podpory jazyka, oproti oficiálnímu DMD přirozeně pozadu a na D2 se dá prozatím rovnou zapomenout. Měla by u nich být rychlost v porovnání s C++ téměř identická, jelikož jde interně o stejné překladače, pouze jiné "syntaktické frontendy" a knihovny.

Jak si na tom stojí samotné DMD vám ponechám jako cvičení. Nezdá se, že by se v něm momentálně nějaká podpora pro jiné architektury než x86 nacházela.

[Bystroushaak]

gdc pokud vím podporuje D2, ale je nutné si ho zkompilovat ručně, v distribučních repozitářích jsou v naprosté většině případů jen balíky D1.

[Bystroushaak]

Viz https://bitbucket.org/goshawk/gdc/wiki/Home

[____]

Zrovna tak ldc, co jsem to tak procházel. Je to spíš v experimentálním stádiu.

[kralyk z abclinuxu]

Dal by se v tom bezbolestně napsat 3D engine nad OpenGL, který by byl rychlý?

D má GC, takže to by mohl být potenciálně problém, ale na wiki píšou, že se dá kontrolovat/deaktivovat (nevím detaily), takže by to asi jít mělo...