Moja odpowiedź jest tak naprawdę rozwinięciem Gillesa, którego nie przeczytałem przed napisaniem własnego. Może jednak jest to pomocne.
Pozwólcie, że zacznę próbę odpowiedzi na wasze pytanie z rozróżnieniem między dwoma wymiarami pracy języków programowania, które odnoszą się zupełnie inaczej do ogólnej teorii języków programowania, a zwłaszcza do rachunku procesowego.
Ten drugi typowo ma miejsce w przemyśle w celu zapewnienia języków programowania jako produktu. Zespoły rozwijające Javę w Oracle i C # w Microsoft to przykłady. Natomiast czyste badania nie są powiązane z produktami. Jego celem jest zrozumienie języków programowania jako obiektów o istotnym znaczeniu i zbadanie struktur matematycznych leżących u podstaw wszystkich języków programowania.
Ze względu na rozbieżne cele różne aspekty teorii języka programowania są istotne w czystych badaniach oraz w badaniach i rozwoju ukierunkowanych na produkt. Poniższy rysunek może wskazywać, co jest ważne gdzie.
W tym miejscu można zapytać, dlaczego te dwa wymiary są tak pozornie różne i jak się odnoszą.
Kluczowym wnioskiem jest to, że badania i rozwój języka programowania mają wiele wymiarów: techniczny, społeczny i ekonomiczny. Niemal z definicji przemysł jest zainteresowany opłacalnością ekonomiczną języków programowania. Microsoft i wsp. Nie rozwijają języków z dobroci serca, ale ponieważ wierzą, że języki programowania dają im przewagę ekonomiczną. Dokładnie zbadali, dlaczego niektóre języki programowania odnoszą sukcesy, a inne, pozornie podobne lub z bardziej zaawansowanymi funkcjami, nie. I odkryli, że nie ma jednego powodu. Języki programowania i ich środowiska są złożone, podobnie jak powody przyjęcia lub zignorowania określonego języka. Ale najważniejszym czynnikiem decydującym o sukcesie języka programowania jest preferencyjne przywiązanie programistów do języków, które są już powszechnie używane: im więcej ludzi używa języka, tym więcej bibliotek, narzędzi, materiałów dydaktycznych jest dostępnych i im bardziej produktywny jest programista może używać tego języka. Nazywa się to również efektem sieciowym. Innym powodem są wysokie koszty zamiany języków dla osób i organizacji: opanowanie języka, szczególnie dla niezbyt doświadczonego programisty, a gdy odległość semantyczna do znanych języków jest duża, jest poważnym i czasochłonnym wysiłkiem. Biorąc pod uwagę te fakty, można zapytać, dlaczego nowe języki w ogóle się cieszą? Dlaczego firmy w ogóle opracowują nowe języki? Dlaczego nie pozostaniemy przy Javie lub Cobolu? Myślę, że istnieje kilka kluczowych powodów, dla których język nie odnosi sukcesu,
Otwiera się nowa domena programowania, w której nie ma żadnych operatorów zasiedlających. Podstawowym przykładem jest sieć z towarzyszącym jej wzrostem Javascript.
Lepkość językowa. Rozumiem przez to wysoką cenę zmiany języka. Ale czasami programiści przechodzą do różnych dziedzin, zabierając ze sobą język programowania i odnosząc sukces ze starym językiem w nowej dziedzinie.
Język jest wspierany przez dużą firmę o poważnej finansowej sile ognia. To wsparcie zmniejsza ryzyko adopcji, ponieważ wcześni użytkownicy mogą mieć pewność, że język będzie nadal obsługiwany za kilka lat. Dobrym tego przykładem jest C #.
Język może pochodzić z przekonujących narzędzi i ekosystemu. Tutaj również C # i jego ekosystem .Net i Visual Studio można wymienić jako przykład.
Stare języki wychwytują nowe funkcje. Przychodzi mi na myśl Java, która w każdej iteracji czerpie więcej dobrych pomysłów z tradycji programowania funkcjonalnego.
Wreszcie, nowy język może mieć nieodłączne zalety techniczne, np. Być bardziej wyrazisty, mieć lepszą składnię, systemy pisania, które wychwytują więcej błędów itp.
Biorąc to pod uwagę, nie powinno dziwić, że istnieje pewien rozdźwięk między badaniami czystego języka programowania a rozwojem komercyjnego języka programowania. Podczas gdy oba mają na celu usprawnienie budowy i ewolucji oprogramowania, szczególnie w przypadku oprogramowania na dużą skalę, praca w języku programowania przemysłowego musi być bardziej zainteresowana ułatwieniem szybkiego przyjęcia, aby osiągnąć masę krytyczną i uzyskać efekt sieci. Prowadzi to do skoncentrowania badań na rzeczach, na których zależy pracującym programistom. I takie są na przykład dostępność biblioteki, szybkość kompilatora, jakość skompilowanego kodu, przenośność i tak dalej. Rachunek procesowy, który ćwiczymy dzisiaj, jest mało przydatny dla programistów pracujących nad projektami głównego nurtu (chociaż wierzę, że to się zmieni w przyszłości).
Badania nad czystym językiem programowania są zupełnie inne. Działa z uproszczonymi modelami języków programowania: -calculus to ogromne uproszczenie programowania funkcjonalnego. W ten sam sposób -calculus jest ogromnym uproszczeniem współbieżnego programowania. Te ogromne uproszczenia są kluczem do udanych badań. Umożliwiają nam skupienie się na podstawowych mechanizmach obliczeniowych (np.π βλπβ- redukcja do programowania funkcjonalnego, rozdzielczość / unifikacja do programowania logiki, przekazywanie nazw dla obliczeń współbieżnych). Aby zrozumieć, czy język taki jak Scala może mieć pełne możliwości wnioskowania na podstawie typu, nie musimy się martwić o JVM. Rzeczywiście, myślenie o JVM wpłynie negatywnie na lepsze zrozumienie wnioskowania typu. Dlatego abstrakcja obliczeń na małe kalkulatory rdzeniowe jest niezbędna i potężna.
Możesz więc myśleć o badaniach nad językiem programowania jako o ogromnej piaskownicy, w której ludzie bawią się zabawkami, a jeśli znajdą coś interesującego podczas zabawy z konkretną zabawką i dokładnie ją zbadają, to ta interesująca zabawka rozpoczyna swój długi marsz w kierunku powszechnej akceptacji przemysłowej . Mówię długi marsz, ponieważ funkcje językowe opracowane po raz pierwszy przez programistów zajmujących się językiem programowania zwykle trwają dekady, zanim stają się powszechnie akceptowane. Na przykład wyrzucanie elementów bezużytecznych zostało wymyślone w latach 50. XX wieku i stało się szeroko dostępne w Javie w latach 90. Dopasowywanie wzorców nawiązuje do 1970 roku i jest szeroko stosowane dopiero od Scali.
Rachunek procesowy jest szczególnie interesującą zabawką. Ale to zbyt nowe, aby je dokładnie zbadać. To zajmie kolejną dekadę czystych badań. W badaniach nad teorią procesów obecnie bierze się największy sukces badań nad językiem programowania, teorię typów (sekwencyjnych) i rozwija teorię typów współbieżności przekazywania komunikatów. Systemy pisania o umiarkowanej ekspresji dla programowania sekwencyjnego, powiedzmy Hindley-Milner, są teraz dobrze zrozumiane, wszechobecne i akceptowane przez pracujących programistów. Chcielibyśmy mieć umiarkowanie ekspresyjne typy do równoczesnego programowania. Badania w tej dziedzinie rozpoczęły w latach 80. pionierzy tacy jak Milner, Sangiorgi, Turner, Kobayashi, Honda i inni, często opierając się, wprost lub pośrednio, na idei liniowości wynikającej z logiki liniowej. W ciągu ostatnich kilku lat nastąpił znaczny wzrost aktywności i oczekuję, że ta tendencja wzrostowa utrzyma się w dającej się przewidzieć przyszłości. Spodziewam się również, że praca ta zacznie przenikać do badań i rozwoju ukierunkowanego na produkt, częściowo z pragmatycznego powodu, że młodzi badacze, którzy zostali przeszkoleni w zakresie rachunku procesowego, pójdą do pracy w przemysłowych laboratoriach badawczo-rozwojowych, ale także z powodu ewolucji procesora i architektury komputera z sekwencyjnych form obliczeń.
Podsumowując, nie martwiłbym się, że nie znalazłeś nowatorskiej teorii języka programowania, takiej jak rachunek procesowy, przydatnej we własnej pracy nad budowaniem języków. Jest tak po prostu dlatego, że najnowsza teoria nie uwzględnia problemów obecnych języków programowania. Chodzi o przyszłe języki. Nadejście „prawdziwego świata” potrwa. Wiedza, której używasz do tworzenia języków na dziś, to teoria języków programowania z przeszłości. Zachęcam do zapoznania się z rachunkiem procesowym, ponieważ jest to jeden z najbardziej ekscytujących obszarów całej teoretycznej informatyki.
Nauka projektowania języka programowania jest w powijakach. Teoria (badanie znaczenia programów i ekspresji języka) i empiryzm (co programiści robią, a czego nie potrafią) dostarczają wielu jakościowych argumentów do rozważenia w taki czy inny sposób podczas projektowania języka. Ale rzadko mamy ilościowy powód do podjęcia decyzji.
Występuje opóźnienie między czasem, gdy jakaś teoria ustabilizuje się na tyle, aby innowacja mogła być użyta w praktycznym języku programowania, a momentem, w którym ta innowacja zaczyna pojawiać się w językach „głównego nurtu”. Na przykład można powiedzieć, że automatyczne zarządzanie pamięcią z funkcją odśmiecania zostało dojrzałe do użytku przemysłowego w połowie lat sześćdziesiątych, ale do głównego nurtu w Javie doszło dopiero w 1995 roku. Polimorfizm parametryczny został dobrze zrozumiany pod koniec lat siedemdziesiątych XX wieku na Javę w połowie lat dwudziestych. W skali kariery naukowca 30 lat to dużo czasu.
Szeroko zakrojona na skalę przemysłową adopcja języka jest kwestią do zbadania przez socjologów, a nauka jest jeszcze w powijakach. Istotnym czynnikiem są względy rynkowe - jeśli Sun, Microsoft lub Apple popchną język, ma to o wiele większy wpływ niż jakakolwiek liczba dokumentów POPL i PLDI. Nawet dla programisty, który ma wybór, dostępność biblioteki jest zwykle o wiele ważniejsza niż projektowanie języka. Nie oznacza to, że projektowanie języka nie jest ważne: dobrze zaprojektowany język to ulga! Zwykle nie jest to decydujący czynnik.
Rachunki procesowe są wciąż na etapie, w którym teoria się nie ustabilizowała. Uważamy, że rozumiemy obliczenia sekwencyjne - wszystkie modele rzeczy, które lubimy nazywać obliczeniami sekwencyjnymi, są równoważne (taka jest teza Churcha-Turinga). Nie dotyczy to współbieżności: w różnych procesach obliczeniowych występują subtelne różnice w ekspresji.
Rachunki procesowe mają praktyczne implikacje. Wiele obliczeń jest rozproszonych - dotyczą one klientów rozmawiających z serwerami, serwerów rozmawiających z innymi serwerami itp. Nawet obliczenia lokalne są bardzo często wielowątkowe, aby wykorzystać równoległość wielu procesorów i reagować na współbieżność środowiska (komunikacja z niezależnymi programami i z użytkownikiem).
Czy potrzebne są postępy w badaniach, aby stworzyć lepsze oprogramowanie? W końcu istnieje przemysł warty miliardy dolarów, który nie potrafi odróżnić rachunku pi od ciasta na niebie. Z drugiej strony branża wydaje miliardy dolarów na naprawianie błędów.
„Czy kiedykolwiek będą potrzebne” nigdy nie jest wartościowym pytaniem w badaniach. Nie można przewidzieć z góry, co będzie miało długoterminowe konsekwencje. Chciałbym nawet pójść dalej i powiedzieć, że jest to bezpieczne założenie, że jakiekolwiek badania będą miały konsekwencje pewnego dnia - po prostu nie wiemy w tym czasie, czy ten dzień nadejdzie w przyszłym roku, czy następnym tysiącleciu.
źródło
To trudne pytanie! Opowiem ci moją osobistą opinię i podkreślam, że to moja opinia .
Nie sądzę, aby rachunek pi był bezpośrednio odpowiedni jako notacja dla programowania współbieżnego. Myślę jednak, że zdecydowanie powinieneś go przestudiować przed zaprojektowaniem współbieżnego języka programowania. Powodem jest to, że rachunek pi daje niski poziom --- ale co ważne, kompozycję! --- konto współbieżności. W rezultacie może wyrazić wszystko, co chcesz, ale nie zawsze wygodnie.
Wyjaśnienie tego komentarza wymaga trochę myślenia o typach. Po pierwsze, przydatne języki programowania zwykle wymagają pewnego rodzaju dyscypliny typu w celu tworzenia abstrakcji. W szczególności potrzebujesz jakiegoś rodzaju funkcji, aby korzystać z abstrakcji proceduralnych podczas tworzenia oprogramowania.
Teraz dyscyplina typu pi-rachunek jest odmianą klasycznej logiki liniowej. Zobacz na przykład artykuł Abramsky'ego Process Realizability , który pokazuje, jak interpretujesz proste programy współbieżne jako dowody zdań z logiki liniowej. (Literatura zawiera dużo pracy na temat typów sesji do pisania programów typu pi-rachunek, ale typy sesji i typy liniowe są ze sobą ściśle powiązane).
Jest to w porządku z teorii typów POV, ale jest to niewygodne podczas programowania. Powodem jest to, że programiści ostatecznie zarządzają nie tylko wywołaniami funkcji, ale także stosem wywołań. (Rzeczywiście, kodowanie rachunku lambda do rachunku pi zazwyczaj wygląda jak transformaty CPS.) Teraz, pisanie gwarantuje, że nigdy tego nie zepsują, ale mimo to jest dużo księgowości narzuconych programistom.
Nie jest to problem unikalny dla teorii współbieżności --- rachunek mu daje dobre teoretyczne zestawienie operatorów sterowania sekwencyjnego, takich jak call / cc, ale za cenę wyraźnego określenia stosu, co czyni go niezręcznym językiem programowania.
Tak więc, projektując współbieżny język programowania, uważam, że powinieneś projektować swój język z abstrakcyjnymi poziomami wyższymi niż surowy rachunek pi, ale powinieneś upewnić się, że jest on przetłumaczony na rozsądny typowy rachunek procesowy. (Dobrym niedawnym przykładem tego są procesy, funkcje i sesje wyższego rzędu Tonhino, Caires i Pfenning : integracja monadyczna ).
źródło
Mówisz, że „ prawdziwym celem końcowym byłoby wykorzystanie teorii do zbudowania PL”. Przypuszczalnie przyznajesz, że są jeszcze inne cele?
Z mojego punktu widzenia celem teorii nr 1 jest zapewnienie zrozumienia, które może dotyczyć rozumienia istniejących języków programowania, a także programów w nich zapisanych. W wolnym czasie utrzymuję duże oprogramowanie, klienta poczty elektronicznej, napisane przed laty w Lisp. Cała znana mi teoria PL, taka jak logika Hoare'a, logika separacji, abstrakcja danych, parametryczna relacja i równoważność kontekstowa itp. Przydaje się w codziennej pracy. Na przykład, jeśli rozszerzę oprogramowanie o nową funkcję, wiem, że nadal musi zachować oryginalną funkcjonalność, co oznacza, że powinien zachowywać się tak samo we wszystkich starych kontekstach, nawet jeśli zamierza zrobić coś nowego w nowe konteksty. Gdybym nie wiedział nic o ekwiwalencji kontekstowej, prawdopodobnie nawet nie byłbym w stanie ująć tego problemu w ten sposób.
Jeśli chodzi o twoje pytanie dotyczące rachunku różniczkowego, myślę, że rachunek różniczkowy wciąż jest zbyt nowy, aby znaleźć aplikacje w projektowaniu języka. Strona wikipedii na temat pi-rachunek zawiera wzmiankę BPML i occam-pi jako projekty językowe przy użyciu pi-rachunku. Ale możesz również spojrzeć na strony jego poprzednika CCS i inne rachunki procesowe, takie jak CSP, rachunek różniczkowy i inne, które były używane w wielu projektach języka programowania. Możesz również zajrzeć do sekcji „Obiekty i rachunek różniczkowy” w książce Sangiorgi i Walker, aby zobaczyć, w jaki sposób rachunek różniczkowy i całkujący odnosi się do istniejących języków programowania.
źródło
Lubię szukać praktycznych implementacji rachunku procesowego na wolności :) (oprócz czytania o teorii).
itp.
źródło