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.