Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła

1. Ideologia, nauka, wynalazczość i komercja w informatyce(na przykładach z obiektowości i baz danych) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Nauki komputerowe (computer science) a wynalazczość Nauki komputerowe nie są „nauką” w tradycyjnym rozumieniu tego terminu. Rozwój w dziedzinach związanych z komputerami oznacza przede wszystkim wynalazczość i nowe zastosowania. Działalność ściśle naukowa, zmierzająca do wypracowania obiektywnych zasad, teorii, metodologii i klasyfikacji, jest nieskuteczna, zwykle spóźniona w stosunku do aktualnych potrzeb i zbytnio obciążona zastanymi paradygmatami i kryteriami naukowymi. Np. matematyczne teorie w dziedzinie inżynierii oprogramowania, od lat dryfujące w kierunku scholastycznych mielizn i pozostawiające po sobie wrakowisko pseudo-wiedzy, pseudo-podstaw i pseudo-autorytetów. Wynalazczość nie podlega kryteriom naukowym, jest spontanicznym błyskiem intelektu wynikającym z wiedzy, doświadczenia, wyczucia potrzeby rynkowej, wyczucia szansy zarobienia pieniędzy. $ Bill Gates, twórca i właściciel Microsoft’u, uważany za jednego z największych wynalazców komputerowych naszych czasów, człowiek, który w ogromnym stopniu przesądził o charakterze współczesnej informatyki, nie ukończył nawet studiów.

3. Wynalazki “niszczą” naukę? Teza (nie do udowodnienia): Gdyby nie nowe wynalazki, naukowcy do dziś zajmowaliby się problematyką budowy arytmometrów w komputerach oraz minimalizacją układów boolowskich. Były to tematy rodzące tak wiele frapujących problemów, że starczyłoby ich dla wielu pokoleń naukowców na wszystkich uniwersytetach. Dlaczego te wspaniałe tematy zmarły? Dlaczego w zasadzie nikt nie zajmuje się maszynami Turinga, teorią informacji, gramatykami bezkontekstowymi i dwupoziomowymi, maszynami abstrakcyjnymi, semantyką denotacyjna, problemem stopu? Informatyka napędza się przede wszystkim coraz to nowymi wynalazkami, zaś w tej powodzi wynalazków nie wystarcza czasu i zapału do budowania i polerowania teorii, zasad i syntez. Nawet wtedy, kiedy już się wydaje, że takie teorie, zasady, syntezy udało się stworzyć, kolejne wynalazki przełamują podstawę, na której były one budowane. Tak jest np. z semantyką języków programowania: pojawienie się programowania wizyjnego i zdarzeniowego niszczy ogromną „kulturę” języków opartych o ręczne wypisywanie tekstu programu w ASCII. Tak jest obecnie z modelem relacyjnym w bazach danych, którego teorie całkowicie załamują się w obliczu nowego wynalazku zwanego obiektową bazą danych.

4. Rodzaje wynalazków Podstawową rolą nauk komputerowych jest tworzenie wynalazków lub tworzenie wiedzy sprzyjającej wynalazkom. Wynalazek jest czymś nieco innym niż konkretna konstrukcja (np. systemu). Granica pomiędzy wynalazkiem i konstrukcją jest jednak bardzo płynna. Cechy wynalazków: Powszechność: powtarzalność zastosowań Nowatorstwo: nowa jakość techniczna, ekonomiczna, społeczna, metodologiczna Użyteczność: mniej lub bardziej wymierny zysk z zastosowania Rodzaje wynalazków w oprogramowaniu (przykłady) Język programowania Algorytm (np. sortowania) Metoda (np. optymalizacji) Koncepcja interfejsu (np. graficznego) Metodyka projektowania Notacja graficzna dla zapisu rezultatów projektu Teoria opisująca pewien aspekt konstrukcji systemu Ideologia ustalająca zasady przyszłych systemów Wynalazki mogą różnić się skalą “twardości”: od twardych, posiadających bezpośrednie mierzalne efekty, do miękkich, subiektywnych, których konstrukcja jest zestawem arbitralnych decyzji, zaś efekty trudne do zmierzenia.

5. Nauka a ideologia Model relacyjny baz danych i obiektowość są ideologiami, czyli wynalazkami określającymi generalne ramy, cele i kierunki rozwoju. Nawet jeżeli system został zbudowany spontanicznie w reakcji na kolejne potrzeby (co w informatyce często ma miejsce), okazuje się, że pod powierzchnią inżynierskich działań tkwiła jakaś ideologia, chociaż nie nazwana i nieuświadomiona. Koncepcje hierarchicznych i sieciowych baz danych były właśnie tego rodzaju nieuświadomionymi ideologiami, które zostały nazwane kilka lat po ich zaistnieniu w informatycznej rzeczywistości. W bazach danych ideologie, zwane modelami danych, okazały zasadniczy wpływ na rozwój. Ideologie mają pierwiastek obiektywizmu, wyrastają bowiem z zaobserwowanych wad istniejącej rzeczywistości. Niemniej argumenty na ich rzecz mają charakter subiektywny i werbalny, skutków ich wprowadzenia nie da się precyzyjnie zmierzyć, jak również (patrz ideologie społeczne) skutki te mogą być sprzeczne z obietnicami. Racji ideologicznych nie da się udowodnić a priori: stanowią one przedmiot wiary lub niewiary, są bliższe religii niż nauce. Nasza droga jest to jedyna słuszna droga ! Nauka, teorie są wtórne w stosunku do ideologii: są im podporządkowane, wyrastają w ich granicach i mogą nie mieć sensu poza ich obrębem.

6. “Nauka” kontra “komercja” Świat komercyjny w zasadzie przestał się interesować tym, co robia ludzie na uniwersytetach, chociaż z drugiej strony bardzo mu zależy na dobrych kontaktach i przykładach współpracy. Środowisko akademickie uważa za opiniotwórcze, które może wspomóc biznes (lub mu zaszkodzić). Natomiast prawie całkowicie ignoruje “dobre rady”, “rozwiązania” i ‘teorie” płynące z uniwersytetów. Świat akademicki dość często wyraża pogardę dla problemów i rozwiązań komercyjnych. Znane są (również w Polsce) przykłady arogancji przedstawicieli świata nauki ferujących daleko idące opinie i konkluzje wyłącznie na podstawie spekulacji teoretycznych, powierzchownych obserwacji lub możliwości/niemożliwości zastosowania matematyki. (Celują w tym Hoare, Dijkstra, Ullman, Parnas, itp.) Te opinie przypominają naukę gry na skrzypcach przez nauczyciela, który nigdy nie miał w ręku skrzypiec. Ludzie na uniwersytetach, zajęci “Nauką” i dydaktyką, nie mają czasu aby interesować się zbyt dokładnie problemami i rozwiązaniami komercyjnymi. Ludzie z firm komputerowych, zajęci robieniem pieniędzy, nie wierzą w ludzi z uniwersytetów. Opinie ludzi ze uniwersytetów są nieistotne z punktu widzenia zysku. Sprzeczność pomiędzy “nauką” i “komercją” jest na dłuższą metę nie do utrzymania. Budowa teorii i budowa systemów są dwiema stronami tej samej monety. Jaka ma być rola nauki?

7. Praktyka Teoria Teorie? Co to znaczy “teoria” w informatyce? W dość powszechnym stereotypie, teorie w informatyce są ubocznym produktem naukowych karier ludzi z uniwersytetów i poza tymi karierami do niczego innego nie służą. “Teoria” kojarzy się ludziom z “następnym artykułem na następną konferencję”. Ludzie z uniwersytetów nie mają nic do powiedzenia w zakresie informatyki rzeczywistej, tworzą więc informatykę urojoną oraz cały samo-podtrzymujący się świat informatyki urojonej. Ludzie z firm informatycznych omijają ten świat szerokim łukiem. Ludzie z uniwersytetów najczęściej posługują się blagą i obiecankami-cacankami dla wyłudzenia od sponsorów pieniędzy na badania teoretyczne. Teorie nazywają “podstawami informatyki”, lub “podstawami sztucznej inteligencji”, co ma dodać autorytetu i zmylić niektórych z nich. Czy ten stereotyp jest słuszny? Czy potrzebne jest budowanie teorii? Do czego mogłyby one służyć? Jaka miałaby być ich rola? Każdy, kto chce poświęcić swoje życie “badaniom naukowym” musi sobie jakoś odpowiedzieć na te pytania.

8. Teorie są niezbędne! Nie można sobie wyobrazić rozwoju jakiejkolwiek dziedziny ludzkiej działalności bez budowania teorii. Dotyczy to także informatyki. Do czego potrzebne są teorie? 1. Do rejestracji stanu wiedzy. Rejestracja tej wiedzy nie może sprowadzić się do faktografii zbudowanych systemów lub języków. Potrzebna jest synteza, potrzebne są uogólnienia. 2. Do nauczania. Nie może ono się opierać na żmudnym zapoznawaniu studentów z kolejnym systemem lub językiem (chociaż znajomość kilku z nich jest niezbędna). Nauczanie powinno dostarczać wiedzy o generalnych zasadach budowy takich systemów lub języków. 3. Do wnioskowania o jakości budowanych systemów. Teoria powinna ustalać ocenę ich kompletności, zgodności ze stanem sztuki, kryteria jakości. 4. Do rozwoju. Teorie są podstawą wniosków co do przyszłych systemów. Czy teorie zastępują wynalazczość? Nie, nigdy. One jej tylko sprzyjają. Czy teorie zastępują ideologie, są prawdami absolutnymi? Informatyka ma mało prawd absolutnych. Teorie służą nam na dziś, są pochodną ideologii i umierają wraz z nimi. “Teoria” nie oznacza “zmatematyzowana teoria”! W medycynie, naukach społecznych, itd. istnieje wiele niezmatematyzowanych teorii. Informatyka jest dziedziną inżynierską, która ma coraz mniej wspólnego z matematyką.

9. Zmatematyzowane teorie? W informatyce występuje kilka rodzajów zmatematyzowanych teorii: 1. Agresywne zmatematyzowane ideologie. Forma najczęstsza, najbardziej hałaśliwa. Bazując na metodach matematycznych budują wizję przyszłych rozwiązań. Do takich “teorii” należy programowanie w logice, dedukcyjne bazy danych, metody specyfikacji oprogramowania i wiele innych. Agresywne zmatematyzowane ideologie w ogóle nie są teoriami, ponieważ nie dotyczą istniejącej rzeczywistości, a proponują nową rzeczywistość, najczęściej utopijną. Są odpowiedzialne za złą reputację badań teoretycznych w informatyce (relacja kowal-cygan). 2. Nie agresywne uniwersalne abstrakcje. Np. teoria automatów, gramatyki bezkontekstowe, teoria algorytmów, teoria złożoności, maszyny Turinga, rachunek lambda, semantyka denotracyjna, itd. Tworzą ogólną kulturę informatyki i nie powinny być oceniane w kontekście bezpośrednich zastosowań. Znaczenie metodologiczne i dydaktyczne wielu z nich jest dzisiaj raczej niskie. Z tego względu niekoniecznie muszą być znane i nauczane. Dla bezpośredniej praktyki są prawie nieprzydatne, nawet pośrednio. 3. Teorie przyczynkowe, na użytek konkretnych metod, algorytmów, itd. Np. metody optymalizacyjne, metody numeryczne, teorie sortowania, wyszukiwania, metody grafiki komputerowej, zbiory rozmyte i przybliżone, miary jakości oprogramowania, itd. Stanowią istotne wspomaganie konkretnego problemu. 4. Teorie porządkujące, umiarkowanie agresywne. Nie proponują nowego świata, lecz próbują uporządkować stan dziedziny, wypracować kryteria oceny jakości przyjętych rozwiązań. Przykładem jest teoria typów, teoria szeregowalności transakcji, teoria języków zapytań, itd. Mają duże znaczenie metodologiczne.

10. Nadużycia teoretyków informatyki (1) 1. Przedstawianie agresywnej zmatematyzowanej ideologii jako nowej teorii. (Patrz “Logika teoretycznych urojeń”, Informatyka 12/1993.) Nadużycie jest powszechne, jest przyczyną nieporozumień, niszczenia autentycznych badań i marnowania publicznych pieniędzy. (Rzadkie w USA, tam na takich “teoretykach” już się poznali. Niestety, zbyt częste w Polsce.) 2. Tworzenie mitów “szerokich zastosowań”. Z reguły nie ma żadnych. Często są potencjalne, ale nikt ich nie sprawdził. Najczęściej są to próby na niewielką skalę, szybko zarzucane jak mało skuteczne. 3. Nadmierne rozciąganie zakresu działania “matematycznej precyzji”. Precyzja ta dotyczy wyłącznie fazy od aksjomatów i definicji do twierdzeń. Nie dotyczy fazy “od problemu do definicji i aksjomatów” i fazy “od twierdzeń do praktycznych rozwiązań”. 1. Sformułowanie matematyczne 2. Wnioski matematyczne 3. Rozwiązanie praktyczne Problem praktyczny Matematyczna precyzja dotyczy wyłącznie fazy 2. Pozostałe fazy pozostawiają mnóstwo pola dla blagi, niechlujstwa, braku precyzji, nadużyć, naciągania.

11. Nadużycia teoretyków informatyki (2) 4. Rozwiązanie problemu cząstkowego, partykularnego i następnie jego prezentacja jako rozwiązanie problemu całościowego. Np. przedstawienie metod i teorii zależności funkcjonalnych i wielowartościowych jako rozwiązanie problemu projektowania baz danych. 5. Rozwiązanie problemu zastępczego zamiast problemu autentycznego. Np. udowodnienie twierdzenia o równoważności pewnego rachunku i pewnej algebry zamiast porządnego podejścia do semantyki języków zapytań. 6. Ignorowanie skali problemu, tworzenie teorii dla kilku-linijkowych przykładów dla studentów z założeniem, że przeskaluje się ona do programów zawierających dziesiątki tysięcy linii kodu. Praktyka dowodzi, że jest to założenie fałszywe w 100%. Algebra relacyjna: sformułowanie matematyczne problemu semantyki języka zapytań abstrahuje od ogromnej ilości bardzo ważnych zjawisk językowych. Wnioski matematyczne są nieadekwantne w stosunku do praktycznych rozwiązań. Notacja Z: ogranicza się do sformułowania problemu w terminach matematycznych (fazy 1). Brakuje nawet fazy 2. Mamy do czynienia z fetyszyzacją matematycznego rodowodu i matematycznej składni. (Syndrom prezerwatywy nadzianej na dzidę w chacie wojownika, który ma dość kolejnych bachorów.) Przykłady:

12. Przykład “teorii”: algebry obiektowe 1. Błędy koncepcyjne: a. Przyjęte explicite i implicite ograniczenia struktur danych b. Przyjęte explicite i implicite ograniczenia uniwersalności języka zapytań c. Brak czystej semantyki wielu pojęć obiektowości (hermetyzacji, klas, przesłaniania,...) d. “Domkniętość” (closure) algebry nad obiektami jest koncepcyjnym nonsensem prowadzącym m.in. do problemów, czym mają być identyfikatory obiektów zwracanych przez wyrażenia algebraiczne. 2. Błędy matematyczne a. Niedopuszczalne zmieszanie językowych i meta-językowych poziomów b. Traktowanie kwantyfikatorów jako operatorów algebraicznych c. Ignorowanie pojęcia stanu bazy danych i stanu obliczeń 3. Błędy pragmatyczne (myślenie życzeniowe) a. Założenie, że da się zrobić odwzorowanie z SQL3 i OQL do tego rodzaju algebry, oraz odwzorowanie odwrotne. Wobec braku formalnych modeli SQL3 i OQL jest to nonsens. b. Założenie, że uda się wyprowadzić twierdzenia dotyczące optymalizacji zapytań, podczas gdy metody algebraiczne są ograniczone do dość słabych metod opartych na przepisywaniu c. Założenie, że tylko algebra jest w stanie poradzić sobie z optymalizacją, podczas gdy wiadomo, że inne formalizmy (logika, semantyka denotacyjna) są często znacznie lepsze. “Nauka” w najgorszym, blagierskim stylu, produkowana przez sławne instytucje i nazwiska (INRIA, Brown University, Uni Penn, ..., nazwisk nie wymienię, ....)

13. Teorie jako hamulec postępu? Postęp jest wyznaczany przez wynalazczość. Rozwój pewnego nieudanego paradygmatu teoretycznego jest w stanie skutecznie zahamować wynalazczość. Dotyczy to szczególnie agresywnych zmatematyzowanych ideologii. Przykłady: W latach 1975-85 było prawie niemożliwie opublikowanie w renomowanym miejscu artykułu teorytecznego w dziedzinie baz danych, który nie dotyczyłby modelu relacyjny lub go krytykował. Występował bardzo silny szowinizm zwolenników tego modelu, którzy opanowali ciała kolegialne. Istnieją opinie, że te praktyki zahamowały rozwój na ok. 10 lat. Relacyjne teorie okazały się w większości bardzo mało przydatne i pełnią teraz rolę dinozaurów. W latach 1983-1993 nastąpił intensywny rozwój dedukcyjnych baz danych, który zaangażował ogromny potencjał naukowy i finansowy. Nic z tego nie wyszło. Napisano ok. 400 publikacji teoretycznych na temat niekompletnej informacji, dzięki czemu wykształciła się grupa ok. 20 “autorytetów” w temacie. Mimo że te teorie są do niczego, 20 “autorytetów” skutecznie blokuje nowe artykuły, który je krytykują lub ignorują. • Teorie są łatwiejszą formą działalności naukowej i są atrakcyjne. • Angażują ogromny, wartościowy potencjał, szczególnie młodych ludzi. • Potencjał ten jest zmarnowany, jeżeli teoria jest nieudana. • Wykształcają się pseudo-specjaliści, którzy obciążają dziedzinę przez • brak autentycznej wiedzy oraz forsowanie wiedzy urojonej. Mogę bardzo wiele powiedzieć o polskich utytułowanych pseudo-teoretykach ...

14. Mity dotyczące teorii wśród praktyków Ludzie praktyki odgradzają się murem od teorii traktując ją jako sztukę dla sztuki. W ogromnej mierze, jest to konsekwencja braku skuteczności badań teoretycznych i związanego z tym “odruchu Pawłowa” u praktyków. Wieloletnia produkcja pseudo-teoretycznych, pseudo-naukowych śmieci zrobiła swoje. Zachodzi tutaj jednak podwójny błąd. 1. Teorię utożsamia się ze ‘zmatematyzowaną teorią”. W rzeczywistości, istnieje wiele teorii w informatyce, które nie są zmatematyzowane i którymi praktycy posługują się na codzień. Np. istniejące metody w zakresie przetwarzania transakcji (kompilatorów, systemów rozproszonych, itp.) tworzą teorię, która ma bezpośrednie znaczenie dla praktyki. 2. Wnioski teoretyczne uważa się za całkowicie nieadekwatne dla praktyki. Dość często wnioski te mają bezpośredni skutek. Np. pokazanie, że system typów jest niespójny i pozwala “przemknąć się” błędom typologicznym jest wnioskiem teoretycznym, który ma doniosłe znaczenie praktyczne. Udowodnienie, że gramatyka zaproponowana przez praktyków prowadzi do zapętlenia parsera jest również wnioskiem praktycznym. “Nie ma nic bardziej praktycznego niż dobra teoria.” (Albert Einstein) Ale jak rozpoznać dobre teorie od niedobrych? Na to nie ma odpowiedzi.

15. Czym powinny być teorie? Czym ma być nauka? Czy nauka, teorie mają zajmować się wyłącznie tym, co zmajsterkowali/sknocili inżynierowie? Czy “nauka” ma być przeciwstawieniem “komercji”? Czy nauka ma być bezpośrednio na usługach i na użytek rozwiązań praktycznych? Czy nauka ma na siebie bezpośrednio zarabiać poprzez dostarczanie rozwiązań do natychmiastowego wykorzystania w praktyce? Nauka i praktyka są dwiema stronami tej samej monety. Nauka powinna systematyzować, syntezować wiedzę. Nauka powinna dostarczać wiedzy bardziej uniwersalnej niż wiedza o konkretnych systemach. Nauka nie musi być bezpośrednio dochodowa; raczej, niemierzalny zysk w horyzoncie dziesięcioleci. Naukowcy-informatycy nie powinni tracić kontaktu z praktyką. Tak jak dobry profesor medycyny powinien wykazać się jako dobry chirurg. Niestety, wielu z naukowców-informatyków żyje w kryształowej wieży. Praktyka i rzeczywistość nic ich nie obchodzi. Jest to negatywna konsekwencja przeniesienia do informatyki stylu działalności naukowej obowiązującego w matematyce.

16. Estetyka i pragmatyka Nauka: ustanowienie podstaw i zasad budowy (przyszłych) systemów zgodnie z kryteriami estetycznymi. Komercja: budowa systemów efektywnych w dzisiejszej rzeczywistości zgodnie z kryteriami pragmatycznymi. Nauka napędza się kryteriami estetycznymi. Produkty nauki (teorie) muszą być intelektualnie interesujące i estetyczne. Niekoniecznie muszą być użyteczne. Komercja napędza się kryteriami pragmatycznymi. Produkty komercyjne muszą być użyteczne, efektywne i przynoszące zysk. Niekoniecznie muszą być estetyczne. Estetyka nie jest sprzeczna z pragmatyką. Historię oprogramowania można podsumować jako epopeję długofalowych zwycięstw kryteriów estetycznych. Na krótką metę, na dzisiaj zwyciężają prawie zawsze kryteria pragmatyczne.

17. Kryteria estetyczne w systemach obiektowych (1) Maksymalna uniwersalność. Pełne możliwości systemu lub języka przy założonym celu. Minimalność środków(brzytwa Occam’a). Jak najmniej pojęć, jak najmniej konstrukcji gramatycznych, unikanie redundancji. Generalizacje, uogólnienia, abstrakcje. Zastępowanie wielu rozwiązań partykularnych jednym bardziej ogólnym. Abstrahowanie od szczegółów implementacyjnych, rodzajów nośników pamięci, sposobów adresacji i alokacji, organizacji zbiorów, metod dostępu, rozproszenia, protokółów komunikacyjnych, itd. Wspomaganie dla oczekiwanego zbioru abstrakcji i opcji programistycznych. Np. procedury, funkcyjne procedury, typy, klasy, moduły, perspektywy, złożone dane. Unikanie niejasności, niejednoznaczności, nieregularnego traktowania, wyjątków. Szczególna uwaga powinna dotyczyć przypadków granicznych lub skrajnych: niezainicjowane zmienne, wartości zerowe, puste zbiory, pętle z zerową ilością iteracji, itd.

18. Kryteria estetyczne w systemach obiektowych (2) Unikanie nieporządku semantycznego, polegającego na zlepianiu informacji semantycznej, tworzenia obiektów programistycznych grupujących niekompatybilne elementy. Czysta formalna składnia i semantyka. W szczególności, precyzyjne określenie dziedzin semantycznych rozważanych języków. (“Formalna” niekoniecznie oznacza “matematyczna”.) Maksymalna ortogonalność koncepcyjnie niezależnych własności. Np. ortogonalność klas i typów, ortogonalność konstruktorów typów, ortogonalna trwałość, ortogonalności języka zapytań w stosunku do trwałości, itd. Zasada korespondencji. Jeżeli wprowadzana jest pewna nowa własność, to należy zapewnić pełne zintegrowanie tej własności ze wszystkimi już istniejącymi konstrukcjami języka lub systemu. Np. jeżeli do języka jest wprowadzany typ “tablica”, to powinny być także przewidziane całkowicie uniwersalne środki dostępu i przetwarzania tablic. Relatywizm konstrukcji programistycznych, relatywizm danych. Syntaktyczne i semantyczne własności składowej powinny być takie same jak własności całości.

19. Kryteria estetyczne w systemach obiektowych (3) Dekompozycja problemu, dążenie do maksymalnego wyabstrahowania jego niezależnych składowych. Kompozycyjność, czyli unikanie dużych konstrukcji syntaktycznych, unikanie odległych zależności kontekstowych. Modularność: jasne oddzielenie granic pewnych bytów programistycznych, oddzielenie specyfikacji od implementacji, minimalizacja specyfikacji. Rozszerzalność, modyfikowalność: własności pozwalające na zmiany lub rozszerzenia języka, schematu, systemu, itd. Przeciwdziałanie błędom: eliminacja konstrukcji prowadzących do częstych błędów, wprowadzanie konstrukcji podwyższających niezawodność (np. mocnej kontroli typów) Unikanie niezgodności impedancji lub niezgodności kompetencji: jednorodność definicji języka, unikanie sytuacji kiedy użytkownik ma do wyboru wiele niekompatybilnych opcji dla realizacji tego samego celu. Bezszwowa integracja konstrukcji językowych, bezszwowa integracja faz analizy, projektowania i programowania.

20. Kryteria pragmatyczne w syst. obiektowych (1) Wydajność w sensie minimalizacji czasu wykonania, minimalizacji zapotrzebowania na różne rodzaje pamięci, minimalizacji obciążenia sieci, minimalizacji kosztów, itd. Efektywność w sensie właściwej realizacji funkcji użytkowych dla których system został zbudowany, przy założonej skali systemu i tempie jego rozrostu Niezawodność w sensie bezawaryjnej, bezbłędnej pracy w długim horyzoncie czasowym Niskie koszty: wytworzenia systemu, zakupu, eksploatacji, utrzymywania, modyfikowania, krótki czas wytworzenia systemu, itd. Popularność: istnienie dużego kręgu użytkowników danej firmy, danego produktu Rozpowszechnienie, czyli obecność produktu na wielu platformach Poziom technologiczny, wykorzystanie najnowszych osiągnięć

21. Kryteria pragmatyczne w syst. obiektowych (2) Zgodność ze standardami (SQL, OMG, ODMG, ODBC, JDBC, X-open,...) Przystosowanie do oprogramowania spadkowego i istniejącej kultury technicznej użytkowników, programistów, analityków, projektantów, kierownictwa (np. czy jest oparty o C, C++, SQL, Java, OMG CORBA, SSADM, OMT, itd.) Łatwość nauczenia się i łatwość używania Współdziałanie z innymi produktami lub językami, “otwartość” systemu Bezpieczeństwo: zapewnienie odporności na awarie, nieuwagę, bezmyślność, nadużycia, wandalizm i sabotaż Zintegrowanie w jednym pakiecie wielu wymaganych przez użytkowników funkcji Poparcie “możnych tego świata”, którzy trzymają kluczyk do kasy

22. Sprzeczność pomiędzy estetyką i pragmatyką? W pewnym sensie. Wiele dyskusji (np. na listach dyskusyjnych) ma następujący scenariusz: ktoś (często ze świata nauki) wysuwa argument estetyczny, inni (ze świata komercyjnego) odpierają ten zarzut podając argumenty pragmatyczne. Np. Estetycy: C++ jest do bani. Jest eklektyczny, ma wiele własności niskiego poziomu,... Pragmatycy: I co z tego? Jest powszechnie używany, produkuje efektywny kod,... Estetycy: Ortogonalna trwałość! Pragmatycy: Po co? W C++ tego się nie zrobi. Nasz tłusty klient tego nie chce. Świat naukowy marzy o estetycznych ideałach, które są spekulatywne i wynikają z pewnych ideologii. Są one często idealistyczne, utopijne, lub sztuką dla sztuki. Świat komercyjny jest pod presją ogromnej konkurencji, gdzie ostatecznym kryterium są pieniądze. To sprawia, że rozwiązania są ad hoc, tymczasowe, redundantne, odpowadające aktualnym brzęczykom, mitom, modom, stereotypom. Rzadko się zdarza, aby pewne idee lub rozwiązania pasowały dla obu światów.

