🚀 go-pugleaf

Dnia Sat, 22 Oct 2005 12:19:43 +0200, jarekr skrobie:
> Sektor van Skijlen napisał:

> >>Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
> >>framework z użyciem generics i narzucam, ze jakiś tam typ X można 
> >>konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
> >>Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
> >>możliwość w miarę bezpiecznej ewolucji frameworku.
> > 
> > 
> > No jasne i co jeszcze.
> > 
> > Patrzysz na to od dupy strony: nie porównuj tego z wzorcami C++, tylko
> > porównaj to z tym, gdybyś sam ręcznie robił to, co generyki robią za ciebie.
> > To znaczy, porównaj z kodem, który byś pisał rzeczywiście obiektowo, bez
> > generyków.

> Wybacz - ale nie rozumiem co masz na myśli. Właśnie porównywaliśmy z 
> wzorcami  C++.

Na razie to dywagowaliśmy, jakiej jakości jest "ficzer" generyków dodatny w
Javie i czy coś to dobrego językowi przyniosło. W tym celu należy porównać
pisanie z generykami i pisanie tego samego bez nich.

> >>W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
> >>powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
> >>  mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
> >>w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
> >>użyje przewidywał).
> > 
> > 
> > Wiesz, nie wiem, w jakiej firmie pracujesz/pracowałeś, że w ogóle takie rzeczy
> > są możliwe.

> Tak naprawdę potykałem się najwięcej jak miałem własną firmę krzak dawno 
> temu. W zasadzie dotyczyło to prób korzystania z różnych ściąganych z 
> googla bibliotek, algorytmów, źródeł, których chciałem używać... 
> odkryłem że w C++ to się nie da (z wymienionego powodu) (a javy wtedy 
> nie znałem za bardzo).

Nie rozumiem. Znaczy się co, miałeś problem z korzystaniem z tego z uwagi na
szurnięte użycie przeciążania operatorów?

> > Nie potrafię sobie wyobrazić, jak pracuje firma, w której każdy może sobie od
> > niechcenia przeciążać operatory jak mu się podoba.

> Dokładnie też sobie nie wyobrażam - dlatego właśnie unikam firm i 
> projektów w C++.

Ależ niemożliwość przeciążąnia operatorów niczego ci nie załatwi.

W Javie można zrobić kupę różnych głupot również z wielu innych powodów. Pod
tym względem Java może jest mniej harmful, niż C++, ale wcale to nie oznacza,
że się pod tym względem bardziej nadaje do tworzenia oprogramowania.

Zresztą dla mnie argument jest z gruntu kuriozalny: chcemy mieć dobre
oprogramowanie, to zatrudniajmy dobrych programistów i przede wszystkim
PATRZMY IM NA RĘCE. Nie ma lepszego filtra na dobry kod niż dobry, zaufany
kierownik; narzędzia do mierzenia złożoności (różne Mckejby i klocworki) kodu
trochę pomagają, ale tylko trochę.

> >>meta programowanie,
> > 
> > Tak jasne! Zastąpmy je znacznie bardziej zawodnym (i znacznie mniej wydajnym)
> > dynamizmem.

> Zawodny.... zgadzam się.
> Mniej wydajny? w jakim sensie?

Nie rozśmieszaj mnie nawet. Tłukę ten temat już od dłuższego czasu.

> >>operator overloading.
> > 
> > No oczywiście, przecież ten poniższy kod jest bardzo czytelny:
> > 
> >       a.setVal(s.add(b.multiply(x.at(g.subtract(1))).divide(6)))
> > 
> > Nie to co C++:
> > 
> >       a = s + (b * x[g-1])/6;
> > 

> >>niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
> >>dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
> >>fragmentami zrozumieć i na szybkiego załatać).
> > 
> > 
> > Podejrzewam, że problemy, na które się natknąłeś są java-specific.

> Jesteś coraz bardziej doskonały w swoim zacietrzewieniu.

No przecież mówiłeś akurat o problemach, które w C++ by nie zaistniały z
przyczyn zasadniczych. Więc nie rozumiem, o co ci chodzi z tym
zacietrzewieniem.

> > W przypadku C++ jeśli miałem kiedykolwiek jakiekolwiek problemy z brzydkim
> > kodem w C++, to były one tworzone przez ludzi, którzy albo byli wyślizgani w
> > języku C i wszystko robili na chama, albo byli wyślizgani w Javie i wydawało
> > im się, że w C++ też tak jest dobrze.

> He, he - dokładnie mam to samo tylko u mnie problemy są z ludźmi 
> wyślizganymi w C (tworzą absurdalny kod) i  C++ (tworzą ciekawe i 
> sprytne koncepcje... które w javie nie działają, nie mają sensu, albo są 
> dramatycznie niewydajne).

No właśnie to mnie interesuje. Jak może programista C++ źle pisać w Javie?
Przykłady poproszę.

> >>Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
> >>zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
> >>niegłupi, tylko bardzo *kreatywny* ) pan X.
> > 
> > 
> > Wychodzi jednak na to - jak wspomniałem - że prawdziwym problemem jest nie
> > niebezpieczna potencjalnie właściwość języka, tylko zła organizacja pracy.

> Idealną organizację pracy to możesz mieć z 2-3 ma dobrymi kumplami.

Idealnej, to od tego zacznijmy, miał nigdy nie będziesz.

W naszej firmie mamy jednak organizację pracy wystarczającą do zapewnienia
dobrej jakości kodu - pod KAŻDYM względem.

> Co innego jak  pracujesz nad kodem, który jest rozwijany 6-7 lat w 
> różnych krajach (równocześnie) i połowy deweloperów nie kojarzysz nawet 
> z nazwiska. Trzeba sie zabezpieczać na wszelkie sposoby.

No właśnie nad takim pracuję.

> I jeśli zostawi się jakąś furtkę to zawsze znajdzie sie ktoś kto w nią 
> wlizie (bez pozwolenia).

Zdarzały się takie próby. Jak oglądał to jakiś kierownik w Stanach, to
faktycznie niektórzy włazili. U nas jednak się to jeszcze nie zdarzyło. U nas
kierownicy są tak skuteczni, że żadnemu takiemu sabotażyście nie przepuszczą.

U nas na WSZYSTKO trzeba mieć pozwolenie. Od kierownika. Każdy kawałek kodu,
który powstaje, albo jest zmieniany, musi przejść przez jego oczy.

> W takim projekcie jedyną rozsądną formą 
> sprawdzania jest ... automatyzacja - (kontrola stylu, cyclomatic 
> complexity,

Taaa... najnormalniej w świecie oszukujecie się. Faktem jest, że to jest też
dobre, bo powstrzyma zapędy różnych cwaniaczków od robienia syfu, ale to nie
jest lekarstwo na wszystkie problemy.

> unit testy etc.).

Nie wiem, co takiego jest niezwykłego w UT, przecież to normalny etap pracy
nad oprogramowaniem.

> Wybór bardziej koszernego języka jest jedną z form tej automatyzacji.

Co za szurnięty argument...

Jeśli potrzeba nam faktycznie jakiegoś sprawdzania, czy użytkownik nie użył
czasem takiej-a-takiej zakazanej konstrukcji, to można albo zrobić narzędzie,
które samo to sprawdzi, albo to tak czy siak wyjdzie na inspekcji.

To samo dotyczy C++ jak i Javy.

> W zasadzie myślę, ze nie patrzysz na 
> problem z tego punktu widzenia co ja. Dla mnie różnice miedzy C++ 
> (dobrze opakowanym w boost, stl, gc,  itp) a Javą (z puntku widzenia 
> samego języka) są małe. Jest to ten sam, hakerski, imperatywny, bez 
> polotu język (tylko przynoszący zysk).
> Idąc dalej w projektach, gdzie mogę to narzucić nie używam javy ... 
> tylko jej mocno ograniczonego podzbioru (narzuconego kontrolą stylu, 
> miarami  itp).

To ja nie rozumiem, z jakiego punktu widzenia ty patrzysz na problem.
Mogę to określić w ten sposób:

Masz zespół kilku programistów, którzy nad kodem nie mają żadnej kontroli (w
każdej chwili ten kod może wziąć kto inny i namieszać).

Nikt nie ma kontroli nad tym, jak oni ten kod piszą.

Nikt tego kodu po nich nie ogląda.

Każdy sobie pisze jak mu się podoba i nikt nie sprawdza, co każdy gość
naskrobał.

Może to, że ja z takim sposobem tworzenia oprogramowania nie miałem do
czynienia nigdy od czasu rozpoczęcia pracy w mojej bieżącej firmie, powoduje
właśnie tą różnicę w punktach widzenia.

> > Wygląda na to więc, że Java jest językiem dedykowanym dla firm typu "krzak", w
> > których nie ma żadnej sensownej organizacji pracy. Z jednej strony to dziwne,
> > skoro dla Javy wymyśla się tyle wypasionych technik zarządzania projektem. Z
> > drugiej strony, to raczej nie dziwi, skoro Java wymusza stosowanie
> > odśmiecacza, który - jak już nieraz zaznaczałem - potrafi skutecznie ukrywać
> > błędy w oprogramowaniu.

