On Apr 2, 6:23 pm, Przemek O <p...@o...eu> wrote:
> W dniu 2012-04-02 05:56, Andrzej Jarzabek pisze:
>
> >> I tak i nie. Wbrew pozorom pracy jest dużo w szczególności jeśli ktoś
> >> zna się ponad przeciętnie.
>
> > Dużo w porównaniu z czym? Javą? C#? C++? Choćby Ruby?
>
> Nie w porównaniu, tylko w ogóle. :) W każdym razie na tyle, że każdy
> bardziej utalentowany programista Delphi nie ma problemu ze znalezieniem
> pracy (co po części jest też powodowane i ich ilością :P ).

Moje doświadczenie jest takie, że każdy bardziej utalentowany
programista w czymkolwiek popularnym nie ma problemu ze znalezieniem
pracy, co więcej, znajdują ją nawet mniej utalentowani programiści,
lub kolesie tak kompletnie nieutalentowani, że nie przejdzie mi przez
klawiaturę określenie ich słowem "programiści" - chociaż teoretycznie
na takich stanowiskach są zatrudniani.

Oczywiście ma pewien sens kombinowanie "nauczę się czegoś, co mało kto
zna, to nie będę musiał konkurować z milardem programistów znających
Javę."

Tylko że nawet przy takim założeniu - moim zdaniem - sensowniej się
specjalizować w czymś bardziej perspektywicznym. Ktoś wchodzący na
rynek pracy ze znajomością Delphi będzie musiał konkurować z
kolesiami, którzy zjedli na tym zęby. Z drugiej strony przynajmniej
część istniejących projektów w Delphi będzie zamykana, przepisywana,
lub przeprojektowywana tak, że coraz więcej nowego kodu będzie
tworzonego w innych technologiach. A nowe projekty w Delphi powstawać
nie będą (z dokładnością do błedu pomiaru). I raczej znikanie
stanowisk dla programistów Delphi będzie procesem znacznie szybszym,
niż wymieranie tychże.

Z kolei jak się chce konkretnie wejść w takie klimaty, to może znowu
sensowniej uczyć się COBOLa? POdobno programiści COBOLa czeszą niezłą
kapuchę.

> > Wydaje mi się jednak, że wybierając dowolną w miarę popularną kombinację
> > (C++ + Qt, C++ + Windows (MFC, ATL, WinAPI), C++ + Unix) będziesz i tak
> > miał (wydaje mi się) rzędy wielkości więcej projektów do wyboru, niż
> > biorąc się za Delphi.
>
> Może tak, może nie. Aż tak obeznany nie jestem, a szacować czy gdybać
> nie mam zamiaru. W każdym razie biorąc np. pod uwagę naszych zachodnich
> sąsiadów to nie byłbym taki pewien tego stwierdzenia. Tam Delphi w swoim
> czasie było dużo bardziej popularne od C++/VS itp. I nadal jest
> popularne, choć już nie aż tak bardzo jak kiedyś.

Tu się przyznam, że nie mam pojęcia, co tam jest popularne. Ale nawet
jeśli tak jest, to wydaje mi się, że zmiany będą takie, jak wszędzie
indziej: popularność Delphi będzie spadać szybciej, niż ilość
programistów Delphi.

> >>> Wszystko powiedzmy w sensie że się uczymy z założeniem, że będziemy na
> >>> tym zarabiać. Pascala na pewno warto poznać do nauki paradygmatu
> >>> strukturalnego/proceduralnego i ewentualnie przejścia z niego na
> >>> obiektowość, ale jak już to się oblata, to chyba lepiej przerzucić się
> >>> na C++, Javę albo coś na dotnet.
>
> >> Bo ja wiem? Dawno wyrosłem ze stwierdzenia że tylko jeden język jest
> >> słuszny.
>
> > Nie wiem, gdzie w "C++, Javę albo coś na dotnet" widzisz "jeden język
> > jest słuszny". Z tym, że jak już się nauczysz nawet wszystkich tych
>
> W tym "chyba lepiej przerzucić się na...", gdzie zakładasz jakieś braki
> Delphi w stosunku do wymienionych, w tym kontekście - ten jeden jest
> niesłuszny z założenia.

Jeśli przez "niesłuszny" rozumiesz "nie ma sensu się uczyć", to
owszem, jest niesłuszny. Nie z założenia, tylko z tego, jak rozumiem
sytuację, i przy rozumieniu, że "sens" dotyczy nauki w celu bycia
zawodowym programistą i zarabiania na tym pieniędzy.

Natomiast "lepiej przerzucić się na" dotyczło kogoś, kto do nauki
programowania poznaje Pascala, być moze nawet w dialekcie Delphi.
Chodziło o to, że fakt, że już się zna Pascala/Delphi w zakresie
potrzebnym do zrozumienia pewnych podstaw nie przeważa szali na
korzyść tego, żeby w ramach dalszej nauki drążyć zaawansowane ficzery,
frameworki czy co tam jeszcze Delphi - nadal uważam, że jeśli się chce
zarabiać, to są rzeczy, których uczyć się jest większy sens (chociaż
niewątpliwie są również rzeczy, których uczyć się jest jeszcze
mniejszy sens).

> > języków (a czy w ogóle można się nauczyć C++?), to nadal jest kilka
> > innych, których bardziej warto się uczyć, niż Delphi: również z punktu
> > widzenia pracy w nich (tu pewnie Javascript, Ruby i Python).
>
> To tylko Twoje stwierdzenie. Ja uważam inaczej. Niemniej każdy ocenia to
> przez pryzmat własnych potrzeb.

Ja nie mam w tym temacie żadnych potrzeb. Po prostu z bezinteresownej
życzliwości dzielę się swoją opinią.

> Zresztą nie można oceniać języka bez dostarczanej z nim
> infrastruktury/frameworka.

Dlaczego? Z punktu widzenia kogoś robiącego aplikacje webowe/
bazodanowe w Javie jakie ma znaczenie, że Spring i Hibernate, a nawet
Eclipse czy IntelliJ Idea nie są "dostarczane z językiem"?

do góry

W dniu 2012-03-31 21:52, f...@g...SKASUJ-TO.pl pisze:
> ciekaw jestem jakie jest zdanie grupowiczow o delphi,
> (ja nie mam o nim (o niem) wiekszego pojecia, nigdy nie
> widzialem nawet kompilatora itp)
>
> czy delphi ma sie dobrze czy raczej stracilo na
> popularnosci,


nie w polsce
widzialem zgloszenia z tej durnej strony zlecenia przez net
80% wykonawcow robilo w delphi l ;)

jak sie ma do popularnych jezykow
> typu java, python, c++, czy mozna powiedziec ze
> delphi to wspolczesny paskal (czyli ze wspolczesny
> paskal to wlasnie delphi?), jak sie ma sprawa z tym
> jezykiem?

jezyk i programisci zyja sobie, srodowisko sie rozwija

po cichu powiem prawde ze delphi to taka platforma dla starszych panow
co robia apki ktore maja cokolwiek doczyniania z bazami danych i do tego
glownie sluzy

do góry

W dniu 2012-04-03 18:12, Andrzej Jarzabek pisze:

> Moje doświadczenie jest takie, że każdy bardziej utalentowany
> programista w czymkolwiek popularnym nie ma problemu ze znalezieniem
> pracy, co więcej, znajdują ją nawet mniej utalentowani programiści,
> lub kolesie tak kompletnie nieutalentowani, że nie przejdzie mi przez
> klawiaturę określenie ich słowem "programiści" - chociaż teoretycznie
> na takich stanowiskach są zatrudniani.

W takim razie nie rozumiem sensu tych dywagacji. Każdy zawsze znajdzie
zajęcie - i o to chodzi :)

> Tylko że nawet przy takim założeniu - moim zdaniem - sensowniej się
> specjalizować w czymś bardziej perspektywicznym. Ktoś wchodzący na
> rynek pracy ze znajomością Delphi będzie musiał konkurować z
> kolesiami, którzy zjedli na tym zęby. Z drugiej strony przynajmniej
> część istniejących projektów w Delphi będzie zamykana, przepisywana,
> lub przeprojektowywana tak, że coraz więcej nowego kodu będzie
> tworzonego w innych technologiach. A nowe projekty w Delphi powstawać
> nie będą (z dokładnością do błedu pomiaru). I raczej znikanie
> stanowisk dla programistów Delphi będzie procesem znacznie szybszym,
> niż wymieranie tychże.

