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

do góry

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.

do góry

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ą.

do góry

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".

do góry

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

do góry

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

do góry

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

do góry

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 ---

do góry

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.

do góry

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.

do góry