Budowanie DSL: Skrypty na języku ogólnego przeznaczenia czy samodzielne?

10

Zastanawiam się nad stworzeniem języka specyficznego dla domeny, aby uprościć dany, niejasny model programowania. Część debaty dotyczy tego, czy zbudować go (jako skrypt) na istniejącym języku / środowisku wykonawczym (np. Java), czy też uczynić go samodzielnym (własny kompilator, & c).

Ci z was, którzy mają doświadczenie w projektowaniu DSL, czy mają zalety / wady i pewną odpowiedź na odpowiednie podejście?

language-design scripting dsl runtime Jé Queue
źródło
kto jest konsumentem tej DSL? i jakie są potencjalne hosty (wspomniałeś o Javie, czy rozważasz inne możliwości)?
Mauricio Scheffer
Rozważam każdą możliwość dla gospodarzy. Konsumentami będą ci, którzy piszą programy asynchroniczne (wiadomości z miejscami docelowymi).
Jé Queue

Odpowiedzi:

9

Polecam utworzenie DSL na istniejącym języku (wewnętrzny DSL). Zrobiłem to kilka razy z Pythonem, tworząc systemy, w których konsument DSL zapisuje plik Pythona, który jest używany jako plik konfiguracyjny dla systemu. Plik konfiguracyjny wykorzystuje konstrukcje (klasy, funkcje), które zdefiniowałem. Te konstrukcje tworzą DSL.

IMO, język taki jak Python (IronPython lub Jython, jeśli system hosta to .NET lub Java) lub Ruby (IronRuby, JRuby) jest lepszy do bazowania na DSL niż Java lub C #.

W moim przypadku hostami był również (C) Python, więc wybór Pythona do DSL był czymś naturalnym.

Niektóre zalety:

  • Niższy koszt budowy. Do wdrożenia jest o wiele mniej. Możesz skoncentrować się na danym problemie zamiast spędzać czas na implementacji parsera / kompilatora / interpretera.
  • Dostęp do języka hosta: Twój język będzie miał dostęp do pełnej mocy istniejącego języka / platformy.
Codeape
źródło
Jestem dość obojętny na język, ale dlaczego według ciebie wcielenia w języku Python są bardziej odpowiednie?
Jé Queue 24.01.11
1
Lepiej nadaje się niż co? Wydaje mi się, że Ruby i Python mają wiele takich samych zalet, Ruby jest może nawet lepiej nadaje się do wewnętrznego DSL ze względu na bardziej elastyczną składnię. Jeśli chodzi o Javę i C #, widziałem wiele świetnych płynnych interfejsów w tych językach (i istnieją nowsze konstrukcje, które ułatwiają tworzenie / używanie wewnętrznego DSL, takie jak składnia inicjalizatora obiektów) - ale IMO języki „niskiej ceremonii” są nieco lepiej nadaje się niż języki „wysokiej ceremonii”.
codeape
1
Wybrałem C #, aby precyzyjnie zaimplementować wewnętrzny DSL w celu wykorzystania „darmowego” sprawdzania statycznego typu kompilacji w czasie. Dynamiczne DSL-y nie dają zbyt wielu korzyści w stosunku do zewnętrznych DSL-ów.
Den
@Den właśnie to mnie rozczarowało, gdy próbowałem robić iDSL w Pythonie. W Javie iDSL wydaje się, że otrzymuje natychmiastowe wsparcie z IDE. Nie znalazłem IDE, które zrobi to dla Pythona.
candied_orange
2

Spójrz na Xtext (http://www.eclipse.org/Xtext/) i Xbase (http://blog.efftinge.de/2010/09/xbase-new-programming-language.html). Jeśli użytkownicy nie są programistami, nie sądzę, że powinieneś opierać swoją DSL na istniejącym języku programowania. Będzie to dla nich zbyt skomplikowane. „Czysta” DSL może być bardzo wydajna, jeśli zostanie wykonana poprawnie.

Henrik
źródło
2

Zamiast zalecać konkretne podejście, pozwól mi polecić Języki specyficzne dla domeny Martina Fowlera jako doskonały zasób do podjęcia decyzji. Zawiera obszerne, skłaniające do refleksji badanie względnych zalet wewnętrznych i zewnętrznych DSL.

eggsyntax
źródło
1

Istnieje trzecia opcja - zbuduj DSL jako kompilator na języku ogólnego przeznaczenia. Dowolny język z jakimś rozsądnym poziomem możliwości metaprogramowania wykona zadanie, w tym nawet na tak niskim poziomie, jak C ++. Wolę Lisp i podobne języki do tego rodzaju rzeczy, ale Template Haskell lub Nemerle mogą również zapewnić ten sam poziom elastyczności.

Logika SK
źródło
1

W swojej książce „Języki specyficzne dla domeny” Martin Folwer opisuje wewnętrzne i zewnętrzne DSL.
Internal DSL= jest podzbiorem istniejącego języka programowania, np. Ruby / Java itp.
External DSL= definiujesz składnię i słownictwo.
Zewnętrzny DSL może być znacznie bardziej wyrazisty, ale może wymagać zewnętrznego parsowania i generowania kodu.
Podczas gdy wewnętrzna DSL nie wymaga dodatkowego przetwarzania, ale czasami jest trudna do zrozumienia dla nieprogramowych ekspertów w dziedzinie (np. Analityków biznesowych, testerów).

Wybierając typ DSL, należy przeanalizować, kim są jego użytkownicy. Jeśli w większości są to osoby nietechniczne, lepszym wyborem może być zewnętrzna DSL. Dla małego zespołu doświadczonych programistów można wybrać wewnętrzną DSL, jeśli używany przez nich język programowania jest wystarczająco wyrazisty.

Olha Pawliuk
źródło