Требуется меньше проверок/менее тщательного анализа кода для обеспечения обратной связи с ошибками среды разработки и автоматического завершения для языков программирования, которые состоят в основном из человекочитаемых фраз и слов (т. Е. Python, VB.NET)? Это отличается от языков C-стиля, которые в большей степени зависят от символов и знаков препинания для структуры кода.Сложность обнаружения ошибок IDE и автозавершения зависит от синтаксиса языка?
У меня есть опыт/ответственность за строительство dozens of language front ends.
Словосочетание языков и языков пунктуации, как правило, одинаково сложно анализировать и статически анализировать.
Люди, которые определяют языки любого вида, либо украшали их на протяжении десятилетий (например, COBOL с 1958 года), либо строят сложные языки (C++, Scala, Ruby) с комплексным синтаксисом и сложным разрешением имен и типом вывода ; поставщики компилятора затем приступают к добавлению неясного синтаксиса для поддержки странных вещей, которые они выполняют, или для обеспечения блокировки клиента (например, MS «управляемый C++», объявления DLL и т. д.). Есть третья проблема паршивых определений; на верхних языках могут быть четкие правила о том, как они работают, но многие языки имеют неаккуратные определения (например, PHP), которые создают темные угловые случаи, которые должны быть устранены болезненным экспериментированием с фактической реализацией.
C++ был нашим худшим, особенно. с комитетом C++ 11, создающим массовый недавний беспорядок вещей. У нас есть полные анализаторы C++, но они все еще работают над полным разрешением имени для C++ 11 поверх нашей реализации на C++ 98. (Код разрешения имен составляет около 250 000 строк кода и его недостаточно!).
IBM COBOL - вторая секунда; язык просто гигантский, и существуют всевозможные смешные правила разрешения имен («неквалифицированное имя может ссылаться на конкретное имя без квалификации, если ссылка однозначна». Итак, это имя является однозначной ссылкой в этом контексте?).
После того, как вы пройдете синтаксический анализ и разрешаете имя/тип, вы попадаете в поток управления, поток данных, анализ точек, диапазон anlaysis, построение графика вызовов, ... которые обычно имеют одинаковую сумму усилий, более ранние этапы; мы избегаем меньше, имея действительно хорошие библиотеки, которые поддерживают эти задачи.
Со всем этим в качестве фонового анализа вы можете начать делать «статический анализ» умного вида, которого хотят люди.
Другой плакат отметил, что восстановление после синтаксических ошибок и (выделение) «продолжают генерировать значимые сообщения об ошибках». Все, что я могу сказать, это «Аминь, брат». См. Этот ответ SO https://stackoverflow.com/a/6657974/120163 для обсуждения того, что пойдет не так, когда у вас есть «частичные программы», что по сути является тем, что вы получаете, когда исправление ошибок синтаксиса угадывает исправление.
Это тот ответ, который я искал. Все, что я могу сказать, это благодарность за то, что вы делаете, это звучит очень сложно. –
Хороший комплимент, спасибо. Есть дни, когда я просматриваю этот конкретный выбор карьеры: -} –
Прежде чем определить «проще», которого вы избегаете, определите «подробные» и «краткие». – jason
@ Закрыть Голосовавшие: Этот вопрос не о том, лучше ли VB thatn C#. – GSerg
Мое предположение было бы, дело не в многословии; скорее, речь идет о том, что в C# разрешено больше вещей, и поэтому у парсера есть больше способов интерпретации строки кода. – GSerg