eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingCo sie tu dzieje?...
Ilość wypowiedzi w tym wątku: 83

  • 51. Data: 2013-04-28 00:58:31
    Temat: Re: Co sie tu dzieje?...
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 52. Data: 2013-04-28 02:21:00
    Temat: Re: Co sie tu dzieje?...
    Od: Edek <e...@g...com>

    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


  • 53. Data: 2013-04-28 21:04:00
    Temat: Re: Co sie tu dzieje?...
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 54. Data: 2013-04-29 01:02:31
    Temat: Re: Co sie tu dzieje?...
    Od: Edek <e...@g...com>

    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


  • 55. Data: 2013-04-29 04:23:43
    Temat: Re: Co sie tu dzieje?...
    Od: A.L. <a...@a...com>

    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.


  • 56. Data: 2013-04-29 11:56:38
    Temat: Re: Co sie tu dzieje?...
    Od: Andrzej Jarzabek <a...@g...com>

    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?


  • 57. Data: 2013-04-29 13:29:20
    Temat: Re: Co sie tu dzieje?...
    Od: Andrzej Jarzabek <a...@g...com>

    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?


  • 58. Data: 2013-04-29 15:03:54
    Temat: Re: Co sie tu dzieje?...
    Od: Edek <e...@g...com>

    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


  • 59. Data: 2013-04-29 15:32:48
    Temat: Re: Co sie tu dzieje?...
    Od: Edek <e...@g...com>

    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


  • 60. Data: 2013-04-29 16:29:39
    Temat: Re: Co sie tu dzieje?...
    Od: A.L. <a...@a...com>

    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.

strony : 1 ... 5 . [ 6 ] . 7 ... 9


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: