🚀 go-pugleaf

Sektor van Skijlen napisał:

> 
> 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.

Nie - w tej częsci dyskutowaliśmy o constraintach na parametry w generykach.


>>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?

No jasne. Z uwagi na użycie przeciążania operatórów - w kodzie 
sprowadzanym z zewnątrz, własnym i do tego jeszcze w STL.
Napisz, że zawsze używasz  operatorów w tym samym (semantycznie) sensie.
Sorry już samo cout<<"text"; superuje, że choćby z << jest ... "kłopot".



> 
> 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.

Właśnied dokładnie... to JEST dla mnie wzgląd.
> 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ę.

Rozumiem, że widzisz rozwiązanie - piszmy w C++ tylko patrzmy wszystkim 
na ręce. ( a kto patrzy kierownikowi ? ).
To ja już jednak wolę automatyzację, sporadyczne sprawdzanie itp.
Taniej wychodzi - a w Javie starcza zupełnie. Mogę sobie swobodnie 
wrzucić jakiś absurdalny kod (np. wyprodukowanyw Elbonii fragment 
dotyczący gui)  do projektu i mam pewność, że co najwyżej sam un kod się 
wykrzaczy a reszta programu nie ucierpi ani troche (nikt mi pamięci nie 
pomaże, a jak będzie trzeba to się nawet temu fragmentowi odetnie IO i 
reszte :-) ) .


>>Zawodny.... zgadzam się.
>>Mniej wydajny? w jakim sensie?
> 
> 
> Nie rozśmieszaj mnie nawet. Tłukę ten temat już od dłuższego czasu.

Nie tłucz - napisz konkrety.

> 
> 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.

Jak to by nie zaistaniały ? a co to C++ to jakiś inny, bezpieczny język 
jest ?

> 
>>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ę.

Najczęstszy przykład to jak wygląda walka o tzw. wydajność.

Typowy programista (długoletni w C++) widzi świat bardzo statycznie.
Zapominając, że we pomimo, że fragment kodu wygląda:
	(MyObject)list.get(4);
to  w kodzie faktycznie uruchamianym może nie być:
	- wywołania funkcji (inlining automatyczny),
	- sprawdzania zakresu tablicy, (wewnątrz get ),
	- sprawdzania zgodności typów (bo poco - sztuka jest sztuka).

Kompilator HotSpot wie o lokalnym kontekśćie programu o wiele więcej niż 
statyczny kompilator C++ i z tego powodu pewne trywialne operacje... 
mogą po prostu być wymazywane.
Niewiedza o tym prowadzi do konstruowania potworków z omijaniem 
rzutowania itp.
Najgorzej wygląda sprawdzanie wydajności - typowy programista C++ ma 
świadomość, że po skompilowaniu programu już się nie da z niego nic 
wycisnąc... a tu prosze  te opcje, które dotycza wydajności i który taki 
zrozpoczony gość szuka przy opiesie javac są dostępne w komendzie java.
Co gorsza tworzy sie benchmarki, które mierzą (niepotrzebnie) czas 
uruchamiania, kompilacji i potem wyciąga się durne wnioski

Po prawdzie to pamietam, że przechodząc z C++ ileś razy wrypałem sie w 
jakieś bardzo zabawne  pułapki - ale nie przypomnę sobie teraz.
> 
> 
>>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.

No to wam bardzo wspólczuje. Może jednak kierownik każe wam przejś na 
jave jeśli zależy mu na zdrowiu swoich oczu.

>>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.
A pisze, że niezwykłe coś jest?
> 
>>Wybór bardziej koszernego języka jest jedną z form tej automatyzacji.
> 
> 
> Co za szurnięty argument...

Całkiem oczooszczędny :-)
> 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.

Czy piszesz o tej swojej klasie Value - widzisz w C++ zrobienie czegoś 
zabezpieczającego choćby skutecznego w 95% jest cholernie trudne.

>>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ć).
To się nazywa kupić. My niestety nie mamy prawa własności do kodu.

> Nikt nie ma kontroli nad tym, jak oni ten kod piszą.
Może musisz podrzucić swojego kierownika ?

> Nikt tego kodu po nich nie ogląda.
Czyżby mieli inne zajęcia po godzinach ?

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

Dzięki, ogólnie, ciesze się że tak doskonale znasz moją firmę - jak ktoś 
z moich współpracowników to przeczyta - to się pięknie załamie :-).
Zwłaszcza, że mnóstwo z nich przyszło do nas uciekajac przed niezłym 
syfem w polskich i zagranicznych firemkach.

> 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.


> 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.

No, zacytuje "pusty śmiech" mnie ogarnia. Lepiej zrób analize jakie 
zmiany wprowadza opcjonalny odśmiecacz - albo 4 używane na raz w jednym 
programie w C++.

>>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?
debugowanie w takim przypadku nie pomaga.
zrobiłem coś w stylu zliczania instancji i kontroli pamięci (na wszytkie 
moje typy  -to mogłem łatwo)--  nie pomogło.
sprawa dotyczyła exportowania gdzieś głupiej tablicy 2 doubli.
(nie pamiętam jak znalazłem to w końcu - czy z jakimś narzędziem czy 
przez przypadek  - pamietam, że długo wiedziałem w których kilku 
linijkach jest problem ... ale nie czaiłem co jest nie tak.
w końcu jak się korzysta z stl to się o takich rzeczach jak delete[] 
zapomina dość szybko :-) )

> 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
znowu mnie uczysz javy ? i to puszczając stronke jakiegoś frustrata?
Memory leaks w programach w javie to dla mnie chleb powszedni 
(sprawdzanie głównie czy aby nie ma)- tyle, ze mam dość fajne narzędzia 
do analizy sterty  - które powodują,  że błyskawicznie znajduje się 
winnych (jeśli sa - w javie trzeba się troche postarać).
  Fajne narzędzia to znaczy - umożliwiają np. monitorowanie sterty na 
systemie produkcyjnym i to co do ostatniego bajta - nieważne z jakiej 
biblioteki pochodzi.

(BTW> w javie pod tym wzgledem, przeszkadza przyzwyczajenie z C++, w C++ 
jak się da delete na obieklcie który jest w użyciu to sie program 
wywali, i programista C++ jest przyzwyczajony do problemu dokładnie 
odwrotnego - szukania nadmiarowych delete, a nie jak w javie 
nadmiarowych użyć)

>>>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.
Sam łatwo napiszesz przykład złośliwy.... tylko po co?
Nie wyciągne teraz odpowiednika z rzeczywistości, ale akurat taki 
problem się może pojawić - koniec.

>>>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.

Ciekawostka.

> 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++.

Nie mogłem tak traktować, C++ znałem na wylot na długo (lata) zanim 
pierwszy fragment programu w javie zobaczyłem na oczy.

>>>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.
A nie mozna pokryć makrem { i  } ?(nie wiem to pytanie - nie chce mi sie 
sprawdzać )

>>w C też.
> 
> 
> No jasne, pożartujmy sobie jeszcze.

>>>
>>>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.

Widzisz, ja ten projekt oglądałem jak się rozwijał.

>>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ł.

JSR-14 - to oni.

>>(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ń.
Czyżby w takim razie wydajność nie miała znaczenia (pisze o rozwijaniu 
pętli) :-) ?

> 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).

Argument równie sensowny jak ten, że const referencje nie bedą działać 
na AMDkach. JVM to prawie chamski assembler - naprawde ma w ... d - co 
też jest przez kompilator javac tworzone ( i ile jest tego kodu).

Jest jeden ważny ficzer obecnej implementacji - zgodność starego 
skompilowanego kodu z nowym (przy generykach) - ale to nie jest ficzer 
przesądzający. W końcu mogli np. kazać stare biblioteki przekompilować.


>>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.
Bzdura - juzo tym pisałem. Po co ma to robić? To nie C++ tu runtime wie 
z czym pracuje.

> 
>>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.
No dobra - tak czy siak zostało mi jeszcze 2 gb wolnego :-)

>>(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>.
Na sto milionów booleanów - będę pamiętał raczej. Jak mi poleci 
OutOfMemory - tym bardziej :-)

>>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").

Zaglądnij na forum java generics na java sun - tam sie to tłucze 3 razy 
dziennie.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html