🚀 go-pugleaf

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


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

> W mojej obecnej firmie w każdym razie takie coś nie miałoby szans dotrwać
> nawet do UT.
> 
> W mojej poprzedniej firmie, w której trzeba przyznać, że panował niemalże
> totalny bałagan jeśli chodzi o tworzenie kodu, nie było żadnego procesu,
> planowanie było jedną wielką fikcją (no cóż to jest spóźnić się z release'm o
> dwa miesiące), pojęcie testowania jednostkowego było dopiero w fazie "a
> wiecie, mam taki pomysł" - ale przynajmniej była instytucja kierownika, nawet
> trochę nieformalna. I na przeciążanie operatorów trzeba było napisać specjalne
> podanie do kierownika (że tak powiem).
> 
> 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++.

>>>>Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
>>>>metaprogramowania ani trochę.
>>>
>>>
>>>Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.
>>>
>>>
>>>
>>>>I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.
>>>
>>>
>>>No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
>>>że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
>>>jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
>>>jak było z generykami.
>>
>>Widzisz bo to właśnie był sens Javy (i obecna moja tendencja do unikania 
>>  C++). Wyrypanie tych pięknych ficzerów:
>>        - bez których da się spokojnie żyć,                                             
>>	  - i z których umiejętnie korzystać potrafi 1% programistów,
>>        - i z których korzysta 50% reszty programistów absolutnie wypaczając sens
> 
> 
> i bez których najczęściej nie da się napisać czytelnego i zrozumiałego kodu.
> 
> 
>>Dokładniej:
>>Makra,
> 
> 
> Pomińmy preprocesor. Poza koniecznością wykorzystania __FILE__ i __LINE__
> (ewentualnie __FUNCTION__ w gcc) nie ma on w C++ prawie żadnych zastosowań.
> 
> 
>>meta programowanie,
> 
> 
> Tak jasne! Zastąpmy je znacznie bardziej zawodnym (i znacznie mniej wydajnym)
> dynamizmem.

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

>>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;
> 
> 
>>( strzelam, że obecnie mnóstwo ludzi korzysta z meta programowania do 
>>rozwijania prostych pętli ... co jak się nieumiejętnie robi (nie 
>>sprawdza) zabija wydajność zamiast poprawiać)
> 
> 
> Nie strzelaj lepiej, albo najpierw poćwicz trochę, jak chcesz trafiać.
> Obecnie prawie nikt nie korzysta z metaprogramowania tak naprawdę. Problem
> jest faktycznie rozdmuchany. Ale mocno korzystają z tego niektóre biblioteki
> i naprawdę to wszystko do czego powinno to być wykorzystywane.
> 
> 
>>Powiem więcej - mimo, że w  mniejszych projektach nie mam oporów z 
>>korzystaniem z java generics... to przy większych projektach zespołowych 
>>w javie... prawdopodobnie optowałbym za nie korzystaniem z genericsów (w 
>>sensie tworzenia własnych typów). Czytelność i prostota kodu to jest 
>>element, którego nie można pominąć, a nie wiem czy chciałbym oglądać 
>>"generyczny" kod stworzony przez człowieka, który właśnie w swoim kraju 
>>przeszedł kurs "learn java in 21 hours". ( w zasadzie to w ogóle nie 
>>chciałbym pracować z żadnym kodem tworzonym przez takiego gościa ... 
> 
> 
> No, może w ogóle to od tego zacznijmy. Ja mam przede wszystkim poważne
> wątpliwości, czy taki gościu jest w stanie poprawnie używać generyków. Skoro
> nie będzie w stanie to nie będzie ich używał.
> 
> Faktem jest, że ja ostatnio - co może nie było konieczne, ale szlag mnie
> trafia, jak widzę taki kod, zresztą na inspekcji ludzie byli tego samego
> zdania - poprawiłem takie oto kwiatki:
> 
> const std::string& name = std::string( "/usr/name/bin" );
> 
> i tym podobne.
> 
> 
>>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.

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

>>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.
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.
I jeśli zostawi się jakąś furtkę to zawsze znajdzie sie ktoś kto w nią 
wlizie (bez pozwolenia). W takim projekcie jedyną rozsądną formą 
sprawdzania jest ... automatyzacja - (kontrola stylu, cyclomatic 
complexity, unit testy etc.). Wybór bardziej koszernego języka jest 
jedną z form tej automatyzacji. 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).

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

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[]. To mi wystarczyło. Nadal pisałem w C++, ale 
dostawiłem sobie odsmieczacz, potem dostawiłem obsługe wątków rozsądną i 
kilka takich ficzerów i mój team odkrył, że piszemy w javie :-).
Mieliśmy z tego nawet ostrą radochę. W końcu przy kolejnym projekcie
pozostało skończyć z hipokryzją i zwyczajnie zacząć pisać w normalnej javie.

