Mám rád C++, méně kódu, více keců

28.5.2008 19:51 | Přečteno: 2408× | Ostatní | poslední úprava: 28.5.2008 20:25

Minule jsem se zájmem sledoval flame pod kraťoučkým blogem a velkým kusem kódu, co nic nedělá, ale je polymorfní, zapouzdřený a kdo ví jaký ještě :).

Včera mi vedoucí v práci řekl, že jsem jednoduše založením programátor. No je pravda že mi tenhle způsob vyjadřování mi nedělá problémy. I když třeba logické paradigma mi vůbec, ale vůbec nesedí.

Můj první jazyk byl Basic ještě na PMD 85 s procesorem MHB 8080A (2,048 MHz) :), jó to byl stroj, kdo ví kde skončil… I v té jeho hloupé grafice jsem uměl kreslit krychle, a podobně. V textovém režimu jsem dokázal nakódit hru Snake z Nokie a pak i Tetris, který byl vzhledem k použitému jazyku a interpretru neuvěřitelně pomalý. Tenhle skoro jazyk jsem zmáknul asi za dva měsíce, ono v něm taky nejde skoro nic složitého dělat, spíš hrozí návyk otřesných konstrukcí, nebezpečný příkaz goto je stále po ruce. I přes absenci jakéhokoli strukturování programu, přes to, že není nijak omezená viditelnost proměnných, vzpomínám na tuhle část mé programátorské cesty velmi rád, bylo to odkrývání tajemství, bez jakéhokoli vedení a hlavně nezřízená zábava :).

Potom se do mě snažili ve škole natlačit Pascal, ale naštěstí jsem odolal :) a s nadšením jsem se pustil do C :). V C jsem programoval dlouho předlouho. Zamiloval jsem si pointerovou aritmetiku, správu paměti a takové ty slasti, strasti a propasti C. Snad můžu s velkou skromností říct, že v C programovat umím. Taky jsem už pár věcí napsal, a nebyly to jen úkoly do školy, ale moc jsem necítil nutnost psát nějaké aplikace zrovna v C. Je to celkem pracné, když si takovou utilitu můžu nabouchat v něčem skriptovaném… Rozhodně ale C patří k mým oblíbencům, aby taky ne :). Pokud budu potřebovat něco rychlého, a šetrného na paměť tak to napíšu v C.

Java byla první objektový jazyk se kterým jsem měl tu čest se pořádně potkat a naučit se ho používat. Myslím si, že pro první seznámení s objektově orientovaným programováním je velmi vhodná. Ve spojení s dobrým IDE (osobně používám NetBeans) se učí Java velmi rychle a příjemně. Člověk se nemusí starat o paměť (to má své pro i proti), výsledná aplikace je celkem rychle hotová, funguje jak má (pokud je správně navržena), kód je přehledný (pokud je aplikace správně navržena). Celkem mi zachutnaly vyjímky, protože ošetřování neočekávaných stavů například v C je spojeno s celkem nehezkými konstrukcemi, povětšinou s goto.

V mezičasu se objevil z výukových důvodů Haskel, ano funkcionální paradigma je fajn, ale k srdci mi nepřirostlo, obzvlášť ve spojení s občas dost praštěnou syntaxí Haskelu, a celkové nepoužitelnosti tohoto jazyka na nějakou běžnou aplikaci. Netvrdím že to nejde, je to věc zvyku, ale můj zvyk to není. Tenhle model není moc vhodný k řešení běžných aplikací, alespoň z mého pohledu.

No a před asi čtyřma měsíci jsem se víceméně z nutnosti pustil do C++ a opravdu, ale opravdu se mi líbí. Je pravda, že občas si říkám, že je to vlastně maškaráda nad C :), ale moc hezká. Když to člověk bere jako objektový jazyk, tak to tak funguje a moc bobře. Navíc můžete spravovat paměť jak se vám líbí. Když si dáte tu práci s kopírovacími konstruktory, get a set metodami, přetížením operátorů, tak nemusíte skoro starat o paměť (za předpokladu, že třídy jsou dost malé na to, aby se daly alokovat na zásobníku).

Možná je to troufalost, že se tenhle jazyk učím za pochodu, a už tři měsíce mě to živí, ale zatím to jde a nikdo si nestěžovatl.

A nakonec: kolik jazyků umíš tolikrát jsi programátorem :).

       

Komentáře

[springer]

.... Zamiloval jsem si pointerovou aritmetiku, správu paměti a takové ty slasti, strasti a propasti C. ...

... nemel jsem chut psat aplikace v C ...

Takze po tisici, jazyk C neni urcen pro psani aplikaci ale pro psani nastroju pro psani aplikaci.

[vogo]

když to bereš takhle, já bych to používal jen na psaní knhoven

[AHAHA]

Jsi snad K&R? A mají do toho K&R vůbec co kecat? C byl vytvořen pro psaní OS a systémových utilit, proč by se ale nemohl používat i na jiné věci?

Každý ať si programuje v tom, co mu vyhovuje nejvíc.

[YYY]

Moje rec. Vzdyt kvuli pravu svobodne volby pouzivam svobodny software

[Let_Me_Be]

No, hlavne je Cecko soucasti POSIXu, coz je uroven na kterou se zadny jiny programovaci jazyk nikdy nedostal. Ale to je asi tak vsechno co se da o Cecku rict

[kralyk z abclinuxu]

souhlasím, c++ je super...
Kde bych byl například bez šablony vector,
a to přetěžování operátorů je sice taková okrasná záležitost, nicméně v praktickém použití pak ten kód vypadá velmi přehledně a elegantně, než furt volat nějaké metody a dosazovat do nich...

Co vidím jako nevýhodu (možná) je občas trochu zvláštní chování konstruktorů, myslím, že kapitolu vytváření a mazání tříd má např. object pascal řešenou lépe, ovšem to je věc názoru...

[vogo]

šablony jsou nejlepší vynález hned po po proudech a jejich operátorech << a >>

[kozzi]

+1

[andree]

yoyo, to ked som prvykrat videl pocitanie faktorialu sablonami, som sa celkom bavil :)

[Let_Me_Be]

Faktorial je traparna Hezci je celociselna odmocnina.

[Kyosuke]

Počítání faktoriálu šablonami místo funkcí? To je ta věc, u které v Lispu stačí místo DEFUN použít DEFMACRO, ale v C++ člověk musí přepisovat syntaxi? To je věc, kterou jsem na C++ nikdy nepochopil - když už chci umožnit zpracování v čase kompilace, není třeba ausgerechnet vymýšlet druhý jazyk a pak lidi nutit používat oba, když stačí jenom jeden.

[elviin]

Je dobry vedet, ze nikdo v dobe navrhu standardu C++ nevedel, ze se pouziti sablon dostane, tam kde je. Nikomu neslo o druhy jazyk. Navic vypocet faktorialu, prvocisel a podobnych veci neberte vazne jako priklad z praxe. Je to uzitecny nastroj, a pokud nepisete knihovnu, tak tu obtiznejsi cas muzete vynechat.

[Kyosuke]

No jak se to vezme. Možná se pletu, ale kdyby ten jazyk byl jednotný, nepsaly by se třeba líp partial applicatory? A to není zase tak nepraktická záležitost.

[AHAHA]

C++ používám rád a od doby, co jsem udělal zkoušku z OOP/C++ k němu chovám velký respekt (šílenosti alá - rozhodněte zda bla, bla (pozn. tuhle vlastnost žádný překladač nepodporuje, ale najdete ji v referenčním manuálu)).

C++ je snad nejkomplexnější jazyk, který existuje. Jeho referenční manuál roste exponenciálně s počtem vydaných standardů, naopak zpoždění implementace v překladačích se s každým novým vydáním lineárně zvyšuje (C++03 už tu máme 5 let a žádný překladač jej AFAIK plně nepodporuje).

[kralyk z abclinuxu]

naopak zpoždění implementace v překladačích se s každým novým vydáním lineárně zvyšuje (C++03 už tu máme 5 let a žádný překladač jej AFAIK plně nepodporuje).

Jo, to je pěkně na*****, co vlastně c++3 přináší?

[Luboš Doležel (Doli)]

Opravdu tam bylo něco nového?

For some years after the official release of the standard, the committee processed defect reports, and published a corrected version of the C++ standard in 2003.

[elviin]

zde je seznam zmen. Nejprve originalni odstavec ve standardu a pak zmena.

[Jirka P]

C++03 už tu máme 5 let a žádný překladač jej AFAIK plně nepodporuje

Sice nevím, co c++03 přináší, ale aspoň Comeau a EDG frontendy o sobě tvrdí, že ho podporují celý.

[s0]

vůz jede do vozovnu Ponkrác

teď jen udělejme nz prstů křížky a modleme se, nechť Míla dorazí a uvede to na pravou míru

[Miloslav Ponkrác]

Až budu ředitelem, hlašte se u mě

Mě je v podstatě C++0x úplně ukradené, protože mám pocit, že je na houby a nic až tak super potřebného nepřináší. Abych řekl pravdu, jsem z něho zklamán. Podle mého by C++ potřebovalo hlavně lepší standardní knihovnu a zabudovat do standardní knihovny řadu věcí, které jiné jazyky mají už dávno. A tím se moc nezabývají.

Neříkám, že v C++0x nejsou věci, které nejsou dobré a potřebné, ale IMHO je jich zlomeček - například UTF-8, UTF-16 a UTF-32 konstanty, nebo knihovna regulárních výrazů plus další věcí, ale osobně jsem očekával od toho víc.

[MJ]

Žel není všechno zlato, co se třpytí (a něco není ani pyrit ). Velmi doporučuji článeček Dark side of C++ od Felixe von Leitnera.

[trekker.dk]

Abych pravdu řekl, ten text na mě dělá dojem, že autor si převážně stěžuje, že je něco blbě, když se to blbě udělá.

[MJ]

Spíš na to, že mezi tím udělat to správně a udělat to blbě je poněkud tenká hranice, která se navíc pěkně klikatí.

Tak jako tak to docela vystihuje nesporný fakt, že C++ je jazyk nadmíru obludný.

(Kdo se chystáte oponovat, zkuste si nejdříve přečíst normu C++. A pak znovu. A pak ještě jednou, než začnete mít pocit, že ji opravdu rozumíte. Pak ještě jednou, abyste ten pocit zase ztratili Mé názory na C++ pramení hlavně z toho, že jsem to svého času učinil.)

[Miloslav Ponkrác]

Tak jako tak to docela vystihuje nesporný fakt, že C++ je jazyk nadmíru obludný.

To je blbost. Kdybyste programoval před řekněme 20 lety, zjistil byste, že jsou ještě daleko daleko rozsáhlejší jazyky. To je dnes v posledních letech se jazyky vyvíjejí tak, aby byly primitivní na pochopení - je to ekonomicky výhodné.

Kdo se chystáte oponovat, zkuste si nejdříve přečíst normu C++.

Jazyky C a C++ mají jednu devízu - jsou velmi logicky postavené. Ve skutečnosti jejich principy jsou jednoduché pro člověka s logickým myšlením. Každá věc v C/C++ je postavena tak, že funguje bez výjimky na vše ve stejném duchu napříč celým jazykem - a až na pár výjimek tak jak by selským rozumem člověk očekával. Slovo selským rozumem myslím pohledem prakticky zaměřeného člověka bez fanatismu a bez předsudků stylu "protože to není v C/C++ tak jako v mém oblíbeném jzyce X, tak je to špatně".

Jinak přestože jste před lety učinil, že jste četl normu, tak jste tak učinil z mylného dojmu, že norma je učebnice C++, což není. Já před lety jsem si normu C++ vytiskl, a četl ve vlaku. Přišla mi velmi srozumitelná a velmi jsem se zdokonalil v C++, byla to ohromná devíza. Nicméně bylo to v době, kdy jsme v C++ léta programoval - protože žádná norma není učebnice. Pokud člověk ne příliš znalý C++ vezme normu, bude zákonitě zmaten.

Stejně tak se prakticky nikdo neučí XML tím, že si přečte normu, nikdo se neučí programovat sítě tak, že začne číst normy, nikdo se nezačne učit SQL tím, že si přečte normu SQL (mimochodem četl jste normu SQL? to je obludnost co?). Je nutné vědět co norma je a jaké je její určení - norma je puntičkářský dokument popisující všechny mezní stavy a všechno chování do posledního detailu, které pro C++ závazné. Nic víc a nic míň.

[MJ]

Jaký je rozdíl mezi normou a učebnicí, vím shodou okolností docela dobře, obojího jsem spoustu přečetl a trochu i napsal A ano, před 20 lety jsem programoval (a nikdy jsem netvrdil, že C++ je jedinou obludou)

Máte úplnou pravdu v tom, že norma C++ je složitá proto, že popisuje hromadu mezních stavů. Jenže to právě ukazuje na obludnost jazyka – kdyby byl navržen slušně, nebylo by v normě potřeba ošetřovat spousty okrajových případů, protože by jejich chování přímo plynulo z obecných definic. Srovnejte složitost normy C++ s krásou a elegancí normy Céčka (C99), nebo třeba se standardem Haskellu či Scheme. (A o její úplnosti by mohly vyprávět svoje třeba archivy mailing-listů autorů GCC.)

(SQL raději nekomentuji, to je C++ku důstojnou konkurencí. A XML ostatně také – tolik stránek textu na popis něčeho, co má vyjadřovací sílu lispových S-expressions...)

[Miloslav Ponkrác]

Srovnejte složitost normy C++ s krásou a elegancí normy Céčka (C99), nebo třeba se standardem Haskellu či Scheme.

A proč se tedy u větších projektů dává přednost C++ před Céčkem? Proč se tedy Haskell či Scheme masívně nepoužívá v praxi? Není ve Vaší úvaze chybka?

Ony LISPovské jazyky spíše ustupují ze scény - před léty si pamatuji, že byly podstatně rozšířenější, ale jejich rozšíření jde dolů. Pročpak asi?

Ona totiž krása a elegance ještě neříká nic o praktické použitelnosti toho jazyka - to je to.

Mě osobně přijde na to, že si stěžujete, že šroubovák, vrtačka, rašple a soustruh jsou příliš složité a neelegantní nástroje, protože vše se jednoduše a elegantně dá vyjádřit kladivem a namlátit to tam. A norma (manuál) ke kladivu bude určitě jednodušší, než norma k soustruhu, což Vy oceníte tím, že soustruh je zbytečnost, obludnost - protože kladivo je jednodušší.

[Radek Miček]

Ona totiž krása a elegance ještě neříká nic o praktické použitelnosti toho jazyka - to je to.

A proč by jazyky jako Haskell a Scheme neměly být prakticky použitelné? Ona totiž nízká rozšířenost a elegance neimplikuje praktickou nepoužitelnost.

[Miloslav Ponkrác]

Bohužel implikuje. Pokud se jazyk nepoužije na žádný více používaný projekt, nebo projekt kde jsou vysoké nároky, pak to není jeho dobrá vizitka.

[thingie]

Uá. Neimplikuje. Jak se může praktičnost jazyka změnit tak, že se v něm něco velkého napíše (a přitom se samotný jazyk nezmění vůbec)? Tohle se může stát jenom v C++, v Haskellu ne :-P

[Miloslav Ponkrác]

Nezlobte se na mě, ale jazyk, o kterém se kecá jak je prakticky dobrý, a nic moc praktického z něj nevychází za výsledky - pak se podobá ženské, která Vám léta slibuje sex a Vy přitom žijete jako poustevník.

Prostě jazyk, který nemůže ukázat větší praktické výsledky neukázal svojí praktičnost. Ale zase se o něm a jeho praktičnosti toho nakecá, to ano, ale jsou to jenom prázdné slibotechní řeči.

[thingie]

(Já jsem poukazoval na to nesmyslné tvrzení o té implikaci. Který teď neni třeba ošizovat nějakou omáčkou, prostě to byla blbost.)

Já praktické výsledky vidím a působí na mne mnohem lépe, než třeba když jsem si teď nainstaloval to velké C++ KDE. To sice možná je velmi praktické a používané a velkolepé, ale jako úžasná vizitka kvality C++ na mne naprosto nepůsobí.

[Miloslav Ponkrác]

Dobrá, implikace, že když se něco málo používá, je to nepraktické obecně neplatí. Naprostou máte pravdu, že je to blbost. Ovšem v extrémním případě, kdy Haskell je tu 18 let, a nic moc výsledky v podobě počtu prakticky použitelných programů, pak tato implikace má smysl. Možná, že Haskell se začne trochu používat, když mu dáme třeba ještě dalších 50 let, nicméně to už nebudu obyvatelem této planety, takže to pro mě nebude zajímavé.

KDE je postaveno na Qt, které není C++ knihovnou - je to něco co s čistým C++ nevystačí, potřebuje preprocessor a tak dál, a tak dál, ...

Jinak určitě počet dobrých projektů psaných v C++ je tak emorní z hlediska počtu, že určitě C++ svojí kvalitu ukázalo. Až bude totéž v Haskellu, nenapadne mě ani pochybovat.

Já nechci hanět Haskell, nicméně ptám se proč po 18 letech tu není velký počet programů v Haskellu psaných. Co za tím vězí? To není provokace, to je otázka, kterou myslím skutečně vážně.

[thingie]

Tu kde? Tu ano. A fungují, velmi dobře, oproti tomu novému KDE, které mě množstvím chyb skoro až šokovalo.

[Miloslav Ponkrác]

Já KDE neviděl už cca 10 let, takže vůbec nevím jak funguje. Jistě mě pochopíte, že nejsem v obraze ohledně KDE.

Navíc jsem známý svým negativním postojem ke všemu, čeho se dotklo Qt (i když hlavní důvod je licence Qt) - třeba mým častým argumentem je, že Qt knihovna špatně ošetřuje chyby, a že řada metod vrací void, ačkoli může selhat a není vlastně jak se dozvědět, že vůbec chyby vznikla, natož aby na ní mohl programátor nějak reagovat.

Navíc Qt je špatně poznamenána tím, že jí sice autoři napsali v C++, ale nechtěli C++, ale ObjectiveC a tak to aspoň zprasili pomocí preprocessoru moc, který jim nějaké vlastnosti ObjectiveC dodal. Na oplátku zase autoři C++ nevyužili kromě tříd nic z efektivity C++ a z jeho možností, takže Qt neberu za nic, co bych řadit silně k C++.

[thingie]

To je tak nějak součást té praktičnosti, že se v tom programuje tak jak „nemá“. Nebo žeby? Couž.

[Miloslav Ponkrác]

Ne, Qt je součást toho, že autoři Qt chtěli jiný jazyk a nesnášeli C++. A tudíž si ohli C++, nic více a nic méně. Něco asi jako když homosexuální módní návrhář určuje módu pro ženy, ale byly sexy

[MJ]

To je podobně nesmyslná otázka, jako kdybyste hodnotil jazyky přirozené podle toho, kolik stránek knih v nich bylo vytištěno (či ještě spíš kolik se nám dochovalo). Také by vám toto měřítko asi řeklo, že Fortran je lepší než C++

Počet programů je zřídka daný kvalitou jazyka, spíš (opět stejně jako u přirozených jazyků) jeho popularitou. To, co opravdu dává smysl srovnávat, jsou mistrovská díla v jednotlivých jazycích psaná.

[Radek Miček]

Já myslím, že si konkrétně Haskell dobyje své pozice, vždyť ho začínají používat i větší společnosti viz http://www.haskell.org/haskellwiki/Haskell_in_industry.

[Miloslav Ponkrác]

Já už do toho nebudu rýt, ale není to trochu málo po 18 letech existence od první ostré verze toho jazyka a ještě delšího vývoje před tím? Kam se dostala Java, Python, C++, a řada dalších jazyků za ten čas?

Jak říkám, možná Haskell ten potenciál má, neznám ho příliš - ale přeci jen mě to vrtá hlavou.

[Kyosuke]

No když Credit Suisse pro účely HPC přechází z C++ na Haskell všude, kde to technicky jde, tak na něm asi opravdu něco bude, že?

[Miloslav Ponkrác]

Nebude. Vzhledem k tomu, že výhoda C++ - tedy raketová rychlost výsledného programu, která byla tak potřebná v dobách slabších počítačů dnes ztrácí smysl - je logicky C++ masově na mnoha frontách nahrazováno vším možným. Od Pythonu, přes Javu, Ruby, C#, ... C++ díky silnějšímu hw ztratilo na mnoha místech opodstatnění a zcela logicky se dnes velmi často nahrazuje. A je to správné, a znamená to jenom to, že C++ zůstává na místech, kde potřeba efektivity a nenáročnosti na systémové zdroje je stále klíčové a jinde je výhodnější jiný jazyk.

Mě to prostě na skoro dvacetiletou existenci jazyka přijde dost málo.

[kralyk z abclinuxu]

Dokazovat úspěšnost projektu linkem na domovskou stránku toho projektu - to nic nedokazuje, takle dokazuje akorát Uhlán. Dokažte nějak seriózně, že haskell je úspěšný.

Jo a mimochodem, KDE de facto není v c++, takže nevím, proč tu někdo haní C++ na základě chyb KDE.
To je asi jako říct, že pascal je nanic, protože open office není dobrý produkt.

A nakonec: Na co je sebeelegantnější jazyk, když ho nikdo nepoužívá a nic se v něm nepíše?

[Radek Miček]

Dokažte nějak seriózně, že haskell je úspěšný.

A co byste si představoval?

Jo a mimochodem, KDE de facto není v c++

O KDE jsem nic nepsal, tak nevím proč reagujete na můj příspěvek.

A nakonec: Na co je sebeelegantnější jazyk, když ho nikdo nepoužívá a nic se v něm nepíše?

V Haskellu lidi píšou a používají ho. Kdybyste se porozhlédl po té domovské stránce Haskellu, tak byste našel odkazy na projekty, které jsou v něm napsané, je jich tam dost.

Jazyky jako Haskell a spol. jsou dobré k tomu, že obsahují mnoho zajímavých myšlenek, které se pak třeba dostávají i do běžných jazyků. Lepší by bylo, kdybyste ho třeba zkusil, než psal, že je k ničemu.

[kralyk z abclinuxu]

Lepší by bylo, kdybyste ho třeba zkusil, než psal, že je k ničemu.

Já neříkám, že je k ničemu.
Mám trochu představu jak ten jazyk vypadá ... teda, moc toho o něm nevím ... ale z toho, co vím, se mi moc nelíbí, zkoušet nebudu, mám c++ ...

[MJ]

A nedokumentuje to spíš nevelký rozhled většiny programátorů?

[pavlix]

Z čehož vyplývá, že jediný prakticky použitelný desktopový operační systém jsou Windows. Proč by se jim jinak dávala ve většině případů přednost?

[thingie]

Furt je to kolem dokola jenom evoluce bastlu. Ten jazyk není od počátku stavěn na silných teoretických základech, jako jsou třeba některé jiné.

[Miloslav Ponkrác]

Ano, C++ vniklo stejně jako C z potřeby udělat PRAKTICKÝ jazyk. Ono přiznejme si to, že v praxi se ty jazyky stavěné teoreticky moc neuplatňují, protože zkrátka to není praktické a neosvědčují se.

[thingie]

Nebo možná proto, že většina i z programátorů té teorii nakonec prd rozumí. A ono to v těch praktických jazycích vypadá, se stačí podívat kolem :-/

[Miloslav Ponkrác]

Jo s tím souhlasím. Dnešní programátoři z větší části neumějí nic. Doporučuji udělat anketu a zeptat se dostatečně velkého počtu programátorů na tyto otázky:

1) Co je to hašovací tabulka? 2) Co je to číslo NaN? 3) Jaké znáte metody třídění pole (odpovědi ve stylu zavolám metodu sort z knihovny se nepočítají)?

Složitější otázky z teorie se bojím uvádět - nicméně uvidíte i tak velmi žalostné výsledky. Přičemž před nějakým časem byste dostali od všech programátorů 100% správné a zasvěcené odpovědi. Jo holt doba se mění.

Nicméně žádný teoreticky hezký jazyk neprorazil. Neprosadil se v praxi - protože byl zkrátka příliš dřevěný a toporný v praxi a narážel na značná omezení. Případně jako druhou variantu vyžadoval IQ nad 150, a být ve střehu. Tudíž až akademici vymyslí něco prakticky použitelného za programovací jazyk, tak mi to nahlašte, ale myslím, že v tomto životě mě to asi nepotká.

[thingie]

Tohle ani nejsou otázky na teorii, to už jsou přece praktické věci.

Už vymysleli, jmenuje se to Haskell.

[Miloslav Ponkrác]

Kdysi jsem vážně přemýšlel, že si začnu s Haskellem a budu ho používat. Ale jestli někdo tu píše o obludnosti C++, pak Haskell zrovna není čistě navržený jazyk. A že některé jeho featury jsou dost obtížné na pochopení, to si pište. Uznávám ale, že určitě je to z funkcionálních jazyků asi nejpraktičtěji zaměřený jazyk. Nicméně dokážete si představit, že v tomhle se bude masově psát?

[thingie]

To možná ne, ale ty základy jsou tam podstatně jasnější a viditelnější.

Dokážu. Proč?

[Miloslav Ponkrác]

To možná ne, ale ty základy jsou tam podstatně jasnější a viditelnější.

Jenže základy jsou pro praxi málo. Stejně tak přeci není měřítko praktičnosti jak snando napíšete v jazyce základní program Hello world. V praxi se říší víc, než základy.

Dokážu. Proč?

Dobře, a kde jsou tedy ty řady projektů a programů prakticky stvořené v Haskellu?

[thingie]

Co tak se dívat kolem sebe?

[Miloslav Ponkrác]

Já tedy koukám, koukám a nic nevidím. Jediné, co jsem kdy slyšel, že bylo psáno v Haskellu je Darcs - version control system, který je ovšem neskutečně pomalý. Slyšel jsem o xmonadu - windows manageru psaném v Haskellu a o Pugs - cosi kolem Perlu6. A to jen proto, že jsem se zajímal, jinak bych asi vůbec netušil.

Nicméně několik málo aplikací, a to ne příliš významných, to mě nepřijde jako velký praktický potenciál toho jazyka. Nic proti Haskellu, ale buď má velký potenciál, který ovšem není využit, nebo prostě prakticky použitelný moc není. A na to, že je tu Haskell 18 let toho fakt moc neukázal - myslím v počtu programů.

[Radek Miček]

Darcs - version control system, který je ovšem neskutečně pomalý

To je již minulost Řada 1 měla totiž mergovací algoritmus s exponenciální složitostí, řada 2 to už napravila.

[thingie]

I to se projevilo jenom někdy. Ale když se to stalo, tak to bylo blbé, no.

[Kyosuke]

Pugs je Perl 6 napsaný z velké části za deset dní. To myslím o schopnostech Haskellu něco vypovídá - na implementaci programovacích jazyků je téměř ideální (ne že by se nehodil i na jiné věci, samozřejmě).

[Miloslav Ponkrác]

A proč když je to tak úžasně schopný jazyk se tedy téměř nepoužívá? Já opravdu neryju do Haskellu, mě to vážně zajímá - protože někde musí ten důvod být.

Jen tak mimochodem, intepretr Perlu "z velké části" za 10 dní napíšu i v C++, nebo v Pythonu, pokud mi o to půjde - protože oni jsou věci napsané velmi rychle. Jak se říká, nejdéle trvá posledních 10% - a následné odladění.

[Kyosuke]

Částečné vysvětlení viz ode mně o něco níže - síla jazyka může i něco stát.

Ufff...tak to je odvážné tvrzení. To bych rád viděl. Já když čtu věci jako tohle, tak se cítím méněcenný.

[happy barney]

interpreter hej ... ale parser za tých 10 dní nenapíšete )

Pokiaľ ma pamäť neklame, Haskell si zvolili preto, lebo syntax perl6 pár rokov dolaďovali a nikoho netrápila pomalosť výsledku.

[Kyosuke]

Microsoft si to nepochybně představuje, protože na fulltime zaměstnává vývojem haskellových technologií jednoho ze dvou hlavnách tvůrců kompilátoru GHC, především v oblasti paralelních výpočtů nevyžadujících žádné zámky ani synchronizaci (STM), a dotyčný kompilátor snad dokonce i sponzoruje. Haskell je sice netriviální, ale žádné jeho vlastnosti nelze označit za "arbitrární nápad autorů podle toho, jak se zrovna vyspali". Celé to stojí na matematice, která některé rysy de facto vynucuje (a tím odbourává částečně potřebu dokumentace funkcí, protože vše lze odvodit ).

Jediný problém pro běžné programátory bude, že dotyčné oblasti matematiky (teorie kategorií) všichni ostatní matematici (ti, co ji nepraktikují) říkají "generalized abstract nonsense". Jak by tomu říkali "entršpajz džavysté"?

[Miloslav Ponkrác]

Tohle ani nejsou otázky na teorii, to už jsou přece praktické věci.

Nicméně na čistou teorii jsem se neodvážil ani pomylet - podle mě 99% programátorů Vám nedá odpověď ani na tyto praktické otázky. Zkuste si to.

[Pavel Křivánek]

Nicméně žádný teoreticky hezký jazyk neprorazil. Neprosadil se v praxi - protože byl zkrátka příliš dřevěný a toporný v praxi a narážel na značná omezení. Případně jako druhou variantu vyžadoval IQ nad 150, a být ve střehu. Tudíž až akademici vymyslí něco prakticky použitelného za programovací jazyk, tak mi to nahlašte, ale myslím, že v tomto životě mě to asi nepotká.

Teoreticky hezké a čisté jazyky, které je snadné se naučit a jsou zárověň prakticky orientované, existují a minimálně s jedním jste se už během své kariéry setkal.

[Miloslav Ponkrác]

Přemýšlím, jestli si mám vzít nápovědu publika, nebo padesát na padesát.

[Pavel Křivánek]

To je fuk, hlavně, že ušetříme za telefon

Smalltalk-80 snad toto vymezení nesplňuje?

[Messa]

Smalltalk IMHO není jednoduché se naučit (syntaxi ano, ale naučit se něco praktického vytvořit ne).

Když jsem si pročítal Školičky, tak se tam na Smalltalk dost nadávalo, že to je nepovedený Lisp

[Pavel Křivánek]

Smalltalk IMHO není jednoduché se naučit (syntaxi ano, ale naučit se něco praktického vytvořit ne).

Jak se říká - člověk se naučí být v C++ produktivní za rok, ve Smalltalku jen za 365 dnů .

Zvládnout Smalltalk znamená z 1% naučit se syntaxi, z 30% základní knihovnu a z 68% naučit se v tom systému efektivně orientovat a pracovat. Zbylé jedno procento vystihuje neuchopitelnou složku, která zapřičiňuje, že i po letech dokáže Smalltalk člověka stále překvapovat

Když jsem si pročítal Školičky, tak se tam na Smalltalk dost nadávalo, že to je nepovedený Lisp

Ta školička je tady. Je to obdoba toho, jako by někdo hodnotil uživatelskou přívětivost OpenOffice podle rozbalených ODF souborů. Většina výtek na gramatiku totiž směřuje na exportní formát pro zdrojové kódy, se kterým se běžně programátor vůbec nesetká (autor psal o Smalltalku na základě seznámení s ořezanou implementací, která vznikla především pro scriptování a od plnohodnotného smalltalkovského systému byla v té době na míle vzdálená). On se snažil ve Smalltalku hledat Lisp a přitom zcela opomenul jeho základní a unikátní vlastnosti, které ho od Lispu odlišují. Pokud chcete objektivnější porovnání s Lispem, obraťte se třeba na Kyosukeho, který rozhodně netrpí tunelovým viděním (pokud se nenachází zrovna v nějakém tunelu)

[Kyosuke]

Ano, to znám: "In seeking the unattainable, simplicity only gets in the way." (Alan Perlis)

[Kyosuke]

Stejně tak se prakticky nikdo neučí XML tím, že si přečte normu, nikdo se neučí programovat sítě tak, že začne číst normy, nikdo se nezačne učit SQL tím, že si přečte normu SQL

Tak já jsem podle Vás "nikdo"?

[Miloslav Ponkrác]

Pane Kyosuke, vy jste vyjímečný a vyjímečně nadaný a schopný jedinec.

[Kyosuke]

Ne, jen jsem divnej. Proto mám taky tolik rád Scheme, tam nemusím číst tisíc stránek jako u C++, stačí jen šedesát. Zbytek funkčnosti se dá přitom logicky odvodit ze základních axiomů. To já mám rád.

Na druhou stranu, ze stejných důvodů se nepouštím do věcí, jako je XSLT, XML Schema a podobně. Odmítám používat věci, které nemají jednoduchou a snadno pochopitelnou vnitřní logiku. (Ostatně, pokud jde o XML, bohatě mi stačí SXML a dílo Olega Kiselyova a Kirilla Lisovského - umí to všechno, co tzv. "XML standardy" a přitom nemusím míchat několik odfláklých jazyků dohromady a stačí mi jeden dobře navržený.)

[Miloslav Ponkrác]

Budu hledat co nás spojuje: Nemám rád XML, ani XSLT, a přijde mi zejména to XSLT jako hodně blbě postavené nalepovací schéma. O XML se myslím leccos, zejména to, že se používá víc, než je užitečné, a že jeho standardy jsou zbytečně složité, ale chápu, že W3C se něčím život musí a musí vykazovat činnost, ať to stojí co to stojí. Možná kdyby mě tak dobře platili, jako těch pár lidí, co píšou XML standardy, že taky horu stránek vyplodím.

Sice nevím, co je to SXML, ale k XML a k transformačním jazykům mi něco na způsob LISPu strasně sedí. Nemůžu si pomoci, ale právě u XML transformačního jazyka by vyjadřovací síla LISPu byla nádherná věc, a přitom mnohem jednodušší, než to co existuje dnes jako paskvil zvaný XSLT.

P.S.: Pokud byste věděli, jak získat dobře placené teplé místečko u W3C komise, určitě slibuji, že napíši další verzi XSLT, která bude ještě složitější a bude mít daleko více stránek.

[kralyk z abclinuxu]

To, na co si ten týpek stěžuje, považuju já za vychytávky

[Let_Me_Be]

Boze co to je za vola?

[Sinuhet]

Opakovany vtip neni vtipem.

[Miloslav Ponkrác]

Velmi doporučuji článeček Dark side of C++ od Felixe von Leitnera.

Tak jsem se mrknul, a získal jsem dojem, že vlastně dvě třetiny argumentů se hodí na jakýkoli programovací jazyk.

Například napsat nečitelný kód se dá v naprosto každém programovacím jazyce, když tomu budete věnovat dostatek snahy.

O tom, jak těžké je parsovat C++ kód mě nezajímá, protože to udělá jednou výrobce kompilátoru a mě spíš zajímá, zda mi syntaxe pomůže. Navíc výrobce kompilátoru řeší tak těžké úkoly, že proti tomu je parsování C++ něco primitivně snadného. Mimochodem, nadává pan Felix von Leitner také na regulární výrazy, protože rozložit regulární výraz na vnitřní graf tak není zrovna snadné - pan Felix von Leitner by měl používat zásadně jen funkce str* funkce z C, protože regulární výrazy "is too hard to implement". Rád bych aby zmíněný pán byl konzistentní ve všech směrech.

Jinak výše zmíněnému pánovi by také neškodilo, aby zjistil, jak C++ funguje, protože dělat ze sebe kreténa tím, že píšu, jak se chovají výjimky, když o tom nic nevím, to se utlučete smíchy, pokud C++ znáte, vřele tuto pasáž od výše zmíněného pána doporučuji.

Pokud pan Felix s von titulem nebude psát v C++ s jeho neznalostí C++, a tento dokument pomůže k tomu, že bude o jednoho špatného programátora méně, pak vítám jeho aktivitu.

[MJ]

O tom, jak těžké je parsovat C++ kód mě nezajímá, protože to udělá jednou výrobce kompilátoru a mě spíš zajímá, zda mi syntaxe pomůže.

Tuhle větu si vystříhněte a přečtěte znovu, až budete luštit nějaký cizí složitý program Shodou okolností složitost parseru často koreluje s obtížností porozumění kódu.

(Jinak si také dovoluji dodat, že konverze regulárního výrazu na graf je naprosto triviální záležitost. Programoval jste ji vůbec někdy?)

[Miloslav Ponkrác]

Tuhle větu si vystříhněte a přečtěte znovu, až budete luštit nějaký cizí složitý program Shodou okolností složitost parseru často koreluje s obtížností porozumění kódu.

Luštím cizí složité programy přes patnáct let.

Jinak si také dovoluji dodat, že konverze regulárního výrazu na graf je naprosto triviální záležitost. Programoval jste ji vůbec někdy?

Konverze regulárního výrazu na graf je jednoduchá věc, nicméně určitě o několik řádů složitější, než napsat funkce typu strchr, strtok, strrchr, strlen, strcat. A protože pan Felix von cosi odsuzuje jakékoli zbytečné těžkosti při implementaci, a protože vyjadřovací síla str* funkcí je určitě větší, než regulárních výrazů - pak je potřeba aby pan Felix odsoudil regulární výrazy a napsal "Regular expression is hard to implement/parse".

Ono ve skutečnosti parser C++ není nic extra těžkého, je to v zásadě dost jednoduchý problém. Nijak jsem si nevšiml, že by kompilátory s tím měly problémy. A upřímně si myslím, že bych daleko rychleji implementoval dobrý C++ parser, než dobrou knihovnu regulárních výrazů.

[Ladicek]

Ono ve skutečnosti parser C++ není nic extra těžkého, je to v zásadě dost jednoduchý problém.

Jasně, syntaktická analýza je v zásadě velmi jednoduchý problém. A třeba u té Ady se i velmi jednoduše řečí, protože ta má rozumně navrženou gramatiku. Ale fakt by mne zajímalo, jak může soudný člověk při plném vědomí navrhnout takový humus plný konfliktů, jako je C/C++ (a další to prezentovat jako nic komplikovaného).

Je samozřejmě pravda, že parsery C++ píše pár lidí na světě, ale to na skutečnosti nic nemění.

A upřímně si myslím, že bych daleko rychleji implementoval dobrý C++ parser, než dobrou knihovnu regulárních výrazů.

A to já bych teda zkoušet nechtěl. Dobrý parser pro mě znamená kvalitní detekci a zotavení se ze syntaktických chyb, a to musí být u C++ pěkný masochismus. Jenom zběžně jsem teď prolítnul C++ parser v ANTLR a není to nic hezkýho (a pochybuju, že to bude nějaký hi-fi, co se rozumně vypořádá s vadným vstupem).

Když jsem před časem četl učebnici C++, říkal jsem si, že takový překladač C++ musí mít minimálně devět průchodů jako u PL/1

[Miloslav Ponkrác]

Ale fakt by mne zajímalo, jak může soudný člověk při plném vědomí navrhnout takový humus plný konfliktů, jako je C/C++ (a další to prezentovat jako nic komplikovaného).

Mě přijde, že s tím humusem přeháníte. Ale i kdybych souhlasil, na Vaší otázku je jednoduchá odpověď: Až nějaký čistý a nehumusoidní jazyk dokáže řešit praktické problémy, které řeší C++, C++ se stane zbytečným. Můžeme tu vést akademické debaty, ale Stroustrup prostě C++ stvořil, protože žádný použitelný jazyk neexistoval. Protože jak se ukázalo, potřeba přesně takového jazyka byla přesně to, co chybělo v praxi (on pan Stroustrup také řešil praktický problém), razantně se C++ rozšířilo. A C++ je tu proto, že tu není nic co by ho nahradilo, a už tuplem ne v "nehumusoidních jazycích".

Dobrý parser pro mě znamená kvalitní detekci a zotavení se ze syntaktických chyb, a to musí být u C++ pěkný masochismus.

Stejně tak u mě dobrá regulární knihovna znamená mnohem víc, než jen zobrazení do grafu - musí se zohlednit rychlost, možnost různých znakových sad, pracovat v řadě různých režimů, atd.

Jinak určitě je praktičtější udělat složitější syntaxi, kde se deset lidí zapotí při návrhu dobrého parseru s detekcí chyb, a desítkám miliónu programátorů to ulehčí práci, než vymyslet jazyk, kde deset lidí v pohodě udělá parser a desítky miliónů programátorů se bude prát s méně praktickou syntaxí. To je zase můj praktický pohled - a z toho mého praktického pohledu složitost implementace parseru syntaxe je nevýznamná.

Nicméně stále si trvám na tom, že C++ parser i s dobrou detekcí chyb a zotavením není nijak vrcholné programátorské dílo.

[Ladicek]

Ten humus jsem myslel po stránce gramatiky. Po sémantické stránce hodnotit C++ nemůžu, ale že se dají šablony znásilnit například k zápisu gramatiky, z něhož překladač vygeneruje parser, mi přijde svým způsobem docela zvrhlé A jak sám píšete výše, C++ je na řadě míst nahrazováno jinými jazyky, často jednoduššími (a relativně méně ohavnými).

Je fakt, že u knihovny pro regulární výrazy na rychlosti záleží o hodně víc, než u parseru programovacího jazyka. Prča to určitě není, když dnešní regulární výrazy mají v podstatě sílu zásobníkového automatu, ale když jsem koukal třeba na implementaci regexpů ve standardní knihovně Javy, tak jsem se pořád aspoň jakž takž orientoval. Ale můj pohled je zřetelně ovlivněný tím, že regulární výrazy docela znám, kdežto i samotná syntaxe C++ ve mně vzbuzuje akorát tak hrůzu.

[Miloslav Ponkrác]

A jak sám píšete výše, C++ je na řadě míst nahrazováno jinými jazyky, často jednoduššími (a relativně méně ohavnými).

Kdyby ta věta v závorkách byla pravda, bylo by fajn. Netvrdím, že C++ je nejlepší na světě, a je naprosto v pořádku, když ho na některých místech nahradí jazyk s daleko lepšími výhodami pro danou oblasti použití, ale někdy se nahrazuje jazyky, že mi běhá mráz po zádech. Raději nebudu jmenovat, abych nevyvolal flame.

Jinak u mě syntaxe C++ nevzbuzuje hrůzu, ale možná je můj pohled ovlivněný tím, že jí znám lépe, než ty regulární výrazy - tedy z hlediska implementace.

[MJ]

Až nějaký čistý a nehumusoidní jazyk dokáže řešit praktické problémy, které řeší C++, C++ se stane zbytečným.

Vidíte, a spousta lidí je ještě stále přesvědčena, takový jazyk existuje už dávno a jmenuje se C Překvapivě ho i v dnešní době mnoho lidí preferuje před C++.

Jinak určitě je praktičtější udělat složitější syntaxi, kde se deset lidí zapotí při návrhu dobrého parseru s detekcí chyb, a desítkám miliónu programátorů to ulehčí práci, než vymyslet jazyk, kde deset lidí v pohodě udělá parser a desítky miliónů programátorů se bude prát s méně praktickou syntaxí.

To je pravda, ale je to argument spíš pro Haskell

[Miloslav Ponkrác]

Vidíte, a spousta lidí je ještě stále přesvědčena, takový jazyk existuje už dávno a jmenuje se C

Znovu se ptám, jaká je výhoda C před C++ (pominu-li výhody styly několikrát dražší vývoj, horší možnosti při týmovém programování, a podobné)? Zvláštní je, že pokud firma musí platit náklady na vývoj a nedělá triviální projekt složitosti něco málo nad "Hello world", ani jí nenapadne dnes při rozhodování mezi C a C++ sáhnout po Céčku.

Céčko je příliš low level na to, aby řešilo praktické problémy. Ano, samozřejmě, můžete si postavit dům stylem, že si sám vyrobíte hřebíky, vypálíte vápno, postavíte si pec na cihly, které si vyrobíte - což je zhruba to co nabízí C.

Takže znovu se ptám, a zatím jsem nedostal odpověď - jaká je výhoda použití C oproti C++? Jediné odpovědi, které jsem dostal je nenávist vůči C++. A jinou asi nedostanu, protože pokus se na C a C++ podíváte bez předsudků, tak to C musí prohrát na plné čáře - a to bez jediného bodíku pro Céčko.

[Algi]

Vidíte a přesto se mi čisté C líbí více než C++. Akorát mu chybí výjimky (které se tu už také někde řešily). Avšak pokud bych chtěl programovat nějakou aplikaci, tak bych dal přednost Objective-C. Jako Javista jsem v něm byl schopný napsat malinkou knihovnu velmi rychle, aniž bych se ten jazyk nějak zvlášť učil. Mě se na C++ nelíbí věci jako je předefinování operátorů, vícenásobná dědičnost, apod.

To vše Objective-C nemá, avšak nabízí místo toho spoustu jiných zajímavých vlastností. Jsou jimi například posílání zpráv objektu, který je nil, aniž by program spadnul. Další jsou selectory, díky nimž lze přeposlat zprávu objektu, který jí rozumí.

Je mi jasné, že jinde než na Macu si Objective-C moc neužijete. Je sice pravda, že Foundation je z části (nebo již úplně?) portováno na Linux. Však jsem také na Linuxu s ObjC začínal. Jenže k tomu, aby se dal tento jazyk používat na všech platformách to má ještě daleko a myslím si, že se to ani nikdy nestane.

Jen si tak vzpomínám, jak jste někde nakousnul v čem tedy píše Adobe své programy. Odpověď je velmi prostá: ty které jsou velmi letité a staré (Photoshop, apod.), ty píše kupodivu v Carbon API. Proto nemohou být 64-bitové a musí být časem přepsány. Přece jenom ta pupeční šňůra ze starého MacOS by se už jednou měla přestřihnout. No a nové programy (jako je Lightroom) píše kupodivu pod Cocoa. Díky tomu může být 64-bitový.

[Miloslav Ponkrác]

Vidíte a přesto se mi čisté C líbí více než C++.

Ano, ale to je dost subjektivní důvod.

Jako Javista ... Mě se na C++ nelíbí věci jako je předefinování operátorů, vícenásobná dědičnost, apod.

Ano, typický přístup Javistů - oni jsou zvyklí na tom, že co nechtějí používat je potřeba zakázat. Napadlo Vás taky někdy, že když se Vám nelíbí featura F, že jí nemusíte používat?

Jen si tak vzpomínám, jak jste někde nakousnul v čem tedy píše Adobe své programy. Odpověď je velmi prostá: ty které jsou velmi letité a staré (Photoshop, apod.), ty píše kupodivu v Carbon API. Proto nemohou být 64-bitové a musí být časem přepsány. Přece jenom ta pupeční šňůra ze starého MacOS by se už jednou měla přestřihnout. No a nové programy (jako je Lightroom) píše kupodivu pod Cocoa. Díky tomu může být 64-bitový.

A není trochu uhozené na hlavu, jestliže 64-bitový MaCOS si předepisuje programovací jazyk, ve kterém se musí psát programy? Mě se třeba na Linux, Windows, a asi tak miliónu dalších OS líbí, že si mohu zvolit jazyk podle svého, ať už to bude cokoli - a řekl bych, že tato možnost volby je plusem i z obchodního hlediska pro výrobce OS.

Ale jinak díky za informaci. Doufám, že u Maca jde jen o porodní bolesti 64-bitové verze, protože jinak jsem rád, že Mac existuje.

[MJ]

Ano, typický přístup Javistů - oni jsou zvyklí na tom, že co nechtějí používat je potřeba zakázat. Napadlo Vás taky někdy, že když se Vám nelíbí featura F, že jí nemusíte používat?

Mně spíš přijde, že zrovna tato featura je v C++ značně nedotažená: přetěžovat operátory sice jde, ale definovat vlastní už nikoliv. Přirozený důsledek je, že když chcete definovat nějaký nový operátor, musíte použít jméno stávajícího naprosto neintuitivním způsobem. Typický případ je << a >> zneužité pro I/O.

[Miloslav Ponkrác]

Souhlas.

Nicméně i tak jak to je, je to velice šikovné.

[Algi]

Jako Javista ... Mě se na C++ nelíbí věci jako je předefinování operátorů, vícenásobná dědičnost, apod.

Ano, typický přístup Javistů - oni jsou zvyklí na tom, že co nechtějí používat je potřeba zakázat. Napadlo Vás taky někdy, že když se Vám nelíbí featura F, že jí nemusíte používat?

Moment, kdo mluvil o zakazování? Já jenom říkám, že se mi ta vlastnost nelíbí a proto jsem rád, že v ObjC ani v Javě není. V C++ ji nemám rád a proto, když jsem v něm chvilku programoval ve škole, tak jsem to nevyužíval.

A není trochu uhozené na hlavu, jestliže 64-bitový MaCOS si předepisuje programovací jazyk, ve kterém se musí psát programy? Mě se třeba na Linux, Windows, a asi tak miliónu dalších OS líbí, že si mohu zvolit jazyk podle svého, ať už to bude cokoli - a řekl bych, že tato možnost volby je plusem i z obchodního hlediska pro výrobce OS.

Mac nepředepisuje jazyk, který musíte používat. Carbon API je již od svého vzniku označeno jako "deprecated" a sloužilo pouze pro přechod mezi Mac OS classic a Mac OS X. Apple chce, aby se už konečně přestalo používat, proto vynechává podporou pro 64-bit.

Krom toho, kdo vám přikazuje používat na Macu Objective-C? Naopak, je tam přímo v XCode podpora pro kupu dalších programovacích jazyků: Ruby, Python, Java a samozřejmě i C a C++. Kde vidíte ten zákaz? Pokud chci programovat aplikaci pro více systémů, zvolím Javu nebo C++. Jestliže chci naplno využívat API, které mi Mac poskytuje, zvolím Objective-C a Cocoa. Krom toho, spousta frameworků umožňuje používat čisté C. Příkladem budiž AddressBook.framework, který má binding přímo na C.

Nevím přesně, co porodními bolestmi s 64-bitovým systémem na Macu myslíte, ale slyšel jste někdy o Universal Binary? To je totiž to, co Linux a Windows nemají. Naopak tyto systémy bych nazval těmi, kteří si své porodní bolesti s 64-bitem teprve prožívají. Protože spouštění 32-bitových binárek na 64-bitových Windows je prý zajímavé dobrodružství. Pokud lžu, vyvraťte prosím.

[Miloslav Ponkrác]

Moment, kdo mluvil o zakazování? Já jenom říkám, že se mi ta vlastnost nelíbí => proto jsem rád, že v ... není.

Ano, nemluvíte o zakazování, jen tam prostě existenci té featury nechcete. Zkrátka mluvíte o zakazování.

Krom toho, kdo vám přikazuje používat na Macu Objective-C? Naopak, je tam přímo v XCode podpora pro kupu dalších programovacích jazyků: ... Jestliže chci naplno využívat API, které mi Mac poskytuje, zvolím Objective-C a Cocoa.

Pokud k _plnému_ využití API potřebuji jeden konkrétní jazyk, v tomto případě ObjC, pak se to nenazývá plná podpora jiných jazyků. To je to, o čem jsem mluvil.

Nevím přesně, co porodními bolestmi s 64-bitovým systémem na Macu myslíte, ale slyšel jste někdy o Universal Binary? To je totiž to, co Linux a Windows nemají. Naopak tyto systémy bych nazval těmi, kteří si své porodní bolesti s 64-bitem teprve prožívají. Protože spouštění 32-bitových binárek na 64-bitových Windows je prý zajímavé dobrodružství. Pokud lžu, vyvraťte prosím.

Namísto universal binary je prostě možné mít několik binárek, výsledek je tentýž. Jinak vyvracet nic nemohu, protože moje zkušenosti s 64 bitovým Linuxem a Windows jsou tak mizivé, že nevím o tom vůbec nic.

[Algi]

Namísto universal binary je prostě možné mít několik binárek, výsledek je tentýž. Jinak vyvracet nic nemohu, protože moje zkušenosti s 64 bitovým Linuxem a Windows jsou tak mizivé, že nevím o tom vůbec nic.

Programoval jste někdy v Javě s pomocí JNI? Pak by se vám tento přístup velmi znechutil. Promiňte, ale proč bych měl nutit uživatele, aby si vybíral, pro jakou verzi svého systému si má stáhnout program. Díky Universal Binary mám všechny 4 architektury v jedné binárce a je hotovo. Pro JNI naprosto ideální situace. Načte se jeden soubor .dylib a mám vystaráno. Naopak na Windows a na Linuxu se s tím musím zvlášť kompilovat pro každou architekturu, kterou chci podpořit. Teď si představte, že chci zároveň podporovat PowerPC, zároveň Intel a pro každý z těchto ještě 32-bit i 64-bit. Bavilo by vás kompilovat 4 různé verze a pak vyrábět 4 různé balíčky, mezi kterými by si uživatel musel vybírat? Mě ne.

K té plné podpoře API. Na Windows pokud vím máte pouze C# a C++. Na Macu je hlavní C a Objective-C. Co je na tom špatné? Nebo hodláte podporovat 20 frameworků pro každý jazyk zvlášť? To my přijde s prominutím trochu přehnané.

Já když napíšu, že jsem rád že tam nějaká vlastnost není, tak to neznamená že to někomu zakazuji. Nejsem diktátor. Proto pokud existuje jazyk jako C++, který obsahuje vlastnosti, které nemám rád, tak jej nepoužívám. To jenom vy máte pocit, že to chci zakázat. Díky tomuto pocitu bych v tom případě zakazoval i Linux a Windows, protože je nepoužívám a jsou v nich vlastnosti, které se mi nelíbí. Je to tak?

[MJ]

Vybrat správnou verzi k nainstalování je starost balíčkovacího systému, ne uživatele. Naopak mi přijde hloupé, abych měl na disku každou binárku 11x delší, protože můj OS běží na 11 různých architekturách.

[Miloslav Ponkrác]

Ad 1) Samozřejmě souhlasím, že je to pohodlnější pro uživatele mít vše v jednom. I já bych si přál na Windows mít jeden instalační balíček se vším. A taky bych si to hlavně přál na Linuxu, aby nebyl jeden balíček pro Debian, jiný pro Suse, jiný pro Ubuntu, .... Ano, nepopírám, že je to pohodlné, a proti universal binary nemám nic, zvláště ne v dnešní době terabajtových disků. Bezvadné by bylo, kdyby ještě universal binary podporovalo možnost, že až se objeví pátá platfroma stáhnout patch a doplnit jí do binárky.

Ad 2) Na Windows nejsem nijak omezen ve výběru programovacího jazyka, mohu používat co se mi zlíbí a ve všech dostanu plnou podporu Windows API. Totéž velmi omezeně na Linuxu, i když tam už to dře.

Nejde o 20 frameworků, základ je ten, že základ musí mít takové API, aby ho dokázal využít jakýkoli jazyk.

Ad 3) Spíš píšu obecně pro většinu diskusí tady. Mě se taky spousta věcí v sw nelíbí, a sice to zkritizuji, ale ať to existuje dál. Je super, že si každý může vybrat. Vlastně jsem rád, že lidi se mnou i často nesouhlasí, protože se dozvím hodně užitečných věcí a zkusím něco jiného. Třeba pan Kyosuke mě aniž to tuší neustále inspiruje k tomu zkusit hlubiny Haskellu, Vy spolu s dalšími třeba podívat se na dnešní stav ObjC, a navíc Maca jsem vždycky obdivoval za to, že se ve světě Apple objevují super zajímavé nápady, nejenom sw. Takže mě to moc zajímá.

[Algi]

Ad 1) No, bohudík udělali Universal Binary natolik inteligentně, že se tam vkládají pouze rozdíly mezi platformami. To znamená, že většinu tvoří univerzální kód a pokud se narazí na místo, kde je to nutno zkompilovat rozdílně, tak se udělá odskok. Tam se provede strojově závislý kód a pak se zase jede dál. Docela zajímavá technologie.

Bohužel v případě Windows a Linuxu by to Universal Binary bylo asi opravdu obrovské. Apple má tu výhodu, že podporuje v podstatě "pouze" čtyři platformy. Díky tomu se takto zkompilované binárky příliš nenafukují. Konkrétní čísla však nemohu dodat - přece jenom se stále hlavně věnuji vývoji v Javě.

Ad 2) API je sice napsané v Objective-C, avšak i zde máte možnost používat jiného jazyka. Bohužel s tím nemám praxi, ale všiml jsem si, že kupříkladu takový Python, nebo Rubi může využívat funkce z Cocoa.

Ad 3) Jistě, svým způsobem i pro mě je tato diskuze zajímavá. A je to jeden z důvodů, proč na Abclinuxu chodím. Abych neztrácel přehled o ostatních systémech. Akorát jsem zjistil, že jsem krapet háklivý na to, když někdo trvdí nesmysly, nebo (dle mého názorou) šiřil nepřesnosti. Příkladem může být tvrzení, že Mac není UNIX, musím na něm používat pouze ObjC, apod.

Na druhou stranu, nelze Applu upřít snaha, aby všichni používali na jeho systému Objective-C. Takže ačkoliv tam existuje velmi dobrá podpora pro binding ostatních jazyků na systémové API, tak není možné přehlédnout tento fakt. Svým způsobem je to logické, avšak brání to ve tvorbě přenositelných nativních programů. Svého času se Apple snažil portovat své knihovny i na Windows - viz projekt YellowBox. Důvody, kvůli kterým toho zanechal jsou mi nejasné. Možná chce chránit vlastní technologie (proto nejsou open-source), možná by to bylo složité (například Core Animation, Quartz, apod.). Čert ví

[MJ]

Výhoda je jasná: Jednoduchost (a ještě poměrně donedávna daleko lepší přenositelnost, protože na interpretaci různých zákoutí normy C++ se překladače prostě neshodly; krásný případ je spor o to, zda lokální deklarace proměnné v cyklu platí jen uvnitř cyklu nebo až do konce okolního bloku). Nedává smysl používat řádově složitější jazyk, pokud nemá opravdu podstatné výhody, mimo jiné proto, že je daleko méně pravděpodobné, že ho někdo bude umět kompilovat efektivně. A opravdové výhody, upřímně řečeno, v C++ nevidím. Většina toho, co C++ nabízí, je pouze nepříliš elegantní syntaktické pozlátko. Výhody pro týmové programování jsou iluzorní, slušné interfacy lze navrhovat v C úplně stejně jako v C++. Vše si rozhodně od základů stavět nemusíte, to už udělali jiní a dali k dispozici jako knihovny.

Souhlasím, že programovat všechno nízkoúrovňově je pitomost, ovšem C++ je na tom v tomto ohledu prakticky stejně jako C. Můj osobní názor je, že buďto potřebujete vyždímat z hardwaru poslední ždibíček výkonu, a potom je C jasně nejlepší volba (pokud budete psát v C++, stejně ho budete používat jako Céčko, protože jinak to bude pomalé). A nebo na výkonu tolik nezáleží, a pak je na místě sáhnout po daleko abstraktnějším jazyku, ať už je to Haskell, Python nebo Erlang.

V C++ chybí naprosto zásadní věci: třeba lambda-funkce (které se mimochodem v některých rozšířeních Céčka dají snadno stvořit – třeba v GCC) nebo slušná generika (šablony jsou pouze parodie na generika, přibližně stejně dobrá jako preprocesor Céčka). Také je hodně důležité, aby jazyk nebyl příliš uzavřený a když vám v něm něco chybí, mohl jste si to dodefinovat (nebo typičtěji použít knihovní modul, který vám to dodefinuje). C++ (i Céčko) to umí v podstatě jen pomocí maker, doopravdy to můžete dělat ve většině dialektů Lispu, v novějších rozšířeních Haskellu nebo třeba v Perlu6. A tak dále.

[Miloslav Ponkrác]

Výhoda je jasná: Jednoduchost

Kde? Jaký je problém vzít C++ a psát v něm úplně stejně jako v C - a nevíc postupně využívat další featury, které C nemá? Já nevidím, že by C++ muselo být složitější, než C.

(a ještě poměrně donedávna daleko lepší přenositelnost, protože na interpretaci různých zákoutí normy C++ se překladače prostě neshodly; krásný případ je spor o to, zda lokální deklarace proměnné v cyklu platí jen uvnitř cyklu nebo až do konce okolního bloku).

Dotaz: Kde se dnes C++ překladače neshodnou? Argumenty, které jsou přes deset staré mě nezajímají, nebo tu taky vytáhnu, jak hrozně nepřátelský byl Linux před deseti lety a jeho distribuce.

Nedává smysl používat řádově složitější jazyk

C++ není složitější. Zajímavé je, jak spousta lidí má paniku a hrůzu, pokud dostanou do ruky nástroj o velkými možnostmi - přičemž - a to je podstatné - je nikdo nenutí využívat všechny možnosti naráz. V podtextu říkáte, že prostě C++ je příliš mocné, možností má moc a Vy se neumíte vybrat, a proto chcete radjěi omezenější nástroj. Vždyť je to jednoduché: Proč nepoužíváte jen ty možnosti, které chcete?

Jinak složitost jazyka nic neříká, například digitální foťák je řádově složitější, než foťák na film - a Vy byste si vybral tedy ten na film, když máte kritérium jednoduchosti konstrukce.

C++ je složitější pro výrobce kompilátorů, než C, ale není složitější pro programátora. Je konstrukčně složitější, ale předpokládám, že 99,9999% lidí tady co diskutuje nevyrábí C++ kompilátory. Z hlediska programování v něm můžete programovat stejně jednoduše jako v C, neboť to v sobě v podstatě celé Céčko má.

Většina toho, co C++ nabízí, je pouze nepříliš elegantní syntaktické pozlátko. Výhody pro týmové programování jsou iluzorní, slušné interfacy lze navrhovat v C úplně stejně jako v C++.

He he he he he. Fakt nemám slov. Úplně jste mě odzbrojil, Vy jste člověče víc věřící, než leckterý pámbíčkář. Vlastně přemýšlím co na to říct - asi takhle - vysvětlete dvouletému dítěti, jak úžasný může být sex, když tento zážitek ještě nepoznalo.

Souhlasím, že programovat všechno nízkoúrovňově je pitomost, ovšem C++ je na tom v tomto ohledu prakticky stejně jako C.

Tu větu myslíte vážně? Já jenom, abych se neztrapnil tím, že jsem nepoznal pokus o vtip a ironii a nebral to vážně?

Můj osobní názor je, že buďto potřebujete vyždímat z hardwaru poslední ždibíček výkonu, a potom je C jasně nejlepší volba (pokud budete psát v C++, stejně ho budete používat jako Céčko, protože jinak to bude pomalé).

Ano, a v čem je C++ pomalejší, než Céčko? Moje volba je, že pokud chci vyždímat poslední ždibíček výkonu, tak je C++ jasně nejlepší volba. Od možností inline funkcí a možnosti optimalizací pomocí šablon plus řadu dalších možností, které v C nejsou tu ani nezmiňuji.

Ne, pokud bude psát rychlostně efektivní kód v C++, tak ani náhodou ho nebudu používat jako Céčko.

třeba lambda-funkce(které se mimochodem v některých rozšířeních Céčka dají snadno stvořit – třeba v GCC)

A v C++ se dají stvořit ve zcela standarním C++ na každém kompilátoru - nepotřebujete žádná rozšíření.

