🚀 go-pugleaf

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

W systemach wbudowanych nie wykorzystuje sie pamięci tak ja na komputerach 
domowych. Tam nie ma tak, że jak mamy 10 razy więcej pamięci, to sobie 
wrzucimy wiecej obrazków, dodamy muzyczkę, jakieś dynamiczne menu i pamięci 
znów mamy mało.

Samego kodu nie da się mnożyć na dużą skalę w nieskończoność. Z pewnością 
jest coraz mniej sytuacji w której ze względu na małą ilość dostępnej 
pamięci, nie można zaimplementować jakieś funkcjonalności w systemie 
wbudowanym. Sprzęt niewielkim kosztem można rozbudować, co jeszcze 
kilkanaście lat temu często nie było możliwe.

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

Przy założeniu, że język C++ jest dedykowany jedynie dla przemysłu, to można 
sie zgodzić z tym, że tempo jego rozoju jest zadowalające.
Niestety takiego założenia przyjąć nie można i mogą rodzić sie słuszne obawy 
o to, że zanim nowy standard zostanie "zaklepany" no i oczywiście wdrożony, 
języka C++ na desktopach mało kto już będzie używał.

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

Zgadza się, trzeba jednak wziąć pod uwagę, że możliwości bibliotek są 
ograniczane przez możliwości samego języka.

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

W swojej kategorii, język C++ wiedzie prym lidera.

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

Jak najbardziej sie zgadzam. Nie wyobrażam sobie języka C++ z innym, niż 
jedynie opcjonalnym system GC.

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

Nikt nie ogłasza zgonu języka C++, ale też nikomu nie chce sie czekać 
kolejnych 10 lat na jego nowszą wersję.

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

Pożyjemy, zobaczymy.

Pozdrawiam.

- Bastek -