Sila paralelniho programovani v Pythonu

31.3.2008 12:16

Python v paralelnu - Parallel Python

Chtel bych zapet odu na efektivitu knihovny Parallel Python.
V souvislosti s poslednim vyzkumem na tema nejefektivnejsiho core z pohledu me aplikace, jsem se tesne pred nakupem pocitace rozhodl otestovat, jak rychle budu schopen aplikaci preprogramovat do paralelna.
Az me to zaskocilo - za zhruba 2 hodiny bylo hotovo a program funguje naprosto bez jakychkoliv obtizi i pro vice pocitacu. Rychlost implementace a efektivita opet vyhrala nad runtime rychlosti.

       

Komentáře

[Miloslav Ponkrác]

Což ale Python zase spolehlivě zabije tím, že překopává syntaxi programovacího jazyka, že nemá binární standard, takže každou knihovnu je potřeba i v případě minor verze Pythonu znovu přeložit.

Takže když napíšu v C, C++, Adě, Fortranu, a řadě dalších jazyků program přesně podle standardu jazyka, můžu si být jistý, že za desítky let ho stále přeložím i na jiné platformě na 99% beze změny jediné čárky zdrojového kódu.

Zatímco Python jsem trochu od sebe odstrčil právě proto, že je neustále překopáván a nutí člověka neustále se srovnávat se změnami dalších verzí (myslím teď hlavně knihovny), a že považuje za správné změnit nekompatibilně syntaxi (viz Python 3000), což klidně může udělat v nejbližších letech znovu třeba 20x, protože žádné záruky Python nedává. Python není seriózní jazyk z tohoto pohledu.

Pak možná v Pythonu něco rychle naprgám, ale on si Python taky může bohatě vybrat díky svému kašlání na nějakou (zpětnou) kompatibilitu.

[Fluttershy, yay!]

Není tomu tak dávno, co každý překladač C/C++ dotyčný jazyk interpretoval trošku jinak.

[Käyttäjä 11133]

Většina z nich uměla/umí ANSI C. To že někdo používal nějaké věci navíc je jeho chyba, ne?

[Fluttershy, yay!]

Moc do toho nevidím, ale co MSVS6? Tam se myslím musely dělat nějaké hacky i kvůli IO...?

A co třeba situace před 10+ lety?

[Käyttäjä 11133]

MSVS6 znamená Microsoft Visual Studio 6? Pokud ano, tak produkty od MS bych se neoháněl, ty jsou schopny špatně interpretovat i vlastní formáty, natož nějakou normu.

[Miloslav Ponkrác]

Pozor! Microsoft právě velmi ctil a ctí normy programovacích jazyků! Ač jinak máte pravdu, že MS si vymýšlí svoje vlastní ptákoviny, tak tady jste šplápnul hodně vedle. Ono je sice módní tady po MS šlapat, ale kdyby na Linuxu existovalo něco srovnatelně kvalitního jako je MSVS, bylo by fajn.

Musíte si uvědomit, že sám MS je na kvalitě vlastního kompilátoru životně závislý, a pokud v něm budou chyby, nebo nestandardy, tak nepřeloží vlastní Windows, Office a spousty dalších vlastních projektů. Takže MS kompilátor je naprosto spolehlivý - nenašel jsem v něm nikdy jedinou chybu (na rozdíl třeba od Borlandských kompilátorů), kdy by něco přeložil špatně.

[Käyttäjä 11133]

Jak říkám, děkuji za opravu.

[Let_Me_Be]

Ted nevim jestli mluvite o kompilator nebo o IDE. Jo IDE je naprosto skvele a nic takoveho v Linuxu neni. Pokud jde o kompilator, tak to je hruza. Jak GCC tak Intel C++ compiler jsou kvalitou uplne nekde jinde.

[Miloslav Ponkrác]

Asi se shodneme, že Intel C++ kompilátor je špička. To ostatně je všeobecně uznávané. Ale už se neshodneme v hodnocení gcc versus MS.

Proč? Z MS kompilátoru leze daleko optimálnější a rychlejší kód, než z GCC. Dokonce i přes deset let staré Visual Studio kvalitou generovaného kódu je na tom tak, že libovolná verze gcc ho nedokáže překonat. To za prvé.

Za druhé - MS kompilátor daleko lépe a inteligentněji hlásí chyby. Zvláště ve složitějších situacích se GCC stává, že ohlásí chyby i o několik desítek řádků jinde, než chybu skutečně máte. Kromě toho MS kompilátor v debug verzi má nacpanou do celé standardní C/C++ knihovny i do STL knihovny spousty kontrol - je tím doslova prošpikován a přijde Vám na kdeco - na memory leak, na špatné použítí zásobníku, na nekorektní použití STL (což se dá v STL, které je zticha pak řadu dní hledat), na to, že pouštíte několik threadů do místa, kde to nemáte threadově safe, nebo synchronizované a stovky dalších.

Dále jak gcc, tak MS přeloží standardní C/C++ naprosto v pohodě. Oba kompilátory jsou zdarma. Pro běžná použití není jediný důvod, proč dát na Windows přednost GCC, máte-li standardní C/C++ zdroják. Proto také většina multiflatformních projektů (třeba jako Apache) na Windows překládá přes MS kompilátor.

Ale pokud chcete i druhou stránku věci a MS kompilátor pohanět - pak MS kompilátor nepodporuje 80 bitové floating point čísla (což v 99,99% nepotřebujete).

Zkuste mi prosím napsat, proč by MS kompilátor měl být hrůza? Já totiž naopak mám pocit, že je dost povedený.

[Let_Me_Be]

Mam takovy pocit ze porovnavate GCC rady 3.x a novy MS kompilator, pak je vsechno co pisete pravda.

Ano kompilator GCC ma hodne divne chybove hlasky, na druhou stranu jsem MS kompilator nebyl schopen donutit k tomu aby provadel alespon zakladni kontroly kodu, ktere provadim pomoci gcc -ansi -pedantic -Wall -Wextra -Weffc++ (nejnovejsi verze jsem nezkousel). Jeste prisernejsi byla podpora jazyka C, kdy dokonce bez varovani zkompiloval C++ konstrukce.

Kromě toho MS kompilátor v debug verzi má nacpanou do celé standardní C/C++ knihovny i do STL knihovny spousty kontrol - je tím doslova prošpikován a přijde Vám na kdeco - na memory leak, na špatné použítí zásobníku, na nekorektní použití STL (což se dá v STL, které je zticha pak řadu dní hledat), na to, že pouštíte několik threadů do místa, kde to nemáte threadově safe, nebo synchronizované a stovky dalších.

Tohle GCC neumi, ani umet nebude, protoze na to jsou samostatne nastroje. Mozna jsou tohle nejake vychytavky posledni verze, nebo managed C++ ale nic z toho co pisete mi MS kompilator nehlidal.

