Discussion:
Dlaczego ludzie nie lubią C++?
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Sektor van Skijlen
2006-03-23 08:35:18 UTC
Permalink
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.

Przyznaję, nie dysponuję aktualnie żadnymi statystykami dotyczącymi użycia C++
w przemyśle i porównania z podobnymi statystykami dotyczącymi Javy. Jakiś czas
temu ktoś gdzieś (bodaj tu) rzucił statystykami, dotyczącymi tylko OpenSource,
które wskazywały, że C i C++ razem mają jakieś 60%, a Java ok 11%. Mówię z
pamięci. Po pierwsze, jednak, statystyki OpenSource nie są miarodajne dla
całego rynku, a po drugie, to było jakieś dwa lata temu i wiele mogło się
zmienić.

Co prawda widzę dość sporo dziedzin, w których Java raczej nie ma czego
szukać, ale już tu czytam jak to pewien osobnik obserwuje, jak firmy na gwałt
wycofują się z C++ i przechodzą na Javę. Co prawda trzeba to traktować z
drobnym przymrużeniem oka, ale myślę, że to nie jest uzasadnione.

Oczywiście jeśli C++ okaże się kiedyś narzędziem nie spełniającym wymagań dla
pisanego przez mnie oprogramowania i znajdą się lepsze, to zostawię C++ i nie
będę po nim płakał. Tak samo, jak olałem swego czasu Amigę, komputer, który w
czasach swej świetności bił na głowę PC pod każdym względem (w tym ceną), a
potem przez przez zatrzymanie się w rozwoju (i jakieś fatum, które powodowało,
że kolejno przejmujące ją firmy plajtowały) dała się PC przegonić. I też nie
było mi jej żal. Przestałem mówić dobrze o Amidze, kiedy słyszałem o super
karcie graficznej dla Amigi (jakby ktoś chciał Amigę stosować profesjonalnie;
ciekawe że podobno miały to założenie spełniać układy wbudowane), która
zawierała po prostu... układzik S3. Przy czym była trzykrotnie większa od
PC-owego odpowiednika i prawie dziesięciokrotnie droższa :)

Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych systemach
czasu rzeczywistego, nie wyobrażam sobie zastąpienia go czymkolwiek innym.
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo. A przynajmniej nie słyszałem o niczym powalającym. Miałem krótki
kontakt z projektem, w którym goście przepisywali na Javę coś, co działało na
C++ z COM-em. W takim, chociażby, przypadku, muszę przyznać, że owszem, COM
jest -delikatnie mówiąc- "nienajlepszą" technologią, ale lepszej o tym samym
zastosowaniu do C++ nie wymyślono, a do Javy tak. Problem polega zatem na tym,
że o ile do Javy opracowano mnóstwo narzędzi, bibliotek, technologii,
metodologii i innych różnych pierduł - co z tego, że co najmniej 60% to
bzdety, w końcu dzieła wybitne powstają przez rafinację badziewia - a C++
długo pod tym względem kulał i porównując z Javą niestety kuleje nadal.
Inaczej mówiąc, C++-owi brakuje głównie wszelkich aktywności okołojęzykowych i
jakiegoś sensownego marketingu. Jak to się dzieje, że nt. Javy jest tak dużo
tego typu aktywności, a jeśli chodzi o C++ to Stroustrup tylko raz na jakiś
czas ponarzeka, że ludzie nie publikują swoich sukcesów z C++?

Zresztą, jeśli oczywiście jakiś inny język/inna technologia z pewnych względów
jest lepsze, to dobrze, niech będzie stosowana. Jeśli C++ jest gorszy, to
niech się go nie stosuje. Ale to dla mnie w dalszym ciągu nie tłumaczy,
dlaczego tak wielu ludzi wykazuje się w stosunku do C++ wręcz nienawiścią. No
bo jak inaczej mam nazwać wypowiedzi, które życzą C++, aby jak najszybciej
zszedł ze sceny, "Goodbye C++", "- C++ jeszcze długo się będzie trzymał ;
- Eee tam nie bądźmy takimi pesymistami" i tak dalej?

Nie wiem, na ile ktoś czytuje np. grupę pl.comp.objects, ale raz na jakiś czas
ta grupa stawała się czymś w rodzaju "centrum nienawiści do C++". A wątki nt.
tego, jak to ludzie nie lubią C++ potrafią ciągnąć się długo i namiętnie. I to
jeszcze, żeby ktoś wskazywał na jego konkretne słabości i różne cechy, które
utrudniają jego stosowanie czy coś w tym sensie - ale gdzie tam. Większość
wypowiedzi to stanowcze stwierdzenia, że C++ to straszne badziewie. Kurde,
nie można pogadać np. o technologiach, które ludzie lubią, a C++ po
prostu olać?

Widzę w tym wszystkim po prostu wylewanie frustracji w związku z tym, że
"znowu w życiu komuś nie wyszło" z C++. Najwyraźniej Java stała się dla tych
sfrustrowanych jakimś wielkim ratunkiem i to nawet z depresji, chociaż biorąc
pod uwagę aktywność takich opinii, nie założyłbym się. Mimo swoich
właściwości, wciąż wychodzi na to, że C++ co najwyżej powoli zastępuje język
C [kolejność zdania normalna: podmiot-orzeczenie-dopełnienie! :)], a do
pisania dużych aplikacji - być może, bo jak mówię statystyk nie znam -
przestaje się go stosować. Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Czy dodanie odśmiecacza w nowym standardzie coś tu zmieni? Oczywiście, że nie
zmieni. I to nie dlatego, że wprowadzony zostanie tak późno, tylko dlatego, że
nikt nie opracuje technologii tworzenia aplikacji konkurencyjnych dla
istniejących i dobrze trzymających się rozwiązań (i to akurat wiem, bo jak
społeczność C++ cokolwiek w tym względzie zmieni pierwszy raz od 20 lat to mi
kaktus na dłoni wyrośnie). Dokładnie to samo dzieje się z Linuxem, który
"szanse na stanie się konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i
jakoś zdecydowanie za mało z tego korzysta.

Może to też kwestia tego, że C++ jest dla niektórych za trudny? Słyszę o tym
od dawna, ale jakoś nie chce mi się w to wierzyć. Kwestię arytmetyki
wskaźników to może olejmy, bo tego argumentu nie można traktować poważnie.
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
z***@wp.pl
2006-03-23 08:59:25 UTC
Permalink
Sektor, czy Ty nie masz większych zmartwień ?
Dyskusje na temat wyższości jednych języków programowania nad innymi są
zazwyczaj pozbawione sensu.
Po prostu stosuj zasadę "cel uświęca środki".

pzdr
w.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
JFS
2006-03-23 09:20:03 UTC
Permalink
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.
Przyznaję, nie dysponuję aktualnie żadnymi statystykami dotyczącymi użycia C++
w przemyśle i porównania z podobnymi statystykami dotyczącymi Javy. Jakiś czas
temu ktoś gdzieś (bodaj tu) rzucił statystykami, dotyczącymi tylko OpenSource,
które wskazywały, że C i C++ razem mają jakieś 60%, a Java ok 11%. Mówię z
pamięci. Po pierwsze, jednak, statystyki OpenSource nie są miarodajne dla
całego rynku, a po drugie, to było jakieś dwa lata temu i wiele mogło się
zmienić.
Co prawda widzę dość sporo dziedzin, w których Java raczej nie ma czego
szukać, ale już tu czytam jak to pewien osobnik obserwuje, jak firmy na gwałt
wycofują się z C++ i przechodzą na Javę. Co prawda trzeba to traktować z
drobnym przymrużeniem oka, ale myślę, że to nie jest uzasadnione.
Oczywiście jeśli C++ okaże się kiedyś narzędziem nie spełniającym wymagań dla
pisanego przez mnie oprogramowania i znajdą się lepsze, to zostawię C++ i nie
będę po nim płakał. Tak samo, jak olałem swego czasu Amigę, komputer, który w
czasach swej świetności bił na głowę PC pod każdym względem (w tym ceną), a
potem przez przez zatrzymanie się w rozwoju (i jakieś fatum, które powodowało,
że kolejno przejmujące ją firmy plajtowały) dała się PC przegonić. I też nie
było mi jej żal. Przestałem mówić dobrze o Amidze, kiedy słyszałem o super
karcie graficznej dla Amigi (jakby ktoś chciał Amigę stosować profesjonalnie;
ciekawe że podobno miały to założenie spełniać układy wbudowane), która
zawierała po prostu... układzik S3. Przy czym była trzykrotnie większa od
PC-owego odpowiednika i prawie dziesięciokrotnie droższa :)
Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych systemach
czasu rzeczywistego, nie wyobrażam sobie zastąpienia go czymkolwiek innym.
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo. A przynajmniej nie słyszałem o niczym powalającym. Miałem krótki
kontakt z projektem, w którym goście przepisywali na Javę coś, co działało na
C++ z COM-em. W takim, chociażby, przypadku, muszę przyznać, że owszem, COM
jest -delikatnie mówiąc- "nienajlepszą" technologią, ale lepszej o tym samym
zastosowaniu do C++ nie wymyślono, a do Javy tak. Problem polega zatem na tym,
że o ile do Javy opracowano mnóstwo narzędzi, bibliotek, technologii,
metodologii i innych różnych pierduł - co z tego, że co najmniej 60% to
bzdety, w końcu dzieła wybitne powstają przez rafinację badziewia - a C++
długo pod tym względem kulał i porównując z Javą niestety kuleje nadal.
Inaczej mówiąc, C++-owi brakuje głównie wszelkich aktywności okołojęzykowych i
jakiegoś sensownego marketingu. Jak to się dzieje, że nt. Javy jest tak dużo
tego typu aktywności, a jeśli chodzi o C++ to Stroustrup tylko raz na jakiś
czas ponarzeka, że ludzie nie publikują swoich sukcesów z C++?
Zresztą, jeśli oczywiście jakiś inny język/inna technologia z pewnych względów
jest lepsze, to dobrze, niech będzie stosowana. Jeśli C++ jest gorszy, to
niech się go nie stosuje. Ale to dla mnie w dalszym ciągu nie tłumaczy,
dlaczego tak wielu ludzi wykazuje się w stosunku do C++ wręcz nienawiścią. No
bo jak inaczej mam nazwać wypowiedzi, które życzą C++, aby jak najszybciej
zszedł ze sceny, "Goodbye C++", "- C++ jeszcze długo się będzie trzymał ;
- Eee tam nie bądźmy takimi pesymistami" i tak dalej?
Nie wiem, na ile ktoś czytuje np. grupę pl.comp.objects, ale raz na jakiś czas
ta grupa stawała się czymś w rodzaju "centrum nienawiści do C++". A wątki nt.
tego, jak to ludzie nie lubią C++ potrafią ciągnąć się długo i namiętnie. I to
jeszcze, żeby ktoś wskazywał na jego konkretne słabości i różne cechy, które
utrudniają jego stosowanie czy coś w tym sensie - ale gdzie tam. Większość
wypowiedzi to stanowcze stwierdzenia, że C++ to straszne badziewie. Kurde,
nie można pogadać np. o technologiach, które ludzie lubią, a C++ po
prostu olać?
Widzę w tym wszystkim po prostu wylewanie frustracji w związku z tym, że
"znowu w życiu komuś nie wyszło" z C++. Najwyraźniej Java stała się dla tych
sfrustrowanych jakimś wielkim ratunkiem i to nawet z depresji, chociaż biorąc
pod uwagę aktywność takich opinii, nie założyłbym się. Mimo swoich
właściwości, wciąż wychodzi na to, że C++ co najwyżej powoli zastępuje język
C [kolejność zdania normalna: podmiot-orzeczenie-dopełnienie! :)], a do
pisania dużych aplikacji - być może, bo jak mówię statystyk nie znam -
przestaje się go stosować. Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Czy dodanie odśmiecacza w nowym standardzie coś tu zmieni? Oczywiście, że nie
zmieni. I to nie dlatego, że wprowadzony zostanie tak późno, tylko dlatego, że
nikt nie opracuje technologii tworzenia aplikacji konkurencyjnych dla
istniejących i dobrze trzymających się rozwiązań (i to akurat wiem, bo jak
społeczność C++ cokolwiek w tym względzie zmieni pierwszy raz od 20 lat to mi
kaktus na dłoni wyrośnie). Dokładnie to samo dzieje się z Linuxem, który
"szanse na stanie się konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i
jakoś zdecydowanie za mało z tego korzysta.
Może to też kwestia tego, że C++ jest dla niektórych za trudny? Słyszę o tym
od dawna, ale jakoś nie chce mi się w to wierzyć. Kwestię arytmetyki
wskaźników to może olejmy, bo tego argumentu nie można traktować poważnie.
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują - na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
Druga rzecz - kiepskie biblioteki gdyby bylo mnóstwo eleganckich
pakietów/bibliotek w których moznaby przebierac jak w cukierkach
byłoby zupełnie inaczej. Moim zdaniem jednak nalezaloby c++
poprawic, zachowac sedno szybkości, skupić się na szybkości.



jFS
Post by Sektor van Skijlen
--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Tomasz Kaczanowski
2006-03-23 09:36:32 UTC
Permalink
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują
Może dyskwalifikują to za dużo powiedziane, ale fakt ma troche wad (w
sumie co nie ma wad? :))
Post by JFS
- na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
Właśnie to mi się podoba... Pliki nagłówkowe to moim zdaniem bardzo
dobry wynalazek. Dzięki temu nie musisz wnikać co jest w binariach,
dostajesz api i z niego korzystasz.
--
Kaczus/Pegasos User
http://kaczus.republika.pl
JFS
2006-03-23 09:50:21 UTC
Permalink
Post by Tomasz Kaczanowski
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują
Może dyskwalifikują to za dużo powiedziane, ale fakt ma troche wad (w
sumie co nie ma wad? :))
Post by JFS
- na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
Właśnie to mi się podoba... Pliki nagłówkowe to moim zdaniem bardzo
dobry wynalazek. Dzięki temu nie musisz wnikać co jest w binariach,
dostajesz api i z niego korzystasz.
Rownie dobrze moglbys miec kolorowego helpa w htmlu :)
Nie dosc ze plik naglowkowy importujesz z obcej biblioteki (co jeszcze
ma wiekszy sens) to w praktyce tworzysz np 50 plikow naglowkowych
do 50 swoich plikow cpp, musisz dbac o ich poprawnosc, nie
zapominac o wklejaniu deklaracji itp zbedna robota.

JFS :)
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
sg
2006-03-23 11:05:55 UTC
Permalink
Post by JFS
Post by Tomasz Kaczanowski
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują
Może dyskwalifikują to za dużo powiedziane, ale fakt ma troche wad (w
sumie co nie ma wad? :))
Post by JFS
- na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
Właśnie to mi się podoba... Pliki nagłówkowe to moim zdaniem bardzo
dobry wynalazek. Dzięki temu nie musisz wnikać co jest w binariach,
dostajesz api i z niego korzystasz.
Rownie dobrze moglbys miec kolorowego helpa w htmlu :)
Nie dosc ze plik naglowkowy importujesz z obcej biblioteki (co jeszcze
ma wiekszy sens) to w praktyce tworzysz np 50 plikow naglowkowych
do 50 swoich plikow cpp, musisz dbac o ich poprawnosc, nie
zapominac o wklejaniu deklaracji itp zbedna robota.
JFS :)
jasne, a pracowałeś na czymś co ma więcej niż dwie klasy ? Wyobraź sobie
program, który 1000klas, pliki nagłówkowe dają tę możliwość, że bez
problemu można zobaczyć deklaracje bez przeglądania implementacji.
A z drugiej strony to ja proponuję pójść dalej, po co pisać całą klasę w
jednym pliku ? Piszmy cały program w jednym pliku, takie 1000klas w
jednym pliku i będzie lepiej, bo inaczej to się nazywa, że język
programowania ma wadę ;-)
JFS
2006-03-23 11:55:42 UTC
Permalink
Post by sg
Post by JFS
Post by Tomasz Kaczanowski
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują
Może dyskwalifikują to za dużo powiedziane, ale fakt ma troche wad (w
sumie co nie ma wad? :))
Post by JFS
- na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
Właśnie to mi się podoba... Pliki nagłówkowe to moim zdaniem bardzo
dobry wynalazek. Dzięki temu nie musisz wnikać co jest w binariach,
dostajesz api i z niego korzystasz.
Rownie dobrze moglbys miec kolorowego helpa w htmlu :)
Nie dosc ze plik naglowkowy importujesz z obcej biblioteki (co jeszcze
ma wiekszy sens) to w praktyce tworzysz np 50 plikow naglowkowych
do 50 swoich plikow cpp, musisz dbac o ich poprawnosc, nie
zapominac o wklejaniu deklaracji itp zbedna robota.
JFS :)
jasne, a pracowałeś na czymś co ma więcej niż dwie klasy ? Wyobraź sobie
program, który 1000klas, pliki nagłówkowe dają tę możliwość, że bez
problemu można zobaczyć deklaracje bez przeglądania implementacji.
A z drugiej strony to ja proponuję pójść dalej, po co pisać całą klasę w
jednym pliku ? Piszmy cały program w jednym pliku, takie 1000klas w
jednym pliku i będzie lepiej, bo inaczej to się nazywa, że język
programowania ma wadę ;-)
Pracuje przy chyba dosyc typowej aplikacji mfcowej - mam tu okolo 140 klas
140 plikow cpp + 140 zbednych moim zdaniem plikow h

JFS
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Krzysztof Rudnik
2006-03-24 06:43:53 UTC
Permalink
Post by JFS
Pracuje przy chyba dosyc typowej aplikacji mfcowej - mam tu okolo 140 klas
140 plikow cpp + 140 zbednych moim zdaniem plikow h
Czesciowo zgodze sie z twierdzeniem ze pliki .h to dodatkowy klopot
dla programisty, w sumie moglyby byc generowane automatycznie -
jakis parser bierze plik .c i naglowki wszystkiego co nie jest
static umieszcza w .h. Wiecej watpliwosci jest z klasami C++,
definicje klasy i tak trzeba napisac 'recznie'. Moznaby wtedy
jednak stworzyc inna definicje 'na zewnetrz' a inna 'do uzytku
wewnetrznego'. Mianowicie mozna by pokusic sie o nieumieszczanie
w definicji publicznej informacji o polach prywatnych klasy, a
jedynie (tutaj potrzebne byloby jakies rozszerzenie skladni)
zaznaczenie ze jest np. 120 bajtow danych prywatnych.
--
Krzysiek Rudnik
Maciej Sobczak
2006-03-24 07:10:02 UTC
Permalink
Post by Krzysztof Rudnik
Czesciowo zgodze sie z twierdzeniem ze pliki .h to dodatkowy klopot
dla programisty, w sumie moglyby byc generowane automatycznie -
jakis parser
Zgadza się - "jakiś parser". Jeżeli faktycznie pracujesz w ten sposób,
że najpierw piszesz implementację czegoś a dopiero później deklaracje,
to bez żadnego problemu możesz posłużyć się "jakimś parserem" do
zautomatyzowania części albo całości tego procesu. Ale to jest problem
zewnętrzny w stosunku do języka i dotyczący tylko narzędzi edycyjnych. I
wiem, że takie narzędzia istnieją, przynajmniej dla C.

Natomiast ciekawi mnie, jak to sobie wyobrażasz w przypadku klas.
Najpierw piszesz .cpp a potem .h?

Ogólnie problem jest właśnie w kolejności. Niektórzy ludzie *najpierw*
piszą .h a dopiero później (albo nawet nigdy) .cpp. Wtedy nie ma sensu
mówić o automatycznym generowaniu czegokolwiek.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Seweryn Habdank-Wojewódzki
2006-03-24 20:23:35 UTC
Permalink
Witam
Post by Krzysztof Rudnik
Czesciowo zgodze sie z twierdzeniem ze pliki .h to dodatkowy klopot
dla programisty, w sumie moglyby byc generowane automatycznie -
jakis parser bierze plik .c i naglowki wszystkiego co nie jest
static umieszcza w .h. Wiecej watpliwosci jest z klasami C++,
definicje klasy i tak trzeba napisac 'recznie'.
Nie wiem czy dobrze zrozumiałem, ale co z szablonami. Obejrzyj proszę
boost::type_traits, albo boost::mpl. I powiedz mi z jakich plików cpp parsery
maja odbudować szabloniki do plików hpp?

Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
`\/\/
Sektor van Skijlen
2006-03-23 12:19:50 UTC
Permalink
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują - na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
To jest dobry argument. Zastanawiała mnie właśnie ta kwestia, dlaczego w C++
mówi się, że bardzo złą praktyką jest umieszczanie kodu wszystkich metod
wewnątrz klasy (pomińmy kwestię inline w tym przypadku, bo to wciąż sprawa
kompilatora), a w Javie jakoś innej możliwości nie ma i nikt nie narzeka?

Możliwość wciągania plików nagłówkowych musi pozostać, żeby łatwiej się
operowało bibliotekami języka C, ale z drugiej strony specjalnie dla C++
mógłby istnieć inny mechanizm.
Post by JFS
Druga rzecz - kiepskie biblioteki gdyby bylo mnóstwo eleganckich
pakietów/bibliotek w których moznaby przebierac jak w cukierkach
byłoby zupełnie inaczej.
Które biblioteki są kiepskie? Biblioteki do czego?
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Paweł Kierski
2006-03-23 13:41:43 UTC
Permalink
Post by Sektor van Skijlen
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują - na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
To jest dobry argument. Zastanawiała mnie właśnie ta kwestia, dlaczego w C++
mówi się, że bardzo złą praktyką jest umieszczanie kodu wszystkich metod
wewnątrz klasy (pomińmy kwestię inline w tym przypadku, bo to wciąż sprawa
kompilatora), a w Javie jakoś innej możliwości nie ma i nikt nie narzeka?
Bo jest javadoc? 8-) Nagłówki i tak trzeba skomentować, żeby opisać
szczegóły interfejsu - w Javie więcej chyba może wynikać z samego
kodu, ale też nie wszystko. A przy dużym projekcie przeglądanie 100
plików nagłówkowych, czy 100 plików z kodem, czy 100 plików
nagłówkowych i 100 plików implementacji to i tak męka. Lepiej
skomentować i wygenerować dokumentację, która w obydwu przypadkach
będzie właściwie identyczna. Dlatego argument o nagłówkach jest raczej
słaby - owszem, czasem się może przydać, ale bez przesady.
Aha - w Javie, choć będzie to dziwnie wyglądało, można od biedy
pisać:

class Klasa
{
// część "robiąca za nagłówek"
public void metodaPubliczna1(int i) {metodaPubliczna1_impl(i);}
public void metodaPubliczna2(int i) {metodaPubliczna2_impl(i);}

// część implementacyjna
private final void metodaPubliczna1_impl(int i) { /* ... */ }
private final void metodaPubliczna2_impl(int i) { /* ... */ }
}

albo - lepiej - konsekwentnie używać interfejsów.
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Maciej Sobczak
2006-03-23 15:44:35 UTC
Permalink
Post by Paweł Kierski
Aha - w Javie, choć będzie to dziwnie wyglądało, można od biedy
class Klasa
{
// część "robiąca za nagłówek"
public void metodaPubliczna1(int i) {metodaPubliczna1_impl(i);}
public void metodaPubliczna2(int i) {metodaPubliczna2_impl(i);}
// część implementacyjna
private final void metodaPubliczna1_impl(int i) { /* ... */ }
private final void metodaPubliczna2_impl(int i) { /* ... */ }
}
Raczej odwrotnie z tym final - to część publiczna powinna być niewirtualna.
Post by Paweł Kierski
albo - lepiej - konsekwentnie używać interfejsów.
Nie lepiej, bo nie można w czymś takim zawrzeć kontraktów.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sektor van Skijlen
2006-03-23 17:30:37 UTC
Permalink
Post by Paweł Kierski
Post by Sektor van Skijlen
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują - na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
To jest dobry argument. Zastanawiała mnie właśnie ta kwestia, dlaczego w C++
mówi się, że bardzo złą praktyką jest umieszczanie kodu wszystkich metod
wewnątrz klasy (pomińmy kwestię inline w tym przypadku, bo to wciąż sprawa
kompilatora), a w Javie jakoś innej możliwości nie ma i nikt nie narzeka?
Bo jest javadoc? 8-)
A dla C++ jest doxygen. Ostatnio generowałem sobie próbnie dokumentację do
takiego badziewnego projektu. Razem z diagramami z dot-a (z graphviz).
Dosłownie szczęka mi opadła.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Krzysztof Rudnik
2006-03-24 06:48:20 UTC
Permalink
Post by Sektor van Skijlen
A dla C++ jest doxygen. Ostatnio generowałem sobie próbnie dokumentację do
takiego badziewnego projektu. Razem z diagramami z dot-a (z graphviz).
Dosłownie szczęka mi opadła.
Ale javadoc jest niemal elementem jezyka, a doxygen to niezalezne narzedzie,
dosc uniwersalne zreszta. Jakby go zawrzec w kompilatorze, tak by doxygenowe
bledy byly tez bledami kompilacji... No ale komentarze sa zwykle w jezyku
naturalnym, nie dla wszystkich zrozumialym.
--
Krzysiek Rudnik
Sektor van Skijlen
2006-03-24 08:25:40 UTC
Permalink
Post by Krzysztof Rudnik
Post by Sektor van Skijlen
A dla C++ jest doxygen. Ostatnio generowałem sobie próbnie dokumentację do
takiego badziewnego projektu. Razem z diagramami z dot-a (z graphviz).
Dosłownie szczęka mi opadła.
Ale javadoc jest niemal elementem jezyka,
Niby dlaczego? Dlatego, że reguły składni tej dokumentacji są zawarte w opisie
języka?

Bo wybacz, ale naprawdę nie widzę żadnej różnicy w tej materii pomiędzy
javadocem a doxygenem. Różnica jest tylko co najwyżej taka, że javadoc nie
potrafi pracować z C++, a doxygen potrafi pracować z Javą.
Post by Krzysztof Rudnik
a doxygen to niezalezne narzedzie,
dosc uniwersalne zreszta. Jakby go zawrzec w kompilatorze, tak by doxygenowe
bledy byly tez bledami kompilacji... No ale komentarze sa zwykle w jezyku
naturalnym, nie dla wszystkich zrozumialym.
A jakież to błędy kompilacji powoduje błąd w komentarzach dokumentacyjnych?

Oczywiście, że doxygen potrafi zgłaszać błędy.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
jfs
2006-03-23 14:44:25 UTC
Permalink
Post by Sektor van Skijlen
Post by JFS
C++ nie jest za dobry, ma kilka horrendalnych wad które
myślę - jeśli spojrzeć ze współczesnego punktu widzenia -
go dyskwalifikują - na przykład ten podział na pliki nagłówkowe
i zrodła - w javie nie ma plikow naglowkowych i jest ok.
To jest dobry argument. Zastanawiała mnie właśnie ta kwestia, dlaczego w C++
mówi się, że bardzo złą praktyką jest umieszczanie kodu wszystkich metod
wewnątrz klasy (pomińmy kwestię inline w tym przypadku, bo to wciąż sprawa
kompilatora), a w Javie jakoś innej możliwości nie ma i nikt nie narzeka?
Możliwość wciągania plików nagłówkowych musi pozostać, żeby łatwiej się
operowało bibliotekami języka C, ale z drugiej strony specjalnie dla C++
mógłby istnieć inny mechanizm.
Post by JFS
Druga rzecz - kiepskie biblioteki gdyby bylo mnóstwo eleganckich
pakietów/bibliotek w których moznaby przebierac jak w cukierkach
byłoby zupełnie inaczej.
Które biblioteki są kiepskie? Biblioteki do czego?
Sorry zle sie wyrazilem pisząc "kiepskie biblioteki"
Mialem na mysli za mala biblioteka okolostandardową
pobiezne porownanie tego co jest z (pobiezną znajomoscia tego
co jest "standardem" w javie) wydaje mi sie wychodzic
na niekorzysc c++ (ale nie znam sie zbytnio ani na bibliotekach c++
ani na bibliotekach javy - wiec moze nie mam
racji)

jfs
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
SirMike
2006-03-23 09:40:43 UTC
Permalink
No to pojechales teraz - przeczytałem nawet do końca ;)
Osobiście uważam C++ za język, który ma się dobrze i przy pomocy
odpowiednich bibliotek można osiągnąć to samo co w Javie czy C#. Ba,
nawet będzie przenośne. Jednak prawda jest okrutna. Szybkość tworzenia
aplikacji w tych językach różni się dość znacznie. Gdy mam napisać na
szybko jakiegoś tool'a to wiadomo, że wybiorę Jave czy C# (choćby
dlatego, że mają świetne wsparcie dla XML'a). W okrutnych czasach gdzie
rządzi komercja wygrywają środowiska, które pozwolą wytworzenie programu
w jak najkrótszym czasie - a takimi niewątpliwie są Java i C#.
Podsumowując, powinniśmy wybrać ten język, w którym dany problem będzie
nam rozwiązać jak najłatwiej (i ten który znamy doskonale) a nie podążać
za głupią modą.
--
SirMike - http://www.sirmike.org

C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg. - Bjarne Stroustrup
z***@wp.pl
2006-03-23 09:58:33 UTC
Permalink
Post by SirMike
Podsumowując, powinniśmy wybrać ten język, w którym dany problem będzie
nam rozwiązać jak najłatwiej (i ten który znamy doskonale) a nie podążać
za głupią modą.
I to zdanie powinno raz na zawsze urwać wszelkie głupie spory na temat
wyższości jednych języków nad drugimi.
Sektor, przepisz to 100 razy do zeszytu :)

pzdr
w.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
SirMike
2006-03-23 09:42:48 UTC
Permalink
No to pojechales teraz - przeczytałem nawet do końca ;)
Osobiście uważam C++ za język, który ma się dobrze i przy pomocy
odpowiednich bibliotek można osiągnąć to samo co w Javie czy C#. Ba,
nawet będzie przenośne. Jednak prawda jest okrutna. Szybkość tworzenia
aplikacji w tych językach różni się dość znacznie. Gdy mam napisać na
szybko jakiegoś tool'a to wiadomo, że wybiorę Jave czy C# (choćby
dlatego, że mają świetne wsparcie dla XML'a). Gdyby chociaż takie cuda
jak boost były w standardzie... W C++ bez zewnętrznych bibliotek jest
ciężko.
W okrutnych czasach gdzie rządzi komercja wygrywają środowiska, które
pozwolą wytworzenie programu w jak najkrótszym czasie - a takimi
niewątpliwie są Java i C#.
Podsumowując, powinniśmy wybrać ten język, w którym dany problem będzie
nam rozwiązać jak najłatwiej (i ten który znamy doskonale) a nie podążać
za głupią modą.
--
SirMike - http://www.sirmike.org

C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg. - Bjarne Stroustrup
Paweł Kierski
2006-03-23 11:11:51 UTC
Permalink
SirMike w wiadomości <dvtqj4$h45$***@atlantis.news.tpi.pl> pisze:
[...]
Post by SirMike
W okrutnych czasach gdzie rządzi komercja wygrywają środowiska, które
pozwolą wytworzenie programu w jak najkrótszym czasie
[...]

Uzupełnię - ... z założoną minimalną wydajnością _oraz_ jakością.
C++ umożliwia większe panowania nad wydajnością, kosztem większych
nakładów na jakość.
Jak zwykle - narzędzie jest (a przynajmniej powinno być) wtórne do
projektu.
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
SirMike
2006-03-23 13:04:25 UTC
Permalink
Post by Paweł Kierski
Uzupełnię - ... z założoną minimalną wydajnością _oraz_ jakością.
C++ umożliwia większe panowania nad wydajnością, kosztem większych
nakładów na jakość.
Tak jest. Jeśli program ma być dopieszczony i szybki a czas i koszty nie
grają roli to wybieram C++. Jeśli ma być dopracowany ale "na wczoraj" to
wybieram Jave / C# :)
--
SirMike - http://www.sirmike.org

C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg. - Bjarne Stroustrup
mike
2006-03-23 22:39:27 UTC
Permalink
Post by SirMike
Tak jest. Jeśli program ma być dopieszczony i szybki a czas i koszty nie
grają roli to wybieram C++. Jeśli ma być dopracowany ale "na wczoraj" to
wybieram Jave / C# :)
W obecnych realiach to "na wczoraj" :)

Pozdrawiam
Bronek Kozicki
2006-03-23 10:08:13 UTC
Permalink
Post by Sektor van Skijlen
Inaczej mówiąc, C++-owi
brakuje głównie wszelkich aktywności okołojęzykowych i jakiegoś
sensownego marketingu. Jak to się dzieje, że nt. Javy jest tak dużo
tego typu aktywności,
za Java stoją firmy (a przynajmniej jedna), które co roku wydają miliony
dolarów na promocję oraz R&D. Pomadto Java jest prostsza, a więc łatwiej
w niej napisać całą "otoczkę".


B.
Marcin Gabryszewski
2006-03-23 10:12:16 UTC
Permalink
Sektor van Skijlen napisał(a):
< bardzo, ale to bardzo duży ciach>

O rzesz w mordkę jeża, Sektor, aż oczy mi się zmęczyły :)
Teraz do rzeczy

1) raczej c++ nie pójdzie w zapomnienie, jakoś drivery w javie mi się
nie widzą.

2) ciągle c/c++ jest najszybszym z wysokopoziomowych języków, a
kompilator z vc8 wymiata. Robiłem ostatnio pewien test szybkości
algorytmów szyfrujących, kompilacja full speed na vc7 i vc8. vc8 wyszedł
ponad 30% szybszy.

3) zżera najmniej zasobów, a tam trzeba odpalić javę, tam frameworka, a
tu już jest "natywny" kod

Ja w ogóle źle zaczołem od javy, bo była to wstrętna ms java z pakietu
vs6, to była masakra i do tej pory mam obrzydzenie.

Następny minus javy to rzekoma przenośność, kurde tyle tego naklepali i
jedno niezgodne z drugim. Jeżeli chodzi o javę me to już totalna
porażka, zero przenośności, pisze się dokładnie pod np. daną komórkę.
Zaś czysty c++ jest przenośny.

Już większe zagrożenie widzę w .net'cie, jak jeszcze dopracują mono to
już faktyczne będzie mocna konkurencja.

Tylko .net ma jeden wielki MINUS i to trochę c++ ratuje. w .net'cie
można przeprowadzić pełen reversing do żródeł, nawet obrzydzacze nie za
bardzo pomagają. To zabija komerchę. Można powiedzieć że programy .net
to opensource :)
--
Marcin Gabryszewski
G DATA Software
www.gdata.pl

address:[FirstName][SurnameFirstLetter]@gdata.pl
Bronek Kozicki
2006-03-23 10:17:30 UTC
Permalink
Post by Marcin Gabryszewski
Tylko .net ma jeden wielki MINUS i to trochę c++ ratuje. w .net'cie
można przeprowadzić pełen reversing do żródeł, nawet obrzydzacze nie
za bardzo pomagają.
e, reverse-engineering można też babrać się na asm, jeżeli ktoś tego
potrzebuje. Większym problemem .NET jest zajętość pamięci aplikacji w
nim napisanych.


B.
Paweł Kierski
2006-03-23 11:18:27 UTC
Permalink
Post by Bronek Kozicki
Post by Marcin Gabryszewski
Tylko .net ma jeden wielki MINUS i to trochę c++ ratuje. w .net'cie
można przeprowadzić pełen reversing do żródeł, nawet obrzydzacze nie
za bardzo pomagają.
e, reverse-engineering można też babrać się na asm, jeżeli ktoś tego
potrzebuje.
Ale złożoność (czyli koszt) tak z rząd wielkości większy, a i wyniki
gorsze. Zdarzało mi się analizować releasową wersję _własnego_ kodu
wyprodukowanego przez kompilator - jak zobaczyłem zoptymalizowane
mnożenie realizowane za pomocą kombinacji lea/add/sub/shl to
podziękowałem 8-)
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Moneetor
2006-03-24 23:42:00 UTC
Permalink
Post by Paweł Kierski
Post by Bronek Kozicki
Post by Marcin Gabryszewski
Tylko .net ma jeden wielki MINUS i to trochę c++ ratuje. w .net'cie
można przeprowadzić pełen reversing do żródeł, nawet obrzydzacze nie
za bardzo pomagają.
e, reverse-engineering można też babrać się na asm, jeżeli ktoś tego
potrzebuje.
Ale złożoność (czyli koszt) tak z rząd wielkości większy, a i wyniki
gorsze. Zdarzało mi się analizować releasową wersję _własnego_ kodu
wyprodukowanego przez kompilator - jak zobaczyłem zoptymalizowane
mnożenie realizowane za pomocą kombinacji lea/add/sub/shl to
podziękowałem 8-)
Heh Kiepski kompilator nie oznacza kiepskiego środowiska. Ale ja .net'a
nie używałem. C++ jest do wszystkiego ;)
--
I love SPAM(TM)...
...but hate spammers!!!
Marcin Gabryszewski
2006-03-23 13:02:02 UTC
Permalink
Post by Bronek Kozicki
Post by Marcin Gabryszewski
Tylko .net ma jeden wielki MINUS i to trochę c++ ratuje. w .net'cie
można przeprowadzić pełen reversing do żródeł, nawet obrzydzacze nie
za bardzo pomagają.
e, reverse-engineering można też babrać się na asm, jeżeli ktoś tego
potrzebuje. Większym problemem .NET jest zajętość pamięci aplikacji w
nim napisanych.
A słyszałeś o trapach na rożnego rodzaju debugery, rewersery itd.
Do c++ bardzo prosto wmieszasz kod asm i już nie masz źródeł, nawet w
formie asm. Takie pułapki są bardzo proste a już windasm czy procdump
tego nie wezmą, a olydbg się całkowicie wykrzaczy. Dodać do tego ochronę
przed si i crc odpalonego procesu i obejście tych pułapek zajmie tyle
czasu a uzyskany kod może być tak nieczytelny że się to nie opłaca.
Swojego czasu zajmowałem się cracksceną i crackmesami i wiem że program
w c++ można naprawdę dobrze zabezpieczyć przez dostępem do źródełek.
--
Marcin Gabryszewski
G DATA Software
www.gdata.pl

address:[FirstName][SurnameFirstLetter]@gdata.pl
jfs
2006-03-23 10:57:35 UTC
Permalink
Jesli o mnie chodzi to kiedys sformulowalem sobie taka mysl - mnie
specjalnie jezyki programowania nie interesują (i to uważam za jak
najbardziej dobry stan) jezyk powinien byc przezroczysty aby nie
zawracac sobie nim glowy - jezyk to w pewnym sensie bzdura - wazne jest
to co się pisze - algorytmi inteligencji dla ludzikow w quejku, nie wiem
co - w abstrakcji od jezyka, na wskroś niego - dlatego
juz wolalbym C niz c++ bo jest bardziej przezroczysty i mozna by pogadac
o ciekawych rzeczach apart of jezyk programowania i jego niedostatki.

JFS
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
jfs
2006-03-23 10:59:16 UTC
Permalink
Post by jfs
Jesli o mnie chodzi to kiedys sformulowalem sobie taka mysl - mnie
specjalnie jezyki programowania nie interesują (i to uważam za jak
najbardziej dobry stan) jezyk powinien byc przezroczysty aby nie
zawracac sobie nim glowy - jezyk to w pewnym sensie bzdura - wazne jest
to co się pisze - algorytmi inteligencji dla ludzikow w quejku, nie wiem
co - w abstrakcji od jezyka, na wskroś niego - dlatego
juz wolalbym C niz c++ bo jest bardziej przezroczysty i mozna by pogadac
o ciekawych rzeczach apart of jezyk programowania i jego niedostatki.
JFS
nie mam jednak czasu pogadac bo mnie jeszcze wyleja z roboty
(a jest ciekawa). :) pzdr

JFS
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
tomek
2006-03-23 12:06:59 UTC
Permalink
Post by jfs
Jesli o mnie chodzi to kiedys sformulowalem sobie taka mysl - mnie
specjalnie jezyki programowania nie interesują (i to uważam za jak
najbardziej dobry stan) jezyk powinien byc przezroczysty aby nie
zawracac sobie nim glowy - jezyk to w pewnym sensie bzdura - wazne jest
to co się pisze - algorytmi inteligencji dla ludzikow w quejku, nie wiem
co - w abstrakcji od jezyka, na wskroś niego - dlatego
juz wolalbym C niz c++ bo jest bardziej przezroczysty i mozna by pogadac
o ciekawych rzeczach apart of jezyk programowania i jego niedostatki.
JFS
ale o co ci chodzi?
redwhite
2006-03-23 13:53:32 UTC
Permalink
tomek wposcił taką oto wiadomość
Post by tomek
Post by jfs
Jesli o mnie chodzi to kiedys sformulowalem sobie taka mysl - mnie
specjalnie jezyki programowania nie interesują (i to uważam za jak
najbardziej dobry stan) jezyk powinien byc przezroczysty aby nie zawracac
sobie nim glowy - jezyk to w pewnym sensie bzdura - wazne jest
to co się pisze - algorytmi inteligencji dla ludzikow w quejku, nie wiem
co - w abstrakcji od jezyka, na wskroś niego - dlatego
juz wolalbym C niz c++ bo jest bardziej przezroczysty i mozna by pogadac
o ciekawych rzeczach apart of jezyk programowania i jego niedostatki.
JFS
ale o co ci chodzi?
przeczytaj jeszcze raz while(1)
--
REDWHITE'S
http://gfm.sytes.net/
Maciej Sobczak
2006-03-23 11:05:53 UTC
Permalink
Hehe - pojechałeś z nutką nostalgiczną, więc też odpiszę "z głebi duszy". :)
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać.
Spada, bo się sesja skończyła i ludzie już pooddawali swoje prace domowe. :p

A teraz na temat: C++ jest najbardziej *użytecznym* językiem
programowania i to zabezpiecza jego szczęśliwy byt na długie lata w
przód. Nie jest idealny w sensie teorii projektowania języków, ale
języki idealne (kupa tego na uczelniach) są używane tylko przez ich twórców.

Popatrzmy na konkurencję.

1. Java w ogóle nie nadaje się do programowania czegokolwiek. Z mojego
punktu siedzenia dwa podstawowe powody to:
- Brak oddzielenia specyfikacji od implementacji (czyli po ludzku: brak
odpowiednika plików nagłówkowych - wiem, wiem, niektórym się wydaje, że
takie rozdzielenie to główna wada C++, ale nie dość, że to jest zaleta,
to w dodatku jest to konieczność w większych projektach i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to za
mało. W wersji dla ubogich potrzebne jest coś, co ma np. Ada w postaci
słów kluczowych type i subtype, w wersji rozbudowanej potrzebne jest
przeciążanie operatorów i wykorzystanie zewnętrznych opisów dziedzin i
generatorów typów albo wbudowanego metajęzyka do opisu dziedzin. W
porządnych językach to się robi naturalnie, w Javie nie da się tego
zrobić wcale a bez tego nie ma sensu mówić o inżynierii programowania.
- Brak deterministycznej destrukcji. Finally jest do bani.

Statystycznie, okres "hurraaaa!" na Javę chyba się kończy i nowe
projekty w Javie nie są już tak radośnie otwierane, jak to było swego
czasu. Być może właśnie dlatego, że ludzie zaczynają sobie uświadamiać
braki tego języka. Polecam posty Jamesa Kanze na comp.lang.c++.moderated
na ten temat - to jest gość, który ma w tym biznesie większe
doświadczenie, niż my wszyscy razem i jego komentarze w tym temacie są
dość ciekawe.

2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję. To jest język na jedną tylko
platformę tak samo jak swego czasu był nim VB i będzie istniał tylko tak
długo, jak długo M$ będzie widział w tym swój biznesowy cel. Nie jest to
platforma, którą możnaby wziąć pod uwagę planując jakiś większy projekt.
Co innego aplikacje desktopowe na Windowsa - i faktycznie,
najprawdopodobniej C# zdominuje ten segment rynku (co nie znaczy, że się
w tym segmencie cokolwiek poprawi).

3. Języki skryptowe nie są konkurencją dla C++. Po prostu - służą do
czego innego.
(No i należy pamiętać, że języki skryptowe dzielą się na Tcl i resztę,
ale my się tutaj tym nie zajmujemy. ;) )

4. Języki funkcjonalne używa Qrczak. ;)
I jeszcze paru gości, którzy (słusznie) uważają, że warto je znać dla
poszerzenia swojego warsztatu, ale dla których i tak głównym nurtem jest
coś innego.


W sensie przenośności, stopnia ustandaryzowania i docelowego segmentu
rynku, bezpośrednim konkurentem dla C++ jest Ada, której z jakiegoś
powodu poza paroma mądralami od inżynierii oprogramowania nikt nie
używa. Tym "jakimś powodem" jest np. to, że nikt jej nie zna, więc nie
ma komu zaczynać nowych projektów, więc... itd. - to jest
samonapędzający się mechanizm.

I właśnie ten sam samonapędzający się mechanizm, który dawno temu
wystartował od języka C zarówno na Uniksach jak i na Windowsie, jest
przyczyną tego, że C++ jest dzisiaj najbardziej użyteczny. Niezależnie
od swoich wad.
Post by Sektor van Skijlen
Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych systemach
czasu rzeczywistego, nie wyobrażam sobie zastąpienia go czymkolwiek innym.
Ada. Ale trzeba wziąć pod uwagę ten samonapędzający się mechanizm.
Wyobraź sobie, że wpadam na pomysł, aby "krytyczny, wbudowany system
czasu rzeczywistego" zrobić w Adzie. System jest całkowicie odizolowany
koncepcyjnie od reszty świata, więc nie ma problemu np. z dostępnością
bibliotek do pierduł w rodzaju XML albo innego filtrowania maili -
potrzebny jest tylko interfejs do systemu operacyjnego a to jest zawsze.
Pomysł może i dobry, ale niemożliwy do zrealizowania przez brak ludzi.
Nikt nie zna Ady, bo nikt się jej nie uczył, bo nikt nie widział takiej
potrzeby, bo nie ma projektów w Adzie, więc nie ma pracy w Adzie. I z
powodu braku ludzi dzisiaj ten projekt też nie będzie w Adzie. Kółko. A
ponieważ dzisiaj żaden projekt nie jest pisany w Adzie, to nie ma ofert
pracy, więc nikomu nie chce się jej uczyć, więc nikt nie będzie jej
umiał, więc nie będzie z kim robić projektów w Adzie jutro. Znowu kółko.
Itd.
Ten mechanizm dotyczy każdego języka, który w danej dziedzinie mógłby
zostać uznany za "lepszy" od C++. Wszystkie takie języki skupiają się w
lokalnych grupach programistycznych, które w odizolowaniu od reszty
świata piszą sobie kolejne wersje czegoś tam, ale w miarę naturalnego
odchodzenia ludzi z projektu, takie lokalne grupy programistyczne po
prostu wymierają.
W użyciu pozostają tylko te technologie, dla których ten samonapędzający
się mechanizm ustabilizował się na pewnym niezerowym poziomie (są
ludzie, książki, biblioteki do wykorzystania, istniejący kod do
poprawiania, itd.).
Post by Sektor van Skijlen
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo.
Trochę bardzo. CORBA jest standardem w tej dziedzinie. I to do tego
stopnia, że większość ludzi nawet nie zdaje sobie sprawy z tego, w ilu
miejscach jest obecna. Piszę ten post komputerze ze środowiskiem GNOME.
Wszystko co robię to jakiś komunikat CORBA, bo CORBA jest podstawą GNOME
tak samo, jak COM jest (był?) podstawą Windowsa. Wiedziałeś o tym? :)
Każdy poważniejszy rozproszony system jest oparty o CORBA. Nawet goście
od Ady powszechnie olali tą część języka, która jest odpowiedzialna za
systemy rozproszone (tak, mają to jako część standardu!) i używają CORBA
bez żadnego żalu.

I to działa.
Post by Sektor van Skijlen
A przynajmniej nie słyszałem o niczym powalającym.
CORBA nie powala. CORBA działa. :)
Post by Sektor van Skijlen
Miałem krótki
kontakt z projektem, w którym goście przepisywali na Javę coś, co działało na
C++ z COM-em. W takim, chociażby, przypadku, muszę przyznać, że owszem, COM
jest -delikatnie mówiąc- "nienajlepszą" technologią, ale lepszej o tym samym
zastosowaniu do C++ nie wymyślono, a do Javy tak.
Ale wiesz o tym, że J2EE to taka przemalowana CORBA?
Nawet protokół na niskim poziomie to IIOP. Zdaje się, że można nawet
komunikować się z tymi ichnimi fasolkami używając normalnych interfejsów
CORBA (ale nie znam szczegółów).
Post by Sektor van Skijlen
Problem polega zatem na tym,
że o ile do Javy opracowano mnóstwo [...]
I tu jest sedno sprawy. Java nie jest standardem (podobnie, jak .NET) a
tylko takie rzeczy opłaca się reklamować. Widziałeś kiedyś, żeby ktoś
reklamował TCP/IP? Nie, bo to jest standard. A może HTTP? Też nie, bo to
też jest standard. Java nie jest standardem i dlatego dla Javy istnieje
mechanizm generujący zwrot z inwestycji w reklamę. Dlatego komuś opłaca
się reklamować Javę, .NET i inne tego typu rzeczy, natomiast nikomu nie
opłaca się reklamować TCP/IP, HTTP, C++, CORBA czy Ada. I to jest
właśnie mechanizm, który stoi za różnicą w postrzegalnej widoczności C++
vs. Java.
Post by Sektor van Skijlen
Mimo swoich
właściwości, wciąż wychodzi na to, że C++ co najwyżej powoli zastępuje język
C [kolejność zdania normalna: podmiot-orzeczenie-dopełnienie! :)], a do
pisania dużych aplikacji - być może, bo jak mówię statystyk nie znam -
przestaje się go stosować.
Z tego co widzę, to nie jest to prawda.
Post by Sektor van Skijlen
Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Oczywiście, że stać. Lepiej - takie technologie są. Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
Post by Sektor van Skijlen
Czy dodanie odśmiecacza w nowym standardzie coś tu zmieni? Oczywiście, że nie
zmieni.
Dokładnie, nic się nie zmieni.
Nadal C++ będzie najbardziej użyteczny. :)
Post by Sektor van Skijlen
Może to też kwestia tego, że C++ jest dla niektórych za trudny?
To nie jest problem. Ludzie powszechnie i swobodnie piszą w C++ prawie w
ogóle go nie znając, więc poziom trudności nie jest tu przeszkodą.
Post by Sektor van Skijlen
Kwestię arytmetyki
wskaźników to może olejmy, bo tego argumentu nie można traktować poważnie.
A cytując (mniej więcej) Joela Spolsky'ego:

"Some people for some reason are born without the part of brain which is
responsible for pointers."

Oczywiście, że to nie jest poważny argument. Można napisać dowolnie duży
system w C++ bez gołych wskaźników i bez ich arytmetyki.
Post by Sektor van Skijlen
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Paweł Sikora
2006-03-23 12:30:08 UTC
Permalink
Post by Maciej Sobczak
Nikt nie zna Ady, bo nikt się jej nie uczył, bo nikt nie widział takiej
potrzeby, bo nie ma projektów w Adzie, więc nie ma pracy w Adzie.
język ADA jest obowiązkową pozycją (laborki, projekty, egzamin)
np. na AGH-u (no przynajmniej na kierunku automatyka i robotyka),
więc ludzie znają ten język, a to, że nie pogłębiają swojej wiedzy
to już wpływ rynku pracy.
mk
2006-03-23 12:48:37 UTC
Permalink
Post by Sektor van Skijlen
Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych
systemach czasu rzeczywistego, nie wyobrażam sobie zastąpienia go
czymkolwiek innym.
No właśnie Sektor... a co z Adą?
Ada 2015 na pewno będzie najbardziej błyszczącą srebrną kulą (z dziesiątą
parą kopyt)...
Post by Sektor van Skijlen
W sensie przenośności, stopnia ustandaryzowania i docelowego segmentu
rynku, bezpośrednim konkurentem dla C++ jest Ada, której z jakiegoś powodu
poza paroma mądralami od inżynierii oprogramowania nikt nie używa.
Nikt???
NASA, ESA, przemysł lotniczy, jądrowy, medyczny, szweje...
Hardware'owcy też na codzień używają VHDL'a, języka opartego na Adzie (i za
to samo przeklinanego).
Post by Sektor van Skijlen
Ada. Ale trzeba wziąć pod uwagę ten samonapędzający się mechanizm.
[...]
IMHO (i nie tylko moim) Ada ma z czym innym problem...
Najzwyczajniej trudno o bardziej nieporęczny język -- ot przerost formy nad
treścią, ale cóż, niektórzy wierzą, że to droga ku niezawodności.

pzdr
mk
Maciej Sobczak
2006-03-23 16:09:34 UTC
Permalink
Post by mk
No właśnie Sektor... a co z Adą?
Ada 2015 na pewno będzie najbardziej błyszczącą srebrną kulą (z
dziesiątą parą kopyt)...
Tak, co 10 lat Ada ma nowy standard.
Tak, C++ również.

I dlatego relacja rynkowa pomiędzy C++ i Adą się nie zmieni. Musiałbyś
zatrzymać jeden z tych języków w miejscu i pozwolić drugiemu rozwijać
się przez co najmniej dwie dekady, żeby coś w tej relacji zaburzyć.
Zauważ też, że Ada 2005 nie jest żadnym istotnym postępem w stosunku do
Ady 95 - po prostu goście nie skorzystali z tej okazji pojawiającej się
raz na 10 lat i zrobili jedynie kosmetykę. A w międzyczasie w C++ pojawi
się całe stado istotnych i fundamentalnych elementów, które popchną ten
język do przodu.
Post by mk
Post by Maciej Sobczak
W sensie przenośności, stopnia ustandaryzowania i docelowego segmentu
rynku, bezpośrednim konkurentem dla C++ jest Ada, której z jakiegoś
powodu poza paroma mądralami od inżynierii oprogramowania nikt nie używa.
Nikt???
NASA, ESA, przemysł lotniczy, jądrowy, medyczny, szweje...
Ci sami ludzie używają C++, Javę, Pythona i nawet VB. To, że ktoś używa
Adę nie znaczy, że jest to istotny segment rynku, który mógłby pozwolić
na użycie słowa "powszechny". Raczej należałoby powiedzieć, że Ada jest
wykorzystywana *tylko* tam. Napisałem, że nikt jej nie używa w tym samym
sensie jak mógłbym napisać, że nikt nie jeździ Bugati albo Maybachami.
Jak to nikt??? Produkują tego całe 80 sztuk rocznie!
Oczywiście, ale co z tego. Maybacha widziałem raz na ulicy (i nawet nie
w Toruniu :) ), Bugati tylko na wystawie.
Mówię właśnie o tych proporcjach.

Inny sposób mówienia o tych proporcjach jest taki: wejdź na jakiś portal
z ofertami pracy i powiedz mi, ile jest tam ofert dla programistów Ada.
Albo, bardziej brutalnie: ilu absolwentów uczelni informatycznych, na
każde 1000 głów, będzie zawodowo pisać w Adzie?
Post by mk
Hardware'owcy też na codzień używają VHDL'a, języka opartego na Adzie (i
za to samo przeklinanego).
VHDL jest tak samo oparty na Adzie, jak Java na C. :)
To, że ma słowa begin i end nie znaczy jeszcze, że jest na czymś oparty.
Post by mk
IMHO (i nie tylko moim) Ada ma z czym innym problem...
Najzwyczajniej trudno o bardziej nieporęczny język -- ot przerost formy
nad treścią, ale cóż, niektórzy wierzą, że to droga ku niezawodności.
Na moje oko, to Ada jest właśnie zbyt *uboga* w mechanizmy, których
naprawdę potrzebuje. Wygląda tak, jakby projektanci zaczęli coś robić
dobrze, ale w połowie tematu się rozmyślili.
Czyli chyba się tu różnimy w ocenie formy i treści. :)
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sektor van Skijlen
2006-03-23 17:59:30 UTC
Permalink
Post by Maciej Sobczak
Oczywiście, ale co z tego. Maybacha widziałem raz na ulicy (i nawet nie
w Toruniu :) ), Bugati tylko na wystawie.
http://www.joemonster.org/mg/displayimage.php?album=search&cat=0&pos=6

(jeśli ktoś ma konto na JoeMonster.org)
Post by Maciej Sobczak
Mówię właśnie o tych proporcjach.
Inny sposób mówienia o tych proporcjach jest taki: wejdź na jakiś portal
z ofertami pracy i powiedz mi, ile jest tam ofert dla programistów Ada.
Albo, bardziej brutalnie: ilu absolwentów uczelni informatycznych, na
każde 1000 głów, będzie zawodowo pisać w Adzie?
No dobra, ale na razie znajduję więcej ogłoszeń na Javę, niż na C++. Podobno
zresztą za Javę więcej płacą (ale z drugiej strony nie wiem, skąd biorą te
dane, czy z ofert, czy z rzeczywiście pracujących).
Post by Maciej Sobczak
Post by mk
Hardware'owcy też na codzień używają VHDL'a, języka opartego na Adzie (i
za to samo przeklinanego).
VHDL jest tak samo oparty na Adzie, jak Java na C. :)
To, że ma słowa begin i end nie znaczy jeszcze, że jest na czymś oparty.
Nieprawda. Większość składni jest tam wzięta z Ady, w tym "end costam;",
dostęp do pól przez ' czy ten dziwny => .

Hardwarowcy jednak używają nie tylko VHDL, ale też Veriloga, języka znacznie
bliższego sprzętowi, podczas gdy w VHDL-u jest pewna konstrukcja (nie pamiętam
jaka), której do dziś żadne narzędzia syntezy nie potrafią zsyntetyzować.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Marcin Gabryszewski
2006-03-24 07:18:03 UTC
Permalink
Post by Sektor van Skijlen
Nieprawda. Większość składni jest tam wzięta z Ady, w tym "end costam;",
dostęp do pól przez ' czy ten dziwny => .
a nie czasem z asm

costam proc
costam endp
--
Marcin Gabryszewski
G DATA Software
www.gdata.pl

address:[FirstName][SurnameFirstLetter]@gdata.pl
Maciej Sobczak
2006-03-24 07:24:21 UTC
Permalink
Post by Sektor van Skijlen
Post by Maciej Sobczak
Oczywiście, ale co z tego. Maybacha widziałem raz na ulicy (i nawet nie
w Toruniu :) ), Bugati tylko na wystawie.
http://www.joemonster.org/mg/displayimage.php?album=search&cat=0&pos=6
(jeśli ktoś ma konto na JoeMonster.org)
Domyślam się, że tam jest Maybach z Dyrektorem.
Skoro już wspomniałem o Bugati:

Loading Image...

(nie trzeba mieć konta)

(Ktoś ostatnio pytał, jaka jest tematyka grupy... :D )
Post by Sektor van Skijlen
No dobra, ale na razie znajduję więcej ogłoszeń na Javę, niż na C++.
Możliwe. Ale Ciebie osobiście nie interesuje sama ilość ogłoszeń, ale
raczej para (ilosc_ogloszen, ilosc_potencjalnych_kandydatow).
Post by Sektor van Skijlen
Podobno
zresztą za Javę więcej płacą (ale z drugiej strony nie wiem, skąd biorą te
dane, czy z ofert, czy z rzeczywiście pracujących).
Ja też nie wiem, skąd się biorą. Moje ostatnie statystyki z Wawy tego
nie potwierdziły.
Post by Sektor van Skijlen
Post by Maciej Sobczak
Post by mk
Hardware'owcy też na codzień używają VHDL'a, języka opartego na Adzie (i
za to samo przeklinanego).
VHDL jest tak samo oparty na Adzie, jak Java na C. :)
To, że ma słowa begin i end nie znaczy jeszcze, że jest na czymś oparty.
Nieprawda. Większość składni jest tam wzięta z Ady, w tym "end costam;",
dostęp do pól przez ' czy ten dziwny => .
Sektor, ale co Ty mi tu? Podpierając się tylko paroma (albo nawet tylko
jednym) elementami *składni* nawet goście od Pythona twierdzą, że
pochodzi od Ady. Niech sobie nawet VHDL ma połowę gramatyki z Ady - te
języki wyrażają zupełnie różną semantykę i koncepcje. To jest istotne a
nie to, jakie są znaki interpunkcyjne.

Aly my nie o tym.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sektor van Skijlen
2006-03-24 08:39:16 UTC
Permalink
Post by Maciej Sobczak
Post by Sektor van Skijlen
Post by Maciej Sobczak
Oczywiście, ale co z tego. Maybacha widziałem raz na ulicy (i nawet nie
w Toruniu :) ), Bugati tylko na wystawie.
http://msobczak.com/photo/temp/06030918.jpg
Eee... Maybach maybach zrobił na mnie lepsze wrażenie :)

Co nie zmienia faktu, że do żadnego z nich bym nie chciał wsiąść, nawet jako
pasażer.
Post by Maciej Sobczak
Post by Sektor van Skijlen
No dobra, ale na razie znajduję więcej ogłoszeń na Javę, niż na C++.
Możliwe. Ale Ciebie osobiście nie interesuje sama ilość ogłoszeń, ale
raczej para (ilosc_ogloszen, ilosc_potencjalnych_kandydatow).
No tak, ale te wartości są zwykle skorelowane. Chociaż nie do końca jestem
tego pewny.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Podobno
zresztą za Javę więcej płacą (ale z drugiej strony nie wiem, skąd biorą te
dane, czy z ofert, czy z rzeczywiście pracujących).
Ja też nie wiem, skąd się biorą. Moje ostatnie statystyki z Wawy tego
nie potwierdziły.
Dobrze słyszeć, ale te dane były z UK.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Post by Maciej Sobczak
Post by mk
Hardware'owcy też na codzień używają VHDL'a, języka opartego na Adzie (i
za to samo przeklinanego).
VHDL jest tak samo oparty na Adzie, jak Java na C. :)
To, że ma słowa begin i end nie znaczy jeszcze, że jest na czymś oparty.
Nieprawda. Większość składni jest tam wzięta z Ady, w tym "end costam;",
dostęp do pól przez ' czy ten dziwny => .
Sektor, ale co Ty mi tu? Podpierając się tylko paroma (albo nawet tylko
jednym) elementami *składni* nawet goście od Pythona twierdzą, że
pochodzi od Ady. Niech sobie nawet VHDL ma połowę gramatyki z Ady - te
języki wyrażają zupełnie różną semantykę i koncepcje. To jest istotne a
nie to, jakie są znaki interpunkcyjne.
Nie do końca masz rację.

VHDL nieprzypadkowo ma składnię wzorowaną na Adzie - chociaż oczywiście poza
owymi podobieństwami składni, wiele wspólnego ze sobą nie mają. Słów
kluczowych entity i architecture Ada też nie posiada, ale sposób deklarowania
jest składniowo podobny. Ale nie zgodzę się, że to jest podobieństwo jak C do
Javy. Ale jeśli przyłożymy to jako C++ do Javy, to będzie już bardziej zgodne
z prawdą.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Seweryn Habdank-Wojewódzki
2006-03-24 20:29:51 UTC
Permalink
Witam
Post by Maciej Sobczak
http://msobczak.com/photo/temp/06030918.jpg
Znaczy się,
ten, tego, ten,
po długim ten tegowaniu
w mojej głowie,
powiem

Ładną masz Maćku brykę ;-).

I w przeciwieństwie do Sektora chętnie bym zagrzał silnik takiego cuda. Choć w
EU to chyba tylko w niemczech można troszeczkę go pogimnastykować.

Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
`\/\/
SirMike
2006-03-23 13:21:40 UTC
Permalink
Post by Maciej Sobczak
- Brak oddzielenia specyfikacji od implementacji (czyli po ludzku: brak
odpowiednika plików nagłówkowych
A interfejsy? Chyba, ze miales na mysli cos innego.
--
SirMike - http://www.sirmike.org

C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg. - Bjarne Stroustrup
Maciej Sobczak
2006-03-23 16:13:29 UTC
Permalink
Post by SirMike
brak odpowiednika plików nagłówkowych
A interfejsy? Chyba, ze miales na mysli cos innego.
Interfejsy w Javie są za słabe, bo nie pozwalają zawrzeć żadnego
sensownego kontraktu. Przy braku const jest to szczególnie dotkliwe.

A drugi problem jest taki, że specyfikacja to nie tylko nazwy funkcji.
To również typy danych użyte w projekcie. Java nie potrafi tego
wyodrębnić i opisać w osobnym pliku.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
A..L.
2006-03-24 03:35:00 UTC
Permalink
On Thu, 23 Mar 2006 17:13:29 +0100, Maciej Sobczak
Post by Maciej Sobczak
Post by SirMike
brak odpowiednika plików nagłówkowych
A interfejsy? Chyba, ze miales na mysli cos innego.
Interfejsy w Javie są za słabe, bo nie pozwalają zawrzeć żadnego
sensownego kontraktu. Przy braku const jest to szczególnie dotkliwe.
A drugi problem jest taki, że specyfikacja to nie tylko nazwy funkcji.
To również typy danych użyte w projekcie. Java nie potrafi tego
wyodrębnić i opisać w osobnym pliku.
Panie Sobczak, a moze by tak Pan sie Javy nauczyl i poprogramowal
troche, ale wie Pan, nie tak akademicko, ale przemyslowo?... Jakos
Panskie resume w zakresie Javy jest zupelnie dziewicze, a "Java 2
fundamentals cerificate" to troche za malo. Dobrze pisac o tym na
czym sie zna, a jak sie nie zna, to lepiej od razu napisac ze sie
nei zna zamiast pisac bzdury. No i wie Pan, wlasnie Java 6.0 sie
ukazala...

A.L.
Maciej Sobczak
2006-03-24 07:42:58 UTC
Permalink
Post by A..L.
Panie Sobczak, a moze by tak Pan sie Javy nauczyl i poprogramowal
troche, ale wie Pan, nie tak akademicko, ale przemyslowo?...
Skoro zostałem wywołany...
Post by A..L.
Jakos
Panskie resume w zakresie Javy jest zupelnie dziewicze
Ono jest dziewicze w wielu zakresach, bo nie wszystko jest sens eksponować.
Post by A..L.
Dobrze pisac o tym na
czym sie zna, a jak sie nie zna, to lepiej od razu napisac ze sie
nei zna zamiast pisac bzdury.
Ponownie polecam lekturę postów Jamesa Kanze na comp.lang.c++.moderated.
Przecież tu nie chodzi o to, żeby wychylać się z własnym autorytetem.
Post by A..L.
No i wie Pan, wlasnie Java 6.0 sie
ukazala...
Coś ciekawego tam jest?
Zwłaszcza w kontekście tego, o czym tu mówiliśmy? Lista na stronie
http://java.sun.com/javase/6/ na nic takiego nie wskazuje.

Poza tym, wie Pan - to, że się "ukazała", być może jest jakąś ciekawą
informacją dla tych, którzy w ciągu jednego wieczoru mogą sobie zrobić
upgrade swojego domowego peceta, natomiast nie jest to informacja
poruszająca w zastosowaniach, jak to Pan ujął, "przemysłowych".
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sektor van Skijlen
2006-03-24 08:47:16 UTC
Permalink
Post by Maciej Sobczak
Post by A..L.
No i wie Pan, wlasnie Java 6.0 sie
ukazala...
Coś ciekawego tam jest?
Zwłaszcza w kontekście tego, o czym tu mówiliśmy? Lista na stronie
http://java.sun.com/javase/6/ na nic takiego nie wskazuje.
Oj... czuję że będzie materiał na felieton :)

Tak przy okazji - no, trzeba przyznać, nieźle rozruszałem grupę, skoro p.
Lewandowski zawitał tu od ho ho ho czasu.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
A..L.
2006-03-24 13:40:36 UTC
Permalink
On Fri, 24 Mar 2006 08:47:16 +0000 (UTC), Sektor van Skijlen
Post by Sektor van Skijlen
Post by Maciej Sobczak
Post by A..L.
No i wie Pan, wlasnie Java 6.0 sie
ukazala...
Coś ciekawego tam jest?
Zwłaszcza w kontekście tego, o czym tu mówiliśmy? Lista na stronie
http://java.sun.com/javase/6/ na nic takiego nie wskazuje.
Oj... czuję że będzie materiał na felieton :)
Tak przy okazji - no, trzeba przyznać, nieźle rozruszałem grupę, skoro p.
Lewandowski zawitał tu od ho ho ho czasu.
Wszusyko dzieki Koledze Galickienu :)

A.L.
A..L.
2006-03-24 13:39:56 UTC
Permalink
On Fri, 24 Mar 2006 08:42:58 +0100, Maciej Sobczak
Post by Maciej Sobczak
Post by A..L.
Panie Sobczak, a moze by tak Pan sie Javy nauczyl i poprogramowal
troche, ale wie Pan, nie tak akademicko, ale przemyslowo?...
Skoro zostałem wywołany...
Post by A..L.
Jakos
Panskie resume w zakresie Javy jest zupelnie dziewicze
Ono jest dziewicze w wielu zakresach, bo nie wszystko jest sens eksponować.
No to prosze wyeksponowac, wtedy Panskei argumenty nabiora wagi.
Post by Maciej Sobczak
Post by A..L.
Dobrze pisac o tym na
czym sie zna, a jak sie nie zna, to lepiej od razu napisac ze sie
nei zna zamiast pisac bzdury.
Ponownie polecam lekturę postów Jamesa Kanze na comp.lang.c++.moderated.
Przecież tu nie chodzi o to, żeby wychylać się z własnym autorytetem.
Wie Pan, ja mam tyle lat i widzialem w zyciu tyle, ze rowno olewam
autorytety.
Post by Maciej Sobczak
Post by A..L.
No i wie Pan, wlasnie Java 6.0 sie
ukazala...
Coś ciekawego tam jest?
Zwłaszcza w kontekście tego, o czym tu mówiliśmy? Lista na stronie
http://java.sun.com/javase/6/ na nic takiego nie wskazuje.
No wlasnie, nie wie Pan...
Post by Maciej Sobczak
Poza tym, wie Pan - to, że się "ukazała", być może jest jakąś ciekawą
informacją dla tych, którzy w ciągu jednego wieczoru mogą sobie zrobić
upgrade swojego domowego peceta, natomiast nie jest to informacja
poruszająca w zastosowaniach, jak to Pan ujął, "przemysłowych".
Prosze Pana, widac ze nei ma Pan pojecia o czym Pan pisze. Widac
cale Panskei doswiadczenie z Java to "upgrade swojego domowego
peceta". Wiec prosze dac sobei spokoj z opiniami w rodzaju "Java sie
do nieczego nei nadaja" i raczej pozostac przy obronie C++ nei
robiec wycieczek w dziedziny Panu neiznane.

A.L.
Maciej Sobczak
2006-03-24 15:30:39 UTC
Permalink
Post by A..L.
Post by Maciej Sobczak
Post by A..L.
Jakos
Panskie resume w zakresie Javy jest zupelnie dziewicze
Ono jest dziewicze w wielu zakresach, bo nie wszystko jest sens eksponować.
No to prosze wyeksponowac, wtedy Panskei argumenty nabiora wagi.
Nie rozumiem - czy to znaczy, że to co napisałem w tym wątku ma sens
albo nie ma zależnie od tego, co sobie dopiszę w życiorysie?

Pan może pracuje w HR?
Post by A..L.
Post by Maciej Sobczak
Post by A..L.
Dobrze pisac o tym na
czym sie zna, a jak sie nie zna, to lepiej od razu napisac ze sie
nei zna zamiast pisac bzdury.
Ponownie polecam lekturę postów Jamesa Kanze na comp.lang.c++.moderated.
Przecież tu nie chodzi o to, żeby wychylać się z własnym autorytetem.
Wie Pan, ja mam tyle lat i widzialem w zyciu tyle, ze rowno olewam
autorytety.
No ja niestety jestem jeszcze młody i niewiele widziałem - dlatego muszę
czasem poczytać, co inni piszą.
Post by A..L.
Post by Maciej Sobczak
Post by A..L.
No i wie Pan, wlasnie Java 6.0 sie
ukazala...
Coś ciekawego tam jest?
Zwłaszcza w kontekście tego, o czym tu mówiliśmy? Lista na stronie
http://java.sun.com/javase/6/ na nic takiego nie wskazuje.
No wlasnie, nie wie Pan...
No więc? Jeśli mnie Pan oświeci, to może skorzystają na tym również inni
forumowicze?
Post by A..L.
Prosze Pana, widac ze nei ma Pan pojecia o czym Pan pisze.
Proszę Pana. W całym tym wątku jedyne co Pan na razie zrobił, to
wydedukował Pan moją niekompetencję na podstawie tego, co mam w swoim
resume.
Natomiast dość istotna sprawa, której Pan *nie* zrobił, to nie odniósł
się Pan technicznie do *żadnej* z poruszonych przeze mnie kwestii.
Jeżeli faktycznie nie mam pojęcia o czym piszę, to tym łatwiej jest to
wykazać. Jak mniemam, osoba z mająca "tyle" lat i która "tyle" w życiu
widziała, powinna jednym pstryknięciem klawiatury wysłać mnie i moją
domniemaną niekompetencję na drzewo. Nie potrafię odpowiedzieć sobie na
pytanie, dlaczego Pan jeszcze tego nie zrobił.
Otóż uprzejmie informuję, że traktuję grupy dyskusyjne jako źródło
wiedzy i często uczestniczę w dyskusjach wyłącznie po to, żeby się
czegoś nowego dowiedzieć (czasami do tego stopnia, że *prowokuję*
dyskusję) i muszę przyznać, że na tym forum są osoby, od których się
sporo rzeczy dowiedziałem. Będzie mi niezmiernie miło, jeżeli również
ten obecny wątek zaowocuje czymś wartościowym w tym aspekcie i liczę na
to, że poruszone przeze mnie tematy znajdą swoje rozwinięcia.
Post by A..L.
Widac
cale Panskei doswiadczenie z Java to "upgrade swojego domowego
peceta".
Niestety nie. Nie uaktualniam swojego domowego peceta aż tak często,
żebym mógł zebrane wtedy doświadczenia traktować jako wartościowe.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
AL.
2006-03-24 22:39:55 UTC
Permalink
On Fri, 24 Mar 2006 16:30:39 +0100, Maciej Sobczak
Natomiast do¶æ istotna sprawa, której Pan *nie* zrobi³, to nie odniós³
siê Pan technicznie do *¿adnej* z poruszonych przeze mnie kwestii.
To Pan poruszal jakies kwestie techniczne?...

Czy z tekstem, cytuje: "1. Java w ogóle nie nadaje siê do
programowania czegokolwiek... " mozna w ogole TECHNICZNIE dyskutowac?
A to Panskie credo numer jeden.

Jezeli Pan zamiesci jakies techniczne uzasadnienie tego faktu, w
szczegolnosci interpretacje slow "do niczego" i "w ogole" to prosze
dac znac.

A.L.
Kyle
2006-03-24 23:15:06 UTC
Permalink
Post by AL.
On Fri, 24 Mar 2006 16:30:39 +0100, Maciej Sobczak
Natomiast do¶æ istotna sprawa, której Pan *nie* zrobi³, to nie odniós³
siê Pan technicznie do *¿adnej* z poruszonych przeze mnie kwestii.
To Pan poruszal jakies kwestie techniczne?...
to może ja w kwestii czysto technicznej ...
mógłbyś nie rozkrzaczać komentarzy ? ... dzięki

[snip]
Post by AL.
A.L.
A..L.
2006-03-25 00:22:28 UTC
Permalink
Post by Kyle
Post by AL.
On Fri, 24 Mar 2006 16:30:39 +0100, Maciej Sobczak
Natomiast do?? istotna sprawa, której Pan *nie* zrobi?, to nie odniós?
si? Pan technicznie do *?adnej* z poruszonych przeze mnie kwestii.
To Pan poruszal jakies kwestie techniczne?...
to może ja w kwestii czysto technicznej ...
mógłbyś nie rozkrzaczać komentarzy ? ... dzięki
Zapomnialem ustawic ze grupa jest polska

A.L>
Sebastian Kaliszewski
2006-03-23 16:57:09 UTC
Permalink
Post by Maciej Sobczak
A teraz na temat: C++ jest najbardziej *użytecznym* językiem
programowania i to zabezpiecza jego szczęśliwy byt na długie lata w
przód. Nie jest idealny w sensie teorii projektowania języków, ale
języki idealne (kupa tego na uczelniach) są używane tylko przez ich twórców.
Popatrzmy na konkurencję.
1. Java w ogóle nie nadaje się do programowania czegokolwiek.
ROTFL!
Post by Maciej Sobczak
Z mojego
- Brak oddzielenia specyfikacji od implementacji
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny jest
jeszcze jakiś opis w ludzkim języku.

A Doxygenem, JavaDocem, KDocem czy czym tam jeszcze mając źródło i
odpowiednio soformatowany opis w ludzkim języku można wygenerować
specyfikację wygodną do poczyania, poklikania, wydrukowania i wzięcia sobie
"do poduszki".
Post by Maciej Sobczak
(czyli po ludzku: brak
odpowiednika plików nagłówkowych - wiem, wiem, niektórym się wydaje, że
takie rozdzielenie to główna wada C++, ale nie dość, że to jest zaleta,
to w dodatku jest to konieczność w większych projektach
Nie prawda. Mylisz konieczność z li tylko przydatnością.
Post by Maciej Sobczak
i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
Post by Maciej Sobczak
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to za
mało. W wersji dla ubogich potrzebne jest coś, co ma np. Ada w postaci
słów kluczowych type i subtype, w wersji rozbudowanej potrzebne jest
przeciążanie operatorów i wykorzystanie zewnętrznych opisów dziedzin i
generatorów typów albo wbudowanego metajęzyka do opisu dziedzin. W
porządnych językach to się robi naturalnie, w Javie nie da się tego
zrobić wcale a bez tego nie ma sensu mówić o inżynierii programowania.
ROTFLMAO! Dlaczegoż więc tyle pozycji właśnie z inżynierii programowania
jako głównym językiem posługuje się Javą?
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z możliwych
rozwiązań problemu.
Post by Maciej Sobczak
2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję.
Cóż to nie używacie ani *nixów ani Wind?
Post by Maciej Sobczak
To jest język na jedną tylko
platformę
Nie jest.
Post by Maciej Sobczak
tak samo jak swego czasu był nim VB i będzie istniał tylko tak
długo, jak długo M$ będzie widział w tym swój biznesowy cel. Nie jest to
platforma, którą możnaby wziąć pod uwagę planując jakiś większy projekt.
Iii tam. Niektórzy robią sobie większe prohekty na Windzie...

[ciach]
Post by Maciej Sobczak
Post by Sektor van Skijlen
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo.
Trochę bardzo.
[ciach]
Post by Maciej Sobczak
Każdy poważniejszy rozproszony system jest oparty o CORBA.
ROTFL!
Mało tych "poważniejszych" systemów widać widziałeś...

[ciach]
Post by Maciej Sobczak
Post by Sektor van Skijlen
Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Oczywiście, że stać. Lepiej - takie technologie są.
Kulawe
Post by Maciej Sobczak
Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
C++ w połączeniu z preprocesorem ma tak po@#$*ą składnię, że wielu narzędzi
*praktycznie* zrobić się nie daje (tak by były przy tym niezawodne),
szczególnie gdy mają być przenośne.

C++ jest natyle pokomplikowane, że do bardzo niedawna (5 lat po ogłoszeniu
standardu) zdecydowana większość kompilatorów tego języka nie była w stanie
go sparsować zgodnie ze standardem. A co tu mówić o jakimś zautomatyzowanym
refactoringu itp...

Do Javy takie rzeczy po prostu robi się łatwiej.

A, jeśli chcę zrobić przenośny program w C++, który da się zbuildowować na
dziś powszechnie używanych biznesowo platrofmach i zechcę użyć jakiś nieco
bardziej zaawansowanych technik (szczególnie w okolicach szablonów) to mam
problem. Bo GCC 3.x (często wciąż używany 3.2.x) wielu rzeczy nie połknie,
bo MSVC 7.1 ma swoje własne humory, nie mówiąc już o kompilatorach na Uniksy
-- te "z zasady" mają na temat różnych konstrukcji własne zdanie.

Durnieją debuggery (mają problem choćby z tym, że np. breakpoint ustawiony
na MyTemplate<int> nie jest breakpointem ustawionym na MyTemplate<long>),
głupieją proste generatory dokumentacji (preprocessor i kompilacja warunkowa
"rulez") -- co tu mówić o nbardziej zaawansowanych narzędziach.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Może to też kwestia tego, że C++ jest dla niektórych za trudny?
To nie jest problem. Ludzie powszechnie i swobodnie piszą w C++ prawie w
ogóle go nie znając, więc poziom trudności nie jest tu przeszkodą.
Jest.

To że piszą w nim nie znając go jest przyczyną całkiem częstych, całkiem
"fajnych" bugów (A bo dla mnie było oczywioste że to musi tak działać)

[ciach]
Post by Maciej Sobczak
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
Właśnie dla tego jest po prostu kosztowny w stosowaniu. I tam gdzie nie jest
niezbędny można się go pozbyć. Zastępując nie koniecznie Javą (Java też jest
fuj, to klasyczny bloatware -- ociężały i przeładowany).
Znam parę dość sporych i istotnych systemów korzystających głównie
(bazujących na) z języków skrypotwych -- a konkretniej pewnego wyjątkowo
obrzydliwego którego nazwa to oksymoron (Sector już pewnie wie o który mi
chodzi ;) ) -- których w C++ nie dałoby się w rozsądnym czasie napisać,
przetestować i wdrożyć. System(y) te działają i to całkiem nieźle. C++ jest
w nich użyte tylko miejscami, tam gdzie wymagana była maksymalna wydajność a
logika była stosunkowo prosta (a realizowana funkcjonalność stosunkowo
niewielka).

System(y) te są w powszechnym użyciu (wielu z uczestników tej grupy z nich
korzysta wcale często).

pzdr
--
Sebastian Kaliszewski
Sektor van Skijlen
2006-03-23 18:27:50 UTC
Permalink
Post by Sebastian Kaliszewski
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny jest
jeszcze jakiś opis w ludzkim języku.
Przecież plik nagłówkowy nie jest od tego, żeby był specyfikacją, tylko od
tego, żeby był wyodrębnionym interfejsem!
Post by Sebastian Kaliszewski
A Doxygenem, JavaDocem, KDocem czy czym tam jeszcze mając źródło i
odpowiednio soformatowany opis w ludzkim języku można wygenerować
specyfikację wygodną do poczyania, poklikania, wydrukowania i wzięcia sobie
"do poduszki".
No przecież w C++ to się właśnie robi. Ale to nie jest do tego, żeby mieć do
poczytania, tylko żeby mieć do użycia.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
W jaki sposób na przykład?

Bo, poza #include, nie potrafię sobie wyobrazić, o co ci mogłoby tutaj
chodzić.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z możliwych
rozwiązań problemu.
O! To bardzo chętnie posłucham, jaką inną technikę rozwiązania tego problemu
mógłbyś zaproponować.

Zakładamy, że piszesz aplikację czasu rzeczywistego, każdy zasób kosztuje
straszne pieniądze, a przydział każdego z zasobów jest sprawą krytyczną. I to
na tyle krytyczną, że nieprzydzielenie zasobu może spowodować zagrożenie życia
i zdrowia ludzi.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
*praktycznie* zrobić się nie daje (tak by były przy tym niezawodne),
szczególnie gdy mają być przenośne.
Wybacz, ale ten argument z przyczyn niemerytorycznych pominiemy. Słucham
dalej.
Post by Sebastian Kaliszewski
C++ jest natyle pokomplikowane, że do bardzo niedawna (5 lat po ogłoszeniu
standardu) zdecydowana większość kompilatorów tego języka nie była w stanie
go sparsować zgodnie ze standardem. A co tu mówić o jakimś zautomatyzowanym
refactoringu itp...
Ciekaw jestem, czy widziałeś, jak wyglądała Java "po pierwszym standardzie".
Post by Sebastian Kaliszewski
A, jeśli chcę zrobić przenośny program w C++, który da się zbuildowować na
dziś powszechnie używanych biznesowo platrofmach i zechcę użyć jakiś nieco
bardziej zaawansowanych technik (szczególnie w okolicach szablonów) to mam
problem. Bo GCC 3.x (często wciąż używany 3.2.x) wielu rzeczy nie połknie,
No, czego na przykład? Chodzi mi o przykład taki naprawdę "biznesowy". Przy
czym zwracam uwagę, że dobrze by było podeprzeć się w tym "alternatywnym"
rozwiązaniem w Javie.
Post by Sebastian Kaliszewski
Durnieją debuggery (mają problem choćby z tym, że np. breakpoint ustawiony
na MyTemplate<int> nie jest breakpointem ustawionym na MyTemplate<long>),
głupieją proste generatory dokumentacji (preprocessor i kompilacja warunkowa
"rulez") -- co tu mówić o nbardziej zaawansowanych narzędziach.
No cóż, faktem jest, że niektóre narzędzia nie wiedzą, że
__attribute__((packed)) to specjalna konstrukcja językowa związana z
rozszerzeniem kompilatora. Ale o ile pamiętam, można robić jakieś wyjątki na
takie konstrukcje.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
Właśnie dla tego jest po prostu kosztowny w stosowaniu. I tam gdzie nie jest
niezbędny można się go pozbyć. Zastępując nie koniecznie Javą (Java też jest
fuj, to klasyczny bloatware -- ociężały i przeładowany).
Zaraz, nie dyskutujemy tutaj o tym, czy C++ to uniwersalny młotek do
wszystkiego, tylko czy C++ zostaje wypierany przez inne języki w tych
dziedzinach, dla których jest przeznaczony.
Post by Sebastian Kaliszewski
Znam parę dość sporych i istotnych systemów korzystających głównie
(bazujących na) z języków skrypotwych -- a konkretniej pewnego wyjątkowo
obrzydliwego którego nazwa to oksymoron (Sector już pewnie wie o który mi
chodzi ;) )
Sektor chyba :)
Niech zgadnę - masz na myśli perla?
No nawet mnie nie rozśmieszaj; jeśli jeszcze chcesz mi wmówić, że w tym języku
jesteś w stanie napisać cokolwiek, co mógłbyś później utrzymywać, to musiałbyś
dużo chleba zjeść.
Post by Sebastian Kaliszewski
-- których w C++ nie dałoby się w rozsądnym czasie napisać,
przetestować i wdrożyć. System(y) te działają i to całkiem nieźle.
O, ależ argument! Są systemy napisane w C++, Javie, C#, Smalltalku, Lispie i
COBOLu. I też działają.
Post by Sebastian Kaliszewski
C++ jest w nich użyte tylko miejscami, tam gdzie wymagana była maksymalna
wydajność a logika była stosunkowo prosta (a realizowana funkcjonalność
stosunkowo niewielka).
Taaa... u nas kiedyś jacyś goście wpadli na pomysł napisania supertoola
testującego.

Silnik musi być szybki i wydajny, no to trzeba go napisać w C++.
GUI musi być w Javie, bo goście jeśli chodzi o GUI to w ogóle nie wiedzą o
tym, że można to pisać w czymkolwiek innym.
Komunikacja przez TCP/IP, bo to przecież zaawansowana technika. Silnik chodzi
na serwerze napisanym w C++, a aplikacja Javy tylko się z nim komunikuje.
Adresy IP oczywiście zahardkodowane, bo ta super przenośna aplikacja napisana
w Javie działa tylko na jednym komputerze.

Wybacz, takie przykłady nie przekonają mnie o tym, że C++ był minimalizowany
ze względów technicznych. Był minimalizowany wyłącznie ze względów
biznesowych.
Post by Sebastian Kaliszewski
System(y) te są w powszechnym użyciu (wielu z uczestników tej grupy z nich
korzysta wcale często).
Nawet nie próbuję zgadywać.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Sebastian Kaliszewski
2006-03-24 18:26:43 UTC
Permalink
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny jest
jeszcze jakiś opis w ludzkim języku.
Przecież plik nagłówkowy nie jest od tego, żeby był specyfikacją, tylko od
tego, żeby był wyodrębnionym interfejsem!
Maciek mówi o specyfikacji.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
A Doxygenem, JavaDocem, KDocem czy czym tam jeszcze mając źródło i
odpowiednio soformatowany opis w ludzkim języku można wygenerować
specyfikację wygodną do poczyania, poklikania, wydrukowania i wzięcia sobie
"do poduszki".
No przecież w C++ to się właśnie robi. Ale to nie jest do tego, żeby mieć do
poczytania, tylko żeby mieć do użycia.
Do użycia jest to potrzebne kompilatorowi. A ten dużo wydajniej użyje
jakiegoś *.class, *.ppu, *.tpu, czy innego pliku binarnego.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
W jaki sposób na przykład?
Bo, poza #include, nie potrafię sobie wyobrazić, o co ci mogłoby tutaj
chodzić.
Kompilator Javy obejrzy sobie plik class i bedzie wiedział to co mu potrzeba
bez starty czasu na przelatywanie zagnieżdżonych includów, preprocessing,
parsowanie, itd...
Java parsuje dane źródło raz, a C++ pliki nagłówkowe magluje tyle razy ile
są includowane.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z możliwych
rozwiązań problemu.
O! To bardzo chętnie posłucham, jaką inną technikę rozwiązania tego problemu
mógłbyś zaproponować.
Zakładamy, że piszesz aplikację czasu rzeczywistego, każdy zasób kosztuje
straszne pieniądze, a przydział każdego z zasobów jest sprawą krytyczną. I to
na tyle krytyczną, że nieprzydzielenie zasobu może spowodować zagrożenie życia
i zdrowia ludzi.
Od różnych form deterministycznego określania życia obiektów (np. do MLi
wymyślono region inference), różnych deterministycznych GC, do zwykłego
powiadamiania obiektów o tym, że opuszczają zakres.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
*praktycznie* zrobić się nie daje (tak by były przy tym niezawodne),
szczególnie gdy mają być przenośne.
Wybacz, ale ten argument z przyczyn niemerytorycznych pominiemy.
Ale to jest powód jak najbardziej merytoryczny. Jest wręcz obrzydliwie
techniczny.
Post by Sektor van Skijlen
Słucham
dalej.
Post by Sebastian Kaliszewski
C++ jest natyle pokomplikowane, że do bardzo niedawna (5 lat po ogłoszeniu
standardu) zdecydowana większość kompilatorów tego języka nie była w stanie
go sparsować zgodnie ze standardem. A co tu mówić o jakimś zautomatyzowanym
refactoringu itp...
Ciekaw jestem, czy widziałeś, jak wyglądała Java "po pierwszym standardzie".
Parsować się dawała normalnie. Można było automatycznei okreslić gdzie są
klasy, metody, pola itd. W C++ w połączeniu z preprocesorem robi się to
ogólnie nierozwiązywalne (bo gdzies tam masz wywołanie makra, które rozwija
się w jakiś kawałek kodu w którym są różne wywołania, itd...).
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
A, jeśli chcę zrobić przenośny program w C++, który da się zbuildowować na
dziś powszechnie używanych biznesowo platrofmach i zechcę użyć jakiś nieco
bardziej zaawansowanych technik (szczególnie w okolicach szablonów) to mam
problem. Bo GCC 3.x (często wciąż używany 3.2.x) wielu rzeczy nie połknie,
No, czego na przykład? Chodzi mi o przykład taki naprawdę "biznesowy". Przy
czym zwracam uwagę, że dobrze by było podeprzeć się w tym "alternatywnym"
rozwiązaniem w Javie.
Ot choćby ostatnio, template instancjonowany pewną biblioteczną funkcją -- w
GCC poszło, w DEC CXX poszło, na Sunie -- nie. Uparło się że nie pójdzie i
koniec. W końcu zrobiłem tak, że jest kompilacja warunkowa i na Sunie
pewnych rzeczy nie robię -- akurat nie jest to na rzeczonym Sunie potzrebne,
więc implementacja zostałą poprostu zubożona w tym przypadku.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Durnieją debuggery (mają problem choćby z tym, że np. breakpoint ustawiony
na MyTemplate<int> nie jest breakpointem ustawionym na MyTemplate<long>),
głupieją proste generatory dokumentacji (preprocessor i kompilacja warunkowa
"rulez") -- co tu mówić o nbardziej zaawansowanych narzędziach.
No cóż, faktem jest, że niektóre narzędzia nie wiedzą, że
__attribute__((packed)) to specjalna konstrukcja językowa związana z
rozszerzeniem kompilatora. Ale o ile pamiętam, można robić jakieś wyjątki na
takie konstrukcje.
Ale co kompilator to inne dodatki. W dodatku gdy masz kod przenośny tio było
nie było takie różne elementy się obmakrowuje. Obmakrowuje się też często
takie rzeczy jak logowanie w zależności od skonfigurowanego poziomu
logowania itd...
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Właśnie dla tego jest po prostu kosztowny w stosowaniu. I tam gdzie nie jest
niezbędny można się go pozbyć. Zastępując nie koniecznie Javą (Java też jest
fuj, to klasyczny bloatware -- ociężały i przeładowany).
Zaraz, nie dyskutujemy tutaj o tym, czy C++ to uniwersalny młotek do
wszystkiego, tylko czy C++ zostaje wypierany przez inne języki w tych
dziedzinach, dla których jest przeznaczony.
Na ile jest wypierany a na ile pewnych nisz nigdy nie zajął...
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Znam parę dość sporych i istotnych systemów korzystających głównie
(bazujących na) z języków skrypotwych -- a konkretniej pewnego wyjątkowo
obrzydliwego którego nazwa to oksymoron (Sector już pewnie wie o który mi
chodzi ;) )
Sektor chyba :)
Ano, Sektor.
Post by Sektor van Skijlen
Niech zgadnę - masz na myśli perla?
Ano :)
Post by Sektor van Skijlen
No nawet mnie nie rozśmieszaj; jeśli jeszcze chcesz mi wmówić, że w tym języku
jesteś w stanie napisać cokolwiek, co mógłbyś później utrzymywać, to musiałbyś
dużo chleba zjeść.
No jestem w stanie. Nawet czasami muszę...

Jak się stara trzymać
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
-- których w C++ nie dałoby się w rozsądnym czasie napisać,
przetestować i wdrożyć. System(y) te działają i to całkiem nieźle.
O, ależ argument! Są systemy napisane w C++, Javie, C#, Smalltalku, Lispie i
COBOLu. I też działają.
Chodzi o to, że realizacja ich w C++ byłaby niemożliwa w założonych ramach
zarówno zcasowych jak i finansowych.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
C++ jest w nich użyte tylko miejscami, tam gdzie wymagana była maksymalna
wydajność a logika była stosunkowo prosta (a realizowana funkcjonalność
stosunkowo niewielka).
[ciach]
Post by Sektor van Skijlen
Wybacz, takie przykłady nie przekonają mnie o tym, że C++ był minimalizowany
ze względów technicznych. Był minimalizowany wyłącznie ze względów
biznesowych.
Był zminimalizowany właśnie ze względów technicznych. Ten wstrętny i brzydki
język skryptowy wraz z dostępnymi dla niego bibliotekami pozwolił na
zrelizowanie działającego systemu w czasie i budżecie nieosiągalnym dla C++
(btw z Javą też wygrało :) -- było 2x wydajniejsze i zrobione w terminie,
wariant Javowy nigdy nie został ukończony, bo przegrał). W C++ są tylko
niektóre krytyczne wydajnościowo elementy.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
System(y) te są w powszechnym użyciu (wielu z uczestników tej grupy z nich
korzysta wcale często).
Nawet nie próbuję zgadywać.
Nie musisz się martwić. Toto akurat całkiem dobrze działa i jest całkiem
bezpieczne i wydajne.

pzdr
--
Sebastian Kaliszewski
Moneetor
2006-03-25 01:18:01 UTC
Permalink
Post by Sebastian Kaliszewski
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny
jest jeszcze jakiś opis w ludzkim języku.
Przecież plik nagłówkowy nie jest od tego, żeby był specyfikacją, tylko od
tego, żeby był wyodrębnionym interfejsem!
Maciek mówi o specyfikacji.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
A Doxygenem, JavaDocem, KDocem czy czym tam jeszcze mając źródło i
odpowiednio soformatowany opis w ludzkim języku można wygenerować
specyfikację wygodną do poczyania, poklikania, wydrukowania i wzięcia
sobie "do poduszki".
No przecież w C++ to się właśnie robi. Ale to nie jest do tego, żeby mieć do
poczytania, tylko żeby mieć do użycia.
Do użycia jest to potrzebne kompilatorowi. A ten dużo wydajniej użyje
jakiegoś *.class, *.ppu, *.tpu, czy innego pliku binarnego.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
i niektóre języki poszły we wspieraniu tego rozdzielenia dużo dalej,
niż C++; im lepiej język rozdziela specyfikację od implementacji,
tym lepiej się nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
W jaki sposób na przykład?
Bo, poza #include, nie potrafię sobie wyobrazić, o co ci mogłoby tutaj
chodzić.
Kompilator Javy obejrzy sobie plik class i bedzie wiedział to co mu
potrzeba bez starty czasu na przelatywanie zagnieżdżonych includów,
preprocessing, parsowanie, itd...
Java parsuje dane źródło raz, a C++ pliki nagłówkowe magluje tyle razy
ile są includowane.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
O! To bardzo chętnie posłucham, jaką inną technikę rozwiązania tego problemu
mógłbyś zaproponować.
Zakładamy, że piszesz aplikację czasu rzeczywistego, każdy zasób kosztuje
straszne pieniądze, a przydział każdego z zasobów jest sprawą krytyczną. I to
na tyle krytyczną, że nieprzydzielenie zasobu może spowodować zagrożenie życia
i zdrowia ludzi.
Od różnych form deterministycznego określania życia obiektów (np. do MLi
wymyślono region inference), różnych deterministycznych GC, do zwykłego
powiadamiania obiektów o tym, że opuszczają zakres.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Dlaczego uważasz, że nie ma? Bo jakiś tam edytorek nie podpowiada
nazw funkcji w C++?
narzędzi *praktycznie* zrobić się nie daje (tak by były przy tym
niezawodne), szczególnie gdy mają być przenośne.
Wybacz, ale ten argument z przyczyn niemerytorycznych pominiemy.
Ale to jest powód jak najbardziej merytoryczny. Jest wręcz obrzydliwie
techniczny.
Post by Sektor van Skijlen
Słucham
dalej.
Post by Sebastian Kaliszewski
C++ jest natyle pokomplikowane, że do bardzo niedawna (5 lat po
ogłoszeniu standardu) zdecydowana większość kompilatorów tego języka
nie była w stanie go sparsować zgodnie ze standardem. A co tu mówić o
jakimś zautomatyzowanym refactoringu itp...
Ciekaw jestem, czy widziałeś, jak wyglądała Java "po pierwszym standardzie".
Parsować się dawała normalnie. Można było automatycznei okreslić gdzie
są klasy, metody, pola itd. W C++ w połączeniu z preprocesorem robi się
to ogólnie nierozwiązywalne (bo gdzies tam masz wywołanie makra, które
rozwija się w jakiś kawałek kodu w którym są różne wywołania, itd...).
Za to po kompilacji C++ widzi już tylko adresy, pod które musi skakać, i
z których pobierać/wysyłać dane. Java używa jeszcze ciągle parsowanego
przez JVM pseudokodu. 1 lub więcej rzędów wielkości chodzi to wolniej -
w końcu wykorzystamy te 16 procków w maszynie dostarczonej przez Suna ;)
Post by Sebastian Kaliszewski
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
A, jeśli chcę zrobić przenośny program w C++, który da się
zbuildowować na dziś powszechnie używanych biznesowo platrofmach i
zechcę użyć jakiś nieco bardziej zaawansowanych technik (szczególnie
w okolicach szablonów) to mam problem. Bo GCC 3.x (często wciąż
używany 3.2.x) wielu rzeczy nie połknie,
No, czego na przykład? Chodzi mi o przykład taki naprawdę "biznesowy". Przy
czym zwracam uwagę, że dobrze by było podeprzeć się w tym "alternatywnym"
rozwiązaniem w Javie.
Ot choćby ostatnio, template instancjonowany pewną biblioteczną funkcją
-- w GCC poszło, w DEC CXX poszło, na Sunie -- nie. Uparło się że nie
pójdzie i koniec. W końcu zrobiłem tak, że jest kompilacja warunkowa i
na Sunie pewnych rzeczy nie robię -- akurat nie jest to na rzeczonym
Sunie potzrebne, więc implementacja zostałą poprostu zubożona w tym
przypadku.
Post by Sektor van Skijlen
Post by Sebastian Kaliszewski
Durnieją debuggery (mają problem choćby z tym, że np. breakpoint
ustawiony na MyTemplate<int> nie jest breakpointem ustawionym na
MyTemplate<long>), głupieją proste generatory dokumentacji
(preprocessor i kompilacja warunkowa "rulez") -- co tu mówić o
nbardziej zaawansowanych narzędziach.
Maszyna Suna tylko Java łyka ;)
Post by Sebastian Kaliszewski
Post by Sektor van Skijlen
No cóż, faktem jest, że niektóre narzędzia nie wiedzą, że
__attribute__((packed)) to specjalna konstrukcja językowa związana z
rozszerzeniem kompilatora. Ale o ile pamiętam, można robić jakieś wyjątki na
takie konstrukcje.
Ale co kompilator to inne dodatki. W dodatku gdy masz kod przenośny tio
było nie było takie różne elementy się obmakrowuje. Obmakrowuje się też
często takie rzeczy jak logowanie w zależności od skonfigurowanego
poziomu logowania itd...
Mało obiektowe podejście. Ja bym taki ficzer dał jednak do klasy lub
chociażby jakiejś struktury.

[...]

Pozdrawiam Moneetor
--
I love SPAM(TM)...
...but hate spammers!!!
A..L.
2006-03-25 04:02:35 UTC
Permalink
Post by Moneetor
Za to po kompilacji C++ widzi już tylko adresy, pod które musi skakać, i
z których pobierać/wysyłać dane. Java używa jeszcze ciągle parsowanego
przez JVM pseudokodu. 1 lub więcej rzędów wielkości chodzi to wolniej -
w końcu wykorzystamy te 16 procków w maszynie dostarczonej przez Suna ;)
Panie Monter, gdzie Pan studiowal sofware engineering? Na
Uniwersytecie Robotniczym?... Przeciez Pan pisze wierutne bzury. Co
JVM "parsuje"?... Pan ma wiadomosci z czasow komputera Atari i
Meritum...

A.L.
Maciej Sobczak
2006-03-24 08:10:10 UTC
Permalink
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Popatrzmy na konkurencję.
1. Java w ogóle nie nadaje się do programowania czegokolwiek.
ROTFL!
No, mi też chce się śmiać.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak oddzielenia specyfikacji od implementacji
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny
jest jeszcze jakiś opis w ludzkim języku.
Komu? Kompilatorowi? Od kiedy to kompilatory potrzebują czegoś w ludzkim
języku?
Post by Sebastian Kaliszewski
Nie prawda. Mylisz konieczność z li tylko przydatnością.
Ja mogę mylić bo ja szary żuczek jestem, ale pomyśl o *intencjach*,
jakie przyświecały twórcom danego. Jest kilka języków, które rozdzielają
specyfikację od implementacji - i te języki były od początku tworzone
dokładnie z myślą o tworzeniu dużych systemów. Dotyczy to zarówno Ady
jak i C++. To, że ktoś będzie w tym pisał HelloWorldy nigdy nie było
głównym celem tworzenia tych języków. Dopiero później zaczęto się
zastanawiać, co zrobić, żeby ułatwić początkującym naukę.

Natomiast Java była od początku stworzona z myślą o lodówkach i
mikrofalówkach i jej rdzeń to dość dobrze odzwierciedla. A to, że potem
ktoś wpadł na pomysł wypromowania Javy w środowiskach serwerowych to już
inny temat.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
i niektóre języki poszły we wspieraniu tego rozdzielenia dużo dalej,
niż C++; im lepiej język rozdziela specyfikację od implementacji, tym
lepiej się nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
Nie rozumiem. C++ ma ułomny, ale działający mechanizm w postaci plików
nagłówkowych - ten mechanizm opera się na preprocesorze. Java nie ma
żadnego mechanizmu, który by pozwalał na wyodrębnienie specyfikacji i
*kontraktów*, które związują ze sobą dostawcę i odbiorcę danej
funkcjonalności. Na jakiej zasadzie Java ma się tu lepiej?
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to
za mało. [...] bez tego nie ma sensu mówić o
inżynierii programowania.
ROTFLMAO! Dlaczegoż więc tyle pozycji właśnie z inżynierii programowania
jako głównym językiem posługuje się Javą?
Naprawdę nie wiesz, czy udajesz?
Ćwiczenie pomocnicze:

Rzucamy na rynek dwie książki:
A. "Grafika 3D w Javie"
B. "Grafika 3D w Adzie"

Ten sam profil, ta sama cena. Nawet tytył ma tyle samo liter. :)

Pytanie 1:

Jeden z tych języków nie ma przeciążania operatorów, co czyni go
upośledzonym w temacie naturalnego wyrażenia częstych operacji w
dziedzinie grafiki 3D.
O którym mowa?

Pytanie 2:

Jedna z tych książek będzie się sprzedawać jak ciepłe rogale a drugą
kupi tylko autor i jego rodzina.
Która książka sprzeda się lepiej?

Odpowiedzi do pytań: 1 - A, 2 - A.

Czy już wiesz dlaczego "tyle pozycji właśnie z inżynierii programowania
jako głównym językiem posługuje się Javą?"
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
Podaj inne możliwe rozwiązania w kontekście Javy.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję.
Cóż to nie używacie ani *nixów ani Wind?
LynxOS. Javy też tam nie ma, jakby ktoś pytał.

Java natomiast działa i jest powszechnie wykorzystywana na stacjach
roboczych. System operacyjny to odmiana Scientific Linux. Ale C# tam nie ma.
Ze wszystkich komputerów, które tu są, C# działa tylko na tych z Windowsem.

Nie interesuje mnie, że sobie mogę coś gdzieś doinstalować. Doinstalować
sobie mogę w domu. Środowisko produkcyjne jest definiowane przez innych
ludzi, zresztą też nie samodzielnie, tylko w uzgodnieniu z innymi
współpracującymi instytutami - w każdym razie środowisko produkcyjne
jest czymś, co ja traktuję jako sytuację zastaną, bez możliwości
modyfikacji. I to dla mnie wyznacza zakres przenośności czegokolwiek.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Każdy poważniejszy rozproszony system jest oparty o CORBA.
ROTFL!
Mało tych "poważniejszych" systemów widać widziałeś...
Faktycznie, wykazałem się sporym rozmachem w tym zdaniu.
Uściślijmy: W mojej dziedzinie większość poważnych systemów
rozproszonych jest opartych o CORBA.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
Właśnie dla tego jest po prostu kosztowny w stosowaniu. I tam gdzie nie
jest niezbędny można się go pozbyć.
A czy ja mówię, że nie? C++ jest najbardziej użytecznym językiem - ale
to nie wyklucza użycia języków, które go uzupełniają. Języki skryptowe?
Proszę bardzo, już pisałem, że one są do czego innego - dlatego są
dobrym uzupełnieniem.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
A..L.
2006-03-24 14:02:15 UTC
Permalink
On Fri, 24 Mar 2006 09:10:10 +0100, Maciej Sobczak
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
Podaj inne możliwe rozwiązania w kontekście Javy.
Pan jest niekompetentny, Panei Sobczak. Neich Pan pzreczyta
specyfikacje Real Time Java i troche pogogluje, to sie Pan przekona
ze a) specyfikacja zawiera mechanizm do deterministycznej gospodarki
pamiecia b) Takie implementacje jak Jamaica oferuje deterministyczny
garbage collector.

Bottom line zas jest taki, ze w "normalnych" aplikacjach
deterministyczna destrukcja jest na grzyba potzrebna, a jak jest
gdzies potzrebna, to programiste ktoremu jest potzrebna nalezy
natychmiast wyrzucic z pracy.

Jeszcze raz proponuje: [pneiwaz Panskie "uczone" uwagi na temat Javy
tylko generuja szum, proponuje aby Pan pozostal przy C++.

Z ubolewaniem musze zaznaczyc ze nei moge sie ustosunkowac do
wszystkich Panskich wypowiedzi i w calosci, albowiem pisze z pracy.
I nie mam czasu na pisanie esejow.

A.L.

P.S. To co Pan pisze o Adzie tez smeiszne.
Maciej Sobczak
2006-03-24 15:48:19 UTC
Permalink
Post by A..L.
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
Podaj inne możliwe rozwiązania w kontekście Javy.
Pan jest niekompetentny, Panei Sobczak. Neich Pan pzreczyta
specyfikacje Real Time Java i troche pogogluje, to sie Pan przekona
ze a) specyfikacja zawiera mechanizm do deterministycznej gospodarki
pamiecia b) Takie implementacje jak Jamaica oferuje deterministyczny
garbage collector.
W jakim stopniu deterministyczny? Czy mam gwarancję, że zdefiniowane
przeze mnie akcje zostaną wykonane *zanim* coś innego się stanie?

{
MyClass m = new MyClass(...);

// (1)
}
// (2)

Proszę sobie wyobrazić, że w punktach 1 i 2 są wykonywane pewne akcje.
Czy mam *gwarancję*, że destruktor (lub inaczej nazwana część kodu, np.
finalizator) dla obiektu, którego referencją jest m, wykona się *po*
akcjach z punktu 1, ale *przed* akcjami z punktu 2?

(Załóżmy, że w międzyczasie nie powstaje kopia referencji do tego obiektu.)

Jeżeli faktycznie mam taką gwarancję, to jestem tym bardzo
usatysfakcjonowany, ale niestety Real Time Java to najwyraźniej nie jest
to samo co Java, skoro się inaczej nazywa, prawda? Czy można w tym
uruchomić np. Eclipse? Albo Together? Albo jakąkolwiek inną aplikację,
która wymaga JVM? Czy można to podpiąć pod serwer Oracla, żeby wykonywać
tam procedury składowane napisane w Javie? I tak dalej. Innymi słowy -
czy mogę wywalić ze swojego komputera JVM 1.4 i zainstalować zamiast
tego Real Time Java? Pewnie nie, skoro pomimo tej niewątpliwej zalety,
jaką Pan opisał, nie jest to główny produkt na stronach Suna.

Natomiast jeżeli wspomnianej wyżej gwarancji nie mam, to musieliśmy się
nie zrozumieć w kwestii tego, co to jest deterministyczna destrukcja.
Post by A..L.
Bottom line zas jest taki, ze w "normalnych" aplikacjach
deterministyczna destrukcja jest na grzyba potzrebna, a jak jest
gdzies potzrebna, to programiste ktoremu jest potzrebna nalezy
natychmiast wyrzucic z pracy.
Właśnie jeden z moich kolegów dostał do poprawienia większy kawałek kodu
w Javie, który "czasami nie zamyka połączeń do bazy danych".
Kogo trzeba wyrzucić z pracy?
Post by A..L.
Jeszcze raz proponuje: [pneiwaz Panskie "uczone" uwagi na temat Javy
tylko generuja szum, proponuje aby Pan pozostal przy C++.
No przecież napisałem, że Java nie jest dla mnie konkurencją dla C++.
Chyba jasne jest więc, że mając do wyboru te dwa języki, zostanę przy
C++. :|
Post by A..L.
P.S. To co Pan pisze o Adzie tez smeiszne.
Nareszcie znalazł się ktoś, kto chce porozmawiać o Adzie. :)
Które z moich wypowiedzi nt. Ady wydały się Panu śmieszne?
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sebastian Kaliszewski
2006-03-24 17:58:17 UTC
Permalink
Post by A..L.
Bottom line zas jest taki, ze w "normalnych" aplikacjach
deterministyczna destrukcja jest na grzyba potzrebna, a jak jest
gdzies potzrebna, to programiste ktoremu jest potzrebna nalezy
natychmiast wyrzucic z pracy.
Akurat nie tyle deterministyczna destrukcja, co jakikolwiek mechanizm
powiadamiania obiektów o opuszczaniu zakresu (wywołanie jakiejś metody, nie
koniecznie akurat destrukcja) pozwala na uproszczenie kodu i pozbycie się
potencjalnie błędogennych sytuacji.

zamiast:

{
MyResuorceHandle h = new MyResourceHandle();

try
{
h.open();
DoSomething(h); // to może rzucić wyjątek
}
finally
{
h.close();
}
}

coś takiego:

{
MyAutoClosingResourceHandle h = new MyAutoClosingResourceHandle();
h.open();
DoSomething(h); // to może rzucić wyjątek
} // h zamknie się samo przy wyjściu z zakresu


To drugie jest wygodniejsze o tyle, że nie trzeba się martwić o jawne
zamykanie w finally, nie ma problemów, że jakaś sierota doda gdzieś w środku
return (bo mu tak "wyszło") itd...


pzdr
--
Sebastian Kaliszewski
.
2006-03-24 20:11:16 UTC
Permalink
[...]
Post by Sebastian Kaliszewski
{
MyResuorceHandle h = new MyResourceHandle();
try
{
h.open();
DoSomething(h); // to może rzucić wyjątek
}
finally
{
h.close();
}
}
{
MyAutoClosingResourceHandle h = new MyAutoClosingResourceHandle();
h.open();
DoSomething(h); // to może rzucić wyjątek
} // h zamknie się samo przy wyjściu z zakresu
To drugie jest wygodniejsze o tyle, że nie trzeba się martwić o jawne
zamykanie w finally, nie ma problemów, że jakaś sierota doda gdzieś w
środku return (bo mu tak "wyszło") itd...
Return w srodku w niczym nie zaszkodzi.

M.
Sebastian Kaliszewski
2006-03-24 17:42:32 UTC
Permalink
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Popatrzmy na konkurencję.
1. Java w ogóle nie nadaje się do programowania czegokolwiek.
ROTFL!
No, mi też chce się śmiać.
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak oddzielenia specyfikacji od implementacji
Plik nagłówkowy jest kiepską specyfikacją. Bardzo kiepską! Potrzebny
jest jeszcze jakiś opis w ludzkim języku.
Komu? Kompilatorowi? Od kiedy to kompilatory potrzebują czegoś w ludzkim
języku?
Kompilatorowi plik nagłówkowy jest też po nic. To wyjątkowo nieefektywny
sposób przekazywania specyfikacji interfejsu do programu.

Kompilatorowi dużo lepiej przypasuje zapis zwięzły, binarny, powioązany
bezpośrednio z implementacją. Właśnie tak robi to praktycznie wszystko
używane w przemyśle za wyjątkiem C i C++.

W szczególności tak robi to Java, C#, Object Pascal (Delphi a także FPC) itd...


Natomiast dla człowieka i tak taki nagłówek C++ jest do bani...

W czasach kiedy Ciebie nie było na świecie a ja sikałem w pieluchy mądrzy
ludzie zauważyli, że odpowiednio pełna i precyzyjna specyfikacja zapisana
formalnie sama w sobie jest programem. Tak narodziły się ML-e.

Jak widać nie są jakoś super popularne... Jak wskazuje doświadczenie, dla
człowieka wygodna specyfikacja to połączenie zwykle kilku upraszczających
prespektyw na opisywany problem. Stąd używa się UMLi, opisów słownych
(często o ujdenoliconym formacie), itd.
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
i niektóre języki poszły we wspieraniu tego rozdzielenia dużo dalej,
niż C++; im lepiej język rozdziela specyfikację od implementacji, tym
lepiej się nadaje do poważnych projektów).
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
Nie rozumiem. C++ ma ułomny, ale działający mechanizm w postaci plików
nagłówkowych - ten mechanizm opera się na preprocesorze.
Przy szablonach i braku export template ten mechanizm nie jest nic wart.
Post by Maciej Sobczak
Java nie ma
żadnego mechanizmu, który by pozwalał na wyodrębnienie specyfikacji i
*kontraktów*, które związują ze sobą dostawcę i odbiorcę danej
funkcjonalności. Na jakiej zasadzie Java ma się tu lepiej?
Bo kompilator woli obejrzeć sobie pliki *.class a nie pliki *.h - -bo mu to
po prostu szybciej idzie.
A człowiekowi i tak ganc-pomada i wsio-ryba. Człowiek woli słowo w języku
ludzkim (albo w piśmie obrazkowym) a nie komputerowym.
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to
za mało. [...] bez tego nie ma sensu mówić o inżynierii programowania.
ROTFLMAO! Dlaczegoż więc tyle pozycji właśnie z inżynierii
programowania jako głównym językiem posługuje się Javą?
Naprawdę nie wiesz, czy udajesz?
Ja wiem. Bo to co ty powiększasz do jakiś strasznych wad jest po prostu mało
istotne.

[ciach]
Post by Maciej Sobczak
Czy już wiesz dlaczego "tyle pozycji właśnie z inżynierii programowania
jako głównym językiem posługuje się Javą?"
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
Podaj inne możliwe rozwiązania w kontekście Javy.
Dlaczego w kontekscie akurat Javy?
BTW. A.L. podał i myślę, że wystarczy
Post by Maciej Sobczak
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję.
Cóż to nie używacie ani *nixów ani Wind?
LynxOS. Javy też tam nie ma, jakby ktoś pytał.
Java natomiast działa i jest powszechnie wykorzystywana na stacjach
roboczych. System operacyjny to odmiana Scientific Linux. Ale C# tam nie ma.
Ze wszystkich komputerów, które tu są, C# działa tylko na tych z Windowsem.
Nie interesuje mnie, że sobie mogę coś gdzieś doinstalować. Doinstalować
sobie mogę w domu. Środowisko produkcyjne jest definiowane przez innych
ludzi, zresztą też nie samodzielnie, tylko w uzgodnieniu z innymi
współpracującymi instytutami - w każdym razie środowisko produkcyjne
jest czymś, co ja traktuję jako sytuację zastaną, bez możliwości
modyfikacji. I to dla mnie wyznacza zakres przenośności czegokolwiek.
Tylko co to ma wspólnego z tematem dyskucji. To, że w twojej konkretnej
sytuacji nie można użyć jakiegoś języka?

To i są sytuacje gdzie nie wolno użyc C, albo wszystko musi być w Javie,
albo jeszcze nie wiadomo co...
Post by Maciej Sobczak
A czy ja mówię, że nie? C++ jest najbardziej użytecznym językiem - ale
to nie wyklucza użycia języków, które go uzupełniają. Języki skryptowe?
Proszę bardzo, już pisałem, że one są do czego innego - dlatego są
dobrym uzupełnieniem.
Ja mówię o sytuacji odwrotnej -- to C++ jest uzupełnieniem. Tak jak dawniej
czasem stosowało się w C wstawki assemblerowe, tak C++ stanowi tylko wstawki.

pzdr
--
Sebastian Kaliszewski
Moneetor
2006-03-25 00:53:16 UTC
Permalink
[...]
Post by Sebastian Kaliszewski
I Java ma się tu lepiej :-P niż C++. C++ ma prepocesor który potrafi
skutecznie utrudnić wydzielenie specyfikacji od implementacji.
LOL. Skoro już pokazujemy kolce róznych języków, to ja wspomnę choćby o
wykastrowanym dziedziczeniu w Java. Dziedziczenie w java tylko
jednostopniowe bo.. Sun uważa że wielokrotne dziedziczenie jest be - dla
mnie zupełnie niezrozumiałe i niestrawne.
[...]
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Mylisz jajko z kurą. Deterministyczna destrukcja to tylko jedno z
możliwych rozwiązań problemu.
Na pewno lepsze niż czekanie na to, aż "działający w tle odśmiecacz"
posprząta ten bajzel w pamięci spowodowany aplikacjami pisanymi w Java.
Czasami szybciej doczekasz się na Longhorna niż na posprzątanie RAMu
przez odśmiecacz.
[...]
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Każdy poważniejszy rozproszony system jest oparty o CORBA.
ROTFL!
Mało tych "poważniejszych" systemów widać widziałeś...
[ciach]
Post by Maciej Sobczak
Post by Sektor van Skijlen
Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Oczywiście, że stać. Lepiej - takie technologie są.
Kulawe
Post by Maciej Sobczak
Dlaczego uważasz, że nie ma? Bo jakiś tam edytorek nie podpowiada nazw
funkcji w C++?
narzędzi *praktycznie* zrobić się nie daje (tak by były przy tym
niezawodne), szczególnie gdy mają być przenośne.
C++ jest natyle pokomplikowane, że do bardzo niedawna (5 lat po
ogłoszeniu standardu) zdecydowana większość kompilatorów tego języka nie
była w stanie go sparsować zgodnie ze standardem. A co tu mówić o jakimś
zautomatyzowanym refactoringu itp...
Do Javy takie rzeczy po prostu robi się łatwiej.
Bo Java nie jest nigdy tak do końca kompilowana. Aplikacja w java to ani
natywny kod, ani w pełni język interpretowany w stylu Basic. Stąd ta
"prostota" czasem nawet do bólu.
Post by Sebastian Kaliszewski
A, jeśli chcę zrobić przenośny program w C++, który da się zbuildowować
na dziś powszechnie używanych biznesowo platrofmach i zechcę użyć jakiś
nieco bardziej zaawansowanych technik (szczególnie w okolicach
szablonów) to mam problem. Bo GCC 3.x (często wciąż używany 3.2.x) wielu
rzeczy nie połknie, bo MSVC 7.1 ma swoje własne humory, nie mówiąc już o
kompilatorach na Uniksy -- te "z zasady" mają na temat różnych
konstrukcji własne zdanie.
A wydawało mi się że GCC już jest standardem na Uniksy.

[...]
Post by Sebastian Kaliszewski
Post by Maciej Sobczak
Post by Sektor van Skijlen
Może to też kwestia tego, że C++ jest dla niektórych za trudny?
To nie jest problem. Ludzie powszechnie i swobodnie piszą w C++ prawie
w ogóle go nie znając, więc poziom trudności nie jest tu przeszkodą.
Jest.
To że piszą w nim nie znając go jest przyczyną całkiem częstych, całkiem
"fajnych" bugów (A bo dla mnie było oczywioste że to musi tak działać)
Aplikację w Java też da się s...c
--
I love SPAM(TM)...
...but hate spammers!!!
A..L.
2006-03-25 01:58:14 UTC
Permalink
Post by Moneetor
Na pewno lepsze niż czekanie na to, aż "działający w tle odśmiecacz"
posprząta ten bajzel w pamięci spowodowany aplikacjami pisanymi w Java.
Czasami szybciej doczekasz się na Longhorna niż na posprzątanie RAMu
przez odśmiecacz.
[...]
Panie Monteor, gdzie Pan pobieral nauki software engineering?... Na
Uniwersytecie Robotniczym?...

Dyc to co Pan pisze to bzdury wierutne...

A.L.
Sektor van Skijlen
2006-03-23 17:24:52 UTC
Permalink
Post by Maciej Sobczak
Hehe - pojechałeś z nutką nostalgiczną, więc też odpiszę "z głebi duszy". :)
Ha! Wiedziałem, że na ciebie mogę liczyć :)
Post by Maciej Sobczak
Popatrzmy na konkurencję.
1. Java w ogóle nie nadaje się do programowania czegokolwiek.
Tyle to zauważyłem. :)
Post by Maciej Sobczak
- Brak oddzielenia specyfikacji od implementacji (czyli po ludzku: brak
odpowiednika plików nagłówkowych - wiem, wiem, niektórym się wydaje, że
takie rozdzielenie to główna wada C++, ale nie dość, że to jest zaleta,
to w dodatku jest to konieczność w większych projektach i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
No właśnie widzisz ja mam na ten temat dylemat.

Z jednej strony, dla mnie jest to wygodne, że można rozdzielić pliki h od
plików cpp z implementacją. Co więcej, często w swoich programach nie miałem w
ogóle czegoś takiego, co często widuję w projektach C++: plik *.h i
odpowiadający mu plik *.cpp. U mnie w plikach *.h są klasy lub odpowiedni
zestaw klas, a funkcje stanowiące implementacje metod są rozsiane po zupełnie
innych plikach. Nawet zdarza się, że metody tej samej klasy potrafią znajdować
się w kilku różnych plikach *.cpp. To wynika stąd, że implementacja metod leży
tam, gdzie najbliżej znajdują się zasoby, z jakich implementacja danej metody
korzysta oraz do jakiej kategorii kwalifikuje się zestaw czynności
wykonywanych przez implementację.

Dla mnie po prostu związek interfejsu i implementacji to jedynie sygnatura i
przynależność. Nic więcej. A akcje wykonywane przez implementację mogą być już
kwalifikowane wedle zupełnie innych kryteriów.

W przeglądaniu kodu to nie przeszkadza. Dziś kiedy mamy od cholery narzędzi
indeksujących, można sobie rozrzucać kod po plikach jak się komuś podoba.

Zresztą właśnie to było jednym z powodów, dla których od początku
nienawidziłem Pascala: to wymuszane uporządkowanie, które ten język
wprowadzał, było dla mnie straszne, bo ja miałem zupełnie inną koncepcję
uporządkowania poszczególnych elementów kodu, niż wymuszała to na mnie
składnia języka - wybitnie zresztą robiona "pod kompilator", a nie pod
programistę.
Post by Maciej Sobczak
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to za
mało.
Zdecydowanie.
Post by Maciej Sobczak
W wersji dla ubogich potrzebne jest coś, co ma np. Ada w postaci
słów kluczowych type i subtype, w wersji rozbudowanej potrzebne jest
przeciążanie operatorów i wykorzystanie zewnętrznych opisów dziedzin i
generatorów typów albo wbudowanego metajęzyka do opisu dziedzin. W
porządnych językach to się robi naturalnie, w Javie nie da się tego
zrobić wcale a bez tego nie ma sensu mówić o inżynierii programowania.
Ale widzisz, tu właśnie następuje kwestia "jakości programistów". Z jednej
strony, oczywiście, wiem na ile C++ nadaje się do poszczególnych rzeczy. Ale z
drugiej, czytam sporo opinii, w tym rzeczowych, o tym, jak to np. w Javie
takie-a-takie rzeczy robi się prościej (oczywiście twierdzenia, że zrobienie
tego samego w C++ jest dużo trudniejsze trzeba traktować z drobnym
przymrużeniem oka), jak to wybór Javy zaowocował lepszymi wynikami (po
prawdzie, gdyby wybrali dowolne narzędzie, a widmo bankructwa zajrzało im w
oczy, to w tym dowolnym narzędziu też by odnieśli sukces, a porażki nikt by
nie nagłośnił). Więc albo te rzeczy w niektórych dziedzinach nie są potrzebne,
albo można się bez nich obejść, albo... nie wiem.

Nie mam miarodajnych danych, żeby to sprawdzić. Musiałbym spróbować taki sam
średni projekt zrobić w C++ i w Javie. A właściwie to w Javie dać najlepiej
komuś, kto na niej zjadł zęby.
Post by Maciej Sobczak
- Brak deterministycznej destrukcji. Finally jest do bani.
Zgadza się. W projekcie, w którym uczestniczę, nie wyobrażam sobie
zastosowania JAKIEGOKOLWIEK języka, który nie posiada deterministycznej
destrukcji. Operuje to zasobami, których zwolnienie musi nastąpić NATYCHMIAST,
bo ilość zasobów jest ograniczona, klient za każdy taki zasób jest ostro
krojony po kieszeni, więc ewentualność, że jakiś zasób przez jakiś czas
pozostanie w stanie zawieszonym, jest całkowicie wykluczona.

W Javie oczywiście można prowadzić deterministyczną destrukcję. Taką samą
metodą jak w C. I tak jest prowadzona. Jak mi ktoś spróbuje na przykładzie
tego wyjaśnić, że w Javie pisze się prościej, to bym go chyba wyśmiał...
Post by Maciej Sobczak
Statystycznie, okres "hurraaaa!" na Javę chyba się kończy i nowe
projekty w Javie nie są już tak radośnie otwierane, jak to było swego
czasu.
No ale właśnie - czy to znaczy, że się je otwiera, ale jednak bez przekonania?
Czy też może nie zauważa się tendencji do "gwałtownego przechodzenia na Javę",
jak to niektórzy rozgłaszają?
Post by Maciej Sobczak
Być może właśnie dlatego, że ludzie zaczynają sobie uświadamiać
braki tego języka. Polecam posty Jamesa Kanze na comp.lang.c++.moderated
na ten temat - to jest gość, który ma w tym biznesie większe
doświadczenie, niż my wszyscy razem i jego komentarze w tym temacie są
dość ciekawe.
Aż znajdę i poczytam. Przyda mi się jakaś odtrutka na tą kampanię reklamową
Javy.
Post by Maciej Sobczak
2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję.
Cóż, trzeba coś doinstalować. Dokładnie tak samo, jak w przypadku Javy. W
nowych windowsach to pewnie będą to instalować od razu jako część systemu.
Post by Maciej Sobczak
To jest język na jedną tylko
platformę tak samo jak swego czasu był nim VB i będzie istniał tylko tak
długo, jak długo M$ będzie widział w tym swój biznesowy cel. Nie jest to
platforma, którą możnaby wziąć pod uwagę planując jakiś większy projekt.
Co innego aplikacje desktopowe na Windowsa - i faktycznie,
najprawdopodobniej C# zdominuje ten segment rynku (co nie znaczy, że się
w tym segmencie cokolwiek poprawi).
No nie wiem. A mono, pnet, dotgnu? Coś M$ słabo widzi ten swój biznesowy cel.
Post by Maciej Sobczak
3. Języki skryptowe nie są konkurencją dla C++. Po prostu - służą do
czego innego.
(No i należy pamiętać, że języki skryptowe dzielą się na Tcl i resztę,
ale my się tutaj tym nie zajmujemy. ;) )
I za to cie, kurde, lubię :)
Post by Maciej Sobczak
4. Języki funkcjonalne używa Qrczak. ;)
I jeszcze paru gości, którzy (słusznie) uważają, że warto je znać dla
poszerzenia swojego warsztatu, ale dla których i tak głównym nurtem jest
coś innego.
Zgadza się. Ale ja pisałem o "realnych zagrożeniach" :)
Post by Maciej Sobczak
Post by Sektor van Skijlen
Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych systemach
czasu rzeczywistego, nie wyobrażam sobie zastąpienia go czymkolwiek innym.
Ada. Ale trzeba wziąć pod uwagę ten samonapędzający się mechanizm.
No tak. Ale właśnie C++ umiał skorzystać z samonapędzającego się mechanizmu
(zresztą Java i C# tak samo), a Ada nie (podobnie jak Eiffel).

Nikt się nie będzie uczył Ady, bo nikt w tym nie pisze, a nikt w tym nie
pisze, bo nikt nie umie, a nikt nie umie, bo nikt się nie uczył. Tak można to
określić najkrócej. :) To jest takie koło zamachowe. Jak ktoś go nie zamacha,
to samo z siebie się nie będzie kręcić.

Mnie tak właśnie dawnymi czasy kumpel zachęcał do nauki języka C: "teraz
wszyscy w tym piszą". Natomiast jak się dowiedziałem o języku C++, to za
cholere sobie nie przypomnę. Pamiętam jednak, że przez parę dni łaziłem po
księgarniach usiłując wybrać jakąś książkę do nauki, w międzyczasie też
konsultowałem się ze znajomymi. Książek o C++ było zresztą zdecydowanie
więcej. Może dlatego ;)
Post by Maciej Sobczak
Ten mechanizm dotyczy każdego języka, który w danej dziedzinie mógłby
zostać uznany za "lepszy" od C++. Wszystkie takie języki skupiają się w
lokalnych grupach programistycznych, które w odizolowaniu od reszty
świata piszą sobie kolejne wersje czegoś tam, ale w miarę naturalnego
odchodzenia ludzi z projektu, takie lokalne grupy programistyczne po
prostu wymierają.
W użyciu pozostają tylko te technologie, dla których ten samonapędzający
się mechanizm ustabilizował się na pewnym niezerowym poziomie (są
ludzie, książki, biblioteki do wykorzystania, istniejący kod do
poprawiania, itd.).
Jestem w tym wszystkim ciekaw, jak ustabilizował się język C. Zakładam, że
długi czas ludzie mieli opory przed językami wysokiego poziomu, a C jest w
końcu bardzo bliski asemblera. Potem poszło z górki: napisano w tym systemy
operacyjne, tworzono oprogramowanie, które biło na głowę wszystko przez swoją
wydajność (a nie zapominajmy, jak bardzo się to wtedy liczyło).

Na popularności C pojechała reszta. Te języki, które próbowały to robić w
oderwaniu od języka C, zeszły w niszę.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo.
Trochę bardzo. CORBA jest standardem w tej dziedzinie.
No, ja mam o tyle dobrze, że na grupach dyskusyjnych mogę się kompromitować
niewiedzą :)
Post by Maciej Sobczak
I to do tego
stopnia, że większość ludzi nawet nie zdaje sobie sprawy z tego, w ilu
miejscach jest obecna. Piszę ten post komputerze ze środowiskiem GNOME.
Ble... :)
Z drugiej strony, KDE też ma swój DCOP.
Post by Maciej Sobczak
Wszystko co robię to jakiś komunikat CORBA, bo CORBA jest podstawą GNOME
tak samo, jak COM jest (był?) podstawą Windowsa. Wiedziałeś o tym? :)
Owszem. Zresztą COM to też taka mniej-więcej korba. A jak z GNOME odrzucić GNU
i Environment, to wychodzi NOM. Trochę podobne do COM :)
Post by Maciej Sobczak
Każdy poważniejszy rozproszony system jest oparty o CORBA. Nawet goście
od Ady powszechnie olali tą część języka, która jest odpowiedzialna za
systemy rozproszone (tak, mają to jako część standardu!) i używają CORBA
bez żadnego żalu.
I to działa.
Wiem. To co w takim razie lepszego w tych wszystkich RMI, Beans, EJB i innych
pierdołach?
Post by Maciej Sobczak
Post by Sektor van Skijlen
A przynajmniej nie słyszałem o niczym powalającym.
CORBA nie powala. CORBA działa. :)
No dobrze, ale na ile wygodne jest jej używanie z opziomu C++ w porównaniu do
Javy?

Przyznaję, nie używałem korby. Uzywałem COM-a i mam po nim naprawdę paskudne
wrażenia.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Miałem krótki
kontakt z projektem, w którym goście przepisywali na Javę coś, co działało na
C++ z COM-em. W takim, chociażby, przypadku, muszę przyznać, że owszem, COM
jest -delikatnie mówiąc- "nienajlepszą" technologią, ale lepszej o tym samym
zastosowaniu do C++ nie wymyślono, a do Javy tak.
Ale wiesz o tym, że J2EE to taka przemalowana CORBA?
Domyślałem się.
Nb. CORBA pozwala na dostęp do interfejsu z poziomu różnych języków, w tym
Javy.
Post by Maciej Sobczak
Nawet protokół na niskim poziomie to IIOP. Zdaje się, że można nawet
komunikować się z tymi ichnimi fasolkami używając normalnych interfejsów
CORBA (ale nie znam szczegółów).
Nieźle. Mam wrażenie, że coś podobnego zrobił wpkontakt. Niby jabber, ale ani
się nie połączysz innym komunikatorem, ani komunikatora Spik nie użyjesz do
innego dowolnego jabbera.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Problem polega zatem na tym,
że o ile do Javy opracowano mnóstwo [...]
I tu jest sedno sprawy. Java nie jest standardem (podobnie, jak .NET) a
tylko takie rzeczy opłaca się reklamować. Widziałeś kiedyś, żeby ktoś
reklamował TCP/IP? Nie, bo to jest standard. A może HTTP? Też nie, bo to
też jest standard. Java nie jest standardem i dlatego dla Javy istnieje
mechanizm generujący zwrot z inwestycji w reklamę. Dlatego komuś opłaca
się reklamować Javę, .NET i inne tego typu rzeczy, natomiast nikomu nie
opłaca się reklamować TCP/IP, HTTP, C++, CORBA czy Ada. I to jest
właśnie mechanizm, który stoi za różnicą w postrzegalnej widoczności C++
vs. Java.
No dobrze, zgadzam się. Ale czy to w takim razie oznacza, że nie rejestrowanie
Javy jako standard było korzystnym posunięciem biznesowym?

Zresztą, Java jest standardem, w pewnym sensie. W pewnym sensie, bo łapę na
standardzie trzyma Sun.

Ale wiesz, różnica w kwestii rozreklamowania to jedno, ale kwestia
popularności jest osobną sprawą. Niezbyt mi się chce wierzyć w to, że reklama
Javy jest skierowana do programistów.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Mimo swoich
właściwości, wciąż wychodzi na to, że C++ co najwyżej powoli zastępuje język
C [kolejność zdania normalna: podmiot-orzeczenie-dopełnienie! :)], a do
pisania dużych aplikacji - być może, bo jak mówię statystyk nie znam -
przestaje się go stosować.
Z tego co widzę, to nie jest to prawda.
No, mam nadzieję :). Ale czy jesteś w stanie wskazać jakieś źródło, które by
wskazywało "pokrycie rynku przez dany język programowania"?
Post by Maciej Sobczak
Post by Sektor van Skijlen
Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Oczywiście, że stać. Lepiej - takie technologie są. Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
Oj, nie o to chodzi :). Czy C++ posiada równie wygodne w używaniu biblioteki
do tych wszystkich rzeczy, do których powszechnie wykorzystuje się Javę?
Jedyne, co mogę powiedzieć na pewno, to że C++ posiada ogromne możliwości do
tworzenia takich bibliotek i to o niebo wygodniejszych od bibliotek w Javie.
Przecież wystarczy porównać Javowe listenery i C++-owy mechanizm sygnałów i
slotów, żeby nie mieć najmniejszych wątpliwości. Ale czy są, to osobna sprawa.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Czy dodanie odśmiecacza w nowym standardzie coś tu zmieni? Oczywiście, że nie
zmieni.
Dokładnie, nic się nie zmieni.
Nadal C++ będzie najbardziej użyteczny. :)
No, co najwyżej będzie można zamknąć gębę różnym krytykantom. Owszem, jest,
nikt go co prawda nie stosuje, ale jest, przyczepić się nie można.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Może to też kwestia tego, że C++ jest dla niektórych za trudny?
To nie jest problem. Ludzie powszechnie i swobodnie piszą w C++ prawie w
ogóle go nie znając, więc poziom trudności nie jest tu przeszkodą.
I tu mnie właśnie ciekawi, jak podobna sprawa przedstawia się w przypadku
Javy.
Post by Maciej Sobczak
Post by Sektor van Skijlen
Kwestię arytmetyki
wskaźników to może olejmy, bo tego argumentu nie można traktować poważnie.
"Some people for some reason are born without the part of brain which is
responsible for pointers."
Czytałem. To była zresztą jedna z inspiracji.
Post by Maciej Sobczak
Oczywiście, że to nie jest poważny argument. Można napisać dowolnie duży
system w C++ bez gołych wskaźników i bez ich arytmetyki.
No tak, ale czy się pisze? Czy wszyscy wiedzą, jak pisać, żeby tak wyszło? Czy
ludzie w ogóle wiedzą, jak pisać w C++, żeby pisanie było co najmniej tak
wygodne, jak w Javie?
Post by Maciej Sobczak
Post by Sektor van Skijlen
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
Ależ mnie nie chodzi, by C++ w jakikolwiek sposób ograniczać - sam bym z niego
zrezygnował, gdyby się coś takiego stało. Chodzi o to, że może należałoby
wypracować jakieś ograniczone reguły sposobu używania C++, tak żeby to się
jednak okazało wygodne? Ograniczone, to znaczy nie stosując jawnego
zarządzania obiektami, nie stosując niskopoziomowych sztuczek itd.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Maciej Sobczak
2006-03-24 09:08:12 UTC
Permalink
Post by Sektor van Skijlen
Post by Maciej Sobczak
- Brak oddzielenia specyfikacji od implementacji (czyli po ludzku: brak
odpowiednika plików nagłówkowych - wiem, wiem, niektórym się wydaje, że
takie rozdzielenie to główna wada C++, ale nie dość, że to jest zaleta,
to w dodatku jest to konieczność w większych projektach i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
No właśnie widzisz ja mam na ten temat dylemat.
Dla mnie po prostu związek interfejsu i implementacji to jedynie sygnatura i
przynależność. Nic więcej.
Dodaj jeszcze kontrakty dotyczące przekazywanych wartości.

Przykład praktyczny:

// base.h
class Base
{
public:
int fun(const SomeClass &sc)
{
int result = do_fun(sc);
assert(result >= -100 && result <= 100);
return result;
}

private:
virtual int do_fun(const SomeClass &sc) = 0;
};

Ten plik definiuje specyfikację pewnego interfejsu, z dwoma ważnymi
kontraktami:
1. Specyfikacja obiecuje klientom interfejsu, że nie zmodyfikuje
podanego argumentu.
2. Specyfikacja obiecuje klientom, że dostaną wartość z okerślonego
przedziału.

Ten plik można rzucić dwóm zespołom programistów - jedni będą klepać
klienta, który może mieć *pewność* co do tych dwóch gwarancji powyżej, a
drudzy będą klepać serwer(y) (klasy pochodne), które nie mogą tych
gwarancji złamać.

A teraz zrób mi to w Javie.
Interfejsami (w sensie Javy) się nie da, bo powyżej kontrakt jest
wyrażony kodem wykonywalnym, którego w Javowym interfejsie się nie da
umieścić. W innych językach (np. w Adzie) taki kontrakt można wyrazić
całkowicie deklaratywnie.
A jeśli zrobisz to w Javie bez interfejsów, tylko z normalną klasą, to
mój następny przykład będzie miał wielodziedziczenie, którego z kolei
nie da się zrobić w Javie na normalnych klasach.

Po cholerę mi język, w którym nie mogę wyrazić *podstaw*?
Post by Sektor van Skijlen
Ale widzisz, tu właśnie następuje kwestia "jakości programistów". Z jednej
strony, oczywiście, wiem na ile C++ nadaje się do poszczególnych rzeczy. Ale z
drugiej, czytam sporo opinii, w tym rzeczowych, o tym, jak to np. w Javie
takie-a-takie rzeczy robi się prościej
Takie-a-takie owszem. A co powiesz o tych-lub-tamtych? :)
Post by Sektor van Skijlen
Nie mam miarodajnych danych, żeby to sprawdzić. Musiałbym spróbować taki sam
średni projekt zrobić w C++ i w Javie. A właściwie to w Javie dać najlepiej
komuś, kto na niej zjadł zęby.
Słusznie. I właśnie problem w tych statystykach jest taki, że do
porównań bierze się projekty w C++, które były robione przez ludzi,
którzy C++ nie znają. Bo sorry, ale jak widzę "delete" co 20 linijek
albo własnoręcznie wyrzeźbioną listę, to nie jest to objaw sprawności w
posługiwaniu się językiem - przynajmniej jeśli mówimy o "normalnym" kodzie.
Post by Sektor van Skijlen
Post by Maciej Sobczak
2. C# nie działa na moim komputerze, ani na żadnym innym z tysiąca,
które coś robią tam, gdzie pracuję.
Cóż, trzeba coś doinstalować. Dokładnie tak samo, jak w przypadku Javy.
Jak już odpisałem Sebastianowi, doinstalować mogę sobie w domu.
Post by Sektor van Skijlen
No nie wiem. A mono, pnet, dotgnu?
Wymieniłeś platformy. A teraz wymień aplikacje, które są przenośne i
dzięki temu odniosły sukces.

Jestem przekonany, że ta przenośność C# jest tylko iluzoryczna.
Aplikacje muszą polegać nie tylko na definicji samego języka, ale też na
wielu elementach, które tworzą jego środowisko - wystarczająco wielu,
żeby tą przenośność ograniczyć. I tu M$ ma wielkie pole do popisu - jak
zdefiniować resztę, żeby tak się właśnie stało.

Jak już pisałem tu parę miesięcy temu - czekam na aplikacje z sukcesami.
Post by Sektor van Skijlen
Jestem w tym wszystkim ciekaw, jak ustabilizował się język C.
No jak to jak. Uniksa w tym wyklepali a potem poszło z górki. Z drugiej
strony barykady było WinAPI, całe w C, i już masz równy krajobraz.
Post by Sektor van Skijlen
Post by Maciej Sobczak
Wszystko co robię to jakiś komunikat CORBA, bo CORBA jest podstawą GNOME
tak samo, jak COM jest (był?) podstawą Windowsa. Wiedziałeś o tym? :)
Owszem. Zresztą COM to też taka mniej-więcej korba.
Bardziej mniej, niż więcej. W CORBA IDLu można definiować skomplikowane
struktury danych. Ostatnio jak sprawdzałem w COMie, strukturą
"skomplikowaną do granic możliwości" była tablica i żeby zrobić coś
bardziej zaawansowanego trzeba pisać własny marshalling.

Przykładowy IDL z
http://www.iona.com/support/docs/manuals/orbix/33/html/orbix33cxx_pguide/IDL.html

module BankSimple {
typedef sequence<string> CustomerSeq;

interface Account {
void getCustomerList(out CustomerSeq names);
...
};
};

Proste, nie?
Post by Sektor van Skijlen
Post by Maciej Sobczak
I to działa.
Wiem. To co w takim razie lepszego w tych wszystkich RMI, Beans, EJB i innych
pierdołach?
Lepszego? Może to, że ograniczają Cię do jednej platformy?

Przykład z tzw. życia:
System rozproszony, w użyciu:
- systemy operacyjne: Windows, Linux, LynxOS
- języki: C++, Java

Niektóre komputery mają tylko 64MB RAMu, większość nie ma nawet dysków
twardych.

Jakiś pomysł na połączenie tego wszystkiego?
Post by Sektor van Skijlen
No dobrze, ale na ile wygodne jest jej używanie z opziomu C++ w porównaniu do
Javy?
Parę centymetrów wyżej masz przykład interfejsu. Zastanów się, w jakim
języku programowania ten przykład ma najbardziej oczywiste przełożenie.

Java jest tu upośledzona już przez sam fakt, że nie ma przekazywania
typów fundamentalnych przez referencję. Czyli takie coś:

void fun(in long a, out long b);

może być w C++ przełożone w sposób naturalny, podczas gdy Java użyje
różnych typów danych dla tych dwóch parametrów (!). Konkretnie, typem
dla a będzie int, ale typem dla b będzie IntHolder. Różne typy danych
dla tej samej dziedziny, ale różnych kierunków przesyłania to jest jedna
z największych bzdur w historii informatyki. (Ale przecież jest tyyyyle
książek do inżynierii oprogramowania w Javie...)

Drugi problem Javy w temacie CORBA to fakt, że CORBA ma typy unsigned.
Java ich nie ma i np. mapuje zarówno long jak i unsigned long na swój
int (czyli ze znakiem).
Wyobraź sobie teraz taki interfejs:

bool less(in unsigned long a, in unsigned long b);

Wyobraź sobie teraz klienta w C++, który wysyła "średnio duże" liczby i
serwer w Javie, który je porównuje. Mam pisać dalej? :)

Ale nic to. Napiszmy lepiej kolejny artykuł o tym, że Java jest
doskonałym językiem do takich systemów i opublikujmy go w żurnalu "Wise
Manager's Choices".
Post by Sektor van Skijlen
Przyznaję, nie używałem korby. Uzywałem COM-a i mam po nim naprawdę paskudne
wrażenia.
Nie dziwię się.
Post by Sektor van Skijlen
No dobrze, zgadzam się. Ale czy to w takim razie oznacza, że nie rejestrowanie
Javy jako standard było korzystnym posunięciem biznesowym?
Na tym się nie znam. :)
Post by Sektor van Skijlen
Zresztą, Java jest standardem, w pewnym sensie. W pewnym sensie, bo łapę na
standardzie trzyma Sun.
Tak to standardem jest też VB. Word też zapisuje pliki w standardowy
sposób...
Post by Sektor van Skijlen
Ale wiesz, różnica w kwestii rozreklamowania to jedno, ale kwestia
popularności jest osobną sprawą. Niezbyt mi się chce wierzyć w to, że reklama
Javy jest skierowana do programistów.
Bo nie jest! :)
Post by Sektor van Skijlen
Post by Maciej Sobczak
Post by Sektor van Skijlen
Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Oczywiście, że stać. Lepiej - takie technologie są. Dlaczego uważasz, że
nie ma? Bo jakiś tam edytorek nie podpowiada nazw funkcji w C++?
Oj, nie o to chodzi :). Czy C++ posiada równie wygodne w używaniu biblioteki
do tych wszystkich rzeczy, do których powszechnie wykorzystuje się Javę?
Czyli jakich rzeczy? :)
Myślałem, że tym edytorkiem sprowokuję Cię do czegoś konkretnego a Ty
jakieś ogólniki tu wrzucasz.
Post by Sektor van Skijlen
Post by Maciej Sobczak
Można napisać dowolnie duży
system w C++ bez gołych wskaźników i bez ich arytmetyki.
No tak, ale czy się pisze? Czy wszyscy wiedzą, jak pisać, żeby tak wyszło?
Oczywiście, że nie. Przecież sam wiesz, z Księżyca nie spadłeś. :)
Problemem jest niestety słaba edukacja.
Różnica pomiędzy C++ i Javą jest taka, że ze słabą edukacją można się
łatwiej ukryć w środowisku Javy, bo tam słaby kod nie musi być od razu
obserwowalnie katastrofalny. ;)
Post by Sektor van Skijlen
Post by Maciej Sobczak
Nie da się dostosować C++ "w dół". Właśnie dzięki temu C++ nadal
pozostanie najbardziej użytecznym językiem.
Ależ mnie nie chodzi, by C++ w jakikolwiek sposób ograniczać - sam bym z niego
zrezygnował, gdyby się coś takiego stało. Chodzi o to, że może należałoby
wypracować jakieś ograniczone reguły sposobu używania C++, tak żeby to się
jednak okazało wygodne? Ograniczone, to znaczy nie stosując jawnego
zarządzania obiektami, nie stosując niskopoziomowych sztuczek itd.
Meyers, Sutter, ...
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Johnny
2006-03-24 14:20:33 UTC
Permalink
Post by Maciej Sobczak
// base.h
class Base
{
int fun(const SomeClass &sc)
{
int result = do_fun(sc);
assert(result >= -100 && result <= 100);
return result;
}
virtual int do_fun(const SomeClass &sc) = 0;
};
Chciałbym zapytać o powyższą konstrukcję. Z podobną zetknąłem się u
Jossutisa z tą różnicą, że metoda virtualna była chroniona nie prywatna
i nie była "pure". Jaki jest sens stosowania takiej konstrukcji? U
Jossutisa czytam: "Ten styl używany jest w celu uniknięcia ukrywania
funkcji składowych podczas nadpisywania jedynie jednej z kilku
wirtualnych funkcji składowych posiadających tę samą nazwę. (...)
Dodatkowo umożliwia to programiście klasy bazowej dodanie do funkcji
niewirtualnych pewnego dodatkowego kodu, wykonywanego nawet w przypadku
nadpisania funkcji wirtualnej."
--
Pozdrawiam
Johnny
Maciej Sobczak
2006-03-24 15:00:39 UTC
Permalink
Post by Johnny
Post by Maciej Sobczak
// base.h
class Base
{
int fun(const SomeClass &sc)
{
int result = do_fun(sc);
assert(result >= -100 && result <= 100);
return result;
}
virtual int do_fun(const SomeClass &sc) = 0;
};
Chciałbym zapytać o powyższą konstrukcję. Z podobną zetknąłem się u
Jossutisa z tą różnicą, że metoda virtualna była chroniona nie prywatna
i nie była "pure".
To są drobiazgi. Jeżeli ktoś chce podać "domyślną" implementację, z
której w dodatku będą mogli korzystać inni w klasach pochodnych, to
faktycznie, jest sens wtedy zrobić zarówno metodę chronioną jak i nie
"pure". Ten przykład powyżej to w zasadzie wersja ortodoksyjna, która
oznacza, że klasa Base dostarcza *tylko* interfejs i żadnej
implementacji, natomiast klasa pochodna *musi* dostarczyć *całą*
implementacją. Ale nie to jest tu istotne, tylko fakt, że interfejs nie
musi być tylko nazwą funkcji.
Post by Johnny
U
Jossutisa czytam: "Ten styl używany jest w celu uniknięcia ukrywania
funkcji składowych podczas nadpisywania jedynie jednej z kilku
wirtualnych funkcji składowych posiadających tę samą nazwę. (...)
Nigdy tego w taki sposób nie traktowałem ale możliwe, że może się to
wtedy przydać.
Post by Johnny
Dodatkowo umożliwia to programiście klasy bazowej dodanie do funkcji
niewirtualnych pewnego dodatkowego kodu, wykonywanego nawet w przypadku
nadpisania funkcji wirtualnej."
No właśnie taki jest sens "instrumentowania" klasy bazowej. W powyższym
przykładzie chodzi o wymuszenie pewnego kontraktu, ale może to być też
np. logowanie wywołań danej funkcji (nie da się takiego logowania
ominąć, bo fun nie jest wirtualna) albo inna diagnostyka.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Paweł Kierski
2006-03-24 10:00:08 UTC
Permalink
Sektor van Skijlen w wiadomości <dvull4$2v3$***@kujawiak.man.lodz.pl> pisze:
[...]
Post by Sektor van Skijlen
Ależ mnie nie chodzi, by C++ w jakikolwiek sposób ograniczać - sam bym z niego
zrezygnował, gdyby się coś takiego stało. Chodzi o to, że może należałoby
wypracować jakieś ograniczone reguły sposobu używania C++, tak żeby to się
jednak okazało wygodne? Ograniczone, to znaczy nie stosując jawnego
zarządzania obiektami, nie stosując niskopoziomowych sztuczek itd.
Ale jednocześnie trzeba by dołożyć trochę standardowych bibliotek
takich jak wątki, sieć, komunikacja międzyprocesowa, itp. bo bez nich
zawsze będzie się skazanym na "niskopoziomowe sztuczki" związane z
daną platformą. Owszem - jest boost, ale już socketstream w nim nie
ma... A bardziej wydajne konstrukcje związane z platformami (serwery
klasy C10K) i tak trzeba w sporej części rzeźbić samodzielnie, a
przecież to jest ten zakres, w którym C++ bardziej się sprawdza, ze
względu na możliwość większego "oszczędzania" zasobów. Sformułowanie
ograniczeń tak, żeby jednocześnie nie przeszkadzały w rozwiązywaniu
takich problemów wydaje mi się sprawą blisko granicy możliwości...
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Maciej Sobczak
2006-03-24 15:15:32 UTC
Permalink
Post by Sektor van Skijlen
Post by Maciej Sobczak
CORBA nie powala. CORBA działa. :)
No dobrze, ale na ile wygodne jest jej używanie z opziomu C++ w porównaniu do
Javy?
Przypomniała mi się pewna kwestia w okolicy CORBA oraz argumentu, że w
Javie jest fajniej, bo nie trzeba mieć tylu bezsensownych plików.
Otóż:

1. Ze względu na ograniczenia Javy w temacie przekazywania parametrów w
różne strony, jeden interfejs w IDLu jest przekładany na kilka klas w
Javie. Nie pamiętam ile, ale jest ich kilka na każdy, nawet
najdrobniejszy, interfejs.

2. W Javie w danym pliku może być tylko jedna publiczna klasa.

Składając te dwa fakty mamy ciekawy efekt. Weźmy jakiś nietrywialny plik
.idl, z bogatym opisem typów danych. Kompilator IDL dla C++ zrobi z tego
2-4 pliki (.h i .cpp dla klienta i serwera), umieszczając w tych plikach
wszystkie definicje wynikające z IDL. Natomiast kompilator IDL dla Javy
zrobi z tego całe stado (nawet kilkaset) plików, po kilka na każdy
interfejs z IDLa. Tych plików może być naprawdę cała masa.

Goście od Javy wymyślili sobie .jar nie dla zabawy, ale właśnie po to,
żeby zapanować nad absurdalną liczbą plików, która może się pojawić w
projekcie.

Mam nadzieję, że ludzie wezmą to pod uwagę zanim następnym razem
napiszą, że C++ jest do bani, bo ma jakieś niepotrzebne nagłówkowe. :)
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
A..L.
2006-03-24 03:28:18 UTC
Permalink
On Thu, 23 Mar 2006 12:05:53 +0100, Maciej Sobczak
Post by Maciej Sobczak
Hehe - pojechałeś z nutką nostalgiczną, więc też odpiszę "z głebi duszy". :)
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać.
Spada, bo się sesja skończyła i ludzie już pooddawali swoje prace domowe. :p
A teraz na temat: C++ jest najbardziej *użytecznym* językiem
programowania i to zabezpiecza jego szczęśliwy byt na długie lata w
przód. Nie jest idealny w sensie teorii projektowania języków, ale
języki idealne (kupa tego na uczelniach) są używane tylko przez ich twórców.
Popatrzmy na konkurencję.
1. Java w ogóle nie nadaje się do programowania czegokolwiek. Z mojego
- Brak oddzielenia specyfikacji od implementacji (czyli po ludzku: brak
odpowiednika plików nagłówkowych - wiem, wiem, niektórym się wydaje, że
takie rozdzielenie to główna wada C++, ale nie dość, że to jest zaleta,
to w dodatku jest to konieczność w większych projektach i niektóre
języki poszły we wspieraniu tego rozdzielenia dużo dalej, niż C++; im
lepiej język rozdziela specyfikację od implementacji, tym lepiej się
nadaje do poważnych projektów).
- Brak możliwości tworzenia nowych dziedzin i typów danych. Klasy to za
mało. W wersji dla ubogich potrzebne jest coś, co ma np. Ada w postaci
słów kluczowych type i subtype, w wersji rozbudowanej potrzebne jest
przeciążanie operatorów i wykorzystanie zewnętrznych opisów dziedzin i
generatorów typów albo wbudowanego metajęzyka do opisu dziedzin. W
porządnych językach to się robi naturalnie, w Javie nie da się tego
zrobić wcale a bez tego nie ma sensu mówić o inżynierii programowania.
- Brak deterministycznej destrukcji. Finally jest do bani.
Statystycznie, okres "hurraaaa!" na Javę chyba się kończy i nowe
projekty w Javie nie są już tak radośnie otwierane, jak to było swego
czasu. Być może właśnie dlatego, że ludzie zaczynają sobie uświadamiać
braki tego języka. Polecam posty Jamesa Kanze na comp.lang.c++.moderated
na ten temat - to jest gość, który ma w tym biznesie większe
doświadczenie, niż my wszyscy razem i jego komentarze w tym temacie są
Dalej nie bede cytowal bo szkoda miejsca. Ale podobnych nonsensow
dawno nie czytalem. Jaja, no po prostu jaja. Kubiczne.

Dziekuje za rozrywke. I kolegom z pl.comp.objects za reklame tego
watku.

A.L.
Rafał Maj Raf256
2006-03-23 11:50:14 UTC
Permalink
Mam nadzieję iż C++ jak najbardziej przetrwa.

Język się rozwija (np. świetne zmiany proponowane w c++0x oficjalnie
pewnie w 2009, a mam cichą nadzieję iż gcc zaimplementuje chociaż część
już wcześniej w 2007/08)

Przy okazji, mały quote z ##c++ freenode.org

<ciaranm> c# is microsoft's version of java. java is sun's version of
c++, aimed at idiots

;)

Bardzo spłycone, ale zasada ogólnie prawdziwa. Nie wiem po co używać np.
Javy skoro jest C++, jedyny powód jaki mi się nasuwa to z szukaniem
wykształconych programistów (na zasadzie - co będziemy kopać koparką i
szukać kierowcy, jak można zatrudnić byle kogo i rozdać łopaty)
--
Wymiana starych układów... na nowe układy - prawie jak walka z korupcja.
Walka z wychowaniem seksualnym i erotyką - prawie jak walka z patologią.
PiS - prawie jak prawo i sprawiedliwość... Prawie. Prawie robi różnicę.
Myśl. Głosuj rozsądnie. Nie na tanie hasła. // Rafał Maj Raf256
Tomasz Pyra
2006-03-23 12:14:02 UTC
Permalink
Post by Rafał Maj Raf256
Mam nadzieję iż C++ jak najbardziej przetrwa.
Język się rozwija (np. świetne zmiany proponowane w c++0x oficjalnie
pewnie w 2009, a mam cichą nadzieję iż gcc zaimplementuje chociaż część
już wcześniej w 2007/08)
Przy okazji, mały quote z ##c++ freenode.org
<ciaranm> c# is microsoft's version of java. java is sun's version of
c++, aimed at idiots
;)
Bardzo spłycone, ale zasada ogólnie prawdziwa. Nie wiem po co używać np.
Javy skoro jest C++, jedyny powód jaki mi się nasuwa to z szukaniem
wykształconych programistów (na zasadzie - co będziemy kopać koparką i
szukać kierowcy, jak można zatrudnić byle kogo i rozdać łopaty)
Zależy kto ma jakie potrzeby.
Jak ktoś ma do skopania grządki w ogródku, to nie potrzebuje do tego ani
koparki ani pługa.
Poza tym niejednokrotnie łatwiej, szybciej i taniej jest zatrudnić ekipę
z łopatami która zrobi co ma zrobić, niż kombinować z koparką.

Tak samo z programowaniem - bardzo wiele tworzonego oprogramowania to
proste rzeczy nad którymi nie ma co się wiele zastanawiać, a głównie
czas zajmuje samo kodowanie, ewentualnie zmiany w kodzie dostosowujące
to co już jest napisane.
W takim przypadku prostszy język przyspieszy taką implementację.
Paweł Kierski
2006-03-23 12:30:31 UTC
Permalink
Rafał Maj Raf256 w wiadomości <dvu21l$1d8$***@inews.gazeta.pl> pisze:
[...]
Post by Rafał Maj Raf256
Bardzo spłycone, ale zasada ogólnie prawdziwa. Nie wiem po co używać np.
Javy skoro jest C++, jedyny powód jaki mi się nasuwa to z szukaniem
wykształconych programistów (na zasadzie - co będziemy kopać koparką i
szukać kierowcy, jak można zatrudnić byle kogo i rozdać łopaty)
Takie zadanie kiedyś było: "Jeden robotnik kopie studnię w 10
godzin. Ile czasu zajmie wykopanie studni 100 robotnikom?". Odpowiedź
10 godzin / 100 == 6 minut nie jest jednak prawdziwa. Za to dobrze
ilustruje fakt, że nie ma prostego przełożenia koparki i odpowiednią
liczbę ludzi z łopatami.
Tak samo z C++ vs. Java/C# - w części przypadków jest prosta
zależność między czasem wykonania i wydajnością kodu wynikowego, ale
nie sprawdza się zawsze. W skrajnych przypadkach: z jednej strony w
Javie/C# pewnych rzeczy nie da się wystarczająco szybko i z małym
zużyciem pamięci zrobić w ogóle, a z drugiej - w C++ produkcja w
sensownym czasie skomplikowanego systemu wymagać będzie użycia takich
technik, które praktycznie zmienią C++ w Javę/C#.
Co nie zmienia faktu, że zarówno łopata jak i koparka są nadal w
użyciu.
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Jedrzej Dudkiewicz
2006-03-23 13:02:01 UTC
Permalink
Post by Paweł Kierski
Post by Rafał Maj Raf256
Bardzo spłycone, ale zasada ogólnie prawdziwa. Nie wiem po co używać np.
Javy skoro jest C++, jedyny powód jaki mi się nasuwa to z szukaniem
wykształconych programistów (na zasadzie - co będziemy kopać koparką i
szukać kierowcy, jak można zatrudnić byle kogo i rozdać łopaty)
Takie zadanie kiedyś było: "Jeden robotnik kopie studnię w 10
godzin. Ile czasu zajmie wykopanie studni 100 robotnikom?".
Też 10 godzin, ale będzie 100 studni :)

JD
Paweł Kierski
2006-03-23 13:28:38 UTC
Permalink
Post by Jedrzej Dudkiewicz
Post by Paweł Kierski
Post by Rafał Maj Raf256
Bardzo spłycone, ale zasada ogólnie prawdziwa. Nie wiem po co używać np.
Javy skoro jest C++, jedyny powód jaki mi się nasuwa to z szukaniem
wykształconych programistów (na zasadzie - co będziemy kopać koparką i
szukać kierowcy, jak można zatrudnić byle kogo i rozdać łopaty)
Takie zadanie kiedyś było: "Jeden robotnik kopie studnię w 10
godzin. Ile czasu zajmie wykopanie studni 100 robotnikom?".
Też 10 godzin, ale będzie 100 studni :)
Ale po co mi 100 studni po 10 godzinach, jak chcę wystarczy mi
jedna, byle jak najszybciej? 8-)
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Jedrzej Dudkiewicz
2006-03-23 13:48:00 UTC
Permalink
Post by Paweł Kierski
Post by Jedrzej Dudkiewicz
Post by Paweł Kierski
Takie zadanie kiedyś było: "Jeden robotnik kopie studnię w 10
godzin. Ile czasu zajmie wykopanie studni 100 robotnikom?".
Też 10 godzin, ale będzie 100 studni :)
Ale po co mi 100 studni po 10 godzinach,
"Jak mawia stare polskie przysłowie: im więcej, tym więcej." :)
Post by Paweł Kierski
wystarczy mi
jedna, byle jak najszybciej? 8-)
To jednak lepiej wiercić a nie kopać :]

JD
Rafał Maj Raf256
2006-03-24 05:30:26 UTC
Permalink
Post by Paweł Kierski
zużyciem pamięci zrobić w ogóle, a z drugiej - w C++ produkcja w
sensownym czasie skomplikowanego systemu wymagać będzie użycia takich
technik, które praktycznie zmienią C++ w Javę/C#.
Tak, to miałem na myśli - bardzo wysokopoziomowe C++, czemu go nie
używać zamiast Javy? I szybsze i często tak samo przenośne w praktyce i
tak samo szybkie w sensie pracy programisty.

Jedyne realne zastosowanie gdzie wybierałbym Javę to aplety itd.
--
Wymiana starych układów... na nowe układy - prawie jak walka z korupcja.
Walka z wychowaniem seksualnym i erotyką - prawie jak walka z patologią.
PiS - prawie jak prawo i sprawiedliwość... Prawie. Prawie robi różnicę.
Myśl. Głosuj rozsądnie. Nie na tanie hasła. // Rafał Maj Raf256
Paweł Kierski
2006-03-24 08:16:17 UTC
Permalink
Post by Rafał Maj Raf256
Post by Paweł Kierski
zużyciem pamięci zrobić w ogóle, a z drugiej - w C++ produkcja w
sensownym czasie skomplikowanego systemu wymagać będzie użycia takich
technik, które praktycznie zmienią C++ w Javę/C#.
Tak, to miałem na myśli - bardzo wysokopoziomowe C++, czemu go nie
używać zamiast Javy? I szybsze i często tak samo przenośne w praktyce i
tak samo szybkie w sensie pracy programisty.
Wymaga określenia, z jakich bibliotek będzie się korzystać,
przygotowania sobie środowiska itd. Szybsze - być może, w każdym razie
chyba potencjalnie lepsza możliwość optymalizacji w wąskich gardłach.
Czy tak samo przenośne - nie wiem, nie mam wiedzy, w Javie jestem
nieco powyżej "Hello, world!", a i to tylko dzięki ogólnemu rozumieniu
obiektowości 8-)
Na pewno za C++ będzie stała większa łatwość "głębokiego" grzebania
w systemie - "systemowe" interfejsy (sterowniki i trochę wyżej)
najpopularniejszych systemów są dostępne w C. Czyli wraca stare -
C/C++ jako (czasem) przenośny asembler do zastosowań specjalnych? 8-)
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
AL.
2006-03-24 15:49:49 UTC
Permalink
On Fri, 24 Mar 2006 06:30:26 +0100, Rafa? Maj Raf256
zu?yciem pami?ci zrobi? w ogóle, a z drugiej - w C++ produkcja w
sensownym czasie skomplikowanego systemu wymaga? b?dzie u?ycia takich
technik, które praktycznie zmieni? C++ w Jav?/C#.
Tak, to mia?em na my?li - bardzo wysokopoziomowe C++, czemu go nie
u?ywa? zamiast Javy? I szybsze i cz?sto tak samo przeno?ne w praktyce i
tak samo szybkie w sensie pracy programisty.
Jedyne realne zastosowanie gdzie wybiera?bym Jav? to aplety itd.
Pan, Panei Maj tez ma takie pojecie o Javie jak ja o japonskim teatrze
Kabuko.

A.L.
Paweł Kierski
2006-03-24 16:25:35 UTC
Permalink
AL. w wiadomości <***@4ax.com> pisze:
[...]
Post by AL.
Pan, Panei Maj tez ma takie pojecie o Javie jak ja o japonskim teatrze
Kabuko.
To naprawdę jest źle z wiadomościami Rafała, biorąc pod uwagę, że
ten teatr to "kabuki"... 8-)
A do rzeczy - coś oprócz stwierdzenia ignorancji dyskutanta chciałeś
dodać do wątku? Może coś merytorycznego? Np. wskazanie, która część
wypowiedzi Rafała świadczy o jego niewiedzy i dlaczego? Sam chętnie
bym się dowiedział.
--
Paweł Kierski
***@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
AL.
2006-03-24 20:33:40 UTC
Permalink
[...]
Post by AL.
Pan, Panei Maj tez ma takie pojecie o Javie jak ja o japonskim teatrze
Kabuko.
To naprawdê jest ¼le z wiadomo¶ciami Rafa³a, bior±c pod uwagê, ¿e
ten teatr to "kabuki"... 8-)
A do rzeczy - co¶ oprócz stwierdzenia ignorancji dyskutanta chcia³e¶
dodaæ do w±tku? Mo¿e co¶ merytorycznego? Np. wskazanie, która czê¶æ
wypowiedzi Rafa³a ¶wiadczy o jego niewiedzy i dlaczego? Sam chêtnie
bym siê dowiedzia³.
Ja wiem ze Kabuki. Pzrejezyczylem sie.

Pam Maj napisal:

"Tak, to mia?em na my?li - bardzo wysokopoziomowe C++, czemu go nie
u?ywa? zamiast Javy? I szybsze i cz?sto tak samo przeno?ne w praktyce
i
tak samo szybkie w sensie pracy programisty..."

Otoz nieprawda co do "szybkosci pracy programisty. Odpowiednie zrodla
(na przyklad ksiazka "Software Estimation: Demystifying the Black
Art", Steve McConnell) podaja cas potzrebny na zaprogramwoanie 1 KLOC
czt tez odpowiedniej ilosci punktow w C++ i Javie. Nie mam ksiazki pod
reka, wiec nie moge przytoczyc dokladnych liczb, ale bynajmniej
porownanie nie wypada na korzysc C++ (jak ksiazke odnajde, bo ktos
sobie "pozyczyl" to przytocze liczby). Z wlasnej praktyki - projekt w
C++ ktory po 2 milionach dolcow zostal skasowany z powodu braku
jakichkolwiek nadziei na zmieszczenie sie w czasie i budzecie. Jak
programista kosztuje firme 150 dolcow za godzine, to ostatnia rzecz
ktora on powinien robic to polowac z Purify na "wiszace wskazniki".
Neistety, okazalo sie ze owe polowania to glowne czynnosci
programistow.

Project byl "reengineering" ze Smalltalka do bardziej "nowoczesnego"
jezyka. Aplikacja w Smalltaku miala tak z 800 tysiecy linii. Okazalo
sie ze zrobienie jej w C++, aczkolwiek zapewne technicznie mozliwe,
biznesowo nie ma sensu.

Aplikacje przepisano bez problemu w Jave. Java jest bardziej
"rozgadana", wiec wyszlo wiecj linii niz Smalltalka, ale odbylo sie to
bez problemow i sensacji. Obecnie aplikacja ma sie dobrze i przechodzi
nastepny "facelift" do Javy 1.5 z dodaniem wielu nowych funkcji.
Pracuje nad aplikacja 25 osob, uzywa Eclipse i CVS jakby sie kto pytal
i zadnych problemow do tej pory nie zarejstrowano. Acha, Javy uzywa
sie tylko od strony serwerowej. GUI pisze sie w C#. Calosc zamknie sie
parwdopodobnie w milionie i cwierc linii Javy

Pan Maj:

"Jedyne realne zastosowanie gdzie wybiera?bym Jav? to aplety itd."

W kontekscie tego co napisalem powyzej, Pan Maj po prostu bredzi.

A.L.
mike
2006-03-24 20:56:26 UTC
Permalink
Post by AL.
Z wlasnej praktyki - projekt w
C++ ktory po 2 milionach dolcow zostal skasowany z powodu braku
jakichkolwiek nadziei na zmieszczenie sie w czasie i budzecie. Jak
programista kosztuje firme 150 dolcow za godzine, to ostatnia rzecz
ktora on powinien robic to polowac z Purify na "wiszace wskazniki".
Neistety, okazalo sie ze owe polowania to glowne czynnosci
programistow.
Same sie wskazniki nie powiesily :)
Post by AL.
Project byl "reengineering" ze Smalltalka do bardziej "nowoczesnego"
jezyka. Aplikacja w Smalltaku miala tak z 800 tysiecy linii. Okazalo
sie ze zrobienie jej w C++, aczkolwiek zapewne technicznie mozliwe,
biznesowo nie ma sensu.
Moze developerzy nie byli zbyt dobrze wyedukowani :)
Post by AL.
Aplikacje przepisano bez problemu w Jave. Java jest bardziej
"rozgadana", wiec wyszlo wiecj linii niz Smalltalka, ale odbylo sie to
bez problemow i sensacji. Obecnie aplikacja ma sie dobrze i przechodzi
nastepny "facelift" do Javy 1.5 z dodaniem wielu nowych funkcji.
Pracuje nad aplikacja 25 osob, uzywa Eclipse i CVS jakby sie kto pytal
i zadnych problemow do tej pory nie zarejstrowano. Acha, Javy uzywa
sie tylko od strony serwerowej. GUI pisze sie w C#. Calosc zamknie sie
parwdopodobnie w milionie i cwierc linii Javy
Pozdrawiam
AL.
2006-03-24 21:33:25 UTC
Permalink
Post by mike
Post by AL.
Z wlasnej praktyki - projekt w
C++ ktory po 2 milionach dolcow zostal skasowany z powodu braku
jakichkolwiek nadziei na zmieszczenie sie w czasie i budzecie. Jak
programista kosztuje firme 150 dolcow za godzine, to ostatnia rzecz
ktora on powinien robic to polowac z Purify na "wiszace wskazniki".
Neistety, okazalo sie ze owe polowania to glowne czynnosci
programistow.
Same sie wskazniki nie powiesily :)
"Aplikacje" to nie tylko "database front end" i GUI. Ta aplikacja to
optymalizacja systemu zaopatrzenia, w ktorej obiektowo modeluje sie
stan systemu. W kazdej chwili dziesiatki tysiecy obiektow powstaja i
powinny znikac. Niestety, nie sposob sprawdzic czy do kazdej alokacji
jest odpowiedni dealokacja, bo musialoby to sie sprowadzic do
pzreanalizowania wszystkich mozliwych sciezek wykonania programu.
Obiektow zas jest tyle, ze nie mozna trzymac niepotzrebnych za dlugo,
bo zabraknie pamieci. Innymi slowy, w takim systemie i przy
zastosowaniu jezyka bez odsmiecacza bedzie sie zawsze mialo albo
"wiszace pointery" albo "memory leaks" albo "memory overflow". Chyba
ze sie spedzi dostatecznie duzo czasu atakujac ten problem. Zauwazyli
to tworcy jezyka Simula 67, ktoar byla wlasnie przeznaczoan do takich
aplikacji i wyposazyli ja w garbage collector. Niestety, nieudolna i
prymitywna kopia Simuli zwana C++ uznala to za zbedny balast.
Post by mike
Post by AL.
Project byl "reengineering" ze Smalltalka do bardziej "nowoczesnego"
jezyka. Aplikacja w Smalltaku miala tak z 800 tysiecy linii. Okazalo
sie ze zrobienie jej w C++, aczkolwiek zapewne technicznie mozliwe,
biznesowo nie ma sensu.
Moze developerzy nie byli zbyt dobrze wyedukowani :)
Dobrze wyedukowani. Niestety, otrzymali zbyt prymitywne nazredzie.
Poslugujac sie moja ulubiona analogia budowlana: dziury w scianach
mozna robic mlotkiem i meslem, mozna tez udarowa wiertarka
elektryczna. Zeby nie bylo watpliwosci: mlotek to C++.

Tak na marginesie, deweloperzy C++ otrzymali propozycje: albo im sie
podziekuje za prace, albo szybko naucza sie Javy. Pensja ta sama.
Wszyscy nauczyli sie Javy w pare dni. O ile wiem, zaden z nich nie
powrocil do C++.

A.L.
mike
2006-03-24 22:21:31 UTC
Permalink
Post by AL.
"Aplikacje" to nie tylko "database front end" i GUI. Ta aplikacja to
optymalizacja systemu zaopatrzenia, w ktorej obiektowo modeluje sie
stan systemu. W kazdej chwili dziesiatki tysiecy obiektow powstaja i
powinny znikac. Niestety, nie sposob sprawdzic czy do kazdej alokacji
jest odpowiedni dealokacja, bo musialoby to sie sprowadzic do
pzreanalizowania wszystkich mozliwych sciezek wykonania programu.
Obiektow zas jest tyle, ze nie mozna trzymac niepotzrebnych za dlugo,
bo zabraknie pamieci. Innymi slowy, w takim systemie i przy
zastosowaniu jezyka bez odsmiecacza bedzie sie zawsze mialo albo
"wiszace pointery" albo "memory leaks" albo "memory overflow". Chyba
ze sie spedzi dostatecznie duzo czasu atakujac ten problem. Zauwazyli
to tworcy jezyka Simula 67, ktoar byla wlasnie przeznaczoan do takich
aplikacji i wyposazyli ja w garbage collector. Niestety, nieudolna i
prymitywna kopia Simuli zwana C++ uznala to za zbedny balast.
Post by mike
Post by AL.
Project byl "reengineering" ze Smalltalka do bardziej "nowoczesnego"
jezyka. Aplikacja w Smalltaku miala tak z 800 tysiecy linii. Okazalo
sie ze zrobienie jej w C++, aczkolwiek zapewne technicznie mozliwe,
biznesowo nie ma sensu.
Mozesz zdradzic kto wylozyl 2mln USD na ten projekt ?
Bo klienta raczej nie interesuje w czym to jest napisane. Ma
dzialac i tyle. W kontekscie tego zmiana jezyka implementacji nie
ma zadnej wartosci dodanej dla klienta.
Post by AL.
Post by mike
Moze developerzy nie byli zbyt dobrze wyedukowani :)
Dobrze wyedukowani. Niestety, otrzymali zbyt prymitywne nazredzie.
Poslugujac sie moja ulubiona analogia budowlana: dziury w scianach
mozna robic mlotkiem i meslem, mozna tez udarowa wiertarka
elektryczna. Zeby nie bylo watpliwosci: mlotek to C++.
Tak na marginesie, deweloperzy C++ otrzymali propozycje: albo im sie
podziekuje za prace, albo szybko naucza sie Javy. Pensja ta sama.
Wszyscy nauczyli sie Javy w pare dni. O ile wiem, zaden z nich nie
powrocil do C++.
A.L.
Mam nadzieje, ze C++ nie "nauczyli" sie rownie szybko jak Javy :)

Pozdrawiam
AL.
2006-03-24 22:36:43 UTC
Permalink
Post by mike
Mozesz zdradzic kto wylozyl 2mln USD na ten projekt ?
Bo klienta raczej nie interesuje w czym to jest napisane. Ma
dzialac i tyle. W kontekscie tego zmiana jezyka implementacji nie
ma zadnej wartosci dodanej dla klienta.
Firma. Klienta, i owszem, inteersuje w czym jest napisane. Zalezy kto
to jest "klient". Ja nie jestem w biznesie robienia bazy danych
szlauchow gumowych i kaloszy dla Miejskiego Pzredsiebiorstwa
Kanalizacyjnego. Jezeli Kolegi doswiadczenie pochodzi wlasnie z takich
"aplikacji" to sie nie porozumiemy.
Post by mike
Mam nadzieje, ze C++ nie "nauczyli" sie rownie szybko jak Javy :)
Nie.

A.L.
mike
2006-03-25 08:42:59 UTC
Permalink
Post by AL.
Firma. Klienta, i owszem, inteersuje w czym jest napisane. Zalezy kto
to jest "klient". Ja nie jestem w biznesie robienia bazy danych
szlauchow gumowych i kaloszy dla Miejskiego Pzredsiebiorstwa
Kanalizacyjnego. Jezeli Kolegi doswiadczenie pochodzi wlasnie z takich
"aplikacji" to sie nie porozumiemy.
Hahaha - nie ma to jak dobry zart w sobotni poranek.
Jakos nie wierze aby taka Lufthansa czy inny flight operator
specyfikowala w czym ma byc soft np. wspomagajacy kontrole ruchu lotniczego.
Ma:
- kosztowac tyle i tyle
- byc na ten termin
- ma miec okreslone ficzery
- ma spelniac okreslone normy safety i security
- ma byc wsparcie (chociaz zwykle za to sie placi oddzielnie)
- ma chodzic na okreslonym sprzecie.

Jedyne sytuacje w ktorych moze byc specyfikowany jezyk to:
- robienie czesci softu - np. moduly dla kogos innego
- klient chce miec mozliwosc pewnej customizacji we wlasnym zakresie

A to czy bedzie to napisane w Assemblerze, Fortranie, Javie, C++ czy
w Prologu ma znaczenie li tylko dla firmy to robiacej.
Sam wybierasz najlepsze narzedzie ktore pozwoli Ci zrealizowac
wymagania, biorac pod uwage koszty wlasne modyfikacji kodu, latwosc
wprowadzania zmian, utrzymanie itp.

Pozwolisz, ze ja jeszcze raz powroce do owych 2mln:
- tzn. klinet powiedzial "zrobcie to w czyms innym byle nie w Adzie" ?
Bo sadzac po tym ze najpierw pisaliscie w C++ a pozniej w Javie to
klinet jakos nie bardzo wiedzial co sam chce.
- skoro 2mln > /dev/null to tylko i wylacznie Wasza wina. Skoro, jak
twierdzisz, ludzie byli wyedukowani w C++ to pewnie jakas te prace
estymowali ?
No chyba, ze zabrali sie do pracy dzielac ekran na pol i przepisujac
kod. Jesli tak to faktycznie nie mamy o czym rozmawiac...


Pozdrawiam

Marcin 'Qrczak' Kowalczyk
2006-03-23 16:08:00 UTC
Permalink
Na razie sprostuję tylko nieścisłości.
Dokładnie to samo dzieje się z Linuxem, który "szanse na stanie się
konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i jakoś
zdecydowanie za mało z tego korzysta.
Linux powstał w 1991 roku, czyli 20 lat temu nie istniał w ogóle.
A przez pierwszych parę lat raczej był zabawką, więc na początku
nikt nie mówił o szansach na stanie się konkurencyjnym.
1. Java w ogóle nie nadaje się do programowania czegokolwiek. Z mojego
brak odpowiednika plików nagłówkowych
Nie, to co innego. Sęk w tym, że plik nagłówkowy C++ zawiera więcej
niż interfejs biblioteki. Albo raczej zawiera interfejs z punktu
widzenia kompilatora, a nie z punktu widzenia programisty. Czyli
zawiera m.in. treści funkcji inline i szablonów, prywatne pola klas,
których jakiekolwiek pola albo metody są eksponowane (chyba że rzeźbimy
z pimpl) oraz wszystkie zależności powyższych, tzn. definicje potrzebne
do zaimplementowania tych funkcji inline, do opisania typów prywatnych
metod itd.

Pierwszy z brzegu przykład: aalib.h. To jest C, a nie C++, ale sprawy
plików nagłówkowych są w tych językach prawie te same. Oto wybrane
elementy "interfejsu":

#ifndef __AALIB_INCLUDED__
#define __AALIB_INCLUDED__
#include <stdio.h>

/* The -malign-double switch changes binarry compatibility with structures
containing floating point values. To avoid this, set alignment manually
to old value. */

#ifdef __GNUC__
#ifdef __i386__
#define __AA_ALIGN __attribute__ ((__aligned__ (4)))
#define __AA_NOALIGN __attribute__ ((__packed__))
#endif
#endif
#ifndef __AA_ALIGN
#define __AA_ALIGN
#endif
#ifndef __AA_NOALIGN
#define __AA_NOALIGN
#endif

/*
* aa_context contains information about the display. It is passed to most
* of AA-lib functions. The full definition of structure is present just
* for compatibility with older programs. Dirrect access to it's fields
* is not recommended, because you might surfer to problems with future
* releases of AA-lib. Use standard AA-lib functions instead.
*/
struct aa_context {
__AA_CONST struct aa_driver *driver; /*Current display driver */
__AA_CONST struct aa_kbddriver *kbddriver; /*Current keyboard driver */
__AA_CONST struct aa_mousedriver *mousedriver; /*Current mouse driver */
struct aa_hardware_params __AA_NOALIGN params; /*Parameters of output
hardware used by AA-lib. */ struct aa_hardware_params __AA_NOALIGN driverparams; /*Parameters of output
hardware as reported
by display driver. */ int mulx, muly; /* Ratio of character size over pixel size */
int imgwidth, imgheight; /* Dimensions of emulated image */
unsigned char *imagebuffer; /* Virtual buffer containing image */
unsigned char *textbuffer; /* Virtual buffer containing text */
unsigned char *attrbuffer; /* Virtual buffer containing attributes */
unsigned short *table; /* Precalculated values used by rendering
algorithm.

WARNING!
It is _strongly_ depreached
to access fields behind this point, because
they can change in future releases.*/
unsigned short *filltable;
struct parameters *parameters;
int cursorx, cursory, cursorstate; /* Cursor possition. */
int mousex, mousey, buttons,mousemode; /* Mouse state. */
void (*resizehandler) (struct aa_context *); /* Handler to be called when
resize happends. */
void *driverdata; /* Internal data used by hardware drivers. */
void *kbddriverdata;
void *mousedriverdata;
};

/*
* The hardware driver specification. Used internally by AA-lib only.
* Provided for compatibility with older programs.
*/
struct aa_driver {
__AA_CONST char *shortname, *name;
int (*init) (__AA_CONST struct aa_hardware_params *, __AA_CONST void *, struct aa_hardware_params *,void **);
void (*uninit) (struct aa_context *);
void (*getsize) (struct aa_context *, int *, int *);
void (*setattr) (struct aa_context *, int);
void (*print) (struct aa_context *, __AA_CONST char *);
void (*gotoxy) (struct aa_context *, int, int);
void (*flush) (struct aa_context *);
void (*cursormode) (struct aa_context *, int);
};

/* This macro implementations are proved for faster compilation. */
#ifdef __GNUC__
/* The putpixel macro can be implemented reliably only using GNU-C extension. */
#define aa_putpixel(c,x,y,color) ({aa_context *___aa_context=(c); ((___aa_context)->imagebuffer[(x)+(y)*(aa_imgwidth(___aa_context))]=(color)); 0;})
#endif
#define aa_setpalette(palette,index,r,g,b) ((palette)[index]=(((r)*30+(g)*59+(b)*11)>>8))
#define aa_recommendhikbd(t) aa_recommendhi(&aa_kbdrecommended,t);
#define aa_recommendhimouse(t) aa_recommendhi(&aa_mouserecommended,t);
#define aa_recommendhidisplay(t) aa_recommendhi(&aa_displayrecommended,t);
#define aa_recommendlowkbd(t) aa_recommendlow(&aa_kbdrecommended,t);
#define aa_recommendlowmouse(t) aa_recommendlow(&aa_mouserecommended,t);
#define aa_recommendlowdisplay(t) aa_recommendlow(&aa_displayrecommended,t);
#define aa_scrwidth(a) ((a)->params.width)
#define aa_scrheight(a) ((a)->params.height)
#define aa_mmwidth(a) ((a)->params.mmwidth)
#define aa_mmheight(a) ((a)->params.mmheight)
#define aa_imgwidth(a) ((a)->imgwidth)
#define aa_imgheight(a) ((a)->imgheight)
#define aa_image(c) ((c)->imagebuffer)
#define aa_text(c) ((c)->textbuffer)
#define aa_attrs(c) ((c)->attrbuffer)
--
__("< Marcin Kowalczyk
\__/ ***@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk
2006-03-23 16:10:27 UTC
Permalink
Na razie sprostuję tylko nieścisłości.
Dokładnie to samo dzieje się z Linuxem, który "szanse na stanie się
konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i jakoś
zdecydowanie za mało z tego korzysta.
Linux powstał w 1991 roku, czyli 20 lat temu nie istniał w ogóle.
A przez pierwszych parę lat raczej był zabawką, więc na początku
nikt nie mówił o szansach na stanie się konkurencyjnym.
1. Java w ogóle nie nadaje się do programowania czegokolwiek. Z mojego
brak odpowiednika plików nagłówkowych
Nie, to co innego. Sęk w tym, że plik nagłówkowy C++ zawiera więcej
niż interfejs biblioteki. Albo raczej zawiera interfejs z punktu
widzenia kompilatora, a nie z punktu widzenia programisty. Czyli
zawiera m.in. treści funkcji inline i szablonów, prywatne pola klas,
których jakiekolwiek pola albo metody są eksponowane (chyba że rzeźbimy
z pimpl) oraz wszystkie zależności powyższych, tzn. definicje potrzebne
do zaimplementowania tych funkcji inline, do opisania typów prywatnych
metod itd.

Pierwszy z brzegu przykład: aalib.h. To jest C, a nie C++, ale sprawy
plików nagłówkowych są w tych językach prawie te same. Oto wybrane
elementy "interfejsu":

#ifndef __AALIB_INCLUDED__
#define __AALIB_INCLUDED__
#include <stdio.h>

/* The -malign-double switch changes binarry compatibility with structures
containing floating point values. To avoid this, set alignment manually
to old value. */

#ifdef __GNUC__
#ifdef __i386__
#define __AA_ALIGN __attribute__ ((__aligned__ (4)))
#define __AA_NOALIGN __attribute__ ((__packed__))
#endif
#endif
#ifndef __AA_ALIGN
#define __AA_ALIGN
#endif
#ifndef __AA_NOALIGN
#define __AA_NOALIGN
#endif

/*
* aa_context contains information about the display. It is passed to most
* of AA-lib functions. The full definition of structure is present just
* for compatibility with older programs. Dirrect access to it's fields
* is not recommended, because you might surfer to problems with future
* releases of AA-lib. Use standard AA-lib functions instead.
*/
struct aa_context {
__AA_CONST struct aa_driver *driver; /*Current display driver */
__AA_CONST struct aa_kbddriver *kbddriver; /*Current keyboard driver */
__AA_CONST struct aa_mousedriver *mousedriver; /*Current mouse driver */
struct aa_hardware_params __AA_NOALIGN params; /*Parameters of output
hardware used by AA-lib. */
struct aa_hardware_params __AA_NOALIGN driverparams; /*Parameters of output
hardware as reported
by display driver. */
int mulx, muly; /* Ratio of character size over pixel size */
int imgwidth, imgheight; /* Dimensions of emulated image */
unsigned char *imagebuffer; /* Virtual buffer containing image */
unsigned char *textbuffer; /* Virtual buffer containing text */
unsigned char *attrbuffer; /* Virtual buffer containing attributes */
unsigned short *table; /* Precalculated values used by rendering
algorithm.

WARNING!
It is _strongly_ depreached
to access fields behind this point, because
they can change in future releases.*/
unsigned short *filltable;
struct parameters *parameters;
int cursorx, cursory, cursorstate; /* Cursor possition. */
int mousex, mousey, buttons,mousemode; /* Mouse state. */
void (*resizehandler) (struct aa_context *); /* Handler to be called when
resize happends. */
void *driverdata; /* Internal data used by hardware drivers. */
void *kbddriverdata;
void *mousedriverdata;
};

/*
* The hardware driver specification. Used internally by AA-lib only.
* Provided for compatibility with older programs.
*/
struct aa_driver {
__AA_CONST char *shortname, *name;
int (*init) (__AA_CONST struct aa_hardware_params *, __AA_CONST void *, struct aa_hardware_params *,void **);
void (*uninit) (struct aa_context *);
void (*getsize) (struct aa_context *, int *, int *);
void (*setattr) (struct aa_context *, int);
void (*print) (struct aa_context *, __AA_CONST char *);
void (*gotoxy) (struct aa_context *, int, int);
void (*flush) (struct aa_context *);
void (*cursormode) (struct aa_context *, int);
};

/* This macro implementations are proved for faster compilation. */
#ifdef __GNUC__
/* The putpixel macro can be implemented reliably only using GNU-C extension. */
#define aa_putpixel(c,x,y,color) ({aa_context *___aa_context=(c); ((___aa_context)->imagebuffer[(x)+(y)*(aa_imgwidth(___aa_context))]=(color)); 0;})
#endif
#define aa_setpalette(palette,index,r,g,b) ((palette)[index]=(((r)*30+(g)*59+(b)*11)>>8))
#define aa_recommendhikbd(t) aa_recommendhi(&aa_kbdrecommended,t);
#define aa_recommendhimouse(t) aa_recommendhi(&aa_mouserecommended,t);
#define aa_recommendhidisplay(t) aa_recommendhi(&aa_displayrecommended,t);
#define aa_recommendlowkbd(t) aa_recommendlow(&aa_kbdrecommended,t);
#define aa_recommendlowmouse(t) aa_recommendlow(&aa_mouserecommended,t);
#define aa_recommendlowdisplay(t) aa_recommendlow(&aa_displayrecommended,t);
#define aa_scrwidth(a) ((a)->params.width)
#define aa_scrheight(a) ((a)->params.height)
#define aa_mmwidth(a) ((a)->params.mmwidth)
#define aa_mmheight(a) ((a)->params.mmheight)
#define aa_imgwidth(a) ((a)->imgwidth)
#define aa_imgheight(a) ((a)->imgheight)
#define aa_image(c) ((c)->imagebuffer)
#define aa_text(c) ((c)->textbuffer)
#define aa_attrs(c) ((c)->attrbuffer)
--
__("< Marcin Kowalczyk
\__/ ***@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Sektor van Skijlen
2006-03-23 18:37:36 UTC
Permalink
Post by Marcin 'Qrczak' Kowalczyk
Na razie sprostuję tylko nieścisłości.
Dokładnie to samo dzieje się z Linuxem, który "szanse na stanie się
konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i jakoś
zdecydowanie za mało z tego korzysta.
Linux powstał w 1991 roku, czyli 20 lat temu nie istniał w ogóle.
A przez pierwszych parę lat raczej był zabawką, więc na początku
nikt nie mówił o szansach na stanie się konkurencyjnym.
Kurde, 10 lat, nie 20. Porąbało mi się. A co do powstania, to kojarzył mi się
raczej rok 1992.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Sebastian Kaliszewski
2006-03-23 17:11:32 UTC
Permalink
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.
Przyznaję, nie dysponuję aktualnie żadnymi statystykami dotyczącymi użycia C++
w przemyśle i porównania z podobnymi statystykami dotyczącymi Javy. Jakiś czas
temu ktoś gdzieś (bodaj tu) rzucił statystykami, dotyczącymi tylko OpenSource,
które wskazywały, że C i C++ razem mają jakieś 60%, a Java ok 11%. Mówię z
pamięci. Po pierwsze, jednak, statystyki OpenSource nie są miarodajne dla
całego rynku, a po drugie, to było jakieś dwa lata temu i wiele mogło się
zmienić.
Co prawda widzę dość sporo dziedzin, w których Java raczej nie ma czego
szukać, ale już tu czytam jak to pewien osobnik obserwuje, jak firmy na gwałt
wycofują się z C++ i przechodzą na Javę. Co prawda trzeba to traktować z
drobnym przymrużeniem oka, ale myślę, że to nie jest uzasadnione.
Oczywiście jeśli C++ okaże się kiedyś narzędziem nie spełniającym wymagań dla
pisanego przez mnie oprogramowania i znajdą się lepsze, to zostawię C++ i nie
będę po nim płakał. Tak samo, jak olałem swego czasu Amigę, komputer, który w
czasach swej świetności bił na głowę PC pod każdym względem (w tym ceną), a
potem przez przez zatrzymanie się w rozwoju (i jakieś fatum, które powodowało,
że kolejno przejmujące ją firmy plajtowały) dała się PC przegonić. I też nie
było mi jej żal. Przestałem mówić dobrze o Amidze, kiedy słyszałem o super
karcie graficznej dla Amigi (jakby ktoś chciał Amigę stosować profesjonalnie;
ciekawe że podobno miały to założenie spełniać układy wbudowane), która
zawierała po prostu... układzik S3. Przy czym była trzykrotnie większa od
PC-owego odpowiednika i prawie dziesięciokrotnie droższa :)
Ale jak na razie nie widzę, żeby z C++ miało zejść ze sceny, co więcej, w
pewnych zastosowaniach, jak chociażby oprogramowanie na wbudowanych systemach
czasu rzeczywistego, nie wyobrażam sobie zastąpienia go czymkolwiek innym.
Moim zdaniem fakt, że Java zastępuje C++ w pewnych zastosowaniach wynika m.in.
stąd, że dla Javy opracowano pewne wygodne technologie do pisania złożonych,
rozproszonych aplikacji, aplikacji opartych o klient-serwer, a dla C++ trochę
nie bardzo. A przynajmniej nie słyszałem o niczym powalającym. Miałem krótki
kontakt z projektem, w którym goście przepisywali na Javę coś, co działało na
C++ z COM-em. W takim, chociażby, przypadku, muszę przyznać, że owszem, COM
jest -delikatnie mówiąc- "nienajlepszą" technologią, ale lepszej o tym samym
zastosowaniu do C++ nie wymyślono, a do Javy tak. Problem polega zatem na tym,
że o ile do Javy opracowano mnóstwo narzędzi, bibliotek, technologii,
metodologii i innych różnych pierduł - co z tego, że co najmniej 60% to
bzdety, w końcu dzieła wybitne powstają przez rafinację badziewia - a C++
długo pod tym względem kulał i porównując z Javą niestety kuleje nadal.
Inaczej mówiąc, C++-owi brakuje głównie wszelkich aktywności okołojęzykowych i
jakiegoś sensownego marketingu. Jak to się dzieje, że nt. Javy jest tak dużo
tego typu aktywności, a jeśli chodzi o C++ to Stroustrup tylko raz na jakiś
czas ponarzeka, że ludzie nie publikują swoich sukcesów z C++?
Zresztą, jeśli oczywiście jakiś inny język/inna technologia z pewnych względów
jest lepsze, to dobrze, niech będzie stosowana. Jeśli C++ jest gorszy, to
niech się go nie stosuje. Ale to dla mnie w dalszym ciągu nie tłumaczy,
dlaczego tak wielu ludzi wykazuje się w stosunku do C++ wręcz nienawiścią. No
bo jak inaczej mam nazwać wypowiedzi, które życzą C++, aby jak najszybciej
zszedł ze sceny, "Goodbye C++", "- C++ jeszcze długo się będzie trzymał ;
- Eee tam nie bądźmy takimi pesymistami" i tak dalej?
Nie wiem, na ile ktoś czytuje np. grupę pl.comp.objects, ale raz na jakiś czas
ta grupa stawała się czymś w rodzaju "centrum nienawiści do C++". A wątki nt.
tego, jak to ludzie nie lubią C++ potrafią ciągnąć się długo i namiętnie. I to
jeszcze, żeby ktoś wskazywał na jego konkretne słabości i różne cechy, które
utrudniają jego stosowanie czy coś w tym sensie - ale gdzie tam. Większość
wypowiedzi to stanowcze stwierdzenia, że C++ to straszne badziewie. Kurde,
nie można pogadać np. o technologiach, które ludzie lubią, a C++ po
prostu olać?
Widzę w tym wszystkim po prostu wylewanie frustracji w związku z tym, że
"znowu w życiu komuś nie wyszło" z C++. Najwyraźniej Java stała się dla tych
sfrustrowanych jakimś wielkim ratunkiem i to nawet z depresji, chociaż biorąc
pod uwagę aktywność takich opinii, nie założyłbym się. Mimo swoich
właściwości, wciąż wychodzi na to, że C++ co najwyżej powoli zastępuje język
C [kolejność zdania normalna: podmiot-orzeczenie-dopełnienie! :)], a do
pisania dużych aplikacji - być może, bo jak mówię statystyk nie znam -
przestaje się go stosować. Czy C++ nie stać na to, żeby mieć dobre technologie
do łatwego i bezproblemowego pisania dużych aplikacji? Oczywiście, że stać.
Właśnie tu jest problem. Dla innych języków wiele, wiele narzędzi robi się
po prostu łatwiej, a dla C++ wiele rzeczy jest bardzo trudne albo wręcz
praktycznie nierealizowalne (albo też jeśli da się zrealizować to w sposób
brzydki, "hackerski" i wymagający dodatkowych nakładów pracy).

O co chodzi?
* Składnia sama w sobie jest parszywa w parsowaniu a gdy dojdzie preprocesor
robi się fatalnie. Narzędzia które dla statycznie typowanego języka powinny
być stosunkowo prostre w realizacji stają się bardzo trudne (albo
niedokładne). Nawet zrobienie głupiego generatora dokumentacji robi się
nietrywialne. A co z narzędziami robiącymi reverse engineering do UMLa,
automatyzacją refaktoryzacji, itd...
* Wiele rzeczy które w innych językach jest niejako dane, w C++ robi się
przynajmniej nietrywialne (ot, choćby generyczna serializacja obiektów,
przezroczysta integracja z różnymi middlewarami, itd.)

Ponadto w innych językach dających bardziej rozbudowaną bibliotekę pewne
rzeczy robi się w sposób jednolity -- wiadomo jak obsłużyć wątki, sockety,
wyrażenia regularne, itp, itd... W C++ każdy robi inaczej, a więc:
* Nie da się zrobić w pełni uniwersalnych narzedzi typu generator kodu które
wychodzą poza ubogą funkcjonalność biblioteki standardowej -- tak więc
powstają różne rozwiązania "specific", nieprzenośne, trudne w integracji z
rozwiązaniami z zewnątrz itd...
* Jak zmieniasz firmę (albo i często po prostu zespół/projekt) musisz
poświęcić dodatkowy czas na nauczenie się całego zestawu bibilitek robiącego
to samo co używany poprzednio, tylko nieco inaczej
* Jak zachodzi potrzeba zintegrowania różnych dotychczas niezależnych
rozwiązań to są problemy -- jeden używa tej biblioteki wyrażeń regularnych,
drugi innej, jeden używa jednej metody serializacji a drugi innej, ten używa
pthreadów a ten nie, itp., itd.
Potem są jazdy -- np. chcesz skleić biliotekę używającą OmniORB z enginem
skrypotowym perla i całość wbudować do Apache 1.3.x -- nie ma lekko (nie da
się, bo jedno wymaga wątków a drugie wątków nie toleruje) -- ot przykład z
życia, brak standardów odbija się czkawką (najprostszym wyjściem okazało się
zastąpienie OmniORBa czymś innym)
Post by Sektor van Skijlen
Czy dodanie odśmiecacza w nowym standardzie coś tu zmieni? Oczywiście, że nie
zmieni. I to nie dlatego, że wprowadzony zostanie tak późno, tylko dlatego, że
nikt nie opracuje technologii tworzenia aplikacji konkurencyjnych dla
istniejących i dobrze trzymających się rozwiązań (i to akurat wiem, bo jak
społeczność C++ cokolwiek w tym względzie zmieni pierwszy raz od 20 lat to mi
kaktus na dłoni wyrośnie). Dokładnie to samo dzieje się z Linuxem, który
"szanse na stanie się konkurencyjnym dla Windowsa" ma już od dobrych 20 lat i
jakoś zdecydowanie za mało z tego korzysta.
Może to też kwestia tego, że C++ jest dla niektórych za trudny? Słyszę o tym
od dawna, ale jakoś nie chce mi się w to wierzyć.
Niestety, ale to jest jeden z powodów.
Post by Sektor van Skijlen
Kwestię arytmetyki
wskaźników to może olejmy, bo tego argumentu nie można traktować poważnie.
Wskaźniki to mały problem. Jest cała paka różnych pułapek czekających na
niespodziewającego się niczego niedoświadczonego programistę.
Post by Sektor van Skijlen
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
C++ nie bardzo może pozbyć się różnych pułapek, bo by to złamało zgodność
wstecz.

A co do technologii okołojęzykowych to tu, jak już pisałem wyżej, złożonosć
samego języka z jednej strony (już na poziomie parsowania) a zybt uboga
biblioteka z drugiej rzecz bardzo utrudniają i ograniczają.


pzdr
--
Sebastian Kaliszewski
Sektor van Skijlen
2006-03-23 22:44:16 UTC
Permalink
Post by Sebastian Kaliszewski
Właśnie tu jest problem. Dla innych języków wiele, wiele narzędzi robi się
po prostu łatwiej, a dla C++ wiele rzeczy jest bardzo trudne albo wręcz
praktycznie nierealizowalne (albo też jeśli da się zrealizować to w sposób
brzydki, "hackerski" i wymagający dodatkowych nakładów pracy).
O co chodzi?
No ciekawe.
Post by Sebastian Kaliszewski
* Składnia sama w sobie jest parszywa w parsowaniu a gdy dojdzie preprocesor
robi się fatalnie. Narzędzia które dla statycznie typowanego języka powinny
być stosunkowo prostre w realizacji stają się bardzo trudne (albo
niedokładne). Nawet zrobienie głupiego generatora dokumentacji robi się
nietrywialne. A co z narzędziami robiącymi reverse engineering do UMLa,
automatyzacją refaktoryzacji, itd...
Doxygen sobie radzi. Moc sobie radzi. Eclipse/CDT też sobie radzi. Nie
sprawdzałem, czy CDT ma jakieś narzędzia do refaktoryzacji (pomijając już
fakt, że mi się ta automatyczno-wspomagana refaktoryzacja cienko widzi).

Nie wiem, na ile jest możliwe wykorzystanie dla C++ parsera z gcc. Ale jeśli
jest to możliwe, to nie widzę problemu. Niech się goście z gcc martwią.
Post by Sebastian Kaliszewski
* Wiele rzeczy które w innych językach jest niejako dane, w C++ robi się
przynajmniej nietrywialne (ot, choćby generyczna serializacja obiektów,
Nie no zgodzę się, że jak w samym języku masz zdefiniowany sposób serializacji
obiektu, to serializuje się łatwo. A w C++ jest to nietrywialne i to nie z
powodu wskaźników, tylko z powodu nieistnienia takicgo mechanizmu (a
przynajmniej sposób serializowania trzeba określić).

Z drugiej strony, ciekawi mnie, czy serializacja wskazanych obiektów to jest
to, o co nam chodzi. Nie każdy obiekt zawiera takie dane, które powinny być
serializowane.
Post by Sebastian Kaliszewski
przezroczysta integracja z różnymi middlewarami, itd.)
Co takiego?
Post by Sebastian Kaliszewski
Ponadto w innych językach dających bardziej rozbudowaną bibliotekę pewne
rzeczy robi się w sposób jednolity -- wiadomo jak obsłużyć wątki, sockety,
Jeśli chcesz mi powiedzieć, że to wszystko robi się w Javie wg standardu, to
musiałbyś liczyć na znacznie niższą od mojej mizernej znajomości Javy.
Post by Sebastian Kaliszewski
* Nie da się zrobić w pełni uniwersalnych narzedzi typu generator kodu które
wychodzą poza ubogą funkcjonalność biblioteki standardowej -- tak więc
powstają różne rozwiązania "specific", nieprzenośne, trudne w integracji z
rozwiązaniami z zewnątrz itd...
Ciekawe, że jakoś Rational Rose i Rhapsody radzą sobie z tym bez najmniejszych
problemów.

A że w wygenerowanym kodzie korzysta z jakichś własnych bibliotek? Kogo to
obchodzi? Ma działać i tyle.
Post by Sebastian Kaliszewski
* Jak zmieniasz firmę (albo i często po prostu zespół/projekt) musisz
poświęcić dodatkowy czas na nauczenie się całego zestawu bibilitek robiącego
to samo co używany poprzednio, tylko nieco inaczej
No, jeśli w jednej firmie używałem Rhapsody, a w drugiej Rational Rose, to
definitywnie będę się musiał trochę pouczyć, niezależnie od tego, jak bardzo
się te biblioteki między soba różnią.
Post by Sebastian Kaliszewski
* Jak zachodzi potrzeba zintegrowania różnych dotychczas niezależnych
rozwiązań to są problemy -- jeden używa tej biblioteki wyrażeń regularnych,
drugi innej, jeden używa jednej metody serializacji a drugi innej, ten używa
pthreadów a ten nie, itp., itd.
Wiesz, te twoje wywody jadą na odległość takim teoretyzmem, że to aż śmieszne.

