> > Kyniu
>
> Witam
>
> Jakie masz argumenty za tym ,że JAVA jest największą pomyłką informatyki?
>

Bo z zalozenia mial byc przenosny?
Dla mnie jako zwyklego lusera w tej sprawie, programy w Javie to
klockowate gnioty, zajmujace znacznie wiecej zasobow komputera niz
rownowazny program napisany w C/C++ chociazby.

Uzywam na codzien kilku programow napisanych w Javie i bez wyjatku to
zamulacze kompa - wolno sie uruchamiaja, wolna dzialaja, i zzeraja bez
umiaru pamiec.
Zreszta roznice miedzy jezykami latwo znalezc np porównując
klasycznego klienta Bittorenta, napisanego w Pythonie,z uTorrentem
pisanym w C++. Ten drugi jest jak rakieta ;-)))...

Widze tez, ze wiekszosc z tych co napadli na Kyniu, to ludzie zyjacy z
dlubania w Javie, wiec nie dziwie sie ze chca mu wydlubac oczy.

do góry

v...@g...com napisał(a):


>> Jakie masz argumenty za tym ,że JAVA jest największą pomyłką informatyki?

> Bo z zalozenia mial byc przenosny?
> Dla mnie jako zwyklego lusera w tej sprawie, programy w Javie to
> klockowate gnioty, zajmujace znacznie wiecej zasobow komputera niz
> rownowazny program napisany w C/C++ chociazby.

To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?

--
Wojciech 'Proteus' Bańcer
p...@p...pl

do góry

>
> To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?
>

Hmm mialem na mysli raczej programy na desktopa. W powyzszych
zastosowaniach nie neguje Javy.
Tylko nie mozna jej traktować jako narzedzia do wszystkiego.

do góry

On 4 Wrz, 14:35, v...@g...com wrote:
> > To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?
>
> Hmm mialem na mysli raczej programy na desktopa. W powyzszych
> zastosowaniach nie neguje Javy.
> Tylko nie mozna jej traktować jako narzedzia do wszystkiego.

a gdzie ktos napisal, ze java to narzedzie do wszystkiego?

--

Pozdrawiam,

glos

do góry

v...@g...com napisał(a):

>> To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?

> Hmm mialem na mysli raczej programy na desktopa. W powyzszych
> zastosowaniach nie neguje Javy.
> Tylko nie mozna jej traktować jako narzedzia do wszystkiego.

Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
zastosowania serwerowe, a nie desktopowe.

--
Wojciech 'Proteus' Bańcer
p...@p...pl

do góry

Wojciech Bańcer <p...@p...pl> wrote:
> Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
> składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
> rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
> zastosowania serwerowe, a nie desktopowe.

No to w takim razie z punktu widzenia osoby zajmującej się na co dzień
utrzymaniem parunastu/parudziesięciu aplikacji J2EE w najróżniejszych
środowiskach, darmowych i komercyjnych, pod najróżniejszymi JVM-ami:
- są o wiele bardziej zasobożerne od ich funkcjonalnych odpowiedników
pisanych w C/C++ (jak raz parę możliwości porównania mam, to wiem);
- ciekną - w garbage collector uwierzę jak zobaczę ;)
- ohydnie logują (nie wątpię, że dla programisty kilometrowe zrzuty z
wyjątków są wybitnie przydatne, ale mówimy o systemach oddanych do
eksplotacji); alternatywa "logować mniej/nic" nie wchodzi w grę;

Krótko mówiąc, w utrzymaniu bywają prawdziwym bólem w dupie. Tak jakby
były pisane dla programistów, nie dla odbiorców. Potwierdza się to zresztą
gdy napotkasz na jakąkolwiek zagwozdkę związaną z utrzymaniem i szukasz
pomocy w dokumentacji. "Tu sobie dopisz fooshmoo, tu sobie zrekompiluj, tu
w tej klasie popraw to i tamto". Jestem adminem, nie wolno mi "sobie
poprawiać", a na zasoby programistyczne dla mojej wygody utrzymania nikt
nie zainwestuje złotówki - tymczasem to mnie rozliczają z poziomu
dostępności usługi.

Powiesz, że większość powyższych utrapień to wina błędu w sztuce
programistycznej - w to uwierzyłabym gdybym miała jedną czy dwie takie
aplikacje. A po tych paru latach wychodzi mi, że Java jest po prostu
językiem zbyt łatwym do nauczenia się - potem siada taki miś po tygodniowym
kursie w $danej_biedronce_informatycznej i przekonany, że już umie, tworzy
soft, z którym potem inni latami muszą się użerać.

I zanim mnie tu jakiś keyboard warrior zaatakuje zza węgła: nie marudzę,
radzę sobie. Ot, trochę więcej czasu marnuję na rzeczy niepotrzebne.

a.

do góry

asiaque <a...@w...hell.pl> napisał(a):

> Wojciech Bańcer <p...@p...pl> wrote:
> > Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
> > składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
> > rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
> > zastosowania serwerowe, a nie desktopowe.
>
> No to w takim razie z punktu widzenia osoby zajmującej się na co dzień
> utrzymaniem parunastu/parudziesięciu aplikacji J2EE w najróżniejszych
> środowiskach, darmowych i komercyjnych, pod najróżniejszymi JVM-ami:
> - są o wiele bardziej zasobożerne od ich funkcjonalnych odpowiedników
> pisanych w C/C++ (jak raz parę możliwości porównania mam, to wiem);
> - ciekną - w garbage collector uwierzę jak zobaczę ;)
> - ohydnie logują (nie wątpię, że dla programisty kilometrowe zrzuty z
> wyjątków są wybitnie przydatne, ale mówimy o systemach oddanych do
> eksplotacji); alternatywa "logować mniej/nic" nie wchodzi w grę;
>
> Krótko mówiąc, w utrzymaniu bywają prawdziwym bólem w dupie. Tak jakby
> były pisane dla programistów, nie dla odbiorców. Potwierdza się to zresztą
> gdy napotkasz na jakąkolwiek zagwozdkę związaną z utrzymaniem i szukasz
> pomocy w dokumentacji. "Tu sobie dopisz fooshmoo, tu sobie zrekompiluj, tu
> w tej klasie popraw to i tamto".

Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadku
ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Aleksander Galicki <t...@g...pl> wrote:
> Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
> aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadku
> ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
> jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
> powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.

Być może w doskonałej przyrodzie tak jest. W mojej zbyt często zdarza się
jeden z poniższych scenariuszy:

- Supportu nie ma, bo nie. Mam jedną taką aplikację - odebrana w 2002
chyba, dostawca rokrocznie zwiększał cenę maintenance'u, aż ktoś wywalił to
z budżetu z argumentem "w razie czego będziemy im płacić za wykonanie
pracy". A nikt mi takich kosztów nie chce zaakceptować ("przecież wystarczy
zrestartować i działa"). Na szczęście akurat z tą aplikacją nie ma za wiele
problemów.

- Support jest, ale dostawca, traf chciał, zatrudnia (powiedzmy) 30
programistów, a wykonuje dla nas dziesiątki superważnych projektów.
Priorytet mojego zgłoszenia jest w związku z tym obniżany przez osoby
decyzyjne ("przecież wystarczy zrestartować i działa").

- Jak już się doczeka analizy - zazwyczaj rozwiązanie sprowadza się do
"Zwiększcie pamięć kontenera/pulę połączeń" (ha, ha). Problem odsunięty o
parę tygodni, w trakcie których ticket się zamyka, a kolejne zgłoszenie
traktuje jak zupełnie oddzielne zdarzenie, oddzielnie liczony czas reakcji
etc.

- Aplikacja jest "rozwojowa", biznes nieustannie zleca tworzenie nowych
funkcjonalności, które są dokładane po kilka/kilkanaście tygodniowo,
terminy naglą, programiści piszą byle jak, w rezultacie na miejsce jednego
usuniętego leaka przychodzą 3 nowe.

Najlepsze jaja są wtedy, gdy system A jest zintegrowany z systemem B innego
dostawcy - wtedy wszystkie problemy z A można oczywiście zrzucić na ten B.
Dostawca B się naturalnie wypiera i jest wesoło, bo nie ma winnych, a
downtime rośnie... :)

Powiesz, że "cóż, nie masz kasy, to cierp" - ale moja firma chyba nie
jest jakoś bardzo odosobniona w tym, że finansowanie wrzuca głównie w
tworzenie nowych rozwiązań biznesowych, a coś, co już raz wdrożono, uznaje
się za rozdział zamknięty - chyba że problem jest na tyle krytyczny, że
wstrzymuje sprzedaż/produkcję bądź jest błędem związanym z bezpieczeństwem.
I tak sobie lecimy na workaroundach, bo "przecież wystarczy... etc". :)

a.

do góry

> Być może w doskonałej przyrodzie tak jest. W mojej zbyt często zdarza się
> jeden z poniższych scenariuszy:

> Powiesz, że "cóż, nie masz kasy, to cierp" - ale moja firma chyba nie
> jest jakoś bardzo odosobniona w tym, że finansowanie wrzuca głównie w
> tworzenie nowych rozwiązań biznesowych, a coś, co już raz wdrożono, uznaje
> się za rozdział zamknięty - chyba że problem jest na tyle krytyczny, że
> wstrzymuje sprzedaż/produkcję bądź jest błędem związanym z bezpieczeństwem.
> I tak sobie lecimy na workaroundach, bo "przecież wystarczy... etc". :)

