Czy programowanie zorientowane na język jest praktyczne?

Przeczytałem ten artykuł na temat programowania zorientowanego na język. Wskazuje pewne słabości współczesnego podejścia proceduralnego / OOP do programowania i sugeruje nowy paradygmat programowania, który je rozwiąże

Jestem zwolennikiem małych, luźno powiązanych części programu: o wiele lepiej jest nauczyć się wielu małych rzeczy, z których będziesz korzystać, niż kilku dużych rzeczy, których używasz tylko fragmentów.

Czytając artykuł, mam wrażenie, że autor promował jedną z dwóch rzeczy:

• Wiele łatwo tworzalnych języków skryptowych
• Pojedynczy, łatwo rozszerzalny język, który może przepisać się w celu zaspokojenia potrzeb programisty

Jeśli sugeruje drugie, odpowiedziałbym: „Już gotowe!” i podaj Lisp jako przykład. Jak sugeruje Paul Graham, i tak wydaje się, że języki ciągle się do tego dążą .

Jeśli chodzi o pierwsze, myślę, że to dobry pomysł, jeśli istnieje podstawowy język, który łączy je wszystkie razem. Wydaje mi się, że to słaby punkt: komunikacja między językami. Czy użyłbyś połączeń, które są pojęciem proceduralnym lub przekazywaniem wiadomości, które przypominają mi komunikację międzyprocesową? Z przyjemnością skorzystam z możliwości pracy z małymi językami specyficznymi dla domeny, jeśli można z nich korzystać jednocześnie. Czy takie podejście (LOP) byłoby praktyczne?

Od dawna opowiadam się za DSL, ale martwię się tym, co stanie się z Dobrymi Pomysłami, kiedy staną się bandwagonami. Buduj produkty, które reklamują Dobry pomysł, obiecując, że wszystko, co musisz zrobić, to go zdobyć , a będziesz w grupie, bez konieczności bardzo uważnego zastanawiania się, co to znaczy.

Co to jest język To słownictwo i składnia, w których można przekazywać znaczenia, prawda? Za każdym razem, gdy deklarujesz zmienną, piszesz funkcję, definiujesz klasę, budujesz nowy język, dodając rzeczowniki i czasowniki do istniejącego języka. Teraz możesz powiedzieć rzeczy, których wcześniej nie mogłeś.

Myślę, że tym, co sprawia, że ​​język jest specyficzny dla Domeny, jest zakres, w jakim w naturalny sposób wyraża on koncepcje mentalne, które są przekazywane, i myślę, że jest na to prosta miara. Zasadniczo, jeśli istnieje proste, niezależne, niezależne wymaganie X, które może być zawarte w programie lub nie, jego poprawna implementacja wymaga pewnego zestawu wstawiania, usuwania i zastępowania kodu Y. Prosty diff przed i po może wyświetlić Y. Liczba N takich zmian jest miarą tego, jak specyficzny dla domeny jest język. Im mniejsze N, tym typowe wymagania są tym lepsze.

Nie musi to zależeć od fantazyjnej składni, struktur kontrolnych, przekazywania wiadomości lub tego, co masz. Zależy od tego, jak zwięźle realizuje to wymaganie. Wiele narzędzi twierdzi, że to robi, ale twierdzenia nie są rzeczywiste. To musi być prawda .

Czasami konieczna jest niezwykła technologia . Oto mój ulubiony przykład. Gdy tak jest, ilustruje to, że może to wymagać wysiłku ze strony programistów, aby to zrozumieć. Tak więc specyficzność domeny (i łatwość konserwacji) wcale nie jest tym samym, co czytelność .

Zgadzam się więc z drugim podejściem, że dobry język to taki, który pozwala łatwo zbudować na nim niezbędne języki. (Właśnie to lubiłem w Lisp.) Ale jeszcze ważniejsze jest to, że programiści muszą wiedzieć, jak budować języki dopasowane do dziedzin, w których pracują, i być gotowym wspinać się na krzywe uczenia się takich języków.

Tak naprawdę to nie widzę. Zamiast tego utknęli w „programach = algorytmy + struktura danych” lub „rzeczowniki stają się klasami, a czasowniki stają się metodami”. Nie pracują w kategoriach, jak brać domeny myślowe i je lingwistycznie dla maksymalnej dokładności.

To całkiem rubinowe podejście.

• Utrzymaj prosty język podstawowy i rozszerzaj go za pomocą klejnotów
• Twórz dialekty języka Ruby dla określonych domen poprzez łatanie małp. ig Ruby on Rails.

Nie wiem, czy tak jest lepiej, ale myślę, że jest bardzo pragmatyczny.

Podejście LOP jest niezwykle praktyczne. Należy pamiętać, że niekoniecznie trzeba wdrażać „języki skryptowe” - metodologia ma również zastosowanie do eDSL i zazwyczaj są one skutecznie kompilowane. Używam tego podejścia w dosłownie całej mojej pracy programistycznej.

W przyszłości zobaczymy wiele więcej o językach specyficznych dla domeny, sądząc po ludziach, którzy teraz o nich mówią - zauważyłem, że Martin Fowler też dużo o nich mówi i kilka interesujących artykułów w Lambda The Ultimate na ten temat, pośród innych.

To sugeruje mi, że jest to zdecydowanie kierunek, w którym wieje wiatr w odniesieniu do projektowania języka programowania i platform programistycznych. Pod pewnymi względami już od jakiegoś czasu - jedną z zalet Ruby (jak ktoś już zauważył) jest to, że ułatwia tworzenie DSL, ale w rzeczywistości jest ich mnóstwo w aplikacjach i bibliotekach programistycznych, których już używamy.

Używam LOP przy programowaniu solo. Odkryłem, że w niektórych projektach nie ma innego sposobu na dotrzymanie harmonogramu. W prostej alegorii można przyrównać użycie LOP do elektronarzędzi. Jeśli pracujesz sam w warsztacie, nie możesz robić rzeczy ręcznie i dotrzymać terminu. Jeśli są przy tobie inne osoby, koordynacja użytkowania tych elektronarzędzi ma zasadnicze znaczenie dla wydajności i bezpieczeństwa.
W trybie drużynowym LOP wymaga przygotowania organizacyjnego, aby uniknąć katastrofy w Tower of Babel.