Почти все традиционные языки сегодня представляют собой намерение программистов как источника текста, которое затем (скажем, для простоты) переведено на некоторый байт-код/машинный код и интерпретируется/выполняется VM/CPU.
Был еще один метод, который по какой-то причине не так популярен в эти дни: «заморозить» время выполнения вашей виртуальной машины и выгрузить/сериализовать среду (привязки символов, состояние, код (что бы это ни было)) в изображение, которое вы можете передать, загрузить и выполнить. В результате вы не «пишете» свой код обычным способом, но вы изменяете среду с новыми символами, в то время как в «run-time».
я вижу большие преимущества этого метода:Код как изображение системы (сериализованная среда выполнения) vs Источник (текст)
- питания увеличили РЕПЛ: вы можете вникать код, как вы пишете, частично оценить его, проверить его непосредственно и видеть последствия изменений. Затем откат, если вы перепутались и сделаете это снова, или завершите его в среду. Нет необходимости в длительном цикле компиляции-отладки;
- Некоторые из обычных проблем с динамическими языками (которые невозможно скомпилировать, поскольку компилятор не может рассуждать о средах статически) игнорируются: интерпретатор знает, где находится, и может подставлять ссылки на символы со статическими смещениями и выполнять другие оптимизации;
- В мозгу программиста проще: вы «разгружаете» различную контекстуальную информацию о коде с вашей головы, то есть вам не нужно отслеживать, что ваш код уже сделал для какой-либо структуры переменных/данных или какая переменная содержит то, что : вы видите это прямо перед вашими глазами! Обычным способом (источник записи) программисты добавляют в код новые абстракции или комментарии, чтобы прояснить намерения, но это может (и будет) запутываться.
Вопрос в том, каковы недостатки этого подхода? Есть ли какой-то серьезный недостаток, которого я не вижу? Я знаю, есть некоторые проблемы с ним, то есть:
- пытается строить модульную систему с ней, что не приведет к зависимостям ад или серьезных проблемам сцепления
- вопросов безопасности
- пытается контроль версий такие изображения и разрешить совместную разработку
Но они, ИМХО, разрешимы с хорошим дизайном.
EDIT1: относительно статуса "закрыто, в первую очередь основанное на мнениях". Я описал два существующих подхода, и ясно и очевидно, что один предпочтительнее другого. Независимо от того, являются ли причины этого чисто «основанными на мнениях» или есть необходимость повторного поиска этого, мне неизвестны, но даже если они основаны на мнениях, если кто-то перечислит эти причины для такого заключения, должен, собственно, ответить на мой вопрос.
Что заставляет вас думать, что динамические языки не могут быть скомпилированы?Все существующие в настоящее время готовые к реализации версии ECMAScript/JavaScript, Python, Ruby, PHP, Perl, Clojure, Erlang, Smalltalk, многие схемы, многие CommonLisps, имеют компиляторы. Bot оригинальной Ruby-based, а текущая самообучающаяся реализация CoffeeScript - это чистые статические компиляторы AOT. Первоначальная версия V8 была чистым компилятором, в текущей версии есть несколько совместимых компиляторов, но до сих пор нет переводчиков, ни в коем случае в истории V8 она никогда ничего не интерпретировала. Конечно, Smalltalk обычно компилируется. –
Изучайте язык ядра, первоклассные макросы, первоклассные среды: есть очень глубокая дискуссия по лямбда-конечному об этой теме. – artemonster