W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej Jarzabek napisał:

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

Tak. To pozwala ograniczyć ilość języków wartych uwagi do takiego zbioru, który
faktycznie można realnie ogarnąć.

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

Ale te rzeczy się nie wykluczają. Zbiór checkboksów (czyli wymagania na nowe
narzędzie) powstaje na skutek refleksji nad stanem obecnym. Samo liczenie checkboksów
to pikuś, ale jakoś trzeba tą listę stworzyć - to jest ta trudniejsza część i na
pewno zajmie najwięcej czasu.

> > 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,
[...]

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

I dokładnie z takiego samego powodu może się nie udać wprowadzenie nowego języka.

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

Checkboksy stanowią odpowiedź na pytanie dlaczego X a nie Y.

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

Zgadza się. I na pewno programista Javy, który patrzy się wyłącznie w swój monitor,
tego problemu konstruktywnie nie rozwiąże. Co więcej, nie zrobi tego też "otwarty"
programista Javy, który jeździ wyłącznie na konferencje Javy, czyta wyłącznie
książki/blogi o Javie, itd. Dlatego w zespole potrzebni są też ludzie, którzy sięgną
dalej. Jeżeli takich ludzi nie ma, to zespół nie ma najmniejszych szans na postęp i w
ogóle cała ta dyskusja takich zespołów nie dotyczy.

> 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ść.

Zgadza się. Na pewno ich własne oczekiwania będą jakoś wpływać na ten proces.

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

Konflikt wygląda tak:

"Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."

> Pomińmy nawet chęć
> zastosowania nowego języka z niskich pobudek jak wpisanie sobie modnej
> technologii do CV,

Ciekawe, że ta motywacja nie jest sprzeczna z oczekiwaniami właściciela projektu, bo
użycie modnej technologii wpływa pozytywnie na rekrutację.

> czy nieodpowiedzialną chęć pobawienia się nowymi
> gadźetami, w obu przypadkach potencjalnie kosztem projektu.

"Oferujemy możliwość pracy z najnowszymi technologiami."

> Dla właściciela projektu liczy się
> przede wszystkim co innego - rentowność projektu.

Tak. Dobry wybór technologii nie stoi w sprzeczności z tym celem.

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

To ciekawy zbieg okoliczności, ale akurat biorę udział w rekrutacji do takiego
projektu.

"Jeżeli chciałby Pan rozwijać się zawodowo i np. nauczyć się czegoś poza głównym
nurtem, który podkreślił Pan w swoim CV, to również tego typu możliwości można w
naszej firmie znaleźć. Np. mamy miejsce na projekty tworzone przy użyciu Scali."

To był mniej lub bardziej dosłowny cytat. Musiałbyś widzieć, jak się wtedy kandydatom
oczy świecą z radości. A przynajmniej jeszcze nie widziałem, żeby ktoś wtedy wyszedł.

Tak więc nie przyjmuję argumentu, że jest to wbrew oczekiwaniom pracodawcy. Wydaje
się, że przy odpowiedniej organizacji można stworzyć układ, w którym wszystkim będzie
po drodze.

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

"No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."

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

do góry

On 2013-02-04, Maciej Sobczak <s...@g...com> wrote:
> W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej Jarzabek napisał:
[...]
>> 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ę,
>
> To ciekawy zbieg okoliczności, ale akurat biorę udział w rekrutacji do
> takiego projektu.
>
> "Jeżeli chciałby Pan rozwijać się zawodowo i np. nauczyć się czegoś
> poza głównym nurtem, który podkreślił Pan w swoim CV, to również tego
> typu możliwości można w naszej firmie znaleźć. Np. mamy miejsce na
> projekty tworzone przy użyciu Scali."

Ja bym powiedział tak: znacznie trudniej zatrudnić kretyna piszącego
w Scali niż kretyna piszącego w Javie. Stosunek sygnału (dobrych
programistów) do szumu (programistów w ogóle) jest znacznie lepszy.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu poniedziałek, 4 lutego 2013 10:40:41 UTC+1 użytkownik Maciej Sobczak napisał:
> W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej Jarzabek napisał:
> > 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ę,
> To ciekawy zbieg okoliczności, ale akurat biorę udział w rekrutacji
> do takiego projektu.
Mam pytanie, dlaczego wybór padł na Scalę? Dlaczego jakiś projekt
bardziej opłaca się zrealizować w Scali niż w C++/Java? Skoro ciągle
rekrutujecie pracowników, to na pewnie nie powodu łatwo dostępnej i
taniej siły roboczej. Nie znam tego języka, będę wdzięczy za
naszkicowanie zalet. Może powinienem się go nauczyć?
Pozdrawiam

do góry

On 04/02/2013 09:40, Maciej Sobczak wrote:
> W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> 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".
>
> Tak. To pozwala ograniczyć ilość języków wartych uwagi do takiego
> zbioru, który faktycznie można realnie ogarnąć.

Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
dodatkowy język wiąże się z dodatkowymi kosztami.

>> Ale widzisz, ja uważam, że rozmawianie, refleksja, to sensowne
>> metody. Liczenie chekboxów jest bezsensowne.
>
> Ale te rzeczy się nie wykluczają. Zbiór checkboksów (czyli wymagania
> na nowe narzędzie) powstaje na skutek refleksji nad stanem obecnym.
> Samo liczenie checkboksów to pikuś, ale jakoś trzeba tą listę
> stworzyć - to jest ta trudniejsza część i na pewno zajmie najwięcej
> czasu.

Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
checkboksów? Bo widzisz, w praktyce zawsze tworzący listę będzie też
uważał, że niektóre checkboksy są ważniejsze od innych. Można oczywiście
bawić się w jakieś przypisanie wag, ale biorąc pod uwagę, że konkretne
liczby zawsze będą arbitalne, to nie lepiej jednak po prostu stwierdzić,
czy się uważa, czy zalety po prawej stornie tableki przeważają nad
wadami po lewej stronie tabelki?

>> 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.\
>
> I dokładnie z takiego samego powodu może się nie udać wprowadzenie
> nowego języka.

I dokładnie to jest to, czego liczenie checkboksów ci nie powie.

>> 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.
>
> Zgadza się. I na pewno programista Javy, który patrzy się wyłącznie w
> swój monitor, tego problemu konstruktywnie nie rozwiąże. Co więcej,
> nie zrobi tego też "otwarty" programista Javy, który jeździ wyłącznie
> na konferencje Javy, czyta wyłącznie książki/blogi o Javie, itd.
> Dlatego w zespole potrzebni są też ludzie, którzy sięgną dalej.
> Jeżeli takich ludzi nie ma, to zespół nie ma najmniejszych szans na
> postęp i w ogóle cała ta dyskusja takich zespołów nie dotyczy.

W praktyce w skali zespołu zawsze będziesz miał ograniczenie polegające
na tym, że rekrutowani byli ludzie z określonymi umiejętnościami. Nie ma
co liczyć na to, żeby w zespole posługującym się Javą wszyscy czy
większość rozumiała jak te rzeczy, które są w Scali praktycznie wpłyną
na pisanie programów. No chyba że rekrutujesz ich specjalnie pod tym
kątem, ale wtedy ktoś kiedyś musiał zadecydować, że takie a nie inne
umiejętności będą wymagane.

[...]
>> checkboxy do wpisania tak, żeby wyszło to, co uważają, że powinno
>> wyjść.
>
> Zgadza się. Na pewno ich własne oczekiwania będą jakoś wpływać na ten
> proces.

Na tyle, że cała metoda jest bezsensowna.

>> programowania. Jest nim pewien konflikt interesów między
>> programistą a właścicielem projektu (właścicielem firmy, prezesem,
>> szefem działu itd.).
>
> Konflikt wygląda tak:
>
> "Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."

U was w firmie programiści chcą, żeby bugi były?

>> Pomińmy nawet chęć zastosowania nowego języka z niskich pobudek jak
>> wpisanie sobie modnej technologii do CV,
>
> Ciekawe, że ta motywacja nie jest sprzeczna z oczekiwaniami
> właściciela projektu, bo użycie modnej technologii wpływa pozytywnie
> na rekrutację.
[...]
> "Oferujemy możliwość pracy z najnowszymi technologiami."

Być może, ale to przecież nie znaczy, że każdy dobór najnowszej czy
dobrej technologii ma sens w każdym projekcie. Tak więc teoretycznie
może zaistnieć sytuacja, kiedy programista, któremu pozostawiono w tej
kwestii wolną rękę, dobiera niewłaściwą technologię nie dlatego, że
wydaje mu się naprawdę lepsza do danego projektu, tylko dlatego, że
wydaje mu się osobiście ciekawsza. Na przykład wybiera bazę danych NoSQL
tam, gdzie SQL byłaby lepsza, bo NoSQL jest sexy i na topie.

Ale, jak mówiłem, mój argument nawet nie dotyczy takiej sytuacji.

>> Dla właściciela projektu liczy się przede wszystkim co innego -
>> rentowność projektu.
>
> Tak. Dobry wybór technologii nie stoi w sprzeczności z tym celem.

Zależy jak rozumie się "dobry". Jeśli taki, który zwiększy produktywność
i niezawodność, to może jednak tak być: jeśli wykorzystanie danej
technologii spowoduje, że miesięczne przychody z programu zwiększą się o
X, a koszty produkcji zwiększą się o Y, to opłacalność tego zależy od
tego, czy X jest większe od Y (upraszczając, ale mniejsza o to). Nie
jest oczywiste, że X będzie zawsze większe od Y, a w dodatku problem
jest długofalowy - początkowo bilans może być dodatni, bo programiści
nie dostaną podwyżek i premii natychmiast po wprowadzeniu Scali, ale w
perspektywie iluś lat trzeba im dać wyższe podwyżki i zapłacić wyższe
koszta rotacji.

Żeby nie było - ja też uważam, że zwykle czy nawet prawie zawsze
bardziej opłaca się zatrudnić dobrych programistów i płacić im
odpowiednią kupę szmalcu, ale też nie mam żadnych rzeczowych dowodów na
to, że X będzie większe od Y, tylko swoją intuicję, a sam przecież nie
jestem bezstronny.

> "Jeżeli chciałby Pan rozwijać się zawodowo i np. nauczyć się czegoś
> poza głównym nurtem, który podkreślił Pan w swoim CV, to również tego
> typu możliwości można w naszej firmie znaleźć. Np. mamy miejsce na
> projekty tworzone przy użyciu Scali."
> To był mniej lub bardziej dosłowny cytat. Musiałbyś widzieć, jak się
> wtedy kandydatom oczy świecą z radości. A przynajmniej jeszcze nie
> widziałem, żeby ktoś wtedy wyszedł.

Oj, nie twierdzę przecież, że problem (metaforycznej) Scali jest taki,
że kandydaci nie będą chętni. Problem jest taki, że:
* Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie będą
mniej produktywni.
* Jeśli chcesz zatrudnić kandydatów już znających Scalę, to możesz
długo szukać. Jeśli nie chcesz długoo szukać, to musisz wystawić bardzo
atrakcyjną ofertę.
* Jeśli dajmy na to nie wymagasz znajomości Scali, ale w celu
skrócenia czasu nauki i zapewnienia dobrego wykorzystania zalet języka
szukasz ludzi, którzy wiedzą coś np. o programowaniu funkcyjnym. To też
utrudnia ci znalezienie kandydata i powoduje konieczność wystawienia
lepszej oferty (niż gdybyś tego nie wymagał) w celu pryciągnięcia
odpowiednich ludzi.
* Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani Scali,
ani odpowiednich technik, to ryzykujesz, że się ich nie będą w stanie
nauczyć. Dasz im, powiedzmy, pół roku okresu próbnego, to musisz się
liczyć, że po pół roku jakiś tam procent nie będzie rokował nadziei i
trzeba będzie szukać kolejnych - koszty. Zaostrzając kryteria
rekrutacji, nawet nie konkretnie w tę stronę, ale nawet w celu
zatrudnienia po prostu najbardziej kumatych, obniżysz ten procent, ale
podwyższysz koszty wyjściowe - będziesz musiał dłużej szukać albo
zaoferować lepsze wynagrodzenie.

Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
kumatych, ale wszystko jest kwestią skali (no pun intended). Zawsze
możesz starać się zatrudnić jeszcze bardziej kumatych, a jeśli ogłosisz,
że płacisz 30 tysięcy na rękę, to na pewno wielu kumatych przyjdzie do
ciebie na rozmowę. Ale to nie znaczy, że twój szef się zgodzi, że warto
zapłacić te 30 tysięcy, i nie znaczy, że nie będzie miał w tym racji.

> Tak więc nie przyjmuję argumentu, że jest to wbrew oczekiwaniom
> pracodawcy. Wydaje się, że przy odpowiedniej organizacji można
> stworzyć układ, w którym wszystkim będzie po drodze.

Nie wszystko, co można jest dobre dla "bottom line".

>> 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.
>
> "No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."

Niekiedy jest tak, że między programistą a pointy haired bossem niekiedy
jest jeden lub więcej szczebli menedżerów technicznych, którzy mają na
tyle pojęcia o technologii, żeby móc podejmować takie decyzje, ale
którzy z drugiej strony nie mają motywacji, że dzięki użyciu Scali będą
mieli większe podwyżki i mniejszą szansę na zwolnienie. Wręcz przeciwnie
- im większe firma będzie musiała dawać podwyżki ich podwładnym, i im
trudniej będzie im zastąpić, tym mniejsze (ceteris paribus) będą ich
własne podwyżki i premie i tym większa szansa na, jeśli nie utratę
pracy, to przynajmniej utratę stanowiska kierowniczego.

do góry

On 2013-02-04 13:30, M.M. wrote:> W dniu poniedziałek, 4 lutego 2013 10:40:41 UTC+1
użytkownik Maciej Sobczak napisał:
>> W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej Jarzabek
napisał:
>> > 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ę,
>> To ciekawy zbieg okoliczności, ale akurat biorę udział w rekrutacji
>> do takiego projektu.
> Mam pytanie, dlaczego wybór padł na Scalę? Dlaczego jakiś projekt
> bardziej opłaca się zrealizować w Scali niż w C++/Java? Skoro ciągle
> rekrutujecie pracowników, to na pewnie nie powodu łatwo dostępnej i
> taniej siły roboczej. Nie znam tego języka, będę wdzięczy za
> naszkicowanie zalet. Może powinienem się go nauczyć?

Dlaczego guardian.co.uk przesiadł się z javy na scalę:
http://www.infoq.com/presentations/Scala-Guardian

--
Pozdrawiam
Marcin Biegan

do góry

W dniu poniedziałek, 4 lutego 2013 13:30:31 UTC+1 użytkownik M.M. napisał:

> Skoro ciągle
> rekrutujecie pracowników, to na pewnie nie powodu łatwo dostępnej i
> taniej siły roboczej.

Rekrutujemy, bo są potrzebni.

> Nie znam tego języka, będę wdzięczy za
> naszkicowanie zalet. Może powinienem się go nauczyć?

Bruce Eckel swego czasu napisał, że według niego Scala to "exit strategy for Java" (w
pełnym kontekście: dla tych programistów, którzy nie chcą ugrzęznąć w czymś, co jest
ograniczeniem dla ich dalszego rozwoju). Nie czuję się jednak odpowiednim
człowiekiem, żeby to komentować, chociaż gdybym traktował Javę jako swój główny nurt,
to na pewno miałbym Scalę na swojej liście rzeczy do rozpoznania.

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

do góry

W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
> dodatkowy język wiąże się z dodatkowymi kosztami.

Jest też komplementarne pytanie, jakie są koszty nie-ogarnięcia.

Pasuje tu dowcip:

Dyrektor IT: Musimy przeszkolić naszych pracowników.
Księgowy: A co będzie, jak ich wyszkolimy a oni wtedy odejdą?
Dyrektor IT: A co będzie, jak ich nie wyszkolimy a oni nie odejdą?

> Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
> checkboksów?

Z refleksji wynika lista checkboksów a z tej listy konkretne rozwiązanie problemu.

Najpierw zastanawiamy się co jest źle, potem co powinniśmy zrobić, żeby było lepiej a
z tego wynika, jakim produktem/technologią/itd. należy się posłużyć, żeby to
wypełnić.

> Bo widzisz, w praktyce zawsze tworzący listę będzie też
> uważał, że niektóre checkboksy są ważniejsze od innych.

Tak.

> W praktyce w skali zespołu zawsze będziesz miał ograniczenie polegające
> na tym, że rekrutowani byli ludzie z określonymi umiejętnościami.

"Oczekujemy gotowości do zdobywania nowych umiejętności i poszerzania swoich
kwalifikacji."

Jeżeli masz ludzi, którzy nie chcą się rozwijać, to nie będą. Pomyśl o tym już w
czasie ich zatrudniania.

> > Konflikt wygląda tak:
>
> > "Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."
>
> U was w firmie programiści chcą, żeby bugi były?

Nie chcą. Ale one są. I to jest temat do refleksji - co możemy zrobić, żeby było
lepiej?

> > "Oferujemy możliwość pracy z najnowszymi technologiami."
>
> Być może, ale to przecież nie znaczy, że każdy dobór najnowszej czy
> dobrej technologii ma sens w każdym projekcie.

Niczego takiego nie pisałem.

> Tak więc teoretycznie
> może zaistnieć sytuacja, kiedy programista, któremu pozostawiono w tej
> kwestii wolną rękę,

To kto ma mieć wolną rękę? Sprzątaczka?

Indywidualny programista nie powinien mieć wolnej ręki, ale kilku programistom,
którzy wspólnie coś rozważą, już by można zaufać.

> > Tak. Dobry wybór technologii nie stoi w sprzeczności z tym celem.
>
> Zależy jak rozumie się "dobry".

Tak, żeby było "lepiej". Celem refleksji jest określenie, co to oznacza. Dla różnych
branż, firm i projektów to mogą być różne rzeczy.

> Oj, nie twierdzę przecież, że problem (metaforycznej) Scali jest taki,
> że kandydaci nie będą chętni. Problem jest taki, że:
>
> * Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
> znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie będą
> mniej produktywni.

Kandydaci i tak nie są produktywni przez początkowy okres czasu.

> * Jeśli chcesz zatrudnić kandydatów już znających Scalę,

Nie chcę. Nauczę ich.

> * Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani Scali,
> ani odpowiednich technik, to ryzykujesz, że się ich nie będą w stanie
> nauczyć.

Tak. Wtedy będą robić mniej ciekawe rzeczy w mniej wartościowym projekcie.
Nie widzę problemu.

> Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
> kumatych, ale wszystko jest kwestią skali (no pun intended).

Tak. Ale zależnie od skali inaczej będę też podchodził do rekrutacji. Masowy projekt
zwykle prowadzi do masowej rekrutacji - i masowych efektów.

> > "No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."
>
> Niekiedy jest tak, że między programistą a pointy haired bossem niekiedy
> jest jeden lub więcej szczebli menedżerów technicznych,

Tak. Nie zawsze jest to problem. Wszystko zależy od ludzi. Jak już pisałem: jeżeli
ludzie nie chcą się rozwijać, to nie będą.

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

do góry

W dniu wtorek, 5 lutego 2013 10:26:18 UTC+1 użytkownik Maciej Sobczak napisał:
> Bruce Eckel swego czasu napisał, że według niego Scala to "exit strategy for
> Java" (w pełnym kontekście: dla tych programistów, którzy nie chcą ugrzęznąć
> w czymś, co jest ograniczeniem dla ich dalszego rozwoju). Nie czuję się
> jednak odpowiednim człowiekiem, żeby to komentować, chociaż gdybym traktował
> Javę jako swój główny nurt, to na pewno miałbym Scalę na swojej liście rzeczy
> do rozpoznania.
Pierwszy lepszy cytat znaleziony w googlu:
[
Scala jest jednym języków programowania nowej fali, mającym pozwolić pisać
programy komputerowe łatwiej, przyjemniej i szybciej. Podobnie jak w przypadku
Rubyego, Pythona czy Groovyego drogą do osiągnięcia tego celu jest wzbogacenie
języka o różnego rodzaju nowe elementy nieznane starej gwardii, czyli C++,
Javie czy C#, przy jednoczesnym ograniczeniu potrzeby bardzo skrupulatnego i
dosłownego pisania kodu. Kompilator bądź interpreter języka ma być inteligentny
i samodzielnie zgadywać intencje programisty, wszędzie tam, gdzie to możliwe.
]
Inteligenty kompilator... super fajnie, chcę taki :)


Potem przykład (chyba) funkcji:
[
def hello2(msg: String): String = {
]
Widzę w tym przykładzie coś strasznie nienaturalnego. W pascalu
pisało się procedure albo function. W niektórych językach,
choćby w PHP, też się jakoś informuje kompilator o definicji funkcji.
Jednak najbardziej popularne języki, z dużym wsparciem z wielu
stron, uporały się z tym potworkiem składniowym i potrafią, właśnie w inteligentny
sposób, domyślić się co jest funkcją bez potrzeby
specjalnego słowa kluczowego.

Pozdrawiam

do góry

On 2013-02-05, M.M. <m...@g...com> wrote:
> Potem przykład (chyba) funkcji:
> [
> def hello2(msg: String): String = {
> ]
> Widzę w tym przykładzie coś strasznie nienaturalnego. W pascalu
> pisało się procedure albo function. W niektórych językach,
> choćby w PHP, też się jakoś informuje kompilator o definicji funkcji.
> Jednak najbardziej popularne języki, z dużym wsparciem z wielu
> stron, uporały się z tym potworkiem składniowym i potrafią, właśnie w inteligentny
sposób, domyślić się co jest funkcją bez potrzeby
> specjalnego słowa kluczowego.

Na przykład Python (`def foo()'), Ruby (`def foo()'), Perl (sub foo {}),
Erlang (foo() ->), SML (fun foo x y).

Jak to było z tym "potworkiem składniowym"?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 5 lutego 2013 13:14:22 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
> Na przykład Python (`def foo()'), Ruby (`def foo()'), Perl (sub foo {}),
> Erlang (foo() ->), SML (fun foo x y).
> Jak to było z tym "potworkiem składniowym"?

W C/C++/Javie udało się usunąć ten element języka, a jeśli się
udało i języki funkcjonują dobrze, to znaczy, że ten element jest
zbędny.

Pozdrawiam

do góry