eGospodarka.pl
eGospodarka.pl poleca

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

  • 21. Data: 2013-02-01 11:50:46
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "M.M." <m...@g...com>

    W dniu piątek, 1 lutego 2013 09:47:05 UTC+1 użytkownik Maciej Sobczak napisał:

    > Inaczej: "programista" to zawód; "programista Javy" to ograniczenie.
    > (Tak, oprócz ideałów znam też realia.)

    Ograniczenie kojarzy się negatywnie, tymczasem znajomość ogromnej
    ilości języków nie jest zaletą. Znajomość kilku języków programowania
    jest na tyle dobra, na ile warto do specjalistycznej klasy zadań
    stworzyć nowy (specjalistyczny) język, zamiast posługiwać się
    jakimś ogólnym. Zdecydowanie większą zaletą jest znajomość jednego,
    może dwóch ogólnych języków, ale wraz z ogromną ilością bibliotek i
    narzędzi. Przynajmniej z takimi realiami się spotkałem.

    Pozdrawiam


  • 22. Data: 2013-02-01 14:17:06
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "Bastion" <n...@m...pl>


    Użytkownik "Wojciech Muła" <w...@g...com> napisał w wiadomości
    news:fa8da6c1-4880-48d4-9c18-6d5628ce2174@googlegrou
    ps.com...
    Ahoj, przeglądam sobie czasem changelogi postgresa, gcc
    i innych dużych programów i mam nieodparte wrażenie, że
    spory odsetek błędów nigdy by nie powstał, gdyby program
    był pisany w języku z silnym systemem typów (czyli nie
    C/C++).

    Nie wiem czy odpowiem na Twoje pytanie.
    W asemblerze latwiej wywalic OS niz napisac co dzialajacego.
    Natomiast programujac w jezykach wysokopoziomowych- np. Java,
    trudno cos napisac, tak zeby celowo spowodowac zawieszenie/restart OS.

    Czyli programowanie wysoko poziomowe w duzym stopniu
    eliminuje prawdopodobienstwo bledu.



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

    On 31/01/2013 09:14, Maciej Sobczak wrote:
    > W dniu środa, 30 stycznia 2013 19:58:00 UTC+1 użytkownik Andrzej Jarzabek napisał:
    >
    >>>> Poza tym kto ma decydować, które cechy
    >>>> dokładnie się znajdą na tej liście, a które nie?
    >>
    >>> Może ci sami goście, którzy potem będą tego języka używać?
    >>
    >> Są dwa problemy. Pierwszy teoretyczny: skoro nie wiadomo jaki język
    >> zostanie wybrany, to nie wiadomo, kto będzie go używać. Bo np. w
    >> zależności od wybranego języka będzie go używać ten, co go zna.
    >
    > Bo *z założenia* wykluczamy podwyższanie kwalifikacji, szkolenia, itd.?
    > Ja bym nie wykluczał.

    Ja z kolei nie bardzo widzę ww praktyce sytuację, kiedy oragnizacja, w
    której pisze się w np. C++ i w której wszyscy znają C++ nagle po
    wielokryteriowej analizie dochodzi do wniosku, że następny system klassy
    safety-critical będzie tworzony w, powiedzmy, Adzie.

    > Zwłaszcza, że mówimy o branżach, gdzie decyzje mają dłogofalowe efekty.
    > Taki samolot albo satelita ma czas życia +15 lat (albo i 40), więc należy
    > wziąć pod uwagę również taki drobiazg, że ci goście co projekt zaczną,
    > prawdopodobnie nie będą go kończyć [*]. Wtedy fakt, że *ktoś* *dzisiaj*
    > zna tylko JavaScripta ma mniejszą wagę, niż się zwykle sądzi.

    To, że nie będą kończyć ci sami ma mniejszą wagę, niż sądzisz. Przecież
    nigdy nie będzie takiej sytuacji, że wymienią na raz cały zespół, a
    tymczasem jeśli zaczniesz od tego, że robisz w technologii X, to
    będziesz dokooptowywać głównie ludzi, którzy znają technologię X, lub
    np. poznają ją stopniowo pracując w twojej organizacji na innych
    stanowiskach.

    Z drugiej strony przecież nie jest chyba tak, że do 40-letniego samolotu
    czy satelity klienci żądają masy nowych ficzerów w oprogramowaniu, a po
    iluś tam latach stabilnej funkcjonalności i regularnej eksploatacji
    ilość wykrywanych błędów też raczej nie jest znaczna, zwłaszcza że to
    podobno oprogramowanie safety critical.

    Z kolei przecież nawet teraz są ludzie znajdujący pracę przy
    programowaniu w COBOL-u i innych, jeszcze bardziej egzotycznych
    technologiach.

    >> Ale w związku z tym pojawia się
    >> praktyczny problem taki, że ci ludzie i tak wybiorą to, co znają i czego
    >> używa się w firmie, i cała zabawa z chekboxami nie ma zabawy, bo zawsze
    >> da się wybrać takie, żeby wygrało to, co ma wygrać.
    >
    > Tak, jest to problem, który jest trudny do wyeliminowania. Ale tak będzie z każdą
    inną metodą.

    Metoda "wszystko robimy w C++ więc to też zrobimy w C++" przynajmniej
    jest dużo mniej pracochłonna.

    >>> Coś jak z wyborem samochodu na flotę firmową - siadamy, piszemy wymagania,
    [...]
    >> Nieco chybiona analogia, bo jak ktoś potrafi prowadzić jeden samochód,
    >> to potrafi prowadzić każdy samochód.
    >
    > Zawsze myślałem, że wykształcony programista też jest zdolny do jakiejś tam
    > intelektualnej mobilności.

    Nie aż takiej, żeby dowolną nową umiejętność opanować w kwadrans.

    >> Mnie na przykład na to hasło nie dało na pierwszej stronie żadnych
    >> linków o porównywaniu języków, czy to checkboxamiczy inaczej (z
    >> wyjątkiem jakiegoś jednego artykułu za paywallem), natomiast grzebiąc
    >> znalazłem coś takiego:
    >>
    >> http://grouper.ieee.org/groups/plv/HISTORICAL-LINKS/
    Derek%20Reinhardt%20MSc%20SCSE%20Thesis%20%28Release
    %20Version%29.pdf
    >
    > Jest to jakiś input.

    Tylko że nic nie dający w temacie wyboru między różnymi językami.
    Owszem, jak już się robi w C++, to jest w tej pracy parę ciekawych
    rzeczy, np. dotyczących coding standards.

    > Każda metoda ma swoje wady. Metoda z checkboksami przynajmniej próbuje być
    obiektywna.

    Skoro dana metoda jest i tak subiektywna, to pretensje do obiektywności
    nie wydają mi się szczególną zaletą.


  • 24. Data: 2013-02-01 23:38:48
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    Hej, nie chciałbym być od razu na starcie nieuprzejmy, ale nie myślałem,
    że będę miał jeszcze okazję w życiu to napisać na newsach: Skonfiguruj
    sobie polskie literki w Outlooku.

    On 01/02/2013 13:17, Bastion wrote:
    >
    > Nie wiem czy odpowiem na Twoje pytanie.
    > W asemblerze latwiej wywalic OS niz napisac co dzialajacego.

    Współczesne OS-y raczej nie są takie łatwe do wywalenia z poziomu
    programu użytkownika.

    > Natomiast programujac w jezykach wysokopoziomowych- np. Java,
    > trudno cos napisac, tak zeby celowo spowodowac zawieszenie/restart OS.

    Przedstawiasz abstrakcyjny dylemat - w praktyce nigdy nie ma wyboru
    między asemblerem i Javą. Może być wybór między np. C a C++, C++ a
    Delphi, C++ a Adą, C++ a Javą, Javą a Scalą, Javą a Pythonem itd.

    > Czyli programowanie wysoko poziomowe w duzym stopniu
    > eliminuje prawdopodobienstwo bledu.

    Pomijając już kwestię zawieszenia czy restartu OS, to i tak jest to
    prawdą tylko o tyle, na ile dużą część błędów w programach stanowią
    błędy typu UB. Natomiast pomijając nawet błędy specyfikacji, jest dużo
    rodzajów innych błędów, a w szczególności z językiem związane są błędy
    wynikające z "zaskakującego zachowania".




  • 25. Data: 2013-02-02 22:42:58
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Maciej Sobczak <s...@g...com>

    W dniu piątek, 1 lutego 2013 11:50:46 UTC+1 użytkownik M.M. napisał:

    > > Inaczej: "programista" to zawód; "programista Javy" to ograniczenie.
    > > (Tak, oprócz ideałów znam też realia.)
    >
    > Ograniczenie kojarzy się negatywnie,

    Tak. Celowo.

    > tymczasem znajomość ogromnej
    > ilości języków nie jest zaletą.

    Nikt tutaj tego nie proponuje. Mówimy o znalezieniu języka, który spełnia nasze
    oczekiwania. Tzn. każdy z nas pewnie będzie miał inne oczekiwania, wynikające
    chociażby z interesującej nas branży, ale nigdzie nie pisaliśmy o znajomości
    "ogromnej ilości języków".

    > Znajomość kilku języków programowania
    > jest na tyle dobra, na ile warto do specjalistycznej klasy zadań

    Zadaniem było zmniejszyć ilość błędów. Nie wiem, czy jest to zadania specjalistyczne
    - chociaż większość ma to w d..., więc może faktycznie jest to specjalistyczne
    zagadnienie. :-)

    > Zdecydowanie większą zaletą jest znajomość jednego,
    > może dwóch ogólnych języków,

    No właśnie. Problem w tym, jak je wybrać.

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


  • 26. Data: 2013-02-02 23:11:20
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Maciej Sobczak <s...@g...com>

    W dniu piątek, 1 lutego 2013 22:59:00 UTC+1 użytkownik Andrzej Jarzabek napisał:

    > Ja z kolei nie bardzo widzę ww praktyce sytuację, kiedy oragnizacja, w
    > której pisze się w np. C++ i w której wszyscy znają C++

    Ja też nie bardzo widzę, bo nigdy nie widziałem takiego zespołu ani takiej
    organizacji (pomijam firmy typu "Java Systems Sp. z o.o."). Zwykle jest w zespole
    kilka równoległych kierunków tematycznych, może też kilka równoczesnych projektów w
    różnych fazach. Zwykle też ludzie dzielą się na tych z wiekszym stażem (często jest
    to staż z zewnątrz, bo w naszej branży jest spora rotacja) i na tych z mniejszym (oni
    *i tak* wymagają szkolenia), co też wprowadza różne możliwości rozwoju takich
    zespołów.
    W firmie, w której teraz pracuję, letko naliczyłem właśnie na palcach 10
    *równocześnie* używanych języków programowania. A naciągając fakty będzie 12.
    W takim zespole można już porozmawiać o porównaniach, refleksji nt. walorów różnych
    rozwiązań, optymalizacji dalszego kierunku, itd. Nie widzę problemu.

    > nagle po
    > wielokryteriowej analizie dochodzi do wniosku, że następny system klassy
    > safety-critical będzie tworzony w, powiedzmy, Adzie.

    Jeżeli była jakaś analiza i to jeszcze wielokryteriowa, to na pewno nie "nagle".
    Obstawiam raczej długotrwały proces refleksji i poszukiwania właściwych torów.

    To jest coś jak z wprowadzaniem nowej metodologii prowadzenia projektu. Cała nasza
    dotychczasowa dyskusja jest w mocy po zamianie słowa "język" na "metoda prowadzenia
    projektu". I tak np. wyobraź sobie, że są zespoły, które po jakiejś analizie i
    refleksji decydują się na wprowadzenia agile, scrum, czy co tam jeszcze, chociaż
    wcześniej nikt tego nie znał. A jednak robią to, z zapałem przewalając całą firmę do
    góry nogami (czasem dosłownie). I uwaga, bywa nawet, że robią w ten sposób postęp.
    Dlaczego taki zespół nie miałby zdecydować się na sięgnięcie po inny język? Nie widzę
    żadnego powodu.

    > To, że nie będą kończyć ci sami ma mniejszą wagę, niż sądzisz. Przecież
    > nigdy nie będzie takiej sytuacji, że wymienią na raz cały zespół, a
    > tymczasem jeśli zaczniesz od tego, że robisz w technologii X, to
    > będziesz dokooptowywać głównie ludzi, którzy znają technologię X, lub
    > np. poznają ją stopniowo pracując w twojej organizacji na innych
    > stanowiskach.

    Tak. Ciągłość techniczna to bardzo ważny argument. Dlatego możliwość łączenia języków
    jest tu istotna - np. to, że Scala potrafi wykorzystać istniejące klasy w Javie. Itp.
    To pozwala robić zmiany jednocześnie zachowując ciągłość.

    > Metoda "wszystko robimy w C++ więc to też zrobimy w C++" przynajmniej
    > jest dużo mniej pracochłonna.

    Ale jak już pisałem nie widziałem takiego zespołu.
    Oczywiście nie twierdzę, że takich nie ma.

    > > Zawsze myślałem, że wykształcony programista też jest zdolny do jakiejś tam
    > > intelektualnej mobilności.
    >
    > Nie aż takiej, żeby dowolną nową umiejętność opanować w kwadrans.

    Proces optymalizacji procesu technologicznego jest z założenia długotrwały. Agile też
    nie da się wprowadzić w kwadrans a jednak są zespoły, które się na to decydują. I
    bywa nawet, że robią w ten sposób postęp.

    Nie widzę problemu.

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


  • 27. Data: 2013-02-03 10:17:35
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "M.M." <m...@g...com>

    W dniu sobota, 2 lutego 2013 22:42:58 UTC+1 użytkownik Maciej Sobczak napisał:
    > W dniu piątek, 1 lutego 2013 11:50:46 UTC+1 użytkownik M.M. napisał:
    >
    >
    >
    > > > Inaczej: "programista" to zawód; "programista Javy" to ograniczenie.
    > > > (Tak, oprócz ideałów znam też realia.)
    > > Ograniczenie kojarzy się negatywnie,
    > Tak. Celowo.
    > Nikt tutaj tego nie proponuje. Mówimy o znalezieniu języka, który spełnia nasze
    oczekiwania.
    > Tzn. każdy z nas pewnie będzie miał inne oczekiwania, wynikające chociażby z
    interesującej nas branży,
    > ale nigdzie nie pisaliśmy o znajomości "ogromnej ilości języków".
    Ok. Myślałem, że dyskusja zbacza z toru i pozwoliłem sobie na coś o
    umiejętnościach programistów :)

    > Zadaniem było zmniejszyć ilość błędów. Nie wiem, czy jest to zadania
    > specjalistyczne - chociaż większość ma to w d..., więc może faktycznie
    > jest to specjalistyczne zagadnienie. :-)
    Zagadnienie jest rozległe i bywa dziwne. W pewnej klasie programów
    jakimi się zajmowałem przez pewien czas (chociażby szachy) usunięcie
    błędu często szkodziło. Tak, to chcę powiedzieć: wielokrotnie obserwowałem
    program który po usunięciu błędu działał gorzej.

    Jakie mamy rodzaje błędów? Można błędy jakoś pogrupować na jakieś
    kategorie? Chyba nie muszą to być kategorie rozłączne.

    1) Błędy algorytmiczne - czyli źle zapisany algorytm, a
    programiści myślą że jest dobrze zapisany.

    2) Błędy w dowodach - algorytm jest poprawnie zapisany, ale źle
    udowodniono że będzie działał poprawnie dla danego zbioru danych
    wejściowych.

    3) Błędy wynikające ze złego użycia lub niewystarczającej znajomości
    języka, typowy przykład: mylenie kolejności opracowania argumentów z
    kolejnością wykonywania działań.

    4) Błędy wynikające z ograniczeń sprzętu, przykład: jakby int pomieścił
    2^35 to program działałby poprawnie.

    Ostatnio wklepałem większy program w C++, a do niego jeszcze kilka
    mniejszych - powiedzmy że razem stanowiły pewien system. Po obdarciu z
    komentarzy miały one rozmiar około 1MB kodu. Miałem łącznie dwa błędy
    pierwszego rodzaju i jeden czwartego - na architekturze 64bit program
    działa poprawnie pomimo tego błędu (fragmentacja pamięci).

    Czy jakiś język uchroniłby mnie przed tymi błędami? Raczej nie. Jedyne
    coby pomogło, to mniejsza presja czasu, większy komfort psychiczny
    w pracy, mniej stresu, może szczegółowy projekt, itd.


    > > Zdecydowanie większą zaletą jest znajomość jednego,
    > > może dwóch ogólnych języków,
    > No właśnie. Problem w tym, jak je wybrać.
    Kurde... nie wiem :) Ja bym wybrał C++ albo Javę, inne
    język pod warunkiem żeby ktoś zasponsoruje mi edukację.

    Pozdrawiam


  • 28. Data: 2013-02-03 13:00:26
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: "AK" <n...@n...com>

    Użytkownik "M.M." <m...@g...com> napisał:

    > Czy jakiś język uchroniłby mnie przed tymi błędami?

    Tak.
    np. Algol/Simula.Fortran uchronilly by Cie od bledow 3go rodzaju, a np Python od 4go.

    PS: Przed bledami 1go i 2go rodzaju zaden jezyk nie uchroni,
    Nie ma takiego obowiazku., gdyz to nie sa bledy zwiazane z inzynieria programowanie
    (czyli m.in. z jezykami proigramowania). To sa po prostu bledy algorytmu.

    AK


    --- news://freenews.netfront.net/ - complaints: n...@n...net ---


  • 29. Data: 2013-02-03 17:07:12
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    On 02/02/2013 22:11, Maciej Sobczak wrote:
    > W dniu piątek, 1 lutego 2013 22:59:00 UTC+1 użytkownik Andrzej
    > Jarzabek napisał:
    >
    >> Ja z kolei nie bardzo widzę ww praktyce sytuację, kiedy
    >> oragnizacja, w której pisze się w np. C++ i w której wszyscy znają
    >> C++
    >
    > Ja też nie bardzo widzę, bo nigdy nie widziałem takiego zespołu ani
    > takiej organizacji (pomijam firmy typu "Java Systems Sp. z o.o.").

    Pewne uproszczenie oczywiście. Dla mnie normą też jest to, że jest kilka
    innych języków, ale każdy z nich ma swoją niszę. Jeśli jest to powiedzmy
    C++/Python, to np. nie pojawi się temat "czy zamiast Pythona nie lepiej
    byłoby używać Ruby".

    [...]
    > właśnie na palcach 10 *równocześnie* używanych języków programowania.
    > A naciągając fakty będzie 12. W takim zespole można już porozmawiać o
    > porównaniach, refleksji nt. walorów różnych rozwiązań, optymalizacji
    > dalszego kierunku, itd. Nie widzę problemu.

    Ale widzisz, ja uważam, że rozmawianie, refleksja, to sensowne metody.
    Liczenie chekboxów jest bezsensowne.

    >> nagle po wielokryteriowej analizie dochodzi do wniosku, że następny
    >> system klassy safety-critical będzie tworzony w, powiedzmy, Adzie.
    >
    > Jeżeli była jakaś analiza i to jeszcze wielokryteriowa, to na pewno
    > nie "nagle". Obstawiam raczej długotrwały proces refleksji i
    > poszukiwania właściwych torów.

    Jeśli liczysz checkboxy, to zawsze jest nagle, bo albo jest tych
    checkboxów więcej, albo ich nie jest więcej.

    > To jest coś jak z wprowadzaniem nowej metodologii prowadzenia
    > projektu. Cała nasza dotychczasowa dyskusja jest w mocy po zamianie
    > słowa "język" na "metoda prowadzenia projektu".

    Moim zdaniem nie jest.

    > I tak np. wyobraź
    > sobie, że są zespoły, które po jakiejś analizie i refleksji decydują
    > się na wprowadzenia agile, scrum, czy co tam jeszcze, chociaż
    > wcześniej nikt tego nie znał. A jednak robią to, z zapałem
    > przewalając całą firmę do góry nogami (czasem dosłownie). I uwaga,
    > bywa nawet, że robią w ten sposób postęp.

    Ta analogia jest moim zdaniem nietrafna, ale nawet pomimo tego można
    zauważyć, że właśnie często jest tak, że próby wprowadzenia Agile nie
    dochodzą do skutku lub kończą się źle na wskutek złego zrozumienia na
    czym to polega lub też konfliktu z mentalnością zespołu czy kulturą firmy.

    > Dlaczego taki zespół nie
    > miałby zdecydować się na sięgnięcie po inny język? Nie widzę żadnego
    > powodu.

    Ja nie widzę żadnego powodu, dla którego miałby w tym celu liczyć checkboxy.

    >> To, że nie będą kończyć ci sami ma mniejszą wagę, niż sądzisz.
    >> Przecież nigdy nie będzie takiej sytuacji, że wymienią na raz cały
    >> zespół, a tymczasem jeśli zaczniesz od tego, że robisz w
    >> technologii X, to będziesz dokooptowywać głównie ludzi, którzy
    >> znają technologię X, lub np. poznają ją stopniowo pracując w twojej
    >> organizacji na innych stanowiskach.
    >
    > Tak. Ciągłość techniczna to bardzo ważny argument. Dlatego możliwość
    > łączenia języków jest tu istotna - np. to, że Scala potrafi
    > wykorzystać istniejące klasy w Javie. Itp. To pozwala robić zmiany
    > jednocześnie zachowując ciągłość.

    Tym niemniej adopcja Scali nie jest gigantyczna, między innymi dlatego
    właśnie, że pracując w organizacji używającej Javy trudno się będzie
    mimochodem nauczyć Scali.

    More to the point, raczej nie będzie tak, że w zespole piszącym w Javie
    a nie w Scali ogół programistów wypisze checkboxy tak, żeby Scala
    wygrała. Może wpiszą checkboxy za wszystko co Java i Scala potrafią
    robić równie dobrze, a Java dostanie doddatkowy punkcik za "już znam".
    Może wpiszą checkboxy dla Javy za dużą dostępność narzędzi do analizy i
    transformacji kodu, może wpiszą "łatwo znaleźć programistów", może
    wyguglają artykuł "dlaczego przestaliśmy używać Scali" i wpiszą
    checkboxy stamtąd. Nie wpiszą raczej "closures", "first-class
    functions", "mocne generyki", "dedukcja typów", "immutable data types",
    "pattern matching". Nawet jeśli te cechy języka obiektywnie byłyby
    pomocne w osiągnięciu wyższej niezawodoności czy produktywności, to nie
    dostaniesz tych checkboxów właśnie dlatego, że spytałeś programistów Javy.

    A jeśli nawet programiści znają te rzeczy i rozumieją ich wartość, to
    zazwyczaj będą mieli też zdanie, czy przeważają one zalety Javy czy nie.
    Wychodząc więc z tego, że znają zalety Javy i zalety Scali i mając
    opinię co jest lepsze, mogą sobie bez problemu wybrać checkboxy do
    wpisania tak, żeby wyszło to, co uważają, że powinno wyjść.

    I w ogóle w tej ostatniej sytuacji wybór ten wygląda jeszcze inaczej:
    skor można łączyć Javę ze Scalą i skoro oba języki mają swoje zalety nad
    drugim i skoro masz w zespole konsensus dotyczący tego, w jakich
    sytuacjach te zalety się przydają, to pytanie (dla kogoś używającego już
    Javy) nie brzmi "czy używać Javy czy Scali" tylko "czy pozwolić na
    mieszanie Javy i Scali". I checkboxy na nie są takie - koszty
    wprowadzenia dodatkowej technologii są niezerowe, jak zatrudnimy
    programistów znających tylko Javę to nie będą mogli efektywnie pracować
    nad częścią kodu zanim się nie nauczą Scali. I te dw checkboxy mogą w
    praktyce łatwo przeważyć choćby i pińćset checkboxów przemawiających za
    stosowaniem Scali. Oczywiście, jeśli pozwolisz (cały czas w tej
    sytuacji) każdemu programiście używać Scali po uważaniu, to całkiem
    prawdopodobne, że któryś z nich do czegoś jej użyje. Ale też
    niekoniecznie jest najlepszym rozwiązaniem, żeby twój projekt na JVM był
    mieszaniną Javy, Scali, Groovy'ego, Jythona, jRuby, CLosure i natywnych
    DLL-ek w C++ używanych przez JNI, mimo że niewątpliwie każdy z tych
    języków ma swoje zalety, które w określonych sytuacjach mogą odhaczyć
    więcej checkboxów niż inne języki.

    Jest więc pewien argument za centralnym decydowaniem, których języków
    można użyć w projekcie, a których nie. I wtedy przeciw są zawsze
    mniej-więcej te same dwa-trzy checkboxy i decyzja będzie zawsze się
    sprowadzała do subiektywnego zważenia tych dwóch-trzech checkboxów
    przeciwko wszystkim argumentom wszystkich programistów, którzy by
    chcieli danego języka używać.

    No i jest jeszcze jeden, mniej przyjemny aspekt tej sprawy - dotyczy też
    bardziej ogólnie, nie tylko metody liczenia checkboxów, ale w ogóle
    dania programistom wolnej ręki w wyborze języka programowania. Jest nim
    pewien konflikt interesów między programistą a właścicielem projektu
    (właścicielem firmy, prezesem, szefem działu itd.). Pomińmy nawet chęć
    zastosowania nowego języka z niskich pobudek jak wpisanie sobie modnej
    technologii do CV, czy nieodpowiedzialną chęć pobawienia się nowymi
    gadźetami, w obu przypadkach potencjalnie kosztem projektu. Załóżmy, że
    programiści podejmują decyzję mając na względzie tylko sukces (w tym
    kmomercyjny) projektu, i że są na tyle kompetentni, żeby zgodnie z tym
    kryterium podjąć właściwą decyzję. Dla właściciela projektu liczy się
    przede wszystkim co innego - rentowność projektu. Programiści, załóżmy,
    nie chcą obniżenia rentowności projektu na tyle, żeby właściciel go
    zamknął, ale też niekoniecznie zależy mu na tym, żeby prezes kupił sobie
    w tym roku domek na Lazurowym Wybrzeżu. Nie na tyle na przykład, żeby
    nie chcieć podwyżki i premii.

    I teraz rozpatrz w świetle tego decyzję o adopcji Scali w projekcie
    javowym. Załóżmy, że zalety języka spowodują, że program będzie miał
    mniej błędów, że nowe ficzery będą szybciej implementowane, że dzięki
    temu klienci będą bardziej zadowoleni i program zarobi więcej. Ale dla
    właściciela projektu efekt adopcji Scali będzie też taki, że nie tylko
    będzie trudniej (i drożej) zatrudnić programistów znających już Scalę,
    ale nawet szukając programistów nie znających Scali, będzie musiał
    szukać raczej takich, którzy mają pojęcie o językach funkcyjnych, trochę
    bardziej zaawansowanych zagadnieniach typowania statycznego i tak dalej.
    W praktyce, nie tylko będzie trudniej zastąpić istniejących programistów
    i będzie to bardziej kosztowne, ale też w związku z tym bardziej
    kosztowne może stać się utrzymanie istniejących programistów - trzeba im
    będzie dawać większe podwyżki i premie, żeby rzadziej odchodzili.

    Jako programista możesz uważać, że skoro zespół jest już na pewnym
    poziomie, to również z punktu widzenia rentowności będzie was zatrzymać,
    a jeśli trzeba zatrudnić kogoś innego, to przynajmniej na tym samym
    poziomie. Możesz nawet mieć rację, ale właścicielowi projektu
    niekoniecznie będzie to łatwo ocenić, a ty nie jesteś w tej kwestii
    bezstronny. Dlatego też nie jest w ogóle oczywiste, czy dla właściciela
    w ogóle dobrym posunięciem jest pozostawienie tej decyzji wyłącznie w
    gestii programistów.


  • 30. Data: 2013-02-03 17:24:53
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com>

    On 03/02/2013 12:00, AK wrote:
    >
    > PS: Przed bledami 1go i 2go rodzaju zaden jezyk nie uchroni,

    Type safety może chronić przed jakąś tam częścią błędów 1. rodzaju.

strony : 1 . 2 . [ 3 ] . 4 ... 10 ... 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: