Języki programowania z trwałością - Instytut Podstaw Informatyki PAN

Języki programowania z trwałością początek historii
Listopad 1998
Kazimierz Subieta
Instytut Podstaw Informatyki PAN
Warszawa
[email protected]
http://www.ipipan.waw.pl/~subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych
Warszawa
K.Subieta. Języki programowania z trwałością, Folia 1
October 1998
Historia trwałości
1964
1965
koniec lat 60-tych
1971
1971-1980
1970
1980-1990
1980-do teraz
koniec lat 80-tych
1991
1986, 1989, 1992
1985-1995
1995
1996-do teraz
K.Subieta. Języki programowania z trwałością, Folia 2
Pierwszy SZBD - IDS - Integrated data Store
Ch. Bachman, pierwszy sieciowy model danych
IBM wypuszcza IMS + DL/I - masowe zastosowania
Propozycja DBTG CODASYL modelu sieciowego
Wiele nowych systemów opartych o propozycję DBTG
Wszystkie systemy były dostępne poprzez jezyki dość
niskiego poziomu, przeważnie COBOL
E.F. Codd proponuje model relacyjny
Masowy rozwój i zastosowanie relacyjnych SZBD
Badania nad nowymi modelami baz danych, w tym
obiektowymi
Masowe pojawienie się obiektowych SZBD
(ObjectDesign, Versant, Gemstone, O2, Objectivity,...)
Utworzenie grupy (komitetu) ODMG
Kolejne standardy SQL, rozpoczęcie prac nad SQL3
Wiele jezyków z trwałością: Pascal-R, DBPL, PS-Algol,...
Java
Kolejne wersje Java z trwałością - PJava, ..., PJama
October 1998
Systemy obiektowo-relacyjne
Powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunku obiektowości,
liczą na pozycję systemów relacyjnych na rynku i odwołują się do ich wiernej klienteli.
Nacisk dwóch tendencji:
Rynek domaga się cech pozwalających zniwelować niedostatki relacyjnej technologii,
szczególnie w zakresie danych multimedialnych, związania z danymi informacji
behawioralnej (reguł, metod), modelowania pojęciowego i środków programowania
aplikacji.
Pokusa wprowadzenia wielu cech obiektowości, takich jak klasy, metody, dziedziczenie,
abstrakcyjne typy danych, pozwalających na twierdzenia o „częściowej obiektowości”
systemów relacyjnych.
Podejście jest określane jako „hybrydowe” lub „obiektowo-relacyjne”.
Ostatnio karierę robi także termin „uniwersalny serwer” (universal server)
K.Subieta. Języki programowania z trwałością, Folia 3
October 1998
Manifest baz danych “trzeciej generacji” (3GDB)
początek 1990
Doktryny:
M.Stonebraker, L.Rowe, B.Lindsay, J.Gray, M.Carey, M.Brodie, P.Bernstein, D.Beach
 3GDB mają wspomagać bogatsze struktury danych i reguły
 3GDB muszą posiadać wszystkie pozytywne cechy 2GBD
 3GDB muszą być otwarte dla innych systemów
13 postulatów:
 3GDB muszą posiadać bogaty system typów
 Dziedziczenie jest dobrym pomysłem
 Funkcje (włączając zapamiętane procedury i metody) + hermetyzacja są dobrymi pomysłami.
 Unikalne identyfikatory powinny być stosowane wtedy, gdy nie są dostępne klucze główne.
 Reguły (wyzwalacze, więzy) staną sie główną cechą przyszłych systemów
 Cały dostęp do bazy danych powinien odbywać się poprzez nieproceduralny język wys.poz.
 Kolekcje powinny być specyfikowane zarówno przez ich wyliczenie, jak i poprzez zapytanie
 Aktualizowanle perspektywy są istotne
 Własności fizyczne nie mają związku z modelem danych i powinny być z niego usuniete
 3GDB muszą być dostępne z wielu języków wysokiego poziomu
 Języki te powinny być wyposażone w cechę trwałości i możliwości języków zapytań
 Na lepsze i gorsze, SQL jest intergalaktycznym językiem danych
 Zapytania i odpowiedzi na zap. powinny być dolnym poziomem komunikacji klient-serwer
K.Subieta. Języki programowania z trwałością, Folia 4
October 1998
Trzeci manifest Darwena i Date
Darwen i Date podzielają większość poglądów autorów trzeciego manifestu,
ale nie zgadzają się z zasadniczymi tezami:
SQL, źródło wypaczeń, powinien być odrzucony całkowicie i bezwzględnie.
Proponują założenia zupełnie nowego języka zapytań/programowania (niestety,
niespójne, niekompletne i dość niekompetentne).
Model relacyjny w czystej matematycznej postaci wystarczy do wszystkiego.
Won ze wszystkimi ulepszaczami modelu, który jest przecież doskonały.
(Powołują się tu na E.F.Codd’a, traktując go jak osobę świętą.)
Odrzucić wszystkie pseudo- pomysły w rodzaju obiektów, klas, hermetyzacji,
itd. Klasy są tym samym co dziedziny (domains).
Hermetyzacja jest bzdurą, bo uniemożliwia realizację języków zapytań.
Argumenty super-specjalistów mają oczywiście charakter religijny.
Wraz z żarliwą wiarą w jedyną słuszność modelu relacyjnego prezentują
wręcz infantylną niekompetencję w przedmiocie (co może trochę dziwić).
K.Subieta. Języki programowania z trwałością, Folia 5
October 1998
Manifest obiektowych baz danych
Formułuje podstawowe założenia obiektowych baz danych w postaci
charakterystyk, które są podzielone na trzy grupy:
Obowiązkowe, czyli takie, które musi posiadać każdy system zarządzania
bazą danych określany mianem „obiektowy”. Do nich należą: złożone
obiekty, tożsamość obiektów, hermetyzacja, typy lub klasy, dziedziczenie,
przesłanianie wraz z późnym wiązaniem, rozszerzalność, kompletność
obliczeniowa, trwałość, zarządzanie pamięcią pomocniczą, współbieżność,
odtwarzanie oraz udogodnienia dla zapytań ad hoc.
Opcyjne, czyli takie, które nie są obowiązkowe, ale które mogą podnieść
jakość systemu. Do nich zaliczono: wielokrotne dziedziczenie, kontrolę typu
i wnioskowanie o typie, rozproszenie bazy danych, transakcje projektowe
(długie lub zagnieżdżone) oraz wersje.
Otwarte, czyli takie, gdzie projektanci systemów mają pewną dowolność co
do ich wyboru. Do nich zaliczono paradygmat programowania, system
typów, system reprezentacji oraz zuniformizowanie.
K.Subieta. Języki programowania z trwałością, Folia 6
October 1998
Języki programowania z trwałością (baz danych)
Bardzo ważny nurt pozostajacy w cieniu wielkich komercyjnych rozgrywek.
Wprowadza trwałe (persistent) zmienne lub obiekty do języków programowania.
Trwałą zmienną nazywa się taką zmienna, która ma wszystkie własności zmiennej języka
programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami
programu. Bazy danych można traktować jako zestaw trwałych zmiennych lub obiektów.
Projektów o statucie eksperymentalnym zwanych językami programowania baz danych
(Data Base Programming Languages, DBPL): Amber, Galileo, Fibonacci, PS-Algol, OPAL,
DBPL, Napier88, Tycoon, MUMPS, Machiavelli i ostatnio PJama. Intelektualnie
zaawansowane i kompetentne. Wielu perspektywicznych koncepcji, takich jak:
• polimorficzny system mocnej kontroli typów,
• ortogonalna trwałość (orthogonal persistence),
• ortogonalność konstruktorów typów masowych: zbiorów, sekwencji i tablic, i inne)
Koncepcje te napotykają na opór ze strony środowisk przemysłowych, ponieważ popularne
systemy i języki takie jak Smalltalk, C++ i SQL i Java nie są do nich przygotowane.
K.Subieta. Języki programowania z trwałością, Folia 7
October 1998
Krytyka obecnego nurtu jezyków z trwałością
Przesadny nacisk na polimorficzny system mocnej kontroli typów.
Ktoś (Cardelli?) tym ludziom wmówił, że typy są najważniejsze, co owocuje w tak
skomplikowane systemy typów, ze prawdopodobnie nie istnieją programiści, którzy je
zaakceptują. Wiąże się to prawdopodobnie z tym, że typy są dobrze zdefiniowanym
problemem, który można badać przy pomocy metod akademickich, w tym matematycznych.
Zaniedbanie innych, znacznie ważniejszych zagadnień, takich jak:
języki zapytań,
obiektowość,
programowanie wizyjne i zdarzeniowe,
integracja ze środowiskiem programistycznym.
Temat języków zapytań został tak zdominowany przez typy (a raczej, przez obecne
poglądy na temat, czym jest typ), że pozostały z niego jakieś marne szczątki, jakieś
drobne operatory typu „join” (np. w Machiavelli). Generalnie, temat ten jest
lekceważony w tych kręgach. Dominuje pogląd, że operatory języka zapytań nie
powinny być „wbudowane” (build in), a raczej „nadbudowane” (add on).
Ta filozofia (żarliwie uzasadniana) jest nie do przyjęcia.
K.Subieta. Języki programowania z trwałością, Folia 8
October 1998
Krytyka obecnego nurtu komercyjnego
Wady:
Dominuje filozofia zanurzania (SQL + C, OQL + C++, OQL+ Java), która już wcześniej była
krytykowana za niezgodność impedancji.
Języki 4GL, narzędzia RAD: dość eklektyczne, o nieprzewidywalnych regułach,
nieprzewidywalnych możliwościach, licznych ograniczeniach i barokowych konstrukcjach.
Dziesiątki własnych rozszerzeń (ad hoc) SQL, włączając w to 4GL, PL/SQL, ODBC, JDBC,
ASP, SQL3, itd. Wielki chaos, bez szans na reguły, zasady, uporządkowanie.
Zalety:
Dobre potraktowanie graficznego interfejsu użytkownika.
Dobre potraktowanie kwestii wydajności maszynowej i ludzkiej.
Oparcie interfejsów na programowaniu zdarzeniowym i wizyjnym.
Zintegrowanie ze środowiskiem programistycznym.
Kompatybilność z innym oprogramowniem.
Standardyzacja SQL i interfejsów? Bzdura. Nie będą działać.
Standardy nie pomogą, jeżeli chory jest ideologiczny i koncepcyjny kręgosłup.
A to jest własnie przypadek modelu relacyjnego i SQL.
K.Subieta. Języki programowania z trwałością, Folia 9
October 1998
Może by zacząć od zasad ... ?
Ostatnio zasady w informatyce są kwestionowane.
Ludzie z komercji argumentują, że zasady są dobre do wykładania na uniwersytetach.
Jeżeli dane rozwiązanie nie odpowiada zasadom, to oznacza, że te zasady są pomijalne,
ponieważ w informatyce nie chodzi o narzucone reguły, lecz o efektywność i zysk
Racja, ale w ten sposób można uzasadniany każdy informatyczny bubel.
Porównując tę argumentację do sytuacji w architekturze można powiedzieć, że każdy może
szybko zbudować szopę, w której może prowadzić bardzo dochodowy interes. Jednakże zasady
architektury są przeznaczone dla takich budowli, które przetrwają dziesiątki lub setki lat, będą
w tym czasie spełniać funkcje, do których zostały przeznaczone, będą spełniać kryteria
estetyczne i funkcjonalne, oraz będą świadectwem ludzkiej cywilizacji i kultury. Zasady są
niekiedy idealistyczne i nie zawsze mogą być spełnione w 100%.
Niemniej ustalenie zasad pozwala na świadomy wybór rozwiązań, zaś decyzje odnośnie
odstępstwa od zasad są podejmowane z pełną świadomością przyczyn tego odstępstwa oraz
konsekwencji, które ono powoduje.
Wiele produktów informatycznych powstało w wyniku przypadkowych decyzji.
Paradygmatem twórczości staje się majsterkowanie; następnie efekt tego majsterkowania
próbuje się zamienić na wiedzę dorabiając do niego mętną i pokręconą filozofię.
Patrz np. produkty Microsoft’u i wypowiedzi Rogera Sessions.
K.Subieta. Języki programowania z trwałością, Folia 10
October 1998
Zasady (1)
Naturalność: zgodność z naturalnym myśleniem potencjalnych użytkowników.
Niekoniecznie oznacza ona wyrażanie instrukcji lub zapytań w języku naturalnym
(ponieważ jest on zbyt mało precyzyjny) i niekoniecznie oznacza umieszczanie w
języku dużej ilości słów kluczowych sugerujących cel danej konstrukcji językowej
(dotyczy to np. lukru select...from...where..., który w wielu przypadkach jest mylący
lub niepotrzebny).
Prostota: klarowność konstrukcji syntaktycznych, oczywistość semantyki, łatwość
uczenia się i nauczania, łatwość dokumentowania, implementacji, pielęgnowania i
użycia.
Modelowanie pojęciowe: łatwość dopasowania wyrażenia języka do aktualnego
myślenia nad programem, łatwe rozumienie znaczenia wyrażeń.
Ortogonalność: każda kombinacja cech języka, która ma sens, powinna być
dozwolona. Ortogonalność pozwala na zredukowanie do minimum definicji języka
oraz znaczne podwyższenie jego mocy. Ma ona ogromne znaczenie dla przypadku,
gdy wyrażenia języka nie są pisane przez ludzi, a są automatycznie generowane z
innych interfejsów.
K.Subieta. Języki programowania z trwałością, Folia 11
October 1998
Zasady (2)
Kompozycyjność: unikanie dużych zlepków syntaktycznych i zależności
semantycznych pomiędzy odległymi kontekstowo fragmentami wyrażeń języka.
Relatywizm: identyczna składnia i semantyka wyrażeń języka odnoszących się do
dowolnego poziomu zagnieżdżenia struktur danych. Np. zapytania odnoszące się
do całej bazy danych i odnoszące się do wnętrza pojedynczego obiektu (które może
zawierać podobiekty) powinny być konstruowane na dokładnie tych samych
zasadach.
Minimalność (brzytwa Occama): unikanie cech redundantnych. Dotyczy to
zarówno redundantnej składni, jak i wprowadzania takich konstrukcji językowych,
które można łatwo zastąpić przez inne konstrukcje.
Uniwersalność: język powinien w maksymalnym stopniu przykrywać dziedzinę,
do której został przeznaczony. Uniwersalność nie oznacza mocy maszyny Turinga,
ponieważ to pojęcie jest całkowicie nierelewantne. Chodzi o uniwersalność
pragmatyczną, czyli spełnienie wszystkich aktualnych (i rozsądnych) oczekiwań
użytkowników na dzisiaj i na przewidywaną przyszłość.
K.Subieta. Języki programowania z trwałością, Folia 12
October 1998
Zasady (3)
Brak anomalii: unikanie specjalnych przypadków, cech wyjątkowych,
nieregularnego traktowania, itd. Wszystkie takie cechy stają się przyczyną błędów
oraz zwiększają objętość dokumentacji języka. Szczególnie groźne są tzw.
semantyczne rafy (znane np. z konstrukcji group by SQL, wartości zerowych, itd.),
które powodują błędny (nieoczekiwany) wynik wyrażenia bez jakichkolwiek
ostrzeżeń.
Koncepcyjna kontynuacja: mała zmiana celu, dla którego budowane jest wyrażenie
języka, nie powinno wywoływać dramatycznej zmiany w myśleniu użytkownika i w
formie tego wyrażenia.
Modularność (hermetyzacja): umożliwienie użytkownikowi posługiwania się
fragmentami języka tak jak zamkniętymi bryłami, bez potrzeby wnikania w ich
wewnętrzną budowę. Zmiana kontekstu użycia takich brył nie powinna prowadzić
do zmiany ich znaczenia.
K.Subieta. Języki programowania z trwałością, Folia 13
October 1998
Zasady (4)
Bezpieczeństwo: wzbogacenie języka o specjalne środki (takie jak deklarowanie
typów, asercje, więzy integralności, transakcje) przeciwdziałające niepoprawnemu
użyciu konstrukcji języka, prowadzących do naruszenia integralności bazy danych
lub integralności przetwarzania.
Specjalna troska o przypadki skrajne: puste zbiory, puste stringi, wartości
zerowe, niezainicjowane zmienne, itd. są bardzo często nie objęte definicją
semantyki języka, co powoduje rezultaty nie oczekiwane przez użytkowników.
Ta lista ogólnych zasad jest prawdopodobnie niekompletna.
Budowanie teorii języków programownia baz danych w oparciu o te i inne zasady
jest niezbędne, jeżeli chcemy ustalić pewne kanony, paradygmaty danej dziedziny,
które mogą być nauczane i które mogą efektywnie służyć do budowy, analizy,
porównania i rozwoju produktów wytwarzanych w danej dziedzinie.
Sama znajomość produktów (np. biegła znajomość SQL, OQL lub C++) jest dla tych
celów niewystarczająca.
K.Subieta. Języki programowania z trwałością, Folia 14
October 1998
Bazy danych a języki programowania
20 lat historii życia i rozwoju “obok siebie”.
Obóz baz danych praktycznie ignoruje dokonania obozu języków programowania.
Obóz języków programowania praktycznie ignoruje dokonania obozu baz danych.
Bazy danych - podejście kosmopolityczne.
Udogodnienia takie jak języki zapytań, opis danych, interfejsy programistyczne
mogą być użyte w wielu językach programowania.
Podejście takie owocuje powstaniem ogromnej ilości “kleju” (a raczej klajstru),
którego zadaniem jest zlepienie wielu jezyków programowania w jedną całość.
Efektem kosmopolityzmu są różnorodne, często nieuświadomione ograniczenia na
model danych i interfejsy do bazy danych.
Języki programowanie - bazy danych jako drugi plan.
Bazy danych są traktowane jako peryferia obsługiwany przez funkcje biblioteczne.
Zasoby baz danych są “plikami zewnętrznymi” do których się “pisze” i z których
się “czyta”.
Debuggery i udogodnienia nie uwzględniają baz danych jako specjalnego tematu.
Temat języków zapytań i niezależności danych jest ignorowany.
K.Subieta. Języki programowania z trwałością, Folia 15
October 1998
Integracja języków progr. i baz danych
Droga “akademicka”
Droga “komercyjna”
Tradycyjny
paradygmat
języka
programowania
Język
zapytań
(SQL)
Zintegrowany jezyk
programowania baz dancyh
Zintegrowany jezyk
programowania baz dancyh
?
K.Subieta. Języki programowania z trwałością, Folia 16
October 1998
Systemy zintegrowane: bazy danych, języki
programowania, systemy operacyjne
Podział na te tradycyjne dziedziny oprogramowania jest anachronizmem.
Więcej, jest już fikcją.
Przypisanie typów do języków programowania jest anachronizmem.
Typy są przypisane do danych, języki programowania powinny korzystać ze
zuniformizowanego, niezależnego od nich systemu typów.
Trwałość dowolnych bytów powoływanych w języku programowania
Kompletność i pełna ortogonalność systemu typów
Języki zapytań jako wyrażenia języka programowania
Uniwersalność: typy polimorficzne, funkcje wyższego rzędu.
System
wspomagania
trwałości
Docelowa
architektura:
System
wspomagania
interfejsu użytk.
Programy aplikacyjne
Programiści
K.Subieta. Języki programowania z trwałością, Folia 17
Użytkownicy
Świat zewnętrzny
October 1998
Ortogonalna trwałość
Wiele języków ma pewne cechy do obsługi trwałości, ale dość ograniczone, np.:
Pascal: własność implementacyjna, specjalna struktura danych (file)
C/C++: wyłącznie poprzez funkcje biblioteczne
Ortogonalna trwałość (orthogonal persistence) oznacza nowy typ języka
programowania, w którym cecha trwałości jest ortogonalna w stosunku do
konstruktorów typu.
Wszystkie cechy (w tym języki zapytań) nie powinny robić różnicy w środkach dostępu i
przetwarzaniu trwałych i nietrwałych danych.
Popularne języki obiektowe Smalltalk, C++, Java nie mają trwałych zmiennych i mają silnie
ograniczone typy masowe, wobec czego nie można tam mówić o ortogonalnej trwałości.
Standard ODMG nie zakłada ortogonalnej trwałości, co jest przedmiotem krytyki.
Przedstawiciele świata komercyjnego krytykują ortogonalną trwałość jako niepraktyczną.
Powód jest jasny: wiele firm zajmujących się obiektowymi bazami danych rozwija obecnie
interfejsy oparte na językach obiektowych, dla których cecha ortogonalnej trwałości nie jest
łatwa do wprowadzenia. Były one zaprojektowane przez obóz jezyków programownia, który
zignorował problem baz danych.
K.Subieta. Języki programowania z trwałością, Folia 18
October 1998