Hlavní navigace

Programovací jazyk D

2. 1. 2007

Sdílet

Blíží se vydání verze 1.0 programovacího jazyka D. D je systémový programovací jazyk, který kombinuje sílu a vysoký výkon C a C++ s produktivitou moderních jazyků jako je Ruby nebo Python.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 2. 1. 2007 10:53

    bez přezdívky
    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.
  • 2. 1. 2007 12:08

    Miloslav Ponkrác
    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.
  • 2. 1. 2007 12:44

    bez přezdívky
    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.
  • 2. 1. 2007 13:30

    Miloslav Ponkrác
    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ý.
  • 2. 1. 2007 13:38

    Miloslav Ponkrác
    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ý.
  • 2. 1. 2007 15:21

    bez přezdívky
    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.
  • 2. 1. 2007 15:42

    Miloslav Ponkrác
    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ů).
  • 8. 11. 2011 14:28

    bez přezdívky

    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.

  • 2. 1. 2007 14:48

    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...
  • 2. 1. 2007 16:18

    Miloslav Ponkrác
    Metaprogramování možná, ale rozšiřování za běhu je zajímavá technika, která je ale v protikladu s efektivitou a rychlostí běhu, tedy s cílem, které si kladou jazyky C/C++/D/Asm. A taky je to dobrá technika ke zmatení nepřítele, tedy ke zhoršení čitelnosti, pokud to autor nezvládne.
  • 2. 1. 2007 18:56

    Pavel Křivánek
    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
  • 2. 1. 2007 11:55

    Palo (neregistrovaný)
    Tak ja som si pozrel porovnanie s Javou. Mne nejako unikaju niektore specialitky. Vela vlastnosti jazyka mi pripadaju ako malicherne nahananie vlastnosti aby to malo lepsie. Namiesto toho aby sa jazyk sustredil na riesenie problemov tak castokrat riesi iba syntakticke pochutky ktore su naviac obvykle nesurode zo zvyskom jazyka. Odkedy sa kvalita jazyka hodnoti podla toho kolko clovek musi pisat? Usetrit na kazdom riadku za kazdu cenu 2-3 pismenka. To je cool. Moja skusenost s programovanim je prave opacna. Syntakticke pochutky nijako vyslednemu kodu nepomahaju. Priblizne 50% programatorov nevie vytvorit spravne genericke typy pripadne vyuzit niektore syntakticke chutovky. Najhorsie je ze to obvykle ani nepotrebuju lebo na vyriesenie daneho problemu to nie je treba. Stiahne sa nejaka kniznica a urobi sa nad nou. Tam uz obvykle nemusite vytvarat nove typy iba ich pouzivat.
    Myslim ze sa podcenuje vyznam standardnych kniznic. Ak ich je vela, daju sa pouzit na rozne problemy a su dostatocne flexibilne to je to co pomaha programatorovi. Nie 3 usetrene pismenka v riadku.
    Nemyslim si ze syntax je to co programatorov vedie k pouzitiu niektoreho jazyka. Mne napriklad na Jave velmi vyhovuje ze ma striktnu typovu kontrolu pri kompilovani. Aj s pozitivami a negativami ktore to prinasa. Pre vyvoj v teame je to neocenitelna funkcionalita. Jazyk D je tu nema. Pre mna to znamena fullstop.
  • 2. 1. 2007 13:08

    Miloslav Ponkrác
    Pane, vy jste Javista, že? Právě že ta syntaxe má velký význam a jazyk s dobrou syntaxí je poklad. Zkuste si porovnat třeba syntaxi Pythonu, nebo Ruby, ochutnejte to intenzívně rok, nebo dva a vraťte se do Javy. Pochopíte.

    Význam knihovny je sice klíčový, ale jazyk se špatnou syntaxí je utrpení a značně zdržuje, i když má vynikající knihovny. Třeba mě přestože v Javě mám letité zkušenosti nesedí právě ta špatná a více, než chudá syntaxe Javy. Mě zase přijde směšné, když mi Javisti typicky říkají, že jim určité šablony Eclipse vygeneruje, což mimo jiné znamená, že Java je syntakticky tak neobratná, že Eclipse musí pro zvýšení efektivity práce generovat "typické sekvence" použití.

    To, že 50% programátorů neumí vytvořit generické typy znamená, že 50% je umí. A zbytek umí používat generické typy vytvořené tou půlkou. Sám tvrdíte, že si mají stáhnout knihovnu a jenom typy používat, tak Vaše argumenty si samy o sobě protiřečí. Typický Javista je rasista - když jsem na něco blbej, ať to raději neexistuje. Jak Vy víte, že to nepotřebují na řešení problému?

    Knihovny jsou velmi důležité, ale ostatní části taky. Navíc mám pocit, že o jazyku D nic nevíte, protože on je staticky typovaný stejně jako Java, tedy má striktní typovou kontrolu. Vy píšete, že jí nemá. Prosím, abyste příště propagoval Javu trochu chytřeji, než pomocí lží a pomocí dokazování, že o tématu nic nevíte. Děkuji.
  • 2. 1. 2007 13:51

    Palo (neregistrovaný)
    Tak robil som okrem Javy aj s inymi jazykmi ale profesionalne to bolo iba C/C++, asi 4 roky a myslim ze som nebol najhorsi. Potom este nejake to 4GL. To ze Eclipse generuje typicke sablony nie je predsa naobtiaz. To sa da robit aj pre hociktory iny jazyk a vdacime za to prave napr. striktnej typovej kontrole lebo nastroj potom moze viac dedukovat co to vlastne ma doplnit.
    Na riesenie problem nie je nieco uplne nevyhnutne vo chvili ked je jazyk "turing complete". Ostatne je uz iba ceresnicka.
    Ja som to ako propagaciu Javy nepojal. Len som chcel nejako zhodnotit realne sance tohto jazyka z pohladu dlhodobeho vyvoja aby to nebolo take programovanie do supliku z naslednym prepisom do ineho jazyka ked prestane byt dana platforma podporovana.
    Niektore porovnania v tabulke jazykov su aj tak nepravdive. Napr. Java ma aj static if aj ked nie taky explicitny. Mixins sa daju riesit pomocou Aspectov. Conditional compilation, ... .
  • 2. 1. 2007 14:33

    Miloslav Ponkrác
    Vy zapomínáte na to, že "turing complete" je trochu málo, ale že ten jazyk musí být taky pohodlný, snadno udržovatelný, apod..

    Generování Eclipse není na obtíž pokud to neslouží jakožto zakrývání nemotornosti syntaxe Javy.

    K poslednímu odstavci, Java má všechno akorát se to musí napsat pomocí něčeho jiného, takže to vlastně nemá. Stejným způsobem dojdeme k tomu, že všechny jazyky mají vše. Všechno se to v Javě dá nějak řešit, ale je to jen z nouze ctnost. Není nad to, když je ze zdrojáku naprosto jasně vidět, co chtěl autor napsat a ne, že to nejdřív musel zparchantět pomocí něčeho jiného a zkoumat co čím v syntaxi emuloval.

    Nemám nic proti Javě, ale uvědomuji si význam dobré syntaxe programovacího jazyka, a v tom Java neexceluje. Zastánci Javy prostě neumí vůbec ocenit význam dobré syntaxe, když jim v tomhle Java nabízí akorát ohlodanou kost.
  • 3. 1. 2007 2:15

    Palo (neregistrovaný)
    Vy zapomínáte na to, že "turing complete" je trochu málo, ale že ten jazyk musí být taky pohodlný, snadno udržovatelný, apod..
    Ale nie je to nevyhnutne na vyriesenie problemu.
    Generování Eclipse není na obtíž pokud to neslouží jakožto zakrývání nemotornosti syntaxe Javy.
    Takze ked sa to objavi pre C tak tiez vyhlasime ze to sluzi na zakryvanie nemotornosti C? Ja v Jave ziadnu nemotornost nevidim (teda nie zasadnu).
    Java má všechno akorát se to musí napsat pomocí něčeho jiného.
    Tomuto celkom nerozumiem. Jedine co napada v tejto suvislosti je Aspect kompilator ale aspekty sa daju deklarovat aj v XML a samotny kod moze byt cista Java.
    Stejným způsobem dojdeme k tomu, že všechny jazyky mají vše.
    Nemyslim. Napr. ruby asi nebude mat static if.
    Nemám nic proti Javě, ale uvědomuji si význam dobré syntaxe programovacího jazyka, a v tom Java neexceluje.
    Mate nieco konkretne? Mna napada z C++ co Java nema uz asi iba multiple inheritance, function pointer a operator overloading. A bez toho viem zit alebo to obist.
  • 3. 1. 2007 4:46

    Miloslav Ponkrác_ (neregistrovaný)
    ..........Takze ked sa to objavi pre C tak tiez vyhlasime ze to sluzi na zakryvanie nemotornosti C? Ja v Jave ziadnu nemotornost nevidim (teda nie zasadnu).

    V C se to běžně nevyskytuje. Já v Javě syntaktických nemotorností vidím spousty.

    .........Mate nieco konkretne? Mna napada z C++ co Java nema uz asi iba multiple inheritance, function pointer a operator overloading. A bez toho viem zit alebo to obist.

    Měl bych tak asi dvacetistránkový seznam. Upřímně, není to tak dávno co se vykřikovalo, že třeba i výčtové typy jsou v Javě zbytečné a nebýt konkurence .NET, tak je Java nemá dodnes. Nemluvím třeba o tom, že v každém normálním jazyku syntakticky porovnám řetězce pomocí operátoru porovnání, pouze Java to neumí. Mohl bych napsat haldu naprosto zásadních věcí, které mi v Javě chybí, například nemožnost typedef, přetěžování operátorů, nemožnost podmíněné kompilace, a to se hodně krotím. Pokud ale srovnáváme s programovacím jazykem D, o který tady jde, bude ten seznam ještě mnohem delší počínaje datovými strukturami přímo v syntaxi (třeba asociativní pole apod.), přes kompletní closures, property a tak dál.

    Obejít se to dá, ale teze všechno se nasimuluje něčím jiným, jak to razí Java není moc uchvacující. Víte ona i v sexu se dá ženská nasimulovat něčím jiným, ale není to ono. :-)
  • 3. 1. 2007 13:43

    Palo (neregistrovaný)
    Upřímně, není to tak dávno co se vykřikovalo, že třeba i výčtové typy jsou v Javě zbytečné a nebýt konkurence .NET, tak je Java nemá dodnes.
    OK. Ale uz ich ma. Takisto ako Genericke typy (templates). Ani C/C++ nebolo hned dokonale.
    syntakticky porovnám řetězce pomocí operátoru porovnání, pouze Java to neumí
    Ale vie. Len treba rozumiet tomu co chcem porovnavat. Ci dva retazce maju rovnaky obsah alebo je to ten isty retazec.
    nemožnost podmíněné kompilace
    To ide. Staticke vyrazy sa priamo pocas kompilacie evaluuju a ked maju vysledok vzdy rovnaky tak sa prislusny kod vyhodi. Samozrejme takto nejde zmenit strukturu triedy ale z pohladu funkcionality to ide.
    počínaje datovými strukturami přímo v syntaxi (třeba asociativní pole apod.)
    Ale sucastou standardu su kniznice kde to je. A implementacii mate viac aby ste sa mohli rozhodnut ktora je pre vas vhodnejsia (Hashtable, HashMap, WeakMap, ...). Aj ja by som bol radsej keby kompilator zistil ze dane pole sa pouziva z viacerych thredov a automaticky by vytvoril synchronizovane pole, ale taky kompilator som zatial nevidel. Takze to treba nechat na programatora. Toto je v Jave podla mna vyriesene vyborne.
    property
    A toto je napr. nieco comu nerozumiem ja: obj.member=3; vs. obj.setMember(3); Z toho ja ziadne pupaky nemam. Toto je jedna z klasickych veci kde sa dostavame na nejaku formu hrania sa na krasu kodu a setrenie pisania. Z funkcionalitou kodu to nic nema.
  • 3. 1. 2007 14:18

    Miloslav Ponkrác_ (neregistrovaný)
    .........."OK. Ale uz ich ma. Takisto ako Genericke typy (templates). Ani C/C++ nebolo hned dokonale."

    Výčtové typy mělo C i C++ od začátku. Na rozdíl od Javy nikdo v těchto jazycích nevykřikoval, že je nepotřebuje, a že jsou zbytečné.

    ..........."Ale vie. Len treba rozumiet tomu co chcem porovnavat. Ci dva retazce maju rovnaky obsah alebo je to ten isty retazec."

    A koho zajímá, jestli jde v případě řetězce o stejný pointer? (mimochodem to je docela sranda, Java píše že odstraňuje práci s pointery, ale v případě řetězců a porovnávání je vlastně aplikuje). Jak často to potřebujete vědět, jestli dva řetězce jsou stejným objektem? Já jsem to za dvacet let praxe nepotřeboval ani jednou, i když připouštím, že se najde hodně vyumělkovaný případ, kde se to dá použít. Zato porovnávat obsdah řetězce se potřebuje opravdu velmi často.

    ...............To ide. Staticke vyrazy sa priamo pocas kompilacie evaluuju a ked maju vysledok vzdy rovnaky tak sa prislusny kod vyhodi. Samozrejme takto nejde zmenit strukturu triedy ale z pohladu funkcionality to ide.

    Zase se zamotáváte do mlhy, to co mluvíte o statických výrazech není podmíněná kompilace, ale pouhá optimalizace výrazů, což má každý slušný kompilátor každého jazyka. Java podmíněnou kompilaci nemá a nemá ani prostředek, kterým se to dá plnohodnotně nahradit.

    ..............Ale sucastou standardu su kniznice kde to je. A implementacii mate viac aby ste sa mohli rozhodnut ktora je pre vas vhodnejsia (Hashtable, HashMap, WeakMap, ...).

    Není nad datové struktury přímo v syntaxi jazyka.

    ........Takze to treba nechat na programatora. Toto je v Jave podla mna vyriesene vyborne.

    Zkuste třeba Python a jeho integraci datových struktur přímo do syntaxe jazyka, nebo klidně to D. Pak pochopíte, že Java to má vyřešené špatně. Pochopíte, jak krásně čitelné to je a jak dobře udržovatelný (a přitom mnohem kratší) kód vzniká. Tím také jako side effect vzniká kód s méně chybami.

    .........A toto je napr. nieco comu nerozumiem ja: obj.member=3; vs. obj.setMember(3); Z toho ja ziadne pupaky nemam. Toto je jedna z klasickych veci kde sa dostavame na nejaku formu hrania sa na krasu kodu a setrenie pisania. Z funkcionalitou kodu to nic nema.

    No řekněme, že z property se nestřílí. Budiž, ale property jsou moc hezká věc.
  • 3. 1. 2007 20:17

    Palo (neregistrovaný)
    Java píše že odstraňuje práci s pointery
    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.
    co mluvíte o statických výrazech není podmíněná kompilace
    public static final boolean DEBUG=true;
    ...
    if (DEBUG) {
       A();
    } else {
       B();
    }
    
    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.
    Není nad datové struktury přímo v syntaxi jazyka.
    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, ...).
    (a přitom mnohem kratší) kód vzniká. Tím také jako side effect vzniká kód s méně chybami.
    A uz sme zase pri pismenkach. Tie 4 pismenka ".get" nic nezhorsuju. Kod nie je o nic nebezpecnejsi. Proste vsetko su objekty a funkcie. Ziadne nativne asociativne pole netreba. Velmi jednoduche, aj ked rozumiem ze na nativnej syntaxe nie je nic vedecke.

    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.

  • 3. 1. 2007 21:16

    Miloslav Ponkrác
    .........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í.
  • 4. 1. 2007 0:41

    Palo (neregistrovaný)
    What about this:
    	private Number value1;
    
    	public A() {
    		if (PRECISION==HIGH) {
    			value1=new Long(0);
    		} else if (PRECISION==NORMAL) {
    			value1=new Integer(0);
    		} else {
    			value1=new Short((short)0);
    		}
    	}
    
    	public Number getValue1() {
    		return value1;
    	}
    
    Ak to skompilujete s PRECISION==HIGH vysledok bude:
    	private Number value1;
    
    	public A() {
    		value1=new Long(0);
    	}
    
    	public Number getValue1() {
    		return value1;
    	}
    
    And this, line by line:
    		a.put("some", a.get("some") + 'x' - a.get("huhu") * a.get("pocet"));
    		int b[]={3,4,5,6,7};
    		if (Arrays.binarySearch(b, 3) > -1) {
    			System.out.println("trojka je ve slovniku a");
    		}
    
    Podle stejného uvažování je u nás nejkvalitnější a nejhodnotnější časopis Blesk, protože ho čte nejvíc lidí.
    To neviem ja ho necitam, ale ten primer celkom nesedi. Groovy moze pouzivat tie iste kniznice, ma rovnaky runtime, stabilitu, skalovatelnost, ... . Od Javy sa lisi iba syntaxou, aj tak ho ludia az tak extenzivne nepouzivaju ako Javu, aj ked podla Vas by mali.
  • 4. 1. 2007 2:02

    Miloslav Ponkrác
    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.
  • 4. 1. 2007 2:55

    Palo (neregistrovaný)
    Ja som ale hned napisal ze podmienena kompilacia funguje okrem zmeny struktury. 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.
    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.
    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, ... .
  • 4. 1. 2007 12:07

    Miloslav Ponkrác
    .......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.
  • 4. 1. 2007 22:22

    Palo (neregistrovaný)
    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.
    Pokial musim robit nieco so 100M objektami tak som urobil nieco zle v navrhu ak ich musim drzat v pamati. Tu reziu ma instancia ktora uz v povodnom objekte je. Nova instancia je nastavena na NULL takze naozaj bude zaberat iba 4B v povodnom objekte. Ale ak potrebujete setrit tak to vyriesi dedicnost.
    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.
    Ja robim s vi/vim viac ako 12 rokov. V tomto ohlade by som sa oznacil za fanatika. Uz asi milionkrat som sa pokusal nejako poriadne integrovat Javu do VIM ale asi 3 roky dozadu som to vzdal. Vela veci sa da vo VIM nastavit ale nie je to ono. A Bram (klobuk dolu) nie je ochotny nejako integrovat Javu do VIM. Bol som niekolko rokov pripojeny do VIM a VIM-DEV mailingu a dodnes chyba univerzalne pripojenie na externe spustane programy ktore by sa dali univerzalne integrovat napr. sqlplus, ftp, ... . Na linuxe som to vyriesil malym scriptom ktory vyuziva FIFO file. VIM pouzivam na vsetko okrem Javy, ale niekedy na hromadne upravy aj pre Javu.

    Ja som sa naucil sustredit na vysledok nie na cestu. Javy mi pride ako dobry a univerzalny nastroj na riesenie vsetkych mojich problemov. Vasa problemova domena je asi inde. Vdaka za konstruktivnu diskusiu. Vela zdaru v praci.
  • 3. 1. 2007 21:37

    Miloslav Ponkrác_ (neregistrovaný)
    .........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í.
  • 2. 1. 2007 14:35

    Miloslav Ponkrác
    Vy zapomínáte na to, že "turing complete" je trochu málo, ale že ten jazyk musí být taky pohodlný, snadno udržovatelný, apod..

    Generování Eclipse není na obtíž pokud to neslouží jakožto zakrývání nemotornosti syntaxe Javy.

    K poslednímu odstavci, Java má všechno akorát se to musí napsat pomocí něčeho jiného, takže to vlastně nemá. Stejným způsobem dojdeme k tomu, že všechny jazyky mají vše. Všechno se to v Javě dá nějak řešit, ale je to jen z nouze ctnost. Není nad to, když je ze zdrojáku naprosto jasně vidět, co chtěl autor napsat a ne, že to nejdřív musel zparchantět pomocí něčeho jiného a zkoumat co čím v syntaxi emuloval.

    Nemám nic proti Javě, ale uvědomuji si význam dobré syntaxe programovacího jazyka, a v tom Java neexceluje. Zastánci Javy prostě neumí vůbec ocenit význam dobré syntaxe, když jim v tomhle Java nabízí akorát ohlodanou kost.
  • 2. 1. 2007 13:12

    Miloslav Ponkrác
    Pane, vy jste Javista, že? Právě že ta syntaxe má velký význam a jazyk s dobrou syntaxí je poklad. Zkuste si porovnat třeba syntaxi Pythonu, nebo Ruby, ochutnejte to intenzívně rok, nebo dva a vraťte se do Javy. Pochopíte.

    Význam knihovny je sice klíčový, ale jazyk se špatnou syntaxí je utrpení a značně zdržuje, i když má vynikající knihovny. Třeba mě přestože v Javě mám letité zkušenosti nesedí právě ta špatná a více, než chudá syntaxe Javy. Mě zase přijde směšné, když mi Javisti typicky říkají, že jim určité šablony Eclipse vygeneruje, což mimo jiné znamená, že Java je syntakticky tak neobratná, že Eclipse musí pro zvýšení efektivity práce generovat "typické sekvence" použití.

    To, že 50% programátorů neumí vytvořit generické typy znamená, že 50% je umí. A zbytek umí používat generické typy vytvořené tou půlkou. Sám tvrdíte, že si mají stáhnout knihovnu a jenom typy používat, tak Vaše argumenty si samy o sobě protiřečí. Typický Javista je rasista - když jsem na něco blbej, ať to raději neexistuje. Jak Vy víte, že to nepotřebují na řešení problému?

    Knihovny jsou velmi důležité, ale ostatní části taky. Navíc mám pocit, že o jazyku D nic nevíte, protože on je staticky typovaný stejně jako Java, tedy má striktní typovou kontrolu. Vy píšete, že jí nemá. Prosím, abyste příště propagoval Javu trochu chytřeji, než pomocí lží a pomocí dokazování, že o tématu nic nevíte. Děkuji.
  • 2. 4. 2008 15:55

    Lolq (neregistrovaný)
    dost informaci v cestine jsem nasel na tomto webu :
    http://d.over.cz/

    Je tam i tutorial a priklady , ikdyz celkem rozsahle teda :)

Byl pro vás článek přínosný?