> Вот насчёт "Существуют задачи, решение которых существенно упрощается при таком подходе.
> Например, это задачи символьного исчисления, программирования AI" - можно подробнее? Это,
> собственно, то, о чём я спрашивал - есть ли реальные применения,
> где прототипы таки дают хороший выигрыш?Ну, тут весь вопрос, выигрыш в чём именно Вас интересует. В производительности - обычно нет. В выразительной силе и возможностях - да. Именно благодаря возможности генерировать код в рантайме появились возможность символьных вычислений и CLOS. Макросы чтения и записи, как логичное развитие этой идеи.
Вообще говоря, порождение объекта как прототипа и генерация кода на лету - явления родственные. Поэтому я мог бы предложить Вам как пример, для начала, смотреть на Maxima, где эти возможности, должно быть, очень широко используются.
Если же Вас интересует именно вопрос прототипирования объектов, то я видел применение данного подхода в ДОЗОР СМАП [1]. Там при анализе сообщений объекты новых типов с произвольным набором полей, порождаются на лету. Довольно увлекательное зрелище. К сожалению, продукт закрытый, но вообще говоря, в проекте используется много GPL-лицензированного кода, так что при желании можно извернуться и получить исходники. Надеюсь.
[1] http://solarsecurity.ru/products/solar_dozor/
>> Область применения порождает пользователей языка, а пользователи - требования к нему.
> Именно. И, соответственно, требования диктуются именно областью применения. А под неё уже
> подбираются программисты, желающие и способные в ней работать. Если у нас
> большая объектная модель (допустим, тот же гуглодок) - то нужно что-то,
> что даст возможность эту объектную модель реализовать с вменяемой эффективностью -
> в смысле стоимости разработки и поддержки, и чтобы на выходе было
> что-то, чем можно пользоваться.
Чтобы на выходе было что-то, чем можно пользоваться, всегда можно нанять стайку мартышек. И средства реализации большой объектной модели - это вовсе не то, на чём она зиждится. Чтобы построить хороший большой программный комплекс нужны не программисты - это дело десятое. Прежде всего нужен архитектор. Грамотный, скурпулёзный, и желательно - один.
> И именно область применения поменялась, объёмы кода выросли, появилась необходимость в
> такой же поддержке, как и для "взрослых" приложений. И все требования,
> отсюда вытекающие.
Я пока что отношусь к JS, как к языку для модификации DOM-а в моём браузере. Впрочем, может Вы и правы? Транслируют же в JS всякие странные вещи, типа игры Quake. Возможно, он способен на большее.
> Ладно, я, кажется, погорячился с предсказанием - в свете сегодняшней новости скорее
> JS через пару лет в основном уйдёт из веба.
Это вряд ли. Очень много кода написано. Не выбросят же его. Так и потянется легаси через десятилетия.
