2. Zasada korespondencji

Podstawowym drogowskazem przy konstruowaniu języka programowania opartego na języku zapytań będzie dla nas zasada korespondencji (correspondence principle).

Przykładowo, jeżeli cecha X jest dynamiczną tablicą, to odpowiednimi pytaniami są: czy może być składową zapisu (struktury, obiektu), czy może być parametrem procedury, czy może być zwrócona przez procedurę funkcyjną, jakie środki będą przewidziane do typizacji, wyszukiwania, aktualizacji, usuwania, dostawiania elementów; itd.

Oddolny rozwój niektórych języków (np. SQL) jest przyczyną wielu przypadków łamania zasady korespondencji, co objawia się m.in. tym, że nowo dodawane cechy nie dają się gładko kombinować ze starymi cechami. Przykładem złamania zasady korespondencji w SQL jest sposób wprowadzenia do niego wartości NULL lub konstrukcja group by.

Zasada korespondencji może i powinna być rozszerzona dalej, poza samą kwestię definicji języka. Jeżeli wprowadzamy do języka cechę X, to równie ważne stają się odpowiedzi na następujące pytania:

• Czy istnieje dostatecznie jasna pragmatyka cechy X, tj. sposób przełożenia konkretnej potrzeby w dziedzinie przedmiotowej na zastosowanie cechy X? Jeżeli nie ma takiej jasnej pragmatyki, to cecha X jest po prostu redundantnym, spekulacyjnym lub scholastycznym tworem.
  
  
• Czy cecha X jest uwzględniona w metodyce projektowania aplikacji i/lub metodyce projektowania baz danych? Jeżeli nie, to cecha X stanie się cechą uboczną, pozostawioną decyzji programisty, co w przypadku niektórych cech zredukuje lub uniemożliwi ich zastosowania.
  
  
• Czy cecha X nie jest redundantna, tj. czy może być zastąpiona przez kombinację już istniejących cech bez istotnego wzrostu pracochłonności projektowania i programowania, wzrostu pracochłonności konserwacji oprogramowania, spadku jakości oprogramowania itd.?
  
  
• Czy i jak cecha X będzie osiągalna z zewnętrznych interfejsów, nie bazujących na definiowanym przez nas języku? Np. jeżeli do danego systemu relacyjnego dodano pewne cechy obiektowe, to mogą one być nieosiągalne dla interfejsów opartych na SQL, np. ODBC, co zredukuje zainteresowanie projektantów i programistów do stosowania tej cechy.
  
  
• Jak cecha X została udokumentowana i objaśniona na przykładach? Jeżeli dokumentacja i przykłady są zbyt lakoniczne, zbyt matematyczne lub zbyt infantylne (dotyczące pewnych zabawowych zastosowań), to cecha może nie być rozumiana od strony możliwości jej użycia.
  
  
• Czy cecha X jest błędogenna lub niebezpieczna dla powszechnego programisty, czy nie prowadzi do raf semantycznych (wyniku niezgodnego z powszechnym odczuciem semantyki tej cechy), czy nie prowadzi do utraty pewnych użytkowych cech systemów, np. bezpieczeństwa, ochrony, skalowalności, współbieżności itd.?
  
  
• Jakie środki dydaktyczne będą zastosowane w celu objaśnienia i zareklamowania użycia cechy X na kursach dla studentów, projektantówi programistów?

Jak widać z tych pytań, niekoniecznie wprowadzenie nowej cechy do środowiska programistycznego oznacza poprawę. Autor jest zdania, że wiele cech wprowadzanych przez różnych autorów do języków programowania okazało wsteczny wpływ, zahamowało postęp, zamiast go wspomagać. Dotyczy to szczególnie wielu propozycji akademickich, w tym większości propozycji mających "zdrowe podstawy matematyczne" lub "głęboko uzasadnionych matematycznie", produkowanych przez osoby nie mające jakichkolwiek doświadczeń praktycznych.