Języki programowania z trwałością - początek historii

1. Języki programowania z trwałością - początek historii Listopad 1998 Kazimierz Subieta Instytut Podstaw Informatyki PAN Warszawa subieta@ipipan.waw.pl http://www.ipipan.waw.pl/~subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

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

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

4. Manifest baz danych “trzeciej generacji” (3GDB) początek 1990 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 Doktryny: 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

5. 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ć).

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

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

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

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

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

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

12. 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ść.

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

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

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

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

17. 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 System wspomagania interfejsu użytk. Użytkownicy Docelowa architektura: Programy aplikacyjne Programiści Świat zewnętrzny

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