eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJakie typowanie jest najlepsze i dlaczego statyczne?Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
  • Data: 2013-02-15 01:08:08
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 14/02/2013 09:22, Maciej Sobczak wrote:
    > W dniu czwartek, 14 lutego 2013 09:18:03 UTC+1 użytkownik Andrzej
    > Jarzabek napisał:
    >
    >> OO w realizacji takiej jak Java/C++ ma dokładnie takie same
    >> problemy ze współbieżnością co programowanie
    >> strukturalne/proceduralne, którego jest prostym rozwinięciem.
    >
    > Ale to nie jest wina OO, tylko tego rozwinięcia.

    To rozwinięcie to właśnie OO (w popularnym znaczeniu). W kwestii czy coś
    ma cechy przeszkadzające, czy nie ma, nie jest istotne, czyja to wina
    ani czy co innego ma takie same problemy.

    > Ja nadal nie widzę w OO niczego, co by miało mieć problem ze
    > współbieżnością.

    No przecież właśnie cały model, gdzie możesz mieć równolegle działający
    kod który ma dostęp do tego samego zmiennego stanu jest tym problemem.
    No chyba że powiesz, że w rzeczywistości w dużych systemach napisanych w
    językach wspierających OO błędy polegające na data races, deadlocks,
    livelocks i tym podobnych atrakcjach nie są poważnym problemem, bo
    zdarzają się niezmiernie rzadko, a jak już się zdarzą, to są łatwe do
    zdiagnozowania, znalezienia i poprawienia.

    >> Wszystkie te paradygmaty mają problem ze współbieżnością, który
    >> jest związany z dzieleniem stanu,
    >
    > Ja nie widzę niczego w OO, co zmuszałoby mnie do dzielenia stanu a
    > tam, gdzie chciałbym stan dzielić, będę musiał to zrobić niezależnie
    > od paradygmatu.

    W asemblerze też nie ma niczego, co cię zmusza do popełniania błędów, po
    prostu łatwo zrobić to przypadkowo. W momencie, kiedy masz w programie
    współbieżność opartą na wątkach, to znalezienie w paradygmacie OO miejsc
    gdzie dzielisz stan między wątkami jest w ogólnym przypadku nietrywialne.

    W innych paradygmatach może być tak, że albo w ogóle nie możesz dzielić
    stanu, albo masz stan wyizolowany w specjalnych konstrukcjach (powiedzmy
    - monadach), i wtedy kompilator czy runtime na podstawie wiedzy czy
    program się wykonuje współbieżnie i które funkcje odwołują się do
    których monad może automatycznie dać locki na wszystkich operacjach na
    owych monadach.

    >> Również "modelowy" OO, chociaż opiera się na dzieleniu stanu,
    >
    > W którym miejscu się opiera?

    W tym miejscu, że obiekty są z założenia "stateful", że klient obiektu
    może dowiadywać się i modyfikować jego stan i że ten sam obiekt może
    mieć wielu klientów.

    >> Przecież Python nie nadaje się do systemów czasu rzeczywistego i w
    >> ogóle słabo do systemów embedded (wymaga interpretera i sporego
    >> wsparcia systemu operacyjnego).
    >
    > A jakiś dynamiczny język nie wymaga?

    Lisp i Prolog na pewno. Poza tym Lisp, nawet z interpreterem może
    chodzić z powodzeniem na malutkim i słabiutkim komputerku i z
    powodzeniem był wykorzystywany w robotyce i nawet w sondach kosmicznych.

    >> W skrócie - nie mam nic do powiedzenia w kwestii czego używać do
    >> tworzenia oprogramowania w przypadku, kiedy używa się metod
    >> formalnych, ale czego by się nie używało, nie przyjmę tego za
    [...]
    >
    > Dowód polega na tym, że nie da się powiedzieć, w którym momencie już
    > używa się metod formalnych a w którym się nie używa. Np. ja używam
    > metod formalnych kompilując program w C++ - kompilator sprawdza tyle
    > ile umie i mówi mi, co zrobiłem źle - mogę go nawet poprosić, żeby
    > tylko sprawdzał i nawet nie generował kodu. Granica jest tu płynna i

    Ach, przepraszam, myślałem, że masz na myśli to, co się powszechnie
    nazywa metodami formalnymi. To, że nie można dokładnie powiedzieć, od
    ilu włosów ktoś jest łysy, to nie znaczy, że łysym jest każdy.

    Jeśli w całej dygresji o metodach formalnych chodziło o to, że w
    językach ze statycznym systemem typów kompilator statycznie sprawdza
    typy, to chyba powinieneś zgłosić się po jakąś nagrodę za najbardziej
    zawiły i okrężny sposób na stwierdzenie oczywistej oczywistości.

    > ta płynność objawia się też dostępnością narzędzi, które oferują
    > różne poziomy weryfikacji.

    Jak pisałem, nie znam się na tym i pewnie się mylę, ale normalnie np.
    taki Lisp (czy jego podzbiory/dialekty) czy Prolog (czy jego warianty)
    są znacznie łatwiejsze do analizowania faktycznymi metodami formalnymi
    niż Java czy C++. Dostępność narzędzi prawodopodobnie jest faktycznie
    większa dla Javy i C++, po prostu dlatego, że są bardziej popularne.

    Przy czym oczywiście jest to znakomity argument - jeśli potrzebujesz
    formalnej weryfikacji, to faktycznie może lepiej użyć nawet bardziej
    błedogennych i trudniejszych w takiej weryfikacji języków Java i C++, po
    prostu dlatego, że są do nich lepsze narzędzia, niż języków mniej
    błędogennych, ale mniej popularnych i przez to z mniejszą dostępnością
    takich narzędzi. Dotyczy to również statycznie typowanych języków
    programowania, które nawet mogą mieć bardziej zaawansowane i bardziej
    bezpieczne typowanie - jak Haskell czy ML - czy nawet Ada. Dodatkowo,
    może to też oznaczać, że być może jeśli wymagasz formalnej weryfikacji,
    to Java jest lepsza niż C++, bo do Javy jest więcej narzędzi do tego
    (nie wiem, czy faktycznie jest więcej, ale załóżmy, że tak).

    > Czyli język statyczny pozwala mi używać
    > metod formalnych na różnych poziomach, zależnie od moich potrzeb i
    > umiejętności - w szczególności mogę dołożyć nowe narzędzie w trakcie
    > trwania projektu. Oczywiście różne języki różnie to wspierają, ale
    > statyczne wypadają tu znacznie lepiej, niż dynamiczne.

    No właśnie czy nie jest tak, że uważana przez Ciebie za dynamiczną Java
    wypada bardzo dobrze?

    Poza tym jak mówię - nie wiem jak jest w systemach do sterowania
    samolotami, ale poza tym nawet w biznesowych systemach obracających
    dużymi pieniędzmi to, co się powszechnie nazywa metodami formalnymi
    (czyli nie zwykłe static checkery czy kompilatory) stosuje się raczej
    niezwykle rzadko - obiegowa opinia jest taka, że się nie opłaca. Tym
    bardziej chyba dotyczy to dużych systemów - im większy system, tym
    bardziej się nie opłaca. Tak więc przy wyborze języka dla powiedzmy
    systemu bankowego czy serwisu webowego pytanie, czy dany język ma dużo
    narzędzi do automatyzacji formalnego dowodzenia poprawności programu
    jest na dalekim, bardzo dalekim miejscu.

    Jeśli chodzi o prostsze narzędzia, jak kontrola poprawności typów w
    kompilatorze, czy programy do statycznej analizy kodu, to nikt nie
    przeczy, że mają one jakąś tam wartość. Czy ta wartość zawsze przeważy
    zalety dynamicznych językó i koszta statycznego typowania. No i tak samo
    jak przy metodach formalnych, powstaje pytanie, czy w takiej sytuacji
    nie jest znowu najlepsza Java, bo ma najwięcej programów do statycznej
    analizy.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: