Názory k článku
Red Hat nechce Mono v RHEL

Osobně si myslím, že ani .NET ani Java se už moc dlouho na výsluní ohřívat nebudou. Obě jsou nepříliš podařené technologie, které jsou dobré akorát pro to, aby bylo proč získávat drahé diplomy (samozřejmě pouze od Sunu a Microsoftu). Podle mě budoucnost zůstává Céčku a C++ s doplněním od Pythonu (hlavně jako výukového a prototypovacího jazyka, místo dnes stále ještě používaných Pascalu a Basicu).

Nebo si myslíte, že je jiný důvod, proč jsou Windows a Solaris napsány v Céčku?

No je to presne naopak myslim, ze C++ nebo ?! C se budou pouzivat uz jen pro nejake low level aplikace apod. ale vetsina ostatnich veci bude naprogramovan v necem takovem .

Ma to nesporne vyhody o kterych vi kazdy kdo o nich chce vedet (multiplatformost, garbage collector atd...) .

My programuje na obouch platformach a mono je pro nas v podstate spasou a uplne se v tom rochnime .

Hele mateji, vy v Microsoftu delate v Monu ? :-)
Nebo jsi jinej matej ?

:-)

Ja bych to videl spis na kombinaci Java + (Python/Ruby)

Pokud chcete rozšiřitelnou/přenositelnou applikaci tak jedině Java (jo a ObjectiveC).

Proč jsou Win, Solaris, Linux psany v C ?
- musí tahat za nožičky švábům na MB ...
- a musí to dělat zatraceně efektivně

Neco na tom bude :)

Podle mich zkusenosti a toho je jasnym favoritem Python. Napsal jsem uz par radek a patri jednoduse k spicce. Osobne neznam nic lepsiho (mozna se milim, nekteri, kteri maji na konte 100x vice aplikaci a upgradu jiste prominou), ale Python je podle me nejuniverzalnejsi programovaci jazyk (alespon pod Linuxem urcite).

Python je asi fajn, ale s principu je to interpreter. V momente ze potrebujete aplikaci pro PDA zacinate mit problem a skoncite u C++ anebo Javy. Zalezi kam se pozene vyvoj, zda stolni PC/notebook bude stale nosnou platformou. Obecne, na PC udelate vse, ale pokud potrebujete neco specialnejsiho (vestavene systemy, prenosne pocitace, mobilni telefony) tak zjistite ze mate jen omezenou moznost volby co muzete pouzit.

Sice interpreter, ale něco podobného lze říci i o aplikacích v javě nebo .NET Ovšem ať tak nebo tak, asi není náhodou, že moje oblíbené (multiplatformní) aplikace,jsou postavené na pythonu a glade a jedou podstatně svižněji a s menším množstvím problémů než ty co používají výše zmíněné technologie.

Jo, taky jsem zaregistroval, že Pythoní aplikace jedou tak nějak rychleji než ty v céčku, o Javě ani nemluvě. Btw. nevím jak .NET, ale Java je určitě interpretovaný jazyk - to k tomu příspěvku nad Vámi.

Podle me je nekolik duvodu, proc pouzivat Python:

- ZMINOVANA RYCHLOST (VIZ SEZNAM.CZ - BLESKOVE ODPOVIDANI NA DOTAZY Z DB - SAMOZREJME HRAJE KLICOVOU ROLI DB SAMA)
- SPOLEHLIVOST (JESTE JSEM NEZAREGISTROVAL APLIKACI, KTERA BY PRI ODLADENI NEJAK ZLOBILA - NAROZDIL OD JAVY)
- INTERPRETER A VSECHNO JE POD GPL A TUDIS SE NIKDO NEMUSI BAT LICENCI (JAVA ZAPLAT PANBUH PO 10-TI LETECH TAKY, NO UVIDIME CO TO PRINESE)
- PRI NAROCNYCH APLIKACI (MYSLIM TIM VYHLEDAVACI A KATALOGIZACNI DB, SPOLEHLIVOST)

Je mozne ze jsem na neco zapomnel, kdyztak mne opravte.

skoda ze se ty kapitalky nedaji cist

[rejp]Číst se dají, ale dost blbě, a navíc to nejsou kapitálky, ale velká písmena; kapitálky se čtou o něco lépe ;-) [/rejp]

prosím o doplnění
- máte nějaká srovnání s něčím podobného ražení jako seznam ale v javě, ať si můžu udělat obrázek o rychlosti.
- nějaký příklad ? "zlobí" JAVA jakožto jazyk a runtime, nebo applikace napsaná člověkem který ji prostě napsal špatně ??? Např. znám spoustu aplikací napsaných v C++ pro linux a fungují perfektně a znám v tomto jazyku applikace pro Windows které stále padají. Také je to ale i naopak. Kdo za to může ?? Programovací jazyk nebo vývojář ??
- on se někdo bál licencí na javu ?? nic takového jsem nikde nezaznamenal
- poslední připomínku bych prosil přeložit do češtiny protože jí nechápu

neosetrene vyjimky?

python ma problem v tom, ze nedokaze bezet opravdu paralelne - i kdyz ma program v pythonu vice vlaken, tak vzdy bezi pouze jedno (i na vice procesorovych strojich a i v pripade, ze pouziva funce napsane v cecku). coz je v dobe core2duo atd. dost blby omezeni.

existuje sice stackless python, kterej tohle omezeni nema, ale vzhledem k tomu, ze u nej neexistuji ani balicky pro nejrozsirenejsi linuxovy distra, tak je jeho pouzitelnost (snad jen zatim) dost omezena

Tohle není tak docela pravda. CPython má tzv. global interpreter lock (GIL) a ten rozhodně neblokuje funkce psané v C, aspoň teda do té doby, než vstoupí do interakce s interpreterem. Takže ano, GIL brzdí, ale pokud funkce v C většinu času běží samostatně, tak to nějak zvlášť nevadí. Další možnost je samozřejmě namístu threadů forkovat (samozřejmě to není možné vždy, ale často je to dobré řešení) a v tom případě GIL nevadí ani čistě pythonovským rutinám, protože mají celý interpreter pro sebe. O GIL se poměrně často a bouřlivě diskutuje, ale zatím se vývojáři CPythonu nemají k tomu, aby ho odstranili.

Je mozne ze jsem na neco zapomnel, kdyztak mne opravte.
Ano, zapomněl jste si vypnout Caps Lock.

Kolik svého času stráví program v Pythonu v built-in funkcích napsaných v céčku a kolik v opravdu pythoním kódu? Jaký je ten poměr u Javy? Zhruba.

(to není flame, ale skutečná otázka)

Na to pochopitelně nelze odpovědět, protože to záleží čistě na aplikaci co dělá a jaké funkce používá.

Ale tak, dá se udělat nějaký vzorek obdobných aplikací a podle toho to porovnat. Jde mi o to, nakolik je rychlost Pythonu dána tím, že samotného pythoního kódu mnoho není a okamžitě se jde do nativního céčkového kódu. Na to se dají udělat nějaká měření a odhady.

Nesmysl, python je mnohem pomalejsi nez Java (o C ani nemluve...) Viz
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=python

Java ma velice propracovany JIT kompilator (preklada dynamicky kod do nativniho kodu a provadi ruzne runtime optimalizaci, takze to zrovna interpretovany jazyk neni - navic kdyz uz, tak se nemuze prinejhorsim interpretovat jenom bytecode), coz je neco, s cim se nemuze rovnat ani python, ani Mono (ovsem nativni C# implementace od MS s tim samozrejme srovnatelna je, tusim byla i o neco rychlejsi).

Navic skalovatelnost Javy je trochu nekde jinde, opravdu netusim, s cim by se v Pythonu dal nahradit treba takovy Sun Application Server a technologie jako EJB.

Ale nic proti pythonu, je to velice dobry skriptovaci jazyk, konec koncu ho obcas taky pouzivam :-) Ale neoznacil bych ho zrovna za konkurenta Javy, jeho pouziti je jinde a mohou velice dobre koexistovat.

Java pomaleji startuje, má větší paměťové nároky a pomalejší GUI. Ná výkonově náročné věci se v Pythonu používají knihovny napsané v C. Výsledkem je aplikace, která má svižnější odezvu než aplikace napsaná v javě, přestože JVM je rychlejší než interpret Pythonu, což jediné porovnává váš test. Proto je Python vhodnější na malé desktopové aplikace typu konfigurační nástroje nebo třeba skripty, než Java.

Tak to je ovšem odvážné tvrzení. Nedovedu si představit, jak zprasené programy v C++ musíte mít na mysli, aby byly pomalejší než ty v Pythonu.

Nebude to třeba tím, že v Pythonu se píší hlavně jednodušší programy?

Imho bylo myšleno C#.

http://www.strongtalk.org - stačí si na vhodný runtime počkat nebo k němu přispět. ;-)

Když pro PDA tak asi jedině .NET Compact

Python? Dyt nema ani klasicky for cyklus!
Pokud chci neco jako

for(i=0;i<1000000000;i++) {
...
}

tak to musim opisovat pres while cyklus.

Neco jako:

for i in range(1000000000):
    ...

ale pak tam nejak nevidim to "while". Zamerne tam nepouzivam xrange, ono brzo i "range" zacne vracet iterator.

Jo, ale to behem toho naalokuje pole 1000000000 integeru a to skonci na nedostatku pameti (na vetsine dnesnich pocitacu)

A tu poznamku o xrange jsi prehledl schvalne? :-D I z tohoto duvodu obsahuje Python generatory.

for i in range(0,100): print i

for i in xrange(1000000000):

A céčko zase nemá normální for, jenom tu napodobeninu co označuješ za klasickou. I ta pitomá Java už to má.

Existuje najaky rebricek jazykov? Prosim poslite link kde je Ruby a Python na spicke. Som velmi zvedavy.

Zajimavy napad, ovsem domnivam se, ze takovy zebricek neni mozne udelat. min i proto, ze statici nebudou dobre hodnotit dynamicke jazyky a opacne. A koneckoncu jaky zebricek, vsechno je to jenom TS :-D

Jinak by tam pravdepodobne byl Lisp, Haskel, Ocaml, Smalltalk, Self a podobne vecicky

nesouhlasim! vsechno je to jen lambda kalkul! ;-]

Muj nazor na Python: Proc museli tak nadejny jazyk od zacatku zabyt tak pitomym napadem jako je 2D layout. Nesnasim, kdyz mi nekdo vnucuje odsazeni.
(A BTW, pokud chce nekdo porovnat rychlost pythonu a C, at porovna klasickou a C verzi portage toolu v Gentoo).

Ono to ma sve vyhody a predevsim je to velmi logicke. Taky se mi to z pocatku nelibilo, protoze je to nezvykle, ale prisel jsem tomu na chut a ted to vnimam pozitivne.

Zkousels nekdy napsat neco vetsiho, udrzovatelneho a bezpecneho v C++ nebo C?
Asi ne, protoze jinak bys takovou blbost nevypustil z prstu.

Vetsiho nemyslim 100 radek ale dejme tomu 10 000 radek (nebo 100 000)
(i kdyz tohle je velmi smesny argument, protoze 10 000 radek
v Delphi, Jave, C# je velmi slusny program, narozdil od 10 000
radek v C je par oken (napr. protoze 70% kodu je testovani volani misto pouziti vyjimek, atd.).
Priklad: proc jsou vsude exploidy na buffer overrun? Protoze C(+)!

V soucasnosti uznavam tyto jazyky pro APLIKACNI PROGRAMOVANI: C#, Object Pascal, Java, a asi i Python, Ruby.
Pro low level nebo specialni ulohy muze byt pouzito C

Mimochodem pletes si platformy (.NET) a jazyky (Java, C, C++).
Treba Microsoft ma IronPython (implementace Pythonu pod .NET) (http://www.ironpython.com/).
Nema se cenu rozcilovat, teoretiku je spousta.

Exploity nejsou protoze C, ale protoze programator udelal chybu. Jestli veris tomu, ze te .NET zachrani, tak se mylis.

V nekterych jazycih se ale podobne chyby delaji hure. Stejne tak problemy se spravou pameti, progaramator udela mene chyb, pokud nepotrebuje pouzivat pointry a nemusi se starat o spravu pameti. Ale kazdy luxus ma svou cenu... ;-)

Programujem pod C++ roky a pointery skoro vobec nepouzivam. Nestaram sa ani nijak extra o spravu pamati. Pokial planujem nieco alokovat dynamicky, je jasne, ze si to v destruktore skontrolujem a pripadne dealokujem. Zacinam mat pocit, ako keby garbage collector sluzil primarne pre programatorov s kratkou pamatou, alebo co ...

Teorie je krasna. Ale proc je tolik programu v Linuxu (treba aplikace pro Gnome), ktere maji problemy s alokaci pameti (neuvolnena pamet). Anebo Firefox, nechte jej par dni bezet a budete hledat volnou pamet. Proc stale tolik aplikaci pada na poruseni ochrany pameti, kdyz je to tak snadne a primocare??

Pokud zvadnete ukazatele a alokaci pameti, pak uz vas muze zaskocit jedine zaludnosti asynchronniho programovani, synchronizace vlaken, sdileni zdroju.

To je jednoduchy. Prectete si na strankach mozilly tohle. Mozilla je napsana v nejakem speudo jazyce, ktery sice pripomina C++, ale neni to C++. Duvodem je strach z chyb a z nekompatibilit v kompilatorech. U C++ se nabizi otazka proc vlastne porad pouzivame programovaci jazyk ke kteremu ani po tolika letech neexistuje plnohodnotny a bezchybny kompilator?
Nehodlam resit jestli budoucnost patri Perlu, Pythonu nebo Ryby, jsem si ale jistej, ze budoucnost patri multivlaknovym aplikacim. Podivejte se jake problemy maji s multithreadingem PHP nebo Perl. Scriptovaci jazyky, ktere zavisi na knihovnach napsanych v Ccku budou mit problemy s multitreadingem vzdycky. Jave a .NET maji tu vyhodu, ze jejich knihovny jsou napsane v Jave nebo .NETu, je to mozna pomalejsi, ale urcite bezpecnejsi a lepe se v tom hledaji chyby.

To je absolutní nesmysl.

Ten článek je o tom jak psát kód pro mozillu/firefox tak, aby šel zkompilovat na všech podporovaných platformách. Je to C++, nic víc.

Letecký průmysl, armádní zařízení, chemické technologie, jaderná zařízení, lékařské přístroje, ... všude tam je drtivá většina havárií způsobená tím, že někdo udělal chybu. Investují se závratné částky do technologií a postupů, které minimalizují možnost lidské chyby.

Vy ale zřejmě patříte k lidem, kteří nevěřícně kroutí hlavou nad dělníkem co nosí helmu - vždyť by mu musel někdo něco hodit na hlavu a to je chyba lidí, stejně tak jako nad automobilovými crash testy - vždyť bouračka je výsledkem chyby člověka. Aneb pokud vás budu parafrázovat pak "jestli věříš tomu, že tě pak lépe stavěné auto zachrání, tak se mýlíš".

Každý střípek, který omezí možnost vzniku lidské chyby nebo alespoň její dopad je přínosem.

Ano .NET je platforma a přináší plus pouze do Windows. Pod ostatními operačními systémy máme kvalitnější platformy... A co se týče C# - jaké má přednosti před C++? Btw. kolik řádků má jádro linuxu? V čem je napsané? Je udržovatelné? Je bezpečné? V čem je napsána většina FOSS aplikací, běžících na linuxu/unixu/bsd? Jsou udržovatelné a bezpečné? Myslím, že si dokážete odpovědět sám. Sice se rozčilujete nad teoretizováním, ale sám v praxi vidíte pouze špičku ledovce!

S tím souhlasím. Ale Java mi ve srovnání s C++ připadá hodně omezená (hodně omezené možnosti "vyjadřování").

Coz je presne to, co je pro vyvoj podnikovych aplikaci super - nepotrebuji "rocket science", jedna se o naprosto nudne programovani, ale potrebuji stabilni a dobre udrzovatelny system, ktery naprogramuji prumerni programatori.

S cimz naprosto souhlasim, ale zkus to rict nejakemu Java rulez chlapikovi a se zlou se potazes, dyk je Java to neelepsi :-D

Java je krásný jazyk, ale mizerná platforma. Proto mám raději .NET, ve kterém se dá napsat více věcí. Například v Managed C++ lze kombinovat .NET a "klasické" C++. Pro běžné aplikace je ale lepší C#.

argumenty nejsou az tak spatne, btw. ja "par" radku kodu v C napsal a rikam, ze kdyz clovek dodrzuje zasady, napise snadno udrzovatelnou a bezpecnou aplikaci... pouzivat C na psani okenni aplikace je BLBOST, prave kvuli tomu, ze vetsina kodu je jen obsluha oken, na druhou stranu, v prostredi salovych pocitacu, kde se pohybuji, si nedokazu predstavit napr. .net, vzhledem k povaze aplikaci bezicich na pozadi si vyhodnejsi jazyk nez C nedokazu predstavit

> Zkousels nekdy napsat neco vetsiho, udrzovatelneho a bezpecneho v C++ nebo C?
> Asi ne, protoze jinak bys takovou blbost nevypustil z prstu.

> Vetsiho nemyslim 100 radek ale dejme tomu 10 000 radek (nebo 100 000)

No ja pisu v U++ (C++ platforma) aplikace ktere maji kolem 210 000 radek (coz odpovida cca 500 000 radku v jave, viz. zde:

http://www.ultimatepp.org/www$uppweb$vsswing$en-us.html)

a nemenil bych. Koho zajima starat se o uvolnovani zdroju jako v Jave (ci C#)?

Zkoušel, jsem za to dobře placený, napsáno mám několik milionů řáděk, možná i desítky milionů.

Exploity na buffer overrun jsou ty samé exploity, jako jsou v Javě a Pythonu exploity na neošetřené vstupní hodnoty (případně na buffer overrun jejich interpretů). Žádný jazyk nedokáže zabránit chybám programátora.

Také to srovnání počtu řádek je dost nepřesné, až budeš používat toolkity (GTK, Qt, ICE, …), tak zjistíš, že potom v C++ napíšeš sto řádky to, co v Javě napíšeš na řádků tisíc (nehledě na to, že to bude mnohem rychlejší). Tím také padají argumenty mnohých, že Java a .NET jsou portabilnější.

Z toho také plyne to, že není pravda, že by Céčko nebo C++ byly těžko udržovatelné. Stačí psát dokumentaci. Ono je celkem jedno, jestli napíšeš deset tisíc řádků v Céčku nebo Javě, bez komentářů a dokumentace se to bude oboje špatně udržovat. To je možná taky důvod, proč existují věci jako Doxygen a Javadoc.

Pokud se ale chceme bavit o kráse jazyka, tak bych na první místo dosadil SmallTalk. Bohužel většinou platí, že čím hezčí jazyk, tím méně je reálně použitelný (snad jedinou výjimkou je ten Python).

Mimochodem, asi ti uniklo, že jak .NET, tak JVM jsou napsány v C++, takže podle tvého tvrzení jsou obě tyto platformy nebezpečné, tudíž by se neměly používat. :)

Samozřejmě vím, že .NET není jazyk, ale platforma; myslel jsem tím jazyky na této platformě běžně používané (např. C#, J#, Visual Basic .NET, popř. i ten IronPython).

A samozřejmě o IronPython vím, mimochodem existuje i JPython. A také existuje PyPy, které by mělo odstranit tvoje námitky na buffer overruny, bohužel se tak neděje.

Mimochodem: proč chce po mě Windows Vista tolik systémových zdrojů? Protože .NET. To je také jeden z důvodů, proč si myslím, že se vývojáří vrátí k C++. Nenažranost .NETu a Javy je neuvěřitelná (samozřejmě Python na tom není o mnoho lépe, ale ten bych bral jako jazyk na jednoduché úlohy a na prototypování, na což se ani Java ani C# nehodí).

A co takhle jaderne reaktory?

Jaderna zarizeni jsou vyvijena v Ade, ktera je pro tyto ucely navrzena a odladena. Napr. ridici system pro Temelin je v Ade (vyvijel to myslim Westinghouse). Nevyhodou je, ze Ada compiler pro kriticke aplikace je sakra drahy, ale jinak je to zajimava technologie.

ja to myslel tak, ze by se nam nekdo mohl vyjadrit i k jadernym reaktorum, kvantove mechanice a podobne, urcite se tady najde dost 'odborniku'

A hlavne: kdyz uz se nekdo dokaze naucit Adu, tak je schopen psat programy inteligentne. IMHO slusna cast spolehlivosti tehle obskurnich jazyku spociva v tom, ze v nich nepisou "prumerny programatori" (natoz aby mluvili do jejich vyvoje).

Neco si o tech jazycich (a hlavne o jejich nasazeni a (ne)vyhodach) precti nez z Tebe priste vypadne takovy blabol...

Ani nemusím, jsou to zkušenosti. Céčko, C++, C#, J#, Javu, Python, Pascal (Borland Pascal, Object Pascal aka Delphi) a Visual Basic (vč. .NET) jsem používal a s C++ a Pythonem se pracovalo nejlépe. Dneska používám Python na menší úlohy a na prototypování, C++ na vlastní implementaci.

Pokud budete dělat nějaké pořádné projekty (typu databáze, velká aplikace, nebo 3D-akcelerovaná počítačová hra), brzo narazíte na pomalost a nenažranost jiného řešení, než je Céčko nebo C++.

Tak zrovna s Pascalem bych nesouhlasil. Podle mě je to jeden z nejvhodnějších jazyků pro výuku a to proto, že je jednak snadno čitelný, má velmi striktní kompilátor a také má poměrně kvalitní vývojové prostředí - ve win Delphi, jinde je celkem dobrý FreePascal, nebo Lazarus. Python si myslím není dobrý na učení - je dost volný a umožnuje kdejaké prasárny, díky nimž se pak může hůře hledat chyba v programu. Ale pořád je to lepší než Basic... Podle mého názoru na výuku programování je jednoznačně nejlepší Pascal, na reálné nasazení pak C(++) a Python a v některých oborech Fortran. .NET podle mého nepřináší žádná významná plus no a Java je děsně pomalá a většina aplikací naprogramovaných v Jave mi příjde, že jsou buďto odfláknuté nebo nedodělané ... Uvidíme, co přinese GPL Java...

Rozhodne souhlasim ze vyuka je to jedine k cemu je Pascal dobry. Je jen otazka, jestli by nebylo vhodnejsi ucit na jazyku, ktery by mel tyto vyhody pascalu ale nebyl tak vzdaleny praxi ... samozrejme by takovy musel existovat, protoze C,C++,C#,Java,Python nebo treba PHP (o Perlu nemluve) takovymi jazyky zcela urcite nejsou.

Java trpi v mensi mire stejnym problemem jako PHP: pri vyvoji jejich zakladu se udelali nejake chyby a ted uz neni mozne je opravit (tedy, v PHP to bohuzel zkousi). Obavam se, ze ani GPL Java to nedokaze.

Právě díky možnostem Pythonu odnést programátora do říše chyb a omylů a díky relativně snadnému zápisu se podle mě hodně hodí na výuku teorie programování. Na praktickou výuku programování je pravda ten Pascal lepší, nicméně pokud se někdo naučí teorii, tak může rovnou z Pythonu přejít na C++ nebo třeba Erlang nebo Haskell (což bych programátorům, co se učili v Pascalu, moc nedoporučoval).

Co znamená "odnést programátora do říše chyb a omylů"?

Jinak plně souhlasím s tím, že Python je mimořádně výhodný pro výuku základů a pro výuku programování pro neprogramátory, tedy pro lidi, kteří si občas chtějí nebo potřebují naprogramovat nějaký výpočet, vizualizovat si průběh funkce nebo já nevím co. Od Pythonu se dá odrazit směrem k C nebo C++, Lispu, Smalltalku apod. Učit začátečníka programovat spojové seznamy v Pascalu pomocí ukazatelů, to mi přijde jako maximální zhovadilost.

opravte prosím to open-rouce

Mne více znepokojuje, že RedHat chce rozhodovat o tom co je dobré a co špatné za uživatele.
Linuxové distribuce chápu jako odladěnou sadu balíčků s případným supportem u komerčních distribucí. Největším přínosem je pak pro mne to, že si nemusím každou aplikaci kompilovat a odladit vazby a to vše znovu a znovu na všech strojích při změně verze SW či používané knihovny. Z tohoto pohledu by mělo být hlavním kritériem pro zařazení SW do distribuce to, že uživatelé jej chtějí a potřebují, přičemž u knihoven a programovacích jazyků ještě navíc musí distributor počítat s tím, že je uživatel používá ve svých aplikacích.
Tímto do toho ale RH zavádí svá kritéria - hodí/nehodí se to do mých strategických plánů, koliduje/nekoliduje to s mými investicemi (JBoss) - a to je dle mého názoru špatně.

PS: Argument, že si mohu vybrat jinou distribuci přijmu lépe od toho, kdo takovouto změnu z podobných důvodů udělal na desítkách produkčních serverů a obhájil si to u těch, kteří ho za tuto práci zaplatili.

Uživatelé jsou jak děti, neví co chtějí. Podívejte se kolem samej Java a .NET pisálek :-)

RH sam rika, ze neni poptavka po Monu. RH je firma, ktera tvori RHEL za ucelem zisku a proto je dobre ze ma sva kriteria. Pokud to budou spatna kriteria, RH poskodi hlavne sam sebe.

Kdyby jej uzivatele chteli, tak si udelaji svoje repository, nebo si je skompiluji (muzou pouzit optimalizacni volby do GCC a tim udelat aplikaci jeste rychlejsi)

Pokud by byl skutecne tlak na mono, tak tam uz je !!!!!

Jenze proc .mono .net ... kdyz tu mame python, ktery postupne nahrazuje perl a nasazuje se kde se da, i skusenosti seznamu rikaji, ze prechod na python je nejefektivnejsi a ze zvlada velkou zatez s rozumnou rezii, narozdilod perlu nebo javy ... proc lide tak nesnaseji javu a tlaci mono kdyz rezie je stejna ??? Nebylo by lepsi udelat just time kompiler javy jako ma IBM a tim zrychlit javu a usporit prostredky jak pametove tak CPU ???

Uz neni potreba vyvijet vlastni JIT, Sun vydava svou Javu - vcetne pomerne rychleho runtime - pod GPL.

Já si myslím, že důvody pro odmítnutí Mona jsou přece jen strachové. A taky možná investice do JBosse.

Protože všechny uváděné důvody jsou _dost_ chatrné. Vyčítat tomboyi v C#, že je to malá aplikace závislá na velkém Monu, to je fakt štěpná myšlenka.

Stejne nesmyslny nazor jako padl na abclinuxu. RH je prece spolecnost, co Red Hat vyrabi a distribuuje. Neni duvod ji pindat do toho, co ma a co nema zaradit. O tom rozhodne Red Hat a zda to ma smysl rozhodnou zakaznici.

Docela by me zajimalo, jak je to ve skuecnosti s licenci. Jasne, officialni vyjadreni o GPL, LGPL, MIT.. jsou znama... Ale zajimalo by me, jestli to tak trochu nesmrdi? Cetl jsem nejeden NE-Microsofti nazor na mono a spousta z nich se shodla, ze to nemusi byt uplne ciste... Novellu uz tedy rozhodne neverim ani nos mezi ocima...
(toto ma byt otazka do diskuze, ne tvrzeni!!!)

o nic - bez Mona nikdo neumre a komu se nelibi, ze neni v Red Hatu,
at si koupi jinou distribuci. Kdyz to nepozaduji nakupujici RHEL,
tak proc by to tam cpali, kvuli 4 aplikacim? Kolik je jich v te
distribuci 10000? A krome toho je to tak - jakekoliv motani se
kolem Microsofti "technologie" prinasi nebezpeci ze vas velky M.
zazaluje pro porusovani IP, tim jsem si jisty.

ze preco MS proste neurobi implementaciu .NET aj pod linux. Bolo by to pre nich len vyhodne, pretoze by sa im programatori rozsirili aj o linuxovych vyvojarov a opet by to pre nich bol len vyssi podiel na trhu. Zaroven by bola zarucena 100% kompatibilita a prenositelnost aplikacii, co pri MONO urcite nikdy nebude.

Zaroven pre tych co by chceli namietat nieco o licenciach by som rad upozornil, ze java bola dlhe roky nie open source a tiez to nikoho netrapilo, v pohode sa rozsirila prave vdaka a myslim si ze len v daka tomu, aka je multiplatformova a na linuxe v podstate jedina jednoducho programovatelna a univerzalna v zmysle jeden jazyk, jeden JVM a bezi to vsade rovnako

Takze podla mna by malo MS zliezt z toho svojho nafukaneho stupienka a zacat troska spolupracovat a robit veci aj pre ludi, bol by to len bod k dobru

naivko :-) MS se naopak bude naramne hodit, ze ve Windows C# aplikace behaji a ze ostatni OS budou o krok pozadu...

...no podla mna by to bolo proti "filozofii" firmy. To je podobna otazka, ako preco neurobia office aj pre linux(teda myslim, ze neurobili :o))...podla mna je jeden z hlavnych dovodov, udrziavanie monopolu v OS...tymto krokom by sa asi stali oba systemy "nebezpecne" kompatibilne a tym padom navzajom nahraditelne...

No dovolim si tvrdit, ze MS office a .NET framework je troska nevhodne porovnavat. MS office keby spravili pre linux, tak v tom momente nema ziadna sekretarka na stole win, co by bolo proti nim samim, ako si pisal.

Ak spravia .NET framework pre linux:
1. programatorske timy budu viac pouzivat ich technologie (voci jave) pretoze budu portabilne na rozne platformy, cim sa rozsiri pouzivanie ich technologie, a to je pre nich dost podstatne
2. firmy ktore su zvyknute pouzivat MS Win servre (ano su take) by v pripade potreby nejakych robustnych aplikacii doteraz beziacich len na linuxe neboli nutene prechadzat / kupovat nove servre linux ale riesenia napisane v .NET primarne pre linux, by im rovnako behali aj pod Win, cim by zas MS neprichadzal o zakaznikov

takze myslim si, ze tym, ze by MS vydal .NET pre linux by viac ziskal ako stratil

no, mozno mas pravdu...ale myslim, ze keby ms viac ziskal ako stratil, tak to urcite spravi...takto si myslim, ze bud je pren riziko privysoke, alebo viac strati ako ziska....to porovnanie s office mozno az tak odveci nebolo....myslel som to tak, ze si buduje uspech na nekompatibile a nie na pomere cena/vykon(kvalita)

"ze preco MS proste neurobi implementaciu .NET aj pod linux"

rekl bych, ze ten duvod je ruznorodost distribuci. Podivej se, jak ma kazdej clovek jinou distribuci, jinak ji aktualizuje, takze ma kazdej jiny jadro, navic si vezmi Gentoo, kterej je snad u kazdy usera jinej. To by M$ musel:

- bud delat binarni balicky pro vsechny mozny varianty a to by nezvladal,

- nebo by delal balicky jenom pro urcite distribuce v urcitych konfiguracich (pricemz pokud by to mel udrzovat treba pro aktualizovanou FC, tak by musel delat aktualizace stejne se systemem, aby to chodil), tim by se ale brzo dostal do stavu, ze by pouzivalo tak malo lidi, ze by se mu zase nevyplatilo,

- a aby to mohli pouzivat uplne vsichni, pak by to musel udelat open source a to M$ nikdy neudela:)

