Co nás čeká v C++09

DevSource píše o očekávaných novinkách ve standardu C++09, které jsou po říjnovém zasedání standardizačního výboru C++ jisté. Jedná se hlavně o reference na r-values a koncepty typů. Stranou nezůstává ani zahrnutí knihoven TR1 a spousta dalších vylepšení.

20.11.2006 17:56 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Miloslav Ponkrác]

Malé FAQ o budoucí verzi C++:

Otázka: Kolik kompilátorů bude implementovat budoucí verzi C++?

Odpověď: Vzhledem k tomu, že nová verze nepřináší v zásadě nic až tak užitečného se na to všechny kompilátory vykašlou. Některé koncepty, například rvalue budou poměrně složité na implementaci, ale nepřinesou téměř nic až tak významně užitečného pro praxi. Proto všechny kompilátory, možná s výjimkou GCC skončí na implementaci C++98. K neochotě implementovat další složitější a náročnější standard přispěje i to, že C++ přestává být strategickým a hojně používaným jazykem.

Otázka: Co významného přináší standard C++ pro programátory?

Odpověď: Kromě pár užitečných drobků nic. Standardizační komise si akorát plácala játra a její výkonnost je mizivá a divím se, že za tolik roků z nich vypadlo tak málo. Pokud by byl opravdový zájem na zlepšení C++, měla se komise inspirovat u programovacího jazyka D (www.digitalmars.com), který zlepšil C++ praktičtějším směrem. Ani nový návrh standardu stále nemá klíčové slovo finally, stále nezavádí ani základní objektové knihovny a mnohé věci je programátor stále nucen kuchtit pomocí starých neobjektových kihoven zděděných z jazyka C.

[Luboš Doležel (Doli)]

Jiné kompilátory než GCC mě moc nezajímají. Možná ještě MSVC++, ale tak nějak věřím, že se MS chytí. Machrují s podporou Boostu, tak proč by nezavedli další standard C++.

Když se podívám na Linux, tak tu žádné jiné nativní jazyky než C/C++ nevidím (assembler stranou), takže mi C++ připadá zatraceně strategické.

[Miloslav Ponkrác]

Mě jiné kompilátory zajímají velmi. Třeba pro to, že GCC mizerně optimalizuje.

Linux je postaven z 99% na C, ne na C++. Je potřeba si říci, že většina C++ projektů nevyužívá možnosti C++ z více, než takových odhadem 40%. Co jim nový standard přinese?

A já se ptám, proč nový standard C++ neodstranil největší slabiny C++? Tedy v první řadě mizernou knihovnu, která kromě datových struktur STL a pár drobností nic neřeší. Programátoři C++ prostě musí automaticky používat staré C knihovny, které v C++ zůstaly, a hojně se obracet na API operačního systému. Proč sakra neexistují přenositelné celočíselné typy jako má C99? Proč není klíčové slovo finally?

Od C++ lidi utíkají pro jeho nadměrnou složitost. Já jsem v C++ programoval (sice ne výhradně) přes deset let. Znám ho jako vlastní boty včetně různých vychytávek šablon, ale už taky váhám. Takže nový standard neodstraňuje skutečné bolístky C++, zejména přenositelnost a knihovnu, ale místo toho zavádí ještě větší složitosti, které budou lidi odrazovat ještě více a budou na houby. Ano, vychytávky typu rvalue a možnost definovat omezení do šablonových typů je věc, která opravdu vynahradí mizerný stav knihoven. Výrobci kompilátorů už teď naprosto plným právem nadávají, že standard C++ je složitý, tak ať mají po novém standardu přidáno.

Největší neštěstí každého jazyka asi je, pokud se dostane pod standardizační komisi. Pak teoretici blbnou a za mnoho let z nich nic nevypadne. A já se ptám, kde je třeba nějaká třída v základní knihovně C++ pro práci s datumem a časem? A to kde je bych tu mohl pokládat hezky dlouho. Ale to standardizační komisi opravdu netrápí. Kolik znáte jazyků umožňující OOP nemající v základní knihovně třídu pro datum a čas? Já jeden jediný a to C++.

C++ je na ústupu. Jeho hlavní přednost, to jest efektivita výsledného kódu už není tak žádaná a C++ je jednak drahé na vývoj, protože je těžké na naučení, a protože je náchylné na chyby (které jsou umocněny ještě STL knihovnou, která klíďo píďo jako standardní reakcí na nesprávné parametry má v normě nedefinovatelné zhroucení programu - opravdu skvělá a potřebná featura). Kromě toho má tak mizernou a chudou knihovnu, že se to nedá přehlédnout a to ještě více zhoršuje situaci. A oproti těm nevýhodám prostě nemá moc co postavit kromě toho, že program bude o pár procent rychlejší, což už nikoho neohromí. A komise namísto toho aby s těmito nevýhodami pohnula je ještě umocní - vrtá se v teoriích rvalue a v konceptech šablon. Přijde mi to asi jako budování Říma v době jeho konce.

Když vezmu, že komise od roku tuším 1998 žádný standard nevydala a to co jsem četl jako draft je asi vydáno na prvního apríla, tak C++ je prakticky mrtvý dinosaurus. Co nezvorala komise, dokončí čas. R.I.P.

[Miloslav Ponkrác]

Mě jiné kompilátory zajímají velmi. Třeba pro to, že GCC mizerně optimalizuje.

Linux je postaven z 99% na C, ne na C++. Je potřeba si říci, že většina C++ projektů nevyužívá možnosti C++ z více, než takových odhadem 40%. Co jim nový standard přinese?

A já se ptám, proč nový standard C++ neodstranil největší slabiny C++? Tedy v první řadě mizernou knihovnu, která kromě datových struktur STL a pár drobností nic neřeší. Programátoři C++ prostě musí automaticky používat staré C knihovny, které v C++ zůstaly, a hojně se obracet na API operačního systému. Proč sakra neexistují přenositelné celočíselné typy jako má C99? Proč není klíčové slovo finally?

Od C++ lidi utíkají pro jeho nadměrnou složitost. Já jsem v C++ programoval (sice ne výhradně) přes deset let. Znám ho jako vlastní boty včetně různých vychytávek šablon, ale už taky váhám. Takže nový standard neodstraňuje skutečné bolístky C++, zejména přenositelnost a knihovnu, ale místo toho zavádí ještě větší složitosti, které budou lidi odrazovat ještě více a budou na houby. Ano, vychytávky typu rvalue a možnost definovat omezení do šablonových typů je věc, která opravdu vynahradí mizerný stav knihoven. Výrobci kompilátorů už teď naprosto plným právem nadávají, že standard C++ je složitý, tak ať mají po novém standardu přidáno.

Největší neštěstí každého jazyka asi je, pokud se dostane pod standardizační komisi. Pak teoretici blbnou a za mnoho let z nich nic nevypadne. A já se ptám, kde je třeba nějaká třída v základní knihovně C++ pro práci s datumem a časem? A to kde je bych tu mohl pokládat hezky dlouho. Ale to standardizační komisi opravdu netrápí. Kolik znáte jazyků umožňující OOP nemající v základní knihovně třídu pro datum a čas? Já jeden jediný a to C++.

C++ je na ústupu. Jeho hlavní přednost, to jest efektivita výsledného kódu už není tak žádaná a C++ je jednak drahé na vývoj, protože je těžké na naučení, a protože je náchylné na chyby (které jsou umocněny ještě STL knihovnou, která klíďo píďo jako standardní reakcí na nesprávné parametry má v normě nedefinovatelné zhroucení programu - opravdu skvělá a potřebná featura). Kromě toho má tak mizernou a chudou knihovnu, že se to nedá přehlédnout a to ještě více zhoršuje situaci. A oproti těm nevýhodám prostě nemá moc co postavit kromě toho, že program bude o pár procent rychlejší, což už nikoho neohromí. A komise namísto toho aby s těmito nevýhodami pohnula je ještě umocní - vrtá se v teoriích rvalue a v konceptech šablon. Přijde mi to asi jako budování Říma v době jeho konce.

Když vezmu, že komise od roku tuším 1998 žádný standard nevydala a to co jsem četl jako draft je asi vydáno na prvního apríla, tak C++ je prakticky mrtvý dinosaurus. Co nezvorala komise, dokončí čas. R.I.P.

[Luboš Doležel (Doli)]

Otázkou je, co místo něj?

• Java? Ehm, ta dneska dala mému PC takový záhul, že jsem na redraw okna Kopete čekal 20 sekund (nedělám si srandu). Tu neodmítám jako programátor, ale jako soudný uživatel.
• Python? Návrhem skriptovací jazyk; nevidím v něm něco, co by začalo válcovat svět... Nevidím žádné velké projekty.
• C#? Mono je hodně pozadu. Směr vývoje tu určuje Microsoft, vývoj tedy míří směrem ku Windows - to ostatní je nezajímá. Na Linuxu bych do toho vážně nešel.
• Perl? Ten mi nepřipadá tak zlý, akorát že výsledný kód vypadá jak šifra...

Každopádně mě jako uživatele dohání k nepříčetnosti všechny ty wrapper knihovny pro interpretované jazyky. Když se podělá nativka? Revdep-rebuild. Když mi tohle udělá "skript"? Hmm, doteď mi nechodí bittorrent-curses a nikdy jsem nezjistil, co s tím je.

Nevím, jakou přenositelnost myslíte. Pokud jde o přenositelnost mezi OS, tak o jistý pokrok se snaží Boost - něco jsem zaslechl, že by to snad mělo být v budoucnu součástí standardní knihovny, ale nejsem si tím vůbec jist.

[Miloslav Ponkrác]

Java - prosím ne.

Python - skvělý jazyk, ale jeho tvůrce GvR jaksi nechápe co je to zpětná kompatibilita a rozhodl se po deseti letech udělat další verzi Pythonu (python 3) naprosto syntakticky nekompatibilní s předchozí a tím z toho jazyka udělal hračku pro děti a ne nic, v čem se dá vážně programovat - dávám další R.I.P. určitě rychlejší, než pro C++

C# - asi není třeba dál diskutovat, je to lepší inkarnace Javy

Perl - souhlasím

Náhrada za C++ není v jeho kategorii. To je jediné proč se bude používat. Já mám C++ rád, ale prostě takhle to dál nejde, musím přiznat, že komise fakt nedělá nic proto, aby ten jazyk byl lepší, spíš naopak je mi jeví jako sabotéři.

Prozkoumám ještě Ruby, počkám si na Ruby 2, která bude mít Unicode. Kdyby Python držel zpětnou kompatibilitu, je to skvělý jazyk. Zkusím Smalltalk a brousím si zuby na Adu, ten jazyk se mi stašně líbí - vypadnou z něj nativní binárky, umí plus mínus podobný rozsah věcí jako C++ s řádově nižší složitostí, bezpečný kód vysoké úrovně, mnohem lepší knihovny. Ještě můžeme mluvit třeba o Eifellu, o tom jsem slyšel moc pěkného, ale první zkoumání mě navnadilo, je to šílenost - můžete podědit třídy nejen přidáním nových vlastností, ale také ubíráním!

[Kyosuke]

Jakožto ďáblův advokát připomenu, že Ada 2005 se nachází v ISO fázi 50.20, tedy měla by být celkem za dveřmi.

[Anselm]

Nejsem zas takový odborník, proto prosím o vysvětlení, proč by měl být Python3 tak významně nekompatibilní s předešlou verzí, víc, než Ruby2 vs. Ruby1, nebo nakonec Python2 vs. Python1?

Úspěšnost jazyka je IMO přímo úměrná použitelností jeho knihoven. To je jeden z hlavních důvodů, proč se Python ujal a možná nejdůležitější důvod, proč ho Ruby začíná předhánět. Python3 je IMO důkladná revize, která snad konečně přinese do knihoven systém a vrátí Pythonu dech.

Knihovny udělaly Javu, bez nich by byl C# prostě jen další programovací jazyk, jsou důvodem, proč se stále drží FORTRAN a diskvalifikují různé akademické jazyky, které jsou sice krásně vymyšlené, ale v praxi nepřinášejí zas tolik výhod.

[Miloslav Ponkrác]

Python 3 bude naprosto a totálně nekompatibilní. Vzhledem k množství kódu v Pythonu 2 je to signál, že Python nebude chránit investice do kódu a jinak řečeno signál všem, kteří ho chtějí vážně třeba podnikově využít, že je to hračka pro děti se kterou se nevyplatí počítat

úspěšnost jazyka není dána použitelností jeho knihoven - to by totiž C++ muselo totálně propadnout už na začátku a hle ono řadu zářilo na nebi slávy. Python 3 je počin, který přinese Pythonu akorát pád, protože pošle k čertu veškerou práci v Pythonu dosud naprogramovanou. představte si, že další Windows bude nebude mít zpětnou kompatibilitu a linuxová komunita může měsíc slavit. stejně tak nekompatibilita Pythonu je hřebíček do rakve. věřte mi, že každý praktický člověk, který ví, že python je tu řadu let a pak jeho tvůrce ho syntakticky totálně změní nebude do pythonu investovat nic jiného, než pár jednoduchých skriptů. python je skvělý jazyk, ale neznám žádný programovací jazyk, kterého by nekompatiblita po mnoha letech nesrazila.

všimněte si stálic na nebi jazyků: fortran, cobol, c, c++, java, ada. žádný z těchto jazyků si nedvážil výrazněji změnit syntaxi nekompatibilním směrem a to v nich jsou konstrukce, které si to zaslouží. proto v těchto jazycích jsou psány také opravdu vážné a velké projekty. jazyk, který se mi mění pod rukama prostě nestojí za to.

[Anselm]

Já myslím že ne, nebude naprosto a totálně zničujícím katastrofálním způsobem nekompatibilní. Bude tam spoustu věcí, které nepůjdou přeportovat automaticky, ale dostaneme nástroje, které nám s tím trochu pomůžou. Na konverzi budeme mít spoustu času a nakonec, nikdo nás nebude nutit do toho jít. Mě se v Pythonu spousta věcí nelíbí už teď (lambda functions, list comprehensions, decorators...), ale stejně se mi zdá jako nejlepší (nebo nejhezčí?) ze všech špatných jazyků. Neexistuje ideální programovací jazyk, stejně jako neexistuje ideální distribuce apod. Na toto téma jsme viděli mnoho flamewarů.

Co se týče těch knihoven, stojím si na svém. C++ vniklo evolučně z C a v tom byla jeho hlavní deviza, v tomto případě to nebyly knihovny, které způsobily jeho popularitu. Pamatuju si, že v té době si ještě každý programátor psal quicksort sám (někdy i zpaměti:), takže absenci knihoven nikdo až tolik neřešil. Nebyla ještě moc vzdálená doba, kdy si každý sám psal rutinu na výpis řetězce pomocí "rep movsw" do grafické paměti Tenkrát byl C téměř monopolní jazyk na všechno a C++ vzniklo jako syntaktická šlehačka na Céčku, které bylo prostě všude, takže proto IMHO ta popularita.

[Miloslav Ponkrác]

Bude tam nejen spousta, ale obrovský kopec věcí, které nepůjdou. Na nástroje, které pomůžou nevěřím, zkušenosti z praxe mi říkají, že to přináší jen potíže a rozhodně to není bezproblémové.

Řeknu to upřímně, vy byste opravdu začal větší projekt v jazyce o kterém víte, že není schopen dodržovat ani zpětnou kompatibilitu? Že třeba budete pát let psát a pak v projektu s milióny řádků kódu ho budete muset totálně přepsat a zkontrolovat? Že si tím zavlečete nové skryté chyby do roky odladěného kódu, a že to může způsobit značné leckdy i ekonomicky vyčíslitelné chyby je nabíledni. Proto je také python "skriptovacím jazykem", a ne "programovacím jazykem".

Zkuste prostě tohle ekonomicky vysvětlit v nějaké firmě, že kvůli kratochvíli tvůrce Pythonu se musí investovat pár miliónků navíc, a že tím získáme kód, který bude třeba znovu otestovat a znovu bude stejně bugovitý díky novým možným chybám při přepisu jako na začátku. Ne, prostě investice do kódu a odladěný kód má svojí cenu.

Jedna z devíz jazyků C/C++ je jejich stálost. Normálním kompilátorem C přeložíte i velmi starý kód C, pokud dodržuje standard. I když používá zmatenou K&R syntaxi a jiné blbosti. Proto je možné dodnes mít spoustu programů, které jsou v C/C++ napsané a tyto programy budou přeložitelné i nadále, pokud je nepsalo prase a dodržovalo standard. To je věc, která hraje nesmírně obrovskou roli při rozhodování, zda v C/C++ napsat důležitý projekt, nebo ne.

Představte si co by se stalo, kdyby se přišlo na to, že unix shell, jedno jestli sh a bash je zastaralý a bez náhrady by se z Linuxu vypustil a namísto toho by se vynyslel bash 3.0, který je lepší, akorát není kompitibilní se současný sh, ani bash a samozřejmě staré verze sh a bashe se přestaly vyvíjet. Že byste donutil všechny autory na světě přepsat všechny shellovské skripty včetně těch v rpm a jiných balíčcích. Tak tohle se snaží udělat Python.

Nebo si představte co by se stalo, kdyby se gcc rozhodlo, že od teď nepřeloží standardní C/C++, ale jejich mnohem lepší variantu, kterou si vymyslí a bude nutit všechny autory programů kódy přepsat. Můžu říct, že to gcc určitě nepřežije.

Python se prostě tímto počinem značně diskvalifikoval, ať už tím myslí cokoli. Přestal být seriózním jazykem, přestal být tím jazykem, který se má brát v úvahu pro větší projekty a už vůbec toto neobhájí pro podniková a enterprise řešení. Python je skvělý jazyk, ale když je někdo blbej, tak mu nic nepomůže.

[Michal Kubeček]

Nebo si představte co by se stalo, kdyby se gcc rozhodlo, že od teď nepřeloží standardní C/C++, ale jejich mnohem lepší variantu, kterou si vymyslí a bude nutit všechny autory programů kódy přepsat. Můžu říct, že to gcc určitě nepřežije.

Ona bohatě stačí ta nevole, která se zvedla mezi programátorskými bohémy vůči čtyřkové řadě gcc…

[Miloslav Ponkrác]

Jenže mezi programátory C++ zavládla nevole kvůli kompatiblitě, a mezi programátory Pythonu při daleko větším rozorání zavládlo nadšené přizvukování. Něčemu tu asi nerozumím, ale zdá se mi, že mezi programátory Pythonu je něco špatně. Nebo je chyba ve mě, připouštím.

[Anselm]

Máš samozřejmě naprostou pravdu. Jenom je mi líto, že jsi z toho tak nešťastnej.

[Miloslav Ponkrác]

C++ vzniklo evolučně z C a Simuly. Hlavní devíza C++ byla efektivita výsledného programu za použití vysokoúrovňového jazyka, což je dodnes nepřekonáno. Absenci knihoven řešilo spousta lidí, proto třeba Qt si na tom založil podnik. Mohu osobně říci, že mít C++ pořádné knihovny, určitě by akcie firmy trolltech byly mnohem níže, než dnes.

Syntaktickou šlehačku C využilo spoustu jazyků a všechny využily popularity C. Třeba C++, Java, C#, ... V podstatě taková Java není o nic méně syntaktická šlehačka na C, než C++. Pokud tedy pomineme těch 99% věcí, co má C++ i Java proti C navíc

[Anselm]

Děkuji za poučnou lekci z historie C++ :)

Ano, devizou C++ byla také vyšší efektivita programu. Protože to bývalo C se šlehačkou (jak jsem psal).

C++ je ve srovnání s moderními jazyky velmi nízkoúrovňové. Ano, tenkrát snad mohlo někomu připadat vysokoúrovňové:)

Ano, absenci knihoven řešilo nemálo lidí. Často tím, že si napsali vlastní (jak už jsem psal).

Syntaktická šlehačka != podobná syntaxe (IMHO!) :)

Nemáš něco lepšího na práci? :)

[Jan Martinek]

Abych pravdu řekl, mě se taky ty změny plánované pro Python 3 nezdají tak dramatické. V drtivé většině případů půjde o změny v implementaci, které se programátora nedotknou. A těch zbývajících změn, které způsobí potíže se zpětnou kompatibilitou bude jen pár.
Přechod na Python 3 samozřejmě způsobí jisté potíže, ale já osobně ty změny vítám - stejně jsem nikdy neměl rád lambdu, reduce, map, apply a spol. A i ty další změny jsou spíše odstranění divných konstrukcí.
Zkrátka souhlasím se vším, co již bylo řečeno, jen IMHO volíte příliš silná slova. Nejsem prorok, ale situaci nevidím tak pesimisticky.
Kdo je konzervativní, ať si programuje v jazycích, které se nemění - a bude se trápit s jejich omezeními a zastaralostí. Kdo je radikálnější, ať se připraví na trápení se změnami a přechody. Těžko říct, co je lepší ale přístup GvR mi vyhovuje.

[Kyosuke]

„…já osobně ty změny vítám - stejně jsem nikdy neměl rád lambdu, reduce, map, apply a spol. A i ty další změny jsou spíše odstranění divných konstrukcí.“

Aneb když pythonisti začnou být sebestřednější než javisti.

[Michal Vyskočil]

Jenže z pohledu Pythonu (toho jak jsou tam implementované) jsou to skutečně podivné konstrukce. Já vím, že v jiných jazycích je to pořádně a divné nejsou

[Miloslav Ponkrác]

Tak se snad naimplementujou do Pythona pořádně, ne? Vám nepřipadá debilní, když po deseti let velmi častého používání lambdy, reduce atd.. se přijde na to, že by to mělo ven? Proč na to GvR nepřišel tehdy? Pochopím, když někdo odstraní konstrukce, které jsou tam pár měsíců, to nikoho nebolí.

Teď je prostě úplně jedno, jestli jsou v Pythonu takové, nebo makové. Jsou tam deset let, tisíce programů a knihoven to používá a tudíž prioritou je zpětná kompatibilita.

Mě to přijde asi tak, žijete se ženskou deset let, nasekáte s ní deset dětí a teď se nechcete znát k dětem, ani alimentům. A chcete jít k další ženské a divíte se, že ta Vás nechce, protože nechce dopadnout stejně, přestože jste hezký chlap a v posteli to zvládáte na jedničku. Tohle bude analogické k tomu jak se dost programátorů bude stavět k Pythonu 3000.

[Miloslav Ponkrác]

Já když čtu nové PEP - tedy standardy Pythonu, vždycky se naštvu. Javu nemám rád, ale alespoň se v Javě dělají rozhodnutí, které jazyku pomáhá. Ale Python a GvR to je banda revolučních snílků, kteří si myslím, že všichni všechno nadšeně přepíšou.

Budoucnost bude jednoduchá. Python má teď značný podíl v programech a skriptech. Oproti tomu Ruby mizivý. Po Pythonu 3000 rychle klesne procento rozšíření Pythonu, protože staré programy přestanou fungovat, spousta knihoven v Pythonu 3000 nebude a mnoho lidí si uvědomí, že nechtějí takový nekompatibilní jazyk. Mezitím Ruby dostane pořádnou podporu Unicode a rozšíří se na úkor Pythonu, protože kromě jiného bude obsahovat právě ty dobré konstrukce, které budou vyhozeny z Pythonu.

Po pár letech bude Python 3000 zkomírat a jeho místo zaujme Ruby. Ruby se sice také změní, ale jeho změny výrazně něco přinesou pro praxi a tudíž budou akceptovatelné. Zatímco Python 3000 mění syntaxi bez větších důvodů a asi by GvR hodně koktal, kdyby se ho někdo zeptal, co nabídne jako bonus a skutečnou praktickou výhodu těm, kteří podstoupí martýrium přepsání. Myslím tím skutečnou praktickou výhodu, ne jen to, že kód bude o 1% hezčí.

[Miloslav Ponkrác]

Já když čtu nové PEP - tedy standardy Pythonu, vždycky se naštvu. Javu nemám rád, ale alespoň se v Javě dělají rozhodnutí, které jazyku pomáhá. Ale Python a GvR to je banda revolučních snílků, kteří si myslí, že všichni všechno nadšeně přepíšou kdykoli kývnou prstem.

Budoucnost bude jednoduchá. Python má teď značný podíl v programech a skriptech. Oproti tomu Ruby mizivý. Po Pythonu 3000 rychle klesne procento rozšíření Pythonu, protože staré programy přestanou fungovat, spousta knihoven v Pythonu 3000 nebude a mnoho lidí si uvědomí, že nechtějí takový nekompatibilní jazyk. Mezitím Ruby dostane pořádnou podporu Unicode a rozšíří se na úkor Pythonu, protože kromě jiného bude obsahovat právě ty dobré konstrukce, které budou vyhozeny z Pythonu.

Po pár letech bude Python 3000 zkomírat a jeho místo zaujme Ruby. Ruby se sice také změní, ale jeho změny výrazně něco přinesou pro praxi a tudíž budou akceptovatelné. Zatímco Python 3000 mění syntaxi bez větších důvodů a asi by GvR hodně koktal, kdyby se ho někdo zeptal, co nabídne jako bonus a skutečnou praktickou výhodu těm, kteří podstoupí martýrium přepsání. Myslím tím skutečnou praktickou výhodu, ne jen to, že kód bude o 1% hezčí.

[Honza Jaroš]

Jenom technická - proč tak často od vás (a nejen zde, i na jiných serverech jsem si toho všiml) chodí tolik příspěvků duplicitně? Problém s připojením, s proxy, s prohlížečem...?

[Michal Kubeček]

Obvykle to způsobuje opakované kliknutí na odesílací tlačítko ještě dříve, než se stihne načíst cílový dokument.

[Honza Jaroš]

No to já vím, ale takhle soustavně? Všímám si toho už nějaký čas.

[Miloslav Ponkrác]

Zarušená mikrovlna spolu s častými chybami kódu abíčka ve stylu "neplatná relationid", nebo co to pořád píše. Mohl bych udělat reklamu svému providerovi

ping 193.179.148.60

Příkaz PING na 193.179.148.60 s délkou 32 bajtů:

Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Odpověď od 193.179.148.60: bajty=32 čas=116ms TTL=127

Statistika ping pro 193.179.148.60:
Pakety: Odeslané = 4, Přijaté = 1, Ztracené = 3 (ztráta 75%),
Přibližná doba do přijetí odezvy v milisekundách:
    Minimum = 116ms, Maximum = 116ms, Průměr = 116ms

To je ping na počítač, který je 300 metrů ode mě a sedí u providera. Tento provider neměl žádný problém nechat si podepsat smlouvu na 3 roky s pokutou za vypovězení. A asi rok to chodilo dobře. Sháním lepší připojení to dá rozum...

[Honza Jaroš]

Jo, tak to vám nezávidím.

[Miloslav Ponkrác]

Aha, takže změní se syntaxe jazyka, některé často používané konstrukce zmizí, jiné se změní, změní se kromě toho základní knihovny a Vy napíšete, že se to programátora nedotkne. Jako komik byste se asi uživil, promiňte, toto není osobní útok, ale Váš newspeak je podivný.

Jedním z důvodů, proč je třeba Java tak populární a proč se nasazuje na čím dál větší projekty přestože je pomalá (teoreticky sice ne, ale v praxi často ano), žravá, dlouho nebyla ani open source atd.. je, že tyhle kejkle se tam neprovozují. Nevím o tom, že by nikdo mezi verzemi Javy přepisoval jako idiot půlku věcí po změně verze.

Prostě věřte mi, že ne každý je kutil, a ne každý má rád, když musí neustále všechno opravovat a přepisovat. Dokonce se na to většina lidí vykašle. Mě tento přístup GvR nevyhovuje a zkuste tento přístup obhájit přes člověkem, který má na starosti dlouholetý vývoj strategického programu. Jen si prosím připravte rychlou ústupovou cestu a trénujte běh.

Pro mnoho lidí prostě setkání s Pythonem 3000 bude zamyšlením, mám svůj program přepsat do Pythonu 3000, a nebo raději do jiného jazyka, kde tyhle kejkle nebudou? Sposuta aplikací v Pythonu zanikne, protože autoři se na přepsání vybodnou. A co když za rok po přepsání do Pythonu 3000 se GvR znovu špatně vyspí a znovu zavede nekompatibilitu?

Ne, nezlobte se, ostrá slova jsou tady namístě. Na bastlení jednorázových skriptíků přístup GvR nevadí, ale na seriózní použití se tento přístup nehodí.

[Miloslav Ponkrác]

Aha, takže změní se syntaxe jazyka, některé často používané konstrukce zmizí, jiné se změní, změní se kromě toho základní knihovny a Vy napíšete, že se to programátora nedotkne. Jako komik byste se asi uživil, promiňte, toto není osobní útok, ale Váš newspeak je podivný.

Jedním z důvodů, proč je třeba Java tak populární a proč se nasazuje na čím dál větší projekty přestože je pomalá (teoreticky sice ne, ale v praxi často ano), žravá, dlouho nebyla ani open source atd.. je, že tyhle kejkle se tam neprovozují. Nevím o tom, že by nikdo mezi verzemi Javy přepisoval jako idiot půlku věcí po změně verze.

Prostě věřte mi, že ne každý je kutil, a ne každý má rád, když musí neustále všechno opravovat a přepisovat. Dokonce se na to většina lidí vykašle. Mě tento přístup GvR nevyhovuje a zkuste tento přístup obhájit přes člověkem, který má na starosti dlouholetý vývoj strategického programu. Jen si prosím připravte rychlou ústupovou cestu a trénujte běh.

Pro mnoho lidí prostě setkání s Pythonem 3000 bude zamyšlením, mám svůj program přepsat do Pythonu 3000, a nebo raději do jiného jazyka, kde tyhle kejkle nebudou? Sposuta aplikací v Pythonu zanikne, protože autoři se na přepsání vybodnou. A co když za rok po přepsání do Pythonu 3000 se GvR znovu špatně vyspí a znovu zavede nekompatibilitu?

Ne, nezlobte se, ostrá slova jsou tady namístě. Na bastlení jednorázových skriptíků přístup GvR nevadí, ale na seriózní použití se tento přístup nehodí.

[mj41]

Hmm, zpětná kompatibilita. Kroky, které dělá GvR moc nesleduji, ale myslím, že uvažuje stejně jako @larry.

U Perlu je to totiž ještě horší. Teda horší podle Vás. Již 6 let se pracuje na Perlu 6, který nebude na úrovni zdrojového kódu zpětně kompatibilní. Na úrovní modulů, ale musí být. Jednou z hlavních zbraní Perlu je totiž CPAN. Jenže zpětná kompatibilita, je to co Perlu dlouho pomáhalo, ale přestalo. Protože byl Perl zpětně kompatibilní, v důležitých věcech snad až s verzí 1, se lidé a hlavně noví zájemci, začali ohlížet po Pythonu, Ruby či Javě. Jak může být jazyk zpětně kompatibilní a moderní, když v době jeho vzniku nikdo nevěděl o např. objektech?

Také samotná zpětná kompatibilita syntaxe je k ničemu. Jazyk se musí vyvíjet. Tím se musí měnit internals (jádro, implementace) a pokud je při každém vylepšení nutné obcházet kupu věcí, nebo je dělat složitě, kvůli "zachování" kompatibility, tak je něco špatně. Nebo to špatně není, ale stejně nemůžete po někom chtít, aby podroroval funkce, které mu překážejí a brání v práci, ve jménu "zpětné kompatibility".

Nikdo vás nenutí přecházet na nové verze. Prostě musíte zhodnotit plusy a mínusy. A když vás bude dost a bude vám to za to stát, tak si udělejte fork . Jenže pokud jazyk nejde kupředu, tak uživatelů ubývá. Připadá mi to prostě jako evoluce.

[Miloslav Ponkrác]

Dám svojí verzi Perlu.

Perl vznikl jako jazyk pro zpracování textů a naáhrada sed, grep, awk. Snad ani Larry nepočítal, že se to tolik ujme, jinak by si asi dal na návrhu jazyka více záležet.

Jenže lidi v něm začali programovat a oblíbili si ho. Co teď?

Protože Larry si akorát válí šunky a je placený jen za Perl, po několika letech propadne nemoci akademiků odtržených od praxe a začne mít nápad změnit jazyk zpětně nekompatibilně. To by praktik nikdy neudělal, protože ani fortran, ani ada, ani c, ani c++, které vznikly z praktické potřeby nikdy nic takového neudělaly. Praktik by totiž staré konstrukce jazyka označil za deprecated, nechal je v jazyce a dodal lepší, nové. Akademik ale je mimo reál.

Kdysi byl jistý GvR, který byl praktik a tak vymyslel Python. Ten vymyslel lépe, než Larry Perl, protože jednak ho zamýšlel jako dobrý programovací jazyk, a jednak měl za sebou neúspěšný jazyk ABC, na kterém se poučil.

Kdysi se Ti dva sčuchli. A od té doby se návrhy změn Pythonu až nebezpečně blíží výmyslům Perlu. Nevm, jestli je spojil parrot, nebo něco jiného, GvR začíná myšlenkově opisovat od Perlu. A dostane stejně debilní nápad jako Larry. Krk bych za to dal, že nápad udělat nekompatibilní verzi opsal od Perlu 6. Odpovídá to časově i místně.

Jinak bych Vás opravil, v době vzniku Perlu existovaly objektu už léta předtím.

Tudíž jazyk se může vyvíjet i se zachováním zpětné kompatibility a ničemu to nevadí. Od toho jsou konstrukce "obsoleted" a "deprecated". Ty nejúspěšnější programovací jazyky mají jedno společné, zachovávají zpětnou kompatibilitu. Ostatní jenom živoří, a nebo se s nimi skriptují pouze malé projekty.

Takže srovnávat situaci Perl u s Pythonem nelze, protože Python se bohužel po Perlu opičí.

[Kyosuke]

Budu citovat ze specifikace:

Migration is important. The perl interpreter will assume that it is being fed Perl 5 code unless the code starts with a "class" or "module" keyword, or you specifically tell it you're running Perl 6 code in some other way, such as by:

#!/usr/bin/perl6
use v6.0;
v6;

Tohle se nepovažuje za zpětnou kompatibilitu?

[mj41]

Sliby, chyby. Za zpětnou kompatibilitu to nepovažuji, ale za slib "zpětné kompatibility" ano . Asi si budeme muset počkat. Ale pochybyji, že lze napsat nové jádro pro jazyk bez přesné specifikace, tak aby byl ze 100% zpětně kompatibilní. Ono totiž specifikací perlu 5 je jeho implementace. Testy rozhodně nepokrývají stejnou část specifikace jako existující moduly. Problém budou tuším např. rozšíření z části napsaná v Céčku. Důležité je, že hodně lidí nechce 100% z.k. na úkor jiných vlastností. Prostě je lepší být zpětně kompatibilní jen např. z 98%.

[mj41]

V oznámení 1.0 na Usenetu se také píše že je to také skriptovací jazyk pro adminy a jeho cílem je být praktický a ne krásný. Šlo taky o čas, kdyby si na tom nechal více záležet, tak se perl možná nikdy neujme. Prostě tak nějak se to stalo a nemá smysl zamýšlet se nad tím co kdyby "Billa Gatese v deseti přejelo auto".

Druhý odstavec je trochu mimo. Placený za Perl? Kdo ho platí? Perl Foundation asi ne. A pochybuji, že by jste mu zrovna vy posílal peníze přímo na účet. Nedávno psal, že Perl 6 již používá v zaměstnání, takže tak hodně od reaility odtržen není. Jinak samozřejmě Larry Perl 6 nenavrhl. Je sice "Benevolent Dictator for Life", ale to proto, že se na to hodí nejvíce. Návrh Perlu 6 byl proveden na základě požadavků uživatelů, 361 RFC dokumentů je málo?

C, fotran, C++, ... nejsou dynamické programovací jazyky. Nemusí se tak přizpůsobovat. Teoretické základy na kterých to stojí jsou již dlouho známé. Mimochodem to je právě práce akademiků. Pokud za jazykem nestojí někdo kdo tomu rozumí, tak to pak vypadá jako PHP. C a Perl mají odlišné problémy. Prostě je to jako srovnávat assembler s Céčkem.

Perl 6 má být dynamický programovací jazyk pro dalších 20 let. Prohlásít některé vlastnosti za deprecated a přidat nové rozhodně nestačí. Píše se nový virtual machine splňující požadavky nového jazyka. Pokud by byl Perl 6 zpětně kompatibilní, tak by nepřilákal tolik nových uživatelů jako Python nebo Ruby a šel by pomalu, ale jistě do kytek.

Jinak souvislost mezi Perl 6 a Pythonem 3 moc nevidím, kromě toho aprílového žertíku o "Parrotu". Parrot zatím Pythonisty nezajímá . A opičí se všichni, není na tom nic špatného.

Larry říká, že po Perlu 6 už Perl 7 asi nebude. A pokud jo, tak to bude navždy ten nejlepší programovací jazyk ve vesmíru . Kromě toho první návrh a implementace stojí vždy za prd. Základem je přece alespoň jednou to přepsat zcela od začátku . I když teď mě napadá, že u Mozilly se to asi povedlo.

[Miloslav Ponkrác]

Víte, Vy naprosto šmahem odmítáte spoustu mých vět a neznáte fakta.

První odstavec nekomentuji. Co je cílem je propaganda, důležitá je pouze skutečnost a ta bývá odlišná od cílu velmi často.

Druhý odstavec - kvantita není kvalita. Počet RFC dokumentů neurčuje nic, než množství byrokracie.

Třetí odstavec - problém Perlu i PHP je ten, že to nikdo nezamýšlel jako univerzální programovací jazyk. Perl byl pro texty, PHP začal jako soubor skriptů pro podporu webů. Časem se to zvrhlo v něco co nikdo asi nečekal. Jinak přizpůsobování jazyků není o to, zda jsou dynamické, nebo ne, ale o obyčejné slušnosti autorů jazyka vůči pracem v něm naprogramovaných.

Čtvrtý odstavec - Hitler měl taky postavit tisíciletou říši a víte jak to dopadlo. To co má být Perl mě je ukradené, důležité je co skutečně bude. Prohlásit věci za deprecated rozhodně stačí a dokud mi nepředvedete, kde to nestačí, nebudu dál diskutovat na rovině, kde nepředvedete konkrétní příklad. Zpětná kompatibilita je ale velmi silný argument pro přilákání uživatelů, viz předveďte mi jazyk, který se udržel delší dobu na poli slávy a porušil zpětnou kompatibilitu. Já žádný neznám.

To, že pythonisty parrot nezajímá je super žert. Až na to, že tvůrce Pythonu o parrotu v mnoha interview básnil a v mnoha interview se najednou tvůrce až moc bratříčkoval s perlem. Opičí se sice všichni, ale proč si vzít z perlu to nejhorší o co se snaží, tedy porušení backward compatibility nechápu. Jinak pokud čtete návrhy nových standardů pythonu, tak jen slepý by nepoznal, že autor obdivuje perl, a ne vždy si bere to dobré.

No jo, nejlepší programovací jazyk. Přepisovat od začátku můžete, ale nemusíte porušit kompatibilitu, to se nevylučuje. U Mozilly se to povedlo právě proto, že neporušila zpětnou kompatibilitu. Mozilla dokonce v prvních verzích byla podobná jako perl, rozhodla se, že nebude podporovat prasecké webové stránky a bude čistá, tedy podporovat jen standardu vyhovující stránky. Až nezájem uživatelů o prohlížeč, který až příliš stránek nedokáže zobrazit nakonec dokopal tým k tomu, že upravili Mozillu směrem ke kompatibilitě s existujícími webovými stránkami a pak teprve Mozilla začala růst. Tedy Mozilla je klasický příklad, jak zájem o ní způsobil až dodržování kompatibility.

[mj41]

Počet RFC a jejich obsah jasně ukazuje co uživatelé chtějí. Je to komunikace, ne byrokracie.

Tvrdíte tedy, že Perl je možné předělat, protože nebyl navrhnut jako univerzální, zatímco Python ne, ptože byl navrhnut jako univerzální a k tomu ještě správně, tj. není co předělávat. Do Pythonu nevidím, takže s Vámi asi můžu souhlasit. Asi tedy nelze porovnávat situaci Perlu, který vznikl hlavně pro práci s texty a dlouho se snažil o zpětnou kompatibilitu (stačí se podívat na Perl 1) s Pythonem.