>>>Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
>>>jeszcze niczego nie oznacza.
> 
> 
>>Jeśli to jest ta piękna biblioteka, która ma uratować C++ 
>>(standaryzacja) .. to wiele znaczy.
> 
> 
> Ja podejrzewam, że głównie te komplikacje wynikają z ograniczeń kompilatorów
> oraz chęci robienia niestandardowej konfiguracji (np. inne nazwy). Bez
> wypasionych ficzerów sterowania biblioteką, w najprostszej postaci, myślę że
> dałoby się to zrobić znacznie prościej.

Też tak myśle :-)

>>>Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
>>>zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
>>>niczym nie przeszkadza.
> 
> 
>>Zależy jak się na to patrzy. W Javie jest coś takiego jak 
>>instrumentacja, refleksja, generowanie kodu w runtime... załatwia się 
>>tym podobną klasę problemów co meta programowaniem w C++ (czyli dość 
>>specyficzne, mocno technologiczne problemy).
> 
> 
> No, chyba na tym się kończą podobieństwa.
> 
> 
>>Niestety, w praktyce załatwia się też całą masę problemów, które można 
>>zrobić zwyczajnie (korzystając z podstawowych własności każdego języka 
>>"obiektowego").
>>Taka, kurde.... moda. A potem kod się kompiluje pięknie tylko trzeba 
>>debugować, żeby odkryć czegoż to jeszcze nie dodaliśmy do naszej klasy, 
>>co akurat niejawnie używane jest w bibliotece XY.
> 
> 
> 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.

> 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++ :-)

>>>I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
>>>sposób. A jest to bardzo istotny element C++.
> 
> 
>>z tego co pamiętam destruktory miałem -
> 
> 
> Nie bardzo mi się chce wierzyć.
> 
> 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ć :-)
w C też.


>>>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.
Głównym powodem takiej a nie innej implementacji java generics są ... 
urządzenia mobilne. Chcieli chłopaki objętość programów ograniczyć... bo 
stwierdzili, że to może być większy problem niż rozmiar danych.
(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ć).
(Fakt, że na normalne komputery do zastosowań nawet desktopowych 
objętość kodu programu ma marginalne znaczenie)

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.

>>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).
(pomyśl o std::vector<bool> kiedyś ktoś walnął tym samym argumentem co 
ty porównując C z C++ :-) ).
Co za problem zdobyć na tak specyficzny przypadek odpowiednio 
przygotowaną implementację.
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. )


>>(OK. byłyby duże zmiany w refleksji - ale to jest ( w kontekście 
>>porównania z C++) wewnątrzjavowy problem).
> 
> 
> No tak właśnie słyszałem, że to był jeden z głównych powodów.
> 
> Z drugiej strony, ciekaw jestem w takim razie, jak wygląda refleksja w
> przypadku typu int.

Całkiem nieźle - (kiedyś mnie to pozytywnie zaskoczyło). Sprawdź sobie.

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