Dnia Tue, 03 Jul 2012 14:10:07 +0200, AK napisal:

> 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.

Większość języków ma jakiś koncept nil. Często graf typów ma wszystkie
ścieżki zaczynające się od 'any' a kończące się na 'null'. Niektóre
mają dodatkowo tagi (coś jak tagged-data na nieistniejących już
architekturach, gdzie każda dana w RAM miała kilka bitów mówiące,
co jest przechowywane w danym miejscu).

To co mi się nie mieści to niekompilowalne w pythonie
"lambda sth: print sth" i podobne.

> 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 właśnie o tym mówię, każdy wspaniały nowy język po jakimś czasie
dryfuje z powrotem do tej samej gromadki już istniejących języków.
Jaki ma być w tym sens, poza vendor lockin? Nie ma technicznego
sensu tworzyć odmianę nr. 957 tego co istnieje, byle miało nazwę
i implementację, bo tylko to pozostaje na dłuższy czas. W tym
całym wysypie języków jak się znajdzie coś nowego to jest fajne,
co za super język, ale po kilku takich super językach zaczyna się
zauważać, że to jeden i ten sam stuff.

> 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ą"...

Podstaw pod C++ Javę to się zgodzę, a nawet rozszerzę z samego języka
na to, co się w języku tworzy, tyle że jest tego dużo. W C++ za to:
http://www.lextrait.com/vincent/implementations.html

>
>> 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.

No właśnie, nieważne.
Chodziło mi tylko o jeden aspekt. Nie nauczę się języka pomiędzy dwoma
postami w tym tempie.

>> 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/

Skąd wiedziałeś, co czytam? ;) Za Icona dzięki generalnie, szukałem
czegoś takiego (chyba, jak doczytam, to się okaże).

Edek