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

> Wręcz przeciwnie
> - im większe firma będzie musiała dawać podwyżki ich podwładnym,

Jeszcze mnie męczy temat tych podwyżek (że jak zdecyduję się na Scalę, to będę musiał
dawać większe podwyżki programistom).

Niby dlaczego mieliby dostawać większe? Bo jak nie dostaną, to odejdą? Gdzie odejdą,
skoro żadna inna firma nie używa Scali a im to sprawia frajdę? Zostaną na miejscu
właśnie ze względu na tą frajdę.
Bo w przypadku, gdy żadna inna firma nie używa Scali, to jedyny argument za
przejściem do konkurencji to wyższe wynagrodzenie. Ale skoro konkurencja używająca
Javy może dać moim ludziom wyższe pensje, to użycie bądź nieużycie Scali jest tu
kompletnie nieistotne - nawet jeśli nie użyję Scali w swoim projekcie, to nadal mam
tą samą konkurencję, która używa Javy i lepiej płaci.
Wychodzi więc, że użycie Scali w ogóle nie wpływa na temat przyszłych podwyżek dla
programistów, których zatrudnię i to niezależnie od tego, czy w momencie rekrutacji
oni Scalę znają czy też nie znają.
Natomiast jeśli konkurencja również zdedycuje się na użycie Scali (ale dlaczego
mieliby to zrobić, biorąc pod uwagę wszystkie Twoje argumenty przeciw?), to po prostu
mamy mały rynek, gdzie mały popyt zgadza się z małą podażą i dalej nie widzę powodu,
żeby ktokolwiek miał zarabiać kokosy tylko dlatego, że używa języka X a nie Y.

Jeśli zachodzą tu jeszcze jakieś dodatkowe zjawiska, to bardzo chętnie o nich
poczytam.

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

do góry

Mi sie wydaje ze (tu co do tej tamatyki tj porownywania jednego z drugim) bardziej
chodzi
o wydajnosc a nie o 'obnizony próg detekcji
błedów'. Co do tego drugiego to w sumie nie
wiem, osobiscie mam za malo doswiadczen z
takimi jezykami.. (na tyle co pamietam teraz niedokladnie bo od ponad 3 lat czy tam
ile programuje wylacznie w c, to chyba nie jest az
tak zle) jakis praktyk moglby powiedziec

do góry

W dniu środa, 6 lutego 2013 09:57:12 UTC+1 użytkownik Maciej Sobczak napisał:
> W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej Jarzabek napisał:
> Niby dlaczego mieliby dostawać większe? Bo jak nie dostaną, to odejdą?
> Gdzie odejdą, skoro żadna inna firma nie używa Scali a im to sprawia
> frajdę? Zostaną na miejscu właśnie ze względu na tą frajdę.
Może przewidzą ten fakt, że zaczną zdobywać takie umiejętności i doświadczenie
jakie potem trudno będzie sprzedać ( np. w razie zmiany pracodawcy ). I dlatego
zażądają więcej już na starcie. Nie wiem jak Wy, ale jak właśnie tak
robię. Jak ktoś chce do projektu w jakimś Cobolu, to nie dość że żądam dużo
więcej niż w C++/Java, to jeszcze chcę na koszt zleceniodawcy się uczyć.
Pozdrawiam

do góry

W dniu środa, 6 lutego 2013 10:48:39 UTC+1 użytkownik M.M. napisał:

> Może przewidzą ten fakt, że zaczną zdobywać takie umiejętności i doświadczenie
> jakie potem trudno będzie sprzedać ( np. w razie zmiany pracodawcy ). I dlatego
> zażądają więcej już na starcie. Nie wiem jak Wy, ale jak właśnie tak
> robię. Jak ktoś chce do projektu w jakimś Cobolu, to nie dość że żądam dużo
> więcej niż w C++/Java, to jeszcze chcę na koszt zleceniodawcy się uczyć.

Bo rozmowa jest źle przeprowadzona. I w ogóle cały proces wdrażania nowej technologii
jest źle przeprowadzony. Zamiast pytać kandydata, czy będzie *łaskaw* nauczyć się
czegoś nowego rozmawiamy tylko z tymi, którzy *szukają okazji*, żeby się czegoś
nauczyć. Wtedy ta rozmowa nie wygląda tak, jak powyżej.

Inaczej: na Scalę zdecydowałbym się tylko wtedy, gdybym miał ludzi, którzy
*chcieliby* to zrobić. Właśnie po to, żebym później nie musiał nikogo *zmuszać*, żeby
się tego uczył. Porównaj pogrubione wyrazy.
Dlatego wprowadzenie nowej technologii udaje się wtedy, gdy jest inicjatywą oddolną
(no, nie tak całkowicie dolną, bo taka inicjatywa nie może wyjść od zupełnego
juniora). Ludzie, którzy pracują z pasją i czują się autorami jakiejś inicjatywy są
znacznie bardziej efektywni. I w rezultacie również... tańsi.

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

do góry

On 02/05/2013 05:57 PM, M.M. wrote:
> W dniu wtorek, 5 lutego 2013 17:05:30 UTC+1 użytkownik Sebastian Kaliszewski
napisał:
>> Np to co jest w Pythonie.
>> W zasadzie Nie. Reflekscja działa w keirunku odwrontym do systemu typów.
> Nie rozumiem, nie znam pythona.

To poznaj. Albo np Lisp, Scheme (to w zasadzie wariant Lisp), Smalltalk,
Lua czy Ruby. Programista który nie ma bladego pojęcia o żadnym z nich
jest ułomny.

> Co jest w pythonie czego nie umożliwia
> java-reflection?

Dynamiczny system typów. W językach dynamicznych (Lisp, Python, Ruby,
Perl, Scheme, Lua, Smalltalk, Dylan, Erlang, itd...) typy są określane w
czasie wykonania (dynamicznie) a nie w czasie
kompliacji/parsowania/linkowania.

> O jakim kierunku mowa?

Refleksja to jest czytanie szczegółów już istniejących typów. System
typów to nadawanie typów.

pzdr
\SK

do góry

W dniu środa, 6 lutego 2013 15:46:17 UTC+1 użytkownik Sebastian Kaliszewski napisał:
> >> Np to co jest w Pythonie.
> >> W zasadzie Nie. Reflekscja działa w keirunku odwrontym do systemu typów.
> > Nie rozumiem, nie znam pythona.
>
> To poznaj. Albo np Lisp, Scheme (to w zasadzie wariant Lisp), Smalltalk,
> Lua czy Ruby. Programista który nie ma bladego pojęcia o żadnym z nich
> jest ułomny.
Jakiś czas temu wziąłem książeczkę do Perla. Chciałem poznać podstawy.
Utknąłem gdy trzeba było uchwyty otwartych procesów przekazać jako
parametry funkcji. Czytałem tę książeczkę, trochę pogrzebałem w necie i
nic nie znalazłem. Doszedłem do wniosku, że wolę być, jak to nazywasz,
ułomny, niż tracić czas w którym dany problem bym rozwiązał 10 razy
szybciej i ładniej w Javie albo w C++ i QT. Może Perl jest dobry, ale
jakoś nie zdołałem się o tym przekonać. Niniejsza dyskusja sprawia
świetną okazję, może jakoś mnie przekonasz do nauki, może jakoś lepiej
niż po prostu "ułomny", bo to do mnie kompletnie nie trafia.


> > Co jest w pythonie czego nie umożliwia
> > java-reflection?
>
> Dynamiczny system typów. W językach dynamicznych (Lisp, Python, Ruby,
> Perl, Scheme, Lua, Smalltalk, Dylan, Erlang, itd...) typy są określane w
> czasie wykonania (dynamicznie) a nie w czasie
> kompliacji/parsowania/linkowania.
Dobra, ale w C i w C++ też jest to możliwe. W C jest wskaźnik, może on
wskazywać na strukturę której pierwszy int mówi nam o tym co jest w dalszej
części struktury. W C++ pod offsetem od danych na które wskazuje wskaźnik
może być adres metody wirtualnej, która wie co zrobić z danym typem. W QT, w
VCL i zapewne w wielu innych jest klasa Variant... Jeśli potrzebuję
rozpoznawania typu w czasie wykonania, to C i C++ w żaden sposób nie
ogranicza mnie, a już na pewno nie czuję się ułomny z powodu używania C/C++.


> Refleksja to jest czytanie szczegółów już istniejących typów. System
> typów to nadawanie typów.
Rzadko używam javy, a refleksji to już w ogóle rzadko, ale z tego co
pamiętam można do klasy dodać dowolne pole o dowolnym typie, a nawet
metodę można dodać. Jeśli się mylę, to poprawcie mnie. Jedyna różnica
jest taka, że do zmiennej typu int nie mogę bez bólu przypisać zmiennej
typu tablicowego, czy referencji na obiekt. Czy to jest aż tak
potrzebne, wygodne, czy nie wiem co? Przecież mogę sobie zadeklarować
drugą zmienną i mam nawet czytelniej, a jak zmienne tymczasowe się
pałętają to mogę je objąć klamrami albo napisać osobną funkcję...

Pozdrawiam

do góry

On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 15:46:17 UTC+1 użytkownik Sebastian Kaliszewski
napisał:
>> >> Np to co jest w Pythonie.
>> >> W zasadzie Nie. Reflekscja działa w keirunku odwrontym do systemu typów.
>> > Nie rozumiem, nie znam pythona.
>>
>> To poznaj. Albo np Lisp, Scheme (to w zasadzie wariant Lisp), Smalltalk,
>> Lua czy Ruby. Programista który nie ma bladego pojęcia o żadnym z nich
>> jest ułomny.
> Jakiś czas temu wziąłem książeczkę do Perla. Chciałem poznać podstawy.
> Utknąłem gdy trzeba było uchwyty otwartych procesów przekazać jako
> parametry funkcji.

WTF is uchwyt otwartego procesu? Czy chodzi może o filehandle?

> Czytałem tę książeczkę, trochę pogrzebałem w necie i
> nic nie znalazłem. Doszedłem do wniosku, że wolę być, jak to nazywasz,
> ułomny, niż tracić czas w którym dany problem bym rozwiązał 10 razy
> szybciej i ładniej w Javie albo w C++ i QT.

Ale zdajesz sobie sprawę z tego, że *własnie na tym* polega nauka? Że
się początkowo rozwiązuje wolniej te rzeczy, które innymi narzędziami
się robiło szybciej? Bo po nabraniu wprawy może się okazać, że jednak
nowe narzędzie jest szybsze w użyciu w pewnych sytuacjach.

> Jedyna różnica
> jest taka, że do zmiennej typu int nie mogę bez bólu przypisać zmiennej
> typu tablicowego, czy referencji na obiekt. Czy to jest aż tak
> potrzebne, wygodne, czy nie wiem co?

Typy prymitywne są wyjątkiem w javowym systemie typów. Niewygodnym nie
jest niemożliwość dodania im metod, tylko w ogóle konieczność dodatkowej
obsługi tych wyjątkowych konstrukcji.

> Przecież mogę sobie zadeklarować
> drugą zmienną i mam nawet czytelniej, a jak zmienne tymczasowe się
> pałętają to mogę je objąć klamrami albo napisać osobną funkcję...

Brzmi trochę jak stanowisko starego Pascalowca, który na oczy nie
widział niczego innego: "w Pascalu do wszystkiego są funkcje, a jeśli
nie ma, to łatwo można sobie taką napisać". Ale to takie tylko odległe
skojarzenie.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu środa, 6 lutego 2013 16:57:09 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> WTF is uchwyt otwartego procesu? Czy chodzi może o filehandle?
Otwieramy dwa procesy do czytania i pisania. Tę samą funkcję
wywołujemy raz:
foo( proces_a , proces_b )
drugi raz
foo( proces_b , proces_a )


> Ale zdajesz sobie sprawę z tego, że *własnie na tym* polega nauka? Że
> się początkowo rozwiązuje wolniej te rzeczy, które innymi narzędziami
> się robiło szybciej? Bo po nabraniu wprawy może się okazać, że jednak
> nowe narzędzie jest szybsze w użyciu w pewnych sytuacjach.
Uznałem, że jeśli powyższego zadania nie mogę opanować w Perlu w
jedną-dwie godziny, to czas poświęcony na naukę nie zwróci się.

> Typy prymitywne są wyjątkiem w javowym systemie typów. Niewygodnym nie
> jest niemożliwość dodania im metod, tylko w ogóle konieczność dodatkowej
> obsługi tych wyjątkowych konstrukcji.
Jakiś przykład tej niewygodny?


> > Przecież mogę sobie zadeklarować
> > drugą zmienną i mam nawet czytelniej, a jak zmienne tymczasowe się
> > pałętają to mogę je objąć klamrami albo napisać osobną funkcję...
>
> Brzmi trochę jak stanowisko starego Pascalowca, który na oczy nie
> widział niczego innego: "w Pascalu do wszystkiego są funkcje, a jeśli
> nie ma, to łatwo można sobie taką napisać". Ale to takie tylko odległe
> skojarzenie.
Starzy Pascalowcy używali tego w dowolnie pracochłonnym kontekście: nie
ma okienkowego GUI - to możesz sobie napisać. We współczesnych rozbudowanych
środowiskach są pod ręką biblioteki na wszelką okazję, byleby ta okazja
powtarzał się w różnych projektach. Zadeklarowanie dodatkowej zmiennej
to nakład pracy 10 rzędów wielkości mniejszy niż w przykładzie z Twojego
skojarzenia. Nie porównywał bym tak.

Pozdrawiam

do góry

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

> ale z tego co pamiętam można do klasy dodać dowolne pole o dowolnym typie,
> a nawet metodę można dodać. Jeśli się mylę, to poprawcie mnie.

Mylisz sie.
Fefleksja w Javie tego nie umozliwia.

AK


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

do góry

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

> Jakiś czas temu wziąłem książeczkę do Perla.

Nikt tu ani slowem nie wymienil Perla.
Dlaczego rozpatrujesz najgorszy przyklad (IMHO antyjezyk:) ?

> Może Perl jest dobry,

Nie. Perl zdecydowanie nie jest dobry.

AK


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

do góry