On 02/04/2012 18:23, Przemek O wrote:
> W dniu 2012-04-02 05:56, Andrzej Jarzabek pisze:
>
>> np. ww ten sposób, że nauka niektórych języków może poszerzyć horyzonty,
>> uczynić cię lepszym programistą, niezależnie od tego, czy będziesz ich
>> używał w pracy, czy nie - pewnie warto poznać jakiś język funkcyjny,
>> albo może Smalltalka, abo Prologa albo choćby Adę.
>
> Nie jestem studentem, nie prowadzę działalności naukowej. Wychodzi na to
> że jestem p...m materialistą bo nie przemawia to do mnie. Wolę ten czas
> przeznaczyć na rodzinę, zabawę z dziećmi, wyjście na spacer do lasu. To
> da więcej niż poszerzanie horyzontów dla samego faktu.

Ja nie mówię o nauce dla samego faktu. Ja mówię o tym, że jeśli znasz
już dobrze C++, C# i Javę, to prawdopodobnie i tak nie zrobisz takiego
manewru, że nauczysz się języka X i znajdziesz pracę jako programista w
języku X - zwłaszcza, jeśli jesteś pieprzonym materialistą. Jeśli
uczenie się jakiegoś kolejnego języka ma sens, w sensie
materialistycznego sensu żeby więcej zarabiać albo mieć lepsze
perspektywy zatrudnienia na przyszłość, to raczej nie taki. Jeśli ma
sens, a wydaje się, że może mieć, to taki, że dzięki znajomości np.
Erlanga czy Haskella znajdziesz innowacyjne rozwiązanie trudnego
problemu, które być może nawet zaimplementujesz w Javie czy C++, i
dostaniesz premię, podwyżkę albo propozycję znacznie lepiej płatnej
pracy gdzie indziej.

I nie mówię ani, że na pewno to dostaniesz, ani że warto poświęcać czas
na rodzinę, żeby to dostać, ani nawet że jeśli już masz poświęcić ten
czas, to akurat nauka nowego języka programowania jest tym sposobem
poświęcenia tego czasu, który da ci najlepszą szansę na premię, podwyżkę
itd., tylko że jeśli już się zdecydujesz w tym celu poświęcić ten czas
na naukę nowego języka, to lepiej się w tym celu uczyć tego Haskella czy
Ady, niż Delphi.

>> kolejny język programowania? Może to być na przykład jakiś popularny
>> framework czy biblioteka do języka, który już się zna, może jakaś inna
>> technologia (tworzenie aplikacji webowych, programowanie wielowątkowe,
>> synchronizacja lock-free), może po prostu dobre praktyki (TDD,
>> refaktoryzacja, design patterns).
>
> Ja zakładam że dobry programista (poza tymi web aplikacjami) to resztę
> zna... Chyba jednam piszemy o innych typach programisty.

Wydaje mi się, że można być dobrym programistą, i przynajmniej części
tych rzeczy nie znać. Ja zresztą nie wiem, czy jest sens wdawania się w
dywagacje na temat co jest dobrą radą dla dobrego programisty, a co dla
niedobrego. Trochę trudno z takiej rady skorzystać, bo przecież jak się
nie jest dobrym programistą, to czy można sensownie ocenić, czy ktoś
jest dobrym programistą? W szczególności czy się jest dobrym programistą
samemu? Ja nie wiem, czy jestem dobrym programistą, czy niedobrym, ale
staram się jednak uczyć nowych rzeczy i rozwijać jakoś umiejętności,
dzieki czemu, mam nadzieję, staję się lepszym programistą, niż byłem
wcześniej. I jakoś nie widzę, żebym miał w przewidywalnej przyszłości
dojść do takiego punktu, że umiem i wiem wszystko co "dobry programista"
powinien wiedzieć i umieć. Jak mawiał Hipokrates: ars longa, vita
brevis. I myślę, że jakby mi już zabrakło innych rzeczy do uczenia się,
a nadal miałbym ochotę się czegoś nauczyć, to bardziej bym skorzystał na
nauczeniu sie delfickiego dialektu starożytnej greki, niż technologii
Delphi.

>> W podsumowaniu Delphi nie warto się uczyć moim zdaniem nie dlatego, że
>> nauka Delphi nie ma w ogóle żadnej wartości, tylko dlatego, że rzeczy,
>> których się bardziej warto uczyć niż Delphi (z punktu widzenia
>> programisty) jest więcej, niż życia człowiekowi starczy (a ciągle
>> pojawiają się nowe).
>
> Lepsze jest wrogiem dobrego. Na tej zasadzie nie pcham się we wszystkie
> nowości bo ich zastosowanie przysparza więcej problemów niż
> pogimnastykowanie się ze starymi.

Nie rozumiemy się. Mówię o pojawianiu się nowych rzeczy, które bardziej
warto. To nie znaczy, że nagle pojawia się rzecz, której wcześniej nie
było, a teraz nagle jest i od razu bardziej warto, tylko obejmuje też
sytuację, kiedy wcześniej coś było nowością i nie było warto bo
zastosowanie przysparzało więcej problemów niż, a od pewnego momentu
warstwa szlachetnej patyny jest już odpowiednio gruba i już warto się pchać.

Z drugiej strony, patrząc z czysto komercyjnego punktu widzenia, czy w
momencie, kiedy dana nowość przejdzie swoje problemy z żąbkowaniem i
stanie się powszechnie stosowanym w branży rozwiązaniem, czy nie jest
korzystnie bbyć jednym z trzech ludzi na świecie, którzy mają z tą
technologą 10 lat doświadczenia? Możesz oczywiście powiedzieć, że nie
wiadomo, która z nowości stanie się powszechnie przyjętym rozwiązaniem,
ale też jest zwykle tak, że nowości są odpowiedzią na konkretny problem
i ich rozwój jest związany z tym, jak bardzo w danym momencie problem
jest palący (jeśli nie są rozwiązaniem lub jeśli problem nie jest
palący, to można sobie od razu odpouścić). W związku z tym można uczyć
się nowości i antycypować ich sukces w ten sposób: uczyć się nowości na
początku, żeby zobaczyć jakie problemy one rozwiązują. Wiedząc to, można
próbować określić, które z tych problemów są najbardziej palące między
innymi poprzez śledzenie, do których z nich odnosi się podejrzanie duży
udział powstających w danym czasie nowości (a także w ogóle orientując
się w temacie "z jakimi problemami bryka się dzisiaj inżynieria
oprogramowania", na przykład, bo ja wiem, poświęcając czas na czytanie
artykułów czy książek na ten temat. W końcu, wiedząc, które problemy są
palące, i które nie mają dojrzałych rozwiązań, to znaczy takich, które
nie są problematycznymi nowościami, można śledzić w jaki sposób owe
nieopierzone nowości próbują te problemy rozwiązać. Są dobre szanse na
to, że jedno z tych rozwiązań, albo coś bardzo podobnego, rozwiąże w
końcu swoje problemy wieku dziecięcego i stanie się powszechnie
przyjętym rozwiązaniem, a wszyscy, którzy znają tę technologię "od
początku" będą mogli zacząć czesać na niej naprawdę niezłą kapuchę.
Dodatkowy bonus jest taki, że dobre obeznanie z problemem i
alternatywnymi próbami podejścia do rozwiązania, daje ci super głęboką
wiedzę o stosowaniu danej technologii, na przykład bardzo dobrze
rozumiesz jej ograniczenia, wiesz dlaczego pewne rzeczy są zroione tak,
a nie inaczej i tak dalej.

>> Co to jest "aplikacja bazodanowa"? Chodzi o aplikację, która korzysta
>> z/której częścią jest (relacyjna) baza danych? Do tego chyba są jakieś
>> sensowne narzędzia do Javy?
>
> Zapewne, bo programowanie w javie w zasadzie sprowadza się do
> znalezienia sensownego narzędzia które trzeba w niej użyć. I tu ma
> przewagę np. Delphi które wszystko ma na pokładzie.

Nie rozumiem, na czym ta przewaga polega? Przecież jak się ktoś nie zna
na tworzeniu programów bazodanowych w Delphi, to i tak musi takie
narzędzie znaleźć, choćby i było "na pokładzie". Jak się ktoś chociaż
trochę zna na robieniu programów bazodanowych w Javie, to wie, że do
SQL-a można użyć JDBC, a do ORM-a Hiernate i jest to chya równie dobre
rozwiązanie, jak to, co Delphi ma na pokładzie? A jak ktoś się zna
dobrze na tworzeniu aplikacji bazodanowych w Javie, to obudzony w środku
nocy wymieni ci dwadzieścia różnych frameworków bazodanowych do Javy,
wyrecytuje wady i zalety i dobierze ten, który jest najlepiej dopasowany
do potrzeb twojego projektu.

Ja się, jak być może wspominałem, na tym nie znam, więc jeśli napiszesz
teraz, że JDBC i Hibernate w porównaniu z tym, co jest dostarczone z
Delphi to kompletna rzeźnia, to przyjmę do wiadomości i nie będę się
spierał (alczkolwiek chętnie przeczytam o szczegółach).

> Że o szybkości
> utworzenia takiej aplikacji nie wspomnę (a szybkość działania
> dobrotliwie przemilczę).

To często w ogóle ne jest problemem - np. dlatego, że i tak
bottleneckiem jest skalowanie RDBMSa.

>> No ale to nie lepiej od razu nauczyć się C# i .NETa? Zakładając, że
>> jakieś tam podstawy w programowaniu się już ma.
>
> C# i .NET nie jest taki wspaniały jakim niektórzy chcieli by go widzieć.
> Poza tym co to znaczy "lepiej"?
> Lepiej C#/.NET bo jest więcej pracy - tak, ale co za tym idzie i
> programistów jest więcej, więc pracodawcy sobie mogą przebierać (nawet w
> studentach ostatniego roku), stąd i zarobki dość niskie (średnio).
> Lepiej C# bo jest trendi :)

Nie wiem, jak jest średnio. Widziałem dużo dobrze płątnych ofert na C#,
chociaż niekoniecznie może dla studentó ostatniego roku (chociaż mz.
inteligentny i zaradny student ostatniego roku jest więcej wart, niż
matoł z trzydziestoletnym doświadczeniem).

Jeśli jest dużo pracy, to z oferowaniem niskiej płacy problem jest taki,
że pracy jest dużo, więc inni pracodawcy zaoferują lepszą płacę, a tobie
zostają matoły i studenci.

Oczywiście są pracodawcy, którzy chętnie zatrudnią matołów i studentów
albo dlatego, że mają taką specyfikę, że im się to najbardziej opłaca,
albo dlatego, że im się tak wydaje, bo nie widzą ile tracą na
zatrudnianiu matołów i studentów, widzą tylko że mniejsze pensje pobierają.

Z punktu widzenia pracownika w takiej sytuacji nie jest istotny język
programowania, tylko żeby się nie zatrudnić u takiego pracodawcy, a jak
się już zatrudni, to sp...ać jak najszybciej. Jeśli się jest studentem,
to można próbować się załapać w organizacji, w której odsetek studentów
i świeżych absolwentów się ogranicza, a matołów stara się nie zatrudniać
w ogóle. To może być trudne, ale jak się nie uda, to zawsze można się
pocieszyć, że studia się w końcu ukończy.

Jeśli się jest matołem, to, no cóż... Może są jakieś leki, które na to
pomagają, albo podręczniki self-help. Ja osobiście polecam spróbować
kariery w polityce.