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