eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJakie typowanie jest najlepsze i dlaczego statyczne?
Ilość wypowiedzi w tym wątku: 197

  • 131. Data: 2013-02-11 01:31:13
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Roman W <b...@g...pl>

    On Sun, 10 Feb 2013 14:25:54 +0000, Andrzej Jarzabek
    <a...@g...com> wrote:
    > Osobną sprawą jest to, że jesteśmy w takim a nie innym czasie i
    > popularne rozwiązania do różnych zastosowań są takie a nie inne -
    > niekoniecznie dlatego, że są pod każdym względem najlepsze. Kiedyś
    > całkiem duże systemy biznesowe powstawały w dynamicznie typowanym
    > Smalltalku i przecież właśnie w tym środowisku opracowano techniki
    > refaktoryzacji.

    Dla mnie jako współautora kilku juz bibliotek do wyceny tych
    nieslawnych derywatow bardzo duza zaletą statycznego systemu typow
    jest możliwość precyzyjnego zdefiniowania API biblioteki, w
    szczególności zaś blokowanie "podpisania" do biblioteki rzeczy, które
    nie miały byc przez nia obrabiane.

    RW


  • 132. Data: 2013-02-11 06:04:58
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "M.M." <m...@g...com>

    W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej Jarzabek
    napisał:
    > To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
    > zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym nie
    > zdecydował się użyć jej do pisania czegoś takiego".
    Argument "ma zalety bo używam" też niewiele wnosi :)

    Właśnie 2-3 godziny temu stanąłem w obliczu takiej refaktoryzacji ze
    zmianą struktury danych dla algorytmów, a więc musiałem także
    poprawiać algorytmy. Konieczność wynikła z nieudanej próby optymalizacji.
    Zamiast globalnie trzymać dane w pamięci, a potem filtrowanie/sortowanie
    zrobić na wskaźnikach, to dla algorytmów przygotowałem specjalistyczne
    struktury danych. Globalne dane były konwertowane na specjalistyczne,
    liniowe tablice w pamięci. Miałem nadzieję że dzięki sekwencyjnemu
    dostępowi do pamięci i mniejszym rozmiarom specjalistycznych struktur
    program zadziała szybciej. Niestety nie udało się, narzut na konwersje i
    kopiowane pożarł cały zysk.

    No więc stanąłem w obliczu tej refaktoryzacji i myślę sobie, jakbym miał
    język z dynamicznym typowaniem, to pomimo wielu błędów w pozostałych
    częściach programu, bym mógł program uruchomić. Bym mógł uruchomić te
    działające części, a w trakcie uruchomienia może zdołałbym zrobić
    jeszcze jakiś eksperyment z optymalizacją. Ze statycznym typowaniem nie
    mogłem na to sobie pozwolić, musiałem wszystkie użycia specjalistycznych
    struktury zamienić na tablice wskaźników. Myślę sobie dalej: znalazłem
    zaletę dynamicznego typowania.

    Jednak po chwili druga myśl: przecież kompilator przez 2-3 godziny krzyczał, że
    jest źle. Bez tej pomocy bym pewnie te wszystkie użycia znajdował przez
    tydzień albo dłużej. Co więcej, środowisko uruchomieniowe odsyłałoby mnie
    do linii w której błąd się uaktywnił, a do złego użycia bym musiał dochodzić
    debugerem po stosie wielokrotnych wywołań funkcji. Tutaj kompilator pokazał
    mi od razu gdzie nie ma zdefiniowanych typów i od razu byłem w linii
    która wymagała poprawek.

    Podsumowując, moje stanowisko nie zmieniło się, nie widzę tych zalet,
    choć niewykluczone że są.

    Pozdrawiam


  • 133. Data: 2013-02-11 09:07:20
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    On 11/02/2013 05:04, M.M. wrote:
    [...]
    > Jednak po chwili druga myśl: przecież kompilator przez 2-3 godziny krzyczał, że
    > jest źle. Bez tej pomocy bym pewnie te wszystkie użycia znajdował przez
    > tydzień albo dłużej. Co więcej, środowisko uruchomieniowe odsyłałoby mnie
    > do linii w której błąd się uaktywnił, a do złego użycia bym musiał dochodzić
    > debugerem po stosie wielokrotnych wywołań funkcji.

    Argument jest taki, że gdybyś stosował odpowiednie techniki, co się
    wiąże również z pisaniem w sposób idiomatyczny dla dynamicznego
    typowania, to:
    a) większość tych sytuacji nie byłaby błedami,
    b) pozostałe błędy zostałyby wyłapane przez unit testy,
    c) mógłbyś wyłapać błędy w momencie powstania np. przy pomocy asercji.

    Oczywiście, jesli piszesz swoje programy tak, jakbyś pisał w języku ze
    statycznym typowaniem, to prawdopodobnie będziesz miał gorsze rezultaty
    niż ze statycznym typowaniem.


  • 134. Data: 2013-02-11 10:49:54
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Maciej Sobczak <s...@g...com>

    W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej Jarzabek
    napisał:

    > > Co z tego, że pokazuje, skoro przez swoją dynamiczność nie dałbym mu
    > > szansy się wykazać.
    >
    > To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
    > zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym nie
    > zdecydował się użyć jej do pisania czegoś takiego".

    Tak, to jest dokładnie taki argument. Poza tym, że obiektowość powstała z myślą o
    dużych systemach i sama w sobie nie ma cech, który by były z nimi sprzeczne.

    > >>> Statyczny system typów pozwala wyrazić związki między różnymi
    > >>> bytami w programie, dzięki czemu szybciej widać jaki jest zakres
    > >>> wprowadzanych zmian.
    >
    > >> Pozwala, ale są inne sposoby, które też pozwalają.
    >
    > > Droższe?
    >
    > Nie wiem nawet, jak to porównać. Chodzi o zupełnie inny paradygmat
    > pisania programów,

    Droższy? Bardziej efektywny? Czy jedynie "też pozwala"?

    Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.

    > > Jak do tej pory jedyny code reuse między różnymi typami widywałem w
    > > kontenerach
    >
    > To niewiele widziałeś.

    Możliwe, ale nie czuję się tym pokrzywdzony a skoro tak, to najwyraźniej nic nie
    straciłem, że nie widziałem.
    Poproszę o lepszy argument, niż "niewiele widziałeś".

    > Żeby nie było: w C++ da się osiągnąć niezły code reuse, ale czasem
    > sensowne zrobienie tego wymaga ostrego lawirowania między dziedziczeniem
    > klas a szablonami.

    Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy bilans.

    > > Innym przykładem może być np. serializacja, ale ponieważ
    > > temat serializacji pojawia się w systemach rozproszonych, które
    > > zwykle są heterogeniczne, to i tutaj mało mnie interesuje, co mi ma
    > > do zaoferowania jakiś jeden język, bo zwykle co by nie miał, to i tak
    > > nie rozwiązuje to problemu heterogeniczności.
    >
    > Można tak zrobić system rozproszony, żeby nie był heterogeniczny.

    Dlaczego? Po co? Żeby móc powiedzieć, że jakiś jeden język jest OK?
    Jednym z celów rozpraszania jest wykorzystanie zalet różnych technologii, bo różne
    technologie mają swoje mocne punkty w różnych częściach całości.

    Czyli znowu mamy podobny argument: co z tego, że język dynamiczny daje fajną
    serializację w homogenicznym systemie rozproszonym, skoro nie robię homogenicznych
    systemów rozproszonych. Ten argument może być niewygodny, ale jest realny i oznacza,
    że w realu wartość dodana dynamicznego systemu typów jest mniejsza, niż się
    reklamuje.

    > Poza tym jest też taki dyanmiczny język specjalnie zaprojektowany do
    > pisania homogenicznych systemów rozproszonych jakim jest Erlang.

    I jego też nie użyję z powodu tego samego argumentu?

    Tak, wiem, że ktoś takie systemy pisze. Ale *ja* nie piszę, więc Erlang rozwiązuje
    problem, którego nie mam a tych, które mam, nie rozwiązuje.

    > >> loose coupling
    >
    > > Daję radę bez dynamicznego systemu typów.
    >
    > Nie chodzi o to, czy daje radę, tylko czy jest wygodne, łatwe i proste.

    Całe programowanie obiektowe powstało po to, żeby mieć loose coupling, więc nie widzę
    tu problemu. Realizacja OO w mainstreamowych językach sprawia, że jest to zarówno
    wygodne, łatwie i proste.

    > W jęyku dynamicznie typowanym też nie potrzebujesz takiego unit testu,
    > bo skoro masz test, który testuje, to, co robi foo, kiedy wywołuje bar z
    > tą liczbą parametrów, to on automatycznie sprawdza też, że może zawołać
    > z taką listą, z jaką woła.

    Zakładając pokrycie 100%. Bo tylko wtedy faktycznie zawoła.
    Testy z pokryciem 100% są bardzo kosztowne.

    > > Nabijam się, ale na poważnie: nie raz dostałem po gałach różnymi
    > > komunikatami, które ładnie zdradzały w czym dany serwis został
    > > ulepiony, więc potwierdzam: faktycznie, masz rację, pisze się.
    >
    > I co, wyjątków z Javy nie widujesz?

    A czy ja gdzieś w tej dyskusji napisałem, że Java jest dla mnie statycznym językiem?

    (Wyprzedzam następne pytanie: w C++ i w Adzie też wyjątki widuję.)

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


  • 135. Data: 2013-02-11 17:24:41
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "M.M." <m...@g...com>

    W dniu poniedziałek, 11 lutego 2013 10:49:54 UTC+1 użytkownik Maciej Sobczak napisał:

    > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy bilans.
    Właśnie to jest to. Chodzi o bilans końcowy. Zdaje się, że nikt (łącznie
    ze mną) nie potrafi w tej dyskusji podać argumentów które by przekonywały
    o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
    korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
    pomiędzy asemblerem a językiem wysokiego poziomu.

    Dwa posty wyżej zauważyłem zaletę dynamicznego typowania: można uruchomić
    program z błędami, można eksperymentować na tej części działającej, a
    dopiero po zakończeniu eksperymentów poprawiać części pozostałe. Jest
    to ewidentna zaleta, bo po co za każdym razem dostosowywać cały program
    z GUI włącznie, jeśli nie ma jeszcze pewności czy logika zadziała
    zgodnie z przewidywaniami. Nie trzeba gdzieś na boku zakładać pomocniczego
    projektu z prototypem.

    Skupiając się na problemie, widzimy niezaprzeczalną zaletę, wręcz dodatkową
    możliwość jaką daje typowanie dynamiczne. Jednak nie wiem, czy takie
    skupianie się jest dobre, raczej jest złe. Liczy się właśnie bilans
    końcowy, a w tym bilansie pojawia się brak komunikatów o błędach ze strony
    kompilatora.

    Pozdrawiam


  • 136. Data: 2013-02-11 18:41:42
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: firr kenobi <p...@g...com>

    W dniu poniedziałek, 11 lutego 2013 17:24:41 UTC+1 użytkownik M.M. napisał:
    > W dniu poniedziałek, 11 lutego 2013 10:49:54 UTC+1 użytkownik Maciej Sobczak
    napisał:
    >
    >
    >
    > > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy bilans.
    >
    > Właśnie to jest to. Chodzi o bilans końcowy. Zdaje się, że nikt (łącznie
    >
    > ze mną) nie potrafi w tej dyskusji podać argumentów które by przekonywały
    >
    > o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
    >
    > korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
    >
    > pomiędzy asemblerem a językiem wysokiego poziomu.
    >
    >
    >
    > Dwa posty wyżej zauważyłem zaletę dynamicznego typowania: można uruchomić
    >
    > program z błędami, można eksperymentować na tej części działającej, a
    >
    > dopiero po zakończeniu eksperymentów poprawiać części pozostałe. Jest
    >
    > to ewidentna zaleta, bo po co za każdym razem dostosowywać cały program
    >
    > z GUI włącznie, jeśli nie ma jeszcze pewności czy logika zadziała
    >
    > zgodnie z przewidywaniami. Nie trzeba gdzieś na boku zakładać pomocniczego
    >
    > projektu z prototypem.
    >
    >
    >
    > Skupiając się na problemie, widzimy niezaprzeczalną zaletę, wręcz dodatkową
    >
    > możliwość jaką daje typowanie dynamiczne. Jednak nie wiem, czy takie
    >
    > skupianie się jest dobre, raczej jest złe. Liczy się właśnie bilans
    >
    > końcowy, a w tym bilansie pojawia się brak komunikatów o błędach ze strony
    kompilatora.
    >

    Zeby moc o tym pogadac z sensem, nalezalo by
    mz podac przyklad konkretnego kawałka kodu
    ktory w wydaniu wewnetrznietypowym jest
    ladniejszy i prostszy niz w wersji z twardymi
    typami.
    Cos takiego pewnie da sie podac ale akurat ja
    jak wspomnialem prawie wogole nie mam doswiadczen z yakimi kodami, totez zeby cos
    ttakiego podac musialbym sie troche pewnie
    nadlubac (nazastanawiac).

    Mz teki jezyk z ukrytymi automatycznymi typami
    ma jednak racje bytu, takie kodowanie byloby tez inne niz to z twardymi typami,
    bardziej
    abstrakcyjne np moge sobie wyobrazic komendy
    (funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju abstrakcyjne wobec
    konkretnych typow pojecia, ktorymi mozna by pisac uniwersalne programy na
    uniwersalnych 'kontentach' zupelnie niezaleznie od ich typu - bylby to bardziej
    wysokopoziomowy paradygmat
    niz ten z twardymi typami


  • 137. Data: 2013-02-11 18:55:19
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "M.M." <m...@g...com>

    W dniu poniedziałek, 11 lutego 2013 18:41:42 UTC+1 użytkownik firr kenobi napisał:
    > Zeby moc o tym pogadac z sensem, nalezalo by
    > mz podac przyklad konkretnego kawałka kodu
    > ktory w wydaniu wewnetrznietypowym jest
    > ladniejszy i prostszy niz w wersji z twardymi
    > typami.
    Tak na szybko tez nie potrafie zrobic takiego opracowania. Watpie aby
    to mogl byc maly kawalek. Rozmawiamy o trudnosciach jakie pojawiaja sie
    przy zarzadzaniu duzymy projektami i o tym jak jezyk moze pomagac.


    > (funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju
    Zgadza sie, w jezyku bez dynamicznych typow, trzeba sobie radzic
    inaczej - pytanie czy "to jest warte tego".

    Pozdrawiam


  • 138. Data: 2013-02-11 19:18:11
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: firr kenobi <p...@g...com>

    W dniu poniedziałek, 11 lutego 2013 18:55:19 UTC+1 użytkownik M.M. napisał:
    > W dniu poniedziałek, 11 lutego 2013 18:41:42 UTC+1 użytkownik firr kenobi napisał:
    >
    > > Zeby moc o tym pogadac z sensem, nalezalo by
    >
    > > mz podac przyklad konkretnego kawałka kodu
    >
    > > ktory w wydaniu wewnetrznietypowym jest
    >
    > > ladniejszy i prostszy niz w wersji z twardymi
    >
    > > typami.
    >
    > Tak na szybko tez nie potrafie zrobic takiego opracowania. Watpie aby
    >
    > to mogl byc maly kawalek. Rozmawiamy o trudnosciach jakie pojawiaja sie
    >
    > przy zarzadzaniu duzymy projektami i o tym jak jezyk moze pomagac.
    >
    >
    >
    >
    >
    > > (funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju
    >
    > Zgadza sie, w jezyku bez dynamicznych typow, trzeba sobie radzic
    >
    > inaczej - pytanie czy "to jest warte tego".
    >

    mz jest warte ale w pewnym obszarze
    zastosowan (mniej biblioteki zwł graficzne
    czy inne gdzie potrzebna jest wydajnosc)
    a bardziej kod userski ze tak to nazwe

    Mz niekoniecznie duze projekty maly
    przyklad tez na pewno mozna podac

    Inna kwestia to czy dynamiczne typowanie
    i jezyki sktyptowe to wlasciwie jedno i to
    samo czy nie - nie bardzo kojarze ktore
    jezyi nie bardzo daja sie kompilowac ale
    mozliwe ze wlasnie te z dynamicznym typowaniem
    co by wyznaczalo moze cos w rodzaju znaku
    rownosci miedzy tymi sprawami;


  • 139. Data: 2013-02-12 00:19:46
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    On 11/02/2013 09:49, Maciej Sobczak wrote:
    > W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej
    > Jarzabek napisał:
    >
    >>> Co z tego, że pokazuje, skoro przez swoją dynamiczność nie dałbym
    >>> mu szansy się wykazać.
    >>
    >> To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
    >> zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym
    >> nie zdecydował się użyć jej do pisania czegoś takiego".
    >
    > Tak, to jest dokładnie taki argument.

    No to odpowiem: ty nie dałbyś, ale kto inny dał. Tajemnica wyjaśniona?

    > Poza tym, że obiektowość powstała z myślą o dużych systemach

    W którym momencie?

    > i sama w sobie nie ma cech, który by były z nimi sprzeczne.

    http://c2.com/cgi/wiki?ArgumentsAgainstOop
    http://folk.uio.no/andersmo/oo.html

    >>>> Pozwala, ale są inne sposoby, które też pozwalają.
    >>> Droższe?
    >>
    >> Nie wiem nawet, jak to porównać. Chodzi o zupełnie inny paradygmat
    >> pisania programów,
    >
    > Droższy? Bardziej efektywny? Czy jedynie "też pozwala"?

    Zapewne zależy kto, co i w jakim języku.

    > Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.

    A dlaczego akurat to dynamiczny, a nie statyczny system typów to jest
    "inaczej"?

    >>> Jak do tej pory jedyny code reuse między różnymi typami widywałem
    >>> w kontenerach
    >>
    >> To niewiele widziałeś.
    >
    > Możliwe, ale nie czuję się tym pokrzywdzony a skoro tak, to
    > najwyraźniej nic nie straciłem, że nie widziałem. Poproszę o lepszy
    > argument, niż "niewiele widziałeś".

    Poproszę o lepszy argument, niż "nie widziałem".

    >> Żeby nie było: w C++ da się osiągnąć niezły code reuse, ale czasem
    >> sensowne zrobienie tego wymaga ostrego lawirowania między
    >> dziedziczeniem klas a szablonami.
    >
    > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy
    > bilans.

    I uważasz, że potrafisz ten bilans policzyć?

    >>> Innym przykładem może być np. serializacja, ale ponieważ temat
    >>> serializacji pojawia się w systemach rozproszonych, które zwykle
    >>> są heterogeniczne, to i tutaj mało mnie interesuje, co mi ma do
    [...]
    >> Można tak zrobić system rozproszony, żeby nie był heterogeniczny.
    >
    > Dlaczego? Po co? Żeby móc powiedzieć, że jakiś jeden język jest OK?

    Na przykład dlatego, że nie ma potrzeby robić go heterogenicznym, a
    heterogeniczność pociąga koszta.

    > Jednym z celów rozpraszania jest wykorzystanie zalet różnych
    > technologii, bo różne technologie mają swoje mocne punkty w różnych
    > częściach całości.

    Ale to tylko jeden z celów. Są inne powody, jak wykorzystanie zasobów
    (mocy obliczeniowej, pamięci, dysku, przepustosości połączeń
    sieciowych), wysoka niezawodność (redundancja), globalne rozproszenie
    (żeby klient ze Stanów nie musiał się łączyć z serwerem w Europie) i tak
    dalej.

    Poza tym pozostańmy nawet przy heterogeniczności. Dość popularnym
    rozwiązaniem z językami dynamicznymi jest Javascript w przeglądarce i
    jakiś Python czy inny Ruby na serwerze. W celu serializacji obiektów i
    przesyłania ich przez sieć wymyślono format JSON - dzięki niemu można z
    łatwością serializować dane w Pythonie i przesyłać do javascriptowego
    klienta lub odwrotnie. Można to spokojnie robić bez potrzeby
    uzgadaniania definicji typów pomiędzy serwerem a klientem - każda strona
    korzysta z tych właściwości, jakich potrzebuje, i każda jest w stanie
    wziąć odserializowany obiekt i zserializować go z powrotem razem ze
    wszystkimi polami/właściwościami, nawet jeśli nie były one jeszcze
    zdefiniowane w momencie pisania tego kodu.

    > Czyli znowu mamy podobny argument: co z tego, że język dynamiczny
    > daje fajną serializację w homogenicznym systemie rozproszonym, skoro
    > nie robię homogenicznych systemów rozproszonych. Ten argument może
    > być niewygodny, ale jest realny i oznacza, że w realu wartość dodana
    > dynamicznego systemu typów jest mniejsza, niż się reklamuje.

    Argument, że czegośtam nie robisz jest tyle realny, co mało znaczący.
    Dla każdej rzeczy istnieje taki ktoś, kto jej nie robi.

    >> Poza tym jest też taki dyanmiczny język specjalnie zaprojektowany
    >> do pisania homogenicznych systemów rozproszonych jakim jest
    >> Erlang.
    >
    > I jego też nie użyję z powodu tego samego argumentu?
    >
    > Tak, wiem, że ktoś takie systemy pisze. Ale *ja* nie piszę, więc
    > Erlang rozwiązuje problem, którego nie mam a tych, które mam, nie
    > rozwiązuje.

    No ale przecież ja się o twoich problemach nie wypowiadam. Chyba że, jak
    M.M. uważasz, że jak tobie coś nie jest potrzebne, to w ogóle nie jest
    potrzebne.

    BTW można się zastanowić nad faktem, że dynamicznie typowany Erlang jest
    przeznaczony do, i używany w systemach wysokiej niezawodności.

    >>>> loose coupling
    >>> Daję radę bez dynamicznego systemu typów.
    >> Nie chodzi o to, czy daje radę, tylko czy jest wygodne, łatwe i
    >> proste.
    >
    > Całe programowanie obiektowe powstało po to, żeby mieć loose
    > coupling, więc nie widzę tu problemu. Realizacja OO w mainstreamowych
    > językach sprawia, że jest to zarówno wygodne, łatwie i proste.

    Nie jest. Prosty przykład - w C++ nawet niewielka zmiana definicji typu
    danych między biblioteką a programem z niej korzystającym może
    spowodować spektakularne wylecenie wszystkiego w powietrze. W Javie jest
    trochę lepiej, ale próby ładowania różnych wersji klasy też mogą się
    niedobrze skończyć. No i oczywiście rozpraszanie czegokolwiek to osobny
    cyrk, wymagający opakowania w wiele warstw, IDL-i, WSDL-i, XML schema i
    nie wiadomo czego jeszcze.

    >> W jęyku dynamicznie typowanym też nie potrzebujesz takiego unit
    >> testu, bo skoro masz test, który testuje, to, co robi foo, kiedy
    >> wywołuje bar z tą liczbą parametrów, to on automatycznie sprawdza
    >> też, że może zawołać z taką listą, z jaką woła.
    >
    > Zakładając pokrycie 100%. Bo tylko wtedy faktycznie zawoła. Testy z
    > pokryciem 100% są bardzo kosztowne.

    Nie musisz mieć pokrycia 100%, wystarczy pokrycietego kawałka kodu, w
    którym foo woła bar. To nie powinno być takie trudne, bo jako
    programista wiesz przecież, dlaczego foo woła bar (jeśli nie wiesz, to
    statyczne typowanie cię nie uratuje) i w związku z tym niezależnie od
    tego, czy woła i z jakimi parametrami masz unit test testujący ten
    kawałek funkcjonalności foo.

    Poza tym niemal 100% pokrycie unit testami (z wyjątkiem cienkich warstw
    owijających przekraczanie granic systemu, które można pokryć integration
    testami) jest bardzo tanie, jeśli stosuje się TDD. A ponieważ w
    większości przypadków TDD jest tańsze niż alternatywy, to wysokie
    pokrycie unit testami jest po prostu tak tanie, że aż ma koszt ujemny.

    >>> Nabijam się, ale na poważnie: nie raz dostałem po gałach różnymi
    >>> komunikatami, które ładnie zdradzały w czym dany serwis został
    >>> ulepiony, więc potwierdzam: faktycznie, masz rację, pisze się.
    >> I co, wyjątków z Javy nie widujesz?
    >
    > A czy ja gdzieś w tej dyskusji napisałem, że Java jest dla mnie
    > statycznym językiem?

    W myśl powszechnie rozumianego podziału na dynamiczne i statyczne
    systemy typów, Java jest językiem o typowaniu statycznym.

    > (Wyprzedzam następne pytanie: w C++ i w Adzie też wyjątki widuję.)

    Na stronach WWW nie widać wyjątków z C++ bo:
    a) praktycznie nigdzie nie stosuje się C++ do aplikacji webowych,
    b) jak już w C++ coś poleci, to raczej UB i kompletne wywrotka niż
    niezłapany wyjątek.

    Z Adą myślę, że w punkcie a) jest podobnie, tylko bardziej, w związku z
    czym ewentualność punktu b) staje się nieistotna.


  • 140. Data: 2013-02-12 00:23:54
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    On 11/02/2013 16:24, M.M. wrote:
    [...]
    > o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
    > korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
    > pomiędzy asemblerem a językiem wysokiego poziomu.

    A ktoś twierdził, że jest?

    > Skupiając się na problemie, widzimy niezaprzeczalną zaletę, wręcz dodatkową
    > możliwość jaką daje typowanie dynamiczne. Jednak nie wiem, czy takie
    > skupianie się jest dobre, raczej jest złe. Liczy się właśnie bilans
    > końcowy, a w tym bilansie pojawia się brak komunikatów o błędach ze strony
    kompilatora.

    On działa w obydwie strony, bo jeśli logika jest OK, tylko hierarchia
    typów błędnie mapuje dziedzinę, to też masz błędy kompilatora.

strony : 1 ... 13 . [ 14 ] . 15 ... 20


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: