Nejpoužívanější programovací jazyk pro programování linuxových aplikací je pravděpodobně pořád C, v závěsu za ním bude asi C++. C je jazyk, který byl navržen pro psaní operačního systému někdy v roce 1972. A 35 let poté se ještě stále používá pro tvorbu uživatelských aplikací. Sice už díky Bohu méně, ale stejně ještě pořád. Přiznám se, že tento jazyk, jakožto i jeho objetově orientovaného bratra se dvěma plusy nemám moc rád. Hlavní důvod mojí zášti je nutnost explicitní alokace a dealokace paměti. Nejde jenom o tu práci a o to, že by se měl kvalifikovaný člověk neměl podle mě pokud možno zabývat takovými malichernostmi jako jsou problémy procesoru s pamětí, ale hlavně jde o to, že z toho pramení nepříjemné chyby – zažil jsem „machry“, kteří ohrnovali nos nad jazyky vyšší úrovně, ale jejich kód byl plný memory leaků.
Pokud se tedy těmto jazykům (Pascal řadím do stejné rodiny fuj fuj pointer-oriented jazyků) chceme vyhnout, máme dvě možnosti – použít interpreter postavený nad nějakým virtuálním strojem nebo použít kompilovaný jazyk, který pointerům neholduje. JRE považuju za poměrně velkého molocha, projektu Mono nevěřím z licenčních důvodů a jazyky jako Python, Ruby atd. jsou možná prima, ale někdy se ukazuje, že rychlostí ne zcela vyhovují. A obecně přinášejí virtuální stroje dodatečné závislosti a až občas příliš odstiňují aplikaci od nativního prostředí. Lákají mě kompilátory do nativního kódu.
Existuje možnost zkompilovat do nativního kódu Javu, existují však i (podle mého názoru) zajímavější jazyky, které lze zkompilovat do „strojáku“. Jedná se hlavně o funkcionální jazyky, které mají i spoustu dalších výhod – snadnější statická analýza kódu, propracovaná teorie, snadná paralelizace funkcionálního kódu, bohaté výrazové prostředky atd. Asi nejznámějším funkcionálním jazykem je Lisp a jedna z hlavních větví se jmenuje Common Lisp. Velmi dobrých výsledků dosahují překladače CMUCL a zejména SBCL, který je ale o něco hůře přenositelný. Do nativního kódu lze přeložit i Haskell – ten patří mezi čistě funkcionální jazyky nebo Erlang, který se specializuje na konkurenční a distributivní zpracování dat.
Mě ale v poslední době zaujal OCaml, který má výhodu například v poměrně čitelné syntaxi, standardním objektovém rozšíření, standardních nástrojích pro tvorbu překladačů (ocamllex a ocamlyacc), makrojazyku (camlp4), debuggeru a profileru a generátoru dokumentace (pravděpodobně inspirovaném Javou). Právě v OCaml zpracovávám projektík, který analyzuje závislosti mezi balíčky v linuxových distribucích. Je to pro mě nový svět a docela mě to baví, snad o tom brzy napíšu víc.
Závěrem bych chtěl napsat, že bych byl rád, kdyby z Linuxu nějaký lepší jazyk výrazně vytlačil C. Nemusí to být žádný ze jmenovaných, ale moc dalších možností momentálně nevidím. A co Vy?
[3] S Adou nemám žádné zkušenosti, ale některé věci s ní má OCaml podobné, např. striktní kontrolu typů. To je vůbec dost podstatný rys tohoto jazyka a pro lidi zvyklé na dynamické jazyky může být občas dost frustrující. V OCaml bez explicitní konverze člověk ani nesečte int s floatem. ;-)
Svet je dnes plny "znalcu", kteri zpochybnuji stare dobre veci.
Je jim to houby platne. Tak jako kvuli jejich pranim nezmizi treba obycejny papir, bude se spousta veci delat i nadale v C. A spousta zbytecneho mista se popise exhibicemi o tom, jak "ja jsem ten progresivni expert, ktery vi co je pro druhe dobre"...
Je to spis zabavne nez aby to cloveka rozcilovalo :-)
[3] V ade to taky nelze secist, ale to beru jako plus. Nicmene ada umi mnohem vic. Typovani je dotazeno tak, ze lze specifikovat rozsah jednotlivych promennych (napr. integer od 1 do 10). To pak velmi vyrazne pomaha proti chybam jisteho charakteru (v C docela beznym). Velmi dobre se pracuje s vyctovymi typy (ktere ve spouste jazyku chybi nebo jsou odflakle ala cislo). Objekty a generika jsou samozrejmost, podpora viceulohoveho zpracovani primo v syntaxi jazyka je pozoruhodna. A hodne se mi libi, ac je to jazyk vyssi urovne, moznost interfacovani s ostatnimi jazyky a hardwarem, kde je mozno nenasilne ale spolehlive specifikovat napr. bitove reprezentace nebo adresy objektu, metody alokovani, zpusob importu a exportu v binarnich souborech.
Obecne je ada vnimana jako jazyk, v kterem lze psat velmi spolehlive aplikace pro zivotne dulezite systemy. (Jelikoz pohani veci jako letadla, vlaky a rakety tomahawk :) Ale protoze je k dispozici GPL prekladac (GCC) a nekolik vazeb k bezne pouzivanym knihovnam (gtk, xml, gl, ...) lze v tom programovat i v nasem "malem" svete.
[8] Díky za úvod. V OCaml je trochu problém v tom, že na každý typ se používá jiná sada operátorů a pak je samozřejmě problém v zadávání konstant. Asi by bylo možné definovat typ, který má rozsah od 1 do 10, ale už by to nebyl integer a musela by se použít jiná syntaxe literálů nebo pokaždé znovu explicitní konstrukce typu. Výčtové typy jsou v OCaml také symbolické a nekryjí se s intem.
C++ je jediny univerzalni programovaci jazyk s rozumnym vykonem vyslednych binarek. Ze nekdo neni schopen napsat program, ktery neleakuje a nepada, je jeho debilita. To same plati i pro jeho zamestnavatele.
C se pouziva prevazne z historickych duvodu a taky protoze ze pro spoustu lidi je C++ prilis slozity jazyk.
Funkcionalni programovani je fajn, nicmene vsechno se v tom opravdu psat neda (i kdyz uz tady mame i window manager).
Java je skvela pro firmy, jelikoz si pak muzou dovolit najmout mnohem mene zkusene programatory.
Skriptovaci jazyky jsou vhodne vyhradne k prototypovani, pripadne psani webu.
[11] Ad výkon - http://dada.perl.it/shootout/craps.html
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Některé méně známé jazyky si vedou dost slušně.
Ad funkcionální programování - většina funkcionálních jazyků nabízí i imperativní prvky pro případ potřeby.
Ad méně zkušení programátoři - a v OSS se zřejmě méně zkušených programátorů pohybuje hodně, když programy leakují a padají (a mají bezpečnostní díry). Je otázka, co s tím
[11]: Let_Me_Be: A kolik velkych projektu (kde se pocty radku kodu pocitaji minimalne na desetitisice) uz mas v C++, kolika takovym produktu jsi musel delat support pro zakazniky?
Existuje zname pravidlo, ze pravdepodobnost chyby narusta umerne velikosti kodu, u spatnych programatoru rychleji, u lepsich pomaleji, nicmene u velkych projektu proste chyby vznikaji, i kdyz to pisi velmi zkuseni lide.
A to je prave misto, kde prichazeji na scenu jazyky jako Java ci C#, poskytuji velkou platformu existujiciho (odladeneho) kodu, na ktere se da velmi dobre stavet, snizuji moznost (a dopad) chyb a zaroven umoznuji rychly vyvoj aplikaci - a to je presne to, co potrebuje bussiness sfera.
Ja mam C++ velmi rad, pisu v nem, ale treba predstava toho, jak nahrazuji Javovsky aplikacni server pro Javu EE vlastnim C++ resenim, mi prijde jako sci-fi... Vyvoj by se protahl o mesice (ne-li roky), zvysila by se pravdepodobnost vyskytu chyb, zobtiznila laditelnost etc. A ze je vysledne reseni vetsi, bere o neco vice pameti a je pomalejsi? No a? Uvedom si, ze treba takove Core 2 Quadcore stoji tolik, co nekolik hodin programatorova casu... Takze je asi jasne, co se vyplati...
Trochu mi to pripomina napr. embedded vyvojovou scenu, kde se najdou skalni odpurci programovani cehokoliv jineho nez assembleru a pohrdlive se divaji na kazdeho, kdo si dovoli pouzivat C:-) Celkem jsem zvedavy, kdy se zacne prosazovat v vetsi mire embedded managed kod (at uz C# nebo Java) - na Javu na to dokonce je nativni podpora procesoru (Jazelle)...
Mimochodem, Java vznikla jako reakce na komplikovany a neefektivni vyvoj a udrzbu C++ aplikaci v Sunu :-)
Ono totiž šíleně záleží na tom, co děláš. Pro systémové programování asi zatím nic lepšího než C není (případně C++) a to právě díky tomu, že to je v podstatě čitelnější assambler. A je to rychlé právě kvůli ukazatelům a přímé kontroly paměti. Na jednu stranu stoupá výkon hw, na stranu druhou klesá ochota lidí čekat. Takže stále ještě to C. A myslím si, že ještě dlouho (dokud se nezmění architektura). Pro klasické aplikační programování je C neefektivní pokud píšeš GUI aplikace. Ale třeba vala změní situaci http://live.gnome.org/Vala . Těžko být prorokem.
Mozna se v blizke budoucnosti dockame i vylepseneho JRE, ktere by konecne mohlo byt rozkouskovano na mensi dynamicky dohratelne casti. Protoze dnesni stav, kdy se i pro spusteni jednoducheho "Hello world" naalokuje pres 20MB, je napr. pro mensi utility dost neunosny a pekne to dokresluje rozsireni Javy na desktopech (servery jsou samozrejme jina vec).
Lispovka vetev jazyku je urcite zajimava, ale podle reakci spousty programatoru by na tyto jazyky tezko prechazeli. Proste imperativni kod je jim mnohem blizsi.
Jedna vec je vsak mit jazyk a druha podpurne knihovny a nastroje. Treba "naroubovani" OpenGL na Lisp je udelano pekne hnusne imperativnim kodem (v podstate 1:1 prepsani ceckovskych volani), i kdyz by to v Lispu slo udelat podstatne kvalitneji.
Mozna bych jeste vyzkousel jazyk D, ten nevypada spatne.
jen si dovolim podotknout, ze ten python neni zas tak pomalej. zvlast, kdyz clovek naprogramuje ty hardcore casti v c++ a pouziva to v pythonu jako modul. kdyz to srovnam s cimkoliv jinym, tak mi porad vychazi nejlip psat nektery veci v c++ (tam, kde jde primarne o vykon), nektery veci kombinovat a nektery veci psat jenom v pythonu (tam, kde o vykon tolik nejde a naopak mi jde o citelnost kodu, jeho snadnou rozsiritelnost atd.)
Díky za další zajímavé reakce.
[22] Jistě, Python lze urychlit mnoha způsoby - napsáním vlastních extension modulů v C, Pyrexu, (koneckonců i v tom OCaml, viz projekt Pycaml) použitím PyInline, nasazením Psyca... Na druhou stranu ale zase při psaní multiplatformních programů vznikají další problémy; například pro kompilaci rozšiřujících modulů pod win32 je třeba instalovat (pokud vím - samozřejmě pokud se bavíme o klasické binární distribuci Pythonu) celé velké Visual Studio (měla by naštěstí stačit verze expres). Ale jinak je mi řešení tohoto typu relativně sympatické, pokud pro konkrétní nasazení nejsou významné překážky.
no vezmime si jazyky na aplikacne programovanie
C - podla mna C _najkrajsi_ jazyk aky kedy existoval, bohuzal je to prilis tenka abstrakcia nad hardwarom, tazko sa to optimalizuje (pointery)..., a pisat vacsi program v C je strata casu (v jave to mam zlepene za tretinu casu)
C++ je asi najlepsie co momentalne mame ale je to _komplikovane_ (ukazte mi komplikovanejsi jazyk ako C++!) a chcelo by to garbage collector (mozno v kombinacii z dakym boehm GC... hm..)
Java - nema smerniky ale aj tak sa optimalizovat neda (vsetko sa alkouje na halde, vsetky pretypovania su dynamic_cast). okrem toho nema unsigned typy, vsetky typy <int su int atd... a 100 (alebo kolko) megovu standartnu kniznicu... privela kompromisov na zjednodusenie jazyka. btw swing vyzera ako z doby kamennej...
.NET/Mono - neviem :-) ale z toho co som cital, myslim ze riesi vacsinu problemov javy ale mam k nemu z principu negativny postoj :-)
skriptovacie jazyky maju jasne nevyhody (a vyhody) ale bavme sa o kompilovanych jazykoch. a funkcionalne jazyky nepoznam :-D
hmm takze co mi zostava ? Ada? Eiffel? D? ... aj tak to bude C/C++ ... nic lepsie (= pouzitelnost + efektivnost kodu + rozsirenost + rozsiretelnost + dostupne kniznice) jedoducho nie je ... co je skoda.
[21]: Na to "rozdelene" JVM se taky tesim, vypada to velice slibne. Jinak tech 20MB standardni knihovny je standardne sdileno mezi procesy.
[24]: ad java a optimalizace:
1. To ze neni explicitni moznost alokace na stacku neznamena, ze to JVM nedela (treba Sunovske JVM to docela dobre dela)
2. Zrovna pointery jako nutnost pro optimalizaci nevidim.
3. Ta std. knihovna nema 100MB, ale cca 20-30MB, sdilena mezi procesy.
4. Nizkourovnova optimalizace je jenom jedna z forem optimalizace a troufam si tvrdit, ze v drtive vetsine pripadu clovek nepotrebuje plne optimalizovany kod (a ten pak stejne pisete na miru architekture - jiste, pokud potrebujete maximalni vykon, je C/C++ vybornym kandidatem - prikladem budiz vypocetni systemy, graficke enginy, etc.). Ale treba Managed Direct3D taky ukazuje, ze to jde i v managed kodu docela solidne...
V Jave samozrejme optimalizovat jde a hodne, jednak algoritmicky, jednak znalosti fungovani JVM (typicky treba GC).
ad .net a mono: Mono je velmi, velmi pomale, na rozdil od .NET od Microsoftu. C# je blizsi C++, vice nez Java, coz muze byt pro nekoho vyhoda i nevyhoda...
[25]: Tak to bych rozhodne nesouhlasil, C++ s GC je velice pekne a uzitecne (navic jistou formu GC ma dost casto vetsina vetsich C++ aplikaci).
[26] Garbage collector pro C++ je overkill. Staci chytre pointery.
[19] Na webu ma java opravnene misto, tam si myslim ze je java celkem kralem, o tom se tady ale nebavime. Pokud jde o desktop tak fuj, pryc s ni. Veskere aplikace, ktere prerostou urcitou velikost jsou budto tak pomale, ze se to vubec neda pouzivat, pokud clovek nema 2GB RAM a high end procesor, nebo jsou psane vicemene C-stylem.
hlavne by si mali vsetci koderi uvedomovat pravidlo 'use the right tool for the right job'
"Hlavní důvod mojí zášti je nutnost explicitní alokace a dealokace paměti." - explicitna dealokacia programatorom nie je nutna, skus si dostudovat boost (predpokladam, ze STL poznas podrobne ked si si dovolil pisat takyto clanok). Machrov, ktori leakuju pamat ale ohrnuju jazyk nad vyssimi jazykmi (ja lubkam ruby :)) tiez nemam rad, vykrikuju ze C++ forever ale ani poriadne nevedia kodit.
Je pravda ze vacsina vyvoja co sa robi v opensource by nemusela byt v C (vid napr. bindingy pre Kde/Qt su kazdy realne rozsireny jazyk, predpokladam ze u gnome/gtk to bude podobne), ale kernel, glibc a daktore kniznice (napr. veci typu openssl/gnutls) by podla mna mali zostat v C s bindingami na zbytok sveta.
A pokial ide o C++ tak mimo Kde ho pouziva minimum projektov.
D ma velky potecial, kompiluje do binarky, je rychly, muzete pouzivat GC nebo nemusite, syntaxe blizka C/C++ primy interface k C knihovan, bohata zakladni knihovna. Pro systemove programovani muze s prehledem nahradit C++ a Javu, zatim je ale pomerne malo knihoven napr. pro GUI, DB atd
[29] Vytvářet nové univerzální jazyky má asi smysl málokdy; už teď jich je přebytek. O flame mi nejde; kdybych chtěl pořádný flame, tak si vyberu jeden jazyk a ostatní pomluvím.
[30] Při zmínce o počtu aplikací v C++ jsem vycházel ze statistik na serverech jako freshmeat.net. Je pravda, že třeba na tom Freshmeatu už C++ předhonila Java.
Je pravda, že v C++ to s tou alokací není až tak špatné jako v samotném C. Zase ale přináší jiné nevýhody - problémy se stabilitou ABI atd.
To je zas debata :-D I v dnesni dobe gigahertzovych multi-core procesoru jsou porad aplikace, kterym je to malo. Takove ma smysl psat v Cecku. Stejne tak jako ruzne veci blizko systemu. Samozrejme psani v C neni pro kazdeho, alespon se pozna kdo umi opravdu programovat :-)
Java a .NET jsou fajn pro jiny druh uloh - "prehazovani dat", velke projekty, projekty kde na vykonu az tak nezalezi atp. .NET ma vic featur, ale IMHO obcas az zbytecne prilis. Uplne by stacilo do Javy doplnit vystupni promenne a explicitni podporu enum a nemel bych zavaznejsich namitek :-)
Moc se mi líbí následující citát.
[6.5] Is C++ better than Ada?
Anyone who argues in favor of one language over another in a purely technical manner (i.e., who ignores the dominant business issues) exposes themself as a techie weenie, and deserves not to be heard. Business issues dominate technical issues, and anyone who doesn't realize that is destined to make decisions that have terrible business consequences — they are dangerous to their employer.
Loučím se s pozdravem: Zhyňtež vy Ruby, Pythony a Nety! ;)
Tak trošku nechápu, co má autor pro alokaci a dealokaci paměti....
Pamět je zdroj (resource) jako cokoliv jiného... a je věcí dobrého vychování vypůjčený zdroj zas vrátit operačnímu systému.
Stejně jako se nikdo nerozčiluje, že je potřeba po použití zavírat soubory nebo TCP/IP spojení, nemělo by nikoho vzrušovat, že je potřeba uvolňovat alokovanou paměť.
Pokud to nechcete v C++ dělat "ručně", vůbec nic Vám nebrání použít "smart pointery" nebo podobnou techniku, která proces memory managementu zautomatizuje.
Neřekl bych, že C++ (C je svými možnostmi na podobné automatizace chudší, ale zas je o něco výkonější) je lepší nebo horší než jiné jazyky... ten rozdíl je trošku jinde.
Jazyky typu C/C++ Vám (programátorovi) nic moc nenařizují... dávají Vám svobodu rozhodnutí, právo volby. Ale s onou svobobodou - zcela samozřejmě, podobně, jako v jakékoliv jiné oblasti lidského bytí - na Vás kladou i určitou zodpovědnost...
Nedívejte se na to tak, že Vás C++ nutí alokovat a dealokovat paměť. Ono Vám dává možnost, mít nad tímto procesem plnou kontrolu :-)... A v C je to podobné, jen té zodpovědnosti je ještě o fous víc...
Co mně osobně chybí na C++ a co je (resp. bylo) dle mého názoru revolučního na Javě, je opravdu široký subsystém knihoven. Ne jen pár základních funkcí (objektů, šablon), ale obecně dostupný framework zahrnující práci se soubory, síťovými prvky, GUI...
Protože standardní knihovny Céčka byly dostačující vdobě jeho návrhu. Snad i v době prvního standardu C++... ale dnes je to opravdu málo...
Hlavni vyhoda C je v jeho univerzalnosti. Neni snad zadny jazyk, pro ktery by existovaly prekladace pro tolik platforem a tolik uz hotovych knihoven (myslim ze treba java porad nema uplne OpenGL) a v kterem by se dalo napsat vsechno od operacniho systemu, ovladacu az po GUI ci web aplikace.
Shrnuti tvrzeni nesoucich nejakou informaci, ktera je falzifikovatelna, neni vseobecne znama a popisuje objektivni realitu. Tvrdi se, ze C bylo navrzeno pro psani operacniho systemu, bez uvedeni zdroju. Dale se tvrdi bez uvedeno podkladu ze z explicitni alokace prameni chyby.
Dale se dozvidame, ze jedna z hlavnich vetvi LISPu se jmenuje common LISP, bez upresneni, co znamena pojem "vetev" v programovacich jazycich a jak se urcuje, zda vetev je hlavni nebo ne. To je opet bez uvedeni zdroje.
Dale autor uvadi, ze jazyk Haskell lze prelozit i do nativniho kodu a ze se radi mezi ciste funkcionalni jazyky.
Nakonec se dozvidame, ze existuje jazyk OCaml, ktery ma objektove rozsireni, nastroje pro tvorbu prekladacu a makrojazyku, debuger, profiler a generator dokumentace.
Clanek na to jak malo informace relevantni pro ctenare obsahuje by mohl byt psan usporneji.
No, to je pekny flame ;)
Podle mne na kazdy task je dobry jiny jazyk - po skriptovanem jazyku sahnu kdyz potrebuju napsat neco rychle, nejde mi tolik o vykon.
Na WEB apliakce, a GUI legrace, kde zatimco user klikne, tak ma program cas sam sebe 2x zkompilovat, tam lze pouzit cokoliv.
Ale proboha - jak chcete napsat v nejakem C#, ci podobnem bazmeku ovladac jadra, nebo samo jadro ??? Jak tam chcete pracovat bez ukazatelu a alokaci s daty podavanymi primo hardwarovymi prostredky ??
Na toto by mne zajimala odpoved. Pokud si pamatuji (posledni dobou pisu jen ty skripty a pak hardcore C a C++ kod) tak toto v .net a jinych podobnych garbage orientovanych jazycich slo tak tezce, az vubec!
BTW: casti jadra a ovladacu se stale nekdy pisou i v assembleru, nebot da rozum, ze kdyz nekudy jde vykonavani programu mnohokrat za vterinu, tak tam se opravdu vyplati optimalizovat...
Mimochodem, chyby v referencich techto "objektu" vedou taky k peknym leakum, jen se hur hledaji, nebot nad pameti neni vubec zadna kontrola...
Dovoluji si tvrdit, ze zakladnim palivem techto flames je vzrustajici procento lidi, kteri NETUSI, jak pocitac ve skutecnosti funguje, nicmene maji erudovany nazor a potrebu davat najevo sve preference ohledne lecjake modni ptakoviny.
Skutecnost je totiz takova, ze assembler bude v urcite mire potreba vzdy, a nic lepsiho nez Ccko coby nadstavbu nikdo doposud nevymyslel a v praxi neoveril - a proto se i po 35 letech pouziva. Zato ruznych pokusu o ultra-BFU-friendly HLL jazyky a frameworky tu jiz bylo - s timtez tristnim vysledkem. Vzdy se ukazaly jako nedostatecne, pomale, a aplikace v nich vytvorene nesly jejich charakteristicke stigma. Je potreba vytvaret dalsi podobne nehoraznosti, nebo se uz svet IT pouci?
Podobne jako nejde udelat program, ktery nauci cloveka s hudebnim hluchem virtuozne hrat na housle, nelze ani sestavit programovaci jazyk/prostredi, ve kterem neznaly clovek napise korektni a efektivni aplikaci.
[47] Opravdu doporucuji se mrknout na 1.5 (Tiger), je tam moc peknych veci - evidentne je zde videt prace Joshuy Blocha a hlavne strach Sunu pred konkurenci :-)
namatkou:
1) for-each konstrukce
2) o kolekci se da specifikovat datovy typ
3) ony vycty jako soucast jazyka
4) automaticky prevod primitivnich datovych typu na jejich obalovou tridu, tj. int<->Integer apod.
ten ctvrty bod by mohl resit vas problem s vystupnimi promennymi (tedy jestli to dobre chapu, tak potrebujete vracet napriklad 3x int apod.)
Pokud se nechcete prokousavat Sunovskymi materialy, kde se to jen hemzi superlativy :-), tak i na Rootu vysel o Java 1.5 (Tiger) clanek.
namatkou kus zdrojaku, na kterem prave makam a ktery nektere vlastnosti (for-each a typovane kolekce) ukazuje:
ArrayList<String> attributeNames=itemBean.getAttributeNames();
ArrayList<String[]> attributes=new ArrayList<String[]>(attributeNames.size());
for (String attributeName:attributeNames) {
}
[47][48] jeste se pokusim ozrejmit ten automaticky prevod int-Integer atd. Automaticky neni vzdy, ale kdyz prekladac pozna, ze potrebujete z Integeru udelat int, tak tu konverzi provede sam. muze byt tedy rozdil mezi zapisem 1+x a x+1 pokud x je typu Integer.
Prikladek, kdy si s Integery hrajeme (skoro) jako s primitivnin datovym typem:
public void inc(Integer[] arr)
{
for (int i=0; i<arr.length; i++) {
arr[i]=1+arr[i]; //= 1+arr[i].intValue();
}
}
Integer[] pole={10,20,30}; // = new int[]{10, 20, 30};
inc(pole);
[44]: A kdo by chtel psat v .NET nebo Jave jadro proboha?:)) Kazdy jazyk je uplne na neco jineho... Jinak ty leaky se hledaji docela dobre, kdyz je mozne se presne podivat na to, ktery objekt kolikrat existuje a proc.
[45]: tvoje produktivita prace musi byt skutecne uzasna :)) Samozrejme, ze psat veci pro jadro, system. knihovny, etc. se musi nizkourovnove, ale to je tak vsechno, dal je to o tom, co delate a kolik vas to stoji, co se vyplati. A managed jazyky jako Java ci .NET se rozhodne vyplati, naklady jsou radove nizsi, hardware je levny, vyvoj drahy, takze neni co resit...
[48] V 1.5+ pisu obcas nejake soukrome veci, o foreach (1) a templatech (2) jsem vedel. Enum a automaticka konverze je pro mne novinka (fakt bych si mel ty release notes nekdy precist :-) ).
Ta konverze _trochu_ pomuze. Ostatne prave dnes jsem napsal metodu ktera vraci 2x datum tim stylem, ze se ji predaji dva Date objekty a ona jim nastavi cas :-) Bohuzel zdaleka ne vzdy se to da takhle osulit; neexistenci vystupnich promennych povazuji za nejvetsi problem Javy :-/
Vypocet typu "praca programatora je draha a HW je lacny" su typicke manazerske kecy odtrhnute od reality. M$ usetri na programovani a skoro cely svet si musi kupit novy HW. Alebo programator usetri hodinu prace a vsetci, co pouzivaju ten program, musia pri kazdom spusteni cakat dve minuty (tisice ludi krat tisice spusteni).
[52]: Mimo realitu jsou leda tak lide, co si mysli, ze cas na vyvoj nic nestoji :-) Konec koncu, podivej se, jak vypada realny softwarovy vyvoj - tam se s cenou prace pocita a velmi dobre pocita.. A proto maji jazyky jako je .NET ci Java uspech - zjednodusuji vyvoj a tim padem snizuji naklady... Takze co je pro firmu vyhodnejsi? A ne, opravdu komercni SW firmy nejsou verejne prospesne organizace..
[51] ano, ta konverze neni vzdy upotrebitelna, napriklad obalove tridy typu Integer jsou nemenitelne, stejne jako String. To znamena, ze ani v metode void add(Integer x) to "x" navenek nelze zmenit. Jedine to cele obalit do dalsi tridy - napriklad Complex, Point atd. vlastne nedelaji nic moc jineho.
Jde o to, jak by to Java mela delat - jit Placalovskych stylem (klicove slovo+pri volani vlastne nevim, jaka konvence je pouzita) nebo C++ovym stylem (predavani "reference na referenci")?
"A proto maji jazyky jako je .NET ci Java uspech" - kde proboha? Zatim jsem si blaha, poskytovaneho temito (bez prominuti) s*ackami neracil vsimnout.
Ano, cvicena opice v tom rychle naklika nekvalitni nanicovatou aplikaci pro urednici, s pomerem velikost*hwnaroky*nutny_environment / vykon presahujicim vsechny rozumne meze... pocitac holt nejak funguje, a kdokoli bude propagovat prilisne abstrahovani od tohoto neoddiskutovatelneho principu, po zasluze zhyne, zavalen gigabyty nesmyslneho, neefektivniho a spatneho kodu, co ani na jeho drahem HW uspokojive nepobezi. Jo, v tomto je to spravedlive. :).
Javu jsem na svem pocitaci zkousel a uspech neslavila - ac se jednalo o Linux s poslednim GCC, nezkompilovalo se to.
Meli syntakticke errory ve zdrojaku C++. Pry je Java portabilni, haha.
Podobne jsem pohorel s Perlem. Potreboval jsem aby muj jednoduchy perlovy skript (pro Ronju) z Linuxu bezel na OpenBSD. Jenze on pouzival binding na gdbm a ten v tom perlu co dodava OpenBSD nebyl. Neexistoval ani jako modul. Dodaval se defaultne v tarballu perlu. Zkusil jsem stahnout tarball perl zkompilovat a nainstalovat, ale prestal zase chodit balickovaci system OpenBSD protoze oni to maji asi nejak patchnute. Tak jsem skript po dlouhem moreni a ruznych machinacich a pokusech to rozchodit prepsal do C a od te doby to chodi vsude a jako vino :)
[48] v jave ale stale kvantum veci chyba (unsigned typy omg!!!), generika tiez nestoja za vela (vdaka spatej kompatibilite... chcelo by to proste new T()), volanie odkazom (tym by sa usetrilo kvantum zbytocnych obalovacich tried, alokcie a garbage collectovania pamati), smerniky na metody (tusim delegaty v C#) - zase by sa usetrili zbytocne kvazitriedy o jednej metode a pomale invokeinterface ... normalny gui toolkit (pridat swt do standartnej kniznce?). a keby sa tak este hello world nestartoval 2 sekundy ... :-)
aspon tie unsigned typy a smerniky na metody ... sun ... prosim :-)
[57]: Ty asi v komercni sfere neprogramujes, ze?:-) Programovat si doma na kolene nebo v akademicke sfere je prece jenom trochu rozdil od toho, kdyz delas vyvijis produkty v komercni sfere, ktere pak musis supportovat a ktery musi fungovat, nemuzes si dovolit ztracet na tom pri vyvoji cas (protoze jinak prodelavas).. A presne z techto duvodu ziskava Java a C# (a .NET), protoze pri vyvoji znacne casti aplikaci ani nepotrebujes aby to bezelo na starem HW s malo pameti (samozrejme to neplati vzdy a vsude) - resp. investice do podpory takoveho HW se nevyplaci (=naklady na vyvoje v C).
Podle podobne logiky bysme vlastne meli programovat jenom v assembleru :)
Plně se ztotožňuji s [40]!
Celá ta myšlenka článečku mi připadá poněkud zvrácená. Vezmeme-li to přísně, tak univerzální jazyk prostě neexistuje. Každý je vhodný na něco jiného.
V dnešní době je jazyk C nenahraditelný a žádné Javy, C# a o jiných jazycích ani nemluvím ani v nejmenším nemohou aspirovat na to, aby ho někdy nahradily.
To onanování nad přísnou typovou kontrolou je sice hezké, ale mám takový pocit, že takto může jásat jedině člověk, který snad nikdy neprogramoval něco většího. Je to podobné, jako jásat nad nepřítomností příkazu goto. Jestli jsem něco např. na Pascalu nesnášel, tak to bylo zrovna toto. Tahle tutorovská role překladače mne nutila akorát vymýšlet různé obezličky a okliky, jak provést to či ono, ale ve výsledku to nemělo pozitivní vliv ani na čistotu kódu, ani (nebo spíš už vůbec ne) na jeho efektivitu.
Můj názor je ten, že u programovacích jazyků platí totéž, co v celém životě. Pokud začínáme, necítíme se jisti v kramflecích nebo potřebujeme něco jednoduššího rychle, tak nám budou vyhovovat "přísnější", "bezpečnější" a "jednodušší" nástroje - auto s automatem, systém a la Windows, polévka v sáčku a konzervy, na zdění prefabrikáty a předem namíchané maltové směsi, na stavbu letadýlka stavebnice, na programování Java...
Pokud ale chceme skutečně tvořit, tak potřebujeme prostředky, které nás nebudou omezovat, ale přesně naopak - pomohou nám realizovat se. Samozřejmě že při práci s takovými nástroji se snadno můžeme pořezat nebo všechno pokazit, ale to jen proto, že to neumíme. Zkušený řezbář už se řízne jen sem-tam. Stejně jako zkušený programátor v C udělá chybu při práci s pamětí jen málokdy.
A příklad embedded aplikací tvořených v něčem jako .NET - tak to je skutečně vrchol neschopnosti. Je to jako kdyby někdo potřeboval napsat na kus papíru dopis či vzkaz, ale už by mu připadalo příliš komplikované vzít tužku a napsat to rukou. Bez počítače, editoru ve stylu Word a laserovky už by to odmítal dělat.
O jednom moznem smeru vyvoje kompilovanych jazyku vim, ale nepovim. :) Nejprve chci tento problem analyzovat sam; zatim se to zda pomerne slibne (prinejmensim jako vyzkumne pole). Nicmene, nemyslim, ze by na to nikdo jiny nemohl prijit, takze urcite nebudu prvni, kdo se o neco takoveho pokousi. Zajimave je to tim, ze je to na opacnou stranu, nez je smer strukturovane programovani -> objektove orientovane programovani (kam se ted vrha veskery vyzkum).
[60] Je pravda, ze unsigned tam chybi, ale zatim jsem na to "nenarazil". Stejne tak jako ty delegates se zatim drzely v unosne forme :-)
[62] 'To onanování nad přísnou typovou kontrolou je sice hezké, ale mám takový pocit, že takto může jásat jedině člověk, který snad nikdy neprogramoval něco většího.' Zrejme pod pojmem "neco vetsiho" myslite "neco co ma vic jak 1000 radek" :-) V opravdu velkem projektu je potreba dodrzovat konvence a pokud mozno neprasit. To plati i o goto; za poslednich nekolik let jsem ho pouzil pouze na "emulaci" bloku "try - finally" ;-)
Nikdo nerika, ze Java nahradi C, ale ani C nemuze plnohodnotne nahradit Javu (nebo nejaky jiny vyssi jazyk), je to proste o necem jinem. Ne ze by se to v C nedalo napsat, ale cas na napsani bude nekde dost jinde. Mimochodem - znam jednu oblast, kde je C dost spatne pouzitelne - tam kde musite vice pracovat s texty.
Díky všem za další příspěvky.
Chtěl jsem reagovat hlavně na [62], ale udělal to za mě Michal Kára. Jenom doplním, že si skutečně myslím, že příkaz goto má hlavní význam v jazycích, které mají slabé vyjadřovací schopnosti - ten klasický Pascal například sice zná goto, ale nezná žádné příkazy pro řízení cyklu o obsluze výjimek nemluvě. Další výborné řešení, které eliminuje potřebu dělat explicitní clean-up, je pythonovský příkaz with - nadefinuju si blok, ve kterém budu používat nějaký soubor a on se mi při ukončení bloku (normálně i pomocí výjimky) zavře automaticky. Tomu já říkám tvořivost; prasení pomocí goto je tak maximálně "lidová tvořivost" nebo z nouze ctnost.
Přílišná typová kontrola zdaleka neznamená, že to nebude zprasené. Právě naopak - pokud ji nemáte, můžete si ji konvencemi ustanovit. Pokud ji máte a musíte s ní počítat při návrhu ať chcete nebo ne, může to naopak zprasit hodně věcí. Ne nadarmo se říká, že méně je někdy více. Když vím, že jedna proměnná může mít různé, avšak smysluplné a dobře definované významy, pokud je nahlížena pohledem různých datových typů, nevidím důvod, proč toho nevyužít. Ovšem jazyky se striktní typovou kontrolou si myslí, že jsou chytřejší, než autor programu. Ikdyž - dnes tomu tak často opravdu bývá.
Pokud jde o goto - tak bych řekl, že vedle ukazatelů je to jedna z nejnebezpečnějších, ale zároveň nejúčinnějších zbraní. Pár dobře použitých goto v rámci funkce může kód významným způsobem současně zrychlit, zkrátit a zpřehlednit (ne, nezbláznil jsem se, skutečně říkám zpřehlednit).
Jazyky se "slabšími vyjadřovacími schopnostmi" dle mého názoru především nepředpokládají, že programátor je vůl a že překladač ví nejlíp, co je pro mě dobré a že dokáže všechny možné eventuality podchytit nějakou svou na míru šitou konstrukcí. Místo aby mi umožnil použít goto, které by vedlo k vygenerování jedné strojové instrukce, jež by můj problém řešila nejjednodušším možným způsobem, tak mě "chytré jazyky" nutí splácávat dohromady různé podivné balasty, jejichž opodstatnělost překladač nikdy nedokáže posoudit a o jejichž výsledné efektivitě by se dalo dlouze polemizovat. A můžete si klidně říkat že je to lidová tvořivost a prasení, stejně moje goto bude mnohem efektivnější, než vaše try-catch nebo with nebo co to bylo za příklad a podobné serepetičky. Vždycky mě fascinuje, jak určitý typ lidí cítí potřebu vnucovat ostatním svá dogmata. Řekněte "goto se mi nelíbí, protože ho neumím efektivně používat" místo toho, že je to prasárna a lidová znouzecnost. Vždyť je to jak zatracovat dláto a ruční hoblik, protože je k dispozici protahovačka a frézka - to sice ano, ale ty dva prvně zmíněné nástroje, ač mnohem jednodušší, jsou nesrovnatelně univerzálnější. Mně nepřirostlo k srdci OOP a také netvrdím, že objektové programování je prasárna. Proti gustu žádný dišputát...
Můj názor je takový, že jedině autor programu ví nejlépe, CO chce udělat a JAK to chce udělat. Jazyk ho v tom má podporovat a ne mu klást do cesty zbytečné překážky.
Takže pokud jde o C - náhrada za něj není, není tedy důvod přemýšlet nad tím, že se ještě dnes tak masivně používá. Je třeba si přiznat, že C je dnes nejuniverzálnější a nejmocnější kompilovaný programovací jazyk ze všech. Stejně tak se dodnes ve vědeckotechnické sféře používá hojně FORTRAN, protože dodnes vyhovuje nárokům v daných oblastech nejlépe.
Komu se to nelíbí nebo nad tím žasne, tak ať přijde s něčím lepším.
P.S.: navíc si myslím, že se ještě dostatečně nerozlišuje mezi "lepičem kódu" a "programátorem" v původním smyslu slova. Pro lepiče, kterých je dnes tak 80%, je C skutečně nevhodné. Pro programátora je to téměř nenahraditelná věc.
Zilogat0r: To ze jsi si toho nevsiml je vcelku zavazny problem, doporucuju prostudovat danou problematiku a zaroven si rozsirit rozhled.
Inkvizitor: C# ma zase using() a C/C++ ve sve podstate { }.
Na goto nevidim nic spatneho, pokud je pouzito spravne, je pak kod mnohem logictejsi. Bohuzel majoritne k tomu sedne nejaky Mort a vysledkem je neco horsiho nez spaghetti :).
C je v jistych smerech tezko nahraditelnym jazykem, bohudik pro nas, tech smeru je dnes jen skutecne minimum a opasek se dale utahuje.
[70] Nevšimnul jsem si, že bych tady něco někomu dogmaticky vnucoval - uznávám, že každý nástroj má své místo a nemohu (skoro) nikomu nic nařizovat. O tom, že se optimalizace a další věci budou čím dál tím více řešit automaticky, jsem ale docela přesvědčen. Teoreticky je dokonce možné, že původně interpretovaný jazyk díky JIT poběží rychleji než kompilovaný (a ručně optimalizovaný), protože má možnost za běhu generovat kód podle aktuální potřeby (rozbalení cyklu atd.).
[71] Díky za doplnění. Sice bych řekl, že { } mají v C poněkud menší moc než v C++, ale v zásadě souhlas.
[72] Však jsem taky neříkal, že konrétně vy ;-) Ovšem např. univerzální odsouzení goto, jež jste provedl, nebo obecně zavrhování C kvůli tomu, že správa paměti je přenechána programátorovi, tím dogmatismem dost zavání. No a pokud nikomu nic nechcete vnucovat, tak vám může být lhostejné, jak je C rozšířené, nebo ne?
Optimalizace by byla další velká kapitola na debatu. Moje zkušenost třeba ukazuje, že nejúčiněji si program dokáže zoptimalizovat jedině člověk a to z jednoho prostého důvodu, který ještě dlouho, ne-li nikdy, nepřekoná žádný automat - člověk rozumí tomu, co dělá, je tak nějak "o dimenzi výš", kouká na to zvenčí. A až to nějaký software dokáže taky, tak už nebudou zapotřebí programátoři - alespoň ne v lidské kůži. Troufám si tvrdit, že většina optimalizací provedených automaticky je spíše optimalizační paběrkování. To podstatné, totiž podstata algoritmů a obecně analytické návrhy softwaru, zůstává často nezoptimalizováno a s tím už nehne ani ten nejgeniálnější překladač. Ostatně podívejte se na poměr výkon/nároky současného SW a SW z doby před 20ti lety. Optimalizátory čím dál vymakanější, HW čím dál rychlejší a méně omezující, ale SW čím dál pomalejší a nespolehlivější.
No a pokud jde o interpretovaný jazyk rychlejší než kompilovaný, tak to už tu je taky desítky let - přesněji, je celkem snadné napsat jeho interpret takovým způsobem, aby tohoto stavu bylo možné docílit vhodně koncipovaným programem v tomto jazyku napsaným. Ale asi by vaším favoritem zrovna nebyl, stejně jako 99% IT populace - i když pro mě je to snad nejpozoruhodnější programovací jazyk, který byl kdy vymyšlen. Poznáte ho? ;-)
[73] Goto sice neni uplne spatne, ale melo by se jim _velmi_ setrit, pouzivat pouze v situacich kdy _opravdu_ zprehledni kod.
Optimalizace: Nojo, ale ma smysl stravit clovekomesic prace na optimalizaci po ktere dostane uzivatel reakci misto za 5ms uz za 1ms?
"Když vím, že jedna proměnná může mít různé, avšak smysluplné a dobře definované významy, pokud je nahlížena pohledem různých datových typů": Omlouva vas jen to, ze evidentne netusite nic o OOP - tomuhle se rika tusim polymorfismus :-) Jinak ano, pri zpracovani binarnich dat se vyskytuji situace kdy je typova kontrola dost na obtiz, ale to dost zalezi na tom, jaky typ uloh programujete.
Kdyz uz jsme u toho OOP - ja bych to oddelil od jazyka a nazval Object Oriented Design. To je urcity zpusob nahledu na problem (analyzy) ktery se v praxi osvedcil pro velkou radu uloh. Programatori jej vicemene znaji takze OO analyzu delanou nekym jinym vetsinou rychle pochopi. Jazyky pro OO maji podporu, takze se to da i rychle nakodovat. (A da se to nakodovat s vetsimi ci mensimi problemy i v takovem ciste C-cku, obcas to delam :-) ).
[74] S goto naprosto souhlasím.
optimalizace - no tak do takových extrémů zabíhat asi ne, ale pokud se jedná o řády, tak si myslím, že už to je nezbytné.
OOP - opravdu, nejsem ani teoretik, ani mi tento styl nesedl, ale i z toho co o tom vím bych řekl, že to co já jsem měl na mysli není polymorfismus. Polymorfismus je založen na "příbuzenských vztazích" mezi třídami, ne?
GOTO je naprosto prirozeny konstrukt. Silny, mocny, da se s nim hodne resit (a pitomec s nim muze mnoho zkazit). Ale to neznamena, ze je spatne - je to pro procesor ta nejprirozenejsi vec, zaklad vseho vetveni algoritmu - a nevim, proc by ji mely vyssi jazyky potirat - v zajmu koho?
nekompetentnich lepicu pseudokodu?
[75] IMHO jen malokdy dosahnete optimalizace o rady zmenou jazyka - to spis zmenou algoritmu (nejlepe zlepsenim asymptoticke slozitosti), ale to neni problem jazyka.
Ja take nejsem teoretik :-) Ale pokud si vezmu vicenasobnou dedicnost (nebo interfaces jak to implementuje Java), tak muzu udelat presne to co pisete. I kdyz pokud jste myslel ze mam pole binarnich dat a koukam se na ne jednou jako na znaky, jednou jako na wordy, tak to samozrejme polymorfismus neresi a OO zde neni moc vhodne, to uz jsem psal.
[76] V zajmu tech chudaku co pak musi takovy kod louskat :-D
Kod ma byt predevsim funkcni, prehlednostm je vzdy az druhorady faktor.
prehledne napsana pitomost bude muset byt stejne opravovana/upravovana, az uz tak prehledna nebude. Zatim tu nezaznelo to zakladni, a sice, ze programy nemaji byt psany rychle, za co nejmin penez, co nejmene znalymi lidmi, ale ze maji FUNGOVAT. A tomuto kyzenemu stavu nas tuny vrstev a frikulinskych vyssich jazyku spise vzdaluji, nez priblizuji, a to je kletba tohoto oboru.
Na otazku, jak asi vypada kompilator vyssiho jazyka, kompilovany bugovym kompilatorem o trochu nizsiho jazyka, bezicim na bugovem jadre, je opravdu odpoved ve hvezdach.
[80] v nefunkcnim vyssim jazyku NELZE napsat obecny funkcni kod, mily zlaty. Funguje vetsinou jen pro par "standardnich situaci". Kodokoli chce neco trosku specifictejsiho, je v naproste vetsine pripadu, bez ohledu na konkretni jazyk, odsouzeny k tweakovani a vymysleni krkolomnych konstrukci, kterak presvedcit HLL ke generovani korektniho kodu.
ano, je to o tom "na spravny ukol spravny nastroj", jenze co jsou ty spravne nastroje, se zacina zapominat. Viz hruzne nesmyslne navrhy na jadro kernelu v C++, operacni system v jave, nebo drivery v .NET, co jsem nedavno zaznamenal. Buh s nami, potom.
[78]: Ty bavis :)) Presne tak, program musi predevsim fungovat a to je snadneji dosazitelne v beznych aplikaci v managed jazycicich nez C, proto se v nich pise tolik veci, co se v nich pise :-)
[79]: No a?:-) Je to vzdy jen o kompromisech nakladu a vykonu. Konec koncu pocet uspornych procesoru celkem utesene narusta, stejne tak jak se snizuje prikon klasickych "vykonnych", evidentne proto, ze je po tom poptavka..
[82] fungovat = vyzadovat desitky megabytu navzajem nekompatibilniho environmentu, casto konkretni verze, na blbe zobrazeni par cisel ve formulari inicializovat desitky sekund pomale applety, a pri behu zahnojit operacni pamet az kam to jde?
typickym prikladem budiz e-banking KB, psany v te skvele uzasne Jave, ktery by mel tedy fungovat vsude. A jaky je vysledek? Funguje s konkretni verzi JVM na konkretnim proprietarnim systemu, jen vuci konkretni verzi IE. Volam bravo, lepici javovych hnusu...
[81] programovat skutecne neumim, ani o programovani nic nevim - natoz o tom, jak vypada efektivni strojova podoba kodu uz netusim ni zbla :))))
[83] naopak - ke spatnemu designu nektere programovaci jazyky svymi paradigmaty vylozene navadi (100% souhlas shttp://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 ) - mluvil o tobe, Michale, a tobe podobnych :). Zeptam se - kdyz uz tak "hodnotis" kvalitu jazyku - znas vubec asm/strojovy kod x86? Nebo je tvym meritkem to, jak to vypada v textovem editoru...
[85] harry_x samozrejme, ze to nemelo s javou vubec nic spolecneho, krom idiotskeho designu emulace zasobnikove architektury s zabudovanymi objektovymi (rozumej: zpomalovacimi, bloatovacimi) rysy...
soucasna verze mi snad bude fungovat napr. s mozillou, pod Linuxem? ne, vid. a proto se ptam - proc to je tedy v jave, kdyz to jen vyzaduje dodatecny environment, a je to kvuli ni 10x pomalejsi? manazerske rozhodnuti?
[87]: co jsem cetl, tak presli na standardni sun javu, takze pravdepodobne fungovat bude (a pokud ne, tak to neni chyba Javy, ale jejich), ale e-banking KB je mi celkem ukradeny, kdyz u tehle banky nejsem :)
A to, ze to nefungovalo kvuli nestandardnim rozsirenim a zmenam, co udelal MS a pro jehoz Javu to psali, to opravdu nema nic spolecneho s architekturou Javy, to by jsi mohl chapat :-)))
Popravde se nad touto diskusi smeju, nejprve se rvalo, ze skutecni programatori neprogramuji v Fortranu, ale v assembleru (s uplne stejnymi argumenty), ted se rve, ze skutecni programatori neprogramuji v managed jazycich. Oboji je k smichu, jedno historie uz nevyvratitelna pohrbila, druhe ceka to same :-)
Jazyky jako C (ci primo assembler) budou mit vzdy sve misto na slunci, veci jako libc ci kernel v nich nikdy nebudou moci byt napsane (nebo resp. neni to zadouci) - ale to je jen zlomek aplikaci, ktere se vyviji. Vetsina aplikaci potrebuje neco uplne jineho a tam exceluji managed jazyky. Na desktopu C#, na serveru Java.
[88] neefektivita je vlastnosti javy obecne, bez ohledu na extenze.
netusim, jestli u KB s prechodem na Sunovskou Javu odstranili i zbytek nekompatibilit, ale puvodni idea, s kterou se nesmyslna Java protlacovala, tj. "pobezi to rovnou na vsem bez ohledu na system/platformu", zrejme opet vyjde naprazdno, viz: http://www.linuxsoft.cz/article.php?id_article=1371
Tedy z neslavne Javy i po letech zbyvaji predevsim nevyhody - presne, jak jsem kdysi predpovidal. A uz to snad zacina dochazet i Sunu, ze tudy cesta nevede.
[89] pokud nejaka technologie produkuje znatelne vetsi procento spatnych (zbytecne velkych, zbytecne pomalych, zbytecne na environmentu/emulaci zavislych, nesobestacnych, nekompatibilnich s verzemi vlastniho prostredi) aplikaci, jsou tedy dve moznosti:
- je to spatna technologie
- tuto technologii preferuji spatni programatori
tak si vyber, kam se zaradis.
[77] "Optimalizace změnou jazyka" - no vidíte, takové spojení mě ani nenapadlo :-) Nicméně jsou jazyky, v nichž daný algoritmus lze zapsat jednoduše a efektivně, a jsou jazyky, kde to jde hůře. A přesně o tom jsem mluvil. Proč mám vymýšlet podivné konstrukce jen abych uspokojil překladač, když by to šlo jinak a snadněji s využitím mnohem jednodušších elementů, jako je např. goto či přetypování? Takový algoritmus tak akorát pohřbím než abych ho implementoval. A to už problém jazyka je.
K tomu OOP - ano, myslel jsem spíše to druhé - kdy se na ASCII znak můžu dívat jako na cifru, na rozdíl dvou ukazatelů jako na velikost, atd. atd... Jinak vícenásobná dědičnost je pokud je mi známo věc, kterou teoretici OOP také nevidí rádi - skoro takové goto v objektové podobě :-) ... Navíc polymorfismus OOP se sice skutečně v mnoha ohledech dá přirovnat k tomu přetypovávání, ale za jakou cenu na úrovni generovaného kódu a jeho efektivity se to děje, to je nesrovnatelné.
[87] on tu zásobníkovou architekturu nakonec více či méně simuluje veškerý generovaný kód každého vyššího jazyka - je to totiž jednodušší. Práce se zásobníkem se dá celkem snadno zapsat a popsat v podstatě matematickým jazykem a lze nad touto strukturou vyslovit a dokázat spoustu tvrzení, mající charakter optimalizace práce s ní a co především - všechno je to lépe automatizovatelné. Spoustu věcí napíšete v Assembleru jednodušeji a efektivněji s využitím širokého sortimentu proměnných a registrů, ale pokud by podobný kód měl být produktem ne člověka ale jiného algoritmu, nastává spousta problémů, jejichž řešení je pro člověka celkem snadné, ale pro stroj komplikované. Člověk totiž dokáže spoustu problémů řešit ad hoc, zatímco stroj potřebuje soubor jasných a jednoznačných pravidel.
[*] Já bych si dovolil znovu opakovat, že je zásadní rozdíl mezi programátorem a lepičem. Něco jako mezi řemeslným mistrem a člověkem u pásu. Je jasné, že ti dva se pohybují každý v úplně jiné lize. Pro mne je programování vysoce tvůrčí činnost, vyžadující intenzivní myšlení a nadhled. Je to něco jiného, než vyhledávat knihovny a existující komponenty a své řešení přizpůsobovat existenci či neexistenci odpovídajících polotovarů, z nichž je pak výsledek nějak poslepován, aniž by autor tušil, jak to celé vlastně funguje. Je mi jasné, že dnes už není možné vystačit si jen s programátory, stejně jako by řemeslní mistři nestačili k uspokojení poptávky po jejich výrobcích. To mi ovšem nebrání hledět na lepiče a jejich nástroje s pohrdáním :-)
[87] - to sice ano, jakekoli strukturovane programovani (a OOP skryte) je uz z podstaty zasobnikovym pohledem na problem - jenze jde o granularitu tohoto rozvrstveni.
Stara koderska poucka "nedelej si na kazdou ptakovinu extra funkci, a kdyz uz, tak aspon inlinuj" s zakladnim atributem Javy hrube koliduje, a stigma tohoto prohresku se java sotvakdy dokaze uplne zbait, byt by se 10x jitovala.
[*] :) hehe, asi tak :)))
[93] jinak klobouk dolů před vámi, když dokážete dopředu poznat, jestli právě zpracovávaná entita je znak nebo číslo a rovnou to správně přetypujete... (bez toho, aniž byste se pokusil něco o té entitě zjistit) - to jen taková moje poznámka k tomu vašemu srovnání polymorfismu a přetypovávání
[96] boze, program je snad deterministicka zalezitost, a kdo uz jiny, nez programator - autor algoritmu, ma vedet, jaka data prave hodla zpracovavat?
takze ono se programy pisi na slepo, aby jako zhruba neco delaly, a bozsky kompilator za vas rozhodne, co vlastne? BOZE. JE TO HORSI NEZ JSEM SI MYSLEL.
[97] :-) vy jste asi nikdy nepsal žádný program, který by zpracovával uživatelský vstup, že? A který má dělat něco na základě toho, co uživatel zadá?
Právě že kompilátor se rozhodne na základě toho, co mu řeknu, jak se má rozhodnout - tj. nechat rozhodnutí až na tu chvíli, kdy ta daná entita bude zpracovávaná...
[96] a bozky Chnushnus kompilator to dela bez toho, aby neco zjistoval?
ne-e. bud je to staticky objekt, a pak uz identifikator rika, co to je (coz MUSI programator vedet take, sak ho zakladal), a nebo je dynamicky, a pak saha do objektu:
p=(_a *)&b;
80485c2: 8d 45 f0 lea 0xfffffff0(%ebp),%eax
80485c5: 89 45 ec mov %eax,0xffffffec(%ebp)
p->ahoj();
80485c8: 83 c4 f4 add $0xfffffff4,%esp
80485cb: 8b 55 ec mov 0xffffffec(%ebp),%edx
80485ce: 8b 42 04 mov 0x4(%edx),%eax
80485d1: 83 c0 0c add $0xc,%eax
80485d4: 8b 55 ec mov 0xffffffec(%ebp),%edx
80485d7: 52 push %edx
80485d8: 8b 18 mov (%eax),%ebx
80485da: ff d3 call *%ebx
80485dc: 83 c4 10 add $0x10,%esp
v nejlepsi verzi (-O4) takto:
p=(_a *)&b;
80485e7: 8d 55 f0 lea 0xfffffff0(%ebp),%edx
p->ahoj();
80485ea: 83 c4 f4 add $0xfffffff4,%esp
80485ed: 8b 42 04 mov 0x4(%edx),%eax
80485f0: 52 push %edx
80485f1: 8b 40 0c mov 0xc(%eax),%eax
80485f4: ff d0 call *%eax
... tj ZBYTECNA reference, i mirne podnapileho C programatora by jiste napadlo dat primo do objektu pri vzniku pointer na funkcni, nastaveny na tu pozadovanou - a hned mame o referenci mene, a ze 4 instrukci jednu.
A to je prosim g++ na maximalni level optimalizace, a tuto trivialitu, kdy lze nahradit blbou _vptr primou referenci (objekt mel jen 1 virt. metodu) samozrejme NEpochytilo. Jak v necem takovem chcete vytvaret, boha, optimalni kod, kdyz to i v trivialnim pripade emituje 4x vice instrukci, nez by napadlo i toho nejpritroublejsiho assembleristu?!?!
Takze stop bullshit, a misto cancu vezmete dbg...
[96] No, teď mne přivádíte do rozpaků... Představte si, že jsou programátoři, kteří to poznají, a představte si, že v minulosti ani jiní neexistovali :-)
[98] Takže vám nestačí ověřit si, že uživatel zadal platné číslo v okamžiku, kdy ho zadal, vy si to ještě musíte ověřit u každé cifry zvlášť a pak ještě sto padesát krát a pokud možno kvůli tomu nechat kompilátor vygenerovat a linker připojit stovky kilobytů naprosto redundantního kódu, jehož jediné poslání je pak v dané chvíli zpomalovat počítač, zaplácávat paměť a vnášet do celého programu další chyby, neboť není žádná bezchybná knihovna...?
[97] - bullshit. runtime polymorfismus, polopaticky receno, znamena, ze existuji 2 funkcne odlisne objekty na 1 pointeru, a jde s nimi pracovat "unifikovane". Takze ten uzivaterlsky vstup STEJNE MUSEL NEJAKY KOD ZANALYZOVAT, a a vytvorit pro nej tridu daneho typu. A jak je ukazano vyse, uz v tomto zakladnim rysu je schopnost kompilatoru "optimalizovat" tristni...
takze kdokoli mluvi o OOP efektivite, nevidi si do pusy, a zrejme ani netusi, jak moc toto paradigma zuzilo puvodni maevrovaci moznosti zde zatracovaneho "cecka". Ano, v C++ se da psat efektivne, ale pak zpetne obvykle zjistime, ze piseme... puvodni cecko.
[96] Vtip je právě v tom, že on opravdu VÍ :-). Přesně ví, s čím pracuje, jak je to v paměti uložené a navrch i ví, jak s tím přesně pracuje procesor :-)...
[102] Hezký :-).... Tuhle jsem se snažil napsat kousek kódu tak, aby to C++ překladač efektivně přeložil... Vysloveně jsem se mu podbízel... a bohužel nic....
Nakonec jsem to napsal v inline assembleru...
to zilogat0r:
mate pravdu, c++ je aj podla mojho nazoru pajazyk, ktory keby vymrel tak by hned bolo na svete krajsie :) (co som sa v nom nakodi... ach.. tolko premrhanych dni...)
Inak g++ (teda gcc pre c++) je podla mojich skusenosti (a skusenosti ludi v mojom okoli) velmi velmi velmi zly c++ kompilator (co je celkom zaujimave v kontraste s gcc pre cecko, na ktore je velmi dobry).
Podla mna cecko (a assembler) bude potreba dovtedy, dokedy budu pocitace fungovat na principe jednotiek a nul a registrov atd... :)
Avsak nechapem, co mate proti vysokourovnovym jazykom vo vseobecnosti (c++ medzi ne rozhodne nepatri). Teda mozno nic, ale ja som to tak z niektorych vasich komentarov pochopil... ak Vam nie je jasne preco v nich niekto programuje, tak sa to rad pokusim vysvetlit...
Este taky dovetok... aj ja zastavam princim, ze na spravnu ulohu spravny nastroj:
- nizkourovnova vec (jadro, ovladac) => cecko
- multiplatformova vec => Java (teraz som tu na tejto diskusii nieco cital o nie az zas tak uzasnej multiplatformovosi - tak to este pozriem teda... sakra... snad to je len problem blbych programatorov a nie Javy samotnej, ci nie?)
- cisto konkurentna a/alebo distribuovana vec => Erlang
- vsetko ostatne => Common Lisp SBCL :)
(vo vsetkych zmienenych som v podstate aj komercne kodil)
Proste C++ predstavuje naprosto posledni rozumnou a jeste "relativne" unosnou abstrakci od strojove implementace.
Proto odpoved na otazku Kudy dal v kompilovanych jazycich zni:
"Nikam, bude lepe dopsat stavajici kompilatory tak, aby
dodrzovaly platnou normu napr. co se tyce sablonovani."
Souhlasim se Zilogat0rem, ze pokud chci mit pro tridy v C++ kvalitni kod musim programovat a uvazovat jako v C. Viz. implementace polymorfizmu u desktriptorech v Symbian OS. Kde vubec vzali tvurci SymbianOS hodne vlastnosti C++ hakem. ;-)
Java a dalsi jim podobne interpretovane jazyky pouze dokazaly, ze mytus o lehke prenositelnosti programu mezi platformami je blbost. Na jinych platformach takovy "dzava" program sice mozna bezi, ale nikdo nema tolik casu, aby ho mohl pouzivat. Protoze to trvaaa hrozneee dlouhooo.
Pripadne nema tolik penez, aby mel dooost velkou pamet. (samozrejme krome ulhana)
A pokud tady bude nejaka lama hned namitat ze Java neni interpretovana a ze vlastne kazdy kod se sklada pouze a jen z volani knihoven, tak at jde pojidat koblihy a ucit se assembler.
[105] mne na jave vadi uz to, ze je - vzdyt je to prachsprosty emulator velice spatne koncipovaneho vypocetniho modelu.
vidime to dnes a denne - prime emulatory konkretnich platforem svisti (napr. qemu, rosetta...), kdezto tenhle hnus, co mel tu nevidanou vysadu stanovit si kod tak, aby se zpracovala nejefektivneji - je neefektivita sama.
kdyby autori distribuovali misto classu (a ted to prezenu) napr. m68000 binarni chunky, a na masinach bezel m68000 emulator, byl by vysledek daleko pouzitelnejsi.
jde o svevolne zavleceni naprosto zcestnych rysu do navrhu, a svevolne prosazovani teto spatne vybrane cesty demagogickym apelem na ty mene znale programatory.
lecjaky manazer si tehdy myslel, ze www == java, a tak to tu dnes holt mame, co nadelame - jako buzzword to byvalo zvucne, ale uz ve specifikaci shnile, a v implementaci shnile na druhou.
[106] Uff... no toho je strasne vela... celkom dobre to zhrnul Linus Torvalds (teraz pred chvilkou som tu v tejto diskusii na to videl odkaz, celkom sa rozohnil, dobre som sa pobavil :)
Momentik... tento:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
Ako mne osobne vadi na nom uz asi vsetko, ale to je asi sposobene tym ze posledne dva roky programujem vacsinou v Common Lispe... takze uznavam, ze asi mam na tvorbu programov uplne iny nazor ako ludia co programuju v c++. Vadi mi jeho neuveritelne ukecana a smiesna syntax (vravel som Vam ze som poznaceny zatvorkami;), ale sak staci sa pozriet na normu, aky je to paskvil...
Vadi mi ze sa pouziva ako vysokourovnovy jazyk, resp. vela firiem ho tak pouziva, a tym padom prichadzam o potencionalne miesta kde pracovat, pretoze si nechcem skazit zivot ako c++ code-monkey.
Vadi mi jeho objektovy system, kde nie je vsetko objekt, nema multidispatch, nema aspektovo orientovane crty (:berofe :after :around), pretazene operatory su len na smiech (uz som to tu na root.cz raz vysvetloval), vadi mi strasne fungovanie viacnasobnej dedicnosti (prekryvanie a pod... uz si to ani nepamatam tie pravidla), vadi mi striktna zapuzdrenost, vadi mi absencia syntaktickej abstrakcie, a v podstate mi aj vadi, ze nema garbage collector - z coho vypliva ze mi vadi ze nema lambdu, closures... a tak by som mohol pokracovat...
Kazdy projekt, co som v c++ videl, by bol v rovnakom rozsahu a rovnakym sposobom naprogramovatelny v obycajnom cecku (kazdy, kto to chcel mat aspon trochu rychle sa totiz vykaslal na RTTI)
[108]
Opat suhlas... Java je hnus (aj ked mozno to trochu prehanate)...
Momentalne vsak pracujem na projekte, kde klient musi bezat v prehliadaci (skratka musi, server je samozrejme SBCL:)... mal som na vyber Java Applet alebo Flex... a po tom co som cital o Flexe sa mi do neho moc nechce...
Vedeli by ste mi poradit nieco ine? Aj ked by som uz teraz nemal cas to prepisovat, do buducna by mi to celkom bodlo...
[109] Absolutně nechci vyvolávat žádný flame, ale Linus není počítačový bůh, jen ve správný čas zkusil napsat ten správný kód... kdyby to neudělal on, udělal by to někdo jiný o půl roku později. Je jenom člověk jako každý jiný :-), některé své podivné názory změnil, jiné nikoliv... má na to právo :-).
Z toho, co jste napsal mi to přijde, že vytýkáte C++ že není superjazykem s naprosto všemi myslitelnými vlastnostmi :-)...
Zkusím to projít popořádku...
K syntaxi - tady si trošku protiřečíte ne? C a Javu byste rád, C++ nikoliv; ovšem z hlediska syntaxe je mezi nimi pouze malý rozdíl... Na druhou stranu chápu, že pokud jste poznamenán Lispem (jehož syntaxe zas připadá nikoliv směšná, ale odstrašující, mě), nebude se Vám syntaxe C-like jazyků líbit. Ale nepoužíval bych to jako argument proti C++, pokud C a Javu můžete.
Co se ukecanosti týče, mohl bych Vám připravit odkaz na kód, který je v C++ a rozhodně byste ho za ukecaný nepovažoval ;-)... bohužel za čitelný taky ne.
Norma - paskvil... opět bych se mohl zeptat, co konkrétně je tam paskvil... a určitě bychom našli něco, co se mi také nelíbí, ale nepřipadá mi rozumné ji odsoudit zrovna tímto způsobem.
C++ samozřejmě není čistý vysokoúrovňový jazyk, nicméně má hodně vysokoúrovňových rysů a proto se dá jako vysokoúrovňový úspěšně použít. Nicméně, jak už jsem psal někde výš, C/C++ jsou hodně o svobodě... můžete... nemusíte :-).
Trošku nechápu co Vám vadí na tom, že v C++ není vše objekt... Z jakého důvodu by třeba jednoduché datové typy měly být objekty? Jednak by to značně komplikovalo nízkoúrovňovější tvář C++, jednak by to bylo zbytečně pomalé... Podobné výkřiky jsou čistě OOP fanatizmus...
Multidispatch... to bohužel netuším, co by mohlo být.
Aspektově orientované rysy... ještě jsem se zcela nerozhodnul, jestli je AOP vůbec nějakým přínosem, či spíš naopak. Podle mě se dá téměř cokoliv, co řeší AOP udělat i jinak a čitelněji... ale chápu, že je to věc názoru.
AOP se objevilo relativně nedávno, možná se ho v C++ dočkáme taky :-(.
Já věřím, že v Lispu je možné udělat operátor z čehokoliv, otázka je, k čemu je to dobré (samozřejmě věřím, že vymyslíte úžasný příklad, ovšem realitě bude jistě značně vzdálený)... Přetěžování operátorů v C++ bylo primárně určené k zlepšení čitelnosti matematických výrazů nad komplexními typy a k tomu (a spoustě dalších věcí) slouží velmi dobře :-).
Vícenásobná dědičnost je samozřejmě diskutabilní věc. Ale C++ Vám ji nevnucuje. Nelíbí? Nepoužívejte ji. Občas dokáže věci hezky zamotat, ale i krásně vyřešit.
Striktní zapouzdřenost - bohužel si nejsem zcela jistý, co tím přesně máte na mysli. Zkuste prosím trošku rozvést.
Syntaktická abstrakce - protože C++ nemá, bohužel asi nebudu vědět o co jde... Takže ani nemůžu komentovat. Možná to může být užitečné...
GC - já jsem rád, že ho C++ nemá. Jak už jsem psal výše, GC se dá plně (a kontrolovaně) nahradit smartpointery, když člověk chce. Obecně si myslím, že GC je ideově pomýlený; programátor by měl být za zdroje výpůjčené od OS zodpovědný...
K poslední poznámce... Ano, to je možné. Podobně, jako každý projekt v Javě by (z hlediska funkčnosti) mohl být napsaný v C++ a každý projekt v C by mohl být napsaný v assembleru.
Nicméně, pro určité třídy aplikací jsou různé jazyky více/méně vhodné z hlediska kompromisu mezi výkonem a náročností na napsání...
Spravuji/rozvíjím ne zcela malý projekt, kde hlavně u jeho hlavní GUI aplikace jsem za C++ skutečně rád :-). Souhlasím s tím, že bychom to bývali mohli napsat i v C, nicméně spoustu věcí z C++ bychom si vlastně implementovali sami (virtuální tabulky+metody rozhodně) a přehlednost kódu by rozhodně značně utrpěla...
[108]: Bytecode m68k misto Javy? Tak to jsi mne skutecne velmi dobre pobavil :) Jen tak dal...
Ale jak se to rika, kazdy ma moznost volby :) Ja kdyz potrebuji, tak programuji v asm (embedded povetsine) nebo C/C++, enterprise aplikace programuji v Jave EE (coz mi setri cas a naklady), vyvoj je rychlejsi a efektivnejsi, klienti jsou spokojeni a ja tez :)
[108] Myslím, že v otázce bytecódu se mýlíte.
Velké množství dnešních kompilátorů pracuje interně s určitým bytekódem, který nemá přímou vazbu na výsledný strojový kód. První fáze kompilace (front end) vytvoří interní bytekód ze zdrojového kódu, druhá část (back end) generuje z bytekódu strojový kód zvolené platformy.
Java pouze při "kompilaci" před distribucí vynechává druhou fázi a provádí ji až za běhu dynamicky.
A protože dynamická kompilace může optimalizovat kód na konkrétní procesor (statická kompilace se většinou omezuje na skupinu procesorů; pro šťouraly zdůrazňuji slovo většinou :-) ), je výsledek velmi rychlý; přesněji řečeno, má potenciál být velmi rychlý.
Samozřejmě ovšem dramaticky záleží na tom, kolik kódu je potřeba kompilovat a kolikrát se daný kód prochází. U algoritmů, které jsou na zkompilování krátké, ale procesor je prochází mnohonásobně může být výsledek teoreticky rychlejší než v C...
Aplikace psané v Javě nejsou pomalé z důvodu, že by bytekód byl špatně zvolený... Příčiny jsou podle mě jinde a jsou (jak to vidím já) zhruba 3:
- Java musí provádět spoustu kontrol, které si programátor může dovolit v C vynechat, když ví co dělá
- lidé, co píšou v Javě jsou většinou hodně vzdálení HW.... většinou nemají tušení jak procesory fungují, jak efektivně pracovat s pamětí a cache...
- protože to je jazyk "in" a ne příliš komplikovaný, spoustu Javovských aplikací dělají zmínění lepiči :-)
To je zase jednou flame ... Tak nejak nechapu o co tu bezi.
Par jedincu se tu snazi presvedcit ze znaji vsechny obskurni zapovezene vlastnosti tech nizsich jazyku, aby tak nejak dokazali, ze jejich nazor ma vyssi hodnotu ... nebo to chapu spatne?
Pritom ale zcela detinsky kopou do tech 'vyssich' jazyku s horecnou nenavisti a to o nich nic ani nevi. Leda jen to, ze 'v nich urcita skupina lidi uvolnuje spatny kod'. Ktera skupina lidi? Oni 'lepici kodu'? Tak at si dal lepi sve code snippets, s takto poslepovanym programem se realne neda prosadit. Pokavad chcete, aby vas nekdo zacal brat vazne, tak pracujte s fakty a ne jen vykriky do tmy stylem 'abrakadabra'.
[86] V assembleru jsem psal. Dokonce v nekolika: Z80, 80x86, 8502, 68000 :-) Napriklad jsem napsal system ktery po spojeni Amigy a PC paralelnim kabelem umoznoval na Amize videt disk PCcka jako normalni disk :-)
Stejne tak v C jsem napsal distribuovanou replikovanou databazi obhospodarujici nekolik desitek terabajtu dat. Takze verte ze VIM o cem mluvim pokud mluvim o programovani v C na "nejvyssi urovni". Ale taky dobre vim, o co vsechno se ve vyssich programovacich jazycich _NE_musim starat a misto toho se mohu soustredit na problem jako takovy misto technickych detailu prace s pameti atp.
Ad odkaz: C++ taky nemusim, pripada mi to jako nechutny hybrid mezi C a OOP jazyky ktery me nevyhody obou ;-)
Jinak (coz se tyce i Vikiho) uz pochopte, ze v 99% programu nezalezi na efektivite - minimalne ne v mezich danych rozdilem mezi C a Javou (napriklad). Vetsinou to akorat znamena, ze procesor nebude 99.9% idle ale 99.8% idle na coz vam viteco... ;-)
Ne ze byste nemeli vubec pravdu, ale tech aplikaci kde o to jde je proste dost malo. Rozhodne min nez aplikaci kde zalezi na tom, jestli to bude napsane za den nebo za tyden.
[108] ano, jenze tento nahled NENI originalni koncepci Javy.
bytecode se hodne dlouho interpretoval (a na interpretovany beh byl Oak, pozdeji Java, puvodne navrzena), a k JIT kompilaci dochazelo az pozdeji.
Neni to zadny mezikod, postihujici obecne semantiku - je to v podstate "vysledny assembler", jen tesne pred linkovanim pro virtualni zasobnikovy pocitac - a tady s tim uz moc nenadelame - jen muzeme vice nebo spis mene efektivne zrealizovat _od_pocatku_neefektivne_ seskladany vypocet.
Nedelam si iluze, ze by nejaky JIT analyzoval semantiku deni na zasobniku, a zpetne rekonstruoval ekvivalent registroveho vypocetniho modelu - to je jen zbozne prani.
Pokud ma nekdo pocit, ze JITovana Java vede ke kvalitnejsimu kodu, nez jaky produkuje nativni kompilator, je zcela vedle - uz jen runtime kontroly jsou nechutna zatez (neodstranitelna - kod, co JITer dostane, s nimi pocita).
[116] podivej, ja jsem assemblerista, a nemusim u vyssich jazyku zabihat do detailu, pokud vidim, ze aplikace je POMALA, VELIKA, NESTABILNI, a po otevreni v debuggeru PLNA NAPROSTO ZCESTNE SESTAVENEHO KODU.
zajima mne, kde co v pameti lezi, co se s cim provadi, a jak casto - to je klic k efektivite aplikace. narozdil od nekoho, kdo mne obdari takovou naslepo poslepovanou "omalovankou", v domneni, ze prave lacino stvoril druhou Monu Lisu - ne.
Obcas mi touhy HLL matlalu pripominaji male dite, co rika: "a proc vlastne nezrusime to seti obili? navrhuji sazet bochniky chleba, to by bylo nejlepsi".
coz je usvedcuje jen z neznalosti a naivniho nadseni pro neco, co je pro ne samotne cernou krabickou.
[112]
Tak aj ja poporade teda (inak vsetko je to len moj nazor, diskutujeme, nevravim ze mam univerzalnu pravdu, len chcem hodit do plena moj pohlad na vec, tiez nechcem vyvolavat flame):
Linus nie je pocitacovy boh, suhlasim, ten link som dal len pre pobavenie (resp. preto aby ste ho nemuseli znoval hladat v diskusii, ked som sa na neho odvolaval). To co tam pise je ale podla mna zcasti pravda...
C++ vycitam to, ze nie je ani nizkourovnovy a ani vysokourovnovy jazyk. Aby bol nizkourovnovy, musite ho pouzivat v podstate ako cecko, a aby bol vysokourovnovy, chyba mu velmi vela dolezitych vlastnosti. Ja mam niekedy pocit, ze ma z oboch "svetov" to najhorsie (malicka vyrazova schopnost z nizkourovnovych jazykov, "pomalost" vysokourovnovych).
Syntax. Nemam rad C-like syntax, ale u cecka ju chapem preco je (a som aj ochotny ju pouzivat:). Vysokourovnovy jazyk by taku obmedzujucu a ukecanu syntax nemal mat. Java syntax mi nevohovuje, preto pouzivam LINJ (Lisp Is Not Java - pisete normalne v Common Lispe, s urcitymi obmedzeniami kvoli Jave..., a LINJ z toho spravi "human-readable" Java kod... takze mozete pouzivat Lispove makra a podobne...)
Norma - paskvil... beriem spat, ospravedlnujem sa... to by bolo na flame... este raz, pardon... nemal som ju tak oznacit (aj ked si to myslim)...
C++ nie je cisty vysokourovnovy jazyk, pravda, a podla mna mu chyba velmi velmi vela vlastnosti, ktore by ho mohli k vysokourovnosti priblizit.
Preco mi vadi ze vsetko nie je objekt? Nema to nic s OO modelovanim... ja v Lispe kodim casti funkcionalne, casti proceduralne, casti objektovo... a ked je vsetko objekt, tak to do seba prirodzene zapada... uz som spoznal, ze sa to tazko niekomu vysvetluje, kto neprogramoval v cisto objektovom jazyku, resp. ja to moc neviem (nikdy ma nepochopia) :)
Multidispatch.... OO jazyky, ktore poznate Vy, rozhoduju o vyslednom zavolani metody iba na zaklade jednoho (prveho) parametra.
CLOS objekty vsak neobsahuju metody, metody patria generickym funkciam, a genericke funkcie su specifikovane na rozne typy objektov, resp. maju specifikovane svoje parametre na rozne typy objektov... ak specifikujete len prvy parameter, podoba sa to na singledispatch, ktory je v OO jazykoch ake poznate. V CLOS vsak mozete specifikovat viacero parametrov (kludne aj vsetky)... ved vsetko je objekt, takze kazdy parameter je objekt... no precitajte si nieco o CLOS a Meta Object Protocole, ak Vas to zaujima, ak nie, kaslite na to...
Aspektovo orientovane rysy davaju dalsiu vyrazovu schopnost do CLOS, resp. vyrazne zvysuju jeho modularnost. Nemusite to pouzivat ak nechcete, v niektorych pripadoch je to super, ale tiez mi chvilku trvalo kym som to pochopil...
O operatoroch v c++ som uz raz pisal, naco znova (ked tak si najdite v starych clankoch na roote, resp. v diskusiach, bolo to tusim nieco o spocitavani matic)...
Viacnasobna dedicnost je super pri tzv. treadovom modeli tvorenia objektov (ci ako sa tomu odborne nadava...:). Hmm... mam to vysvetlovat? Ak vas to zaujima, tak napiste, vysvetlim, ak nie, kaslite na to...
Zapuzdrenost pomocou public, protected, private je v niektorych pripadoch nanic. Podla mna je aj dokonca zbytocna... nechapem preco by mal programator pred sebou nieco ukrivat... a ak dam vsetko public, zasa to bude vyzerat ze to patri k interfejsu objektu. Mne vyhovuje, ked mam jasny interfejs, ale zaroven aj ku vsetkemu pristup. No ale prave zapuzdrenost nie je asi nejaky velky problem v c++, len mi pride ako blbost...
Syntakticka abstakcia? Vytvarate si vlastne syntakticke konstrukcie, hmm... taky jednoduchucky priklad... ako je napriklad otravne stale pisat for pre prechadzanie pola a zoznamov a podobne, tak niektore jazyky pridali foreach. V jazyku so syntaktickou abstrakciou si kludne napisete vlastne foeach napr:
- for line in file
- for key and val in hashtable
- for computer in local-network
Naprogramujete si vlastne syntakticke vyrazy, ktore vam sprehladnia a zmensia kod, atd... (inak co vsetko sa da s makrami som myslim pisal prave pri tom vysvetlovani blbosti c++ operatorov). Znova, ak vas to zaujima a chcete si rozsirit obzor, citajte, vyhladajte... to ze teraz nevidite na co by Vam to bolo este neznamena ze by Vam to naozaj na nic nebolo...
GC je u vysokourovnovych programovacich jazykoch nutnost (IMHO). Ja som rad ze ho nema cecko.
K poslednej poznamke... chcel som povedat nie to, ze by to islo, ale ze by to nakoniec bol skoro rovnaky kod (teda podla mna... hmm... no mozno nie, toto nechajme tak:)
[122] Assemblerista ... fajn, stejne stupidne muzu zacit tvrdit, ze jelikoz drtiva majorita programatoru dnes neni schopna vyplodit kvalitni ASM kod, tak je ASM spatny?
Efektivita aplikaci je krasna vec, skoro podobny svaty gral jako znovupouzitelnost kodu a citelnost.
Tvoje idealy jsou proste jen trochu nekde jinde, nicmene porad idealy.
Ja si radeji sahnu po .Net a na jakakoli hanliva oznaceni kaslu, dani jedinci maji jen problem se semantikou.
[113] harry-x evidentne javista, co ani netusi, ze veci jdou delat JINAK a LEPE... takze je obtizne ti naznacit, ze napr. rekonstrukce obycejneho cyklu pocitajiciho sumu nad polem prvku znamena u bytecode neustale ukladani indexu, neustale ukladani reference na pole, neustale dereferencovani hodnoty (s kontrolou meze), secteni s mezivysledkem na stacku, a opakovani toho celeho?
JIT udela jen to, ze tenhle cyklus zapise natvrdo, ekvivalent opcode jeden za druhy, prolozeny runtime checky. Nikdy z toho nebude napr.
xor eax,eax
x: add eax,[ecx+(zacatek_pole - 1)]
loop x
coz vypoti i koder-zacatecnik...
pokud je rucne optimalizovany asm 1. liga, je C-cko okresni prebor, C++ utkani mistni TJ, a java kopanim do micku v arealu detskeho piskoviste.
rozdil je v r~a'du r~a'du(s krouzkem).
[123] nejak moc nepadal, ale napr. execnout aplikaci pres pc2am byla loterie 50:50, jestli neskoncime v suspend/reboot (5b/4b cross kabel na LPT, 2m) naposledy jsem to pouzil, kdyz jsem na jare logoutovi do opravene A600 vimplantoval kickstarty z vypalene A1200, a dopraval si nostalgie :).
jinac kabel stacil 10zilovy (9 zivych + opleteni), nevim ke jsi vzal toto: http://www.boomerangsworld.de/cms/apccomm/pics/LapLink4.png
kor spojeni 2-15 je usmevne, vidim, ze nejen memory, taktu, ale i dratu jsi mel vzdy habadej :)))
ale jinak celkem good, lepsi nez transferer Kumrana Karimiho :>.
[124] Koukam na C++ mame velmi podobny nazor
[126] Jenze i tak je vetsinou realny rozdil v radu mikrosekund. A vo tom to je. A taky o tom ze az se nekdy spletes a budes sahat mimo rozsah pole (nejlip zapisem) tak ta aplikace zacne padat a to je teprv chutovka odladit - uz jsi nekdy takovy problem ladil? ;-) Podle zakonu schvalnosti samozrejme pada nahodne a nekde uplne jinde nez na tom kodu ktery strili do pameti :-)
[126]: Jestli te to zajima, tak v asm jsem programoval jak spoustu embedded veci (m68k, 8051, hc12 napr.), zazil jsem projekty, kde se muselo setrit s kazdym bajtem mista, kdysi pred 7mi lety jsem v asm/x86 a C napsal mikrokernel...
Vim, ze to jde rychleji a efektivneji pro stroj (nez programovain v managed jazycich - delam jak v Jave, tak .NET), ale vubec mi to nevadi. Java mi setri cas, zvysuje efektivitu prace (=delam veci rychleji a s mensim usilim a potencialnim mnozstvim chyb)...
A zakaznikum je taktez jedno, jestli je jejich aplikace o 10% pomalejsi a zere o 20% vice pameti, zvlast k prihlednutim k tomu, jak je stavajici HW levny. Pro zakaznika je skutecne nesmyslne, aby platil za optimalnost kodu tam, kde ho naprosto nepotrebuje a kdyz by mu vyvoj takoveho "optimalnejsi" reseni prisel na radove vetsi investici (a vetsi zdrzeni)... V tomhle ohledu jsem naprosty pragmatik...
[127] toz to mas jedine stesti - ale ono to nebylo symetricke, vid - zatimco PC potrebovalo D0 z Amigy, amiga D0 z PC ignorovala (nemela cim nacist) - tj. dost zvlastni :>.
[126] dobre, ale tu sla diskuze o tom, zda by neco nemelo z linuxu vytlacit cecko, a jako navrh padala JITovana java - dovedes si v ni predstavit nejakou vazne minenou userspace aplikaci? Treba ssh, md5sum, mplayer, mpg123, putty? Vzdyt by to byla cista smrt.
[131] dobre, takze pro pole 64kB unrollne mega jitovaneho blivajzu, aby mela code-cache "lehci zivot"? :) A checky se ztrati kam?
To uz je podruhe, co slysim, ze "unrollnuty spatny kod je rychlejsi" - haha. Ne, je jen spatny^2, rychlejsi o zanedbatelnou rezii cykleni, prevazenou do zaporna rezii nacitani cache, rezii dekodovani instrukci na hranach cacheline... no, hanba domyslet :).
nehlede k tomu, ze ten cyklus mel variabilni pocet opakovani, tj. unroller by musel resit vskok dovnitr tak, aby ukonceni vyslo na ten cyklici loop, blablabla... proste zlaty voci, pohadky z CHIPu.
[128] Mě by zajímala tahle metrika. Vždycky jsem programoval věci, který sežerou procesor a když je napíšu blbě, tak poběžej klidně 10x pomaleji.
A tady každej druhej tvrdí, že je to uplně buřt, že 'všechny' programy vlastně nedělaj nic, takže je jedno, v čem se napíšou... OMFG
Pravděpodobně jsou tedy OS, Office, cokoli s videem apod. jen 'výjimky' a všechno ostatní se může psát v basicu...
Na rozdíl od jednoho z předřečníků tvrdím, že C++ je to nejlepší z obojího. Neefektivita kompilátorů, co tak vadí Zilogátorovi, je druhá naprosto nesouvisející věc.
[134] mne nevadi ani tak samo C++, jako spis styl programovani a navyky programatoru, ktere s sebou prineslo.
vadi mi nasilna objektovost tam, kde nema co delat. objekty maji zapouzdrovat rychle funkcni celky, a ne ze kazda pitoma operace uvnitr smycek bude take metoda, a vse bude objekt, malem intem pocinaje...
uz jsem videl i objekt pixel a virtualni metodu "nastav rgb", co podle sirky pixely delala 8:8:8 nebo 5:6:5 zapis... :)
[139] Mno a čemu ty metody vaděj? Když je krátká, tak se inlinuje, když je static, nepotřebuje ani this. Pokud potřebuje šmatat po proměnných, tak je stejně musíš předat, takže jediný, o co přicházíš, tak je nutnost dereference proměnný, což stejně je dneska jedna lea nebo tak něco. Virtuální metody sou zase jen převlečený pointery na fce. Je to jako C, jen se syntaxí pro lenochy ;)
A zase je třeba oddělit problém kompilátoru od problému jazyka.
Díky všem dosavadním diskutujícím za příspěvky, byť jenom zlomek z nich se přímo týká mé otázky.
Jeden citát pro Zil0gatora (a Vikiho a další): "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Jak už napsal Michal Kára v nějakém předchozím příspěvku, důležitá je hlavně asymptotická složitost algoritmu. Zvolit správnou datovou strukturu a algoritmus je základ rozumně rychlého běhu programu. Dnes málokomu záleží na jednom nebo několika CPU cyklech; o speciálních případech, kde to má význam, se nepřu.
Dobrý programátor napíše rozumný program takřka v čemkoliv a "lepič" bude mít tendenci psát spaghetti kód v jakémkoliv jazyce. Ale ta některými nenáviděná Java umožňuje minimalizovat škody a i ty méně zdatné programátory svým způsobem vede.
Pokud ale člověk neudělá botu v návrhu a základních algoritmech, má kompilátor nebo interpreter dost prostoru pro vlastní optimalizace. Proč třeba nenechat na něm, jestli inlinovat tu kterou funkci, když se z modulu nikam nevyváží? Vlk se nažere a koza zůstane celá - kód se (často) zpřehlední a zároveň je rychlost stejná, jako by ten kód byl napsán v každé metodě. Dříve se doporučovalo v C používat dereferenci namísto indexování a dnes to kompilátor zkompiluje do rychlého kódu tak jako tak. Ve funkcionálních jazycích například může kompilátor nahradit koncovou rekurzi iterací, funkcionální konstrukce typu map nebo reduce / fold bez destruktivních operací lze dokonce automaticky paralelizovat.
V mnoha případech interpretované jazyky rychlostně postačují, přesto nejsem ani já občas nadšen dosaženým výkonem a ptám se, zda není možné spojit "výhody obou světů" nebo hledat rozumný kompromis. Několik tipů tady zaznělo, díky za ně. Samozřejmě uvítám další názory.
[141] Knuth si to muze dovolit, coby autor jedne z mala BEZCHYBNYCH aplikaci. Bohuzel si neuvedomil, ze ne kazdy programator k tomu pristupuje s jeho peci (napr. v TeXu odvozoval datove typy zpracovani vystupu od vlnove delky viditelneho svetla, jako totalniho maxima myslitelneho DPI:).
Kdyby napr. autori GCC platili za bugy stejne jako on... tak zchudnou behem odpoledne.
[141] to neplati. pro realne objemy zpracovavanych dat se VELMI LEHCE stane, ze trivialnejsi (a hloupejsi) forma algoritmu jde naimplementovat jako daleko efektivnejsi zalezitost.
Typicky ruzne nekolikaprvkove sorty (3D rendery), vyhledavani, memory-management, cache-management...
Ze ma nejaky algoriotmus lepsi op. sloz z nej jeste nedela vhodneho kandidata k implementaci.
[143]: ad knuth: Jenze prave tenhle jeho citat byl myslen obecne :-)
[144]: Rychlejsi nebude. No a? Smysl managed jazyku neni, aby byly rychlejsi nez nativni, ale aby byly dostatecne rychle pro aplikace v nich vyvijene (coz neni rozhodne 100% aplikaci) a aby vyvoj v nich byl efektivnejsi.
[147] smim vedet, ktera aplikace si muze dovolit tu svatokradez mrhat strojovym casem a pameti? hm?
napadaji mne jen jednoucelove formulare pro pristup do databazi, tj. klikatka pro urednictvo. v podstate jakakoli jina aplikace musi byt skalovatelna co do kvantity zpracovavanych , a tedy napsana efektivne, no way.
[145] Ano, jistě, to je pravda. Asymptotická složitost například zanedbává konstanty, které mohou být občas nepříjemně velké. Přesto si myslím, že většina lidí neudělá chybu, pokud použije standardní knihovní řadící funkci a případné problémy s výkonem bude řešit až podle potřeby.
[147] [149] V době velmi nedávné jsem musel napsat program, který zpracovával 20GB textových denních logů.
Napsal jsem to v Perlu i s vědomím, že to jeden den přechroustá za 2 hodiny. Protože v C/CPP bych to psal dýl a určitě bych to zvoslil, tady jsem to naplácal prakticky bezrizikově za pár minut.
Na jednorázovku to bylo dobrý, ale kdyby se to mělo dělat pravidelně, asi to v tom C napíšu. Nechtěl bych vidět, jak dlouho by to trvalo v něčem ještě vyšším.
Zase mi z toho vypadlo něco tak staroprdelního jako 'všeho s mírou', no ;-)
[150] jako treba STLkovy sort (uvnitr implementovan jako introsort) - to jest ten, co pri neireflexivnim operatoru< (a op a musi byt false). takze pokud si ho nejaky C++ nadsenec do pretypovani nahradil necim jinym, co sice porovnava, ale tuto vlastnost nema, skonci v segfaultu.
a ted mi rekni - kolik C++ "lepicu" o tomhle vi? btw. ve widlich neni introsort, takze tam jim to "projde". Pak to nekdo zkusi naportovat (C++ je preci portabilni, jako spravna HLL), a ... :)))
[148] Mylis se, ja se celou tu dobu bavim o .Net, jenze ty z prispevku ctes kazde pate slovo, to se pak neni cemu divit ze plodis takovy blaboly.
Jeden specificky snippet nic nedokazuje, navic, ja netvrdim ze napr. C# JE rychlejsi ci stejne rychle jako C, pokud se to napise dobre, je to dost rychle ze to dokaze konkurovat, a dokaze to uspokojit potreby vsech s tim, ze v C# to mam napsane Xkrat rychleji.
Pokavad chces nejakou technologii otevrene bashovat, tak dukazy prekladej ty, neco tvrdit jen tak halabala, s tim jdi do politiky.
[153] ja budu tak velkorysy, ze ti dovolim dokazat to na tom tvem .NETu. jsi to ty, kdo tvrdi neco nepravdepodobneho, tak se opri o argumenty. Ja a mnozi dalsi si opravnene myslime, ze bytecode, navzdory JITovani, bude i v takto trivialnim pripade pomalejsi, nez nativne zkompilovy usek kodu. Mas sanci to vyvratit.
[154] u GCC je spis problem "pokud nekdo neumi naimplementovat STL", protoze, jak uz zminoval Linus, je to bugovy DES a HRUZA. Napr. pitomy std basicstring NEMA atomicky handlovany emptystr usagecount.
Dusledek? Kdo ve vice threadech bude zakladat basicstringy, a zase je rusit, muze se na konci podivit, ze mu to spadne. Duvod? Reference neni v heapu, ale .data, nastavena na 1 uz v sekci binarky (POD-object). A kdyz se dva konstruktory setkaji, zvedne se jen o 1, a destruktor pak zavola free nad .data :>.
Pravda dnes uz to opravili (gcc4ka), ale do te doby vsichni hlasali, jak je to STL skvele, a jak je nutne pouzivat basicstringy vsude, kde to jde... trapas.
[157] pozor, tam pisi, ze porovnavali proti rucne optimalizovane asm verzi Q2 - predpokladam, optimalizovane pro Pentium-I - tj. striktni prokladani dvou streamu ("nepouzijes tentyz registr ve 2 instrukcich vedle sebe").
coz je ovsem na PentiuIV (coz byl asi referencni procesor te doby?) nekolikanasobne zpomaleni, kvuli zvrhle uzkemu portu do registerfile (v podstate se vykon redukuje na 1 pipeline, protoze regfile nestiha pripravovat operandy, a z mezivysledku sousedni instrukce z ROB to brat nejde).
Na tyto testy bacha, na PentiuIV bezi rucne optimalizovany kod pro PentiumI vylozene spatne. A nemuzeme obvinovat jeho autory, nemohli tusit, ze u Intelu obrati o 180 stupnu a vznikne hruzne P4 (jedina metoda, jak na PIV napsat solidni strudl instrukci, je neustale hrabat pres [EBP+0xxx] na stack - pak se pipeliny nezadrhavaji - tj. to, co produkuje nejblbejsi kompilator, co si ani local var neumi nechat v registru, sigh :(.
Takze na miru blbym HLL uz se ku*vi i procesory, jak je videt. Takze dekujeme :(.
[158] Pokud vim, tak ID Soft releasnul cely VS.2003 projekt, tzn. spise v dobach PIII a ne PI.
Navic, docela si uderil hrebicek na hlavicku, k cemu ti budou tvoje super-1337 ASM optimalizace, kdyz s jinym procesorem budou akorat pomalejsi, zatimco moje managed app pobezi prinejmensim stejne.
Nemluve kdyz to same spustim na x86-64 / IA-64.
[140]
... ze misto cyklu, co by sosal argumenty v RGB, a sjoinovane do fyzicke podoby je praskal do pole framebufferu, se vubec volala nejaka fce, a navic virtualni metoda...
samozrejme, je mozne, aby nejaky hypoteticky kompilator
i z "nejoptimalnejsiho" mozneho zapisu napr. konverze nibble->hex:
unsigned char num=5; //treba
char hexascii;
hexascii = num + ((num > 9)?('A' - 10):('0');
udelal:
cmp al,0ah ;2B
sbb al,069h ;2B
das ;1B
... ale jak by na to prisel? i kdyby mel tenhle figl zakodovany nekde ve "slovniku obratu", musel by tuhle semantiku rozpoznavat a detekovat v ruznych podobach...