Po pierwsze, zamykanie projektów nie zależy od języka/środowiska w jaki
zostały/ są tworzone.
Po drugie przepisanie kodu z czegokolwiek na cokolwiek, musi mieć silne
uzasadnienie ekonomiczne. Samo w sobie jest droższe niż dalsze
utrzymywanie rozwoju w starszym środowisku. Co w przypadku Delphi nie ma
znaczenie, bo środowisko istnieje, jest rozwijane, a i firmy trzecie
nadal zajmują się dostawą rozwiązań dedykowanych.
Po trzecie nowe projekty w Delphi powstają i to w ilości większej niż Ci
się wydaje.
Drugie i trzecie wynika z tego, że firmy poważnie zajmujące się
tworzeniem oprogramowania inwestują ogromne pieniądze w pełną
infrastrukturę i dostosowanie wszystkiego do swoich potrzeb i nie
zmienią tego ot tak bez powodu. A ważnym powodem mogłoby być np.
zaprzestanie rozwoju środowiska - co na chwilę obecną nie ma miejsca.
Podążanie za modą jest zdecydowanie za słabym argumentem.
Co do ostatniego zdania to się nie wypowiadam, bo to są Twoje dywagacje,
a ja takie opinie słyszę już od co najmniej 10-15 lat. Ze Delphi
zniknie, że nie będzie projektów itd itp. I co? I nic. Jakoś się to nie
sprawdza.

> Z kolei jak się chce konkretnie wejść w takie klimaty, to może znowu
> sensowniej uczyć się COBOLa? POdobno programiści COBOLa czeszą niezłą
> kapuchę.

Możliwe.

> Tu się przyznam, że nie mam pojęcia, co tam jest popularne. Ale nawet
> jeśli tak jest, to wydaje mi się, że zmiany będą takie, jak wszędzie
> indziej: popularność Delphi będzie spadać szybciej, niż ilość
> programistów Delphi.

Gdybanie nie poparte żadnym dowodem i przy okazji zaklinanie rzeczywistości.

> Natomiast "lepiej przerzucić się na" dotyczło kogoś, kto do nauki
> programowania poznaje Pascala, być moze nawet w dialekcie Delphi.
> Chodziło o to, że fakt, że już się zna Pascala/Delphi w zakresie
> potrzebnym do zrozumienia pewnych podstaw nie przeważa szali na
> korzyść tego, żeby w ramach dalszej nauki drążyć zaawansowane ficzery,
> frameworki czy co tam jeszcze Delphi - nadal uważam, że jeśli się chce
> zarabiać, to są rzeczy, których uczyć się jest większy sens (chociaż
> niewątpliwie są również rzeczy, których uczyć się jest jeszcze
> mniejszy sens).

Dokładnie, ale tymi rzeczami nie są języki programowania. Język
programowania jest sprawą drugorzędną. Jeśli chcesz zarabiać dobre
pieniądze musisz się wyspecjalizować w dziedzinie docelowej.

> Ja nie mam w tym temacie żadnych potrzeb. Po prostu z bezinteresownej
> życzliwości dzielę się swoją opinią.
>
>> Zresztą nie można oceniać języka bez dostarczanej z nim
>> infrastruktury/frameworka.
>
> Dlaczego? Z punktu widzenia kogoś robiącego aplikacje webowe/
> bazodanowe w Javie jakie ma znaczenie, że Spring i Hibernate, a nawet
> Eclipse czy IntelliJ Idea nie są "dostarczane z językiem"?

Nie zrozumiałeś. Chodzi o to że język nie jest nic wart, jeśli nie jest
dostarczony z pełną infrastrukturą. Samo C# bez .NETa nie miałby
wartości produkcyjnej, Java bez tony bibliotek tak samo. Znajomość
języka nie ogranicza się do znajomości jego składni, semantyki czy typów
danych, ale do gruntownego poznania bibliotek i ich sensownego
wykorzystania. W tym kontekście nie można oceniać języka bez dodatków
(bibliotek, frameworków, komponentów itd itp.).

pozdrawiam,
Przemek O.

do góry

On 03/04/2012 21:18, Przemek O wrote:
> W dniu 2012-04-03 18:12, Andrzej Jarzabek pisze:
>
>> część istniejących projektów w Delphi będzie zamykana, przepisywana,
>> lub przeprojektowywana tak, że coraz więcej nowego kodu będzie
>> tworzonego w innych technologiach. A nowe projekty w Delphi powstawać
>> nie będą (z dokładnością do błedu pomiaru). I raczej znikanie
>> stanowisk dla programistów Delphi będzie procesem znacznie szybszym,
>> niż wymieranie tychże.
>
> Po pierwsze, zamykanie projektów nie zależy od języka/środowiska w jaki
> zostały/ są tworzone.

Zgadza się. Ale jeśli np. projekty w Javie są zamykane, ale z drugiej
strony są też rozpoczynane nowe projekty w Javie, to ludzie, którzy
odchodzą z zamykanych projektów mają lepszą perspektywę na
długoterminowe zatrudnienie.

Jeśli projekty w danej technologii są zamykane, natomiast nowe projekty
nie są otwierane to... a taki właśnie uważam, że jest przypadek Delphi.

> Po drugie przepisanie kodu z czegokolwiek na cokolwiek, musi mieć silne
> uzasadnienie ekonomiczne. Samo w sobie jest droższe niż dalsze
> utrzymywanie rozwoju w starszym środowisku.

To zależy. Są przypadki, że np. z powodu tego jak wygląda kod, albo z
powodu decyzji projektowych, zaczyna być trudno dodawać do programu taką
funkcjonalność, jaką by się chciało. Znaczy trwa to strasznie długo i
wymaga wiele pracy. Co jakiś czas pojawia się oszacowanie: gdyby to a
tamto było inaczej zrobione, to byśmy mogli dodać ten ficzer w dwa
tygodnie, a tak to zajmie nam to trzy miesiące. I to jest uzasadnienie
ekonomiczne.

Osobiście brałem udział w przepisywaniu dwóch projektów, z czego jeden
był właśnie przepisywany z Delphi na co innego.

> Co w przypadku Delphi nie ma
> znaczenie, bo środowisko istnieje, jest rozwijane, a i firmy trzecie
> nadal zajmują się dostawą rozwiązań dedykowanych.
> Po trzecie nowe projekty w Delphi powstają i to w ilości większej niż Ci
> się wydaje.

Nie wiem ile ci się wydaje, że mi się wydaje, ale skoro ty wiesz, ile to
jest naprawdę, albo przynajmniej potrafisz oszacować od dołu, to może
napisz, np. jaki to jest procent nowo powstających projektów w ogóle,
albo ile w stosunku do nowo powstających projektów w Javie czy choćby w C++.

> Drugie i trzecie wynika z tego, że firmy poważnie zajmujące się
> tworzeniem oprogramowania inwestują ogromne pieniądze w pełną
> infrastrukturę i dostosowanie wszystkiego do swoich potrzeb i nie
> zmienią tego ot tak bez powodu. A ważnym powodem mogłoby być np.
> zaprzestanie rozwoju środowiska - co na chwilę obecną nie ma miejsca.

Są też inne ważne powody.

> Podążanie za modą jest zdecydowanie za słabym argumentem.

Powiedz to może temu chochołowi, który użył tego argumentu.

> Co do ostatniego zdania to się nie wypowiadam, bo to są Twoje dywagacje,
> a ja takie opinie słyszę już od co najmniej 10-15 lat. Ze Delphi
> zniknie, że nie będzie projektów itd itp. I co? I nic. Jakoś się to nie
> sprawdza.

Jak to nie? Przecież znika.

>> Tu się przyznam, że nie mam pojęcia, co tam jest popularne. Ale nawet
>> jeśli tak jest, to wydaje mi się, że zmiany będą takie, jak wszędzie
>> indziej: popularność Delphi będzie spadać szybciej, niż ilość
>> programistów Delphi.
>
> Gdybanie nie poparte żadnym dowodem i przy okazji zaklinanie
> rzeczywistości.

