🚀 go-pugleaf

Dnia Fri, 21 Oct 2005 23:26:13 +0200, jarekr skrobie:
> Sektor van Skijlen napisał:
> > W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
> > wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
> > wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
> > W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
> > ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
> > bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
> > implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
> > zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

> Sektor ! To jest naprawdę wspaniałe jak mnie uczysz jak działają 
> generyki w javie :-). (fakt, że przynajmniej technicznie trochę prawdy 
> napisałeś)

Ja tylko uzasadniam swoje zdanie.

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

> Mam pewność, ze jeśli ktoś czegoś tam nie odziedziczy to mu się kod nie
> skompiluje ( kontrola na zasadzie:  akurat przypadkiem klasa Z ma metodę
> setValue() którą wywołuje to jak dla mnie nie jest szczęśliwe rozwiązanie)

No to ci podałem przecież - możesz sobie użyć is_base_and_derived. Nawet chyba
jeszcze jest jedna rzecz, o której zapomniałem - static_assert. Właśnie ma
sypiącą się specjalizację dla parametru false.

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

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.

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

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

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.

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

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.

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

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

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

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

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

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


-- 
//  _    ___         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"