Vlákno názorů k článku
Programovací jazyk D
od anonym - Na D jsem se kouknul jen velmi lehce,...
-
Na D jsem se kouknul jen velmi lehce, takže se mohu mýlit, ale podobnost s Ruby (a jeho flexibilitou) mi uniká. Metaprogramování je v D založeno na šablonách podobně jako v C++, snad jen s lepší syntaxí. A ani si neumím představit, že bych si v jazyce se statickými typy mohl například za běhu rozšířit definici nějaké třídy nebo určitého objektu. -
Jde to, viz Strongtalk (http://www.strongtalk.org/), ale tam je staticka typova kontrola pouze volitelna nadstavba nad dynamicky typovany jazyk.
-
Otázkou je, jestli rozšířování definice třídy, nebo objektu za běhu je to pravé ořechové pro programování a feature number one. Tahle možnost za běhu rozšiřovat třídu mě nijak a nikde nechybí a nijak mě to neomezuje ve flexibilitě v programování, a to se teď konkrétně nebavím o jazyku D. Hlavně mi není jasné, jak u jazyka s touhle feature zajistíte rychlost a efektivitu, tedy vlastnosti, které mají nejvyšší prioritu v jazycích jako je C/C++/D.
-
Jistě, budu-li chtít napsat nový realtimový operační systém, nejspíš si k tomu nevyberu Ruby. Chtěl jsem jen poukázat na to, že mi přijde v té zprávičce (i v originále) poněkud "píárková" (a tedy zavádějící) ta formulace "... s produktivitou Pythonu nebo Ruby ...", protože kategorie těch jazyků (C/C++/D vs. Smalltalk, Ruby, Python) mi přijdou až příliš vzdálené.
BTW, pomocí metaprogramování se dají velmi elegantně řešit některé úlohy - viz například Ruby on Rails. -
Ona ta formulace ve stylu pr je, ale ono to taky není tak daleko od pravdy. Protože věřím, že produktivitu blízkou Pythonu, nebo Ruby tam v D dosáhnete. Tam přeci není napsáno, že to má stejné features jako Python, nebo Ruby, ale o srovnatelné produktivitě. Ten nadpis opravdu nelže.
Zkuste se začíst do toho jazyka D, a já sám jakožto slouholetý programátor v C++ jsem o takovém jazyce snil. Kdyby bylo rozšířenější, byla by paráda. Jediné co se mi nelíbí je absence vícenásobné dědičnosti, kterou považuji za lepší. Ale třeba garbage collector, nebo dynamické closures, nebo vestavěné základní datové typy a operaci s nimi na úrovni syntaxe jazyka (ne knihovny) ve stylu Pythonu vám nepřijsou jako podstatné zvýšení efektivity? A to jsem zamlčel spoustu dalších věcí, kdy se to vlastnostmi blíží úplně někam jinam, než je C/C++. A pořád je to přitom jazyk kompilovatelný do binárky, tedy superrychlý. -
Ona ta formulace ve stylu pr je, ale ono to taky není tak daleko od pravdy. Protože věřím, že produktivitu blízkou Pythonu, nebo Ruby tam v D dosáhnete. Tam přeci není napsáno, že to má stejné features jako Python, nebo Ruby, ale o srovnatelné produktivitě. Ten nadpis opravdu nelže.
Zkuste se začíst do toho jazyka D, a já sám jakožto slouholetý programátor v C++ jsem o takovém jazyce snil. Kdyby bylo rozšířenější, byla by paráda. Jediné co se mi nelíbí je absence vícenásobné dědičnosti, kterou považuji za lepší. Ale třeba garbage collector, nebo dynamické closures, nebo vestavěné základní datové typy a operaci s nimi na úrovni syntaxe jazyka (ne knihovny) ve stylu Pythonu vám nepřijsou jako podstatné zvýšení efektivity? A to jsem zamlčel spoustu dalších věcí, kdy se to vlastnostmi blíží úplně někam jinam, než je C/C++. A pořád je to přitom jazyk kompilovatelný do binárky, tedy superrychlý. -
Mám pocit, že se snažíme diskutovat o přesném významu vágního píárkového tvrzení "produktivita blízká Pythonu nebu Ruby", což je asi z podstaty věci nesmysl. IMHO záleží na požadavcích a omezeních zadání, typu a rozsahu řešené úlohy, požadovanému výkonu apod. Budu-li psát driver nějakého hw zařízení, nejspíš budu produktivnější v C než v Ruby. Naopak budu-li psát pokročilý framework pro webové aplikace (něco jako RoR nebo Nitro/Og) budu nejspíš nejproduktivnější v Ruby (nebo podobném jazyku). A budu-li dělat aplikaci pro MS-Windows s náročným GUI, nejspíš budu nejproduktivnější v C#. A pro transformaci XHTML dokumentů budu nejproduktivnější v XSLT.
-
Já s Vámi souhlasím. Sice se můžu hádat o detaily, ale princip je tentýž. Problém je dvojí:
a) jestli daný problém je vůbec reálné v jazyku řešit (například hw driver se dá napsat v C/C++/D/Asm, ale pochybuji, že reálně se dá psát hw driver v Ruby - takže to není jen o efektivitě)
b) jestli existuje již hotová knihovna (což se mnohdy zaměňuje)
1) Jazyky ve stylu C/C++/D/Asm/Ada apod.. jsou dobré právě v tom, že v nich napíšete naprosto všechno (v krajním případě s nepatrnou pomocí inline asm) a máte k dispozici veškeré prostředky a přitom maximální možnou efektivitu.
2) Jazyky ve stylu Python, Ruby, Smalltalk, Strongtalk, Java, LISP, Scheme apod.. nejsou schopny bez pomoci předchozích jazyků existovat a nelze v nich napsat vše a potřebují pomoc předchozích jazyků. Jsou také z principu pomalejší, nelze v nich mít vše pod kontrolou, a některé věci v nich napsat nelze vůbec, nebo jen z principu velmi těžko.
3) Problémově orientované jazyky, jako třeba SQL, nebo XSLT, které dokáží jen velmi omezenou množinu úloh, ale dokáží jí velmi dobře.
Proto dochází k tomu, že jazyky první skupiny přebírají eleganci druhých, což je třeba na tom C++/D vidět, aniž by ztratily na rychlosti a stávají se vysokoúrovňovými (ale taky složitými na naučení). A jazyky druhé skupiny se snaží efektivitou přibližovat prvním (což znamená nechutné nelogičnosti ve jménu efektivity - nejvíce je ta nelogičnost vidět na Javě, a také někdy plýtvání prostředky počítače a obrovskou složitost optimalizátorů a jit kompilátorů). -
Mohl byste, prosím, dát příklad toho, co je možné naprogramovat v C ale ne v LISPu?
Mohl byste se, prosím, vyjádřit k článku "How to make Lisp go faster than C" www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf ?
Děkuji.
-
pf (neregistrovaný)Metaprogramovani a rozsirovani za behu se staci nebat. Pri zajmu je mozny se treba podivat na framework Magritte http://www.lukas-renggli.ch/smalltalk/magritte - je to ve Smalltalku, takze se vam asi nebude moc chtit prosvistet ten dokument aspon lehce, ale me to prijde "orechovy" az dost...
-
Na druhou stranu je tato technika naprosto zásadni pro inkrementalni exploratorni systemy, které tak dovoluji velmi snadno a elegantne resit celou radu jinak velice slozitych problemu. Zkuste se podivat na toto video z roku 1983 a odpovedet si na otazku, kdy jste mel poprve v rukou vyvojove prostredi se stejnymi schopnostmi: http://video.google.com/videoplay?docid=-7466310348707586940