Czy moje słowo nie jest wystarczającym dowodem na to, że mi się tak
wydaje? Uważasz, że w rzeczywistości jestem przekonany o świetlanej
przyszłości Delphi, ale publicznie mówię co innego w celu "zaklinania
rzeczywistości"?

>> frameworki czy co tam jeszcze Delphi - nadal uważam, że jeśli się chce
>> zarabiać, to są rzeczy, których uczyć się jest większy sens (chociaż
>> niewątpliwie są również rzeczy, których uczyć się jest jeszcze
>> mniejszy sens).
>
> Dokładnie, ale tymi rzeczami nie są języki programowania. Język
> programowania jest sprawą drugorzędną. Jeśli chcesz zarabiać dobre
> pieniądze musisz się wyspecjalizować w dziedzinie docelowej.

Co to znaczy "dziedzina docelowa"? Że np. muszę się znać np. na
sprzedawaniu biletów lotniczych i wtedy będę zarabiał dobre pieniądze na
tworzeniu programów do sprzedawania biletów lotniczych?

To być może zależy od tego, co się rozumie przez "dobre pieniądze". Ja
na przykład mam dość marne pojęcie o tym, do czego służy oprogramowanie,
które tworzę, a zarabiam może nie jakieś kokosy, ale jak się porównam z
krajowymi statystykami, to wychodzi na to, że też nie tak zupełnie źle.
W dodatku regularnie dostaję telefony, że jest robota za większą kasę,
ale wiąże się to z tym, że musiałbym dłużej siedzieć w pracy i dalej
dojeżdżać, więc temat spacerów z rodziną mi konfliktuje. A do tamtych
prac też chcą zatrudniać kogoś, kto się niekoniecznie zna na tym co robi
program, ale za to bardzo dobrze zna jakąś technologię, często właśnie
język programowania.

>>> Zresztą nie można oceniać języka bez dostarczanej z nim
>>> infrastruktury/frameworka.
>>
>> Dlaczego? Z punktu widzenia kogoś robiącego aplikacje webowe/
>> bazodanowe w Javie jakie ma znaczenie, że Spring i Hibernate, a nawet
>> Eclipse czy IntelliJ Idea nie są "dostarczane z językiem"?
>
> Nie zrozumiałeś. Chodzi o to że język nie jest nic wart, jeśli nie jest
> dostarczony z pełną infrastrukturą. Samo C# bez .NETa nie miałby
> wartości produkcyjnej, Java bez tony bibliotek tak samo. Znajomość

Nie bardzo rozumiem, co to dla ciebie "pełna infrastruktura"?
Standardowe bilioteki do Javy, runtime i JDK to dla ciebie "pełna
infrastruktura"? Dla C++ pełną infrastrukturą jest kompilator, linker,
debugger i biblioteka standardowa?

> języka nie ogranicza się do znajomości jego składni, semantyki czy typów
> danych, ale do gruntownego poznania bibliotek i ich sensownego
> wykorzystania.

No więc niekoniecznie. Często jest tak, że dana firma wykorzystuje swoje
własne biblioteki, albo jakieś mało standardowe frameworki. W takich
sytuacjach w ogóle nie szukają ludzi pod kątem znajomości tych iliotek,
tylko zakładają (słusznie, moim zdaniem), że jak ktoś dorze zna język i
potrafi dobrze programować, to nie będzie miał wielkich problemów z
nauczeniem się danej biblioteki.

do góry

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.

do góry

W dniu 2012-04-04 00:04, Andrzej Jarzabek pisze:
> On 03/04/2012 21:18, Przemek O wrote:

>> Nie zrozumiałeś. Chodzi o to że język nie jest nic wart, jeśli nie jest
>> dostarczony z pełną infrastrukturą. Samo C# bez .NETa nie miałby
>> wartości produkcyjnej, Java bez tony bibliotek tak samo. Znajomość
>
> Nie bardzo rozumiem, co to dla ciebie "pełna infrastruktura"?
> Standardowe bilioteki do Javy, runtime i JDK to dla ciebie "pełna
> infrastruktura"? Dla C++ pełną infrastrukturą jest kompilator, linker,
> debugger i biblioteka standardowa?