23. Co można zaobserwować w językach programowania baz danych? 1 Języki programowania + dodatkowe funkcje dla obsługi baz danych Pascal/R, DBPL, Tycoon, Ps-Algol, Napier88, Galileo, Fibonacci, Machavelli, Pjama 2 Bazy danych + dodatkowe (dolepione) funkcje języków programowania Oracle PL/SQL, Ingres OpenRoad, 4GL, Postgres, Illustra, UniSQL, ODMG, SQL3 1-sza linia jest rozwijana głównie przez świat akademicki. 2-ga linia jest rozwijana głównie przez świat komercyjny Świat komercyjny czasami twierdzi, że 1-sza linia nie ma szans. Świat akademicki czasami twierdzi, że 2-ga linia nie ma sensu. Do tego dochodzi liczna grupa agresywnych zmatematyzowanych teorii budowanych głównie przez świat akademicki, które (zdaniem K.S.) nie mają ani szans ani sensu. Np. dedukcyjne i dedukcyjno-obiektowe bazy danych, obiektowe logiki i algebry, rachunek monoidów, itd.

24. Zasada relatywizmu Ogólnie: jeżeli X zawiera jakąś składową Y, to Y posiada te same ogólne własności jak X i może istnieć (być rozpatrywany) niezależnie od X. I odwrotnie, jeżeli X istnieje i jest rozpatrywany niezależnie, to może być włączony jako składowa jakiegoś większego bytu Y. samochód silnik gaźnik przepustnica zawleczka osoba zatrudnienia zatrudnienie firma adres Obiekt może być dowolnie złożony, tj. składać się z pod-obiektów, które też mogą być dowolnie złożone. • Relatywizm pociąga za sobą: • hierarchiczną budowę obiektów • relatywizm środków dostępu i manipulacji obiektami • konieczność określenia identyfikatorów (tożsamości) • dla podobiektów Zasada relatywizmu danych/obiektów jest podstawą większości akademickich języków programowania baz danych. Niestety, nie jest ona wspomagana przez czołowych propagatorów obiektowości (np. C++, OMT, OMG, ODMG).

25. Zasada wewnętrznej identyfikacji Każdy byt programistyczny, który może być niezależnie od innych wyszukany, zaktualizowany, wstawiony, usunięty, autoryzowany, zaindeksowany, zabezpieczony, zablokowany, itp. musi mieć unikalny wewnętrzny identyfikator. Identyfikator taki umożliwia budowanie jednoznacznych referencji (odsyłaczy). Brak możliwości budowy jednoznacznych referencji do bytu programistycznego powoduje zasadnicze kłopoty z jasną semantyką wymienionych wyżej funkcjonalności. Taki identyfikator może być (ale nie musi) fizycznym adresem zapamiętanej danej. Ta zasada nie była przestrzegana przez modele zorientowane na wartości (value-oriented), w szczegól- ności, przez model relacyjny, stąd liczne anomalie i niejasna semantyka wielu cech systemów i języków (np. semantyka aktualizacji w SQL, semantyka kursorów w zagnieżdżonym SQL, itd.). Zasada ta jest spełniona dla obiektów, ale powinna być także obowiązująca dla atrybutów (podatrybutów) obiektów. Dla atrybutów unikalny identyfikator można skonstruować jako OID+nazwa atrybutu, ale taka konstrukcja jest niespójna dla atrybutów powtarzalnych. Tej samej zasadzie muszą podlegać powiązania pomiędzy obiektami. Takie powiązanie (czyli wskaźnik) może być aktualizowane, wobec czego konieczne jest identyfikacja miejsca, w którym ma być dokonana aktualizacja, czyli identyfikatora takiego wskaźnika.

26. Zasada ortogonalnej trwałości orthogonal persistence Tradycyjnie, bazy danych przechowywały wyłącznie typy trwałe i masowe (zbiory, relacje, etc.). Tradycyjnie, języki programowania zajmowały się prawie wyłącznie typami indywidualnymi i nietrwałymi (zmienne, struktury, zapisy, etc.). Tradycyjnie, istnieją różnice w koncepcjach dostępu do bazy danych i dostępu do zmiennych programu. W istocie, nie istnieje logiczne uzasadnienie takiego podziału. Można podać wiele przykładów, kiedy przydałoby się zapamiętanie w bazie danych zmiennych indywidualnych (np. liczba pracownikow. Brak kolekcji (typów masowych) w językach programowania prowadzi do koncepcji “sterty” (heap), która ma liczne wady, w szczególności, ograniczoną kontrolę typów, konieczność dynamicznych operacji alokacji i zwalniania pamięci, konieczność przetwarzania poprzez wskaźniki. Ortogonalna trwałość oznacza nowy typ języka programowania, w którym cecha trwałości jest ortogonalna do konstruktorów typu. W szczególności, baza danych może przechowywać dane indywidualne (trwałe), zaś w obszarze roboczym programu mogą znajdować się wartości masowe (nietrwałe). Cecha trwałości powinna być obsługiwana przez wyspecjalizowane funkcje, ale wszystkie pozostałe funkcjonalności (w tym języki zapytań) powinny nie robić żadnej różnicy w dostępie do trwałych i nietrwałych danych.

27. Ortogonalność języka zapytań, rodzaju danych i trwałości W modelu relacyjnym przyjęto, ze języki zapytań mogą obsługiwać wyłącznie trwałe dane typu masowego (relacje). To założenie zostało naruszone w SQL poprzez umożliwienie parametryzowania zapytań zmiennymi języka programowania. Przyjmując zasadę ortogonalnej trwałości nie widać powodu, dla którego należy przyjąć te ograniczenia Język zapytań powinien w zuniformizowany sposób traktować: • Trwałe i nietrwałe dane • Dane indywidualne, tablice i kolekcje • Parametry procedur Zapytania powinny być utożsamione z wyrażeniami jęz. programowania i mogą być użyte wszędzie tam, gdzie mozna używać wyrażeń: • Jako argumenty zdań imperatywnych (podstawienia, usuwania, wstawiania, tworzenia) • Jako argumenty procedur i metod • Jako określenie wyniku zwracanego przez procedurę funkcyjną Jak dotąd, istnieje tylko jeden taki język zapytań: SBQL zrealizowany w systemie LOQIS. OQL ma do przebycia długą drogę, zanim osiągnie w tym zakresie poziom LOQIS-a.

28. Inne estetyczne kryteria w językach programowania baz danych (1) Struktury danych: • Identyfikatory obiektów mogą być używane jako wartości (wskaźniki) • Identyfikatory mogą być lub mogą nie być trwałe (niezmienne na całe życie obiektu) • Obiekty mogą mieć zero, jedną lub więcej zewnętrznych nazw (?) • Struktury danych powinny być całkowicie ortogonalne w stosunku do wszystkich • rodzajów danych: dane alfanumeryczne, tekst, grafika i inne multimedia, kody procedur • i funkcji, typy, klasy, zdarzenia, ograniczenia, aktywne reguły • Struktury danych powinny także traktować w podobny zunifikowany sposób dane • odnoszące się do meta-informacji: grafika dla zewnętrznej reprezentacji obiektów, • prawa dostępu, reguły bezpieczeństwa, dokumentację, komentarze, pomoce, opisy, • słowniki • Struktury danych powinny wspomagać uporządkowanie danych • Struktury danych powinny wspomagać wartości zerowe i warianty

29. Inne estetyczne kryteria w językach programowania baz danych (2) Możliwości programistyczne: • Kompletność algorytmiczna • Kompletność pragmatyczna • Środki programowania ogólnego: polimorfizm, klasy parametryczne, refleksja, itd. • Programowanie w makroskopowym stylu poprzez język programowania zintegrowany z • językiem zapytań. • Minimalny, spójny zbiór abstrakcji programistycznych zbudowany w zuniformizowany • sposób: procedury, procedury funkcyjne, metody, operatory, ADT, moduły, • perspektywy, procedury baz danych, atrybuty pochodne, ograniczenia, aktywne reguły, • aktywne obiekty,... • Konsekwentny, uniwersalny i pełny system mocnej (statycznej) kontroli typów. Dla • wspomagania ortogonalnej trwałości system typów obiektów powinien być niezależny • od języka programowania. • Wszystkie inwarianty obiektów powinny być zgrupowane w ramach klasy (nie tylko • typy i metody)

30. Podsumowanie Młody człowiek (dowolnej płci) wybierający karierę naukową w dziedzinie obiektowości, baz danych, języków programowania, inżynierii oprogramowania powinien dobrze się zastanowić czego oczekuje. Jaki model kariery wybiera: czy będzie uczestniczył w strumieniu wynalazków, czy będzie tworzył/rozwijał nowe ideologie, czy będzie też systematyzował, porządkował dziedzinę? Czy będzie tylko udawaczem, karierowiczem i blagierem, jak to się zdarzyło wielu (nie tylko polskim) naukowcom? (Nauka przynosi małe pieniądze i zaszczyty. Karierowiczem i blagierem warto być w innych dziedzinach, gdzie pieniądze i zaszczyty są większe (np. w polityce)). Jeżeli mimo tego ostrzeżenia postanowi być naukowcem, warto aby zastanowił(a) się nad takim swoim życiowym tematem, który spełnia przyjęte kryteria estetyczne i jednocześnie nie jest zbyt odległy od pragmatyki. Warto inwestować w teorie. Nawet jeżeli są na razie nieprzydatne lub są po prostu intelektualnymi ćwiczeniami. Dobrze jest jednak zdefiniować charakter naszej teorii, czego od niej oczekujemy i jaki ona będzie miała sens dla innych. Nie tylko dla naszej maleńkiej naukowej kariery.