Итак, IDE как-бы становится нечего делать. Ан нет, есть что! Уже существуют разного рода верификаторы и аудиторы программ. Они проверяют её на нетривиальные ошибки - анализируя в целом. Конечно, запустить её, она весь проект компилирует, а потом анализирует, да ещё и делает достаточно сложный анализ - это от 5 минут на небольшом проекте до нескольких часов на приличного размера проекте. Что же мы имеем храня программу в виде дерева? Мы имеем возможность проводить именно этот, сложный, нетривиальный анализ всей программы в целом - и проводить его в реал-тайме. Немедленно. То есть, предположим, анализ уже проведён. Мы знаем о программе всё, в том числе и что от чего зависит. Теперь мы поменяли какой-то узел. Скажем, раньше был метод foo() { return ""; }, а стал foo() { return null; }. Мы поменяли узел "return" и сразу видим - возвращается null, а раньше был не-null. Мы знаем все места, где этот метод используется - и можем быстро (в фоне) проверить эти узлы - не выскочит ли там NullPointerException? Это достаточно примитивный пример, только для демонстрации потенциальных возможностей.
Реально обретут силу, скажем такие технологии, как call by contract - потому как большинство условий контракта (constraints на входящие и выходящие значения) можно будет проверить на стадии компиляции. Можно будет создавать средства для более полного описания программы с последующей их верификацией. То есть вместо комментария "здесь у нас в начале исполнения программы это поле может быть нулём, а после того как мы перейдём к такой-то стадии исполнения - это поле нулём быть уже не должно" - можно будет создавать средства, которые это смогут формально описать и затем в фоне и реалтайме плагин аудита проверит - выполняется ли это условие.
Мне кажется, именно это "усиление" программистских мозгов - именно оно и даст в перспективе наибольший эффект. Безусловно, подобного рода средства анализа создавать будет не просто, и не быстро. Ближайшее улучшение программисткой жизни мы получим от синтаксической свободы. Но в более отдалённом будущем - именно это даст бОльшие возможности для создания более сложных программ, для удешевления их разработки и сопровождения.
Инкрементные анализы и компиляция - это, конечно, очень важное преимущество для больших проектов, но, опять-таки, совсем не все анализы (в том числе и потоков данных, который вы используете выше для проверки на null) легко переформулировать в инкрементной форме.
Реально обретут силу, скажем такие технологии, как call by contract - потому как большинство условий контракта (constraints на входящие и выходящие значения) можно будет проверить на стадии компиляции. Можно будет создавать средства для более полного описания программы с последующей их верификацией. То есть вместо комментария "здесь у нас в начале исполнения программы это поле может быть нулём, а после того как мы перейдём к такой-то стадии исполнения - это поле нулём быть уже не должно" - можно будет создавать средства, которые это смогут формально описать и затем в фоне и реалтайме плагин аудита проверит - выполняется ли это условие.
Мне кажется, именно это "усиление" программистских мозгов - именно оно и даст в перспективе наибольший эффект. Безусловно, подобного рода средства анализа создавать будет не просто, и не быстро. Ближайшее улучшение программисткой жизни мы получим от синтаксической свободы. Но в более отдалённом будущем - именно это даст бОльшие возможности для создания более сложных программ, для удешевления их разработки и сопровождения.
Reply
Reply
Leave a comment