Tak, jasne, pewnie kilku bibliotek do wyrażeń regularnych używa się w obrębie
tego samego zespołu, a nawet tego samego projektu. A może nawet w tym samym
module używa się dwóch różnych bibliotek, bo jedna ma to, druga ma tamto.

I może jeszcze chcesz mi powiedzieć, że w Javie tego burdelu nie ma. No jasne.
Pożartujmy sobie jeszcze.
Post by Sebastian Kaliszewski
Potem są jazdy -- np. chcesz skleić biliotekę używającą OmniORB z enginem
skrypotowym perla i całość wbudować do Apache 1.3.x -- nie ma lekko (nie da
się, bo jedno wymaga wątków a drugie wątków nie toleruje) -- ot przykład z
życia, brak standardów odbija się czkawką (najprostszym wyjściem okazało się
zastąpienie OmniORBa czymś innym)
No cóż, nie mogę tego określić inaczej, niż złym doborem zestawu narzędzi do
zintegrowania. W szczególności ten engine skryptowy, bo jak się domyślam, to
ta część właśnie nie tolerowała wątków.

Nie mów mi nic o standardach wspominając jednocześnie Perla.
Post by Sebastian Kaliszewski
Post by Sektor van Skijlen
Może jednak właśnie chodzi o to, że niektórym potrzeba takich klapek na
oczach, żeby byli w stanie cokolwiek zaprogramować? Może, ale nawet jeśli tak
jest, to nie ma co na nich wyrzekać, tylko się dostosować. Bez dostosowania
się do "przeciętnego użytkownika" nie można liczyć na sukces. A bez tego na
pewno nie można liczyć na rozwój technologii okołojęzykowych. I bez tego na
pewno C++ czeka los Lispa, czy Eiffla.
C++ nie bardzo może pozbyć się różnych pułapek, bo by to złamało zgodność
wstecz.
Pozbyć może i nie, ale może udałoby się ustalić reguły, przez które tych
pułapek by nie było?
Post by Sebastian Kaliszewski
A co do technologii okołojęzykowych to tu, jak już pisałem wyżej, złożonosć
samego języka z jednej strony (już na poziomie parsowania) a zybt uboga
biblioteka z drugiej rzecz bardzo utrudniają i ograniczają.
Wydaje mi się, że stanowczo przesadzasz. No, może co do biblioteki to się
zgodzę.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Seweryn Habdank-Wojewódzki
2006-03-23 22:21:50 UTC
Permalink
Witam
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.
Znaczy się dawno nie było dobrego flame ;-).

Coś chyba jesteś przemęczony pracą - może urlop?
Post by Sektor van Skijlen
Przyznaję, nie dysponuję aktualnie żadnymi statystykami dotyczącymi użycia
C++ w przemyśle i porównania z podobnymi statystykami dotyczącymi Javy. Jakiś
czas temu ktoś gdzieś (bodaj tu) rzucił statystykami, dotyczącymi tylko
OpenSource, które wskazywały, że C i C++ razem mają jakieś 60%, a Java ok
11%. Mówię z pamięci. Po pierwsze, jednak, statystyki OpenSource nie są
miarodajne dla całego rynku, a po drugie, to było jakieś dwa lata temu i
wiele mogło się zmienić.
Na stronach komerchy jest aktualne zapotrzebawanie pracodawcow na
języki/technologie/systemy/whatever.

http://wlodarek.com/komercha/ranking/

Jest to proste badanie, które coś pokazuje, pewnych rzeczy nie pokazuje - mnie
ono się podoba. Kilka mięsięcy temu Java byla numer 1 dzis juz nie. Nie ma
znaczenia jak się ono ma do innych statystyk, ważne jest jaka dynamika
występuje wewnątrz tej statystyki. Języki C i C++ generalnie utrzymują się na
stałym poziomie odkąd ta strona ruszyła, a inne sprawy pływają. Ale do
rzeczy ...

Może trochę aby poprawić Ci Sektorze chumor powiem kilka słów od siebie. W
moich zastosowaniach tylko C i C++ się spełniają. Programuje zintegrowane
systemy obliczeniowe. Zagadnienia, w które wchodzę to programowanie gridów ew.
klastrów, dalej same w sobie dedykowane serwery obliczeń (to jest największa
kobyła z tego co piszę) plus algorytmy obliczeniowe na sprzęcie.

Kiedyś też myślałem, że "Java rulez" Szczególnie tak myślałem, kiedy
(2001/2002) w zespole pisaliśmy serwer obliczeniowy (symulator procesów
stalowniczych) i klienta w javie. Ekipa C++, w której byłem, pisząca serwer
obliczeniowy posuwała sie powolutku do przodu. Klient w Javie pisany był
szybko, bardzo szybko. Ale dziś patrząc na ten projekt widzę, że tak na prawdę
tylko kod C/C++ przetrwał. Java sama z siebie sie tak zmienila, ze kod pisany
wtedy poprostu nie kompiluje sie. Pewnie przepisali go juz kilka razy od zera,
albo zarzucili sprawę.

Dziś patrząc na historię bibliotek numerycznych widzę, że C i C++ są optymalne,
bo fortran jest rzadko używany. Poza tym można bibliotekę napisaną w fortranie
można załadować do C, czego nie można powiedzieć o Javie.

Co mnie totalnie odstarszyło od javy i obliczeń. Prosta sytuacja jakiś 1.5 roku
temu. Zaladowalem, nazwijmy to, pliczek konfiguracyjny do systemu (ok. 200 000
lini danych) java domyslnie tego nie łyka - potrzeba pisac:

java -Xmx tyle_MB_ile_jest_dostepne_na_maszynie nazwa_aplikacji

Czyli zamiast po prostu z lini polecen odpalac aplikacje, musze miec skrypt
startowy ktory to robi. Na dodatek w windows nie ma /proc/meminfo wiec trzeba
miec aplikacje dodatkowa, ktora automatycznie zwroci ilosc pamieci w systemie,
bo jak powiem userowi, zeby sobie sam recznie wpisywal ilosc ramu do skryptu
to przeciez mnie powiesi. W *X jesli jest /proc/meminfo lub podobne to tylko
przeba grep i sed i skrypcik dziala. No ale to mi przypomina czasy dos'a,
kiedy trzeba bylo odpalac jakiegos *.bat, który odpalal aplikację i pytal
uzytkownika, czy ma karte CGA czy EGA ;-).

W C/C++ nie mialem nigdy z tym problemu, po prostu system jest system. I
jeszcze tak na dokladke nie liczac prawdziwych bajtow danych tylko tekstowe
jezeli plik tekstowy zajmowal X MB to w Javie po zaladowaniu do pamieci
zajmowal ok 7 razy tyle, a w C/C++ 2 razy tyle - stosujac kompatybilne
kontenery wewnątrz kodu programu. Dla mnie nie ma znaczenia czy GC sobie
zarezerwowal troche pamieci na niby - zabral wiecej i tyle. Gdybym miał
dłuższy plik to by mi go program nie zaladowal i tyle, bo CG nie ma różnych
strategii pracy.

Sam czas pracy zaprogramowanego systemu obliczeniowego dla pliku z 200 000
rekordami danych. Według kolejnych implementacji.

Matlab -> 1 dzień obliczeń.
Java -> 10 minut.
C++ -> 1.5 minuty.

Co do bibliotek. W Javie są dwa rodzaje użytkowników, tacy którzy maja klasy
zawarte w głównych drzewie klas i to dziala każdemu wszyscy się cieszą maja do
wyboru po jednej metodzie do kazdej sprawy. Kiedy jednak trzeba coś, że tak
powiem, zassać z sieci to już nie jest tak różowo. W C/C++ i w Javie jest
wiele różnych bibliotek i jeżeli zaczynamy twórczo grymasić - szukamy
optymalnego rozwiązania dla aplikacji to czary pryskają. Dokumentacje są takie
jakie są o ile są. Generalnie nie ma takiej rzeczy w C/C++ dla której nie ma
biblioteki, a która to była by w Javie. Mówię tu oczywiście cały czas o
obliczeniach. Jest natomiast tak, że są biblioteki w C/C++ a nie ma ich w
Javie - ot tak np. dobra implementacja filtru Kalmana.

Juz strasznie dużo napisałem, ale jeszcze po ostatnich lekturach
(Aleksandrescu; Abahams, Gurtovoy; Josuttis, Vandervoorde) muszę dać
świadectwo. METAPROGRAMOWANIE w szerokim tego slowa znaczeniu jest w C++ super
w Javie nie ma go z definicji typów uogólnionych (potocznie zwanych
generiksami - trochę mnie telepie jak słyszę to słowo).

Z mojego punktu widzenia, kiedy mogę konstrukcje podobne do GSL - czyli wieczna
praca na wskaźnikach do funckcji zamienić na odpowiednio "cechowane" i
"wytyczane" szablony jest bardzo dobra. Nie mówię już o takich cudeńkach jak
są zawarte w boost::mpl kiedy na poziomie statycznej typizacji nie da się
dodać "float" masa do "float" siła. W C źle ustawiony skaźniczek wiadomo czym
się kończy, w Javie zazwyczaj "Null pointer exception", a w C++ no cóż, błędów
związanyc z szablonami nie cytuje się, ale pojawiają się w czasie kompilacji,
a nie po 30 godzinach pracy programu na prezentacji i klienta. Ostatnio
zresztą na grupie zarzuciłem temacik grupowanie klas tego nie da się
naturalnie zrobić w Javie, choć pewne triki są możliwe. Z resztą w javie nie
ma wieloczedziczenia, tylko są wielo-interfejsy co jest pewnego rodzaju
samosprzecznością, ale to jest insza inszość.

Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
`\/\/
Sektor van Skijlen
2006-03-24 11:29:37 UTC
Permalink
Post by Seweryn Habdank-Wojewódzki
Witam
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.
Znaczy się dawno nie było dobrego flame ;-).
No, nie musiałeś tego mówić aż tak wprost :)
Post by Seweryn Habdank-Wojewódzki
Coś chyba jesteś przemęczony pracą - może urlop?
Mam ponad 30 dni zaległego urlopu. Ale muszę wykombinować najpierw jakiś
fajno-sensowny sposób na jego spędzenie.
Post by Seweryn Habdank-Wojewódzki
Na stronach komerchy jest aktualne zapotrzebawanie pracodawcow na
języki/technologie/systemy/whatever.
http://wlodarek.com/komercha/ranking/
Trochę niepocieszające z jednej strony, ale z drugiej trzeba pamiętać, że
statystyki w Polsce trochę się różnią od reszty świata (zwróciłem też uwagę na
Perla i Tcl-a :).
Post by Seweryn Habdank-Wojewódzki
Kiedyś też myślałem, że "Java rulez" Szczególnie tak myślałem, kiedy
(2001/2002) w zespole pisaliśmy serwer obliczeniowy (symulator procesów
stalowniczych) i klienta w javie. Ekipa C++, w której byłem, pisząca serwer
obliczeniowy posuwała sie powolutku do przodu. Klient w Javie pisany był
szybko, bardzo szybko. Ale dziś patrząc na ten projekt widzę, że tak na prawdę
tylko kod C/C++ przetrwał. Java sama z siebie sie tak zmienila, ze kod pisany
wtedy poprostu nie kompiluje sie. Pewnie przepisali go juz kilka razy od zera,
albo zarzucili sprawę.
Taaa... i ciekaw jestem co na to ci, którzy twierdzą, że w Javie cokolwiek
jest standardowe, trwałe, stabilne...
Post by Seweryn Habdank-Wojewódzki
Dziś patrząc na historię bibliotek numerycznych widzę, że C i C++ są optymalne,
bo fortran jest rzadko używany. Poza tym można bibliotekę napisaną w fortranie
można załadować do C, czego nie można powiedzieć o Javie.
Jak to nie? A native?
Post by Seweryn Habdank-Wojewódzki
Co mnie totalnie odstarszyło od javy i obliczeń. Prosta sytuacja jakiś 1.5 roku
temu. Zaladowalem, nazwijmy to, pliczek konfiguracyjny do systemu (ok. 200 000
java -Xmx tyle_MB_ile_jest_dostepne_na_maszynie nazwa_aplikacji
Czyli zamiast po prostu z lini polecen odpalac aplikacje, musze miec skrypt
startowy ktory to robi. Na dodatek w windows nie ma /proc/meminfo wiec trzeba
miec aplikacje dodatkowa, ktora automatycznie zwroci ilosc pamieci w systemie,
bo jak powiem userowi, zeby sobie sam recznie wpisywal ilosc ramu do skryptu
to przeciez mnie powiesi. W *X jesli jest /proc/meminfo lub podobne to tylko
przeba grep i sed i skrypcik dziala. No ale to mi przypomina czasy dos'a,
kiedy trzeba bylo odpalac jakiegos *.bat, który odpalal aplikację i pytal
uzytkownika, czy ma karte CGA czy EGA ;-).
To jest właśnie - w odróżnieniu od "zasobożerności", czyli ilość zużytych
zasobów w stosunku do złożoności problemu - osobny współczynnik, zwany
"krwiożerczość". Krwiożerczość programu, który przy zwiększeniu pamięci
dostępnej w systemie o tyle samo zwiększa swoje zapotrzebowanie na pamięć,
wynosi 100%.

A wydawało mi się kiedyś, że programy, w których krwiożerczość jest większa od
zera, odeszły w przeszłość. No ale niestety przecież jest Java. Wygląda na to,
że nawet pierwsze prawo Gatesa nie pozwoli takowym zginąć.
Post by Seweryn Habdank-Wojewódzki
W C/C++ nie mialem nigdy z tym problemu, po prostu system jest system. I
jeszcze tak na dokladke nie liczac prawdziwych bajtow danych tylko tekstowe
jezeli plik tekstowy zajmowal X MB to w Javie po zaladowaniu do pamieci
zajmowal ok 7 razy tyle, a w C/C++ 2 razy tyle - stosujac kompatybilne
kontenery wewnątrz kodu programu. Dla mnie nie ma znaczenia czy GC sobie
zarezerwowal troche pamieci na niby - zabral wiecej i tyle. Gdybym miał
dłuższy plik to by mi go program nie zaladowal i tyle, bo CG nie ma różnych
strategii pracy.
Ha! Cóż, co prawda pierwsze prawo Gatesa pozwala żyć takim programom, które
zużywają 7* więcej pamięci, niż mamy danych, ale z drugiej strony drugie prawo
Gatesa pozwala się C++-owi wstrzelić tam, gdzie Java stuknie głową w sufit.
Post by Seweryn Habdank-Wojewódzki
Sam czas pracy zaprogramowanego systemu obliczeniowego dla pliku z 200 000
rekordami danych. Według kolejnych implementacji.
Matlab -> 1 dzień obliczeń.
Java -> 10 minut.
C++ -> 1.5 minuty.
Gdzieś już czytałem o wyniku "120% wolniejsza". Dziś już jest lepiej, ale nie
są to powalające wyniki.
Post by Seweryn Habdank-Wojewódzki
Juz strasznie dużo napisałem, ale jeszcze po ostatnich lekturach
(Aleksandrescu; Abahams, Gurtovoy; Josuttis, Vandervoorde) muszę dać
świadectwo. METAPROGRAMOWANIE w szerokim tego slowa znaczeniu jest w C++ super
w Javie nie ma go z definicji typów uogólnionych (potocznie zwanych
generiksami - trochę mnie telepie jak słyszę to słowo).
Nie lubię słowa "uogólniony", bo nie oddaje nawet w połowie określenia
"generyczny". Trzeba mówić po ludzku "generyczny" i jest ok. :)
Post by Seweryn Habdank-Wojewódzki
się kończy, w Javie zazwyczaj "Null pointer exception", a w C++ no cóż, błędów
związanyc z szablonami nie cytuje się, ale pojawiają się w czasie kompilacji,
a nie po 30 godzinach pracy programu na prezentacji i klienta. Ostatnio
No właśnie... oczywiście, że te długaśne błędy są czasami denerujące, ale
uważam, że ludzie stanowczo z tym przesadzają.

Oczywiście nie masz co liczyć, że wszystkowiedzący superautorytet p.
Lewandowski da do tego jakiś rzeczowy komentarz...
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Seweryn Habdank-Wojewódzki
2006-03-24 22:03:31 UTC
Permalink
Witam
Post by Sektor van Skijlen
Post by Seweryn Habdank-Wojewódzki
Znaczy się dawno nie było dobrego flame ;-).
No, nie musiałeś tego mówić aż tak wprost :)
Potrzebowałem sprawdzić czy to jest aby poprawnane "explicit instantiation"
szablonu "flame<typename T>", czyli flame<wyższość C++ nad innymi językami>;
Post by Sektor van Skijlen
Post by Seweryn Habdank-Wojewódzki
Coś chyba jesteś przemęczony pracą - może urlop?
Mam ponad 30 dni zaległego urlopu. Ale muszę wykombinować najpierw jakiś
fajno-sensowny sposób na jego spędzenie.
Jeśli Polska polecam Tatry - jest pięknie.
Jeśli gdzieś indziej - polecam Zimbabwe lub cokolwiek innego bez netu, aby
rzeczywiście odpocząć.
Post by Sektor van Skijlen
Post by Seweryn Habdank-Wojewódzki
Kiedyś też myślałem, że "Java rulez" Szczególnie tak myślałem, kiedy
(2001/2002) w zespole pisaliśmy serwer obliczeniowy (symulator procesów
stalowniczych) i klienta w javie. Ekipa C++, w której byłem, pisząca serwer
obliczeniowy posuwała sie powolutku do przodu. Klient w Javie pisany był
szybko, bardzo szybko. Ale dziś patrząc na ten projekt widzę, że tak na
prawdę tylko kod C/C++ przetrwał. Java sama z siebie sie tak zmienila, ze
kod pisany wtedy poprostu nie kompiluje sie. Pewnie przepisali go juz kilka
razy od zera, albo zarzucili sprawę.
Taaa... i ciekaw jestem co na to ci, którzy twierdzą, że w Javie cokolwiek
jest standardowe, trwałe, stabilne...
Nie wiem, ostatnio prywartnie dla siebie przepisuję na C++ pewien serwer, bo
ktoś go napisał dla java 1.3 i mam stres, kompiluje się na java 5.0 po wielu
poprawkach, ale nie działa zadawalająco. Pomijam fakt, że poprzez to, że w
javie szybciej sie kod klepie to kodu jest napisane dużo, a możnaby go napisac
o wiele lepiej.
Post by Sektor van Skijlen
Post by Seweryn Habdank-Wojewódzki
Dziś patrząc na historię bibliotek numerycznych widzę, że C i C++ są
optymalne, bo fortran jest rzadko używany. Poza tym można bibliotekę
napisaną w fortranie można załadować do C, czego nie można powiedzieć o
Javie.
Jak to nie? A native?
Jasne. To już wiele razy było podnoszone na pl.comp.lang.java. Każdy mówi słowo
kluczowe "natywnie" i nikt tego nie rozwiązuje, pomijam fakt, że jeśli to by
było proste to nikt by nie pisał czegoś takiego jak Java GSL. Kiedyś zresztą
orientowałem się jak Koguta, czy OCAMLa porzucić do javy, no i jest kłopot,
ale to tylko przecież serwery obliczeniowe takie problemy mają. A pieniądze
przecież robi się na sklepach internetowych.
Post by Sektor van Skijlen
To jest właśnie - w odróżnieniu od "zasobożerności", czyli ilość zużytych
zasobów w stosunku do złożoności problemu - osobny współczynnik, zwany
"krwiożerczość". Krwiożerczość programu, który przy zwiększeniu pamięci
dostępnej w systemie o tyle samo zwiększa swoje zapotrzebowanie na pamięć,
wynosi 100%.
Nie całkiem o to mi chodziło. Program nie potrzebował całego RAMu program
potrzebował dużo. I sam nie był wstanie wskazać JVM ile potrzebuje. To musiało
być dane z zewnątrz. A zdrugiej strony niby jak łysa JVM ma wiedzieć że jakiś
program będzie chciał pożreć duzo romu i poto trzeba było mieć skrypt
startowy.
Post by Sektor van Skijlen
Post by Seweryn Habdank-Wojewódzki
Juz strasznie dużo napisałem, ale jeszcze po ostatnich lekturach
(Aleksandrescu; Abahams, Gurtovoy; Josuttis, Vandervoorde) muszę dać
świadectwo. METAPROGRAMOWANIE w szerokim tego slowa znaczeniu jest w C++
super w Javie nie ma go z definicji typów uogólnionych (potocznie zwanych
generiksami - trochę mnie telepie jak słyszę to słowo).
Nie lubię słowa "uogólniony", bo nie oddaje nawet w połowie określenia
"generyczny". Trzeba mówić po ludzku "generyczny" i jest ok. :)
Tak tylko, że w C++ programowanie generyczne - uogólnione a wszczególności
metaprogramowanie jest czymś innym niż w Javie, dlatego w C++ są template a w
Javie generics.

Tak na marginesie, widziałem ogłoszenie parafialne o Javie 6. Ciesze się na nią
bardzo ;-). Mam tylko jedno pytanie, czemu czemu ludzie pracujący nad
standardem C++ myślą o tworzeniu bibliotek faktycznie wspomagających pisanie
programów opartych o uogólnione wzorce projektowe, a ludzie z Javy myślą o
look and feel.
Post by Sektor van Skijlen
No właśnie... oczywiście, że te długaśne błędy są czasami denerujące, ale
uważam, że ludzie stanowczo z tym przesadzają.
Nie ważne jakie są długie, ważne, że pojawiają się na Twoim biurku, a nie w
czasie działania programu u klienta.
Post by Sektor van Skijlen
Oczywiście nie masz co liczyć, że wszystkowiedzący superautorytet p.
Lewandowski da do tego jakiś rzeczowy komentarz...
Szkoda. Choć powiem szczerze, że C++ nie jest językiem do wszystkiego, ale też
nie jest językiem do niczego. Jednak moje doświadczenie pozwala mi stwierdzić,
że w kontekście serwerów obliczeniowych jest jednym z najlepszych. A jeżeli go
supportować językami funkcyjnymi lub dynamicznie kompilowanym kodem i
ładowanymi bibliotekami to po prostu wymiata.

Moim ulubionym przykładem jest adaptacyjnny neuro-rozmyty system decyzyjny
współpracujący z inteligętną bazą danych pracującą w reżimie częściowo
soft-real-time i częściowo hard-real-time. Celem systemu jest samouczenie się
poprzez adaptację i wprowadzanie nowych reguł. Najlepiej jeśli można to
wykonywać pracując w strukturze mieszanej klaster i grid. Ale tak, aby można
było ucząc jeden kawałek systemu automatycznie wiedzę przesyłać do reszty.
Wiedza może być pisana w postaci kodu programu, tworzonego automatycznie lub
ręcznie. Tego nie da się napisać lepiej w Javie niż w C++, a C++ jest szybsze
więc ...

Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
`\/\/
A..L.
2006-03-25 04:23:50 UTC
Permalink
On Fri, 24 Mar 2006 23:03:31 +0100, Seweryn Habdank-Wojewódzki
Post by Seweryn Habdank-Wojewódzki
Moim ulubionym przykładem jest adaptacyjnny neuro-rozmyty system decyzyjny
współpracujący z inteligętną bazą danych pracującą w reżimie częściowo
soft-real-time i częściowo hard-real-time. Celem systemu jest samouczenie się
poprzez adaptację i wprowadzanie nowych reguł. Najlepiej jeśli można to
wykonywać pracując w strukturze mieszanej klaster i grid. Ale tak, aby można
było ucząc jeden kawałek systemu automatycznie wiedzę przesyłać do reszty.
Wiedza może być pisana w postaci kodu programu, tworzonego automatycznie lub
ręcznie. Tego nie da się napisać lepiej w Javie niż w C++, a C++ jest szybsze
więc ...
Moim ulubionym przykladem jest serwer rozwiazujacy uogolniony
problem marszrutowania pojazdow i optymalizacji ladunkow (Pickup -
Delivery Vehicle Routing Problem). System pracuje w czasie ciaglym
(tak zwana "streaming optimization") przetwarzajac u klienta okolo
10 tysiecy zamowien na godzine. Te zamowienia sa przepuszczane przez
optymalizator bedacy mieszanina dosyc niestandardowego algorytmu
genetycznego (ja to nazywam DNA Programming) i algorytmow
obliczeniowych wykorzystujacych "constraint programming". Wszystko
napisane w Javie, dziala dostatecznei szybko aby owe 10 tysiecy
zamowien na godzine przerobic i jeszcze jest troche zapasu jakby sie
znalazl jakis wiekszy klient. Proba zrobienia tego w C++ zniosla
jajo kubiczne, albowiem struktralny asembler nieudolnie wspierajacy
obiektowosc czyli C++ okazal sie dla tego celu zbyt prymitywny.
Niewatpliwie, gdyby w nim sie udalo system napisac, program bylby
szybszy. Tylko nie ma armat, jak mowi anegdotka o Napoleonie. No i
poza tym nie wiadomo po co mialby byc szybszy.


A.L.
Foxy
2006-03-25 09:45:18 UTC
Permalink
Post by A..L.
Post by Seweryn Habdank-Wojewódzki
Moim ulubionym przykładem jest adaptacyjnny neuro-rozmyty system decyzyjny
współpracujący z inteligętną bazą danych pracującą w reżimie częściowo
soft-real-time i częściowo hard-real-time. Celem systemu jest samouczenie
się poprzez adaptację i wprowadzanie nowych reguł. Najlepiej jeśli można
to wykonywać pracując w strukturze mieszanej klaster i grid. Ale tak, aby
można było ucząc jeden kawałek systemu automatycznie wiedzę przesyłać do
reszty. Wiedza może być pisana w postaci kodu programu, tworzonego
automatycznie lub ręcznie. Tego nie da się napisać lepiej w Javie niż w
C++, a C++ jest szybsze więc ...
Moim ulubionym przykladem jest serwer rozwiazujacy uogolniony
problem marszrutowania pojazdow i optymalizacji ladunkow (Pickup -
Delivery Vehicle Routing Problem). System pracuje w czasie ciaglym
(tak zwana "streaming optimization") przetwarzajac u klienta okolo
10 tysiecy zamowien na godzine. Te zamowienia sa przepuszczane przez
optymalizator bedacy mieszanina dosyc niestandardowego algorytmu
genetycznego (ja to nazywam DNA Programming) i algorytmow
obliczeniowych wykorzystujacych "constraint programming". Wszystko
napisane w Javie, dziala dostatecznei szybko aby owe 10 tysiecy
zamowien na godzine przerobic i jeszcze jest troche zapasu jakby sie
znalazl jakis wiekszy klient. Proba zrobienia tego w C++ zniosla
jajo kubiczne, albowiem struktralny asembler nieudolnie wspierajacy
obiektowosc czyli C++ okazal sie dla tego celu zbyt prymitywny.
Nie znam Javy (wyprzedziłem wytykanie mi niekompetencji) i staram się
obiektywnie czytać tę dyskusję. Ale argument "C++ okazał się (...) zbyt
prymitywny" bez podania ani jednej cechy tej prymitywności to jest, za
przeproszeniem, gówno nie argument.
--
Pozdrawiam, Foxy
Wiktor Zychla
2006-03-24 13:00:58 UTC
Permalink
Post by Sektor van Skijlen
Ponieważ aktywność grupy nieco spada, postanowiłem ją nieco rozruszać. Temat
jest z pozoru oklepany, a w rzeczywistości nie taki znów oczywisty.
ładny i adekwatny cytat z Richarda B. Johnsona (znaleziony kiedyś na
www.kerneltraffic.org, tam: w konteście dyskusji o języku programowania dla
jądra, ale idealnie pasuje do dyskusji o wyższości pewnych języków nad
innymi).

nic dodać nic ująć.

Wiktor Zychla

-------------------------------------
It's interesting to observe the advocates of a specific computer language.
Most often a discussion about a particular compiler of similar tool results
from the failure of persons to understand the basic nature of any computer
language.
Computers don't communicate very well, even with other computers. When
humans try to communicate with them, they have to use certain tools. These
tools may range from devices such as keyboards to software tools such as
compilers and editors.

Since computers don't understand the human languages very well, although
there is continual work in this area, humans have to learn computers'
languages. Since the computers' internal languages do not interface well
with human languages, we have created tools to translate. There are called
assemblers, compilers, and interpreters.

Every one of these tools, and probably those to be created in the future,
pose major communications and control limitations. It becomes necessary, for
programmers using these tools, to provide work-arounds for the limitations
of these tools.

An expert in a particular computer language is really an expert in the
work-arounds necessary to use this language to perform useful work. An ideal
computer language would do exactly what it was told simply from reading a
specification. In the absence of a specification, it would ask enough
questions to produce such a specification, then it would generate the code
necessary to perform the specified functions.

So a programmer becomes a captive of the tools used to communicate with the
computer. With experience, the programmer starts to identify with its
captors and starts to believe that the language mastered, is in fact, the
only true language. Once captured, the programmer becomes an advocate.
Psychology teaches the name of this effect as the "Stockholm Syndrome". It
was first recognized during the detention of World-Games competitors in
Stockholm, Sweden.

You see this problem mostly with programmers who have mastered only one
language. If you have been around computers since 4-bit nibbles on
paper-tape, you have long ago abandoned the notion that there is only one
true language. But the first language you truly mastered still seems to have
been the best. The Stockholm Syndrome affects us all to some extent.

I advise to not get trapped into the notion of the "correct" tool for a
particular use. Just because you have become expert in C++, don't presume
that it is the "correct" language for the kernel.

Even C has its shortcomings which have to be handled with assembly language
extensions. A Master Carpenter has many tools and is expert with most of
them. If you only know how to use a hammer, every problem begins to look
like a nail. Stay away from that trap. It bytes (sic).
Kontynuuj czytanie narkive:
Loading...