Oddzielenie języków ludzkich pochodzi od ewolucji (darwinowskiej?) W odizolowanych społecznościach. Oddzielenie języków programowania wynika z różnic w potrzebach technicznych, ideologii technicznej, zmianach w zrozumieniu technicznym i teoretycznym oraz zmianach naszej technicznej możliwości wdrożenia. Myślę, że jest to nieco bardziej świadomy proces.
Czy języki komputerowe mogłyby być bardziej podobne do języków naturalnych? Prawdopodobnie do pewnego stopnia. Wydaje mi się, że duża część złożoności języka naturalnego wynika z różnorodnych zjawisk ewolucyjnych, które nie mają powodu do uzyskania spójnego wyniku w dowolnym momencie, nawet jeśli prawdopodobne jest, że stare niespójności zostaną prawdopodobnie stopniowo wyeliminowane, a pojawią się nowe. . Nie jestem ekspertem w lingwistyce diachronicznej. Ale czy chcemy tego rodzaju złożoności w językach programowania.
Kwestia dwuznaczności jest ważna, ale nie tak, jak twierdzi większość ludzi. Język jest środkiem komunikacji i musi być analizowany w kontekście tej komunikacji (człowiek-człowiek, człowiek-maszyna, zarówno pomiędzy miejscami, jak i między czasami,… by powiedzieć nieco uproszczony). Liczy się nie to, czy w języku można tworzyć tylko jednoznaczne wypowiedzi, ale czy zawsze można zapewnić, że komunikacja będzie jednoznaczna w zamierzonym kontekście. Istnieje jeden dobrze znany i powszechnie używany język programowania, który umożliwia pisanie niejednoznacznych programów (no tak, ale od dłuższego czasu nie patrzyłem na najnowsze wersje). W takim przypadku kompilator jest wystarczająco inteligentny, aby wykryć niejednoznaczność i poprosić o wyjaśnienie, które można włączyć do programu, aby wyeliminować niejednoznaczność. Zauważ, że wykrywanie niejednoznaczności nie oznacza, że tylko jeden z możliwych wyborów ma znaczenie, wszystkie mają. Problem polega na tym, czy jeden z komunikujących się podmiotów może wykryć niejednoznaczność, aby nadawca mógł ją wyjaśnić. Ludzie są w tym źli, ale komputery mogą być całkiem dobre.
Formalizmy i języki programowania mogłyby mieć bogatszą i bardziej elastyczną składnię. Uważam, że głównym powodem, dla którego tego nie robią, jest prosty konserwatyzm. Użyte narzędzia składniowe to wciąż bardzo często narzędzia zaprojektowane trzydzieści lat temu lub wcześniej, aby sprostać ograniczeniom komputerów z tamtych czasów. Wydajność analizowania nie jest już tak istotnym problemem przy kompilacji, a bardziej wydajne techniki istnieją w sensowny sposób.
Co ciekawe, najczęściej stosowana podstawa składni języków programowania pochodzi z badań języka naturalnego: gramatyka bezkontekstowa. Wiele badań technicznych przeniosło się na informatykę teoretyczną / techniczną w latach sześćdziesiątych, aby na początku lat osiemdziesiątych zostały nieco odkryte przez osoby posługujące się językiem naturalnym (upraszczam). Od tego czasu poczyniono znaczne postępy w zakresie składni w językach naturalnych, podczas gdy informatyka wydaje się w dużej mierze utknąć w starych narzędziach składniowych. Wahadło języka naturalnego ponownie zmierza w kierunku technik statystycznych, ale algebraiczne podejścia do składni nie są zapominane. Najprawdopodobniej dobre podejścia wynikną z połączenia technik algebraicznych i statystycznych.
Mam wrażenie, że krytycznym obszarem jest semantyka i przejście między składnią a semantyką. Jest to nadal bardzo trudne do sformalizowania w przypadku języka naturalnego, podczas gdy mamy wiele precyzyjnych technik w przypadku języków programowania i systemów formalnych. Ponieważ gra jest daleka od grania w językach naturalnych, trudno jest powiedzieć, jaki wpływ może ona mieć na języki programowania w przyszłości.
Inną kwestią jest to, że wielu projektantów języków programowania próbuje coś udowodnić lub narzucić ideologię techniczną. W ten sposób stają się niezwykle nakazowe w swojej konstrukcji, aby uniemożliwić użytkownikom odejście od zamierzonych paradygmatów. Jest to niestety wyjątkowo niekorzystne dla kreatywności. Najbardziej kreatywny język, jaki kiedykolwiek zaprojektowano, był jednym z pierwszych: Lisp (1958). Swoboda i elastyczność, na jaką pozwalały, były źródłem znacznej kreatywności. Cena była taka, że wymagała samodyscypliny i zrozumienia. Ale Lisp był tak naprawdę językiem metalicznym, językiem do tworzenia języków.
Teraz, aby spojrzeć z innej perspektywy, programy są faktycznie dowodami ich specyfikacji postrzeganej jako stwierdzenie matematyczne (cóż, upraszczam ponownie). Niektórzy ludzie (nie pamiętam odniesień, przepraszam) bawili się dowodami twierdzeń, aby przedstawić dowody, które wyglądałyby tak, jakby zostały napisane przez matematyka w języku naturalnym. Myślę, że pomysł posiadania programów, które wyglądają, jakby były napisane w języku naturalnym, może nie być całkowicie absurdalny.
Możesz jednak zauważyć, że nawet gdy matematyk napisał je nieformalnie, dyskurs matematyczny wygląda zupełnie inaczej niż zwykła mowa lub książka historyczna. Wynika to ze znacznej różnicy w omawianym wszechświecie dyskursu, o domenach semantycznych, o których się mówi. Tak więc, chociaż można sobie wyobrazić języki programowania, które wyglądają bardziej jak języki naturalne, istnieje naturalne ograniczenie, które jest domeną dyskursu i jego własnymi pożądanymi właściwościami. Najprawdopodobniej pozostanie zasadniczo powierzchowny, to znaczy w większości składniowy. Matematyk może mówić o systemach formalnych i polityce. Mam nadzieję, że te dwa dyskursy nie będą wyglądały podobnie. Komputery nie mogą (jeszcze?) Mówić o polityce ani rozumieć jej. Dzień, w którym to zrobią, nie będzie już programował.
Patrząc wstecz na historię, języki wysokiego poziomu były od pierwszego (FORTRAN) próbą zbliżenia się do bardziej naturalnej formy wyrażania zadań obliczeniowych, ale zadania te były rozumiane jako matematyczne lub logiczne (Fortran 1957, Algol 1958, Lisp 1958 ) lub bardziej zorientowane na biznes (Cobol 1959). W ciągu 10 lat ludzie martwili się o języki, które będą bliższe, lepiej dostosowane do danego problemu, i przeprowadzono znaczące badania w zakresie tzw. extensible
languages
, Obejmujące zarówno składnię, jak i semantykę. Jedną z głównych ścieżek wyrażania problemów w bardziej naturalny sposób było pojawienie się object
orientation
(czasem pod innymi nazwami). Chociaż przypisanie rodzicielstwa zawsze jest trudne, prawdopodobnie wynikało to z pracy nad sztuczną inteligencją, głównie w Lisp, oraz z językaSimula
67
(Rodzina Algol), która sama w sobie miała wyrażać bardziej naturalnie rzeczywiste problemy, które mają być symulowane na komputerze. Wszystko wydaje się historycznie spójne.