Czy możemy uczyć się języków programowania w kontekście językoznawstwa? Czy języki programowania ewoluują naturalnie w podobny sposób jak języki naturalne?
Chociaż pełna racjonalność i spójność matematyczna są niezbędne do programowania języków, nadal istnieje potrzeba (zwłaszcza języków współczesnych), aby były czytelne i wygodne dla ludzi.
Czy języki programowania ewoluują, by stać się bardziej lingwistyczne, a przez to bardziej naturalne? Na przykład kod maszynowy, karty perforowane i języki asemblera ustąpiły miejsca bardziej czytelnym językom, takim jak Ruby i Python itp.
Kiedy mówię, że języki komputerowe stają się bardziej naturalne, nie mam na myśli, że zawierają więcej „słów, które mamy po angielsku”, mam na myśli, że stają się bardziej podobne do języka naturalnego pod względem złożoności gramatyki i umiejętności wyrażania znaczenia (na przykład możliwość wymownego opisania zapytania z bazy danych w sposób racjonalny i zrozumiały dla człowieka).
Co wszyscy myślicie Czy języki programowania stają się bardziej podobne do języków naturalnych, a tym samym mają zastosowanie do praw językoznawstwa?
A może języki żyją w spektrum, gdzie z jednej strony masz skrajnie racjonalne języki, z drugiej bardziej kreatywne. Być może języki programowania i naturalne są identyczne i oba leżą na tym spektrum językowym (ich jedyna różnica, być może to „rzecz”, nad którą starają się nadać sens).
Czy istnieje związek między (ludzką wieżą Babel) separacją języków ludzkich i języków komputerowych? Czy stają się bardziej zróżnicowani z tych samych powodów (tj. W celu rozwiązywania różnych problemów w ciągle rozwijających się systemach komputerowych / systemach kultury itp.)?
źródło
Odpowiedzi:
Nie, naprawdę nie. Języki programowania stały się bardziej podobne do języków naturalnych w sensie „słów, które mamy po angielsku” ( sic ).
Kluczową cechą języków programowania jest to, że nie są one dwuznaczne. Kiedy piszesz i uruchamiasz program, ma on dobrze zdefiniowane znaczenie, którym jest jego zachowanie. Jeśli chcesz napisać program, który działa zgodnie z przeznaczeniem (trudny cel), ważne jest, aby zachowanie¹ programu było jak najbardziej przewidywalne. Języki programowania nie zrobiły dużej różnicy w szerokiej luce w stosunku do języków naturalnych.
Odwrotnie, pracowano nad uzupełnieniem luki z drugiej strony: analizowaniem języków naturalnych za pomocą tych samych narzędzi, co języków programowania. To pole nazywa się przetwarzaniem języka naturalnego . Podejścia te zostały w dużej mierze odrzucone na rzecz uczenia maszynowego . Zacytuję fragment artykułu z Wikipedii, który jest bezpośrednio istotny tutaj:
Jednym ze sposobów ewolucji programowania jest to, że kiedy projektujemy coraz większe systemy, kod źródłowy nie zawsze jest dobrym sposobem na ich zrozumienie. Na przykład procesor Intel jest jednym z najbardziej skomplikowanych obiektów, jakie kiedykolwiek zaprojektował Man, a jego „kod źródłowy” to nie tylko zbiór plików tekstowych. Ale pełny projekt nie ewoluuje w kierunku czegoś podobnego do ludzkiego języka. Nie wiem, jakie są tutaj odpowiednie narzędzia poznawcze lub metafory, i nie sądzę, żeby ktokolwiek jeszcze wiedział; zapytaj ponownie za kilka stuleci.
¹ A raczej zestaw możliwych zachowań opatrzonych adnotacjami o okolicznościach, w których powstają, ale to tylko dodaje jeden krok pośredni w modelowaniu, więc nie jest to tak naprawdę istotne.
źródło
Języki komputerowe mają tendencję do radzenia sobie ze zwięzłością i precyzją, podobnie jak notacja matematyczna, która nie wykazywała żadnej szczególnej skłonności do ewolucji w kierunku języka naturalnego (o czym wiem) w ciągu ostatnich kilku tysięcy lat.
Wątpię również, czy gdybyś komunikował się ze swoim niemowlęciem wyłącznie w Haskell przez pierwsze kilka lat swojego życia, rozwinąłby biegłą znajomość języka. Myślę więc, że istnieje dość ostry kontrast między językiem naturalnym a językiem komputerowym.
Być może szersze rozpowszechnienie technik konstruowania języka poprawiło nieco „naturalność” w miarę upływu czasu, ponieważ programiści „głosują tam nogami”, używając języków, które wydają się im łatwiejsze, a liczba osób zdolnych do tworzenia języków wzrosła z większą liczbą praktykujących i lepszych narzędzi, ale jest to niewielki efekt na brzegach i nie stanowi fundamentalnej transformacji języków programowania w ludzkie.
źródło
ciekawym studium przypadku w tym obszarze jest Perl vs. Ruby (i Python ). Perl to język skryptowy opracowany na początku lat 90., który dodał wiele możliwości w porównaniu do wcześniejszych języków skryptowych opartych na Uniksie (np. Bash). autor Larry Wall jest znany z tego, że jego pochodzenie z lingwistyki zainspirowało niektóre cechy językowe.
jednak Perl ma niezręczną składnię i wiele specjalnych przypadków, które sprawiają, że język jest trochę podobny do angielskiego we wszystkich swoich subtelnych osobliwościach inspirujących różne poziomy krytyki . późniejsze języki skryptowe, takie jak Ruby i Python, opracowane przez informatyków, mają znacznie większą spójność w składni. główny problem polega na tym, że język naturalny ma dużą niejednoznaczność (jest to badane w dziedzinie językoznawstwa), więc język naturalny będzie odgrywał kluczową rolę w przyszłych interfejsach człowiek-komputer, takich jak Siri, ale interfejsy te z natury będą podlegać problemom z dwuznacznością.
oto przypadek, w którym ewolucja języków komputerowych odeszła od idei języka naturalnego. co więcej, ogólna historia języków programowania komputerowego polega na tym, że zostały one opracowane i zmienione w celu usunięcia dwuznaczności (która jest wysoce nieodłączna dla języka naturalnego). nie zostało to zrozumiane na początku historii kompilatorów (powiedzmy być może w latach siedemdziesiątych), a np. wczesne wersje języka Fortran miały zdania o dwuznacznych znaczeniach, które zależały od implementacji kompilatora. niektóre teorie języka CS związane z analizowaniem zostały opracowane częściowo w odpowiedzi na odkrycie niejednoznaczności w analizie językowej.
źródło
Język maszynowy jest bardzo precyzyjny, a tekst napisany przez człowieka można zwykle interpretować na wiele różnych sposobów (na przykład niektóre teksty poetyckie).
Coraz bardziej ewoluuje dopasowywanie wzorców, na przykład, gdy piszesz brzydki kod, kompilator może pomóc zaproponować kilka możliwych rozwiązań, a następnie rzucić ostrzeżenie lub błąd, który może pomóc ci samemu się wypromować. (na przykład na podstawie typowych wzorców kodu)
Istnieją szczegółowe badania nad wzorcami interakcji / projektowania, nawet T9 i SWYPE są rozpoznawaczami wzorców, które bardzo ci pomagają (programy, które nagrywają Twój głos i konwertują go na tekst, również rozpoznają wzorce).
Oczywiście program jest oparty na precyzyjnych mechanizmach, więc potrzebujesz precyzyjnych języków (a nie naturalnych), podczas gdy proste wyszukiwanie w Google jest bardzo naturalne, wystarczy wpisać kilka słów i otrzymasz to, czego chcesz.
Każde inne zadanie i cel ma swój własny język, to nie jest prosta „ewolucja jednego języka”, jest o wiele więcej języków. Precyzyjne zadania wymagają precyzyjnych języków, a swobodne zadania wymagają swobodnych języków
Możesz napisać ten sam fragment kodu C, a następnie skompilować go z kilkoma różnymi kompilatorami, i (chyba że jakiś kompilator jest uszkodzony) wynik kodu będzie taki sam, nawet jeśli wygenerowany zostanie inny zestaw, podczas gdy dla wyszukiwania w sieci daje to samo słowa kluczowe do różnych wyszukiwarek dają różne wyniki.
źródło
Kilka lat temu wraz z moim starszym synem opracowaliśmy system programowania i rozwoju Plain English w celu udzielenia odpowiedzi na następujące pytania:
Czy programy niskiego poziomu (jak kompilatory) można wygodnie i wydajnie pisać w językach wysokiego poziomu (jak angielski)?
Czy języki naturalne można analizować w sposób stosunkowo „niechlujny” i nadal zapewniać wystarczająco stabilne środowisko do produktywnego programowania?
Czy łatwiej jest programować, gdy nie trzeba tłumaczyć myśli w języku naturalnym na alternatywną składnię?
Możemy teraz odpowiedzieć na każde z tych trzech pytań, z bezpośredniego doświadczenia, głośnym „Tak”.
Myślimy, że nasz parser działa jak ludzki mózg. Rozważać. Ojciec mówi swojemu synkowi:
„Chcesz ssać tę butelkę, mały człowieku?”
A dzieciak słyszy
„bla, bla, SUCK, bla, bla, BUTELKA, bla, bla”.
Ale właściwie reaguje, ponieważ ma „zdjęcie” butelki po prawej stronie głowy połączone ze słowem „butelka” po lewej stronie i wcześniej istniejącą „umiejętność” w pobliżu karku połączoną z termin „ssać”. Innymi słowy, dziecko dopasowuje to, co może ze zdjęciami (typami) i umiejętnościami (rutyną), które zgromadził, i po prostu ignoruje resztę. Nasz kompilator robi to samo, z nowymi obrazami (typami) i umiejętnościami (procedurami) definiowanymi - nie przez nas, ale - przez programistę, gdy pisze nowy kod aplikacji.
Typowa definicja typu wygląda następująco:
Wielokąt jest rzeczą z niektórymi wierzchołkami.
Wewnętrznie nazwa „wielokąt” jest teraz kojarzona z rodzajem dynamicznie alokowanej struktury, która zawiera podwójnie połączoną listę wierzchołków. „Wierzchołek” jest zdefiniowany gdzie indziej (przed tą definicją lub po niej) w podobny sposób; liczba mnoga jest automatycznie rozumiana.
Typowa procedura wygląda następująco:
Aby dołączyć współrzędną x i ay do wielokąta: Utwórz wierzchołek, biorąc pod uwagę x i y. Dołącz wierzchołek do wierzchołków wielokąta.
Zauważ, że formalne nazwy (właściwe rzeczowniki) nie są wymagane dla parametrów i zmiennych. Uważamy, że jest to ważny wgląd. Moje krzesło i stół z prawdziwego świata nigdy (w normalnej rozmowie) nie są nazywane „c” lub „myTable” - nazywam je po prostu „krzesłem” i „stołem”. Podobnie tutaj: „wierzchołek” i „wielokąt” są naturalnymi nazwami takich rzeczy.
Zauważ też, że spacje są dozwolone w rutynowych i zmiennych „nazwach” (takich jak „x coordin”). To jest 21 wiek, tak? I że „pseudonimy” są również dozwolone (takie jak „x” dla „x coordin”). I to, że dzierżawcze („wierzchołki wieloboku”) są używane w bardzo naturalny sposób do odniesienia się do „pól” w „zapisach”.
Zauważ też, że słowo „dane” mogło być „za pomocą” lub „z” lub jakimkolwiek innym równoważnym, ponieważ nasze niedbałe parsowanie koncentruje się na obrazach (typach) i umiejętnościach (procedurach) potrzebnych do zrozumienia i ignoruje tak wiele jak to możliwe, reszta.
Na najniższym poziomie rzeczy wyglądają tak:
Aby dodać numer do innego numeru: Intel 8B85080000008B008B9D0C0000000103.
Zauważ, że w tym przypadku mamy zarówno najwyższy, jak i najniższy język - angielski i kod maszynowy (choć w systemie szesnastkowym) - w jednej procedurze. Wgląd tutaj polega na tym, że (podobnie jak typowa książka matematyczna) program powinien być napisany przede wszystkim w języku naturalnym, z odpowiednimi fragmentami w wygodniejszych składniach, jakie są wymagane (i tylko jako).
Możesz pobrać nasz system rozwoju tutaj: www.osmosian.com/cal-3040.zip. To mały program dla systemu Windows, mniejszy niż megabajt. Jeśli zaczniesz od pliku PDF w katalogu „dokumentacja”, zanim przejdziesz do dziesięciu stron, ponownie skompilujesz cały shebang sam w sobie (w mniej niż trzy sekundy na najprostszej maszynie z Walmart).
Pytania i komentarze należy kierować na adres [email protected]
źródło
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.źródło
Chociaż są one podobne, ponieważ zadawane pytania są podobne, są dość różne pod względem złożoności. Główną różnicą jest to, że język naturalny jest z natury niejednoznaczny (nawet na poziomie słów). Nie jest nawet jasne, co należy rozumieć przez słowo? Jednak w świecie języków programowania do dyspozycji jest wiele różnych urządzeń definiujących. Spójrz na gramatyki do analizowania języka naturalnego i te do analizowania języków programowania, różnica w wielkości jest oszałamiająca. Chodzi o to, że gramatyki języków programowania są systemami formalnymi; więc podlegają one analizie matematycznej. Radzenie sobie z dwuznacznościami rodzi wiele problemów, dla których rozwiązanie w języku programowania byłoby banalne lub proste.
Być może różnica między językami naturalnymi a językami programowania zmniejszy się, jeśli zmniejszy się przepaść między informatykami a „naturalnymi” ludźmi.
źródło
W ostatnich latach zainteresowanie (E) DSL i płynnymi interfejsami stale rosło w wielu różnych językach: Haskell, różnych językach skryptowych, C #, Java, a nawet C ++ (pomyśl o przeciążeniu
operator<<
do robienia wyników).W pewnym stopniu umożliwiają one bardziej naturalny odczyt kodu. Zilustruję przykładem EDSL w wersji groovy. Groovy.time pakiet pozwala na pisanie
Jeśli miałbyś to zrobić za pomocą klasy java.util.Calendar , musiałbyś napisać coś takiego na pierwszy przykład:
źródło
Języki komputerowe (nawet podstawowe języki maszynowe z dawnych czasów) to języki ludzkie, ponieważ służą one przede wszystkim do komunikacji z innymi ludźmi, są zdefiniowane przez ludzi i są używane jedynie w celu przekazania instrukcji do maszyny. Tak więc ewoluują one w ten sam sposób, w jaki ewoluują języki „naturalne” (wystarczy wyszukać „idiomy” dla swojego ulubionego języka, sprawdź, jak np. C ewoluowało z K&R C do obecnej ISO-C 2011. Ale istnieją w innym środowisku, musi przekazywać dokładne znaczenie (komputery są wciąż zbyt głupie, aby mieć sens i korygować to, o co się od nich pyta), a ponadto istnieje przewaga w łatwości przetwarzania (w związku z tym gramatyka i słownictwo nawet w C ++, PL / 1 lub APL są znacznie prostsze niż np. angielski, który w języku naturalnym jest raczej prosty).
To samo można powiedzieć o formalizmie matematyki lub naukach w ogóle, a nawet planach (z natury 2D, a nie 1D, jak inne).
źródło