Co do frameworków 'zewnętrznych' (nie zapaczkowanych razem z 'językiem'
cokolwiek by to miało znaczyć), język wydaje się nie ma znaczenia ...
jednak w głębszym oglądzie jednak ma. Język ('core' ale i ludzie
skupieni koło niego) wytwarza pewien 'ekosystem', i albo ten ekosystem
sprzyja w miarę sensownemu rozwojowi frameworków, albo nie.
Uffff, ale zdanie wyszło, trochę ilustracji:
ekosystem C++ nawet nie potrafił wytworzyć dominującego na rynku
String'a że o GUI nie wspomnę
ekosystem PHP pełen jest chorych ambicji 'ja napiszę lepszy framework
nie wspólpracujący z niczym innym'
dwa syntaktycznie i implementacyjnie bliskie języki/platformy jak
Java/C# JVM/.NET mają zuuuupełnie inne ekosystemy, inna subkultura.

Ekosystem jak go pojmuję to nieustająca pętla twórcy języka-użytkownicy,
dla użytkowników i ich nawyków robi się następne wersje itd. Vox populi,
vox dei - czasem podsumować trzeba głośnym NIESTETY, bo nawyki są dobre
lub złe, twórca/y ma siłę realizować jasną liniowa wizję, lub nie: w
wersji 5 zaprzecza czemuś z 4-tej.

Delphi bym jednak zaliczył do tych niższych lotów: cały rynek
komponentów, to wyłącznie front end (bo statystyczny użytkownik chce
szybko szyć kod na gui). Nie ma komponentów 'architekturalnych' ani nie
ma myślenia 'architekturalnego' (w jakimś średnim przekroju oczywiście).


>> języka nie ogranicza się do znajomości jego składni, semantyki czy typów
>> danych, ale do gruntownego poznania bibliotek i ich sensownego
>> wykorzystania.
>
Zdecydowanie tak.

> No więc niekoniecznie. Często jest tak, że dana firma wykorzystuje swoje
> własne biblioteki, albo jakieś mało standardowe frameworki. W takich
> sytuacjach w ogóle nie szukają ludzi pod kątem znajomości tych iliotek,
> tylko zakładają (słusznie, moim zdaniem), że jak ktoś dorze zna język i
> potrafi dobrze programować, to nie będzie miał wielkich problemów z
> nauczeniem się danej biblioteki.
Poznanie Javy (rdzenia) to 1 wieczór, ile trzeba na poznanie J2EE
(=biblioteki), zwłaszcza że nie chodzi o KOD javowski z wprawek z
pierwszego wieczora, tylko filozofię, konfigurację, metaprogramowanie,
xml-e itd? Myślę że ciężkie miesiące lub lata.

Więc SŁUSZNIE szukają znających biblioteki.

Oczywiście, wejście dobrego programisty (np. OOP) w dobry choć nieznany
mu wcześniej framework (wtedy OOP) zachodzi. O kilku miesięcy obcuję z
dobrze zaprojektowanym, choć słabo udokumentowanym obiektowym
środowiskiem OOP, podsumuję: praca z wielką frajdą, czucie tego, co
projektant chciał powiedzieć, skoro zrobił klasy jak zrobił.

do góry

W dniu 2012-04-03 22:18, Przemek O pisze:

> Nie zrozumiałeś. Chodzi o to że język nie jest nic wart, jeśli nie jest
> dostarczony z pełną infrastrukturą. Samo C# bez .NETa nie miałby
> wartości produkcyjnej, Java bez tony bibliotek tak samo. Znajomość
> języka nie ogranicza się do znajomości jego składni, semantyki czy typów
> danych, ale do gruntownego poznania bibliotek i ich sensownego
> wykorzystania. W tym kontekście nie można oceniać języka bez dodatków
> (bibliotek, frameworków, komponentów itd itp.).

Tak na marginesie: jak w tej chwili wygląda integracja Delphi z .NET ?
Idą mocno w tym kierunku, czy zarzucone ?

do góry

On Apr 4, 7:07 am, Jacek Czerwinski <x...@...z.pl> wrote:
> W dniu 2012-04-04 00:04, Andrzej Jarzabek pisze:
>
> > Nie bardzo rozumiem, co to dla ciebie "pełna infrastruktura"?
> > Standardowe bilioteki do Javy, runtime i JDK to dla ciebie "pełna
> > infrastruktura"? Dla C++ pełną infrastrukturą jest kompilator, linker,
> > debugger i biblioteka standardowa?
>
> Co do frameworków 'zewnętrznych' (nie zapaczkowanych razem z 'językiem'
> cokolwiek by to miało znaczyć), język wydaje się nie ma znaczenia ...
> jednak w głębszym oglądzie jednak ma. Język ('core' ale i ludzie
> skupieni koło niego) wytwarza pewien 'ekosystem', i albo ten ekosystem
> sprzyja w miarę sensownemu rozwojowi frameworków, albo nie.
> Uffff, ale zdanie wyszło, trochę ilustracji:
> ekosystem C++ nawet nie potrafił wytworzyć dominującego na rynku
> String'a że o GUI nie wspomnę

Podobno Qt jest dominujący. Z drugiej strony podejście Javowe do
tematu tez ma swoje wady - jednym z częstych powodów odrzucania Javy
jako technologii do GUI jest to, że dominujący framework robi GUI po
swojemu, a użytkownicy chcą mieć standardowy look&feel.

> > No więc niekoniecznie. Często jest tak, że dana firma wykorzystuje swoje
[...]
> Poznanie Javy (rdzenia) to 1 wieczór, ile trzeba na poznanie J2EE

Jeśli chcesz polemizować z argumentem, że "niekoniecznie", to musisz
jeszcze wykazać, że każdy język jest Javą i każda praca
programistyczna wymaga instensywnej znajomości J2EE.

Bo "niekoniecznie" nie znaczy "nieprawda, znajomość języka jest ważna,
znajomość bibliotek jest nieważna", tylko "może być tak albo śmak,
zależy".

> Więc SŁUSZNIE szukają znających biblioteki.

Piszę przecież, że jedni szukają, a inni nie szukają.

do góry

On Wednesday, April 4, 2012 7:07:17 AM UTC+1, Jacek Czerwinski wrote:

> Poznanie Javy (rdzenia) to 1 wieczór, ile trzeba na poznanie J2EE
> (=biblioteki), zwłaszcza że nie chodzi o KOD javowski z wprawek z
> pierwszego wieczora, tylko filozofię, konfigurację, metaprogramowanie,
> xml-e itd? Myślę że ciężkie miesiące lub lata.

Nie musisz znac J2EE zeby uzywac profesjonalnie Javy.

RW

do góry

W dniu 2012-04-04 09:20, zażółcony pisze:
> W dniu 2012-04-03 22:18, Przemek O pisze:
>
>> Nie zrozumiałeś. Chodzi o to że język nie jest nic wart, jeśli nie jest
>> dostarczony z pełną infrastrukturą. Samo C# bez .NETa nie miałby
>> wartości produkcyjnej, Java bez tony bibliotek tak samo. Znajomość
>> języka nie ogranicza się do znajomości jego składni, semantyki czy typów
>> danych, ale do gruntownego poznania bibliotek i ich sensownego
>> wykorzystania. W tym kontekście nie można oceniać języka bez dodatków
>> (bibliotek, frameworków, komponentów itd itp.).
>
> Tak na marginesie: jak w tej chwili wygląda integracja Delphi z .NET ?
> Idą mocno w tym kierunku, czy zarzucone ?

Wcale nie wygląda :) Delphi miało w okolicach wersji 8 mały romans z
.NETem, ze względu na to, że M$ oświadczył, że kolejny system miał być
natywnie .NETowy (chodziło o Viste). Jako że siłą Delphi od zawsze była
kompilacja do kodu natywnego, zainteresowali się .NETem. Sprawy się
jednak tak potoczyły, że ani Vista, ani 7 ani nawet 8 nie są systemami
natywnie .NETowymi. Stąd producent porzucił wsparcie dla .NETa. Na dobrą
sprawę promuje teraz swoje rozwiązanie - FireMonkey które ma w założeniu
być wieloplatformowe. Na teraz jest nim dla Win32, Win64, MacOS (i
kombinowane dla OSX, Android).
Dla .NETa jest w pakiecie Oxygen, ale IMHO to się mija z celem.

pozdrawiam,
Przemek O.

do góry