SUN Java nema s Linuxem sebemensi problem, funguje bez potizi vsude.

No neviem ci vies ako presne funguje .NET, ale ma dost vela spolocneho s javou. Po skompilovani totiz dostanes bytecode, ktory sa preklada az pri prvom spusteni, jedine co teda musi MS spravit je .NET framework pre jednotlive platformy, x86, IA64, AMD64... a sem tam vydat novu verziu ak pride nova verzia jadra, ktora nieco zasadne meni, nie pri kazdej. Takze by to asi nebolo az take komplikovane podla mna

asi ta trosku poopravim, nezalezi to od verzie jadra. Uzivatelske aplikacie(a tym padom aj pripadny .NET framework) idu cez glibc rozhranie a az glibc vola jadro. A to kernel rozhranie sa aj tak nemeni uz peknych par rokov(okrem noviniek)

To přeci nemůžeš myslet vážně. Existuje několik důvodů, proč neimplementovat .NET jinde. Třeba například:
1) mnoho práce
2) proč připouštět konkurenci, když mám monopol

</blah> ... vse jde napsat treba i ve strojaku potazmo v assembleru (napr. os menuetos) nebo i v java ... ale pravdou zustava ze kdyz se programuje velky informacni system tak java je urcite vyhodou ... ne proto ze by programy v jave napsane byly nejake lepsi (to zalezi jen na navrhu a implementaci), ale ten kod je snaze udrzovatelny (muj subj. nazor.) ... proste nemusite hlidat jestli nahodou nekdo nepretizil operator "+", jestli se dobre uvolnila pamet po vystupu z bloku, jestli ... neznamena to sice ze by jsme to cele nemohli udelat treba v pascalu ...

a mela by byt java a/nebo mono v distribucich linuxu? ... to zalezi na distributorech ... ale osobne preferuji aplikace ktere nejsou zavisle na mono ... asi jen zvyk? </blah>

C++ kod je podla mna tiez dost dobre udrzovatelny. Vsetko to stoji samozrejme na kvalite pociatocneho navrhu. Ale chybny objektovy navrh mozte spravit aj v jave:)

Skuseni programatori nemaju zvycajne problemy s memory leaks. Je to pre nich prakticky rutina. Ak sa nejaky predsa len najde, tak je to otazkou maximalne par hodin, kedy sa problem lokalizuje a odstrani. U nas sa operatory + len tak benevolentne nepretazuju. To je prave vec, ktora zaciatocnikov laka na vsetko si porobit kadejake operatory. Prakticky to ale nema zmysel, iba to v konecnom dosledku zneprehladnuje kod.

..jo a pracujem na projekte ktory ma viac ako 100 riadkov :)

Mozno sa toho v C/C++ uz vela zmenilo ale mne najviac vadili kniznice. Java ma dnes prakticky uz v standarde baliky prakticky na vsetko. Pluginovacie systemy napr. na encryption znamenaju ze moj kod je nezavisly od implementacie konkretnych algoritmov. Samozrejme vela je odpozorovane s CORBA a C++ ale je to urobene dobre.
V C/C++ stale kazda kniznica pozaduje iny sposob uvolnovania pamate naalokovanych zdrojov a podobne. A pisat si vzdy vsetko znovu nie je cesta. Naviac mnohe kniznice multiplatformove nie su.

Vo vela veciach mate pravdu a verim vam, ze su kniznice v jave dobre. Ja som ale reagoval na nieco trosku ine. Mam bohate skusenosti s multiplatformovym vyvojom a to co popisujete je najskor problem tych kniznic a nie C++ vo vseobecnosti. To su predsa dve uplne odlisne veci - jazyk a nejaka kniznica v nom pouzitelna.

Ked uz od veci, tak si zoberte taky pripad PHP, kde sa tieto dve veci zaciatocnikom prakticky prekryvaju. Potom sa nestacim cudovat ake bastle obcas vidim, pretoze takito programatori zvycajne povazuju nacitanie suboru za "nejaku instrukciu" a tomu aj zodpoveda pocet iteracii :)

Jenže použitelnost jazyka stojí a padá s kvalitou STANDARDNÍCH knihoven. Standardní knihovny (či spíše jejich specifikace) jsou de facto součástí jazyka. Nejde o "nějaké" knihovny napsané Frantou od vedle. Mám C++ hrozně rád, ale tady má jedno velké mínus. Standardizace knihoven pro C++ skončila někde na úrovni STL. Je velká ostuda, že pro práci s časem musíte v C++ volat Céčkové funkce, neexistuje standardní třída pro reprezentaci času. A takových věcí je spousta. Standardizace C++ je velice konzervativní a zkostnatělý proces. Přitom inspirací je spousta, třeba vynikající projekt Boost.
Tady má Java obrovský náskok - existují specifikace a implementace standardních knihoven pro prácí snad úplně se vším, nebo se alespoň připravují do dalších verzí.

Zrovna boost ma silenou praci s casem. Sice je to pry silna knihovna, ale hodne silena pro ty, co ji potrebuji jednou za cas :-|

jinak by nepsal, ze jde o "truc" podnik lidi, protoze nemaji podporu MS a neexistuje oficialni port... jde samozrejme o vec podporovanou ne -li primo iniciovanou MS

a je to jak s javou, pri priprave stroje pro deployment se proste nainstaluje potrebna verze runtime. a jestli je v default instalaci je uplne jedno

jen mi unika logika tvorby distribuci, dovolim si tvrdit, ze zahrnout mono je zajmu RH, radeji nez zahrnovat 1000 telnet klientu, 500 text editor, 700 grafickych editoru apod

maji tedy nazory urazenych deti, nebo zpatecniku - a ono vlastne je to obecny problem linuxu

pozrite sa, kto sa k tomu od rh vyjadruje - sef marketingu.
z toho vyplyva, ze ide o obchodny "problem", nie odborny.

jednoducho rh investoval do jbossa (java) a nema zaujem pomahat s rozvojom konkurencnej platformy (.net).

az to bude nevyhnutne (uzivatelia povedia "radsej si kupime suse, maju podporu mono") tak mono samozrejme zaradi.

tvůj názor se asi nejvíc přibližuje pravdě.
Jakoby RH ústy šéfa marketingu říkal:My jsem se nezašpinili IP MSoftu.
To souvisí s prohlášením RH , že veškeré problémy s IP MS jdou jen problém RH a ne zákazníku RH.

Nemylim-li se, tak Microsoft vydal .NET jako ISO normu a kazdy si ji muze koupit a funkce podle ni implementovat. Co mam zpravy, tak to vyvojari udelali a legalne tuto normu ziskali. Nevidim tedy zadnou moznost ze strany M$ vyvozovat jakoukoliv pravni odpovednost od osob co Mono vyvijeji natoz obycejnych uzivatelu.

No ona se nějaká cesta vždy najde :). A k vyhrožování se lži hodí stejně dobře jako nějaká ta pravda. Microsoft je v produkci překážek vcelku zdatný :).

Otazka je, ci je ISO normou aj .NET 2.0 a 3.0. a keby aj boli, MS si vyhradzuje pravo kedykolvek .NET uzavriet.

ISO norma, je standard, vydany International Standard Organization. Co je a co neni ISO norma, o tom rozhoduje ISO, a rozhodne ne Microsoft. Asi mate mozek vymyty MS-propagandou...

Tak dobre jeste jednou a pro neznale podrobne. Aby bylo neco vydana jakakoliv norma jako ISO musi autor teto normy o toto pozadat. Nasledne probehne rizeni, ktere v tomto pripade bylo uspesne a na navrh M$ byl uznan .NET jako ISO norma. Jestli ja mam vymyty mozek tak vy jste zase linuxove vymyty.

Ne. Ze byl .NET schvalen jako ISO norma je uplne neco jineho nez: "MS schvalil .NET jako normu. Tahle veta je dost zavadejici.... proto taky ten vyraz o vymyvani mozku... On se totiz MS snazi tvarit jako svetova norma pro pocitace.....
Pokud jste se jen spatne vyjadril, hluboce se vam omlouvam.

Nechci slovickarit, ale v momente, co pozadal o zarazeni do ISO schvalovaciho procesu, se rozhodl pro normalizaci zkracene normu.

Ja se jenom lekl, ze rikate: "Microsoft udelal normu".. coz by byla samozrejme blbost.... uz jsem to pochopil.

Celý problém je v patentech. Pokud je na nějakou důležitou část .NETu patent (od způsobu práce s bytecodém, přes JIT až po požadované chování knihoven), pak je ISO norma na nic.

A to je to čeho se všichni bojí ...

A to se prave mylis. Tim, ze tu normu prodava, tak prodava i toto sve intelektualni vlastnictvi k pouziti opravnenou osobou, kterou je prave kupujici.

Nejaka reference na podporu tohoto tvrzeni by nebyla? Me totiz prijde jako nepravdive. Jednak samo o sobe a druhak jako reakce na problem s patenty.

Nie celkom: IP sa nepredava, ale licencuje. V licencnom ujednani je sposob nakladania s IP obmedzeny. V prvom rade nie je dovolene zverejnenie a to vylucuje open source implementaciu takto licencovanej technologie.

Myslím že máte mylnou představu... Vydání jako ISO standard je IMHO formální specifikace něčeho de jure a s pozdějšímí patentovými nároky to nemá co dělat. Typický příklad ISO MPEG-4. Vydaný ISO standard, ale v právním (IP komerčně-licenčním) absurdistánu jako USA je vám to houby platné, protože na kdejaký kousek algoritmu má někdo patent. Minimálně musíte zaplatit organizaci MPEG LA http://www.mpegla.com která sdružuje většinu vlastníků patentů použitých v MPEG kompresních algoritmech. Několikrát se ale už stalo, že nějaký nový "vyděrač" který nestojí o členství v MPEG LA a rozumné licencování, vymáhal pomocí soudního sporu nechutné peníze.

Na druhou stranu, ISO ma podminku, ze pokud je neco ISO norma, tak to nesmi byt zatizeno zadnymi dalsimi poplatky.
Tzn. zaplatite konstantni castku za ISO normu a nikdo uz po vas nesmi chtit dalsi penize. Tohle se alespon psalo cca pred dvema roky, kdyz se resilo jak to bude dal s JPEG a MPEG-4 protoze si nejaka firma cinila patentove naroky na DCT nebo nejaky jiny bezny princip, ktery se pouziva v kompresnich algoritmech.

presne tak, o tom celou dobu mluvim

Vím, že .NET -- vlastně pouze C# a CLI -- je "standardizováno" ECMA. A koukám, oni už to protlačili i do ISO. Ale pořád pouze C# a CLI. Takže si troufám odhadovat, že těmito standardy zdaleka není pokryta celá platforma .NET. Ví o tom někdo něco bližšího?

presne tak. norma nepokryva treba tak dulezite casti jako ASP.NET a kolik procent knihoven ma standard si netroufnu tvrdit. kazdopadne tady muze byt zakopane jadro pudla.

Ony jsou standardizovány jen některé části platformy .NET, to je to. Aby byly přenositelné aplikace z windows, musí být implementováno celé .NET, třeba i win forms, které standardizovány nejsou. A to je ten kámen úrazu.

C++ je taky ISO norma (a nevydal ji Microsoft).

.NET obsahuje spoustu patentů, takže si málokterá firma může dovolit implementovat .NET; a pokud si to dovolí, tak většinou hrozně neefektivně (aby obešla právě ty patenty). God bless America. (Tohle se sice netýká EU, ale vyvíjet podobný software, který nelze použít v USA, se prostě nevyplatí)

Pokud je .NET 1 ISO norma, pak .NET 2 tuto normu porušuje (protože není kompatibilní), tudíž je v EU nelegální (v EU není legální používat implementace vycházející z ISO standardů, ale tyto standardy nedodržující). Další důvod pro pokutování Microsoftu.

Nejlepší jazyk je PHP. Perl a Python jsou hodně za ním a Java a C++ jsou zhruba na stejný úrovni.

Ale no tak... vsichni dobre vedi, ze nejlepsim jazykem vubec je Karel. Bohuzel nevim o zadne open source implementaci :'(

http://xkarel.sourceforge.net/cz/

Presne tak najlepší jazyk je PHP teda okrem Visual Basicu samozrejme.

no tak, nekasli sa a daj sem este jeden for :)

Myslis PHP bez objektu, PHP s objekty podle verze 3, PHP s objekty podle verze 4, PHP s objekty podle verze 5 nebo PHP s objekty podle verze 6 ?

Otázka je jak je to s pythonem. Zda je to náhrada, protože další verze python 3000 má být nekompatibilní se současným pythonem a to rozhodně není znak serióznosti a něčeho, co by jej opravňovalo pro podniková a vážná řešení.

Ač nemám příliš v lásce Javu, zdá se mi, že tam takové kejkle nejsou, tedy že jak Java, tak byte kód je standardizován a nepamatuji se, že by někdo musel rozsáhle přepisovat zdrojáky jen proto, že vyšla další verze Javy. Ale možná se mýlím.

Ale Python deklaruje, že nezachová zpětnou kompatibilitu a to je podle mě i signál do budoucna, že mu nelze svěřit větší věci, protože nechrání investice do existujícího kódu.

Píšu to proto, že sám jsem hodně napsal v Pythonu, je to skvělý jazyk, ale přemýšlím o jiném právě z tohoto důvodu. Seriózní jazyk by měl věci měnit jen v odůvodněných případech a jinak raději používat zaklínací formule obsoleted, deprecated a warning, ale dál se moc neodvažovat.

Python 3000 není další verze Pythonu. O Pythonu 3000 se mluví již léta. Vždycky když vývojáři dojdou na to, že něco implementovali blbě, že zvolili nepříliš šťastnou koncepci, ale nemohou to opravit právě z důvodu zachování zpětné kompatibility, tak řeknou, že to opraví/odstraní ve verzi 3000, tedy Pythonu 3.0, který nebude zpětně kompatibilní, jak napovídá změna major verze. Tyto záležitosti se evidují a možná jednou Python 3.0 opravdu vznikne, ale zatím se na něm nedělá a vyvíjí se už po řadu let řada 2.x. I kdyby k tomu jednou došlo, nebude tu žádný problém paralelně provozovat verzi 2.x a 3.x současně, jako se dodnes může provozovat současně řada 1.x a 2.x, má-li někdo tu potřebu.

není problém provozovat verzi 2.x a 3.x současně? jak dlouho to nebude problém? a budou všichni autoři knihoven pro python udržovat verze pro 2.x a 3.x? už teď je problém, protože verze pro 2.4 nechodí třeba pro 2.5. takže opravdu to nebude problém? opravdu není problém provozovat 1.x verzi pythonu?

blbě se navrhne vždycky něco, ale to není důvod k porušení zpětné kompatiblity, ale k tomu označit danou konstrukci jako deprecated, ale je potřeba jí tam nechat pro starší kód. navíc změny navrhované v pythonu a porušující zpětnou kompatiblitu jsou takové ptákoviny, že je těžko obhájíte jinak, než rozmarem

reálně to nevídím tak bez problému jak uvádíte

Provozovat soucasne python 2.x a 3.x je problem, protoze python 3.x neexistuje, to da rozum. Provozovat soucasne 2.x a 1.x problem skutecne neni, v dobe vzniku pythonu 2.0 to byl na linuxu standardni stav.

Presne tak to Python dela, zastarale veci oznacuj jako deprecated a ponechva je pro zpetnou kompatibilitu po nekolik let. Pokud by mel snad jedno vzniknout nekomatibilni python, tak proc to nevzit od podlahy? Je naopak v poradku, ze se pamatuje i na banality, neni to rozmar, ale dukladnost. Tyto banality nejsou duvodem pro vytvoreni nekompatibilni verze. Zadny takovy duvod dnes neexistuje. Kdyby se objevil, svezou se s tim i ostatni zmeny. Divim se, ze mate tak velky problem pochopit tak jednoduchou vec. Ostatne, kdyz se takovy duvod objevil u C a vzniklo C++, tak to taky nikomu nevadilo, C se klidne udrzovalo zakonzervovanw pri zivote dal a rozvijelo se C++.

Ten oddůvodněný případ mezi 1.x a 2.x bylo objevení se UNICODE a jeho podpora jako nového datového typu.

A mimochodem, Python 2.0 vyšel v roce 2000, od toho Python 3000 :-). Jestli někdy dojde ke vzniku Pythonu 3.0, bude to nepochybně dobře oddůvodněné. Vývojáři Pythonu na zpětnou kompatibilitu řádně dbají a na různé změny dlouhodobě (po několik verzí pythonu) upozorňují (deprecate warning).

vývojáři pythonu dbají na zpětnou kompatibilitu, ale veřejně deklarují, že nebude zachována. to je celé. prostě všechny jazyky, které dlouhodobě drží na špici si nikdy neodvážily hrubě porušit zpětnou kompatibilitu. zkuste v javě deklarovat, že další verze javy nebude mít kompatibilní syntaxi s předchozí javou a všichni vás vyštípou. zkuste prohlásit, že bash v příští verzi nebude kompatibilní se současnou verzí a bude nutné všechny shellovské skripty přepsat a budete si muset připravit ústupovou cestu a raději chodit kanálama. zkuste prosadit, že příští verze jazyka C nebude umět přeložit milióny existujících programů v C a nikdo vás nebude brát vážně. totéž pro c++, adu, fortran, cobol, ... prostě všechny jazyky, ve kterých se naprogramovaly obrovské projekty, a ve kterých se nikdo nebojí dělat si NIKDY nedovolí ani POMYSLET NA TO, že by některá další verze nebyla zpětně kompatibilní, natož to veřejně prohlásit jako GvR. tohle je rozdíl mezi seriózním jazykem a ostatními. jazyk, který nezajistí možnost v jakékoli další verzi přeložit a používat již existující kód deklaruje, že nechrání investice do něj vložené.

Tak zrovna Java zrušila (kromě jiných kotrmelců) "private protected" metody a co se stalo? Nic. Je možné v nejnovější specifikaci jazyka C používat K&R deklaraci parametrů? Pokud ne, vadí to někomu, pokud ano, používá to dneska někdo?

K čemu tohle plašení? Až (jestli) se vývojáři Pythonu rozhoupou a začnou pracovat na projektu "Python 3000", určitě jedna z věcí, kterou budou řešit jako první, bude jak zajistit plynulý a pokud možno bezbolestný přechod stávajících aplikací na Python 3000.

Fáze 1: implementovat do stávající verze vlastnosti, které ve verzi "3000" budou klíčové a potřebné k přechodu

Fáze 2: označit jako zastaralé ty vlastnosti, které z verze "3000" budou vyloučeny

Fáze 3: nabídnout nástroj, který provede automatický převod méně komplikovaných konstrukcí a označí problematické pasáže, které by neměl být problém v rozumně navržené aplikaci přepsat.

Fáze 4: vypustit Python 3000 pro nadšence

Fáze 5: označit Python 3000 za hlavní vývojovou platformu

Tento přechod může klidně trvat hodně let (kde máme Perl 6?). Za tu dobu hromada projektů morálně zastará. Nechci se bavit o tom, jestli všechny změny v Pythonu 3000 (který ještě nikdo neviděl, ale za sebe říkám: pokud je něco v Pythonu skutečně špatné, přepište to.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ...

vývojáři pythonu 3000 už vygenerovali desítky dokumentů jak to bude a prezentovali, že nebude zajištěna kompatibilita

ad fáze 3: neznám žádný nástroj, který by v praxi 100% fungoval bez lidského zásahu. i Vy píšete, že pouze označí, nikoli přegeneruje. až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd.. - to je báječné, podnikoví ekonomové se mohou rozplynout blahem a všichni budou š%tastni děkovat GvR :-(

ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat. z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný. už jen to, že se o tom vážně uvažuje, a že kompatibilitu nikdo moc neřeší je důležitý. chytrý poslouchá teď, hloupý pak řeší až nastanou problémy.

OK. Co sa tyka spatnej kompatibility je C-ko nekorunovanym kralom, ale vsetky ostatne jazyky kompatibilitu z casu na cas neriesia.

VŠECHNY jazyky, které jsou stálicemi jí řeší - C, C++, Ada, Fortran, Cobol, ... tohle všechno je stále zpětně kompatibliní i desítky let u starších jazyků

V kompatibilitě C u C99 rozbili dost významnou věc --- definovali, že kompilátor může přehazovat přístupy na pointery různých typů a rozbili tím dost programů.

(problém je tu mnohem zákeřnější než se změněnou syntaxí --- tady ne, že se to nezkompiluje, ale zkompiluje se to a pak to dělá něco jiného v závisloti na verzi kompilátoru nebo optimalizacích).

... a původní K&R C tuším dovolovalo sčítat pointery nebo odčítat pointery různých typů (nevím, co mělo být výsledek; narazil jsem na to při pokusu o kompilaci nějakých programů z originálního unixu).

Další věc, co odstranili, byl soubor <varargs.h>, kterým se dělaly funkce s proměnným počtem argumentů s K&R prototypy. Odstranili to nejspíš z důvodu, že je to na architekturách, co mají argumenty v registech, neimplementovatelné.

Nějak jste zapoměl na Javu? Nakonec .NET 1.0 rovněž není kompatibilní s 2.0, některé věci je nutno přepsat a tak dále. Taky historie VB od Microsoftu je velmi pohnutá. A co ASP? Nebo třeba Access, tam se taky musely programy přepisovat. A co na to podnikoví ekonomové?

Vývojáři Pythonu na to své uživatele připravují s předstihem spousty let (dnes minimálně pěti, aniž by se na Pythonu 3000 ještě začalo pracovat, či se jen vědělo, zda vůbec vznikne. Jen se shromažďují požadavky pro případ vzniku nekompatibilní verze).

Jak už jsem napsal, žádné přepisování není třeba, staré aplikace poběží stále na interpretu 2.x.

To je FUD, zpětnou kompatibilitou se vývojáři Pythonu zabývají mimořádně poctivě. Už řadu let dopředu dávají najevo, co by se mohlo změnit, kdyby mělo k nějaké takové verzi dojít. Ostatní vás z čista jána postaví před hotovou věc. U Pythonu víte již dnes co je nemoderní a co možná za několik let nebude podporováno, pokud z uddůvodněných případů ke vzniku takové verze dojde, přičemž staré aplikace bude moci pořád provozovat ve staré verzi, upgrade na 3000 nebude povinný. Chytrý člověk není hloupý a tmář jako vy :-).

Odpověď viz jiný příspěvek. VB, ASP a nejmě Access řešit nebudu. Protože tohle je jiný případ. Nemluvím o tom, že vše je standartizované.

Žádné přepisování ZATÍM není třeba, ale deklaruje se, že vývojáři připustí, že to BUDE TŘEBA.

To, že vývojáři Pythonu dávají najevo, že to bude nekompatibilní je hezká věc, ale důležitý je i fakt, že nekompatibilitu vůbec připustí bez závažného důvodu. A závažný důvod jen takový, že to nelze ani při 100% snaze udělat jinak. Stará verze nebude existovat na věky věků a nikdo vám ani interpretr, ani tisíce knihoven nebude udržovat funkční pro starou verzi, postupně to začne být nepoužitelné. Díky za toho tmáře, myslím si, že každý člověk by měl o Pythonu vědět, že když v něm udělá větší projekt, že bude mít potencionálně tyto potíže.

A neslo by to udelat nejak tak aby Python 2000 program mohl volat Python 3000 knihovnu ?

V zásadě je to podle mě možné bez větších problémů - prostě se přeloží moduly z Python 2.x a Pythonu 3000 do společného bytecode a tam už ty rozdíly nemusí být podstatné. Pokud například pro celočíselné dělení bude v Pythonu 3000 (a neřešme teď, jestli nějaký bude nebo ne), přeloží se 3 / 2 v Pythonu 2.x do stejné instrukce (např. INTDIV) jako 3 // 2 v Pythonu 3000. Lambda může být nahražena normální funkcí (na úrovni překladače), range() ze stávajícího Pythonu se dá převést na list(range()). Teď mě ale napadá, že by mohl být problém s klasickými třídami, které mají poněkud jiné chování než třídy nového stylu - tahle rozpolcenost by podle mě z Pythonu měla zmizet každopádně.

Pak je samozřejmě možné zachovat bytecode a interní podporu klasických tříd (a možná i jiných vlastností, pokud by bylo třeba) v novém interpreteru dál, akorát by překlad do .pyc nebo .pyo musel být dělán samostatným překladačem. Takto by bylo možné zachovat možnost současného běhu 2.x a 3000 modulů libovolnou dobu. Otázkou je, jestli by se to vyplatilo. Vzpomeňme si na nedávný pokřik ohledně @ syntaxe pro dekorátory, která udělala problémy vývojářům projektů ipython a leo. Bylo to trochu nepříjemné, ale nic strašného se nestalo.

To zalezi na tom, z jakeho duvodu by treti rada vznikla, je spis pravdepodobnejsi ze ne, protoze u pythonu se moduly pisi pro konkretni verzi. Ono je to logicke, pokud mdul vyuziva novych vlastnosti, tezko pujde pouzit se starym interpretem, ktery je neumi.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ... Nevím, nezjišťoval jsem to. Tvrdím ale, že kdyby od června 2008 všechny najednou přestaly tyhle metody překládat, naprosto nic hrozného by se nestalo. až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd.. A kolik programů s pár milióny řádky v Pythonu máte Vy? Pro zajímavost, v Zope 2.10 je něco přes půl miliónu řádků v Pythonu. ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat. To snad nikdo netvrdil, že se problémem nebude vážně zabývat. z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný. Kdo ochránil investice vývojářů, kterým nechodí aplikace pod Windows Vista? Kdo ochrání Vaše investice, až vyjdou nové Windows a Microsoft se rozhodne nějaké rozhraní přestat podporovat? Kdo ochránil investice vývojářů webu, pokud zjistili, že IE7 nevykresluje dobře stránky? Kdo ochrání Vaše investice do kódu v Javě, pokud zkrachuje Sun? O jakých zárukách se bavíme? Jaké REÁLNÉ problémy se řeší? chytrý poslouchá teď, hloupý pak řeší až nastanou problémy. Takovýto typ "argumentace" neberu.

až by přestal kompilátor C překládat K&R metody, pak by mnoho kódu nešlo přeložit. vy si myslíte, že by se nic hrozného nestalo, ale naštěstí zodpovědní lidé vidí reálněji, než vy.

neznám programy s milióny řádky v pythonu, protože takové vznikají pouze v seriózních jazycích, které nemění zpětnou kompatibilitu. v jiných je to neúnosné.

ohledně Windows vista - které KONKRÉTNÍ aplikace napsané přesně podle dokumentace Microsoftu nebude fungovat? pokud jsou programátoři prasata a používají nedokumentovaná rozhraní, nebo rozhraní pro drivery, které jsou proměnlivé, pak samozřejmě bude problém. příklad takových prasáckých aplikací je třeba cygwin, který bez skrupulí používá nedokumentové API Windows. jaké KONKRÉTNÍ rozhraní nebude podporovat?

co se týká IE7, žádný browser nezaručuje stejné vykreslování stránek, viz W3C standardy.

až zkrachuje Sun, tak Java stále bude žít. jaké KONKRÉTNÍ problémy v investicích do vašeho kódu nastanou, pokud zkrachuje Sun?

až by přestal kompilátor C překládat K&R metody, pak by mnoho kódu nešlo přeložit.

Veškerý tento kód by se dal poměrně snadno převést do přeložitelné podoby. Velice jednoduše by se dalo ověřit, že přeložený program bude funkčně ekvivalentní.

vy si myslíte, že by se nic hrozného nestalo, ale naštěstí zodpovědní lidé vidí reálněji, než vy.

Mohl byste už konečně zanechat toho bullyingu?! Nestačilo Vám napsat jednou, že na takovýto způsob argumentace nejsem zvědavý?!

které KONKRÉTNÍ aplikace napsané přesně podle dokumentace Microsoftu nebude fungovat?

Například některé aplikace od Microsoftu přestaly fungovat. To mi úplně stačí.

co se týká IE7, žádný browser nezaručuje stejné vykreslování stránek, viz W3C standardy.

Takže, jinými slovy, pro vývojáře aplikací s webovým rozhraním neexistuje žádná ochrana jejich investic. To jsem chtěl říci, díky, že jste to uznal.

jaké KONKRÉTNÍ rozhraní nebude podporovat?

Nevím, za ty roky jich Microsoft vytvořil desítky. Předpokládáte, že tady všechna budou za 20 let?

až zkrachuje Sun, tak Java stále bude žít.

Jak to víte? Co když všichni za čas přejdou na .NET, Mono nebo na něco docela jiného? Kde máte tu záruku?

"Veškerý tento kód by se dal poměrně snadno převést do přeložitelné podoby. Velice jednoduše by se dalo ověřit, že přeložený program bude funkčně ekvivalentní."

Dal, ale přesto jak vidíte se to neděje, neboť usnadnění kompatibility a její zachování je pro někoho víc, než prázdný pojem. Výrobci kompilátorů chápou, že je to důležité.

"Mohl byste už konečně zanechat toho bullyingu?! Nestačilo Vám napsat jednou, že na takovýto způsob argumentace nejsem zvědavý?!"

Mě nebudete poroučet na co jste zvědavý, to si prosím odpusťte. Děkuji. Pokud Vám vadím, ignorujte mě.

"Například některé aplikace od Microsoftu přestaly fungovat. To mi úplně stačí."

Pokud existuje milión aplikací a třeba dvě přestanou fungovat, je to velmi kompatibilní věc.

"Takže, jinými slovy, pro vývojáře aplikací s webovým rozhraním neexistuje žádná ochrana jejich investic. To jsem chtěl říci, díky, že jste to uznal."

Pokud vývojáři aplikací očekávají víc, než je ve standardech je to naprosto v pořádku. Pak se nejedná o porušení kompatibility a o porušení ochrany investic nemůže být ani řeči.

"Nevím, za ty roky jich Microsoft vytvořil desítky. Předpokládáte, že tady všechna budou za 20 let?"

Nemáte argumenty? Nemůžete na nic konkrétního ukázat? Takže jen planě kladete písmena.

"Jak to víte? Co když všichni za čas přejdou na .NET, Mono nebo na něco docela jiného? Kde máte tu záruku?"

Pak stále budou existovat kompilátory stejně jako dodnes exitují třeba kompilátory COBOLu, nebo FORTRANu, nebo PL/I, nebo dalších jazyků, protože je potřeba ochránit investice projektů, kterých je obrovské množství. Stačí?

Jinak jediná Vaše 100% záruka je, že umřete. Cokoli jiného je jenom na 99,999% a mě 99,999% záruka ochrany investic přijde dostatečná.

> Dal, ale přesto jak vidíte se to neděje, neboť usnadnění kompatibility a její zachování je pro někoho víc, než prázdný pojem. Výrobci kompilátorů chápou, že je to důležité.

Výrobci kompilátorů Vás chápou. Já vlastně taky.

> Mě nebudete poroučet na co jste zvědavý, to si prosím odpusťte. Děkuji. Pokud Vám vadím, ignorujte mě.

OK, beru na vědomí, že se úmyslně chováte jako neotesaný hulvát a totéž od nynějška očekáváte od jiných.

> Pokud vývojáři aplikací očekávají víc, než je ve standardech je to naprosto v pořádku. Pak se nejedná o porušení kompatibility a o porušení ochrany investic nemůže být ani řeči.

Protože žádná ochrana neexistuje. Jak mazané.

> Nemáte argumenty? Nemůžete na nic konkrétního ukázat? Takže jen planě kladete písmena.

Samozřejmě. A nejenom já v tomhle threadu.

> Pak stále budou existovat kompilátory stejně jako dodnes exitují třeba kompilátory COBOLu, nebo FORTRANu, nebo PL/I, nebo dalších jazyků, protože je potřeba ochránit investice projektů, kterých je obrovské množství. Stačí?

Samozřejmě. A protože je Python open source (a interpreter je napsaný v C, které je věčné!), tak si můžete chránit svoje investice s interpreterem ve verzi 2.X, jak dlouho budete chtít. A s poněkud reálnějším využitím, než má kompilátor PL/I.

> Jinak jediná Vaše 100% záruka je, že umřete. Cokoli jiného je jenom na 99,999% a mě 99,999% záruka ochrany investic přijde dostatečná.

Kdo Vás naučil takhle hezky počítat? Váš přednášející ze statistiky?

"OK, beru na vědomí, že se úmyslně chováte jako neotesaný hulvát a totéž od nynějška očekáváte od jiných."

Já Vám jenom jemně naznačil, že nebudu skákat jak Vy pískáte. Pokud si za svým názorem stojím, tak ho hájím. Pokud v tom vidíte neotesané hulvátství prosím, vyvracet Vám to nebudu.

"Protože žádná ochrana neexistuje. Jak mazané."

Pokud neexistuje standard, neexistuje ochrana. To je normální.

"Samozřejmě. A nejenom já v tomhle threadu."

Uf, takže nic konkrétního nemáte. Ok. Na rozdíl od jiných v tomto threadu, kteří diskutují seriózně a konkrétně, když si o to říkáte.

"Samozřejmě. A protože je Python open source (a interpreter je napsaný v C, které je věčné!), tak si můžete chránit svoje investice s interpreterem ve verzi 2.X, jak dlouho budete chtít. A s poněkud reálnějším využitím, než má kompilátor PL/I."

Nemůžu, protože možná je interpretr v C, ale knihovny, které je potřeba také používat Vám tuto věčnost nezaručují. Stejně tak jako návaznosti na další věci. Kompilátor PL/I je možná málo používaný, ale stále existuje, protože je potřeba chránit investice. Python je sice open source, ale to je nepodstatné, podstatné je, že prostě existuje forma standardu ve formě PEP a ta by se měla dodržovat. Jinak Pyton není open source v sw smyslu, protože Python není program, ale jazyk. Open source může být konkrétní implementace jazyka. To je stejné jako byste řekl, že IP protokol je open source.

"Kdo Vás naučil takhle hezky počítat? Váš přednášející ze statistiky?"

Dojdou-li mi argumenty, pokusím se zesměšnit oponenta alespoň emotivně. Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

> Já Vám jenom jemně naznačil, že nebudu skákat jak Vy pískáte. Pokud si za svým názorem stojím, tak ho hájím.

To je v pořádku. Mně se nelíbil a nelíbí ten způsob, jakým ho hájíte.

> Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

> Nemůžu, protože možná je interpretr v C, ale knihovny, které je potřeba také používat Vám tuto věčnost nezaručují.

Knihovny jsou rovněž psané v C, resp. v C++, ne-li rovnou v Pythonu. Pořád tam nevidím slabé místo.

> Uf, takže nic konkrétního nemáte. Ok. Na rozdíl od jiných v tomto threadu, kteří diskutují seriózně a konkrétně, když si o to říkáte.

:-)

> Python je sice open source, ale to je nepodstatné, podstatné je, že prostě existuje forma standardu ve formě PEP a ta by se měla dodržovat.

PEP není standard. To je jenom návrh, jak v nějaké oblasti Python posunout kupředu. Jediné, co je podle mě směrodatné, je Language Reference a Library Reference. A platí pouze pro danou verzi překladače.

> Python není program, ale jazyk.

Napsal jsem "Python" a myslel jsem "CPython", který umožňuje spouštět programy psané v jazyce Python. To se stává.

> Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

Konkrétně se mi nelíbí lehkovážné žonglování s čísly a procenty, byť možná v rámci nadsázky. Protože kdybyste připustil, že 99,999% možná není ve skutečnosti 99,999%, ale ze statistického hlediska výrazně méně, v tu ránu bychom se mohli dostat k tomu, že je třeba stanovit hladinu významnosti pro ověření Vaší hypotézy a vůbec bychom se museli z říše dojmů posunout k nějaké použitelné metodologii odhadu rizik. Což by bylo pro mě velice zajímavé, ale obávám se, že z tohoto threadu bude jenom to jalové kladení písmen.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ...

Nevím, nezjišťoval jsem to. Tvrdím ale, že kdyby od června 2008 všechny najednou přestaly tyhle metody překládat, naprosto nic hrozného by se nestalo.

až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd..

A kolik programů s pár milióny řádky v Pythonu máte Vy? Pro zajímavost, v Zope 2.10 je něco přes půl miliónu řádků v Pythonu.

ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat.

To snad nikdo netvrdil, že se problémem nebude vážně zabývat.

z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný.

Kdo ochránil investice vývojářů, kterým nechodí aplikace pod Windows Vista? Kdo ochrání Vaše investice, až vyjdou nové Windows a Microsoft se rozhodne nějaké rozhraní přestat podporovat? Kdo ochránil investice vývojářů webu, pokud zjistili, že IE7 nevykresluje dobře stránky? Kdo ochrání Vaše investice do kódu v Javě, pokud zkrachuje Sun? O jakých zárukách se bavíme? Jaké REÁLNÉ problémy se řeší?

chytrý poslouchá teď, hloupý pak řeší až nastanou problémy.

Takovýto typ "argumentace" se mi nelíbí.

Nesuhlasim. Kazdy jazyk z casu na cas porusi spatnu kompatibilitu. Java pri verzii 1.2 a .NET pri 2.0.

Alebo, vezmite si napriklad C++ - nedbajuc na spatnu kompatibiltu sa menil nielen standard ale aj kompilatory. Dobre sa pamatam na bolestny prechod z Visual C++ 6.0 na Visual C++ 2005. Tu je obzvlast pikantne, ze mnohe POSIX funkcie boli oznacene ako osolete. Podobne nestandarny bol prechod z g++ 2.9.5 -> 3.x alebo g++ 3.x -> 4.x. C++ skratka bolo a bude nocnou morou spravcov projektov.

Osobne si myslim ze Python je seriozna platforma a preto aj Python 3000 je dnes len utopia. Pre odoberanie funkciii sa schvalila velmi konzervativna politika a zasadne zmeny v jazyku tiez nie su na programe dna. Napri. nikto, kto ma zdravy rozum, si dnes nevie predstavit zmenu operatora / z celociselneho delenia na realne. Skratka, python dozrel.

Porušit zpětnou kompatibilitu ve verzi 1.2 se dá celkem pochopit a tolerovat. Mnoho jazyků jí poruší při přechodu z verze 1 do verze 2, to je takový folklór. Ale pak by to mělo končit.

C++ nic neporušilo. standard C++ je stále jeden, platný a porušovat se nikdy nebude ani se to neplánuje. předtím neexistoval standard C++, ani psaný, ani nepsaný, tudíž nebylo co porušovat. takže noční můry se nekonají.

python není seriózní platforma, protože je příliš "volná". seriózní platforma to bude, až každému vývojáři bude jasné, že byť jen uvažovat o porušení kompatiblity je hloupost, a nebo aspoň velmi vážná věc, která musí mít sakra dobré důvody. a až když někdo navrhne nekompatibilitu, druzí ho samozřejmě a bez přemýlšení seřvou. a taky až bude existovat přenositelný binární formát tohoto jazyka, který umožní přenositelnost aplikací i bez zdrojových kódů. java tohle umožňuje i napříč verzemi.

Ze znamkou serioznosti platformy ma byt skutecnost, ze nekdo nekoho _bez premysleni_ serve, si muze myslet jen znamy urvanec Miloslav Ponkrac, ktery tu rve bez premysleni.

Dekuji za vas nazor, ze pro vas Python neni seriozni platformou, pro me neni seriozni vas nazor bez premysleni. Osobne jsem rad, ze vyvojari Pythonu premysli, to povazuji za mnohem lepsi ochranu investic.

Pro ostatni. Zadny Python 3000 neexistuje ani se nevyviji. Tvrzeni ze pristi verze Pythonu bude nekompatibilni je lez. Python je jazyk zivy a stale se vyviji, takze srovnavat ho s mrtvou Adou nebo C je nesmyslne. K drobnym upravam kodu je nutno pristupovat i dnes. Napriklad existuje nekolikalety plan postupneho prejiti z textovych vyjimek na objektove a pritom uz pred radou let platilo pravidlo, ze ty textove by se nemely pozivat. V praxi to nedela problemy a jak bylo uvedeno, kdyby bylo nejhur, porad je tu moznost pouzivat interpretr s podporou starsi verze jazyka.

Petr Mach už nemá argumenty a tak se tu zoufale schyluje k osobním útokům.

Python 3000 se připravuje a plánuje a deklaruje se, že bude nekompatibilní. Pokud lžu, pak lžou i ofociální stránky pythonu, stejně jako třeba anglická wikipedie. Možnost staršího interpretru odpadne časem, protože se nebude až moc vyvíjet.

standard C++ je stále jeden, platný a porušovat se nikdy nebude ani se to neplánuje.

Sorry, ale nemate o tom ani paru.

ale rozumím, programuji v C++ od roku 1991. vím, že se to měnilo jako ponožky, ale standard vznikl v roce 1999 a ani příští standard, který se připravuje nehodlá nijak měnit zpětnou kompatiblitu

A kdyby někdo Python 3000 přejmenoval třeba na ".ORG platform framework", tak budete s kompatibilitou současného Pythonu spokojený?

Spíš mi to přijde jako takové manažerské argumenty, že v tom neprogramujete, ale opíráte se o nějaká prohlášení někoho. Kdyby ta prohlášení byla formulována jinak, tak se nad tím ani nezastavíte.

Zkuste si udělat nekompatibilní Javu, nebo Adu a nazvěte to Javou, nebo Adou a můžete se připravit na soudní proces. Pak bych vám doporučil mimosoudní vyrovnání, jinak přijdete i o kaťata. Právě z těchto důvodů jsou tyhle jazyky používány tam, kde o něco opravdu jde.

Pokud se Python bude stále vyvíjet kompatibilně a nikdo si udělá něco pod jiným jménem už to není Python a je to jedno.

V Pythonu jsem toho napsal moc a moc a právě proto mě to štve.

Vývojáři Pythonu udržují seznam požadavků na změny, které by bylo vhodné provést, ale nemohou kvůli zpětné kompatibilitě. Nikdo neprohlásil, že příští verze Pythonu bude nekompatibilní se stávajícími. Šíříte poplašnou zprávu.

I kdyby Jednou za 10, 50 nebo 993 let Python 3000 vzniknul, pořád bude možno stávající aplikace provozovat na Pythonu 2.x, protože mu nečiní problémy paralelního chodu více verzí současně, tudíž není potřeba nic předělávat, a o žádné ohrožení investic se nejedná, takže zklidněte hormony a nedělejte z komára velblouda.

Já doufám, že jednou Python 3000 vznikne a vyřeší se tak multiprocesorový běh interpretu a vylepší podpora multithreadů, což bez ztráty zpětné kompatibility (knihoven, nikoli kódu) není možné.

Ostatně, taková Windows Vista nebo IE7 jsou nekompatibilní až hrůza a co se děje? Přestanou podnikoví ekonomové Windows používat?

v tom případě šíří poplašnou zpávu i oficiální web pythonu, stejně jako třeba wikipedie. prosím vynadejte jim tam, jmenovitě GvR.

ne, nebude možné provozovat apliakce na python 2.x, protože vývoj 2.x bude upadat, až se stane nepoužitelným. mohu se zpetat, udržuje někdo stále aplikace pro Linux 1.0, nebo pro Windows 2.0? Udržuje se maximálně něco pro určitý počet let starého a pak šlus. opravdu si myslíte, že autoři každé z tisíců knihoven budou udržovat verzi pro všechny potenciální nekompatibilní verze pythonu?

jenže změny, které se navrhují jaksi neření multicosi, ale jen to, že GvR prohlašuje, že tato konstrukce musí zmizet, protože není dostatečně "pythonoská", nebo že se mu špatně implmentuje. pokud by mělo porušení zpětné kompatibility výrazný benefit jinde, pak se to možná dá omluvit, ale ono to v pythonu 3000 tak není!!!

Windows Vista je kompatibilní se slušnými, tj. standardně napsanými aplikacemi dokonce Windows 1.0 (tuším asi dvacet staré), nebo dokonce DOS. co je tam tak nekompatibilního?

Až Windows budou opravdu hrubě nekompatibilní, tak podnikoví ekonomové přestanou Windows využívat, na to se můžete spolehnout. A Microsoft to ví, na rozdíl od GvR. Proto každou nekompatibilitu, kterou je nucen zavést si tvrdě rozmyslí a pokud je, tak má pro ní sakra důvod. A pokud by zavedl nekompatibilitu, tak můžete měsíc slavit, protože Windows je poražen a je volná cesta Linuxu. Něco nejasného?

Odporujete si sám sobě.

Máte vaši aplikaci co funguje s pythonem 2, máte pro to knihovny co fungují. Ty knihovny jsou založené na neměnném rozhraní operačních systémů a neměnném C nebo na tom pythonu co máte, takže vám teoreticky budou fungovat navždy (nebo jsou podle vašeho vlastního názoru jejich programátoři prasata a pak nevím proč je používáte, to je čistě váš problém v takovém případě). Že vám nikdo nebude vydávat nové verze, to jednou taky přijde. Nicméně to co máte budete mít jednou provždy. Programátoři v PL/I asi taky nemají obrovský výběr všeho možného pro svůj programovací jazyk a těžko se mohou čemu divit, když používají exotický kus šrotu.

ale nebude. chcete říci, že stále budou pro python 2 rozhraní pro nové a nové verze databází, xml a dalšího? že i po deseti letech co skončí aktivní vývoj pythonu 2 bude k dispozici pro python 2 wrapper na aktuální verzi mysql řekněme verze 50, nebo na sqlite verze 40? nebo k pythonu 2 budete muset mít i deset let starou verzi databází? a to nemluvím o dalším. vývoj stejně učiní python 2 nepoužitelným pokud se jeho vývoj zastaví.

To je jak u blbych. Nikdo krome vas netvrdi, ze pristi verze pythonu bude nekompatibilni, proto poplasnou zpravu sirite vy.

Ad linux 1 a windows 2. a) Jestlize udrzovat zpetnou kompatibilitu za nutne nepovazuji vyvjari linuxu a Windows, roc by to meli delat vyvijari pythonu? b) Kde jste prisel k tomu, ze to vyvijari pythonu delat nebudou?

Ad python 3000. Tento python neexistuje ani se nevyviji, vas prispevek je proto nesmyslny a na hlavu postaveny.

Windows Vista neni kompatibilni ani s aplikacemi od Microsoftu pro Windows XP, a to je uz co rict.

Na rozdil od Pythonu jsou aplikace Microsoftu tezce nekompatibilni, viz windows, IE, .NET, VB, Access a rada dalsich a jak se microsoftu dari. Uzivatele zjevne pred kompatibilitou preferuji rychly vyvoj. Takze si o GvR neotirejte usta, ktery vyvoj zene kupredu, ale kompatibilitu drzi na uzde.