Kiedy rozsądnie jest stworzyć własny język programowania?

Czy istnieją rodzaje zabójczych aplikacji, klasy problemów algorytmicznych itp., Gdzie na dłuższą metę lepiej jest stworzyć własny język?

PS: Dla pewności mam na myśli nowy język programowania i kompilator, a nie nowy kompilator dla istniejącego języka.

EDYCJA : Dziękuję za odpowiedzi. Czy możesz podać kilka przykładów, w których absolutnie nie jest konieczne tworzenie DSL lub przypadków, w których DSL może być dobrym pomysłem?

Z pewnością ważne jest, aby osoba napisała własny język do celów edukacyjnych. Aby dowiedzieć się o projektowaniu języka programowania i projektowaniu kompilatora. Ale zastosowania w świecie rzeczywistym są nieliczne i dalekie.

Pisząc swój język, jesteś:

• Zwiększenie złożoności problemu
• Dodanie znacznej ilości pracy przy pisaniu i utrzymanie nowego języka i kompilatora

Tak więc, jeśli planujesz napisać własny język dla swojego projektu, to funkcje, które zapewnia, że ​​inne języki nie muszą kompensować powyższych kosztów.

Weźmy na przykład tworzenie gier. Często potrzebują mini-języków w swoich grach lub językach skryptowych. Używają tych języków, aby napisać scenariusz do wielu wydarzeń w grze, które się zdarzają. Jednak nawet w tym przypadku prawie zawsze wybierają istniejące języki skryptowe i dostosowują je do swoich potrzeb.

Pozwólcie, że zacytuję Paula Vicka, byłego głównego programistę kompilatora VB, a teraz pracującego nad Projektem Oslo i językiem M.

Budowanie nowego języka, nawet opartego w dużej mierze na istniejącym, jest niesamowicie trudne. Jednak wielu programistów myśli „hej, używam języków, jak trudne to może być?” I zaczynam . … Prawdopodobnie ponad 98% z nich nigdy nie zyskuje żadnej przyczepności, ale niech Bóg błogosławi optymistom, ponieważ bez nich nigdy nie uzyskalibyśmy 2% języków, które odniosą sukces. Osobiście jestem gotów poświęcić miliony dolarów i godziny zmarnowane na języki, które nigdy tego nie robią, abyśmy mogli uzyskać języki takie jak C # i Java, Ruby i Python i tak dalej.

Zatem fakt, że wymyślenie nowego języka jest złym pomysłem, nie powinien zniechęcać ludzi do opracowywania nowych DSL, powinien po prostu dać im przerwę i, miejmy nadzieję, odrobinę pokory. Myślę, że kluczem jest zacząć od małego i pozostać małym.

DSL: Zdecydowanie zły pomysł!

Kiedy to jest rozsądne?

Kiedy masz na to ochotę!

Nie słuchaj tych ludzi, którzy mają złośliwe komentarze, które w zasadzie mówią:

„Nie rób tego, ponieważ jest zbyt trudny, a język X jest lepszy niż jakikolwiek język, jaki możesz wymyślić”.

Rzecz w tym, że tworzenie DSL odbywa się cały czas. Framework to DSL. Makro to DSL. Za każdym razem, gdy piszesz funkcję dla swojego programu, jest to część DSL. Oczywiście, mieści się w granicach gramatyki, ale słownictwo jest częścią języka. Właśnie dlatego branże często tworzą własne języki: jest bardziej wydajny!

Gdyby „nie rób tego” było właściwą odpowiedzią, wszyscy pisalibyśmy w języku COBOL i Fortran.

Jeśli chcesz napisać własny język, możesz przeczytać fragmenty nadchodzącej książki Martina Fowlera o DSL .

Naprawdę nie mogę wymyślić uzasadnienia biznesowego, by stworzyć język od zera inny niż wspaniałe doświadczenie edukacyjne.

Edycja: w przypadku DSL istnieje wiele przypadków biznesowych, ale kluczem tutaj nie jest dać się ponieść emocjom i zachować prostotę.

Sugeruję, aby kluczowe pytania brzmiały: „Jaki problem próbuję rozwiązać?” i „Kto otrzymuje zwrot z inwestycji?”

Jeśli starasz się budować własne umiejętności i doświadczenie, musisz osiągnąć pełną prędkość, ale nie w systemie produkcyjnym, który powinien rozwiązać problem innej osoby.

Wydaje się, że głównym powodem, dla którego chcesz mieć nowy język, jest rozpoczęcie odkrywania w kodzie wzorców, których istniejące języki nie radzą sobie dobrze. Ale istnieje wiele problemów z tworzeniem własnego języka. Będziesz tracić wszystkie biblioteki i frameworki, które są zbudowane dla istniejących języków. Spędzisz dużo czasu na projektowaniu i wdrażaniu nowego języka, czyli przez cały czas nie musisz spędzać na prawdziwym zadaniu programistycznym. Sporo wysiłku przekonasz innych programistów, że powinni używać twojego języka. Będziesz miał trudności z rekrutacją i szkoleniem nowych programistów.

Dlaczego nie napisać w języku takim jak Lisp, który pozwala rozszerzyć ten język, odkrywając nowe wzorce? Następnie zyskujesz moc nowego języka ze wszystkimi zaletami ustalonego języka.

Jednym z powodów może być stworzenie go jako eksperymentu, aby dowiedzieć się o projektowaniu języka i budowaniu kompilatora.

Innym powodem może być wbudowanie języka skryptowego w aplikację, gdy nie ma możliwości dodania interfejsu API innej firmy.

Nie sądzę, że możesz programować bez tworzenia nowego języka, więc dobrze jest zdać sobie sprawę, że to, co robisz, i zrozumieć problemy.

• Co to jest język
  Słownictwo, składnia i semantyka.

Gotowy język, taki jak VB, Java, C # itp., To tylko język podstawowy . Jak tylko dodasz do niego klasy, metody itp., Dodasz słownictwo i semantykę. Istnieje wiele sposobów implementacji języków - parsowanie i tłumaczenie, parsowanie i tłumaczenie, makra na istniejącym języku, dodawanie klas i metod do istniejącego języka.

• Co chcesz robić w języku?
  Bądź dobry w zwięzłym wyrażaniu problemów.

Skąd wiesz, czy to zrobiłeś? Miarą, której używam, jest liczba edycji . Jeśli pojawi się wymóg A jednego zdania, przystępuję do implementacji tego wymogu w kodzie. Kiedy skończę i usunę wszystkie błędy, sprawdzam kod, a repozytorium kodu zawiera listę zmian, które wprowadziłem, B. Im mniejsze B, tym lepszy jest język. Uśredniona na podstawie rzeczywistych i możliwych wymagań, ta miara mówi mi, jak „specyficzny dla domeny” jest język.

• Dlaczego zwięzłość jest dobra?
  Ponieważ minimalizuje błędy.

Jeśli zajmie to N zmian kodu, aby zaimplementować 1 wymaganie, a czasami popełniasz błędy, liczba wprowadzonych błędów jest w przybliżeniu proporcjonalna do N. W limicie, w którym N = 1, prawie niemożliwe jest wprowadzenie błędu bez próby.

Pamiętaj, że jest to bezpośrednie wyzwanie dla „rozdętego kodu”, który widzimy obecnie.

DODANO: W odpowiedzi na prośbę o przykład zobacz wykonanie różnicowe . Nie powiem, że można to szybko zrozumieć, ale znacznie zmniejsza kod interfejsu użytkownika.

Używanie tego słowa w (oryginalnym) pytaniu zawsze jest „wykonalne”, ale nie jest zbyt często przydatne i bardzo rzadko optymalne, biorąc pod uwagę obfitość dobrze obsługiwanych i dojrzałych języków i struktur.

Jest to jednak interesujące wyzwanie intelektualne.

Tylko jeśli podstawową działalnością Twojego zespołu są języki programowania.

Pracowałem nad językiem programowania, który został stworzony w firmie finansowej.

Najwyraźniej dla samego architekta było to wielkie wyzwanie i poprawiło swoje umiejętności.

Nieuchronnie język nie mógł się rozwijać ani poprawiać w tempie zbliżonym do C # lub Java - mają zespoły zaangażowane w to.

Język wkrótce stał w miejscu, ponieważ nikt nie chciał podjąć się zadania ulepszenia czyjegoś projektu dla zwierząt domowych.

Oryginalny architekt odszedł. Język uschł i umarł po 10 latach.

Te 10 lat było piekłem dla każdego, kto miał nieszczęście pracować nad ślepym językiem.

Więc śmiało, stwórz swój własny język, ale proszę nie prosić nikogo o faktyczne użycie go. Nie oczekuj, że ktokolwiek Ci za to podziękuje.

Projektowanie języków może być świetną zabawą. Ale nie musisz ograniczać się do języków programowania.

Jeśli tworzę średnio złożoną aplikację, lubię dodawać język makr / skryptów, aby ułatwić wykonywanie skomplikowanych, powtarzalnych zadań. Większość użytkowników nie będzie korzystać z tej funkcji, ale niewielu, którzy z niej korzystają, jest bardzo wdzięcznych. Poza tym upewniam się, że wsparcie dla osób pomagających w rozwiązywaniu problemów klientów jest cenne.

Jest to całkowicie uzasadnione, jeśli jest zrobione w celu poszerzenia umiejętności i nauki.

Poza tym, jeśli musisz zadać pytanie, to nie jest. Jeśli próbujesz dowiedzieć się, czy możesz poradzić sobie z pewną klasą algorytmów lub domeną problemową lepiej niż istniejące języki, najpierw musisz być ekspertem w dziedzinie, którą się zajmujesz. Będziesz wiedział, że jest to właściwe, kiedy mówią o tym twoje umiejętności i doświadczenie.

I też możesz się mylić, ale potrzebujesz innego eksperta, aby cię o tym przekonać (lub pokazać, że nie jesteś ekspertem, za jakiego się uważasz). To byłaby ożywiona dyskusja, a nie zwykłe pytania i odpowiedzi, jak tu znajdziesz.

Z wyjątkiem celów samokształceniowych chciałbym twierdzić, że dziś nie ma potrzeby tworzenia własnego języka. W każdych okolicznościach. Zawsze. Niezależnie od tego, co chcesz zrobić, istnieje mnóstwo istniejących języków, które możesz wziąć / dostosować do swoich potrzeb.

To ostatecznie zależy od sytuacji. Jak powiedział nosklo - jeśli masz dobry pomysł, zupełnie nową koncepcję lub coś takiego, zdecydowanie polecam to zrobić.

Ogólnie sugeruję polegać na sprawdzonej technologii.

Ale jeśli chcesz stworzyć swój własny „język”, powinieneś sprawdzić: YACC i Lex

Możesz po prostu nie złapać się w anty-wzór „Odtwarzanie kwadratowego koła”.

Oznacza to, że odtwarzasz to, co już zostało zrobione, tylko gorsze niż oryginały.

Wouter był znany z tworzenia nowego języka dla każdego nowego pomysłu. Możesz czerpać inspirację z jego pracy: strony języka programowania Woutera .

Kiedy stworzyć własny język?

Kiedy chcesz, jako duży projekt hobby.

Dla języka specyficznego dla domeny. Mogą być dość skomplikowane; zobacz, co dzieje się w społeczności Interactive Fiction (lub przygody tekstowej), sprawdzając archiwum .

Kiedy twoje cele są bardzo ambitne i myślisz, że możesz zrobić prawdziwy postęp, jak projekt Arc Paula Grahama .

Również w każdym wystarczająco dostosowalnym języku (być może C ++, zdecydowanie Common Lisp) w procesie opracowywania konstrukcji niskiego poziomu.

Kiedy mam tego unikać, tak jak ty, mam nadzieję, unikając banału, jak unikanie tego jak zarazy?

Kiedy ma to być podstawą ciągłego rozwoju prawdziwych projektów. Zawsze kończy się poważnym opóźnieniem w stosunku do tego, co jest dostępne na rynku za tanie, i utrudnia dalszy rozwój. Pracowałem dla firmy z własną wersją COBOL i nigdy nie chcę pracować w innej firmie, która utrzymuje swój własny język. Widzieliśmy, jak inne wersje COBOL-u zyskują lepsze możliwości i lepsze narzędzia, podczas gdy mamy do czynienia z tymi samymi problemami. (Nie chcę nigdy więcej współpracować z COBOL, ale to już inna historia).

Nie wpadają w to sytuacje, w których możesz stworzyć swój własny język. Projekty hobby nie są wykorzystywane do prawdziwego rozwoju. Coś takiego jak Arc odniesie sukces (i otrzyma wiele implementacji oraz dalszej ewolucji i rozwoju) lub zakończy się niepowodzeniem (i nikt inny go nie wykorzysta). Mały język specyficzny dla domeny jest tylko częścią projektu, a ponieważ jest mały, można go z czasem ulepszyć. Język tekstowy jest używany do pisania pojedynczych gier, a te gry, oprócz tego, że są projektami hobbystycznymi, prawie nigdy nie są używane do dalszego rozwoju.

Moim zdaniem DSL są ogólnie „słabym pomysłem” i na dłuższą metę bardziej produktywne jest używanie standardowego języka i budowanie specyficznych dla domeny potrzeb jako biblioteki „nie-DSL”.

Może się jednak okazać, że Twoje potrzeby są na tyle niestandardowe, że lepiej jest mieć DSL (nie tylko nieco zmodyfikowaną implementację gcc lub lisp) dla Twojej firmy. Wiele firm korzysta z drop-ów obecnych języków, które są ukierunkowane na to, co robią, bez pisania / utrzymywania własnego języka. Np. Słyszałem, że PHP ma niezłą wtyczkę; Lua została zaprojektowana jako drop-in, ModelView używa Pythona, a AutoCAD ma AutoLISP jako scripter.

Nie ma nic złego w pisaniu własnego języka programowania, jeśli można wykorzystać istniejące narzędzia. W dzisiejszym świecie oznaczałoby to, że albo zdefiniujesz go w składni użytecznej dla istniejącego języka (jak Java lub C #), albo napiszesz mały system transformacji (makro-ekspander), który generuje kod w istniejącym języku.

Przejście na kod maszynowy wymyśla wiele kół ...

Bardzo dobrym powodem DSL jest zwięzłe przedstawienie danych domeny. Umożliwia to ekspertom domeny bezpośrednią pracę z danymi zamiast konieczności przechodzenia przez inne. Sztuka polega na tym, aby powstałe programy były łatwe do przetworzenia.

Ogólnie rzecz biorąc, odpowiedzią byłoby duże NIE. Spośród setek dostępnych języków zwykle jest taki, który będzie pasował do twojego problemu.

Istnieją jednak okoliczności, w których racjonalną opcją jest opracowanie nowego języka:

• Kiedy jeden z twoich konkurentów posiada teraz jedną z twoich głównych platform programistycznych. Mam na myśli obecne poleganie Googles na Javie i ich rozwój „go”, (to pomaga, jeśli masz autora najbardziej udanego języka na liście płac!).
• Kiedy musisz napisać mnóstwo kodu dla nowej platformy, a istniejące języki są pełne i podatne na błędy - np. Php do tworzenia stron internetowych.
• Kiedy natrafisz na problemy skali i równoległości, których nigdy wcześniej nie spotkałeś, ponieważ nikt nigdy nie miał tyle sprzętu do przetworzenia tak dużej ilości danych - np. Scala i (do pewnego stopnia GO).

Dobrym językiem jest kompozycyjność lub łączenie tych samych składników na różne sposoby.

Jeśli twój problem z domeną wymaga tylko ustawienia kilku przełączników ortogonalnych, język prawdopodobnie nie dodaje wiele do formularzy, graficznego interfejsu użytkownika lub prostej konfiguracji tekstu. plik. (Zakładam tutaj, że plik pełen par klucz-para nie jest tym, co rozumiesz przez „język”).

OTOH, jeśli twoja konfiguracja jest jak prawdziwy język, np. czasowniki i rzeczowniki można łączyć w wiele różnych (i nowatorskich) kombinacji o dowolnym stopniu złożoności, wtedy język stanie się prawie nieunikniony, ponieważ kombinatoryczna eksplozja próby określenia tego, czego chcesz za pomocą dowolnej innej metody, przytłacza.

Poza ćwiczeniami edukacyjnymi rozsądne jest stworzenie własnego języka programowania tylko wtedy, gdy rozumiesz inne języki, swoją dziedzinę problemową oraz sposób, w jaki istniejące języki rozwiązują tę problematyczną dziedzinę, a zrozumienie jest na tyle dokładne, że wiesz, że nowy język jest rozsądny rozwiązanie bez konieczności zadawania pytania.

Ostatnim razem, gdy postanowiłem to zrobić w projekcie hobby, zacząłem określać, jak ma wyglądać składnia, i zdałem sobie z tego sprawę w połowie, odkrywając prolog. Inne języki, które mogą być dobre, gdy myślisz, że musisz wymyślić język, to seplenienie, lua lub coś w rodzaju Haskell. Zasadniczo wszystkie te języki, które zignorowałeś na studiach, ponieważ myślałeś, że nigdy nie będą przydatne.

Jednym z powodów są cele edukacyjne, jak już wspomniano. Ale jest więcej. Na przykład, istnieje wiele języków badawcze takie jak Sing#na Singularity systemie operacyjnym i BitCna Coyotos , które zostały zaprojektowane, ponieważ istniejące języki nie oferują wymagane funkcje (na przykład weryfikacji na poziomie językowym).

Tom Van Cutsem napisał ostatnio esejową odpowiedź na to pytanie:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Podsumowanie punktorów (z tej strony):

• Język jako mechanizm abstrakcji składniowej: w celu zmniejszenia liczby powtarzających się „szablonów” kodu, których nie można wyodrębnić za pomocą wbudowanych mechanizmów abstrakcji w innym języku.
• Język jako „shaper myślowy”: w celu wywołania zmiany paradygmatu w sposobie tworzenia oprogramowania (zmiana „ścieżki najmniejszego oporu”).
• Język jako uproszczenie: sprowadzenie istniejącego paradygmatu do jego podstawowych części, często w celu zwiększenia zrozumienia i wglądu.
• Język jako organ ścigania: egzekwowanie ważnych właściwości lub niezmienników, być może w celu ułatwienia wnioskowania o bardziej użytecznych właściwościach z programów.

Prawdopodobnie nigdy.

Lua jest najlepszym wyborem, jaki możesz uzyskać, jeśli chcesz osadzić język w zasadzie w jakimkolwiek innym języku.

Języki specyficzne dla małych domen są obecnie dostępne i ma to sens w niektórych aplikacjach.

Poza tym powody są głównie akademickie.

Tworzenie języka, gdy nie jest potrzebny, jest naprawdę złym posunięciem ze względu na złożoność związaną z jego rozwijaniem i utrzymywaniem. Widziałem wiele projektów, które wprowadzają jakiś język skryptowy specyficzny tylko dla tego programu, i to było to, co znacznie spowalniało rozwój podstawowej wersji. Dobrym przykładem są na przykład języki automatyzacji, takie jak Phantom, AutoHotKey, AutoIt. Te narzędzia byłyby IMO znacznie lepsze, gdyby użyły dobrze znanego emanującego języka, takiego jak Lua.

Twoja „edycja” wydaje się być zupełnie innym pytaniem („kiedy powinienem zbudować DSL?” Niż pierwotnym pytaniem, które ludzie rozumieli jako „kiedy powinienem zbudować nowy język programowania ogólnego przeznaczenia”). Wygląda na to, że ludzie dokładnie odpowiedzieli na „oryginalne” pytanie, ale istnieje niewiele odpowiedzi określających konkretne kryteria, kiedy należy korzystać z DSL. Proponuję więc listę kontrolną:

1. Baza użytkowników jest większa niż kilka osób, ogólnie nietechnicznych i / lub z ograniczonym dostępem do systemu (dlatego nie można oczekiwać, że nauczą się / będą używać istniejącego języka ogólnego przeznaczenia). Jeśli należy do twojego zespołu programistów lub organizacji oprogramowania, możesz zamiast tego powiedzieć „po prostu napisz skrypt”.
2. Użytkownicy muszą z niego korzystać wystarczająco często, przy zachowaniu odpowiednio zróżnicowanych i zmieniających się zachowań (tj. Nie można po prostu zapewnić stałej biblioteki obsługiwanych przez Ciebie funkcji)
3. Zachowanie, które użytkownicy mogą określić, jest zbyt skomplikowane, aby można je było określić jako dane (np. Nie można tego osiągnąć przy użyciu tabeli bazy danych, matrycy wprowadzania danych przez użytkownika, listy zadań lub zbioru klucz-wartość ... pomyśl dokładnie ponieważ dzięki nim można osiągnąć dużo złożoności). Jeśli możesz osiągnąć takie zachowanie za pomocą wprowadzania danych lub konfiguracji zamiast DSL, prawdopodobnie powinieneś to zrobić, ponieważ będzie to znacznie mniej pracy. Pewna warunkowość, kompozycyjność / łączenie w łańcuchy lub modelowanie kilku różnych abstrakcji może być oznaką, że zachowanie, którego potrzebujesz, jest zbyt złożone dla zwykłych danych / konfiguracji
4. Ale zachowanie jest nadal na tyle ograniczone, że można je określić w zwięzłej liście DSL. Dużym zagrożeniem jest „wzdęcie platformy”, np. Gdy użytkownicy zaczną pytać „czy możesz po prostu dodać ...?”. Jeśli muszą połączyć się z Internetem, czytać i zapisywać z systemu plików lub otwierać i zamykać procesy - to nie jest już DSL. (Widziałem, jak to się dzieje dla prawdziwych ... użytkowników, którzy mogą osadzać małe wywołania w języku Python, stopniowo przechodząc do skryptów Python i ostatecznie niszcząc wszelkie ograniczenia / modułowość / wydajność)

Jeśli wszystkie są prawdziwe, DSL może być odpowiedni.

Czy istnieją rodzaje zabójczych aplikacji, klasy problemów algorytmicznych itp., Gdzie na dłuższą metę lepiej jest stworzyć własny język?

To zależy.

Weźmy nasz mózg. Wydaje się, że jest to tak skomplikowany bałagan, że napotykamy granice DOWOLNEGO języka programowania (przynajmniej teraz). Być może więc, aby faktycznie zwirtualizować nasz mózg, potrzebujemy innych podejść, a także innych semantyki i składni.

Ogólnie rzecz biorąc, istnieją jeszcze tak złożone tematy, które mogą prowadzić do innych strategii, które obejmowałyby również „lepszy” język dla danego scenariusza.