On 27/04/2013 13:32, Edek wrote:
> Dnia Sat, 27 Apr 2013 00:39:02 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
>> 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.
>
> Bez sensu, bo? Nadal też nie rozumiem, po co był wykład nt. COM.

Wykład był po to, żeby wyjaśnić dlaczego bez sensu.

> Nie twierdzę, że COM czy CORBA nie działa - tylko działa kiepsko.
>
> Powiedzmy, że chcemy przekazać jeden int do 1e8 wątków. Ile
> linijek kodu i narzędzi trzeba użyć w CORBA? Ile czasu wykonania
> otrzymamy? A ile w Go?

To pytanie tylko potwierdza, że nie masz pojęcia o czym mówisz.

>> 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.
>
> Architektury procesów rozproszonych nie tworzy się tak, że mamy
> wersję desktopową i "tylko ją rozproszymy".

Języki programowania (ogólnego zastosowania) nie służą do opisywania
architektury systemu, tylko do pisania programów.

do góry

Dnia Sat, 27 Apr 2013 23:58:31 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 27/04/2013 13:32, Edek wrote:
>> Dnia Sat, 27 Apr 2013 00:39:02 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>
>>> 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.
>>
>> Bez sensu, bo? Nadal też nie rozumiem, po co był wykład nt. COM.
>
> Wykład był po to, żeby wyjaśnić dlaczego bez sensu.

Przypomnę: polemizujesz Pan z tezą "COM jest podobnie zbędny
w systemach rozproszonych co wyjątki i generyki". Ja zupełnie nie
rozumiem co wykład na temat COMa, czym jest COM, ma tu do rzeczy,
jeżeli nie jest podany wraz z wykładem na temat "co to są wyjątki"
i "co to są generyki". Poproszę te dwa też, niech stracę.

>> Nie twierdzę, że COM czy CORBA nie działa - tylko działa kiepsko.
>>
>> Powiedzmy, że chcemy przekazać jeden int do 1e8 wątków. Ile linijek
>> kodu i narzędzi trzeba użyć w CORBA? Ile czasu wykonania otrzymamy? A
>> ile w Go?
>
> To pytanie tylko potwierdza, że nie masz pojęcia o czym mówisz.

Hehe, jasne.

>>> 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.
>>
>> Architektury procesów rozproszonych nie tworzy się tak, że mamy wersję
>> desktopową i "tylko ją rozproszymy".
>
> Języki programowania (ogólnego zastosowania) nie służą do opisywania
> architektury systemu, tylko do pisania programów.

A to było do mnie? Ja gdzieś twierdziłem, że "do opisywania"? Chyba EOT,
bo musiałbym non-stop zaprzeczać jakimś ciekawym wymysłom w stylu
"można argumentować, że generyki służą do programowania generycznego,
a nie są syntaktycznym cukrem zastępującym nadmiarowe ClassCasty
uformowanym w Wielkanocnego Zajączka dla dzieci w McDonalds,
z wołowiny".

--
Edek

do góry

On 28/04/2013 01:21, Edek wrote:
> Dnia Sat, 27 Apr 2013 23:58:31 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
>>>
>>> Bez sensu, bo? Nadal też nie rozumiem, po co był wykład nt. COM.
>>
>> Wykład był po to, żeby wyjaśnić dlaczego bez sensu.
>
> Przypomnę: polemizujesz Pan z tezą "COM jest podobnie zbędny
> w systemach rozproszonych co wyjątki i generyki". Ja zupełnie nie
> rozumiem co wykład na temat COMa, czym jest COM, ma tu do rzeczy,
> jeżeli nie jest podany wraz z wykładem na temat "co to są wyjątki"
> i "co to są generyki". Poproszę te dwa też, niech stracę.

Możesz przyjąć, że to nie było do ciebie.

>>>> 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.
>>>
>>> Architektury procesów rozproszonych nie tworzy się tak, że mamy wersję
>>> desktopową i "tylko ją rozproszymy".
>>
>> Języki programowania (ogólnego zastosowania) nie służą do opisywania
>> architektury systemu, tylko do pisania programów.
>
> A to było do mnie? Ja gdzieś twierdziłem, że "do opisywania"?

Napisałeś zdanie, które się zaczynało od "Architektury..."
Wyglądało, jakbyś odpowiadał na to, co było powyżej. Jeśli to było takie
stwierdzenie bez związku z czymkolwiek to przepraszam bardzo, piękną
mamy pogodę.

> Chyba EOT,

CHyba tak.

do góry

Dnia Sun, 28 Apr 2013 20:04:00 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 28/04/2013 01:21, Edek wrote:
>> Dnia Sat, 27 Apr 2013 23:58:31 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>>>> 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.
>>>>
>>>> Architektury procesów rozproszonych nie tworzy się tak, że mamy
>>>> wersję desktopową i "tylko ją rozproszymy".
>>>
>>> Języki programowania (ogólnego zastosowania) nie służą do opisywania
>>> architektury systemu, tylko do pisania programów.
>>
>> A to było do mnie? Ja gdzieś twierdziłem, że "do opisywania"?
>
> Napisałeś zdanie, które się zaczynało od "Architektury..."
> Wyglądało, jakbyś odpowiadał na to, co było powyżej. Jeśli to było takie
> stwierdzenie bez związku z czymkolwiek to przepraszam bardzo, piękną
> mamy pogodę.

Nie, nie było bez związku. Zacznę od drobnego framentu: wyjątki. Co
już A.L. uznał za opary absurdu, w rozproszonym procesie o błędzie
trzeba czasami powiadomić kilka innych Procesów [1]. I tu jest
idealny przykład dlaczego Go jest dostosowane do systemów
rozproszonych: ma defer, panic, recover.

Różnica ze względu na rozproszoną architekturę jest taka, że
wyjątek łapie się w jednym miejscu, a defer-panic-recover pozwalają
ręcznie przekazać informację o błędzie w wielu kierunkach. Oprócz
tego panic() jest jak throw, recover() jak catch(), a defer()
jak finally; tylko dużo elegantsze. Panic() zwija stos jak throw.

Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej
podoba, bo defer() używa się w miejscu inicjalizacji zasobu, trochę
zastępuje "goto cleanup2;" z C, ale działa podczas unwind, i nie
ma cech finally z Javy:
con = ...;
stmtFoo = ...;
stmtBar = ...;
... stronę niżej ...
finally {
if (con != null) con.close();
if (stmtFoo != null) {
stmtFoo.bar(); // ojej, a czy to nie rzuci wyjątku? TODO FIXME
smtmFoo.close(); // TODO owinąć kolejnym finally, podpisano
// deweloper O'Hara
}
itd.

Ten styl z Javy jest fatalny. Dodatkowo, Java jest tu niespójna,
bo nie można zadeklarować "final stmtFoo" - bo będzie niezainicjalizowane
w finally. Defer() pozwala dodawać elementy czyszczenia w miarę
inicjalizowania elementów, mniej więcej tak, że po stworzeniu
"con" dodaje się "defer(con.close())" itd.

Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
linijkach propagować błędy pomiędzy Procesami, co w przypadku
wyjątków _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.

To wszystko jest bardzo fajnie przemyślane moim zdaniemi i jest
lepsze niż wyjątki. Wbrew twierdzeniu że "nie mam pojęcia o
czym mówię" mogę podać przykłady już konkretne tego, o czym mówiłem
jedynie w postaci haseł. W zasadzie rozwinąłem się tu tylko
o wyjątkach - "dlaczego niby miałyby być potrzebne i w którą stronę
ma wyjątek polecieć, jeżeli jest kilka kanałów?". A że może
być ich wiele wykłada się na I roku studiów.

Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.

Może tak będzie łatwiej, zamist posługiwać się abstrakcyjnym poziomem
dyskusji mówić o konkretach w Go i np. Javie.

[1] W sensie goroutinges, czu dowolnego innego jednowątkowego algorytmu

--
Edek

do góry

On Sun, 28 Apr 2013 23:02:31 +0000 (UTC), Edek
<e...@g...com> wrote:

>
>Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
>linijkach propagować błędy pomiędzy Procesami, co w przypadku
>wyjątków _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.


Moze oddac glos tym ktory maja na ten temat zdanie

http://joneisen.me/post/38188396218

A.L.

do góry

On Apr 29, 3:23 am, A.L. <a...@a...com> wrote:
>
> Moze oddac glos tym ktory maja na ten temat zdanie
>
> http://joneisen.me/post/38188396218

Interesująca uwaga w tym wpisie "they have added a panic function, but
it is not meant to be used predominantly in production code". Po
przeczytaniu na ten temat, ten cały "panic" wygląda bardzo mocno jak
rzucenie wyjątku. Dlaczego niby miałoby się go nie używać w kodzie
produkcyjnym? I jeśli faktycznie nie jest po to, żeby używać w kodzie
produkcyjnym, to po cholerę on w ogóle?

do góry

On Apr 29, 12:02 am, Edek <e...@g...com> wrote:
> Dnia Sun, 28 Apr 2013 20:04:00 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
> > On 28/04/2013 01:21, Edek wrote:
[...]
> Nie, nie było bez związku. Zacznę od drobnego framentu: wyjątki. Co
> już A.L. uznał za opary absurdu, w rozproszonym procesie o błędzie
> trzeba czasami powiadomić kilka innych Procesów [1]. I tu jest

No ale wyjątki (takie jak w Javie czy C++) nie służą do powiadamniania
procesów. Jeśli trzeba powiadomić procesy, to kod, który to robi
możesz mieć w catch.

> idealny przykład dlaczego Go jest dostosowane do systemów
> rozproszonych: ma defer, panic, recover.
>
> Różnica ze względu na rozproszoną architekturę jest taka, że
> wyjątek łapie się w jednym miejscu, a defer-panic-recover pozwalają
> ręcznie przekazać informację o błędzie w wielu kierunkach. Oprócz
> tego panic() jest jak throw, recover() jak catch(), a defer()
> jak finally; tylko dużo elegantsze. Panic() zwija stos jak throw.

W takim razie przepraszam bardzo. Moja teza była taka, że wyjątki są
przydatne, a nie że Go jest be, bo nie ma wyjątków. Doczytałem o panic
i recover i jak dla mnie są to po prostu wyjątki, tylko troszeczkę
inaczej zrobione. Z tego co przeczytałem jest to ficzer dodany do
języka w późniejszym etapie i sądzę, że narzekanie, że nie ma wyjątków
raczej pochodzi z czasu, kiedy nie było.

Jeśli chodzi o to, co panic/recover wnoszą do rozproszonej
architektury, to przykro mi, ale nie widzę różnicy. W dodatku z
wykorzytsaniem w kontekście współieżności nie wydają się wnosić zbyt
wiele w stosunku do wyjątków, bo z tego co wyczytałem to wyjście z
goroutine w stanie spanikowanym wywala cały program.

Interesującą różnicą między tradycyjnymi wyjątkami a panic/recover
jest "dynamiczny" charakter tych drugich. Jak rozumiem defer/recover
można rejestrować np. warunkowo w klauzuli if. Czy to dobrze czy źle,
nie mam szczególnie zdania: widzę potencjalne problemy z czytelnością,
łatwością wnioskowania p programie, wykrywaniem błędów i
refaktoryzacją, w dodatku "tradycyjne" podejście oparte o zakresy
wydaje mi się elegantsze. Być może natomiast panic/defer/recover mają
jakieś ciekawe idiomatyczne sposoby stosowania, które może nawet
jeszcze nie są odkryte. Po prostu nie wiem.

Niepokojące natomiast są argumenty ze strony projektantów języka typu
"tak, wiemy, że (cośtam w) panic/recover jest kijowe. Specjalnie
zrobiliśmy kijowe, żebyście nie używali panic."

> Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej

Ach, ale akurat to, czy wyjątki są dobre, czy niedobre to jest
oddzielny temat od tego, czy sprzątanie zasobów przez finally jest
dobre czy niedobre. Są języki, które mają inne rozwiązania rtego
problemu, i nawet w samej Javie da się stworzyć (i tworzy się)
odpowiednie wrappery.

> Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
> linijkach propagować błędy pomiędzy Procesami, co w przypadku
> wyjątków _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.

Takie rozwiązanie, jak daje ci go, czyli złapać wyjątek w wątku, który
go rzucił i przekazać jako wynic coroutine to z grubsza tak samo
możesz zrobić w C++ przy pomocy future, try/catch, i pair.

[...]
> jedynie w postaci haseł. W zasadzie rozwinąłem się tu tylko
> o wyjątkach - "dlaczego niby miałyby być potrzebne i w którą stronę
> ma wyjątek polecieć, jeżeli jest kilka kanałów?". A że może

No więc dokładnie w taką stronę, w jaką mu exception handler każe
polecieć. Dokładnie tak jak z panic w Go.

> Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.

Po przyjrzeniu się wygląda trochę tak, jakby w Go interfejsy dawały
generyczność - przynajmniej taką jak w Javie, a może nawet trochę
mocniejszą. Nie mam racji?

do góry

Dnia Mon, 29 Apr 2013 02:56:38 -0700 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On Apr 29, 3:23 am, A.L. <a...@a...com> wrote:
>>
>> Moze oddac glos tym ktory maja na ten temat zdanie
>>
>> http://joneisen.me/post/38188396218
>
> Interesująca uwaga w tym wpisie "they have added a panic function, but
> it is not meant to be used predominantly in production code". Po
> przeczytaniu na ten temat, ten cały "panic" wygląda bardzo mocno jak
> rzucenie wyjątku. Dlaczego niby miałoby się go nie używać w kodzie
> produkcyjnym? I jeśli faktycznie nie jest po to, żeby używać w kodzie
> produkcyjnym, to po cholerę on w ogóle?

Pomijając taki szczegół jak to, że tablice mają sprawdzany zakres i
leci panic w sytuacji tego typu błędów, to po nic.

--
Edek

do góry

Dnia Mon, 29 Apr 2013 04:29:20 -0700 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On Apr 29, 12:02 am, Edek <e...@g...com> wrote:
>> Dnia Sun, 28 Apr 2013 20:04:00 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>> > On 28/04/2013 01:21, Edek wrote:
> [...]
>> Nie, nie było bez związku. Zacznę od drobnego framentu: wyjątki. Co już
>> A.L. uznał za opary absurdu, w rozproszonym procesie o błędzie trzeba
>> czasami powiadomić kilka innych Procesów [1]. I tu jest
>
> No ale wyjątki (takie jak w Javie czy C++) nie służą do powiadamniania
> procesów. Jeśli trzeba powiadomić procesy, to kod, który to robi możesz
> mieć w catch.

Tylko że to jest strasznie niewygodne. Działa ok w c++ dla prostych
rzeczy, typu odczytaj dokument z bazki, przetwórz, zapisz, ale mając
nie jeden wątek tylko masę i bilioteki w setkach tysięcy linii kodu
nawet RAII robi się kłopotliwe gdy dołączona jest reakcja
zewnętrznych systemów. C++11 ma lepsze rozwiązania ale nie
mam praktyki, o Javie może lepiej się nie wypowiem.

Dopiero małe goroutines z mniejszym stosem są światełkiem
w tunelu. Zamiast olbrzymiego stosu przez który leci wyjątek ma
się niewielkie procedury połączone kanałami. Widzę, że niedługo
powiemy, że BASIC też działał.

>> idealny przykład dlaczego Go jest dostosowane do systemów
>> rozproszonych: ma defer, panic, recover.
>>
>> Różnica ze względu na rozproszoną architekturę jest taka, że wyjątek
>> łapie się w jednym miejscu, a defer-panic-recover pozwalają ręcznie
>> przekazać informację o błędzie w wielu kierunkach. Oprócz tego panic()
>> jest jak throw, recover() jak catch(), a defer()
>> jak finally; tylko dużo elegantsze. Panic() zwija stos jak throw.
>
> W takim razie przepraszam bardzo. Moja teza była taka, że wyjątki są
> przydatne, a nie że Go jest be, bo nie ma wyjątków. Doczytałem o panic i
> recover i jak dla mnie są to po prostu wyjątki, tylko troszeczkę inaczej
> zrobione. Z tego co przeczytałem jest to ficzer dodany do języka w
> późniejszym etapie i sądzę, że narzekanie, że nie ma wyjątków raczej
> pochodzi z czasu, kiedy nie było.

Hmm. Ja żyję tu i teraz, ale może źle robię ;)

> Jeśli chodzi o to, co panic/recover wnoszą do rozproszonej architektury,
> to przykro mi, ale nie widzę różnicy. W dodatku z wykorzytsaniem w
> kontekście współieżności nie wydają się wnosić zbyt wiele w stosunku do
> wyjątków, bo z tego co wyczytałem to wyjście z goroutine w stanie
> spanikowanym wywala cały program.

Tu nie ma żadenj różnicy, wyjątki też trzeba łapać. Mi nie jest przykro
że rozmówca się nie zgadza, wręcz przeciwnie.

> Interesującą różnicą między tradycyjnymi wyjątkami a panic/recover jest
> "dynamiczny" charakter tych drugich. Jak rozumiem defer/recover można
> rejestrować np. warunkowo w klauzuli if. Czy to dobrze czy źle,
> nie mam szczególnie zdania: widzę potencjalne problemy z czytelnością,
> łatwością wnioskowania p programie, wykrywaniem błędów i refaktoryzacją,
> w dodatku "tradycyjne" podejście oparte o zakresy wydaje mi się
> elegantsze. Być może natomiast panic/defer/recover mają jakieś ciekawe
> idiomatyczne sposoby stosowania, które może nawet jeszcze nie są
> odkryte. Po prostu nie wiem.

Może najpierw "doczytam i wiem" a potem sugerowanie problemów? Podobny
cleanup stosuje się w C, tylko bez automatycznego zwijania stosu. Z tymi
znienawidzonymi goto.

> Niepokojące natomiast są argumenty ze strony projektantów języka typu
> "tak, wiemy, że (cośtam w) panic/recover jest kijowe. Specjalnie
> zrobiliśmy kijowe, żebyście nie używali panic."

No tak, bo panic to wszyscy lubią. Ech... . Go ma taką filozofię:
pozwlamy pisać ryzykowny kod, ale oferujemy bezpieczne metody
pisania.

>> Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej
>
> Ach, ale akurat to, czy wyjątki są dobre, czy niedobre to jest oddzielny
> temat od tego, czy sprzątanie zasobów przez finally jest dobre czy
> niedobre. Są języki, które mają inne rozwiązania rtego problemu, i nawet
> w samej Javie da się stworzyć (i tworzy się)
> odpowiednie wrappery.

Ja podałęm konkretny przykład i nic nie mówiłem o tym, czy finally
jest "dobre" czy "niedobre". Mając RAII używa się RAII, mając finally
używa się finally, mając goto w C używa się goto. Mówimy o braku
wyjątków w Go i z czym to się je w porównaniu do innych języków.

>> Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
>> linijkach propagować błędy pomiędzy Procesami, co w przypadku wyjątków
>> _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.
>
> Takie rozwiązanie, jak daje ci go, czyli złapać wyjątek w wątku, który
> go rzucił i przekazać jako wynic coroutine to z grubsza tak samo możesz
> zrobić w C++ przy pomocy future, try/catch, i pair.

Ano nie. To znaczy da się, ale praktyka zupełnie inaczej wygląda. W BASICu
też się da pisać.

> [...]
>> jedynie w postaci haseł. W zasadzie rozwinąłem się tu tylko o wyjątkach
>> - "dlaczego niby miałyby być potrzebne i w którą stronę ma wyjątek
>> polecieć, jeżeli jest kilka kanałów?". A że może
>
> No więc dokładnie w taką stronę, w jaką mu exception handler każe
> polecieć. Dokładnie tak jak z panic w Go.

Ano nie. Chociażby kod podzielnoy jest na goroutines, a nie na
jeden monolityczny wątek ze stoma ramkami stosu. To inna architektura,
trzeba przekazać informację o błędzie przez channele a nie tylko w górę
stosu.

Panic nie jest "dokładnie tak samo", tylko właśnie "zupełnie
inaczej", choć ma wspólne cechy, bo służy do tego samego celu.

>> Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.
>
> Po przyjrzeniu się wygląda trochę tak, jakby w Go interfejsy dawały
> generyczność - przynajmniej taką jak w Javie, a może nawet trochę
> mocniejszą. Nie mam racji?

Oj, j.w., doczytajmy może najpierw. Bo ja już nie wiem, czy brakuje
generyków czy są generyki, zdecydujmy się na zajęcie jakiejś
pozycji w argumentacji, pogubiłem się ;)

--
Edek

do góry

On Mon, 29 Apr 2013 02:56:38 -0700 (PDT), Andrzej Jarzabek
<a...@g...com> wrote:

>On Apr 29, 3:23 am, A.L. <a...@a...com> wrote:
>>
>> Moze oddac glos tym ktory maja na ten temat zdanie
>>
>> http://joneisen.me/post/38188396218
>
>Interesująca uwaga w tym wpisie "they have added a panic function, but
>it is not meant to be used predominantly in production code". Po
>przeczytaniu na ten temat, ten cały "panic" wygląda bardzo mocno jak
>rzucenie wyjątku. Dlaczego niby miałoby się go nie używać w kodzie
>produkcyjnym? I jeśli faktycznie nie jest po to, żeby używać w kodzie
>produkcyjnym, to po cholerę on w ogóle?

Moim zdaniem, kolejnosc byla taka:

1. Faceci uznali ze "nowatorsko" bedzie bez wyjatkow
2. Faceci stwierdzili ze bez wyjatkow sie nie da
3. Faceci stwierdzil ize po 1. wprowadzeie wyjatkow byloby utrata
twarzy
4. Wiec wprowadzili "panic" ktory oficjalnie wyjatkiem nie jest a de
facto jest

Teraz czekamy na generic i dziedziczenie wprowadzone "kuchennym
wejsciem"

Przy okazji wypada przypomniec entuzjastom GO ze "goroutines" nie sa
woatkami. Sa KORUTUNAMI (coroutine) a to jest zwierze inne niz watek
(threaad). Ten model wspolbieznosci byl wprowadzony po raz pierwszy w
jezyku Simula-67 a potem uzyty przez Wirtha w jezyku Modula-2.
Programuje sie to-to ineczej niz watki, bo coroutines (w odroznieniu
od watkow) nie sa kontrolowane pzrez scheduler systemu operacyjnego.

Dla mnie to krok do tylu, jakby co...

A.L.

do góry