Передо мной была поставлена задача внедрения предметно-ориентированного языка для инструмента, который может стать весьма важным для компании. Язык простой, но не тривиальный, он уже допускает вложенные циклы, конкатенацию строк и т. Д., И практически уверен, что другие конструкции будут добавлены по мере продвижения проекта.
По своему опыту я знаю, что написание лексера / парсера вручную - если грамматика не тривиальна - это трудоемкий и подверженный ошибкам процесс. Таким образом, у меня остались два варианта: генератор синтаксического анализа а-ля yacc или библиотека комбинаторов, например Parsec. Первое тоже было хорошо, но я выбрал второе по разным причинам и реализовал решение на функциональном языке.
Результат довольно впечатляющий на мой взгляд, код очень лаконичен, элегантен и удобен для чтения. Я допускаю, что это может выглядеть немного странно, если вы никогда не программируете ни на что, кроме java / c #, но тогда это будет верно для всего, что не написано в java / c #.
Однако в какой-то момент я был буквально атакован сотрудником. После быстрого взгляда на мой экран он объявил, что код непонятен и что я не должен заново изобретать синтаксический анализ, а просто использовать стек и String.Split, как это делают все. Он издал много шума, и я не смог его убедить, частично потому, что меня застали врасплох, и у меня не было четких объяснений, частично потому, что его мнение было неизменным (без каламбура). Я даже предложил объяснить ему язык, но безрезультатно.
Я уверен, что дискуссия вновь появится перед руководством, поэтому я готовлю некоторые веские аргументы.
Вот первые несколько причин, которые приходят мне в голову, чтобы избежать решения на основе String.Split:
- вам нужно много ifs для обработки особых случаев и вещей, которые быстро выходят из-под контроля
- много жестко закодированных индексов массивов делает обслуживание болезненным
- чрезвычайно трудно обрабатывать такие вещи, как вызов функции в качестве аргумента метода (например, add ((add a, b), c)
- очень сложно предоставить значимые сообщения об ошибках в случае синтаксических ошибок (очень вероятно, что это произойдет)
- Я все за простоту, ясность и избегая ненужных умных и загадочных вещей, но я также считаю, что ошибкой было бы заглушить каждую часть кодовой базы, чтобы ее мог понять даже флиппер бургера. Это тот же аргумент, который я слышу за то, что не использовал интерфейсы, не принимал разделение задач, не копировал и не вставлял код и т. Д. Для работы над программным проектом в конце концов требуется минимум технических знаний и желания учиться. (Я не буду использовать этот аргумент, поскольку он, вероятно, будет звучать оскорбительно, и начало войны никому не поможет)
Какие твои любимые аргументы против анализа Ктулху ? *
* конечно, если ты сможешь убедить меня, что он прав, я тоже буду совершенно счастлив