Dále jak gcc, tak MS přeloží standardní C/C++ naprosto v pohodě. Oba kompilátory jsou zdarma. Pro běžná použití není jediný důvod, proč dát na Windows přednost GCC, máte-li standardní C/C++ zdroják. Proto také většina multiflatformních projektů (třeba jako Apache) na Windows překládá přes MS kompilátor.

Intel C++ kompilator je taky zdarma. Jinak napriklad Opera pouziva GCC i pod Windows.

Moje osobni zkusenost je ze prekladat primarne pomoci MS kompilatoru je nejhorsi mozne rozhodnuti. Finalni preklad je jina vec, ale i tam jsem narazil na podivne pady pri pouziti STL (i kdyz nektere verze GCC jsou na tom podobne).

[Sinuhet]

Tohle GCC neumi, ani umet nebude ...

Ale umi.

[Let_Me_Be]

Tak tohle povazuji za nutnou soucast implementace. Nemluve o tom ze concept checking je soucasti pristi verze standardu C++.

[Miloslav Ponkrác]

Ano kompilator GCC ma hodne divne chybove hlasky, na druhou stranu jsem MS kompilator nebyl schopen donutit k tomu aby provadel alespon zakladni kontroly kodu, ktere provadim pomoci gcc -ansi -pedantic -Wall -Wextra -Weffc++ (nejnovejsi verze jsem nezkousel). Jeste prisernejsi byla podpora jazyka C, kdy dokonce bez varovani zkompiloval C++ konstrukce.

Já tedy raději snesu kompilátor, který primárně najde závažné chyby v mém kódu a až na druhém místě mě bude oznamovat soulad se standardem. Já osobně nepotřebuji hlášky o souladu se standardem - za cca 10 let praxe v C a o trochu víc poté v C++ už z hlavy vím, jak psát, aby to bylo "ISO C++ compliant". Ale když si začnu hrát se šablonami trochu víc - pak gcc je žalostné s hlášením chyb. To je víc o luštění šifer lezoucích z gcc. A jak říkám, ohlásit chybu na jiném řádku je u složitějších věcí pro gcc běžná praxe - MS to nedělá.

Tohle GCC neumi, ani umet nebude, protoze na to jsou samostatne nastroje. Mozna jsou tohle nejake vychytavky posledni verze, nebo managed C++ ale nic z toho co pisete mi MS kompilator nehlidal.

Jenže samostatné nástroje prostě jsou _jenom_ samostatné nástroje. Nemohou zastoupit situaci, kdy sama runtime knihovna C/C++ hlídá každou maličkost, kdy kompilátor generuje do strojáku kontrolní sekvence včetně testů všeho možného a nemůže už vůbec zastoupit kontrolu na takové úrovni, jaká je v STL v MS kompilátoru. Protože většina z toho je z pohledu samostatných nástrojů zcela v pořádku a žádnou chybu prostě nezjistí, protože nemají jak. A tyto kontroly jsou v MS kompilátorech odjakživa.

Intel C++ kompilator je taky zdarma.

Prosím tedy o odkaz na Intel C++ kompilátor pro Windows zdarma. Předem děkuji.

Jinak napriklad Opera pouziva GCC i pod Windows.

A co z toho vyplývá?

Moje osobni zkusenost je ze prekladat primarne pomoci MS kompilatoru je nejhorsi mozne rozhodnuti.

Řiďte se Vaším osobním rozhodnutím. Já mám své zkušenosti přesně opačné. Ale tady bychom měli diskutovat objektivně - a já se ptal, proč je MS špatný - a žádný konrétní argument jsem tu nedostal - jenom emoce.

Finalni preklad je jina vec, ale i tam jsem narazil na podivne pady pri pouziti STL (i kdyz nektere verze GCC jsou na tom podobne).

Zvláštní, já jsem zatím vždy narazil na pády pouze z důvodu chyby v aplikaci - přesněji v mých zdrojácích. Mimochodem, když už jste to nakousnul, tak v GCC není v STL unicode verze stringů a streamů, ač to má každý normě vyhovující C++ kompilátor obsahovat. Takže třeba std::wstring prostě smolenka s gcc. Ano vím, podle návodu si můžete nějak zařídit - snad zkompilovat svojí vlastní STL, ale mě se to nikdy nepovedlo, asi něco dělám špatně. Ale tyhle problémy jsem s MS kompilátorem nikdy neměl.

[Let_Me_Be]

Já tedy raději snesu kompilátor, který primárně najde závažné chyby v mém kódu a až na druhém místě mě bude oznamovat soulad se standardem. Já osobně nepotřebuji hlášky o souladu se standardem - za cca 10 let praxe v C a o trochu víc poté v C++ už z hlavy vím, jak psát, aby to bylo "ISO C++ compliant".

No to je hezke a pak to neprelozim na dalsi verzi kompilatoru ani na vedlejsim pocitaci, nemluve o jine architekture. Btw. ty prepinace zapinaji slabou (na splint to nema) verzi static checkeru.

Ale když si začnu hrát se šablonami trochu víc - pak gcc je žalostné s hlášením chyb. To je víc o luštění šifer lezoucích z gcc. A jak říkám, ohlásit chybu na jiném řádku je u složitějších věcí pro gcc běžná praxe - MS to nedělá.

Pravda, ale problem mi to opravdu nedela. Clovek jenom musi vedet kam koukat.

Jenže samostatné nástroje prostě jsou _jenom_ samostatné nástroje. Nemohou zastoupit situaci, kdy sama runtime knihovna C/C++ hlídá každou maličkost, kdy kompilátor generuje do strojáku kontrolní sekvence včetně testů všeho možného a nemůže už vůbec zastoupit kontrolu na takové úrovni, jaká je v STL v MS kompilátoru. Protože většina z toho je z pohledu samostatných nástrojů zcela v pořádku a žádnou chybu prostě nezjistí, protože nemají jak. A tyto kontroly jsou v MS kompilátorech odjakživa.

Muzete hodit nejaky link co presne to hlida? Docela by mne to zajimalo.

Prosím tedy o odkaz na Intel C++ kompilátor pro Windows zdarma. Předem děkuji.

http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm

Zvláštní, já jsem zatím vždy narazil na pády pouze z důvodu chyby v aplikaci - přesněji v mých zdrojácích. Mimochodem, když už jste to nakousnul, tak v GCC není v STL unicode verze stringů a streamů, ač to má každý normě vyhovující C++ kompilátor obsahovat. Takže třeba std::wstring prostě smolenka s gcc. Ano vím, podle návodu si můžete nějak zařídit - snad zkompilovat svojí vlastní STL, ale mě se to nikdy nepovedlo, asi něco dělám špatně. Ale tyhle problémy jsem s MS kompilátorem nikdy neměl.

No, docela bych chtel videt nakolik ovladate standard. Treba takove nevinne std::vector<int> x; x[0] = 10; nemusi vubec fungovat. Nevim co vam na wstring nefunguje, ale tenhle kod prelozim naprosto bez problemu a naprosto bez problemu take bezi.

