Наблюдаемость языка программирования на первом месте

Перевод статьи Rambles around computer science | Автор: Stephen Kell (спасибо!)

На прошлой неделе у меня был увлекательный разговор с Mark Shinwell and Stephen Dolan, двумя коллегами, которые знают OCaml наизнанку. Мы говорили о том, как сделать код OCaml наблюдаемым: что позволяет ему поддерживать интерактивную отладку и различные другие динамические анализы (в частности, профилирование памяти).

Оказывается, что, хотя это не невозможно, но очень трудно. Справедливо сказать, что Caml не был разработан с оглядкой на наблюдаемость. Это далеко не уникальный случай: ML-языки, как правило, не реализуют наблюдаемость. На самом деле, можно утверждать, что OCaml явно предназначен для ненаблюдаемости. Ортодоксия постановила, что помеченное хранение было наивной техникой реализации и стирания меток во время выполнения, так как это позволило получить скромный прирост производительности. Кроме того, это означало, что теги стали считаться ценным математическим результатом – для языковых конструкций в целом и, в частности, для ML. Побочный эффект заключается в том, что это стирание также удаляет способность декодировать данные программы напрямую из кодирования в памяти. При отсутствии какого-либо другого механизма, который OCaml в настоящее время не имеет в наличии – это сильно подрывает наблюдаемость.

ML не одинок в этом. Хотя я не так хорошо знаком, буду держать пари, что Haskell, в GHC, страдает подобным ограничением наблюдаемости - или, что еще хуже, это делает более обширные преобразования во время компиляции, и они не могут быть легко "видеться" во время выполнения. Это затрудняет объяснение состояние исполнителя программы во время выполнения, в терминах исходного кода. Кроме того, я не выделяю функциональные языки. Java имеет серьезные недостатки в механизмах, подверженных наблюдаемости виртуальной машины.С, как обычно, – интересный случай. На первый взгляд, язык, кажется, не предназначен для наблюдаемости. Он, конечно, не создает много метаданные при выполнении. Это упущение может рассматриваться как в ML стирание неявных тегов. Тем не менее, это не точное представление. Прагматические программисты, вроде Ричи и Томпсона, хорошо знают значение интерактивной отладки. Первое издание Unix включало db, интерактивный отладчик уровня сборки в основном используется на coredumps. К восьмому изданию оба отладчика, adb и sdb, были задокументированы в разделе 1 настоящего руководства, в последнем, поддерживающем отладки исходного уровня, в то время как третий отладчик (pi; построен на PROCFS Киллиана) имел в комплекте дополнительные услуги, которые становятся Планом 9 . Более современные отладчики (более или менее!) с более продвинутой оптимизацией компилятора, используют сложные форматы метаданных. В результате, С-код был лучше наблюдаем.

Совместная эволюция тоже интересна. Механизмы достижения наблюдаемости в C коде лежат вне языка. Дампы ядра и таблицы символов – механизмы системы, а не механизмы языка. Наблюдаемость в Unix была частью дизайна. Упрямый разработчик системы (хорошо, я буду идти на шаг вперед) может утверждать, что наблюдаемость слишком важна, чтобы оставить составителей языка. Есть, однако, некоторые пробелы подключить и преодолеть умонастроения для того, чтобы применить отладку инфраструктуры Unix-стиля в ML-подобных языках.