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-13 10:10:38
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Maciej Sobczak <s...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    W dniu wtorek, 12 lutego 2013 20:14:34 UTC+1 użytkownik Andrzej Jarzabek napisał:

    > > > > Poza tym, że obiektowość powstała z myślą o dużych systemach
    > > > W którym momencie?
    >
    > > W takim, że w małych nie było powodów, żeby powstała.
    >
    > Kto konkretnie, kiedy i co takiego zrobił z myślą o dużych systemach?
    >
    > Bo mi wygląda na to, że opowiadasz o wymyślonej przez siebie historii
    > OO, a nie tej, która faktycznie miała miejsce.

    Bo ta, która miała miejsce, absolutnie nie dotyczyła dużych systemów, tylko systemów
    sztucznej inteligencji i symulacji? Bo, jak wszyscy wiedzą, sztuczna inteligencja i
    symulacje to malutkie programiki, i właśnie w takim kontekście wymyślono OO, żeby te
    malutkie programiki pisało się jeszcze fajniej?

    W sumie - znowu nie rozwijamy dyskusji, więc nie będę się sprzeczał.

    > > Przewinąłem losowo i trafiłem na argument "OO runs too slow",
    >
    > > Przewinąłem losowo i trafiłem na argument "Everything has to be an object".
    >
    > Poszczególne argumenty odnoszą się do różnych definicji
    > obiektowości...

    Do jakich? Nie napisali a ja nie znam żadnej definicji, do której przykładowe dwa
    argumenty by się odnosiły.

    > Technicznie nawet assembler nie posiada cech sprzecznych z dużymi
    > systemami,

    Ma, bo przez brak czytelnego wsparcia dla tworzenia abstrakcji nie sprzyja tworzeniu
    projektów, które można łatwo rozwijać w długiej perspektywie a oprócz abstrakcji w
    długiej perspektywie i przy dużych rozmiarach pojawia się też temat przenośności, w
    czym asembler nie błyszczy. To są powody techniczne.

    > To czy owo może posiadać cechy przeszkadzające albo pomocne w pisaniu
    > dużych systemów, ale to kategorie subiektywne - cechy przeszkadzające
    > komuś lub pomocne dla kogoś.

    Niech będzie, że wszystko co napisałem, jest subiektywne.

    > Przy takim pytaniu nie da się przecież odpowiedzieć abstrakcyjnie:
    > zarówno C++ jak i Java mają swoje ograniczenia, każdy projekt ma swoje
    > okoliczności. Jeśli np. chcesz mieć UI w przeglądarce, to możesz
    > zaimplementować go:
    >
    > * w dynamicznym Javascript
    > * jako aplikacja flashowa w dynamicznym actionScript czy jak to się
    > tam nazywa
    > * jako applet Javowy
    > * w C++ jako komponent ActiveX
    >
    > Nie powiesz chyba, że skoro używasz już C++ albo Javy, to rozwiązanie
    > z tym właśnie językiem jest oczywistym wyborem.

    Nie jest.
    Mogę jedynie ubolewać, że w kategorii "UI w przeglądarce" rynek nie wypracował
    safysfakcjonyjących rozwiązań. Niektórzy pokładają nadzieje w HTML5, ale to tylko
    czas pokaże, czy te nadzieje się spełnią.

    > Inny przykład, tym razem z osobistego doświadczenia: miałem rozbudować
    > możliwości programowania narzędzia testowego napisanego w Javie.
    > Zdecydowałem się zrobić to przez dodanie DSL-a. Żeby zrobić to szybko,
    > postanowiłem zaimplementowac embedded DSL i wybrałem do tego język
    > Groovy,
    [...]

    Tak, też tego używamy.

    > Czy w takiej sytuacji byś uznał, że wprowadzenie języka dynamicznie
    > typowanego do projektu w mainstreamowej Javie ma sens?

    Może mieć sens. Podobnie jak w samym kontekście mógłby mieć sens np. JPython. Albo co
    tam komu lepiej leży w ręku.

    Przecież nie napisałem, że języki dynamiczne powinny być zakazane.

    > Nawiasem mówiąc, w nawiązaniu do odnogi dyskusji o wprowadzaniu
    > języków programowania przez programistę, najlepszy sposób uwalenia
    > dowolnej inicjatywy innowacyjnej to zażądanie przedstawienia bilansu.
    > Na zasadzie: "postawiliśmy checkboxa dla Scali bo ma lambdy? Proszę o
    > konkretny dowód na to, że języki z lambdami są mniej błedogenne niż
    > języki bez lambd".

    To bardzo dobry argument. Dlatego nie wprowadziłbym Scali dlatego że ma lambdy myśląc
    o mniejszej błędogenności.

    > Bo bilans wyciągnięty z odbytu to każdy potrafi pokazać.

    Owszem. Ale ja naprawdę chcę wiedzieć, dlaczego będzie lepiej.
    Bo jeśli nie wiem, to będzie to na zasadzie "spróbujmy" - i to też jest bardzo dobra
    zasada, podobna np. do kupowania na pałę akcji losowych firm na giełdzie. Są tacy, co
    tak robią i bywa nawet, że na tym zyskują. Kluczowym hasłem jest to zarządzanie
    ryzykiem - im więcej wiem, tym łatwiej jest tym ryzykiem zarządzać.

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

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: