Przydzielono mi zadanie wdrożenia języka specyficznego dla domeny dla narzędzia, które może stać się dość ważne dla firmy. Język jest prosty, ale nie trywialny, pozwala już na zagnieżdżanie pętli, łączenie łańcuchów itp. I jest praktycznie pewne, że wraz z postępem projektu zostaną dodane inne konstrukcje.
Wiem z doświadczenia, że ręczne pisanie leksyk / parsera - chyba że gramatyka jest trywialna - jest procesem czasochłonnym i podatnym na błędy. Zostały mi więc dwie opcje: generator parsera à la yacc lub biblioteka kombinatora, taka jak Parsec. Ten pierwszy był również dobry, ale wybrałem ten drugi z różnych powodów i zaimplementowałem rozwiązanie w funkcjonalnym języku.
Rezultat jest dla mnie dość spektakularny, kod jest bardzo zwięzły, elegancki i czytelny / płynny. Przyznaję, że może to wyglądać nieco dziwnie, jeśli nigdy nie programowałeś w niczym innym niż java / c #, ale to byłoby prawdą w przypadku wszystkiego, co nie jest napisane w java / c #.
W pewnym momencie jednak dosłownie zostałem zaatakowany przez współpracownika. Po szybkim spojrzeniu na mój ekran oświadczył, że kod jest niezrozumiały i że nie powinienem na nowo wymieniać parsowania, ale po prostu użyć stosu i String.Split, jak wszyscy. Zrobił dużo hałasu i nie mogłem go przekonać, częściowo dlatego, że byłem zaskoczony i nie miałem jasnego wyjaśnienia, częściowo dlatego, że jego opinia była niezmienna (nie zamierzano grać słów). Zaproponowałem nawet, że wytłumaczę mu język, ale bezskutecznie.
Jestem pewien, że dyskusja pojawi się ponownie przed zarządem, dlatego przygotowuję solidne argumenty.
Oto kilka pierwszych powodów, dla których przychodzi mi na myśl, aby uniknąć rozwiązania opartego na String.Split:
- potrzebujesz wielu ifs do obsługi specjalnych przypadków, a rzeczy szybko wymykają się spod kontroli
- wiele zakodowanych indeksów tablic sprawia, że konserwacja jest bolesna
- niezwykle trudne do obsługi rzeczy takich jak wywołanie funkcji jako argument metody (np. add ((add a, b), c)
- bardzo trudno podać znaczące komunikaty o błędach w przypadku błędów składniowych (bardzo prawdopodobne, że tak się stanie)
- Jestem za prostotą, klarownością i unikaniem niepotrzebnych inteligentnych, tajemniczych rzeczy, ale uważam również, że błędem jest ogłuszanie każdej części bazy kodu, aby nawet łopatka burgera mogła to zrozumieć. To ten sam argument, który słyszę za nieużywaniu interfejsów, nieprzystosowywaniu separacji problemów, kopiowaniu i wklejaniu kodu itp. W końcu do pracy nad projektem oprogramowania wymagane są minimalne kompetencje techniczne i chęć do nauki. (Nie użyję tego argumentu, ponieważ prawdopodobnie zabrzmi to ofensywnie, a rozpoczęcie wojny nikomu nie pomoże)
Jakie są twoje ulubione argumenty przeciwko parsowaniu po Cthulhu ? *
* oczywiście, jeśli zdołasz mnie przekonać, że ma rację, również będę całkowicie szczęśliwy