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.
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.
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.
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.
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é kompilaceTo 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.
propertyA 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.
Java píše že odstraňuje práci s pointeryTo 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.
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.
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.
Pavel Chalupa je redaktorem zpráviček a příležitostným pisatelem článků na Root.cz.