Bo o to właśnie chodzi w biznesie, aby zarabiać kasę. A dopóki Twoje
zmagania są dla firmy opłacalne, to nie ma sensu topić kasy w czymś
nierozwojowym, tylko dla wygody pracownika/ów.

Pocieszę Cię, że pracownicy większości zawodów mają znacznie gorzej.


--
Zobacz, jak się pracuje w Google:
http://pracownik.blogspot.com

do góry

asiaque <a...@w...hell.pl> napisał(a):

> Aleksander Galicki <t...@g...pl> wrote:
> > Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
> > aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadk
> u
> > ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
> > jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
> > powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.
>
> Być może w doskonałej przyrodzie tak jest.

To nie jest doskonalosc, to calkiem zwyczajna normalnosc. To co opisujesz to
jest raczej przypadek kompletnej indolencji w zarzadzaniu (Twoja firma). Na to
zaden jezyk programowania rady nie da.
Choc, to ze macie problemy z memory leaks wskazuje, ze developerow tez macie
nienajlepszych (oglednie mowiac). Ostatni raz, gdy widzialem leak w aplikacji
javowej bylo z 6 lat temu. Ale jest istotna roznica pomiedzy memory leaks a
niewystarczajaca iloscia zasobow dla aplikacji. Dostalas niewatpliwie
java.lang.OutOfMemoryError z jakims komunikatem. Z ciekaowosci: jaki byl
komunikat?

A jak powinno byc? Mniej wiecej tak: firma, ktora potrzebuje i ktora stac na
nascie projektow softwareowych zatrudnia zespol odpowiednich prawnikow i pare
tzw enterprise/solution architects. Zadaniem prawnikow m.i. jest takie
formulowanie umow z firmami programistycznymi by zapewnic interesy wlasnej
firmy i, w razie czego, ud..nie firm, ktore sie nie wywiazuja z podpipsanych
kontraktow. Zadaniem architekta (czesto jest to osoba, ktora spedzila z 10 lat
po drugiej stronie i zdecydowala sie na 10 razy mniej ciekawa prace za 3 razy
wiecej kasy) jest kontrolowanie i zatwierdzanie merytoryczne tego co robi
wykonawca. Zwykle takie jednorazowe projekty to tzw fixed price-fixed size, co
oznacza ze termin, koszty, deliverables i jakosc owych deliverables sa
ustalone przy podpisywaniu kontraktu. Za dowolne poslizgi wzgledem ustalonych
uprzednio kosztow i terminow placi wykonawca. Kary za poslizgi tez sa
ustalone. Krytycznych bugow po releasie zwykle nie ma, bo przed releasem jest
paromiesieczny (dla srednio malego projektu) okres testowania. Wtedy sa tez
kilka rund tzw user acceptance testing, podczas ktorych powinny byc naprawione
wszystkie bugi wylapane przez zewnetrzych testerow. To sie nazywa user
acceptance testing, bo dopoki nie sa naprawione wszystkie bugi kleint moze nie
przyjac projektu, co bedzie roznowazne z uruchomieniem zespolu prawnikow,
ktorzy ud..pia wykonawce w razie nienaprawienia chocby jednej literowki. Mniej
wiecej w tym samym czasie sa tez testy niefunkcjonalne: m.i. ze skalowalnosci,
wydajnosci, bezpieczenstwa i niezawodnosci (odpowiednie oczekiwania tez
powinny byc zawarte w kontrakcie, a architekt jest odpowiedzialny za ich
sensownosc). Dla zwyklych aplikacji biznesowych zwykle sie wynajmuje na dwa
tygodnie odpowiednia ilosc serwerow w np jednym z HP Solution Centers i sie
testuje: co sie stanie z aplikacja po 1,5,10,15... latach, co bedzie jak
przewidziana liczba uzytkownikow skoczy z X do 100*X i tak dalej. Pelna
dokumentacje z tego testowania przekazuje sie architektom klienta do
akceptacji. Po zaakceptowaniu tego wiekszych problemow z wydajnoscia przez
nastepne nascie lat nie powinno byc bo to ile zasobow potrzebuje aplikacja
jest udokumentowane. Dla odrobine wazniejszych aplikacji, procz takiego
testowania jest tez okres, gdy aplikacje nie jest jeszcze w produkcji ale jest
na pilot environment.

Nie masz tak we wlasnej firmie? Zmien firme.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry