Dnia Tue, 03 Jul 2012 13:06:57 +0200, AK napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
>> Cała zabawa polega na tym, że jedno może stawać się drugim.
>
> Alez wiem. No i po co zepsules cala zabawe ? :)
>
> PS: Nie Ruby pierwszy. Juz w latach 90tych byl sobie jezyk zwany Icon
> (kiedys bylem w nim "zakochany") w ktorym (prawie) kazda
> instrukcja zwracala wartosc wiec w zaleznosci od kontekstu uzycia
> traktowalo sie ja jako instrukcje lub wyrazenie.

Chodzi mi głowie, że nie znam dobrego języka. Wszystkie mają masę wad.
Taki python rozumie "return" jako "return None", jeżeli chodzi o
wyrażenia, za to lambda musi mieć Expression, bo tak.

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.

Icon na pierwszy rzut oka niewiele się różni od Pythona w tym
względzie, tylko lepiej zaadoptował generatory i zbiory. Cool.

Edek

do góry

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

do góry

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

do góry

W dniu 3.07.2012 r. 14:10, AK pisze:
> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>> Icon na pierwszy rzut oka niewiele się różni od Pythona w tym
>> względzie,
>
> Tyle, ze Icon nie jest obiektowy.
Można zainteresować się językiem Unicon: <http://unicon.sourceforge.net/>

do góry

Dnia Tue, 03 Jul 2012 15:27:11 +0200, no+spam napisal:

> W dniu 3.07.2012 r. 14:10, AK pisze:
>> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>>> Icon na pierwszy rzut oka niewiele się różni od Pythona w tym
>>> względzie,
>>
>> Tyle, ze Icon nie jest obiektowy.
> Można zainteresować się językiem Unicon:
> <http://unicon.sourceforge.net/>

Ponieważ napisałem, co napisałem, muszę spytać "dlaczego tym,
z całej masy nowych języków".

Edek

do góry

W dniu 3.07.2012 r. 15:31, Edek Pienkowski pisze:
> Dnia Tue, 03 Jul 2012 15:27:11 +0200, no+spam napisal:
>
>> W dniu 3.07.2012 r. 14:10, AK pisze:
>>> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>>>> Icon na pierwszy rzut oka niewiele się różni od Pythona w tym
>>>> względzie,
>>>
>>> Tyle, ze Icon nie jest obiektowy.
>> Można zainteresować się językiem Unicon:
>> <http://unicon.sourceforge.net/>
>
> Ponieważ napisałem, co napisałem, muszę spytać "dlaczego tym,
> z całej masy nowych języków".
Bez powodu, pisałem informacyjnie, a Icon wpadł mi dość dawno temu w
zainteresowanie -- język nie jest aktywnie rozwijany (wolniej niż np.
D), sami twórcy określają go jako język bardzo wysokiego poziomu; FAQ:
#v+
6. What is the motivation for Unicon?
We wish to develop, improve, and promote Icon-style goal-directed very
high level languages. [...]
#v-
Goal-directed:
<http://en.wikipedia.org/wiki/Icon_programming_langu
age#Goal-directed_execution>
<http://homepages.feis.herts.ac.uk/~msc_fl/fl-node43
.html>[?]

do góry

On Jul 4, 9:27 pm, n...@m...invalid wrote:
>
> D), sami twórcy określają go jako język bardzo wysokiego poziomu; FAQ:
> #v+
> 6. What is the motivation for Unicon?

Nie ma w tym FAQ najważniejszego pytania: jak to cholerstwo wymawiać?
Anajkon? Junajkon? Junikon?

do góry

W dniu wtorek, 3 lipca 2012 09:55:58 UTC+2 użytkownik Maciej Sobczak napisał:
> Właśnie został zebrany w całość dokument pt. "Ada 2012 Rationale", który wcześniej
powstawał w kolejno publikowanych kawałkach:
>
> http://www.ada-auth.org/standards/rationale12.html
>
> Jest to opis i uzasadnienie nowych ficzerów w Adzie.

W sumie najciekawsze są rozszerzenia sprawdzania typów:
pre/postwarunki i niezmienniki. Składnia wyrażeń warunkowych
to, IMHO, ledwie lukier składniowy.

w. (kurde, piszę to 3. raz, google groups obsysają)

do góry

W dniu sobota, 7 lipca 2012 16:00:14 UTC+2 użytkownik Wojciech Muła napisał:

> W sumie najciekawsze są rozszerzenia sprawdzania typów:
> pre/postwarunki i niezmienniki.

Niby tak, w tym sensie, że najbardziej się to rzuca w oczy - warto jednak pamiętać,
że te warunki są sprawdzane dynamicznie i działają na zasadzie automatycznie
generowanych assertów, które strzelają wyjątkami w razie niespełnienia warunku. To
znaczy, że jest to raczej krok w stronę Eiffelowych kontraktów, niż kontynuacja
statycznej kultury wykrywania bugów i to jest też źródło ich krytyki ze strony
Adowego betonu.
Z drugiej strony - intencją tych warunków jest taki stopień zintegrowania z resztą,
żeby ich statyczna analiza była jak najbardziej możliwa i należy się spodziewać, że z
biegiem czasu (czyli w miarę udoskonalania kompilatorów) coraz większa ich część
będzie sprawdzana już w czasie kompilacji.

> Składnia wyrażeń warunkowych
> to, IMHO, ledwie lukier składniowy.

Zgadza się, ale ten cukier też ma szersze znaczenie - tu nie chodzi tylko o to, żeby
zrobić coś a la pytajnik z C++, tylko żeby pozwolić na łatwiejsze pisanie
jednolinijkowych predykatów bezpośrednio w plikach specyfikacji, które to predykaty z
kolei mogą być nazwane, refaktoryzowane, itd. i użyte choćby w tych warunkach
pre/post. Dopiero jak się spojrzy na całość to widać jak się te rzeczy zazębiają.
Same wyrażenia warunkowe oderwane od tej reszty to faktycznie pikuś.
Natomiast warte uwagi są też standardowe kontenery, które się mocno rozrosły od
poprzedniej wersji.

> w. (kurde, piszę to 3. raz, google groups obsysają)

Ano obsysają - zwłaszcza ten nowy interfejs, wygląda jak forum dla debili.
Najwyraźniej złote czasy dobrze rozumianych innowacji firma ma już za sobą.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

W dniu sobota, 7 lipca 2012 23:07:45 UTC+2 użytkownik Maciej Sobczak napisał:
> > W sumie najciekawsze są rozszerzenia sprawdzania typów:
> > pre/postwarunki i niezmienniki.
>
> Niby tak, w tym sensie, że najbardziej się to rzuca w oczy - warto jednak
> pamiętać, że te warunki są sprawdzane dynamicznie i działają na zasadzie
> automatycznie generowanych assertów, które strzelają wyjątkami w razie
> niespełnienia warunku. To znaczy, że jest to raczej krok w stronę Eiffelowych
> kontraktów, niż kontynuacja statycznej kultury wykrywania bugów i to jest też
> źródło ich krytyki ze strony Adowego betonu.
> Z drugiej strony - intencją tych warunków jest taki stopień zintegrowania z
> resztą, żeby ich statyczna analiza była jak najbardziej możliwa i należy się
> spodziewać, że z biegiem czasu (czyli w miarę udoskonalania kompilatorów)
> coraz większa ich część będzie sprawdzana już w czasie kompilacji.

Właśnie, nie sądzę też, żeby to mógł być nadużywany mechanizm. Zresztą,
ten statyczny obecnie wcale nie musi być statyczny - w sensie, bez kosztów :)
Zerknąłem niedawno w wygenerowany kod i dla typu Float range 0 .. Float'Max
każda operacja na nim to było kilka instrukcji FPU + sprawdzenie czy wynik > 0.

> Natomiast warte uwagi są też standardowe kontenery, które się mocno rozrosły
> od poprzedniej wersji.

Może to przyciągnie więcej firm do zwykłego softu. Ale ogólnie myślę,
że przydałby się lepszy PR, żeby ludzie nie myśleli, że w Adzie warto
pisać tylko, gdy robimy samoloty lub latamy w kosmos. :)

w.

do góry