🚀 go-pugleaf

On 27 Lut, 14:39, "Sebastian Nibisz" <EB...@poczta.onet.pl> wrote:

> >> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
> >> dzisiaj znacznie mniejsze niż kiedyś.
>
> > To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy
> > aplikacji
> > standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
> > systemach wbudowanych.
>
> Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika powoli
> problem z ilościa dostępnej pamięci.

Nie rozumiem tego powyżej.
Co to znaczy, że gdzieś znika problem z ilością pamięci? Nigdzie nie
znika. Kupuje się większy hardware po to, żeby na nim puszczać większy
software. Problemu pamięci to nie rozwiązuje, jedynie pozwala dalej
ślizgać się po krawędzi. Ja problemy z pamięcią widzę zarowno na
płytach z 64MB jak i z <put-your-favorite-number>GB, bo po prostu
chodzą na nich różne systemy, które mają różne wymagania. Tak samo nie
ma sensu mówić, że autobusy rozwiązują problem samochodów osobowych z
ilością miejsc dla pasażerów. Kto stał w tłoku w szczycie zrozumie.
Inaczej: dla każdej ilości pamięci istnieją programy, które się w niej
nie mieszczą. Problem nigdzie nie "znika". Co więcej, większe programy
są pisane również po to, żeby wykorzystać okazje stwarzane przez
większy hardware. Kręcimy się tak od kilku dekad - każdego roku ktoś z
radością ogłasza, że problem pamięci lub CPU lub dysków itd. "znika",
bo oto np. firma X wyprodukowała dysk twardy o zawrotnej pojemności
80MB (megabajtów), i teraz ludzie w ekstazie nie mają pomysłu, co tam
trzymać. Całą walizkę dyskietek 5.25" można tam zmieścić. Łał.

Bilu też kiedyś myślał, że 640kB każdemy wystarczy - a dzisiaj Visty
poniżej 2GB nie ma po co nawet uruchamiać.

Pytam się więc - co to znaczy, że problem z pamięcią znika?

> >> Faktem jest, że język C++ się praktycznie nie rozwija

Język C++ rozwija się na dwóch płaszczyznach, z dwoma różnymi
prędkościami.
Jedna płaszczyzna to definicja języka, czyli standard - tempo rozwoju
to jedna iteracja na dekadę. Czy to wolno? Moim zdaniem akurat -
przemysł ledwo nadąża z wymianą kompilatorów w tym tempie. Hint:
przemysł to nie jest koleś z laptopem i Ubuntu aktualizowanym z
automatu.
Druga płaszczyzna to biblioteki i narzędzia orbitujące (np. generatory
kodu). To się rozwija dużo szybciej i spokojnie pozwala na
przedłużenie życia C++ w dowolnym obszarze. Hint: nie potrzeba było
zmieniać standardu, żeby pojawił się przykładowy Boost.

> >> i że jeżeli taki
> >> stan
> >> się utrzyma, będzie wiódł prym lidera tylko do czasu.

C++ nie wiedzie prymu lidera, bo nie musi. To jest język, który
świetnie się sprawdza w wymagających zastosowaniach i nie musi być na
topie popularności we wszelkich innych.

Wracając do GC - sam GC nie jest problemem. Problemem jest sytuacja, w
której twórca języka po wrzuceniu do niego GC otrzepuje ręce i
oznajmia, że wszystkie problemy rozwiązał. Efekty takiej
amatorszczyzny widać w Javie, gdzie np. w tutorialu dla początkujących
co chwila jest wołami przypominane, jakie to ważne, żeby zawsze
zamykać strumienie i inne takie. I to jeszcze w odpowiedniej
kolejności. W XXI wieku to jest po prostu *żenujące* (chociaż
początkujący czytelnicy akurat tego nie zauważą), niezależnie od
dostępnych gigabajtów.
To jest też dowód na to, że w Javie GC więcej problemów pozostawił,
niż rozwiązał.

Dodanie GC do C++ może przedłużyć mu życie w wielu obszarach. A
ponieważ wiadomo, że tak się właśnie stanie, to nie ma po co ogłaszać
zgonu.
Co ciekawe, dodanie GC do C++ jest dużo łatwiejsze, niż dodanie
sensownego systemu zarządzania czasem życia obiektów w Javie. Nie
podejmuję się prorokować, jak będą wyglądały rankingi języków za ~5
lat - ale wiem, że będą ciekawe.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com