Czy programowanie zorientowane na język jest praktyczne?

12

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?

Michael K.
źródło
To z pewnością ma ogromny potencjał.
2
Nie jest dla mnie jasne, jaki problem rozwiązuje ten paradygmat. Nawiasem mówiąc, LISP nie jest przykładem udanego języka.
mouviciel
7
@mouviciel zależy w dużej mierze od tego, co dokładnie rozumiesz przez „sukces”. Czy jest używany przez większość programistów? Nie. Czy był używany od dłuższego czasu? Tak - 50 lat i wciąż rośnie. Czy większość współczesnych języków ukradła z tego cały zestaw przydatnych funkcji? Tak. (Czy języki mogą ukraść jeszcze więcej z języków Lisp? Tak!)
Frank Shearar
2
Istnieje różnica między językiem powszechnie używanym a przydatnym. Język, który eksploruje nowe obszary, na ogół nie jest używany, ale może przyczynić się do wszystkiego w dłuższej perspektywie. Z drugiej strony Java jest bezużyteczna, ponieważ nie wprowadza niczego nowego do tabeli (mimo że zdecydowanie jest udanym językiem dla wszystkich kont).
Matthieu M.,
1
Przydałoby mi się bardziej opanowanie Lispa niż opanowanie Cobola.
glenatron

Odpowiedzi:

8

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.

Mike Dunlavey
źródło
Zdecydowanie zgadzam się z tobą w części modowej - „spiczasty włosy szef wie, w jakim języku powinien być napisany. [...] Java.” Inną kwestią jest to, co Joel nazywa „architektem astronautą”. Widziałem też, jak DSL układają się na sobie nawzajem ad infitium (sp?). Myślę, że sprowadza się to do programisty -> inżyniera oprogramowania -> informatyka.
Michael K
A jeśli nie wymaga wysiłku, aby zrozumieć, są szanse, że tak naprawdę nie jest tego warte :)
Michael K
4

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.

Nerian
źródło
7
RoR nie jest dialektem Ruby.
back2dos
4
@ back2dos: Myślałem o metaprogramowaniu. Oczywiście RoR nie jest innym językiem programowania. Przez dialekt rozumiem to, że nawet jeśli wszystko pod Railsami jest Ruby, z punktu widzenia dewelopera używa Ruby na wyższym poziomie abstrakcji. Domena Dialekt. Korzysta z widoków, modeli, kontrolerów i programuje je za pomocą składni, która przypomina inny język, że tak powiem, dialekt. To piękno języka skryptowego tak potężnego jak Ruby.
Nerian
Myślę, że ważne jest, aby naprawdę zobaczyć różnicę. AspectJ jest dialektem Java, podczas gdy AspectR to tylko biblioteka Ruby. Różnica polega naprawdę na języku. Ruby został zaprojektowany, aby zapewnić elastyczność i ekspresję, a Java nie. Oba języki można uznać za języki ogólnego przeznaczenia, z tą różnicą, że Ruby jest na ogół wystarczająco ekspresyjny, aby wyeliminować potrzebę faktycznego DSL do dowolnego ogólnego celu, podczas gdy Java nie jest, chociaż na przykład często używasz widoków, modeli i kontrolerów.
back2dos
1

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.

Logika SK
źródło
Przepraszam za moją ignorancję - eDSL może być preprocesorem innego języka, prawda?
Michael K
@Michael, tak, możliwe jest wdrożenie eDSL w ten sposób, patrz na przykład CamlP4. Jednak coraz częściej eDSL opiera się na własnych funkcjach języka (np. Makra Lisp, szablony C ++ itp.).
SK-logic
1

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.

glenatron
źródło
Możesz dodać FoF, który służy do tworzenia sterowników dla jądra Barrelfish. Język do tworzenia DSL w :)
Matthieu M.,
0

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.

Kakungulu
źródło