> Przeczytaj sobie cały ten swój paragraf jeszcze raz. Zastanów się co 
> piszesz. Weź sie, kurde, umyj.

Nie obawiaj się o moją świadomość podczas pisania. To akurat mówi każdy, kto
przeprowadził rzeczową analizę o tym, jakie zmiany w języku wprowadza
obowiązkowy odśmiecacz i jakie są jego zalety i wady.

> Spędziłem kiedyś parę tygodni poszukując wycieku pamięci w średnim 
> projekcie w C++ bez odśmiecacza... i znalazłem, że gdzieś było użyte 
> delete ... zamiast delete[].

A mogę zapytać, w jaki sposób to znalazłeś? Czy może poprzez debugowanie kodu?
Jeśli tak, to rzeczywiście, nie dziwię się, dlaczego musisz używać
"ograniczonych języków".

> To mi wystarczyło. Nadal pisałem w C++, ale dostawiłem sobie odsmieczacz,

Typowe podejście w stylu łatania bezpiecznika drutem.

Odśmiecacz _NIE_ załatwi ci problemu wycieków pamięci. Pozwoli ci tylko co
najwyżej mieć tą pamięć pod kontrolą, co najczęściej oznacza, że jesteś w
stanie powstrzymać co najwyżej tzw. progresywne wycieki pamięci. Mające
znaczenie tylko gdy są faktycznie częste, a aplikacja ma chodzić długo bez
restartu.

Jeśli masz jakieś przekonujące argumenty, że jednak odśmiecacz ma zalety, to
zapoznaj się najpierw z tym poniżej:

http://warp.povusers.org/grrr/java.html

> > Zapominasz znów, że to są problemy Java-specific. W przypadku C++ jeśli kod
> > "metowy" jest zły, to się po prostu nie skompiluje. Jak się skompiluje, to
> > najczęściej oznacza, że jest dobry. Natomiast stosowanie metod dynamicznych,
> Nie jest tak jak piszesz - skompiluje sie i wylezie problem dopiero np. 
> na testach - podawałem już dlaczego.

Pokaż mi jak i dlaczego - niczego nie napisałeś jak do tej pory o tym,
dlaczego tego typu problemy są w C++ przy wzorcach. O ewentualnych przykładach
nie wspominając.

> > co jest bardzo powszeche w Javie, oznacza w praktyce konieczność robienia
> > bardzo rozbudowanych testów jednostkowych zapewniających poprawność. Często
> > też konieczność debugowania tego, czy te instrukcje w runtime poskładały się
> > do kupy tak, jak powinny.
> Dokładnie tak jest w jednym i w drugim języku. Zaczynam poważnie 
> podejrzewać, że nie masz wielkiej styczności z C++ :-)

Dokładnie tak jest w jednym i w drugim języku, ale o ile w C++ jest występuje
to tylko w tych miejscach, w których rzeczywiście dynamizmu używamy, o tyle w
Javie występują one po prostu WSZĘDZIE, bo WSZĘDZIE używa się dynamizmu.

Skoro ty nie wiesz takich prostych rzeczy, to pewnie dlatego, że od początku
traktowałeś C++ jak Javę bez odśmiecacza. Co też odpowiednio świadczy o twojej
znajomości C++.

> > Sam miałbym problemy z ich zaimplementowaniem, mając na uwadze dowolny poziom
> > zagnieżdżania kontekstów wewnątrz jednej funkcji.

> Stary, jak to ? przecież w makrach da się wszystko zrobić :-)

Nie wstawienie odpowiednich kawałków kodu w arbitralnych miejscach.

> w C też.

No jasne, pożartujmy sobie jeszcze.

> >>>Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
> >>>wszystko.
> >>>
> >>>Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to
> > 
> > 
> >>Ale w jakim sensie  *efficiency* ?
> > 
> > 
> > W każdym. Zużycie pamięci i mocy procesora.
> Pomyliłeś się w jednym i drugim.
> Bo to nie jest takie proste jak Ci się wydaje.

Oczywiście, że jest proste.

Jeśli mam choćbyu ten cały stos intów, to overhead na każdy obiekt klasy
opakowującej doskonale obniża wydajność, jeśli porównać to z używaniem
"gołych" intów. I to wydajność pod "każdym" względem.

> Głównym powodem takiej a nie innej implementacji java generics są ... 
> urządzenia mobilne.

Taaa.. bardzo jestem ciekawy, skąd ty masz takie informacje.

> Chcieli chłopaki objętość programów ograniczyć... bo 
> stwierdzili, że to może być większy problem niż rozmiar danych.

Zaraz się chyba rozpłaczę do rozpuku. W sytuacji gdy różnica w objętości
pomiędzy kodem a danymi liczy się w rzędach wielkości, goście martwią się, że
im się kod niebezpiecznie rozrasta.

> (wcale nie mam pewności co do tej tezy  -ale nie ja ją wymyśliłem a nie 
> jestem specem od oprogramowania małych urządzonych, żeby sie wypowiadać).

To może powiedz mi, kto ją w takim razie wymyślił.

> (Fakt, że na normalne komputery do zastosowań nawet desktopowych 
> objętość kodu programu ma marginalne znaczenie)

Objętość kodu programu ma marginalne znaczenie w ogóle. Zwłaszcza
wystarczająco dobrze o tym świadczy popularność optymalizacji przez rozwijanie
pętli i wywołań.

Z tego, co ja wiem, to generyki są jakie są tylko i wyłącznie dlatego, że jest
to jedyna metoda, żeby wpasowały się w aktualne reguły wirtualnej maszyny
(przynajmniej tak twierdził Anders Hejlsberg).

> Co do zużycia procesora - to jest zagadnienie już inne - ale patrząc na 
> to, że finalnemu kodowi w asemblerze zupełnie zwisa jaki co ma typ to 
> ten argument jest taki sobie.

Ale nie zwisa mu to, ile razy dereferuje wskaźnik i ile szurniętych operacji
musi wykonać, żeby przeprowadzić operację na takich wartościach.

> >>To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
> >>ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
> >>kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
> >>  zmieniło (poza rozmiarami programów wynikowych).
> > 
> > 
> > Nie wiem, może Java ma tak badziewne VM, że takie ulepszenie nie zrobiłoby jej
> > róznicy.
> > 
> > Ale nie mam pewności. Jeśli różnica w stosie 100 milionów intów to różnica
> > pomiędzy 400 MB i 1.5 GB, to moim zdaniem gra była warta świeczki.

> Argument dobry i prawdziwy ale jednak dość specyficzny... lepiej było 
> stos stu  milionów booleanów podać. (to dopiero byłby dramat).

Ty chyba jesteś chory. Ale dobra, niech dzisiaj znów będzie dzień dziecka:

Możliwe, że przykład nt. 100 milionów intów jest mało praktyczny. Ale nie ma
żadnej różnicy pomiędzy tym, czy mamy jeden zbiornik po 100 milionów, czy dwa
po 50. Tak? Skoro tak, to znaczy że nie ma również różnicy pomiędzy
posiadaniem jednego zbiornika, który ma 20 milionów intów, i drugiego, który
posiada 20 milionów liczb zespolonych?

I tak rozdrabniając to coraz bardziej, dochodzimy do bardziej praktycznych
przykładów, a stosunek zajętości pamięci programu w Javie i programu w C++,
gdzie używa się typów wartościowych, pozostaje prawie taki sam. Może i różnica
trzykrotnej objętości jest przesadzona, ale weź też pod uwagę, że ta zajętość
pamięci w przypadku Javy jest i tak wzięta z przesadnym optymizmem. Dlatego w
najlepszym razie program w Javie może zająć jedynie dwa razy więcej pamięci,
niż program w C++.

Jeśli zaś program w C++ zajmuje ci w czasie działania 500 MB pamięci, to
wykonujący to samo program w Javie...

No dobra. Koniec dnia dziecka na dzisiaj.

> (pomyśl o std::vector<bool> kiedyś ktoś walnął tym samym argumentem co 
> ty porównując C z C++ :-) ).

No nie rozumiem o co ci chodzi. Przecież w vector<bool> każdy element zajmuje
jeden bit. Więc vector<bool> zajmie ci zawsze tyle, co ilość bitów wyrównana
do pełnych ośmiu plus stały overhead (12 bajtów).

Nie zawsze też interesuje nas dynamiczny wektor bitowy; czasem pewnie też
sensownie jest użyć statycznego zbiornika z bitami, czyli bitset.

> Co za problem zdobyć na tak specyficzny przypadek odpowiednio 
> przygotowaną implementację.

Tak, a potem na jeszcze specyficzną i jeszcze specyficzną...

I pamiętaj tylko potem, że musisz użyć VectorBoolean a nie Vector<boolean>.

> Fakt jest taki, że java generics ma słabą stronę pod tytułem tablice.
> (nie wiem czy to będzie zmienione, poprawione w przyszłości- są różne 
> koncepcje. )

Ciekawi mnie, dlaczego tak jest, swoją drogą (nb. trzeba przyznać panu AL:
rzeczywiście "eleganckie rozszerzenie języka").


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"