Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Chodzi mi głowie, że nie znam dobrego języka. Wszystkie mają masę wad.
> Taki python rozumie "return" jako "return None"

To prawda.
Tez mnie w Pythonie to gryzlo nieco (lubie klarowny podzial
na statements i expressions), ale jakos przyzwyczailem sie.
W Pythonie None jest nieco szerzej ("mentalnie":) traktowane niz
zwykla wartosc, wiec.. nie bylo wyjscia. Trzeba bylo sie pogodzic
z tym return === return None.

> Wszystko to jeden i ten sam nierozwiązany przez nikogo problem.
> Funkcyjne też nie są w tym względzie lepsze na tyle, na ile być powinny.

Idealow nie ma. Jednak IMHO nie to jest najgorsze.
Najgorsze jest to ze czesto "asymptota rozwoju" ucieka/odbiega
daleeeekooo od idealu (np wlasnie C++), a potem sie udaje (gdy sie
okazuje, ze to slepa uliczka) ze jednak "to stare" bylo lepsze (w dodatku gotowe)
i trzeba to dorobic.
No ale oczywiscie pisze sie to zwykle w sekcji: "very modern and completelly
revelatory and new features/languages/constructions" (+ pstrzy belkotem
marketingowym), zamiast napisac: "zaimplementowalismy w 'naszym ukochanym'
jezyku Y wlasnosc X dokladnie/podobnie wzorem tejze w
Algolu/Simuli/PL/I/Eiffla/Prologu...".
No a mlodzi czytaja i "wiedzą"...

> Icon na pierwszy rzut oka niewiele się różni od Pythona w tym
> względzie,

Tyle, ze Icon nie jest obiektowy.
Inaczej tez traktuje sie "zmienne" (w Pythonie to metki).
Roznic dosc zasadniczych jest wiecej ale.. niewazne.
Zrwszta nie bede zaprzeczal ze moje droga w tym obszarze wiodla wlasnie tak:
Icon -> Python :)

> tylko lepiej zaadoptował generatory i zbiory. Cool.

A no bo Python zerznal _wprost_ generatory _od Icona wlasnie_
(i bardzo dobrze, ze nie wymyslano "kola na nowo").
Jednak (tu masz 100% racji). Z powodu neico "innej mentalnoci" Pythona
jego generatory nie dorownaja tym Iconowym (bo tak naprawde Icon to
"generators driven programming")

http://www.cs.arizona.edu/icon/

AK