On Thursday, April 25, 2013 7:19:00 PM UTC+2, A. L. wrote:
> Jeszcze ktos mnie musi pzrekonacze to jest "SILNY" system typow

M.in. bez konwersji domyślnych, jak w Adzie. W Go zresztą typy
są identyfikowane przez nazwę, jak w Adzie, czy SML-u. W przeciwieństwie
do C/C++ gdzie brana jest pod uwagę struktura.

> Optymalizacja robiona pzrez uzytkownika maniespecjalnie wiele
> wspolnego z optymalizacja robiona pzrez kompilator.

Pardąsik, niejasno się wyraziłem. Miałem na myśli to, że kompilacja
jest robiona raz, u producenta. JIT obciąża końcowego użytkownik,
przysłowiowego Kowalskiego.

> Co wiecej, optymalziacja "po wierzchu" mzoe spowodowac bledy, na
> przykald zmienic pozadany sposob obliczania wyrazen arytmetycznych
> (rozstawienie nawiasow itede).

Widziałeś http://compcert.inria.fr/? Kompilator (podzbioru) C, który
formalnie dowodzi, że po swoich optymalizacjach nie zmienił semantyki.

w.

do góry

On Fri, 26 Apr 2013 08:58:01 -0700 (PDT), Wojciech Muła
<w...@g...com> wrote:

>On Friday, April 26, 2013 3:30:29 PM UTC+2, A. L. wrote:
>> W czym GO jest lepszy od sprawdzonego i istnieajcego od lat Erlanga?
>
>To jest źle postawione pytanie. Go powstał jako odpowiedź na problemy
>Googla w

No wlasnie. Wiekszosc ludzi ma inne problemy. Ale docenic nalezy to ze
Gogel w koncu zauwazyl ze sa problemy z C++

A.L.

do góry

Dnia Fri, 26 Apr 2013 08:39:55 -0700 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On Apr 26, 3:16 pm, Edek <e...@g...com> wrote:
>> Dnia Fri, 26 Apr 2013 02:42:05 -0700 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>
>> > To nie są specjalne zastosowania. Serwery wysoce współbieżnie mogą
>> > robić cokolwiek. A dane cokolwiek może być na porzykład takie, że
>> > lepiej się pisze program mając np. generyki i wyjątki - i często tak
>> > jest.
>>
>> I COM, nie zapominajmy o COM do tego.
>
> Nie rozumiem o co ci chodzi. Wsparcie COM w języku jest przydatne do
> komunikowania się z serwisami COM albo do tworzenia takich serwisów.
> Jeśli sie używa COM, to ma to jakiś tam sens, chociaż jeśli język ma
> odpowiednie mechanizmy ogólnego zastosowania (w tym generyki i wyjątki),
> to można też dość sensowne wsparcie zrobić bibliotekami. Przede
> wszystkim jednak sam COM jest po prostu specyficzną technologią, dla
> aktórej istnieją alternatywy, czy to CORBA, J2EE/EJB, cośtam na dotneta,
> różne łebserwisy i co tam jeszcze. Oczywiście jak siedzisz mocno w
> Windowsach to masz bezpośrednie wsparcie dla COM z C#
> i z różnych dialektów VB - ale użycie COM lub czego innego to przecież
> nie jest kwestia zastosowania tylko wybranej technologii.

Oprócz wykładu na temat COMa, what's your point? Miałem na myśli tyle,
że w takiej architekturze wyjątki są podobnie niepotrzebne co COM
i takie "generyki" jakie ma Java.

--
Edek

do góry

On Fri, 26 Apr 2013 08:55:20 -0700 (PDT), Wojciech Muła
<w...@g...com> wrote:

>On Friday, April 26, 2013 3:29:16 PM UTC+2, A. L. wrote:
>> >Czyta�e� ten wpis go�cia? Pisze, jakby generyki by�y absolutnie
niezb�dne.
>> >Jak pokazuje praktyka, s� zb�dne w bardzo wielu przypadkach.
>>
>> No, kompilator tez lest w wielu wypadkach zbedny. Mozna pisac w
>> asemblerze.
>
>Można też każdy argument sprowadzić do absurdu.
>
>> P.S. Zbedne sa tez wyjatki, dziedziczenie i pare innych mechanizmow
>> ktorych jezyki dorobily sie w ciagu ostatnich lat a ktore tworcom GO
>> wydaly sie zbedne
>
>Nie zadałeś sobie trudu, żeby przeczytać dlaczego tego nie ma.
>Nie widzę sensu referować ogólnodostępnych materiałów.
>
>w.

Ja tez nie. Ich poglad, ich sprawa, ich jezyk. Jak dla mnie, to czego
nei ma w GO wydaje sie calkiem uzyteczne.

A.L.

do góry

On Fri, 26 Apr 2013 17:07:00 +0000 (UTC), Edek
<e...@g...com> wrote:

>Dnia Fri, 26 Apr 2013 08:39:55 -0700 po głębokim namyśle Andrzej Jarzabek
>rzekł:
>
>> On Apr 26, 3:16 pm, Edek <e...@g...com> wrote:
>>> Dnia Fri, 26 Apr 2013 02:42:05 -0700 po głębokim namyśle Andrzej
>>> Jarzabek rzekł:
>>>
>>> > To nie są specjalne zastosowania. Serwery wysoce współbieżnie mogą
>>> > robić cokolwiek. A dane cokolwiek może być na porzykład takie, że
>>> > lepiej się pisze program mając np. generyki i wyjątki - i często tak
>>> > jest.
>>>
>>> I COM, nie zapominajmy o COM do tego.
>>
>> Nie rozumiem o co ci chodzi. Wsparcie COM w języku jest przydatne do
>> komunikowania się z serwisami COM albo do tworzenia takich serwisów.
>> Jeśli sie używa COM, to ma to jakiś tam sens, chociaż jeśli język ma
>> odpowiednie mechanizmy ogólnego zastosowania (w tym generyki i wyjątki),
>> to można też dość sensowne wsparcie zrobić bibliotekami. Przede
>> wszystkim jednak sam COM jest po prostu specyficzną technologią, dla
>> aktórej istnieją alternatywy, czy to CORBA, J2EE/EJB, cośtam na dotneta,
>> różne łebserwisy i co tam jeszcze. Oczywiście jak siedzisz mocno w
>> Windowsach to masz bezpośrednie wsparcie dla COM z C#
>> i z różnych dialektów VB - ale użycie COM lub czego innego to przecież
>> nie jest kwestia zastosowania tylko wybranej technologii.
>
>Oprócz wykładu na temat COMa, what's your point? Miałem na myśli tyle,
>że w takiej architekturze wyjątki są podobnie niepotrzebne co COM
>i takie "generyki" jakie ma Java.


Jakies argumenty?

A.L.

do góry

Dnia Fri, 26 Apr 2013 12:08:01 -0500 po głębokim namyśle A.L. rzekł:

> On Fri, 26 Apr 2013 17:07:00 +0000 (UTC), Edek
> <e...@g...com> wrote:

>> Miałem na myśli tyle,
>>że w takiej architekturze wyjątki są podobnie niepotrzebne co COM i
>>takie "generyki" jakie ma Java.
>
> Jakies argumenty?

Po naprawdę ciężkie argumenty musiałbym zejść do piwnicy, więc
zaryzykuję tylko teoretyczne [1]. Mogę też nie pamiętać niuansów Go,
nawet nie znam wersji 1.0.

Pierwszy problem w procesach mających kilka wejsć i kilka wyjść,
lub nawet po jednym, jest taki: kto ma złapać wyjątek? Downstream,
upstream, rodzic? Jednocześnie mówimy o Failure więc powiem o jakie
Failure mi się (nie) rozchodzi.

Wyjątki mogą być spowodowane wadą algorytmiczną. Powiedzmy, że
w systemie płac Złośliwy Zenek zakodował:

if (name == Żółty.Stefan and boss == doopa.noerweskiego.renifera)
then die;

Wtedy _zawsze_ proces dawania podwyżki dla Stefana Architekta
nie przejdzie [2].

Ale takie problemy na bok, Poisonous Messages są znane,
tak jak i Tagged Logging, gdzie "zarażane" są wszystkie wyjścia
i procesy mające od czynienia ze sktukiem jednej wiadomości.

Większość modeli teoretycznych jakie ja znam operuje
na kilku prymitywach zakładając, że z wielu procesów zawsze
jakiś padnie w przypadkowy sposób, powiedzmy promieniowanie
jonizujące uszkodzi ALU procesora. Prymitywy to najczęściej
atomiczne rejestry, Procesy realizujące algorytm, message passing,
i Wyrocznia, możliwie słaba. Jeżeli znane N procesów ma liczbę
mogą one ustalić największą liczbę[3], jeżeli Wyrocznia
w dowolnym momencie informuje każdy proces, który z procesów
jest Leaderem. Ale to samo jest też możliwe dla Wyroczni
informującej czy procesy jeszcze nie padnięte a) to wszystkie
b) czy ich liczba jest parzysta (jeżeli czegoś nie pokręciłem).
Ta druga jest ściśle słabsza, bo z informacji dawanej przez
pierwszą da się wyprowadzić drugą, a na odwrót już nie. To cała
dość fajna dziedzina algorytmiki, science of its own. Dość
dobrze znana, na pewno znana doskonale od strony praktycznej
przez Google i na pewno mają odpowiednią infrastrukturę.

Nie znam odpowiednich prac mających za postawę wyjątki, ale
jak przekazać wyjątek przez message passing tak,
żeby uniknąć samego problemu w message passing lub procesie
w momencie wysyłania wyjątku? Tu mógłbym skończyć.

Drugi punkt widzenia jest taki, że trzeba napisać oprogramowanie
za pomocą pracy Szarych Edziów, którzy mogą nie zrozumieć niuansów
zabezpieczeń przed dowolnym Failure, lub Sowich Adamów,
ekspertów od ...analizy kryształów, którzy nie chcą być tym
obarczani. Podejrzewam, że mając Go można ukryć większość
tych włochatych problemów przed Szarymi Edziami, o ile
Żółty Stefan Architekt sam nie jest Dooponte tak jak
jego szef.

Go może wszystkie te powyższe mechanizmy mieć ukryte
w implementacji. Z punktu widzenia Szarego Edzia i Sowiego
Adama wystarczy wysłać int-a przez channel, żeby dotarł i
obsłużyć wynik WynikBrakMuzgu. To jedna linijka w przeciwieństwie
do CORBY czy COMa. Za to w implementacji poszczególne
algorytmy są Procesami zgodnie z teorią i mają określany stan
w każdym punkcie dostępu do channela, więc można je restartować
i odtworzyć bez widocznego skutku dla realizowanego
algorytmu. Infrastrukturę robi się raz, Edzie mają znać Go i
tylko pójść przed rozpoczęciem pracy postemple ppoż i bhp, a
nie mieć wtłaczaną tygodniami do głowy teorię systemów
rozproszonych i potem jeszcze zgodnie z nią pisać kod.

Pewnei coś pokręciłem, mam nadzieję że jutro ędzie
nadal wyglądało w miarę...

Jest jeszcze punkt widzenia taki, że modna Java ma modne
wyjątki więc Go jest niemodne, ale ja zawsze wolę jak
coś działa i jest spokój, mam nadzieję że na p.c.p to
podejście przejdzie :). A, i Google nigdy nie faworyzowało
wyjątków.

[1] Uprzedzałem, jakby ktoś coś do mnie miał mieć
[2] Bez manualnej ingerencji Doopy Renifera, inni głosu nie mają
[3] Z żyjących procesów, i procesy nie odżywają

--
Edek

do góry

On 26/04/2013 18:07, Edek wrote:
[...]
> Oprócz wykładu na temat COMa, what's your point?

Że przywaliłeś kompletnie bez sensu.

> Miałem na myśli tyle,
> że w takiej architekturze wyjątki są podobnie niepotrzebne co COM
> i takie "generyki" jakie ma Java.

W jakiej architekturze? Mowa była o "zastosowaniu" typu aplikacja
serwerowa rozproszona i równoległa. To nie jest jeszcze architektura,
ale oczywiście COM się używa w aplikacjach spełniających takie warunki.

Jeśli chodzi o wyjątki i generyki (nawet takie, jakie ma Java), to ich
przydatność jest raczej zależna od tego, co konkretnie ta aplikacja robi
rozproszenie i równolegle i w jaki sposób to jest zakodowane.
Doświadczenie uczy, że generykii wyjątki są przydatne w kodowaniu
problemów w językach imperatywnych/OO, więc to samo będzie raczej
dotyczyć kodu realizującego to samo zadanie, tylko chodzącego w ramach
aplikacji współbieżnej i równoległej.

do góry

On 26/04/2013 18:07, A.L. wrote:
>
> Ja tez nie. Ich poglad, ich sprawa, ich jezyk. Jak dla mnie, to czego
> nei ma w GO wydaje sie calkiem uzyteczne.

Od razu żebyy nie było - to nie jest tak, że oni zauważyli problemy z
C++, więc wymyślili język, który rozwiązuje te problemy i odpowiada ich
potrzebom, więc uzywają go zamiast C++. Otóż wcale nie używają, nadal
wszystko piszą w C++, a Go wykorzystują chyba tylko na zasadzie
"popatrzcie jakie kulerskie rzeczy tutaj wymyślamy".

do góry

On Fri, 26 Apr 2013 21:07:45 +0000 (UTC), Edek
<e...@g...com> wrote:

>Jest jeszcze punkt widzenia taki, że modna Java ma modne
>wyjątki więc Go jest niemodne, ale ja zawsze wolę jak
>coś działa i jest spokój, mam nadzieję że na p.c.p to
>podejście przejdzie :). A, i Google nigdy nie faworyzowało
>wyjątków.
>
>[1] Uprzedzałem, jakby ktoś coś do mnie miał mieć
>[2] Bez manualnej ingerencji Doopy Renifera, inni głosu nie mają
>[3] Z żyjących procesów, i procesy nie odżywają

To ne sa argumenty merytoryczne, w kazdym razie nie sa takie (albo
pzredstawione nie tak) aby mi sie chcialo do nich ustosunkowac.

Pzremysl sobie i napisz jescze raz. Tym razem na serio

A.L.

do góry

On Sat, 27 Apr 2013 00:42:31 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 26/04/2013 18:07, A.L. wrote:
>>
>> Ja tez nie. Ich poglad, ich sprawa, ich jezyk. Jak dla mnie, to czego
>> nei ma w GO wydaje sie calkiem uzyteczne.
>
>Od razu żebyy nie było - to nie jest tak, że oni zauważyli problemy z
>C++, więc wymyślili język, który rozwiązuje te problemy i odpowiada ich
>potrzebom, więc uzywają go zamiast C++. Otóż wcale nie używają, nadal
>wszystko piszą w C++, a Go wykorzystują chyba tylko na zasadzie
>"popatrzcie jakie kulerskie rzeczy tutaj wymyślamy".

Skadinad... Wydaje sie ze oni zadroszcza sukcesu Javie i chca wymyslec
cos takiego co by bylo ich wlasne. Ale chyba ciezko bedzie z
entuzjazmem, nawet na wlasnym podworku (Android...)

A.L.

do góry