nebo slušná generika (šablony jsou pouze parodie na generika, přibližně stejně dobrá jako preprocesor Céčka

Ok, další ironie z Vaší strany, beru.

Také je hodně důležité, aby jazyk nebyl příliš uzavřený a když vám v něm něco chybí, mohl jste si to dodefinovat (nebo typičtěji použít knihovní modul, který vám to dodefinuje). C++ (i Céčko) to umí v podstatě jen pomocí maker

Opět ironie.

[MJ]

A v C++ se dají stvořit ve zcela standarním C++ na každém kompilátoru - nepotřebujete žádná rozšíření.

Jak? Tím (s prominutím) hnusem, který nabízí Boost?

(Jinak na ostatní vaše rádobyargumenty si dovolím neodpovídat a raději v duchu přesně opačném než titulek tohoto článku tvořit více kódu, zato však méně keců.)

Pokud chcete seriózní argumenty, raději se předveďte s nějakým kusem kódu v C++, který by podle vašeho názoru nešel elegantněji napsat v jiném jazyce.

[Miloslav Ponkrác]

Jak stvoříte lambda funkce ve _standardním_ C? Ve standardním C++ to jde.

Ohledně posledního odstavce: Cokoli jde napsat elegantněji. Jenže my jste neporovnávali "jiný jazyk", ale konkrétně C a C++.

[MJ]

Jinak ano, vše, co jsem předtím psal, jsem myslel naprosto vážně, včetně (nevyřčených) pochybností o Vašem odborném rozhledu.

[Miloslav Ponkrác]

Pochybovat o mém odborném rozletu samozřejmě můžete, na to máte plné právo. V tomhle nikomu nebráním, a nikdy jsem tu nepsal, že jsem super odborník. Naprosto respektuji Vás v tom, že si o mě můžete myslet cokoli. Jen nebudu Vám to nějak vyvracel - reaguji pouze na věcné argumenty o tématu, zbytek je Váš osobní názor, který respektuji.

K věci - asi si to chce vyzkoušet větší týmový projekt v C a pak v C++. A ideálně za vlastní peníze, kdy ten vývoj budete platit z vlastní kapsy. Myslím, že pak nebudu muset nic argumentovat, protože pochopíte sám, jak to je a nevěřím, že byste poté našel jediný argument proč dát přednost C.

[MJ]

K věci - asi si to chce vyzkoušet větší týmový projekt v C a pak v C++. A ideálně za vlastní peníze, kdy ten vývoj budete platit z vlastní kapsy.

Větších týmových projektů v C jsem už pár vedl (a vývoj aspoň v některých dobách platil), kupříkladu takový Holmes. V C++ jsem napsal jen řádově 10k řádků, ale měl jsem to potěšení vývoj několika velkých projektů sledovat. Vím tedy svoje

To podstatné naťukl už Kyosuke: C++ je docela vhodný jazyk, pokud chcete na velkém projektu zaměstnat spoustu průměrných programátorů (a tím pádem téměř nutně vytvářet projekt průměrné kvality; to na druhou stranu ke komerčnímu úspěchu často stačí). Pokud má být projekt špičkový a máte na to špičkové lidi, C++ je zřídka optimální volba.

[Miloslav Ponkrác]

V C++ jsem napsal jen řádově 10k řádků

Měl jste napsat hned, že C++ nerozumíte...

měl jsem to potěšení vývoj několika velkých projektů sledovat.

A všechny byly dobře vedeny Doufám, že poté co jste viděl několik rozvodů jste se analogicky rozhodl neženit se, po setkání a seznámení s tím, že existuje AIDS jste se rozhodl zůstat do konce života bez sexu, apod..

Většin sw projektů skončí špatně, ať je použito na jejich programování cokoli. To je bohužel smutná pravda - prý ani ne 5% sw projektů dopadne podle očekávání.

C++ je docela vhodný jazyk, pokud chcete na velkém projektu zaměstnat spoustu průměrných programátorů

Bohužel pravda je zcela opačná, dnešní průměrný programátor na C++ těžce pohoří. Na C++ potřebujete nadprůměrného programátora, což je obrovské mínus pro C++.

Pokud má být projekt špičkový a máte na to špičkové lidi, C++ je zřídka optimální volba.

Vzhledem k tomu, že každý projekt potřebuje něco jiného, tak Vaše tvrzení má nula bitů informace. Podle druhu projektu a účelu výsledného produktu je optimální volba pokaždé něco jiného. Jediné co tvrdím, že pokud se rozhoduji mezi C a C++, je v 99,9999% případů optimální volba C++. Nicméně to nevyvrací to, že pro většinu projektů není dvojice C/C++ vůbec vhodná volba, a je lépe použít něco jiného.

[MJ]

Netvrdím, že C++ rozumím. Spíš tvrdím, že mu doopravdy nerozumí téměř nikdo. Nesouhlasím, že úplně porozumět jazyku potřebuje pouze autor překladače. Každý zkušený programátor na obskurní kouty jazyka při své práci dříve či později narazí (pokud ne, pak jazyk nevyužívá pořádně) a i v těchto koutech by se jazyk měl chovat přímočaře.

Právě zde je ohromná výhoda Céčka (a jeden z hlavních důvodů, proč je třeba vývojáři jádra Linuxu rozhodli pro C, ačkoliv nějakou dobu kernel zkoušeli v C++ psát): když se na program podíváte, daleko snáze vidíte, co doopravdy dělá.

Jeden docela pěkný příklad za: Když v C předáte funkci jako parametr proměnnou, je okamžitě vidět, že ji funkce nijak nezmění. V C++ musíte studovat deklaraci oné funkce, abyste se ujistil, že parametr není předáván referencí, a pokud je, tak se podívat dovniř funkce (nebo věřit její dokumentaci), že je to pouze kvůli rychlosti a ne kvůli tomu, aby se hodnota měnila.

Samozřejmě to není nijak zásadní problém, jen je takových drobností v C++ spousta.

[Miloslav Ponkrác]

Spíš tvrdím, že mu doopravdy nerozumí téměř nikdo.

A není Váš dojem daný spíše tím, že se nepohybujete v C++ kruzích? Já například stále nemohu uvěřit, že existují nějací černoši, protože je nepotkávám.

Nesouhlasím, že úplně porozumět jazyku potřebuje pouze autor překladače. Každý zkušený programátor na obskurní kouty jazyka při své práci dříve či později narazí (pokud ne, pak jazyk nevyužívá pořádně) a i v těchto koutech by se jazyk měl chovat přímočaře.

Není potřeba žádný jazyk znát na 100%. A na obskurní kouty jazyka narazíte po nějaké praxi jenom tehdy, když se tam vydáte.

Právě zde je ohromná výhoda Céčka (a jeden z hlavních důvodů, proč je třeba vývojáři jádra Linuxu rozhodli pro C, ačkoliv nějakou dobu kernel zkoušeli v C++ psát): když se na program podíváte, daleko snáze vidíte, co doopravdy dělá.

Vývojáři jádra se rozhodli pro C z historických důvodů. Kdyby ho psali o trochu dřív, možná by jádro psali v module, nebo Adě, a Linus by dnes vykřikoval, jak je C k ničemu, protože Ada/Modula je jejiná správná volba. V C++ museli zákonitě selhat, protože ho nezvládali. Nic víc a nic méně.

Jinak já daleko snáze vidím co dělá C++ zdroják, než C zdroják, ta rychlost pochopení cizího zdrojáku je u C++ několikanásobně rychlejší. A to mám mnohaletou praxi v C.

Jeden docela pěkný příklad za: Když v C předáte funkci jako parametr proměnnou, je okamžitě vidět, že ji funkce nijak nezmění. V C++ musíte studovat deklaraci oné funkce, abyste se ujistil, že parametr není předáván referencí, a pokud je, tak se podívat dovniř funkce (nebo věřit její dokumentaci), že je to pouze kvůli rychlosti a ne kvůli tomu, aby se hodnota měnila.

A jste si tím jist co píšete? Když třeba předáte pole, tam vidíte v C kulové ohledně změny, či nezměny. Stejně tak se v C často předávají ukazatelem třeba rozsáhlé struktury, protože je to efektivnější, a to i tehdy, když funkce danou strukturu nezmění. Takže nemusíte poznat nic.

[MJ]

A není Váš dojem daný spíše tím, že se nepohybujete v C++ kruzích?

Nikoliv, je dán jednak sledováním vývoje překladačů (jeden by čekal, že lidé, kteří překladače programují, jsou jedněmi z nejlepších znalců jazyka), jednak velmi častými příklady programů, které nejdou novou verzí překladače přeložit, ač s tím starší (či jiný) překladač nemá sebemenší problémy. Jistě, jsou to konstrukce, o kterých se nakonec ukáže, že je nejnovější verze normy zakazuje, alespoň když ji čtete dostatečně pozorně, ale samotný fakt, že překladačům (a tvůrcům normy) trvalo několik let, než zkonvergovaly k tomu, že taková konstrukce není korektní, vypovídá o mnohém.

A jste si tím jist co píšete? Když třeba předáte pole, tam vidíte v C kulové ohledně změny, či nezměny. [...] Takže nemusíte poznat nic.

Jistě, jsou situace, kdy nepoznám nic ani v Céčku. Ale v mnoha případech poznám, zatímco v C++ prakticky jen tehdy, když předávám konstantu

[Miloslav Ponkrác]

jeden by čekal, že lidé, kteří překladače programují, jsou jedněmi z nejlepších znalců jazyka

A důvod proč si to myslíte?

Jistě, jsou to konstrukce, o kterých se nakonec ukáže, že je nejnovější verze normy zakazuje

V C++ existuje jenom jedna jediná norma.

Ale v mnoha případech poznám, zatímco v C++ prakticky jen tehdy, když předávám konstantu

Nepoznáte nic, například Linus prosazuje tento prototyp:

void free(const void*);

[MJ]

A důvod proč si to myslíte?

Inu, máloco donutí člověka rozmyslet si i ty nejtemnější zákoutí jazyka, jako psaní překladače.

V C++ existuje jenom jedna jediná norma.

Ano, oficiální norma existuje jenom jedna, leč 10 let stará a prakticky žádný překladač se podle ní neřídí. Obvykle se snaží řídit spíš podle nejnovějšího draftu normy nové...

Nepoznáte nic, například Linus prosazuje tento prototyp:

A co má být? Jedním protipříkladem kvantifikátor "skoro vždycky" nepopřete

Naopak Vaše tvrzení o tom, že nepoznám nic, se popře velmi snadno. Třeba: double sin(double x);.

[Miloslav Ponkrác]

Inu, máloco donutí člověka rozmyslet si i ty nejtemnější zákoutí jazyka, jako psaní překladače.

To bych neřekl. Stejně tak jako s velkou lodí umí jezdit lépe zkušený kapitán, než stavitel lodi. Psaní překladače je o tom v zásadě zalgoritmizovat normu (tedy výsledek práce jiných lidí - návrhářů C), ale určitě bych byl dalek tvrzení, že autoři překladačů jsou největší znalci C++. Navíc psaní překladače je z 99% psaní optimalizátoru.

Ano, oficiální norma existuje jenom jedna, leč 10 let stará a prakticky žádný překladač se podle ní neřídí.

Zvláštní, programuji v C++ už hrozně dlouho, ale ničeho takového jsem si nevšimnul.

Naopak Vaše tvrzení o tom, že nepoznám nic, se popře velmi snadno. Třeba: double sin(double x);.

Ale mluvil jste cosi o tom, že to poznáte bez toho, aniž byste se kouknul na prototyp. Zatímco jste C++ kritizoval za to, že ten prototyp potřebujete vidět, abyste věděl co potřebujte.

[MJ]

1) Nezapomínejte, že tvůrci norem jazyků jsou v drtivě většině případů autoři překladačů.

2) I u funkce free, kterou jste zmiňoval, z volání velmi dobře poznám, že proměnnou, kterou jsem ji předal, nezmění.

[Kyosuke]

C++ není složitější. Zajímavé je, jak spousta lidí má paniku a hrůzu, pokud dostanou do ruky nástroj o velkými možnostmi - přičemž - a to je podstatné - je nikdo nenutí využívat všechny možnosti naráz. V podtextu říkáte, že prostě C++ je příliš mocné, možností má moc a Vy se neumíte vybrat, a proto chcete radjěi omezenější nástroj. Vždyť je to jednoduché: Proč nepoužíváte jen ty možnosti, které chcete?

No já nevím. Totéž by se dalo říct třeba o Lispu, proč se spousta lidí tak strašně bojí, že dostane do ruky mocný nástroj? (Přičemž jsem to opravdu slyšel jako argument proti používání Lispu ve firmách - "představte si průměrné javisty, co by v tom začali dělat, buďme rádi, že takhle aspoň nenapáchají škodu".)

Jako mnohem podstatnější problém vidím, že většina komplexity C++ je zbytečná - zcela shodně mocný jazyk lze založit i na mnohem jednodušší gramatice a sémantice. A zbytečnou složitost bych viděl jako mnohem větší problém, než zbytečnou sílu jazyka - zatímco za vyjadřovací schopnost jsem rád i za cenu toho, že přečíst něco po některých lidech může chvilku trvat (případ Lispu), při zbytečné složitosti mi to čtení občas může trvat ještě déle, ale nezískám tím zhola nic (případ C++).

Od možností inline funkcí a možnosti optimalizací pomocí šablon plus řadu dalších možností, které v C nejsou tu ani nezmiňuji.

Možná jste si toho nevšiml, ale standardní C má inline funkce taky.

A v C++ se dají stvořit ve zcela standarním C++ na každém kompilátoru - nepotřebujete žádná rozšíření.

A jak se chovají jejich volné proměnné?

Ok, další ironie z Vaší strany, beru. ... Opět ironie.

Myslím, že to myslí vážně. A já to vidím asi tak stejně. A někde jinde tady jsem se k tomu už vyjádřil - C++, když už ni jiného, nutí lidi učit se dva jazyky tam, kde jiným jazykům stačí jen jeden.

[Miloslav Ponkrác]

No já nevím. Totéž by se dalo říct třeba o Lispu, proč se spousta lidí tak strašně bojí, že dostane do ruky mocný nástroj? (Přičemž jsem to opravdu slyšel jako argument proti používání Lispu ve firmách - "představte si průměrné javisty, co by v tom začali dělat, buďme rádi, že takhle aspoň nenapáchají škodu".)

Já tenhle argument taky nechápu. Proč lidi považují za mínus jazyka, že je mocný? Zajímavé je, že nikomu nevadí třeba chodníky, po kterých nechodí, nebo lesy, které nenavštívil, a nemá potřebu zrušit chodník třeba v Košicích, protože on ho nechce používat a do Košic nechodí. Ale vidí C++ a vadí jim, že jsou tam věci, které nehodlají používat, tak ať je ksakru nepoužívají! Jak jednoduché.

Jako mnohem podstatnější problém vidím, že většina komplexity C++ je zbytečná - zcela shodně mocný jazyk lze založit i na mnohem jednodušší gramatice a sémantice.

Je a není zbytečná. Většina komplexity v C++ není proto, že to nelze udělat jednodušeji, ale proto, že komplexita podstatně zvyšuje možnost rychlostních optimalizací. C++ je dělaný na max. rychlost a nízkou spotřebu zdrojů a tomu je podřízeno naprosto vše. Proto taky píšu, že tohle je účel C++ a asi není moudré nasazovat C++ tam, kde tyhle vlastnosti nevyužijete.

Navíc stále platí, že C++ je systémově laděný jazyk - je to jazyk, který si vystačí sám se sebou, teoreticky v něm napíšete naprosto všechno i hodně low level a C++ nepotřebuje podporu žádného jiného jazyka. I to je jeho účel.

A zbytečnou složitost bych viděl jako mnohem větší problém, než zbytečnou sílu jazyka - zatímco za vyjadřovací schopnost jsem rád i za cenu toho, že přečíst něco po některých lidech může chvilku trvat (případ Lispu), při zbytečné složitosti mi to čtení občas může trvat ještě déle, ale nezískám tím zhola nic (případ C++).

Jenže ta "zbytečná složitost" je právě vyjadřovací síla toho, že kompilátoru dáváte další informace pro rychlostní optimalizaci. Zatímco LISP nebyl primárně tvořen pro rychlost, a jeho syntaxe tomu odpovídá - C++ bylo od počátku tvořeno pro rychlostní maratonu a velká část vyjadřovací síly je zaměřena na možnost rychlostních optimalizací. Pokud pominete to, že do vyjadřovací síly C++ neuvažujete velmi detailní nápovědu programátora kompilátoru pro rychlostní optimalizace, pak Vám C++ bude připadat zbytečně složité a budete si myslet, že "nic tím nezískáte".

A jak se chovají jejich volné proměnné?

Z C++ LISP neuděláte Pokud tedy nenapíšete v něm LISP executor.

Myslím, že to myslí vážně. A já to vidím asi tak stejně. A někde jinde tady jsem se k tomu už vyjádřil - C++, když už ni jiného, nutí lidi učit se dva jazyky tam, kde jiným jazykům stačí jen jeden.

Pokud bych měl porovnávat dvojici C a C++, nevidím jediný důvod pro C. Pokud bych měl porovnávat C++ a něco jiného odlišného od C, pak velmi často najdu důvod, proč použít něco jiného.

[Kyosuke]

Většina komplexity v C++ není proto, že to nelze udělat jednodušeji, ale proto, že komplexita podstatně zvyšuje možnost rychlostních optimalizací. C++ je dělaný na max. rychlost a nízkou spotřebu zdrojů a tomu je podřízeno naprosto vše.

Zvláštní, že spousta tvůrců jiných programovacích jazyků to vidí přesně naopak. Totiž že čím jednodušší jazyk mám, tím snáze pro něj napíšu opravdu dobře optimalizující kompilátor, protože nemusím řešit spoustu bizarních okrajových případů a můžu rychleji řešit podstatné věci. Třeba pokud mám pouze pure funkce, můžu podle libosti eliminovat zcela jakéholi společné podvýrazy a podobně, a ne jen podmnožinu jazyka.

Z C++ LISP neuděláte Pokud tedy nenapíšete v něm LISP executor.

Nemusí se jednat zrovna o Lisp (BTW, už dekády se to píše s malými písmenky. ). Nicméně i pokud už máte anonymní first-class funkce, pořád ještě to nejsou lambda funkce, pokud neumožňují zachytit volné proměnné. Ostatně tvrdíte-li, že C++ téměř umí lambda funkce, to už můžete rovnou říkat, že Číňané z drtivé většiny dodržují lidská práva.

[Miloslav Ponkrác]

Totiž že čím jednodušší jazyk mám, tím snáze pro něj napíšu opravdu dobře optimalizující kompilátor

Jenže v praxi je to stále pomalejší, než to co leze z C++. Asi někde soudruzi akademici udělali v teorii chybu.

[Kyosuke]

Jo ještě jedna připomínka...

je to jazyk, který si vystačí sám se sebou, teoreticky v něm napíšete naprosto všechno i hodně low level a C++ nepotřebuje podporu žádného jiného jazyka.

A už umí standardní C++ něco tak triviálního, jako bitová rotace, nebo je to pořád ještě vylepšená PDP-11ka?

[Miloslav Ponkrác]

A Vy si nenapíšete v libovolném běžném jazyce funkci pro bitovou rotaci?

[MJ]

Samozřejmě napíšu, jen je to sázka do loterie: Všimne si překladač, že jsem popsal obyčejnou bitovou rotaci, a přeloží ji efektivně (tj. jako instrukci pro rotaci)? GCC obvykle ano, jak jiné překladače, vlastně nevím.

[Kyosuke]

Napíšu, ale nikdo mi nezaručí, že kompilátor pozná, že píšu birovou rotaci svépomocí a že ji přeloží do jediné strojové instrukce - která touhle dobou je prakticky všude, jen nebyla v PDP-11, což je důvod, proč to neumí ani Cčko.

[Ondrej 'SanTiago' Zajicek]

Tohle je konzistentni argumentace od cloveka, ktery tu zminoval Lisp a Scheme ;&nash;) ? Tam je takovych pripadu tuny. Namatkou treba zminene zachycovani volnych promennych. Nikdo mi nezaruci, ze kompilator pozna, ktere jsou potreba a nebude kvuli tomu drzet referenci na cely aktualni environment. Oproti tomu u klasickeho ceckoveho idiomu (ke kazdemu callbacku jeden void pointer zdarma pro data) tohle odpada.

[Kyosuke]

Asi mi něco ušlo, ale nechápu. Já se pouze pozastavil nad tím, že údajně zcela samospasitelný dokonalý jazyk C++ (samospasitelný včetně systémového programování) nepodporuje triviální operaci, která je dnes v podstatě všude v hardwaru. Přitom mi přijde, že implementovat ji by bylo snadné, ale přesto se s tím nikdo ani v moderních normách C a C++ neobtěžoval (aspoň jsem si toho nevšiml), proto třeba kompilátor SBCL (Common Lisp trpí obdobným problémem) extra poskytuje rozříšení ROTATE-BYTE, hlavně kvůli kryptografickým algoritmům a podobně - nemá cenu psát je zbytečně pomalé, když procesor tu instrukci prostě má.

Closure conversion je zajímavý problém. Udělat ji efektivně je určitě mnohem složitější, než jen přidat operátor pro jednu operaci a dopsat pár řádků do generátoru kódu. Nicméně já tuhle vlastnost jazyka považuju za vlastnost pro vyšší jazyk natolik výhodnou - a především, natolik fundamentální - že kdybych si měl vybrat mezi efektivní implementací closure conversion a přítomností či nepřítomností bitové rotace v jazyku, ve kterém budu psát 80 % kódu nebo víc, radši beru kvalitní closure conversion.

U Cčka jsem smířený s tím, že tam takové věci mít nikdy nebudu, a tak se soustředím na to, co mít můžu, a chvílemi by se rotace mohla hodit, tedy hlavně v té třídě přoblémů, pro kterou se Cčko nejvíc používá (chroustání čísel a bitů). U vyšších jazyků (než C, které je samo o sobě celkem slušně vysoko, když se to tak vezme) by mi zase vadila absence funkcí, jako jsou zcela plnohodnotné closures, protože když už rezignuju na výkon za všech okolností, chci někde aspoň ty základní fíčury. Kde přesně mám tedy tu nekonzistenci?

[Ondrej 'SanTiago' Zajicek]

Opsani bytove rotace pomoci komplikovaneho kodu a doufani, ze kompilator uhodne, ze to ma prelozit do jedne instrukce je specialnim pripadem obecneho vzoru - chci udelat neco jednoducheho a rychleho, ale presto pouziji neco hodne obecneho a obecne sloziteho, kde to jednoduche je specielnim pripadem, a doufam, ze me to nebude stat tolik (jako to obecne reseni), protoze to bude vyoptimalizovano/specielne osetreno ... .

Rekl bych, ze s timhle vzorem se mnohem casteji setkavam v jazycich jako Lisp ci Scheme, nez treba v C. A mam pocit, ze autori a uzivatele tech jazyku to snad ani nepovazuji za chybu ... . Ty closures byl jen jeden z mnoha prikladu.

[Kyosuke]

Jo, chápu, jak to myslíš. Tohle je věc, na kterou se snažím si dávat pozor, protože se mi to taky pověšinou moc nelíbí. Ale zrovna closures bych neradil do dobrých příkladů tohohle problému, to je podle mě jedna z těch několika věcí, které by kompilátor bezpodmínečně měl řešit aspoň trošku pořádně automaticky, protože volné proměnné vystrkují růžky úplně všude (úplně abstraktním beztypovým lambda kalkulem počínaje), tak si snad zaslouží nějaké obecné řešení, aspoň tedy víc, než celá řada dalších věcí. Nějak mi nepřijde, že by to byl příklad něčeho, co se řeší zbytečně a každý by si to měl psát ručně, na rozdíl třeba od specializovaných instrukcí procesoru, kde si tu práci klidně dám. Jo, možná mám divné názory, proti tomu nic namítat nebudu.

[Kyosuke]

Ale fakt by mne zajímalo, jak může soudný člověk při plném vědomí navrhnout takový humus plný konfliktů, jako je C/C++ (a další to prezentovat jako nic komplikovaného).

Ono by tky možná stačilo nahradit jenom ten parser...

[Miloslav Ponkrác]

To bych pane Kyosuke nedělal. Kdyby mělo C++ lepší parser, pak by lidé houfně přecházeli z LISPu, Scheme, Haskellu, a dalších jazyků na C++ a tyto jazyky by vlastně zanikly

[Ladicek]

Jo, na to jsem myslím už jednou narazil. Řekl bych, že by to značně pomohlo i plain C. Jenže to by se z něj stal jazyk pro pojídače koláčů, a to přece nesmíme dopustit

[trekker.dk]

spíš hrozí návyk otřesných konstrukcí, nebezpečný příkaz goto je stále po ruce

Nebezpečnost goto se IMO přeceňuje.

[MJ]

Moje řeč. Často bývají (pro srozumitelnost kódu) daleko nebezpečnější snahy obejít se bez goto za každou cenu než jedno dobře mířené goto.

[Kvakor]

Doproucuju kouknout se do zdrojaku (jadra) Linuxu, tam je spousta mist, kde je goto nejlepsim resenim. Typickym mistem jsou modularizovane ovladace zarizeni, kde se goto pouziva v iniciacni casti modulu, kde je nutne odinicializovat jen to, co uz bylo inicializovano, ve stylu pseudodu

  najdi_zarizeni, if nejalezeno goto konec

  alokuj porty, if sehlalo goto konec

  otestuj_pritomnost, if selhalo goto uvolni_porty

  namapuj pamet, if selhalo goto uvolni_porty
 
  inicializuj, if selhalo goto uvolni_pamet
  
  vytvor_zarizeni atd...

  uvolni_pamet:
    odmapuj pamet
  uvolni_porty:
    dealokuji porty
  konec:

Je pravda, ze je mozne to same udelat i bez goto, ale tohle elegantnejsi, obzvlast u veci, kde toho muze pri inicializaci spoustu selhat.

[Martin Böhm]

To jsou plus minus výjimky, nebo se pletu? (Teď zrovna neřeším, že jsme v Céčku a navíc v kernelu, takže si leckteré "výdobytky" moderní doby nemůžeme dovolit, ale přesto by se nám hodily.)

[Ondrej 'SanTiago' Zajicek]

Jak bys pouzil vyjimky, aby ten kod vypadal tak pekne prehledne, jako s takhle pouzitym goto?

[Martin Böhm]

Budu trochu podvádět, nezlob se :o)

try:
  najdi_zarizeni, if nenalezeno throw konec

  alokuj porty, if selhalo throw konec

  otestuj_pritomnost, if selhalo throw uvolni_porty

  namapuj pamet, if selhalo throw uvolni_porty
 
  inicializuj, if selhalo throw uvolni_pamet
  
  vytvor_zarizeni atd...

except:
  uvolni_pamet:
    odmapuj pamet
    continue

  uvolni_porty:
    dealokuji porty
    continue
  konec:

[trekker.dk]

continue se dá použít na něco jiného, než na skok na začátek smyčky? Mám ten pocit, že ne a že tenhle kód by se ani nepřeložil...

[Martin Böhm]

Ano, tenhle pseudokód by se skutečně nepřeložil :o) Tak trochu vysvětlivek:

Použil jsem continue jako analogii pro nutnost psát break v každé části klauzule switch v Céčku. Výjimky jsou ve většině jazyků navrženy tak, že se nečeká, že bude víc handlerů spuštěno v téže době. Naopak ve switchi se musí explicitně psát break, asi se tehdy očekávalo, že většinou se bude pokračovat dále. continue v tomhle případě tedy funguje opačně, říká "nezastavuj se, pokračuj dál".

Jestli to v některých jazycích nejde takto hezky či analogicky udělat, tak je to chyba těch jazyků, že některý use case takhle zazdí.

[trekker.dk]

Jestli to v některých jazycích nejde takto hezky či analogicky udělat, tak je to chyba těch jazyků, že některý use case takhle zazdí.

Na začátku vlákna se mluví o jádře, C/C++ a o tom, jak v něm použít výjimky, aby to bylo lepší, než goto...

[Martin Böhm]

Jakmile jsem začal mluvit o tom, že to jsou vlastně jen výjimky, tak Tě mohlo napadnout, že budu mluvit o jazyce Böhm++, čili čirá utopie. :o) Ten kód ze začatku je hezká simulace výjimek v C pomocí goto, ale to je vše.

[Ondrej 'SanTiago' Zajicek]

Nemuzu se ubranit dojmu, ze takto pouzite vyjimky nejsou nic jineho nez maskovane goto.

Kdybys v prgramu pouzival takhle vyjimky, tak bys musel zarucit, ze ty volane funkce nebudou raisovat vyjimky vnitrne (v opacnem pripade by ti takhle napsana obsluha volala spatne).

A cele to je obecne spatne, protoze to nema tu spravnou vyjimkovou semantiku :–) .

[Jirka P]

Nemuzu se ubranit dojmu, ze takto pouzite vyjimky nejsou nic jineho nez maskovane goto.

Nápodobně. Je to proto, že Martin Böhm a trekker.dk jsou prasata (viz třeba tohle nebo tohle). RAII na ně

[trekker.dk]

A ty jsi zase blbec, který nepochopil, jaký byl účel toho pseudokódu, který jsem napsal výše...

[pavlix]

Jak dědkové v hospodě :D.

[Martin Böhm]

Já jsem Čuník s velkým Č! Na svou obranu podotýkám, že když se podívám na ten svůj pseudokód jen jako na kus textu, tak ta klíčová slova přesně popisují, o co tam jde - že se něco zkouší a když to nevyjde, tak se uklidí. goto je něco jako ty vole, dokážete tím říci cokoli.

[vogo]

no když se to správně navrhne(hierarchie) tak se to dá přesně takhle udělat vyjímkama…

[trekker.dk]

Problém je v tom, že s výjimkami by to tady vypydalo nějak takhle.

try {
 najdi zařízení; if nenalezeno throw Enenalezeno;
 alokuj porty; if selhalo throw Enenalezeno;
 try {
  namapuj paměť; if selhalo throw Euvolniporty;
  try {
   inicializuj; if selhalo throw Einit;
   }
  catch Einit: { uvolni paměť; throw Euvolniporty;}
  }
 catch Euvolniporty : { dealokuj porty; throw Enenalezeno; }
 }
catch Enenalezeno

To se ve výsledku přeloží na kód, který pravděpodobně bude vypadat takhle:

...

uvolni paměť;
 goto uvolni_porty;
...
uvolni_porty:
 uvolni porty;
 goto nenalezeno;
...
nenalezeno:

Problém je v tom, že většina programátoruů v C++ a v Javě si neuvědomuje, že žádné objekty a žádné výjimky v CPU neexistují (teda co se výjimek týče, tak existují, ale jde o trochu jiné výjimky). Veškerý kód výjimek se stejně přeloží na nějaký ekvivalent goto, tedy na nepodmíněný skok.

Narozdíl od C ale v tomto případě nemá programátor žádnou kontrolu nad vygenerovaným kódem, takže z jedné výjimky musí vyhazovat jinou místo toho, aby prostě nechal program běžet stylem mám úklidový kód a skočím do něj tak, aby se uklidilo jenom to, co je potřeba uklidit.

[Kvakor]

Samozdrejme, ze ano, ale tady by musely byt do sebe vnorene, takze by to zas o moc elegannejsi nebylo.

[Martin Böhm]

Bylo by hezké, kdybys zalovil z klobouku a předvedl nám nějaký zajímavý příklad.

Hledal jsem na vlastní pěst, od včerejška mám rozečtený letitý, ale stále zajímavý Structured Programming with Goto Statements od letitého, ale stále zajímavého pana Knutha. Nicméně i on říká, že pokud by byly konstrukty, které v tom dokumentu navrhuje, přítomny v nějakém vysokoúrovňovém jazyce, asi by nikdy goto nepotřeboval.

[Kyosuke]

No vida, a přitom stačí používat jazyky, které dovolují programátorovi čistým způsobem definovat nové syntaktické konstrukce. A pak už místo nacpání konstrukce do normy jazyka stačí malá knihovna, kterou zkompiluje každá jeho kompatibilní implementace.

[Martin Böhm]

Podívejme se na tohle rýpnutí (obecně proti jazykům Kyosukeova typu nic nemám, naopak) z jiné stránky:

Myslím si, že odpůrci goto (a třeba i Knuth, i když on se k nim nehlásí) by jej nerušili proto, že by ho sami neuměli používat. Spíš by rádi jazyk, který nováčkům vštípí ty základní "správné" postupy, a sám by zabraňoval neelegantním konstrukcím. Jinými slovy, aby neelegantní konstrukce v praxi skutečně vypadaly neelegantně i na papíře, aby to člověka "trklo". Proto se bavíme o základní specifikaci jazyka. Prasárničky ať si do jazyka chrogramátor dopíše sám, třeba tak, jak navrhuješ. :o)

[Kyosuke]

Já ale nemluvil o psaní prasárniček. Já mluvím o užitečných věcech, o kterých ó-všemocný-a-vševědoucí-BDFL při tvorbě jazyka vědět nemohl.

Ovšem samozřejmě souhlasím s tím, že vyšší jazyk zrovna goto v základní specifikaci obsahovat nemusí. A pokud ho obsahuje, měl by mu aspoň místo toho říkat "tail-call", případně "kontinuace", to nejsou tak kontrovarzní názvy.

[Martin Böhm]

Ten příkládek, prosím prosím... :o) Opravdu mne zajímá, jestli jsi myslel něco konkrétního.

[pavlix]

Zajímavé, já už ten příklad (nahoře) četl.

[Martin Böhm]

Od MJe jsem doufal v něco hezky algoritmického... nebo jsem to přehlédl?

[MJ]

Aha, já v tom threadovišti vůbec nepochopil, že je to otázka na mne

Tak tedy: třeba výše popsaný kousek kernelu (nebo obecně funkce, kde je potřeba podobným způsobem uklízet), nebo když chcete implementovat konečný automat, případně je-li třeba vyskočit z několika cyklů najednou.

Jistě, ve všech třech případech se lze bez goto obejít (konec konců není těžké dokázat, že všechny cykly, goto i rekurzi lze nahradit jedním jediným while-cyklem v celém programu), ale s goto to bude výrazně přehlednější. (Teď mluvím o céčkovitých jazycích – například v Perlu je výskok přes několik úrovní vnoření elegantně řešen tím, že lze cykly pojmenovat a pak říci, ze kterého se vyskakuje.)

[Kyosuke]

A přitom by na stavový automat stačily pořídné tail cally. Osobně bych na cokoli složitějšího asi použil spíš Ragel, abych měl jistotu, že se v tom pak nezamotám, až to po sobě budu číst. Z ukázky hned na hlavní stránce toho nástroje je ovšem hned zřejmé, do čeho že se to vlastně kompiluje.

Teď mluvím o céčkovitých jazycích – například v Perlu je výskok přes několik úrovní vnoření elegantně řešen tím, že lze cykly pojmenovat a pak říci, ze kterého se vyskakuje.

Připočti si tam Common Lisp a jeho BLOCK a RETURN-FROM.

[Václav "Darm" Novák]

navíc nevím jak to bylo na zmíněném PMD 85, ale snad všechny osmibity co znám měly gosub, které se funkcím blížilo mnohem víc...

[Rezza]

Jak rika dr. PP - C++ je prase s kridly :)

[Kvakor]

Takovehle ?

[David Šmíd]

Největším problémem C++ a brzdou jeho rozvoje jsou standardní knihovny, resp. jejich nedostatek. Tady s Javou prohrává na celé čáře. STL je fajn, ale není v ní ani zdaleka všechno. Kde jsou třídy pro práci s časem, pro síťování, XML, multithreading ?

To, co by C++ potřebovalo, je zahrnutí Boost knihoven do standardu.

---

[kozzi]

JJ, XML a hlavně síťování mi chybí

[AHAHA]

Zahrnutí některých Boost šablon se plánuje pro C++0x.

[Michal Vyskočil]

Kde jsou třídy pro práci s časem, pro síťování, XML, multithreading?

No a proč asi existuje Qt? To je přibližně to, jak by měla dobrá standardní knihovna jazyka vypadat.

[springer]

6600 $ a kazdorocne jeste 15% ....

[Michal Vyskočil]

Nu já mluvil o kódu, ne o penězích

[Petr Bravenec]

Tak, správně! Od dob, kdy jsem poprvé sáhnul po Qt (konkrétně verzi 4.3), už nechci vidět nikdy žádnou jinou knihovnu. Používám to doma na všechno. Programuji s tím aplikace pro povelovou řádku i pro X11, parsuji XML, posílám signály z objektu do objektu, objekty si schovávám do kontejnerů, do databáze koukám patnácti různými způsoby a v neposlední řadě tím mažu bolavá kolena a namožená záda... S knihovnou Qt si prostě vystačím na všechno!

Nedávno jsem byl postavený před potřebu napsat v Javě jednoduchý formulář a program - zvyklý na Qt jsem v knihovně Swing mááááárně hledal přehršel užitečných formulářových udělátek, což se nakonec dalo obejít (ale té práce!), a když jsem měl půlku aplikace přenesené z C++, padnul jsem na zadek při zjištění, že formulář nemůže dědit vlastnosti po sedmi různých třídách a že bez vícenásobné dědičnosti musím postavit aplikaci úplně jinak

[David Šmíd]

Sdílím s tebou obdiv ke Qt, ale Qt se nikdy standardní knihovnou C++ nestane. Boost by se jí stát mohla.

---

[elviin]

Kdyz uz si to myslim, tak to sem napisu. Myslim, ze prvni pokus o std gui knihovnu vzejde z diskuze kolem Qt + Boost::GIL od Adobe + Cocoa.

[Miloslav Ponkrác]

Bohužel, Qt není C++ knihovna (potřebuje preprocessor), a druhá věc je, že nepoužívá možnosti C++ v jeho šíři. Tudíž jakákoli standardní knihovna, která se stane součástí normy C++ určitě se nebude podobat C++.

[Kyosuke]

Tudíž jakákoli standardní knihovna, která se stane součástí normy C++ určitě se nebude podobat C++.

To bude asi další z důvodů, proč se C++ vyhnout, že?

[Miloslav Ponkrác]

Překlep, chtěl jsem napsat:

Tudíž jakákoli standardní knihovna, která se stane součástí normy C++ určitě se nebude podobat Qt.

Jak říkal pan Holenda (se spoustou titulů před a za jménem), kterého jsme měli na lineární algebru: Pokud něco špatně píšu a něco jiného si správně myslím, pište si co si myslím.

[Michal Vyskočil]

Asi jsem málo zdůraznil, co jsem vlastně myslel. Mluvil jsem o tom, že Qt obsahuje přibližně všechno, co by slušná standardní knihovna měla mít. Od technického řešení jsem si dovolil abstrahovat, protože jednak neznám Qt a jednak neumím C++

[Messa]

Cpát všechno do standardní knihovny je blbost. Pak by se všechen ten balast musel vláčet všude s sebou. Od čeho jsou normální knihovny? Do nich věci jako síťování a XML patří a taky tam na tebe čekají. Pokud je něco součástí takového standardu, jakým je C++, je s tím akorát hodně práce při standardizování, při změnách, ... Navíc to už je napořád. Proč by sakra ve standardu jazyka mělo být něco o XML? YML bys tam nechtěl? Zrovna síťování a threading jsou součástí jiných dost vhodných standardů, jako např. POSIX.

[Miloslav Ponkrác]

Já myslím, že cpát do standardní knihovny by bylo fajn. Uvítal bych v C++ možnost síťování - čímž by bylo možné psát přenositelné síťové programy na každé (i neposixové) platformě. Navíc něco jiného je smiřovat se s low level C přístupem k POSIX funkcím, a něco jiného je mít plný C++ komfort v síťovém API, které by bylo případně součástí C++.

XML by ovšem součástí C++ být nemuselo, je to zbytečné, protože XML parser se dá napsat přenositelně.

Stejně tak bych uvítal jako součást standardní knihovnu šikovné třídy pro práci s datumem a časem včetně časových zón.

Velmi bych uvítal, kdyby součástí C++ standardu se staly třídy pro práci s regulárními výrazy.

A velmi bych uvítal ve standardní knihovně C++ podporu multithreadingu - tedy třídy pro vytváření threadů a pro základní synchronizační objekty.

[MJ]

Uvítal bych v C++ možnost síťování - čímž by bylo možné psát přenositelné síťové programy na každé (i neposixové) platformě.

Není spíš lepší implementovat POSIXové síťové funkce na těch několika málo platformách, kde ještě nejsou?

Co by takový C++ komfort obnášel? Zabalení socketů do objektů?

[...] třídy pro práci s datumem [...]

Co to vlastně je, ono datumum? Nebo ten datumus?

[Michal Vyskočil]

Je to jednoduché, pokud je něco ve standardní knihovně jazyka, programátoři se snaží používat prostředky z ní. Pokud standarní knihovna stojí za prd, schází se nám ve větších projektech X nekompatibilních implementací* téhož a dát to dohromady pak stojí zbytečně velké usilí.

* v jistém jazyce je tradicí, že starší projekty obsahují různé implementace řetězců, seznamů a všeho možného.

[alkoholik]

Tak schvalne. Kdo prohlasil
C++ is a horrible language. It ’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
;)

[disorder]

torvalds

[MJ]

A kdo: "When I invented the term Object-Oriented Programming, I didn't have exactly C++ in my mind."?

[Pavel Křivánek]

Originál je asi

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

[MJ]

Jo jo, díky za opravu, vypadl mi refresh.

[disorder]

kay

[petr]

Java velmi rychle a příjemně. Člověk se nemusí starat o paměť (to má své pro i proti)

Ano, proto některé aplikace vypadají tak, jak vypadají. Protože se nikdo o paměť nestará :'(

[alblaho]

A nakonec: kolik jazyků umíš tolikrát jsi programátorem :).

Nene, chlapče. Kolik programovacích jazyků navrhneš a implementuješ, tolikrát jsi programátorem. Takhle by to bylo příliš jednoduché

[disorder]

a pocita sa turing complete alebo staci DSL? :D

[Kyosuke]

Tyto dvě množiny jazyků mají snad prázdný průnik?

[disorder]

pokial to nebude turingovsky kompletne stylom brainfuck, tak si myslim, ze ani velmi nie ;) ono to tak trochu ide proti uzitocnosti DSL

[alblaho]

Já mám na kontě jeden dotazovací DSL, který asi turingovský není, takže ANO .

[Miloslav Ponkrác]

Kolik programovacích jazyků navrhneš a implementuješ, tolikrát jsi programátorem.

A nejlepší programátoři si nejdřív stvoří programovací jazyk, ve kterém navrhnou a implementují ty další programovací jazyky.

[MJ]

Kdepak, ti opravdu nejlepší si stvoří jazyk a implementují ho v něm samém

[happy barney]

btw, zaujímvé veci o C++ sú na Guru of the Week

[Jirka P]

Jo, ale lepší adresa je http://herbsutter.wordpress.com/

[vogo]

Takový flame pod svým blogem nepamatuju :), možná jsou všichni Unixáři interesováni na C++