🚀 go-pugleaf

Jarek Kucypera wrote:
> [...]
> To jest akurat kwestia gustu: czy ktoś lubi języki niskopoziomowe, czy nie.
> Zauważ
> że za tę wydajność trzeba zapłacić cenę związaną np. wyciekaniem pamięci,
> niepoprawnymi wskaźnikami co generuje czasem bardzo trudne do wykrycia
> błędy, zawiłą i nieczytelną składnią itp.

Niskopoziomowość niskopoziomowością, ale bardzo duża nadmiarowość kodu
daje w efekcie również sporą ilość obiektów, o których trzeba
jednocześnie pamiętać przy pisaniu kodu. Sama wielorakość dostępu do
obiektów powoduje, że z każdym z nich skojarzona jest już całkiem spora
ilość informacji, jak na przykład to, czy leksykalnie obiekt
identyfikowany jest wskaźnikiem, referencją, czy też poprzez wartość.
Czy jest obiektem stertowym, a jeśli tak to jak określony jest jego
czasokres trwania i kto jest odpowiedzialny za jego zwalnianie itp.
Owszem, teoretycznie daje to duże możliwości. Problem jest tylko taki,
że ilość rzeczy, o których trzeba pamiętać przewyższa możliwości
postrzegania programisty. Gdzie to było?.. Chyba był to gość nazwiskiem
Miller, który w połowie lat 50 zajmował się badaniem pamięci
krótkoterminowej człowieka. Wtedy sformułował zasadę "7 plus minus 2".
Według jego obserwacji pamięć krótkoterminowa człowieka mogła pomieścić
tylko 7 obiektów naraz z dokładnością do dwóch elementów. Bodajże w 75
roku uściślił swoje obserwacje jako zasadę - proszę się nie śmiać -
"trzy po trzy", czyli mamy zdolność krótkoterminowego kontrolowania
trzech grup po trzy rzeczy.  Jako, że - jak słusznie zauważył Pan
Lewandowski - nie jestem specjalistą z zakresu genealogii języków, to
głowy za to nie dam, ale myślę, że wnioski Dr. Millera były na tyle
ważne, że stały się istotnym fundamentem do tworzenia logiki
późniejszych narzędzi programistycznych. 

A jaki to ma związek z C++ - wydaje mi się, że ta wielorakość
traktowania różnych rzeczy przez C++ powoduje, że nawet przy dość silnej
dekompozycji projektu i nawet we względnie krótkich fragmentach kodu
znajduje się tyle rzeczy o których programista musi pamiętać, że
efektywność realizacji projektów jest dość niska. Generalnie, z punktu
widzenia obserwacji Millera, optymalny język to taki język, którego
zwartość jest na tyle wysoka, że czas przerzucenia go do pamięci
długoterminowej jest krótki, podobnie rzecz się ma do podzbioru wyrażeń
stosowanych w projekcie - jeśli jest on bardzo duży, to trzeba poświęcić
dużo czasu na jego opanowanie. A na dodatek, jeśli głupi zapis a = b +c
może znaczyć tysiąc różnych rzeczy w zależności od miejsca w programie i
projektu, to wtedy wszystkie te informacje będzie trzeba szukać w
dokumentacji i przechowywać w krótkoterminowym "cache-u". Wtedy po
prostu nie ma możliwości, żeby zapamiętać coś długoterminowo, bo
rzadziej stosowane warianty zapisu są z pamięci wypierane przez jego
najpospolitsze znaczenie. To jest właśnie w C++ złe, że daje możliwości
tworzenia własnych zapisów nie wskazując, ani nawet nie sugerując
ujednoliconego rozwiązania.

I moim zdaniem nie jest to kwestia gustu, ale kwestia skali problemów z
jakimi ma się do czynienia. I to one kształtują gust.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND