Programovací jazyk D

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.

.........To som ja nikde necital. Iba zaciatocnik ma ten pocit. Potom neskor pochopi ze vsetko je pointer. Vsak sa treba iba naucit ze porovnanie objektov sa robi pomocou equals(). To sa naucite a je to. Na funkcnost to nema vplyv.

Na funčnost nemá nic vliv, ale na udržovatelnost a přehlednost kódu ano. Co je lepší:

if (a.equals("ahoj") && !b.equals("x"))

nebo

if (a == "ahoj" && b != "x")

Co je přehlednější je nabíledni, však taky Javy se svým equals zůstává sama.

...........Sposobi ze vo vyslednom kode bude iba volanie A(). Ziadna podmienka, ziadne volanie B(). Opat neviem v com spociva rozdiel oproti #ifdef. Ak samozrejme pod pojmom podmiena kompilacia myslime to iste.

Prosím předveďte mi v Javě toto (a to je jen velmi málinko co dokáže podmíněná kompilace):

#if defined(HIGHEST_PRECISION)
typedef big_integer_t value_type;
#elif defined(NORMAL_PRECISION)
typedef long value_type;
#else
typedef short value_type;
#endif

class measure_object
{
private:
value_type value_1, value_2, value_3;

public:
value_type getValue1()
{
return value_1;
};
};

..........A znova prelozime a["some"] na a.get("some"). Funkcnie v tom rozdiel nie je. Dokonca aj s java nativnymi arrays sa robi iba vo velmi extremnych pripadoch kedy je treba rychlost. Vacsinou sa pozaduje flexibilita a pouzije sa nejaky List (ArrayList, LinkedList, ...).

Ukázky z Pythonu:

a = {'some':'neco', 'huhu':'bubu', 'pocet':3, 'vnoreny_slovnik' : { 'a':3, 'b':4 }}
a['some'] += 'x' - a['huhu'] * a['pocet']
b = (3,4,5,6,7)
if 3 in a:
print "trojka je ve slovniku a"

Na této ukázce jen velmi mála z možností Pythonu je jasně vidět co jsem udělal. Zapište ekvivaletní kód v Javě a takové Javě a už na tak krátkém kódu bude znát oč je datová struktura v syntaxi lepší. A teď si to představte v programu s miliónem řádků. Ačkoli to co zapíšete v Javě bude ještě v těch pár řádcích srozumitelné, i když ne tak jako v Pythonu, u velkého projektu pak ten rozdíl ve srozumitelnosti bude obrovský.

..............Napriklad Groovy sa kompiluje, ma aj closures aj asociativne polia. Triedy a runtime je rovnaky. Napriek tomu ako vidite nikto nan prudko nekonvertuje. Pre mna je to jasny dokaz toho ze Syntax nie je king.

To je mi argument :-) Jasně, hlavním důvodem proč na Groovy nikdo nekonvertuje je určitě jeho syntaxe. A tu o červené karkulce znáte? :-) Podle stejného uvažování je u nás nejkvalitnější a nejhodnotnější časopis Blesk, protože ho čte nejvíc lidí.

Ta podmíněná kompilace není stejná:

public Number getValue1() {
return value1;
}

Jednak já nechci vracet Number, ale příslušný typ podle podmíněné kompilace. Nechci vracet objekt Number, ale primitivní typ pro short a long, a nebo big_integer_t. Kromě toho v úseku datových členů máte to samé

private Number value1;

Já tam nechci objekt, ale přesně ten typ co jsem předepsal v podmíněné kompilaci.

Jinak ten kód s těmi datovými strukturami v Pythonu také není tentýž, i když je to skoro ono.

.............Od Javy sa lisi iba syntaxou, aj tak ho ludia az tak extenzivne nepouzivaju ako Javu, aj ked podla Vas by mali.

A proč by měli? Jen proto, že má jinou syntaxi? Nad Javou existuje Jython, což je Python pro Javu a JRuby, což je Ruby pro Javu. Oba mají lepší syntaxi a navíc jsou určitě podporovanější, než Groovy, o kterém jsem poprvé slyšel od Vás.

.......Ja som ale hned napisal ze podmienena kompilacia funguje okrem zmeny struktury.

Jinak řečeno to není podmíněná kompilace, ale jen optimalizace.

......Nemozte proste vynechat clenov struktury na zaklade ifdef podmienky. Otazka ale znie ze naco by som to robil. Takto sa uz neprogramuje. 4 byty v pamati ako nepouzity smernik nikoho nezaujimaju.

Pokud máte držet v paměti třeba sto miliónů takových objektů, docela se to hodí. To už je rozdíl 4 x 100 MB paměti, ale ve skutečnosti několikanásobek, protože každý objekt má vnitřní režii paměti, kterou nevidíte, jako že si musí pamatovat svojí třídu a svojí vnitřní tabulku virtuálních metod a další položky. Ale podmíněně se kompilují třeba věci závislé na operačním systému, je naprosto zbytečné aby objekt držel datové členy, které se na jeho platformě nepotřebují.

.........V JDK 1.5 mozete mixovat Objekty a primitivne typy. Takze sa da scitat int a Integer. Keby som chcel presne realizovat ten Number tak to urobit pomocou generickych typov alebo ciste objektovo cez dedicnost a vyuzijem polymorfizmus bez potreby akehokolvek ifdef.

A opravdu se dá sčítat i ten BigInteger? Problém je, že tento příklad tak uděláte, ale podmíněná kompilace toho zvládne mnohem víc a hlavně efektivněji. Nepotřebuje uměle zavádět typy, které momentálně nepotřebujete, ani vymýšlet společné předky.

..........Uvidime ako to pojde dalej ale este je tu problem nastrojov. Pre vyvoj v Jave dnes existuju minimalne 3 spickove tooly (Eclipse, NetBeans, Oracle JDeveloper). Som zvedavy kedy sa objavi aspon trochu kvalitativne podobny editor pre Ruby alebo D. S doplnanim, textovymi sablonami, refaktoringom, quick fixom, ... .

No já nevím, já dělám s vimem, a většinu své práce s Javou jsem dělal také raději s vimem, než s Eclipse. Automatické doplňování mi ve vimu funguje, textové šablony no problem, činnosti podobné quickfixu zvládne dokonale, dokonce si můžu cokoli připrogramovat co po něm chci a spoustu dalších věcí, o kterých se mi jinde ani nesní (dokonce mi zkontroluje pravopis v komentářích :-)). Jinak si myslím, že dobře navržený jazyk takové prostředí jako Eclipse nepotřebuje a stačí běžný programátorský editor. Taky se divím, že každý Javista klade tak obrovský důraz na refaktoring, já osobně jsem za 20 let programování, a to i ve velkých týmech prakticky přejmenovával větší balík snad jednou v životě. Spíš mi přijde jako nedostatek Javy, že pro efektivní vývoj je skoro nutné mít takový špičkový tool.