Обсуждение

Надо думать по другому. Компилятор - это построение модели объекта. Объект - программа. А интерпретатор - часть модели, и интерпретируемая программа - часть модели. Объект же - из предметной области.

А они неплохо параллельно развиваются. Да и совместные проекты делают - те же JIT'ы. В контексте динамической компиляции не трудно сделать и суперкомпилятор для экстремально позднего связывания - просто генерировать специализированный код в момент связывания или чуть позже. Либо применять хинты/эвристики. Можно и строготипизированные языки адаптировать под экстремально позднее связывание.

Ты путаешь компилятор и суперкомпилятор: компилятор не строит модель программы, он осуществляет эквивалентные преобразования (трансформацию) программы из одного языка в другой. Компилятор на выходе получает ту же самую программу. Суперкомпилятор строит модель, у него на выходе -- другая (совсем!) программа, результаты выполнения которой идентичны исходной. Вот про суперкомпилятор можно говорить, что речь идет о моделировании (а не трансформации текста). А у тебя какое-то нестандартное понимание модели. Интерпретатор у тебя -- часть модели чего?! Текста программы?! А кто тогда запускает модель в работу (исполняет ее)? И этот тип рассуждения еще нужно как-то помечать специально, чтобы не путать с традиционным рассуждением о моделировании в суперкомпиляции, чтобы людей не запутывать.

Я тебе предлагаю взгляд на проблему интерпретации, потому про компиляцию писал просто для сравнения. Интерпретатор - часть модели предметной области. Инфраструктура модели. Ты же спрашивал - как понимать процесс интерпретации как моделирование. Я тебе и ответил. При суперкомпиляции есть два процесса моделирования - моделирование предметной области на языке А и моделирование программы на языке А программой на языке Б. При интерпретации - моделирование есть, но оно идёт в один такт. Кстати, наверняка есть системы, моделирующие далее вполне рабочую модель в интерпретаторе. Я думаю, что дело идёт к тому, что раработка систем будет включать оба этапа. Специалисты в предметной области будут моделировать в режиме интерпретации и суперпозднего свяывания, но потом результаты будут существенно оптимизироваться суперкомпиляторами, просто чтобы получить супербыстрый код для спецпроцессоров каких-нибудь.

Как бы сказать -- суперкомпиляуия своидит сложную программу к несколько более простой. Как-бы упрощает текст. Позднее свзязывание уменьшает сложность текстов за счет перененсения выбора из альтернатив на уровень структуры ыпрограммы. Тексты которые раньше были сложными теперь можно записать проще. Но сложность текстов определяется все таки не задачей а способностями человека генерировать сложные тексты. Которые тоже можно упрощать (если можно как-то зафиксировать контекст времени выполнения). Т. е. актуальность суперкомпиляции с наличием позднего связывания слабо связана. Ну и использование структурного аналища для суперкомпиляции развивается тоже (вместо анализа if-ов аналищируем структуру иерархии), но это немного другая история.

Компиляторы (в том числе и супер) и интерпретаторы - просто имеют принципиально разные области применения. Не надо писать на компилируемых языках то, где нужно сильно позднее связывание (интерфейсы пользователя, мобильные агенты и т.д.), но не надо и писать на интерпретируемых языках реализации криптоалгоритмов.

Это ты воспроизводишь стандартное рассуждение про метамоделирование aka стек (мета)моделей. Не имеет отношения к указываемой мной проблеме различий в типе одной из моделей в стеке. Компиляция-на-лету, а также инкрементальная компиляция тоже давно известны, и они понятно как обходятся с точками суперпозднего связывания (а именно -- их не трогают ;) Суперкомпиляция выгодна тогда, когда на вход подается вся программа (ибо как раз основные оптимизации в суперкомпиляции происходят не с участками программы "от вызова до вызова", а именно в изменении всей структуры). Так что твое замешивание всего стека метамоделей непонятно какое отношение имеет к обсуждаемой проблеме.

сеть заставляют моделировать объект

На Lambda the Ultimate была вчера ссылка на статью про что-то похожее. Правда, саму статью я ещё не прочитал, прочитал только аннотацию. Насколько я понял, идея там такая: у программистов в голове есть интуитивное понятие "алгоритма", который реализует программа. Разные программы могут реализовывать один и тот же алгоритм. ⇒ Алгоритм есть класс эквивалентности программ. И авторы статьи доказывают аргументируют, что ввести такую эквивалентность разумным образом нельзя. Ссылка и обсуждение здесь. (Не путать с проблемой эквивалентности алгоритмов, которая изучена давно и хорошо).

... Жители антиутопии чаще всего счастливы ...

"Позднее связывание" + "компиляция" = "поздняя компиляция". Just in Time, Ahead of Time -- умных слов много. Почему-то на моих задачках Питон, пропущенный через такой вот поздний компилятор, оказывается строго вторым после чистых C и впереди компилируемых Ocaml и C++. Надо будет попробовать криптоалгоритм на нём написать и замерить.

... Ненавижу романтику и электронику ...

В проекте COLA (он же IS из VPRI) как раз ставится задача получения кода не менее быстрого, чем на Си -- но с суперпоздним связыванием. И к этой цели они довольно быстро движутся.

Если ты отдаешь себе отчёт в том, что это разные уровни стека - непонятно, зачем ты изначально поставил "один интересный вопрос" сравнения разных уровней?

А, нет, не отдашь. Ты полагаешь, что суперкомпилируемая программа и инерпретируемая программа - на одном уровне в стеке. Точнее, ты пишешь "моделирования/суперкомпиляции", то есть по факту оставляешь интерпретацию вообще за пределами стека метамоделей.

Я как раз говорю об одном уровне: есть программа на языке X, и ее нужно выполнить на языке Y. Это ты начал вдруг разговаривать о стеке метамоделей (программа -- это модель объекта, интерпретатор -- это часть модели объекта и т.д.). Тут нужно добавить обязательно, что программа в объектном коде [pun intended] -- это тоже модель объекта, но не модель исходной программы, а результат ее трансформации (в случае компиляции). Или модель исходной программы, если речь идет о суперкомпиляции. Так что ты просто про другие проблемы пишешь.

Еще раз: программа пишется на языке X, затем интерпретируется прямо в этом языке X (интерпретатором, работающем на языке Y), или компилируется или суперкомпилируется в язык Y (и тогда текст на языке Y либо результат трансформации текста на языке X, либо его модель соответственно) и затем все одно интерпретируется только на языке Y.

Не бывает такй "нужды", как "ее нужно выполнить на языке Y". Это чисто научная постановка задачи, таких можно много выдумать, и, как тебе указывают в научных целях скрещивать ужа с ежом уж научились в любых пропорциях. Реальные нужды - либо программы нет, и её нужно написать. Либо она есть, и её нужно заставить работать лучше.Вот в контексте этих нужд и надо размышлять о месте компияции и интерпретации.

Ужа с ежом не научились скрещивать -- это про обычную компиляцию. Если вместо обычного компилятора для "на лету компилируемого" кусочка программы вызвать суперкомпилятор, то не стоит ожидать большого эффекта. В обсуждаемой мной предметной области компиляции/суперкомпиляции/интерпретации как раз важны языки. Нет там постановки задачи "написать лучше" (или ты имеешь ввиду оптимизацию кода без смены языка? Речь-то не об этом, хотя в варианте суперкомпилятора такое обсуждение может быть осмысленно -- но при этом все равно нужен анализ подлежащего интерпретатора -- что именно этот интерпретатор может выполнять быстрее из его набора команд...).

Языки выбираются из задач. Сначала специфика предметной области и наличных ресурсов (есть ли эксперт в предметной области), потом выбор языка. Потом специфика использования (куда программу совать) и опять выбор языка. Когда эти шаги пройдены, используемые инструменты уже определены.

Ты что-то странное говоришь. Вот у тебя, например, среда типа COLA, в которой языки задаются "под настроение" -- и там тобой задаваемые вопрос (мухи) обсуждаются отдельно, а вопросы компиляции/интерпретации (котлеты) отдельно. Мой вопрос про то, как в системы типа COLA (она же IS) упихивать суперкомпиляторы так, чтобы от этого был хоть какой-то толк (в силу специфики подхода суперкомпиляции). А ты мне про предметные области, экспертов, уровни метамоделей и прочее. Для меня ты говоришь на совсем-совсем другие темы, приводишь куски осмысленного совсем в другом месте разговора. Я тебе постоянно объясняю про свой конкретный вопрос, а ты мне приводишь абстрактные и отвлеченные рассуждения про программирование вообще... Я начну понимать тебя тогда, когда ты покажешь, как в твоих рассуждениях использование суперкомпилятора по результату будет существенно отличаться от использования простого компилятора. Если в твоих рассуждениях этого не будет, то значит оно не по теме.

Позднее связывание и суперкомпиляторы возникли из разных "нужд". Ты пока не можешь показать реальную нужду "упихивания" их в один уровень системы создания кода. Твой вопрос понятен, но ты не можешь показать, для каких решений ты можешь применить ответ на него.

Ты пишешь: "компиляторы (включая моделирующие суперкомпиляторы) потихоньку проигрывают интерпретирующим структурам" А тебе все отвечают: а они не соревнуются.