#include <iostream>
#include <locale>
#include <string>
using namespace std;

int main()
{
        locale::global(locale("cs_CZ.UTF-8"));
        wcout.imbue(locale());
        wstring s = L"Ťuťu, ňuňu.";

        wcout << s << endl;
}

[Miloslav Ponkrác]

No to je hezke a pak to neprelozim na dalsi verzi kompilatoru ani na vedlejsim pocitaci, nemluve o jine architekture.

Na další verzi kompilátoru to přeložíte pokaždé, pokud jde o slušný kompilátor. A hlavně programátor musí vědět co používá, ne kompilátor. Kompilátor je od toho, aby přeložil a chytal chyby. Varování o nesouladu se standardem je hezká věc, ale podružná.

Pravda, ale problem mi to opravdu nedela. Clovek jenom musi vedet kam koukat.

Pak jste lepší, než nejlepší machři v C++. Protože těm to problém dělá.

Prosím tedy o odkaz na Intel C++ kompilátor pro Windows zdarma. Předem děkuji.

Děkuji za odkaz, nicméně chápete, že slovo "for Linux" není kompilátor pro Windows?

No, docela bych chtel videt nakolik ovladate standard. Treba takove nevinne std::vector<int> x; x[0] = 10; nemusi vubec fungovat.

To já dobře vím, že tohle není ok. Ale když to použijete v gcc, tak gcc ani nepípne - maximálně se Vám může program složit. A hledej šmudlo. Když tohle pustíte v MS kompilátoru, máte okamžitě vyskočenou chybovou hlášku s přesným popisem, že tohle tedy ne včetně jména proměnné, řádku a daších detailních informací, kde jste tuhle věc napsal.

Nevim co vam na wstring nefunguje,

Cituji: As far as I know some gcc ports do not support wide characters and strings. This is a _major_ deficiency and I hope somebody is working on that.

Prostě ono je hezké, že tu máváte o tom, že gcc hlásí, že zdroják není v souladu se stnadardem, ale ono by bylo možná lepší, kdyby gcc ten standard na všech platformách alespoň ovládalo. Už to by byl pokrok.

[Let_Me_Be]

Na další verzi kompilátoru to přeložíte pokaždé, pokud jde o slušný kompilátor. A hlavně programátor musí vědět co používá, ne kompilátor. Kompilátor je od toho, aby přeložil a chytal chyby. Varování o nesouladu se standardem je hezká věc, ale podružná.

Jestli mi chcete tvrdit ze microsofti extenze prelozim ve vsech verzich MS kompilatoru bez uprav, tak fakt chci videt dukaz.

Pak jste lepší, než nejlepší machři v C++. Protože těm to problém dělá.

Jediny rozdil ve vypisu je ten ze GCC na kazdem miste, kde se odkazuje na sablonu vypisuje jeji kompletni instanci. Duvod je jednoduchy, kdyz to chci zkratit, tak si to proste vyfiltruju (coz za mne udela IDE - napriklad Kdevelop), jinak dostanu kompletni informace.

Děkuji za odkaz, nicméně chápete, že slovo "for Linux" není kompilátor pro Windows?

Nejak mne nenapadlo ze je to jenom pro Linux, takze jsem to dal nezkoumal. V tom pripade sorry.

Prostě ono je hezké, že tu máváte o tom, že gcc hlásí, že zdroják není v souladu se stnadardem, ale ono by bylo možná lepší, kdyby gcc ten standard na všech platformách alespoň ovládalo. Už to by byl pokrok.

No, za prve, Windows neni podporovana platforma GCC. Program se prelozi, ale nic nevypisuje, az budu mit chvilku cas, tak se mrknu jestli to je spatne natavenym locale, nebo proc to konkretne nefunguje.

To já dobře vím, že tohle není ok. Ale když to použijete v gcc, tak gcc ani nepípne - maximálně se Vám může program složit. A hledej šmudlo. Když tohle pustíte v MS kompilátoru, máte okamžitě vyskočenou chybovou hlášku s přesným popisem, že tohle tedy ne včetně jména proměnné, řádku a daších detailních informací, kde jste tuhle věc napsal.

Pri prekladu nevypise vubec nic. Jenom pri behu sleti na asserci. Jestli tohle je ta slibovana kontrola kodu, tak to jsem rad za GCC + externi nastroje, protoze ty funguji mnohem lip.

[Miloslav Ponkrác]

Já vzhledem k nedostatku času reaguji na tento thread naposledy.

Jestli mi chcete tvrdit ze microsofti extenze prelozim ve vsech verzich MS kompilatoru bez uprav, tak fakt chci videt dukaz.

Dokažte opak.

Jediny rozdil ve vypisu je ten ze GCC na kazdem miste, kde se odkazuje na sablonu vypisuje jeji kompletni instanci. Duvod je jednoduchy, kdyz to chci zkratit, tak si to proste vyfiltruju (coz za mne udela IDE - napriklad Kdevelop), jinak dostanu kompletni informace.

Jediný rozdíl je v tom, že nevíte co píšete a asi jste nic složitějšího neladil. Ale gcc forever za každou cenu musí být podle Vás nejlepší, i kdyby bylo nejhorší.

No, za prve, Windows neni podporovana platforma GCC. Program se prelozi, ale nic nevypisuje, az budu mit chvilku cas, tak se mrknu jestli to je spatne natavenym locale, nebo proc to konkretne nefunguje.

Zvláštní, máte na to důkazy? Nezlobte se, ale evidentně si neověřujete fakta ani v základním levelu - a nevážíte slova, která pronášíte (viz Váš odkaz na Intel kompilátor pro Windows), takže já Vám implicitně bez důkazů nevěřím. Navíc velmi pochybuji, že GCC nějak zvlášť bude vynechávat Windows.

Pri prekladu nevypise vubec nic. Jenom pri behu sleti na asserci. Jestli tohle je ta slibovana kontrola kodu, tak to jsem rad za GCC + externi nastroje, protoze ty funguji mnohem lip.

Tak jo, hýčkejte si dál svůj sen o Vašich dokonalých nástrojích a já se budu držet svého.

[Let_Me_Be]

Jediný rozdíl je v tom, že nevíte co píšete a asi jste nic složitějšího neladil. Ale gcc forever za každou cenu musí být podle Vás nejlepší, i kdyby bylo nejhorší.

Nejak vam dochazeji argumenty. Jelikoz se zabyvam metaprogramovanim tak si dovolim tvrdit, ze jsem prekladal i hodne slozite zalezitosti. MS kompilator mi vypise identickou chybu co GCC s tim ze instance sablon vysekne pred samotny vypis a nevypisuje instanciated from, coz GCC defaultne dela. To je cely rozdil.

