He, he. Można by dodać:
6. Java - SUV. Na każdą drogę, ale cholernie trudny w prowadzeniu i dużo żre
7. C# - Chrysler z licznikiem w mph. W zasadzie nadaje się głównie na drogi w USA
8. Python - kompaktowa Toyota z automatyczną skrzynią biegów
9. Ruby - j.w. ale skrzynia manualna
10. Visual Basic - Fiat Panda z płytą na lusterku wstecznym. Dla niewymagających
11. PHP - stary VW Golf sprowadzany z Niemiec na lawecie. Co drugi samochód, który mijasz na drodze; przy bardziej wymagającej trasie rozkracza się i nie jedzie dalej.
:D

Ponieważ wpisuje się to w moją prośbę do Nosty'egp, pozwolę się ustosunkować: ochrona danych i operacji wewnętrznych nie jest cechą języków obiektowych: np. w C mamy static i pliki nagłówkowe zawierające interfejs, co jest nawet bardziej elastyczne od public/protected/private. Poza tym public/protected/private ma ograniczoną siłę wyrazu i nie zastąpi całkiem dokumentacji - wystarczy spojrzeć na metody publiczne udokumentowane w .NET jako "infrastructure", to samo w Javie. Garbage collector też nijak ma się do paradygmatu programowania obiektowego.
Nie mówię, że programowanie obiektowe jest niepotrzebne - ma swoje zastosowania. Jednak niepotrzebnie wciska się je do głowy studentom pierwszego roku, którzy w ogóle nie potrafią programować.

to ile flash żre w bardzo dużym stopniu zależny od umiejętności tego kto mu kazał jechać

Pierwsze kompilatory C++ kompilowały się do C. Składnia Objective-C też jest tylko lukrem. Ale nie o to chodzi. Obiektowo możesz programować i w asemblerze co wielokrotnie udowadniano. Najistotniejszą cechą języków wspomagających obiektowość jest wbudowanie pojęcia obiektu w strukturę języka, co pozwala na wczesne wykrywanie błędów.
W sprawie GC osobiście uważam, że błędem jest zabranie programiście władzy nad żywotnością jego obiektów i wbudowanie szemranych, niedeterministycznych mechanizmów w sam język. Wg mnie wzorcem w tej mierze jest C++, w którym zasobami można zarządzać jak komu się żywnie podoba od ręcznego wołania delete, poprzez automatykę bazującą na RAII, aż po GC implementowane bibliotecznie.

Por. D.

Za ochronę przed skutkami pisania po nie swojej pamięci odpowiada współcześnie system operacyjny wespół z MMU.
Pisanie np. poza zakresem tablicy ale w pamięci tego samego procesu to już inna sprawa i w różnych językach można się przed tym bronić łatwiej lub trudniej.
Obie sytuacje mają jednak niewielki związek z GC lub jego brakiem.

Ostatnio edytowany przez epi (2010-08-07 17:10:11)

epi, jell: To był taki skrót myślowy, faktycznie dość niezrozumiały. Miałem na myśli automatyczne zarządzanie pamięcią, w tym alokację i zwalnianie pamięci. Dzięki temu, że nie trzeba przydzielać dodatkowego miejsca przy każdej operacji np. na tablicy, nie ma znanego z C ryzyka "pisania po nie swoim", a automatyczne usuwanie nieużywanych obiektów zapobiega wyciekom pamięci. Bardziej w tych kwestiach ufam twórcom (dojrzałych) języków, niż sobie.
Wiem, że niewiele to ma wspólnego z samym garbage collection; chyba po prostu chciałem wyrzucić z siebie swoją głęboko tłumioną niechęć do C ;)

BartoszP: W samochodzie, aby zmniejszyć zużycie paliwa można po prostu "słabiej naciskać pedał gazu" i jeździć bardziej optymalnie (zwalnianie poprzez zdejmowanie nogi z gazu, a nie częste naciskanie hamulca, hamowanie silnikiem itp) wtedy przy tym samym silniku zużyjemy mniej paliwa :P I wtedy nie jeździ się mniej, tylko nawet więcej, bo nie dość że paliwa wystarczy na większą odległość, to jeszcze czasowo się dłużej jedzie, chcąc jechać ekonomicznie ;P

Jest to zachowanie racjonalne, bo komputer (a co za tym idzie program) to tylko narzędzie do wykonania konkretnych czynności. Coś jak grabie: mogę mieć ręcznie kute grabie z trzonkiem z rzeźbionego dębu, za 1500 złotych, wytrzymujące sto lat celnego ostrzału artyleryjskiego, robione przez artystę na zamówienie, a na realizację będę czekał 3 miesiące.

Ale jeśli potrzebuję zagrabić trawnik teraz, to coś takiego nie wchodzi w rachubę: trzeba kupić za 20 złotych chińskie grabki z plastiku, które połamią się przy drugim grabieniu, ale dostępne są natychmiast i w milionach sztuk.

Jak by to rzec... zależy co rozumiemy przez "zawodowego programistę":

1. Już raczej nie.
2. Miałem kiedyś wizytówkę "Kierownik działu programowania obiektowego.".
3. Wykształcenie kierunkowe mam.

Tylko, że te grabie z rzeźbionego dębu będą twoje prawnuki używać cmokając nad jakością i finezją producenta.

Ostatnio edytowany przez BartoszP (2010-08-08 14:22:49)

Co do D, zgadzam się. Implementacje są w zasadzie cztery, każda "działa, ale". ;)

Co do arsenału wskaźników, masz oczywiście na myśli Boost i Loki?

Poczułem zapach spalonego prochu... :D

Ostatnio edytowany przez jer (2010-08-08 20:23:59)

No ale to jest oczywiste. SmartPointery tylko przesuwają problem. Rozwiązania dobrego nie ma (można używać weak pointerów, ale nie zawsze się da). W naszej firmie staramy się odejść od IntrusivePtr.