[python] Buducnost Pythonu: lambda, map, filter

[superman]

> Jde o to, že Python může k reduce a lambda nabídnout 
> alternativy, které nelze srovnávat s primitivností 
> podmíněného skoku. Ty alternativy mi připadají lepší
> než reduce/lambda.

Tady je problém jednak ten výraz "mi připadají lepší", tedy jde o
subjektivní názor a druhý problém je zpětná kompatibilita.

> Ten sadistický důvod se jmenuje zpětná kompatibilita. Začíná
> to u strojových instrukcí, přes C, C++ a vše, co se je snaží
> napodobovat. Strojové instrukce neznají typy ve smyslu
> vyššího programovacího jazyka. Nula je false, cokoliv jiného
> je true. Python kdysi boolovské hodnoty vůbec neznal.

Toto už jsem diskutoval v tom kontextu, že Python 3 stejně tuto
kompatibilitu porušuje. Jazyk, který od počátku nezná boolevské hodnoty
je IMHO hrubá chyba návrhu jazyka.

> ... ale ne v Pythonu. V něm můžu jakémukoliv jménu přiřadit 
> cokoliv (referenci na libovolný objekt). Pascal a Java dělají
> typovou kontrolu v době kompilace a identifikátor je svázán
> s typem. V Pythonu by tedy docházelo k výrazně zapeklitějším 
> chybám.

A Python taky dělá typovou kontrolu. Rozdíl je akorát ten, že jí dělá za
běhu, to je vše. Takže tento Váš argument neplatí.

> Říká se tomu interpretace v boolovském kontextu. Je to věc
> dohody. Taky píšu raději 
>   if len(lst) > 0:
>      ...
> než jen
>   if lst:
>      ...
> 
> Ale hodně lidí dává přednost stručnosti... ;o)
> a taky vyhození této vlastností by v porovnání s vyhozením
> lambda bylo mnohem výraznější...

Tahle stručnost způsobila tolik chyb, že by se neměla podporovat.

Lambdu beru u každého jazyka jako výraznou výhodu. Problém je, že lambda
má jen velmi omezenou funkčnost v Pythonu, spíše by to mělo být rozšířeno.

> Trochu mi to připomíná "Nic mi neříkejte! Já na to přijdu sám.".
> Debata kolem návrhu odstranit lambda a spol byla tuhá. Pokud si
> dobře pamatuji, implementace lambda je v jádře jazyka udělána
> nějak nečistě a některé věci komplikuje. Asi komplikuje i další
> vývoj. V novějších verzích Pythonu se objevily generátory 
> a generátorové výrazy, které zpětně vyjasňují i konstrukce
> s tak krkolomným názvem, jako je "list comprehension"
> (generátor seznamu).

Mě to připomíná styl, že pokud má Eskymák problémy s odrazem Slunce od
sněhu, tak mu vypíchneme oči namísto toho, abychom ulevili jeho očím.
Je-li implementace udělána v jádře nečistě, nechť se udělá čistě. Co
jiného?

> Spousta odborníků používajících C++ říká, že jednou z největších
> chyb byla asi snaha být důsledně zpětně kompatibilní s C.

Jako člověk, který se drsně komerčně mimo jiné pomocí C++ přes deset let
dost dobře živil, a ještě předtím pomocí C, a který má dodnes tento
jazyk C++ má rád říkám, že každá věc má dva konce.

1) Pokud by jazyk C++ nebyl dost kompatibilní s C, asi by se nerozšířil,
protože takto tvořil přirozenou přestupní stanici z C na C++. Pokud by
kompatibilita C++ byla malá, asi by lidé z C nepřestoupili na C++ a C++
by zůstalo jen pokusem v historii.

2) Jazyk C++ není zpětně kompatibilní s C, to je sice hodně tradovaná
fáma, ale není to pravda. Mnoho zápisů má v C++ jiný význam, než v C,
mnoho konstrukcí z C není v C++ povoleno. Takže o jaké důslednosti to
mluvíte?

3) To co C++ zdědilo z C je podle mě spíš plus. Jendak zdědilo logickou
syntaxi, jednak prostředky na úrovni práce se strojovým kódem, obojí
dodnes velké a silné zbraně C++.

Jinak nevidím v C++ problém co se týká kompatibility s C, vidím v C++
problém v jeho mizerném rozvoji dobudoucna, a v jeho mizerných
knihovnách. Můj názor je, že největší chyby C++ jsou:

1) Přenesení vývoje do standartizační komise, neznám jazyk, kterému by
to prospělo. Vezmu-li si C, C++, Javu, Python, Ruby, Pascal, Smalltalk,
Lisp, Simulu, C#, atd.. všechny jazyky se bouřlivě vyvíjely a udržely si
čistotu a konzistenci, pokud hlavní slovo ve vývoji měl jednotlivec,
nebo skupina. Teď je problém cokoli změnit a jakákoli drobná změna v C++
je otázkou pěti let diskusí.

2) Modla rychlosti. Například standardní STL knihovna v C++ je navržená
pro maximální rychlost. To znamená prasečiny stylu neprovádí se kontrola
chyb, třídy nelze podědit, nebo přetěžovat, atd.. Jenom vybojování
vlastnosti, že STL bude bezpečná vůči vyhozeným výjimkám byla dlouholetá
zdůvodňovací bitva. Takže STL je zprasená stejně tak jako spousty
dalších knihoven. Hledejte si chyby v STL, když to někde padá, že.

3) Mizerné knihovny. C++ spoléhá na C knihovny, není tam ani třída pro
datum a čas, nejsou tam thready, není tam vůbec nic.

Raději toho už nechám. Viděl bych spoustu chyb v C++, ale zpětná
kompatibilita s C to rozhodně není. Spíše bych to nazval vykašláním se
na rozvoj C++, který šel nabastlit v C zděděné části - tím mluvím o
knihovnách.

>>2) Jazyk, který kdy v historii hrubě porušil zpětnou 
>>kompatibilitu vymřel.
> 
> Příklad?

Rozhlédněte se kolem. Všechny zavedené jazyky drží zpětnou
kompatibilitu. C, C++, Java, Fortran, Cobol, Ada, Lisp, Smalltalk,
unixový shell, tohle jsou stálice, které stále žijí a přežily mnoho let.
Ani jedna z těchto stálic si nedovolila výrazněji porušit zpětnou
kompatibilitu s často desítky let starými zápisy. Já to obrátím,
jsemujte mi jeden jediný příklad jazyka, který se delší dobu udržel a
hrubě porušil zpětnou kompatibilitu. Já takový jazyk neznám.

Mnoho těchto jazyků se při svých nejodvážnějších snech o porušení zpětné
kompatibility odvážilo tak maximálně do vod daných warningem
"obsoleted", nebo "deprecated", ale nikam dál!!!

Miloslav Ponkrác