Zvláštní, máte na to důkazy? Nezlobte se, ale evidentně si neověřujete fakta ani v základním levelu - a nevážíte slova, která pronášíte (viz Váš odkaz na Intel kompilátor pro Windows), takže já Vám implicitně bez důkazů nevěřím.

Jaky dukaz? Vzal jsem port kompilatoru gcc pro Windows, a prelozil ten priklad, ktery uvadim nahore. Preklad probehl bez problemu, ale jak uz jsem napsal nic se nevypsalo. Az budu mit cas, prozkoumam proc.

Navíc velmi pochybuji, že GCC nějak zvlášť bude vynechávat Windows.

GCC je vyvijeno pro posixove systemy (coz standardne Windows neni).

Tak jo, hýčkejte si dál svůj sen o Vašich dokonalých nástrojích a já se budu držet svého.

Klidne se ho drzte, jenom priste nesirte bludy.

[Miloslav Ponkrác]

Nejak vam dochazeji argumenty.

Ano, protože rád se bavím nad konrétními argumenty a Ty z Vaší strany nejsou.

Jelikoz se zabyvam metaprogramovanim tak si dovolim tvrdit, ze jsem prekladal i hodne slozite zalezitosti. MS kompilator mi vypise identickou chybu co GCC s tim ze instance sablon vysekne pred samotny vypis a nevypisuje instanciated from, coz GCC defaultne dela. To je cely rozdil.

Znovu říkám, překonal jste nejlepší světové odborníky na C++. Ti vidí zcela rozdílné věci, než Vy - takže prostě jste dobrej.

GCC je vyvijeno pro posixove systemy (coz standardne Windows neni).

Zvláštní, že gcc nic takového netvrdí. Ba právě naopak - když si čtete jeho interní materiály o interních kódovacích pravidlech (měl jsem kdysi zájem gcc vypomoci), tak jsou závislí pouze na C a jeho standardní knihovně - a to jejich podmínka je standardní C89 kompilátor.

Klidne se ho drzte, jenom priste nesirte bludy.

Já jsem tuto část debaty prostě ukončil, protože z Vaší strany nepadl jediný konkrétní argument, například příklad, kdy Vaše dokonalé nástroje jsou účinnější, takže nemá smysl debatovat o emocionálním a citovém vztahu, které máte k tomu kterému kompilátoru. Já raději fakta.

[Let_Me_Be]

Znovu říkám, překonal jste nejlepší světové odborníky na C++. Ti vidí zcela rozdílné věci, než Vy - takže prostě jste dobrej.

Neco konkretniho by nebylo?

Zvláštní, že gcc nic takového netvrdí. Ba právě naopak - když si čtete jeho interní materiály o interních kódovacích pravidlech (měl jsem kdysi zájem gcc vypomoci), tak jsou závislí pouze na C a jeho standardní knihovně - a to jejich podmínka je standardní C89 kompilátor.

http://gcc.gnu.org/install/prerequisites.html

Já jsem tuto část debaty prostě ukončil, protože z Vaší strany nepadl jediný konkrétní argument, například příklad, kdy Vaše dokonalé nástroje jsou účinnější, takže nemá smysl debatovat o emocionálním a citovém vztahu, které máte k tomu kterému kompilátoru. Já raději fakta.

Jasne, jako treba ze gcc neumi wstring, ze?

[Karel]

Jak je to dlouho, co kdosi z OO.org chtel financni podporu pro nakup MSVC? Pac ze kdyz se to sjede gcc, tak se to nehne?

[...............23]

Mne sa zdá že ešte niekedy v dobe MSVC 6 bol problém s tým že pri kóde:

for (int i=0; i<whatever; i++) {
}

for (int i=0; i<whatever; i++) {
}

to pri tom druhom cykle vyhodilo že premenná i už je deklarovaná, a bez toho int pred ňou to šlo. V neskorších verziách je to ok, ale neviem či MS vydali aj nejaký fix pre 6.

[Miloslav Ponkrác]

To je ale naprosto v pořádku, protože C++ tehdy nemělo ještě normu a nikdo nevěděl, jak se má C++ vlastně chovat. A z pohledu C je kód nesmyslný.

Nemůžete posuzovat MSVC6 z hlediska C++, protože norma C++ vznikla později. To je stejné jako kdyby někdo mával gcc z té doby - taky bude mít s dnešním C++ problémy.

Takže žádný skutečný problém nebyl - pravý stav věcí v budoucí normě C++ šlo zjistit pouze pomocí křišťálové koule, a nebo věštění z jater. A jak je vidět, jak gcc, tak msvc6 nevyvěštili na 100% a zcela se netrefili do _budoucího_ C++ standardu.

[Miloslav Ponkrác]

Pomocí MSVS6 bez problémů přeložíte ANSI zdoják Céčka. Mnokokrát odzkoušeno. Ohledně C++ v něm přeložíte většinu, ale nemá zcela dotáhnutou STL knihovnu, protože tento kompilátor byl vyvinut v době před konečnou verzí standardu C++. A nezazlíval bych mu, že nemají v MS křišťálovou kouli.

[Käyttäjä 11133]

Jsem rád, že si uvedl na prvavou míru toto tvrzení. Já bohužel (naštěstí) s žádným Microsovtím IDE, ani kompilátorem nikdy neměl tu čest.

[Miloslav Ponkrác]

Ale už DESET LET C++ má svojí ISO normu a dává záruky neomezeně do _BUDOUCNA_, že C++ program napsaný podle standardu nebudete mít problém přeložit ani za dvacet let a lze se na 100% spolehnout. A C++ k této situaci mířil.

Ale Python se o tuto situaci ani jednak nesnaží a jednak Python jako jazyk 17 let starý stále překopává syntaxi svého jazyka dodnes. Vám to přijde jako znak seriózního jazyka, kterému byste svěřili větší projekt s dlouhodobým výhledem? To jako kromě problémů s projektem chcete ještě přibrat problémy s neustálým překopáváním samotného Pythonu, se zanášením skrytých chyb, které proměnlivý Python do projektů nutně bude vnášet?

C++ po 17 letech od první verze už měl vydnaou ISO normu a jazyk byl stabilizovaný. A je jasné, že k ISO normě to nedotáhnete hned, ale že je to až několikaletý proces.

A dnes, když se projednává další verze C++ (zcela zpětně kompatibilní s přědchozí jak je u seriózních jazyků zvykem), tak i proces standardizace napovídá leccos o serióznosti - rozhoduje komise lidí, nikoli tvůrce jazyka sám. A na Stroustrupovi - tvůrci C++ je vidět, že ho víc zajímá rozvoj jazyka, než jeho osobní záměry. Zatímco o Pythonu rozhoduje jeho autor sám, normu to nemá, sám autor překopává syntaxi jak se mu zlíbí - a když se špatně vyspí, tak v příští verzi nebude fungoval žádný Python zdroják. Ač trochu přeháním, tak Python nejenže nedává žádné záruky do budoucna, on svými činy také tvrdě ukazuje, že mu na investicích vývojářů do Pythonu nezáleží a že na ně kašle, a že překopání skutečně probíhá. Proto také není Python seriózní programovací jazyk, ale toliko skriptovací.

