🚀 go-pugleaf

Odpowiedz na tekst p.  Waldka Hebisch'a:

Wlasnie w trakcie edycji odpowiedzi do pana, wspanialy system
IRIX  zawalil mi sie totalnie z powodu przepelnienia dysku -
i prawie napisany list przepadl. To taka dygresja. DObrze by bylo
zeby systemy tego nie robily, albo jak nie ma miejsca na dysku to
nie pozwalaly na wprowadzanie danych do pamieci puki sie tego miejsca 
nie zrobi. Bo szkoda roboty.

A teraz do meritum:
To beda moje aktualne poglady na sprawe, nieco rozne od przedstawionych w
artykule.

Pisze pan:
"(...)
	Ja sadze ze wysokopoziomowa czesc systemu jest w zasadzie 
latwa (choc pewnie bedzie wielokrotnie wieksza niz reszta), a glowna
czesc to znalezc niskopoziomowy mechanizm ktory bedzie wydajny i 
da porzadana semantyke. 
"

Wydaje mi sie ze optymalnym rozwiazaniem jest zaprojektowanie
API (OPI?) na takim poziomie abstrakcji zeby jednoczesnie dawala
 wystarczajaca moc i swobode w tworzeniu aplikacyjnej nadbudowy,
nie wymagala nadmiernego babrania sie w szczegolach na pozionie
aplikacyjnym, a  j e d n o c z e s n i e nie krepowala implementatorow
wewnetrznych warst systemu. Cos jak definicja systemu POSIX, tyle ze
pelniejsza i lepsza. 
		I to jest najtrudniejsza czesc zadania -
zaprojektowanie takiego interface. A wewnatrz jest pole do popisu dla
programistow systemowych. "Aplikatora" moze nie interesowac gdzie i jak
sa skladowane obiekty,  kiedy sa backupowane, czy metody wykonywane na
rzecz obiektu sa naprawde bardziej podobne sa do watkow czy do klasycznych
procesow, czy moze stosowana jest metoda monitorow - gdzies we wnetrzu
systemu kazdy aktywny obiekt ma chodzacy w petli watek odbierajacy wysylane
do niego komunikaty=wywolania metod i wykonujacy je kolejno, wreszcie jak jest
implementowana pamiec wirtualna, czy jej konfiguracja jest przechowywana dla
obiektu, czy zawsze tworzona od nowa itd.

"(...)
I tu mam, moim zdaniem, istotna uwage - pracujac 
na wysokim poziomie latwo jest zapomniec o szczegulach impementacji 
ktore moga byc kluczowe dla wydajnosci. Co gorsza, czesto najpierw robi 
sie probna malo wydajna implementacje - do sprawdzenia koncepcji, a 
potem wlasnosci tej wplywaja na istotne fragmenty jezyka. Np. w TCL uzycie 
interpretera pozwolilo na dynamiczna redefinicje procedur, ale ta redefinicja 
wlasciwie uniemozliwia klasyczna kompilacje. Podobnie Smalltalk ma wiele 
wlasnosci utrudniajacych kompilacje. 
"

Dlatego opieram sie na C++, ze przy jego projektowaniu myslano o wydajnosci i
technikach kompilacji. Nie ma co prawda wielu wygodnych wodotryskow jak
TCL czy inne jezyki interpretowane, ale jest wystarczajaco elastyczny, a
przy dobrym projektowaniu nie ustepuje wydajnoscia czystemu C, a nawet
assemblerowi (jesli kompilator jest dobry). 

"(...)
Sa to przy tym nie tylko problemy wydajnosci - stosujac silne mechanizmy 
do rozwiazania latwych problemow otrzymuje sie system o duzej zlorzonsci 
logicznej.
Wydaje mi sie tez ze jest tu kwestia metodologi programowania - dobra 
metodologia obiektowa mowi ze nie nalerzy dziedziczyc ze wspolnego obiektu 
tylko po to miec wspolny kod metody. Zgadzam sie z tym, ale aby 
miec wydajny system musze w efekcie najpierw zbudowac nizsza warstwe, 
a potem dopiero "zapakowac" ja w obiekty.
"

Obiektowosc daje szanse na ukrywanie zlozonosci przez tzw enkapsulacje.
Dla uzytkownika istotny jest interface, a implementacja moze byc zmienna.
Poza tym jesli wlozyc wystarczajaco duzo wysilku w projekt to mozna
stopniowac zlozonosc: wiele wlasnosci obiektu, nawet wszystkie, moze byc
domyslnych. Uzytkownik nie musi o nich wiedziec, choc jesli zechce, to
moze je odczytac a takze zmienic - ale na poziomie podstawowym moze
wystarczyc mu nazwa typu i pare podstawowych operacji o ogolnie
przyjetym znaczeniu:  operatory np [] czy >> , << , metody w rodzaju view,
edit, czy "Obecny stan obiektu jest zbyt wazny zeby go stracic" zapewniajaca 
zapis nieulotny i ewentualne przywrocenie tego stanu, jesli cos sie rypnie.

Co do pakowania. Mozna, ale nie trzeba. Co kto lubi. Czasem nawet system
operacyjny latwiej napisac w odpowiednim jezyku obiektowym. I to nawet
system REALTIME - czego dowodem jest np ADA.

"(...)
Szczegolowy proces projektowania 
moze byc bardzej skomplikowany, ale jest problem zapewnienia jednolitosci 
specyfikacji roznych czesci systemu. To MUSI uwgledziac (czy nawet bazowac) 
na aspektach niskopoziomowych. 
" 

Uwzgledniac tylko na tyle ile jet to konieczne dla efektywnosci, ale
starannie ukrywajac. Im lepiej aspekty niskopoziomowe sa schowane,
tym wiecej mozna potem zmienic we wnetrzu systemu, nie wplywajac na 
aplikacje.

"
(...)
Mam dodatkowa uwage co do wspoldzielenia danych przez obiekty:
Wydaje mi sie ze wiekszosc danych ma z natury zmienna dlugosc (teksty,
listy, itp) i przy malej zmianie (i natralnej metodzie skladowania) 
wieksza czesc danych obiektu ulegnie przesunieciu. W efekcie 
oczekowalbym ze rozne obiekty w zasadzie nie bedza mialy wspolnych 
stron danych (chyba ze "read only").
"
Oczywiscie takie "przesuniecie" jest smiertelne dla wspoldzielenia stron,
ale mozna go czesto uniknac:
Np lista, czy tekst (traktowany jako kolekcja lancuchow reprezentujacych
linie lub akapity) moze miec strukture dynamiczna. Wezmy chocby modyfikacje
lini w tekscie zwiazana z jej przedluzeniem:
  Tekst ma powiedzmy 100KB czyli powiedzmy 25 stron ( pamieci, nie druku).
"W-insertowanie" literki powoduje koniecznosc realokowania pamieci dla
tej linii, oczywiscie z jakims zapasem - np 16 czy 32 znakow. 
Zmieniaja sie wiec conajmniej dwie strony - ta gdzie byl zapisany odnosnik,
lub stara wersja lini, i ta gdzie umieszczono nowa wersje lini.
Ale to sa dwie a nie wszystkie. I potem ta linie czy akapit mozna edytowac 
dlugo nie powodujac zmian kolejnych stron.
Nawet bitmapa moze miec strukture dynamiczna. Kosztuje to datakowa pamiec
na wektor wskaznikow do linii, ale czasem moze sie oplacic.


			Wojciech Borkowski

PS: Tresc artykulu oraz starsza korespondencja dostepna jest przez link
z mojej strony domowej.


-- 
********************************************************************
*                 Wojciech Borkowski                               *
* Zaklad Systematyki i Geografii Roslin Uniwersytetu Warszawskiego *
*   oraz			        	                   *
* Instytut Studiow Spolecznych Uniwersytetu Warszawskiego          *
* WWW:                                                             *
* http://www.bot.astrouw.edu.pl/~borkowsk/Borkowsk.html            *
* MAIL:                                                            *
* bork...@ulmus.bot.astrouw.edu.pl bork...@samba.iss.uw.edu.pl   *
********************************************************************