U Perlu deprecated rozhodně nestačí. Je třeba předělat syntaxi. O tom jsou Synopses. Pokud opravdu bude jakžtakž fungovat:

   use v6-alpha;
   # ...some Perl 6 code...
   {
       use v5;
       # ...some Perl 5 code...
       {
           use v6-alpha;
           # ...more Perl 6 code...
       }
   }

tak to bude supr. Ale Perl 6 se ujme i když bude kompatibilní jen z 95%. Zpětná kompatibilita je opravdu opodstatněná jen někdy a rozhodně ji za hlavní vlastnost dynamického jazyka napovažuji.

To o nezájmu o Parrot, jsem mysle vážně. Nějakou dobu se snažím věci okolo Parrotu a Perlu 6 sledovat a např. tohle mi bohužel uniklo. Polepším se a budu rád když doplníte nějaké odkazy.

Pokusím se "poznat fakta" a ozvu se.

Prostě u Pythonu nevím, ale u Perlu už bylo na čase změnit syntaxi. Je chvályhodné, že se to udělá najednou a nespěchá se .

[mj41]

No, z toho rozhovoru, Parrot se mu líbí, ale nevěří že na něm Python v nejbližší době poběží. Místo Perl by si raději zvolil TCL, tak nevím proč se s ním bratříčkuje.

Jinak taky odpovídá, že pro něj zpětná kompatibilita není důležitá, ale pro komunitu, která nyní již tvoří Python ano.

Další problém, je že vylepšená syntaxe musí být jasná a její parsování rychlé. Proto nejde u Perlu dodržet zpětnou kompatibilitu. Kromě toho na nahrazení "->" tečkou u volání metod a použití sigil i pro klíče (say @pole[1];) se opravdu těším .

[Miloslav Ponkrác]

Nevím, jakou přenositelnost myslíte. Pokud jde o přenositelnost mezi OS, tak o jistý pokrok se snaží Boost - něco jsem zaslechl, že by to snad mělo být v budoucnu součástí standardní knihovny, ale nejsem si tím vůbec jist.

Na to vám odpovím jednoduše - zkuste přenositelně pracovat se soubory delšími 4 GB. Pak to začnete zjišťovat, v normě není při práci se soubory definován žádný konrétní typ, protože long nic nezaručuje, jen to, že musí být minimálně čtyřbajtový podle normy C++. Takže jak mohu přenositelně pracovat s takovými soubory, když norma mi vůbec neurčuje typ ukazatele pozice v souboru jinak, než nicneříkajícím "je to nějaký celočíselný typ, ale velikost typu je implementačně závislá"? Pak skončíte tak, že buď voláte přímo API systému, a nebo to nějak ošulíte.

Boost je skvělá knihovna, ale prostě je jako život - jsou tam příšernosti zvíci knihovny pro datum a čas, která by se měla dávat jako odstrašující příklad jak věci nedělat - a jsou tam diamanty. Jenže zase je to o tom, že všude je int a long atd.. Tudíž přenositelnost jen zdánlivá.

Proč sakra C++ něco nepostaví na konkrétním typu třeba, že pozice v souboru je int64_t? A to jsem jen na začátku potíží.

Boost jen staví na tom, co v C++ je a využívá to do mrtě, nic víc. Neopravuje chyby C++ a nedává si to snad ani za úkol.

[Michal Kubeček]

Proč sakra C++ něco nepostaví na konkrétním typu třeba, že pozice v souboru je int64_t? A to jsem jen na začátku potíží.

Technická poznámka: často se na to zapomíná, ale existenci typu int64_t striktně vzato nezaručuje ani ISO C99.

[Miloslav Ponkrác]

Nebuďte detailista, v normě by se samozřejmě využil typ s přídomkem least, nebo fast, který už zaručený je poněkud více. Jde o princip, že neurčitost typů v C++ je nesmyslná vlastnost, která přenositelnosti brání.

[Miloslav Ponkrác]

Nebuďte detailista, v normě by se samozřejmě využil typ s přídomkem least, nebo fast, který už zaručený je poněkud více. Jde o princip, že neurčitost typů v C++ je nesmyslná vlastnost, která přenositelnosti brání.

[elviin]

Musim souhlasit, ze prace s boost::date_time byla pro mne na zacatku komplikovana a bylo mi to neprijemne. Jenze pak jsem zjistil, ze vyjadrovaci schopnost je diky tomu velmi bohata, jako je tomu se vsim. Ale urcite je tam prostor pro vetsi pohodli.

Prosim, opravte me, ale boost::filesystem podporuje vetsi soubory. Nezkousel jsem to, ale nekde jsem to cetl. Alespon jako "dukaz" podavam nasledujici vlakno: lists.boost.org/Archives/..

Detaily viz funkce fs::possible_large_file_size_support()

[Miloslav Ponkrác]

boost a date time je překomplikovaná knihovna, kterou jsem několik večerů studoval a pak jsem přišel na to, že její vyjadřovací schopnost dělená poměrem zdrojového kódu je velice nízká. obyčejná třída Calendar z .NET frameworku, nebo Javy dokáže vyjádřit prakticky potřebné věci, které s boost:date_time neuděláte, pokud slovy udělat nemyslím naprogramovat rozsáhlou extenzi boost:date_time. poměr zdrojáků je přitom asi tak 1000:1 v neprospěch boostu.

boost:filesystem podporuje větší soubory. je to ale smutné, když to není v knihovně jazyka. (ironie)je alespoň hezké, že C++ umí sčítat a násobit a není potřeba na to podpora v boost knihovně(konec ironie).

[Michal Vyskočil]

To je problém všech těchto komisí. Myslím že styl vývoje ve stylu RFC - nejprve implementace, potom standardizace, je obecně daleko praktičtější. Jenže to by komisaři přišli o snadné živobytí

[mj41]

Souhlasím. U jazyků to je možná implementace + specifikace + testy. Každá implementace, které splňují testy je pak prohlášena za vyhovující specifikaci. Ostatně takhle to probíhá u Perlu 6 .