[Fluttershy, yay!]

A Java je také špatná? Nemýlím-li se, kolem verze 1.2, nebo 1.3 proběhla celá řada zásadních změn.

Až jednou bude C++ mimo, zapomene se na něj. PHP, Ruby, či Python se vyvíjí, ač to často způsobuje zpětnou nekompatibilitu (vždy ale lze v produkčním prostředí ponechat starší verzi). A spoustě lidí se to evidentně libí, nebo jim alespoň nevadí.

[Käyttäjä 11133]

(vždy ale lze v produkčním prostředí ponechat starší verzi)

Tím bych si u uzavřeného SW nebyl tak jist.

[Fluttershy, yay!]

Proč by nemělo jít do produktu zabudovat Python 2.5 a dále vyvíjet na jeho bázi? Licence Pythonu to umožňuje.

[Käyttäjä 11133]

Mluvil si o Javě.

[Fluttershy, yay!]

Java je teď docela dost OSS.

[Miloslav Ponkrác]

Ono ot jde, ale samotný Python je k ničemu. Jednak - objeví-li se chyba v jádře Pythonu 2.5, tak se Vám na to každý vykašle, aby to opravil, když bude aktuální verze o deset releasů dopředu. A knihovny, které se bohužel musí s každou novou verzí Pythonu opět doladit, dopřepsat a přeložit pro konkrétní verzi Pythonu - ty Vám taky většina lidí nebude podporovat x verzí dozadu.

Takže byste skončil nakonec tak, že kromě časových a finančních nákladů na vývojáře a na vývoj byste se ještě stal vývojářem a musel věnovat čas a prostředky na udržování Vaší zastaralé verze Python enginu a řady knihoven, které používáte.

Takže právně a licenčně to jde, ale prakticky by do toho asi hned tak nikdo nešel.

[Fluttershy, yay!]

Ale zdá se, že se používání Pythonu celé řadě vývojářů vyplatí.

[Miloslav Ponkrác]

Samozřejmě, že vyplatí - to je otázkou priorit. Pokud potřebuji něco rychle jednorázově udělat - třeba přeparsovat data do tvaru abych je hodil do databáze a udělám to jednou dvakrát a pak program zahodím, tak mě ani moc netrápí nějaká zpětná nekompatibilita Pythonu.

Stejně tak na webové aplikace, které mají plus mínus krátký život - a kde stejně za mě většinu udělá framework, který nevyvíjím, tak je úplně jedno, jestli se pachtím s Pythonem, Ruby, PHP - protože všechno se to nějakou seriózností moc nezabývá. Například poslední verze Ruby nedokáže rozjet ani Ruby on Rails, protože nekompatiblita je tak velká, že to zkrátka nejde.

Podle mě je tohle stejně všechno trend poslední doby - dostávají se nahoru jazyka, které se rychle naučíte bez ohledu na to, co za to později zaplatíte. Ono to taky lidi za pár let přestane bavit a zpětná kompatibilita začne mít u lidí větší váhu. A jisté signály dostávají vývojáři už teď. Například PHP 5 je na světě už nekolik let a stále se mu nedaří vymýtit používání PHP 4, protože přes docela malou nekompatibilitu (která je mnohonásobně menší, než třeba mezi Pythonem 2 a 3) se prostě vývojářům nechce předělávat co funguje a funguje spolehlivě.

A pokud mě dobře zaplatíte, budu Vám programovat i v jazyce, který bych osobně pro své účely nepoužil - proč ne?

[Fluttershy, yay!]

A co třeba Python u NASA?

[Miloslav Ponkrác]

Nemám informace - ale rád se dozvím něco nového.

[Fluttershy, yay!]

Tady.

[Miloslav Ponkrác]

Až jednou bude C++ mimo, zapomene se na něj.

Já se obávám, že to nebude možné. C++ je nejefektivnější kompilovaný jazyk zaměřený na max. rychlost. Nenajdete málo projektů, který by ztrátou C++ neutrpěl. Například Java nemůže bez C++ vůbec existovat - Javovská virtuální mašina je 3 milióny řádků v C++ jazyce. Většina Windows je psána v C++. OpenOffice se bez C++ neobejde. Mozilla Firefox a Thunderbird je v C++. Symbian je v C++. A tisíce klíčových projektů, které nejde škrtnout, nebo přepsat.

Ono třeba Python nahradíte jiným podobně schopným jazykem. Ruby, PHP, též. Ve své kategorii je spousta konkurentů, které mají podobné vlastnosti. Je tu sice problém, že je v tom psáno sousta projektů, ale nové projekty můžete psát v jiném jazyce a staré umřou.

Ale čím nahradíte C++? Nemáte za něj náhradu, prostě není. Jediné co se dá použít je Céčko, ale efektivita vývoje zvláště větších projektů je v C žalostná oproti C++. Větší pracnost, více řádek kódu, více vývojářů, větší chybovost, mnohem více času a nákladů oproti C++ - a nic programováním v C nezískáte - ani rychlejší program, prostě nic.

K C++ opravdu neexistuje adekvátní náhrada. Nemáte žádný jazyk, který by ho nahradil v jeho vlastnostech. Pokud jde o efektivitu a rychlost výsledného programu, a zároveň o rychlý vývoj - je C++ absolutním králem bez protivníka a konkurenta. To nepíšu z fandovství k C++, ale tak to prostě je.

Nebojím se tedy, že C++ zmizí v dohledné době. Rozhodně v době, kdy skončí Python, Ruby, PHP bude C++ stále v plné síle. Jediné je, že se C++ používá na méně projektů, protože už rychlost není tolik priporitou, ale tam kde je prostě bude i do budoucna. Nemá náhradu.

Ohledně "vývoje" - jazyk, který za 17 let (mluvím o Pythonu) se nedokázal stabilizovat ani v základní syntaxi - to není vývoj, to je diletantnství. To je můj osobní názor. A že se to někomu líbí? Až budete někdy udržovat projekt o miliónech řádků, kde záleží na spolehlivosti a udržovatelnosti - nebude se Vám to líbit, to mi věřte. Nebo Vám by se líbilo, kdyby někdo překopával syntaxi bashe a všichni admini by neustále přepisovali své skripty například?

[Fluttershy, yay!]

Co třeba D? Já mu do budoucna věřím.

[Miloslav Ponkrác]

Bez podpory se neprosadí a tu nemá. A taky nemá to co má C++ - ISO standard, záruky do budoucna, širokou podporu mnoha výrobců překladačů.

Ač jsem sám D studoval a upřímně, hodně věcí se mi tam líbilo a samotný jazyk D by tu sílu měl nahradit jazyk C++, přesto mu chybí ty serióznosti dotáhnuté do konce - tedy norma, záruky, podpora.

Jinak C++ má taky vynikající kompatiblitu s Céčkovými zdrojáky i binárkami, což je jeho další devíza - nevím jak je to u D.

Ale proč jsem D nezačal používat já osobně - nemá vícenásobnou dědičnost a makra. Hlavně to první je hodně užitečná věc, kterou autor C++ přenesl ze Simuly, když jí de facto bral jako vzor objektů v C++.

Ale pokud by se na D zapracovalo, souhlasím, je to opravdu vážný adept na nahrazení C++.

[Miloslav Ponkrác]

Mimochodem, víte, že lidi se ohledně jazyka D nedokázali shodnout ani na základní knihovně? Právě, že autor jazyka D vymyslel svojí verzi základní knihovny pro jazyk D, která se ale spoeustě lidem nelíbí a tak se vyvinula druhá - přes API nekompatibilní verze standardní knihovny jazyka D. A oba proudy hájí svojí pravdu.

A teď ve které z nich máte programovat? A pokud to nemá ani de jure, ani de facto normu, tak se není o co opřít.

Podobná situace byla (a nevím jestli ještě je) třeba okola jazyka Eiffel.

[andro]

Mohl by jsi prosim uvest, jak se zmenila syntaxe pythonu za rekneme poslednich 5 let??? Mozna jsem na neco zapomel, ale o nejake pronikave zmene nevim a treba mi to otevre oci. Diky.
C++ je fajn, ale mam s nim ten problem, ze mi hrozne dlouho vzdycky trva neco v nem vytvorit za rozumnou dobu. Obycejne je rychlejsi/levnejsi to udelat jakkoliv jinak a kdyz je to pomaly, tak prikoupit hardware.

[Miloslav Ponkrác]

Vydání Pythonu 3000 nedávno není změna syntaxe? A že Python několik let VEŘEJNĚ DEKLAROVAL, že syntaxi změní Vám přijde málo?

To, že neumíte rychle psát v C++ je otázka tréninku. Nikdo Vás do C++ nenutí, je tu spousta jiných jazyků, které jsou seriózní, mají nějakou de jure, nebo de facto normu, kterou vážně hodlají dodržovat - a realisticky ctí a chrání investice do vývoje v tom jazyku. Je jich obrovské množství, nejenom C++ - porozhlédněte si a vyberte si.

Nejde o rychlost, jde o to, aby Vám to taky za čas vůbec fungovalo.

[andro]

Python3000 je jina vec - to je budoucnost, respektive zatim alfa verze. V minulosti tedy zadna zmena v syntaxi neprobehla? Pak ovsem musim brat s rezervou i tvoje ostatni tvrzeni.
Python 2.6 ma byt po vydani prodporovan minimalne dalsich 5 let a obavam se, ze ode dneska za 5 let bych uz rad s programovanim nemel nic spolecneho. Tudiz co bude "za cas" je mi jedno - treba nejaky muj program nejaky mladik v budocnu preprogramuje do C++ ( [ ) aby to fungovalo na veky.
V C++ budu umet psat rychle a zbesile, pokud v nem budu delat kazdy den. Ale ja potrebuji neco naprogramovovat jen obcas a prijde mi zbytecny se diky tomu vzdy znovu ucit jazyk, protoze jsem v mezidobi zase vsechno zapomel.
Kady den vidim, v cem a jak se programuje, co z toho vznika a s jakymi porodnimi bolestmi. Bohuzel neznam zadny jazyk, ve kterem by bylo jednoduche a zabavne programovat a zaroven by byl "dostatecne" normovany.
A vazne: prekladac/interpreter mi nikdo nevezme, i kdyby se stalo s jazykem cokoliv, muzu vzdy zustat u stare verze. Konkretne python je momentalne stabilni ve 2.3, 2.4, 2.5

[podlesh]

obavam se, ze ode dneska za 5 let bych uz rad s programovanim nemel nic spolecneho ... Ale ja potrebuji neco naprogramovovat jen obcas a prijde mi zbytecny se diky tomu vzdy znovu ucit jazyk, protoze jsem v mezidobi zase vsechno zapomel.

Já myslím že není o čem diskutovat - evidentně mluvíte o zcela odlišných situacích s odlišnými nároky a je jen přirozené, že je vhodnější jiný jazyk. Dokonce to sám M.P. v této diskusi minimálně jednou zmínil, ale asi to zapadlo.

[Miloslav Ponkrác]

Python 3000 je hlavně záruka, že Python syntaxi zaručeně změní a na starou se vyprdne - abych to řekl jazykem sprostého lidu. A to bezmála dvacet let po jeho startu. Python 3000 je budoucnost, která se stane přítomností za x časových jednotek - o to hůře, protože základní sysntaxe Pythonu se změní ne 17 let poté, ale třeba 18, nebo 19 - což je přesně to co považuji za znak neserióznosti - základní syntaxi by měl jazyk stabilizovat podstatně rychleji.

Python 2.6 možná 5 let podporován bude, ale budou jej podporovat i všichni autoři externích pythonovských knihoven? Opravdu věříte tomu, že každý vývojář bude 5 let poté backportovat všechny své věci i pět let poté co verze 2.6 už nebude aktuální? Já tedy nee, ani trochu. A Python runtime je bez knihoven dost k ničemu, jako každý programovací jazyk se bez knihoven může jít celkem klouzat, pokud tedy mám věřit svým dvacetiletých programátorským zkušenostem.

Ohledně C++ vzniká mýlka - já naprosto nikoho nenutím programovat v C++, je tu ho uvedl jen jako jednoho z obrovské spousty seriózních programovacích jazyků, které ctí zpětnou kompatibilitu. Klidně se můžeme bavit o jiném jazyce.

To, že neznáte žádný jazyk (dosaďte si sem požadované vlastnosti) neznamená, že takový neexistuje.

Překladač/interpret Vám nikdo nevezme, ale možná nebude na čem ho spustit, případně ten výsledek. Ono když třeba Vás překladač s knihovnami bude podporovat databázi XY verze max. 3.0 a aktuální bude 6.7, pak Vám ten fungující překladač/interpret s knihovnami taky může být platný jako mrtvému zimník.

[alblaho]

Miroslave, tak kritizujete Python nebo Python3000?

Python3000 je jistě kontroverzní změna. Prostě je otázka jestli se to zahození kompatibility vyplatí nebo ne. Kvído si myslí, že ano a bere to vážně - je to dlohodobý a dopředu avizovaný, budou konverzní utility, speciální režim Python 2.6 s warningama atd.

Naproti tomu fakt nevím, jakou nekompatibilitu mezi minor verzemi máte na mysli. Přidávaly se fíčury, to je všechno ne? Nevím jestli se přidalo nějaké klíčové slovo (to vždycky něco rozbije), ale asi není důvod, aby program pro Python 2.2 nefungoval na 2.5.

Jistěže C++ nebo dokonce Ada jsou "vážnější". S tím "desítky let" bych to ale bral s rezervou, desítky let starý céčkový zdroják bude mít s nejnovějším GCC bude mít taky problém. A víte jistě, že C++0x standard nerozbije něco z C++97? Třeba za pár let bude ISO norma na Python...

[Miloslav Ponkrác]

Kritizuji celý Python.

Python 3000 je hlavně signál, že zahození kompatiblity může být kdykoli provedeno v budoucnu. Poté to může být Python 4000 a 5000, prostě kdykoli si Rossum umane.

Ostatně, nemyslíte si, že teď nastal čas na zahození a znekompatibilnění celého unixového shellu včetně sh, bash, a dalších a jeho modernizaci? Co na tom, že se bude muset přepsat půl Linuxu? Co na tom, že admini budou muset zahodit své skripty? Co na tom, že než nové odladí bude Linux děravý jako řešeto? Ale Linus Torvalds třeba bude mít dojem, že se to vyplatí. To jen abych to parafrázoval na něčem, co na tomto serveu bude bližší.

Konverzní utility na přechod nejsou - a ty co jsou nejsou stoprocentní. A co mám informace, ani se nijak nepočítá s tím, že by byly lepší.

Nekompatibilita mezi minor verzemi je taková, že pokud něco napíšete v Python C API, tak musíte vše znovu přeložit. A protože obrovská část pythonovských knihoven něco v Céčku má napsáno, je potřeba knihovnu minimálně znovu přeložit, někdy dokonce torchu poladit.

Prostě Python je hračka pana Rossuma, a podle toho jak si chce hrát, tak budou pískat vývojáři. A já nechci být něčí hračka - chci spolupracovat tam, kde já i druhý cítíme vůči sobě určité závazky a zodpovědnost.

Jinak mám doma sadu 20 let starých Céčkových zdrojáků ze začátku své kariéry. Ty zdrojáky plně odpovídají něco K&R normě, něco ANSI C normě a bez problémů je přeložím nejnovějším gcc, stejně tak jako jako nejnovějším MS kompilátorem - a výsledný program dělá do puntíku to samé co kdysi. Nemusel jsem na zdroják ani sáhnout a změnit v C ani čárku. A je to o to pikantnější, že část zdrojáků vznikla na Amize, část na VAXu a část v raném MS-DOSu. A přestože jsem je překládal pro Linux a Windows (které v době vzniku zdrojáků ani neexistovaly) - přesto je kompatiblita 100%ní. Není to úžasné?

Ne, takže nic s rezervou neberu - kompatiblita buď je, nebo není. A ve sféře C, Ady, Fortranu, Cobolu je 100% kompatiblita trvající mnoho desítek let naprostou samořejmostí. A skutečnou realitou. Jsem si naprosto jistý, že C++0x nerozbije naprosto nic z C++ a kompatibilita bude zachována. Jednak situaci podrobně sleduji a jednak celý přístup pana Stroustrupa a komise je ryze profesionální a vedený s ohledem po zvýšení maximální užitečnosti C++. A je to znát na každém kroku.

Nevěřím, že bude ISO norma na Python, tedy nevěřím v horizontu několik let. A abych řekl pravdu, vzhledem k tomu, jak sleduji dění kolem Pythonu několik posledních let - nevěřím, že vůbec kdy ISO norma na Python vznikne.

[alblaho]

Python C api je stejná písnička jako vnitřnosti Linuxu (kernelu). Kdyby to bylo stabilní bylo by to fajn, ale holt není.

Python C api jsem osobně nepoužil. Knihovny to asi používají, ale většinou jako performance hack. Pokud dělám v pure Pythonu, minor verze mi nic nerozbijí.

A k těm vašim starým programům: asi jste měl štěstí, že neobsahovaly GUI, vlákna, napojení na databáze... Já jsem normy v C++ vždycky ctil (mám přenositelný kód rád), ale svůj kód psaný pod Windows v BCB si v Linuxu GCC nepřeložím

[Miloslav Ponkrác]

Jenže API je API!!! A vnitřnosti je něco úplně jiného. Kdy už to konečně někdo pochopí.

Knihocny to používají nejen jako performance hack, ale také hlavně proto, že Python neumí lézt sám o sobě do systému, volat API operačního systému, ani se připojovat na Céčkovské knihovny v systému. K tomu všemu potřebuje napsané knihovny připojené k Pythonu přes jeho C API. Jak byste to jinak dokázal?

Jenže ani GUI (nepočítám-li command line interface), ani vlákna nejsou součástí standardu. A Borlandské kódy v C++ samozřejmě dnes nepřeložíte - protože Borland byl průkopníkem v C++. Napsal naprosto první nativní kompilátor pro C++ a v době, kdy se teprve tápalo, jak má C++ vypadat. Jinak práci s databází v těch zdrojácích mám, tedy pokud DBF je databáze. Ale jinak samozřejmě souhlas.

[Ondrej 'SanTiago' Zajicek]

Ne, takže nic s rezervou neberu - kompatiblita buď je, nebo není. A ve sféře C, Ady, Fortranu, Cobolu je 100% kompatiblita

Ani v C neni kompatibilita 100%. Pri zmene vydani C99 doslo k zmenam, ktere mohlo rozbit par programu. Koneckoncu proto ma GCC parametr -std, aby se s nim dala urcovat verce C.

[Miloslav Ponkrác]

Dobře, a Vy máte pocit, že kompilátory nepodporují a nebudou podporovat verzi Céčka podle standardu z roku 89? Já tedy ne a ani se na to žádný nechystá. Vsadíme se, že i za 20 let přeložíte bez problémů ANSI C program podle normy z roku 1989? Co jste ochoten vsadit?

Navíc slušně napsaný program s kompatiblitou při přechodu na C99 problém mít prakticky nebude.

[Ondrej 'SanTiago' Zajicek]

Dobře, a Vy máte pocit, že kompilátory nepodporují a nebudou podporovat verzi Céčka podle standardu z roku 89?

Nic takoveho netvrdim, jenom jsem rozporoval onu 100% kompatibilitu *jazyka* (nikoliv jeho implementaci).

[thingie]

> přesto je kompatiblita 100%ní. Není to úžasné?

Není, koukejte si vrazit facku.

[Ondrej 'SanTiago' Zajicek]

Python 3000 je hlavně záruka, že Python syntaxi zaručeně změní a na starou se vyprdne - abych to řekl jazykem sprostého lidu.

A kdyby Rossum rekl, ze vyda novy jazyk ABC, mel by si kvuli tomu vyhrady vuci pythonu?

Pokud ne, tak jaky je rozdil, kdyz ten novy jazyk se jmenuje Python 3000 ?

[Kyosuke]

Dnes by to musel být spíš DEF, ABC není Pythonův syn, ale otec - jako v Cimrmanovi.

[Miloslav Ponkrác]

Jenže ona jedne verze Pythonu končí a druhá začne - tak to je a tak to bude. Ne, neměl bych výhrady, kdyby Python pokračoval a Python by ubastlil jiný jazyk. Ale Python 3000 není nový jazyk, je to killer dnešního Pythonu a tak se oněm jedná. A právě proto má stejný název "Python" a liší se jenom číslem verze.

Já se jen těším, až mi při pohledu na žlutou kouli dáte opakovat "tato krychle je modrá". Přesně takhle si připadám při Vaší otázce. Chcete mě zblbnout, abych přijal něco, co není pravda - a Vy to dobře víte.

[Ondrej 'SanTiago' Zajicek]

Jenže ona jedne verze Pythonu končí ... Ale Python 3000 není nový jazyk, je to killer dnešního Pythonu a tak se oněm jedná

A na zaklade ceho tvrdis tohle? Pokud bude soucasny python nekoho zajimat, tak ho nekdo bude dal udrzovat a vyvijet. A v distribucich bude paralelne nekolik pythonu.

[mimi.vx]

Python3k jeste nebyl vydan .....

Jeho nekompaktibilita byla deklarovana nekolik let dopredu v PEPs...

A jsou projekty ktere potrebuji stabilitu jazyka .... a jsou projekty a cinnosti ktere potrebuji spis jeho vyvoj...

[Miloslav Ponkrác]

Souhlasím, konečně rozumný člověk. Přesně tak to je!

[Roman Schulz]

Ano, taky jsem rád, že se Python vyvíjí. Posledních několik verzí ke změně syntaxe nedošlo (nebo jen minimální, která neměla vliv na mé projekty), přibyla spousta věcí v knihovnách a to je dobře. Pokud se jedná o nutnost překompilování C API, tak s tím problém taky nemám, protože jej využívám jen vyjímečně. Je to můj oblíbený jazyk a dělám v něm i velké projekty, stejně jako v C++. Obecně je nutné se nejdříve rozhodnout jestli je požadován výkon a pak volím C++, nebo rychlost vývoje a snadnost udržování projektu, a pak vede Python i přes nevýhodu mírné nekompatibility.

Co se týče Pythonu 3000, tak jsem byl zpočátku vyveden z míry co to chystají, ale po prostudování změn jsem zjistil že to nebude tak hrozné, většinou ze syntaxe vypadnou obsolete věci které už téměř nikdo nepoužívá a zbytek zařídí konverzní utilita. Až bude ostrá verze Pythonu 3OOO tak uvidíte že přechod nebude až tak hrozný jak píšete.

Naopak někdy mám pocit že hacků pro různé kompilátory C++ je více než dost, zkuste si nějaký větší projekt zkompilovat v gcc, MSVC i - téměř vždy narazíte na problémy se vzájemnou kompatibilitou, nechci říkat kdo je na vině protože každý kompilátor má svůj podíl.. Narazil jsem na spoustu takových projektů.

S Pythonem 2.x pracuji pátým rokem a v C,C++ se potýkám cca 10 let tak vím o čem mluvím

[Miloslav Ponkrác]

Co se týká Pythonu - já osobně tedy problémy mám a velké. A tyto problémy jsem tu popsal. Já čekám od tvůrce jazyka určitou zodpovědnost vůči lidem používajícím jeho jazyk a ten u pana Rossuma nenacházím. Bůh bude při pythonistech stát, pokud se nic v budoucnu nestane, ale to tak nemusí být dlouho. A já se přiznám jsem konzervativní, a rád při programování alespoň základní pevnou půdu pod nohama a tu při sledování vývoje Pythonu a činů pana Rossuma hodně postrádám.

Ohledně C i C++ - rozmohl se nešvar zavedený zejména Linuxovou komunitou, že oni neprogramují v C, ani v C++ - oni programují v GCC kompilátoru. Je to jejich problém a jejich blbost. Už jsem tu na abclinuxu četl tolik pitomostí a krávovin a kritik na C++, které vycházely z nízkého IQ jejich autora, který si nedokázal ve svém mozku dát dohromady ani elementární fakt, že pokud něco blbě dělá GCC, že to není vina C++, ale GCC.

Takže tohle já neřeším, protože zdrojáky velké části linuxové komunity nejsou zdrojáky programovacího jazyka C, ani C++, ale jsou to zdrojáky pseudoGCC jazyka, které jsou inspirované C/C++. Je to o to srandovnější, že tu spousta lidí nadává a horuje za multiplatformní programy (především v souvislosti té, že Windows programy by měli výrobci portovat i na Linux), ale sami nejsou s to napsat ani program, který vyhovuje standardu C/C++ a dá se přeložit jiným kompilátorem, než gcc.

Já programuji v C od roku cca 1998 (předtím asm, Pascal, a další). V C++ dělám od prvních verzí Borlanských kompilátorů, tedy odhadem plus mínus někdy od roku 1990. Velmi slušně mě to živí a problémy s kompatibilitou zdrojových kódů v C++ z různých zdrojů v zásadě nemám - a to řeším několik různých platforem a různé kompilátory.

[Miloslav Ponkrác]

Oprava : Já programuji v C od roku cca 1998 - má tam být 1988.

[Kyosuke]

"Javovská virtuální mašina je 3 milióny řádků v C++ jazyce"

Ale? Když jsem si naposledy stahoval trunk JRE 7, bylo to šest set tisíc, jestli se nepletu.

[Sinuhet]

A dnes, když se projednává další verze C++ (zcela zpětně kompatibilní s předchozí jak je u seriózních jazyků zvykem)

C++0x nebude zcela zpetne kompatibilni.

[Miloslav Ponkrác]

Zpětná kompatibilita je na prvním místě - a neustále se zvažuje a bere se jako důležitá věc. Pokud si pročtete body, které chce nová norma řešit, a které si stanovila za cíl, tak první bod je zachování zpětné kompatibility s C++.

Je obrovský rozdíl číst si jakoukoli diskusi o jednání v každé maličkosti - jakýkoli prohřešek proti zpětné kompatibilitě je okamžitě napadán jako nepřípustný. Je vidět, že jednání vedou profesionálové a mistři svého oboru a praktici.

Zatímco při jednání ohledně změn v Pythonu mám pocit, že Rossum je amatér a hlavní důvody jsou tam "Rossum nemá rád Céčkové kontrukce", "Rossum nemá rád LISP", "Rossum se sčuchnul s autorem Perlu". Takhle natvrdo to tam není, ale ani to moc schované není.

Ale k věci - ano C++0x nebude na 100% kompatibilní, například export nikdo nikdy nepoužil. Takže nenajdete běžný program, který byste novou normou nepřeložil. A za druhé - vzhledem k tomu, že norma ještě není hotova, pak kategorické tvrzení o nekompatiblitě není na místě. Velmi vidím přiostřovací fázi teď zaměřenou právě na likvidaci možností nekompatibilit. V C++ komisi se použitelnost jazyka bere velmi vážně.