Ни о какой безапелляционности в моих высказываниях не может быть и речи!

From:

rsh.livejournal.com

.

From:

Я думал в воскресенье, не запостить ли эту ссылку, но отказался: это пример убогости in-jokes.

From: (Anonymous)

Так я так и не понял:
действительно нельзя написать виртуальную машину для всех языков?

Программист 1

From:

можно, запросто, в два приёма.

. реализуйте машину тьюринга с конечной лентой (что нетрудно сделать).

. напишите компиляторы source->MT для интересующих Вас языков.

hope that helps. :)

From:

Виртуальную - почему нет, но останется неразрешенной проблема с безопасностью, на которой и споткнулись дуфусы (как, кстати, правильно переводится?). Если цель - система команд, в которую компилится все и может с разумными затратами JIT-компилироваться на любом процессоре, то надо брать за основу insn'ы GNU C или другое внутреннее представление современных компиляторов, а не байткоды. Если же цель - "песочница", в которой можно секюрно исполнять посторонний код, то это совсем другая сказка. Попытка же и рыбку съесть, и на [] сесть кончается.... собственно, сам факт того, что попытка предпринимается, свидетельствует о непонимании проблемы.

From:

avva.livejournal.com

Почему нельзя? Можно конечно. Вот, например, у меня одна под рукой есть, Пентиум называется ;)

From:

> Виртуальную - почему нет, но останется неразрешенной проблема с безопасностью

не-дуфусы по всяким университетам этой тематикой активно заняты, кстати. тематика называется proof-carrying code, вроде даже там кто-то чего-то уже добился.

> Если цель - система команд, в которую компилится все и может с разумными затратами JIT-компилироваться на любом процессоре, то надо брать за основу insn'ы GNU C или другое внутреннее представление современных компиляторов, а не байткоды.

факт. даже в .net байткоды определены только для "ментальной совместимости" с Жабой, по-моему, а так можно и без байткодов обойтись. и вообще в Microsoft Research вроде не полные идиёты сидят, они же до этого C-- делали...

From:

>proof-carrying code,

Ну, вы же про дуфусов-то читали. :) Если мы ставим задачу реализовать полностью программируемую машину, то все эти ношения пруфов сводятся к задаче автоматического доказательства финитности исполнения. Значит, мы должны делать не полностью программируемую машину. Нес па?

Выход если и есть, то в поиске новой парадигмы вычислений, не эквивалентной дискретному автомату. А остальное - так, развлечения для дуфусов. :)

Вон, кстати, как раз

ilyavinarsky постил воспроизведение бага в человеческой зрительной подсистеме (http://www.livejournal.com/talkread.bml?journal=ilyavinarsky&itemid=206270): ведь, зараза, любая джава в такой ситуации просто скажет унхандлед эксепшн и пятки остыли, а человеческий wetware - плющится, колбасится, но работает. И глаза отведешь - тут же колбаситься перестает.

>в Microsoft Research вроде не полные идиёты сидят

Вот в этом я как раз не убежден. :)

From:

А какая есть альтернатива байт-кодам? Про-parse-анные деревья? Но тогда JIT-компиляция будет гораздо более медленной, чем это было приемлемо архитекторам .NET-а.

From:

avva.livejournal.com

Категорически не согласен. Это вообще не in-joke. Вот если бы это был анекдот про то, как программист свою жену garbage collector'ом называет, и хочет её перевести на алгоритм mark-n-sweep, тогда да, это была бы типичная убогая in-joke.

From:

У эпилептиков, бывает, активация бага в зрительной системе (напр. периодически мерцающий фонарик) может привести к general protection fault (припадку).

From:

Doofus - лапоть, деревенщина?

From:

В Microsoft Research сидят весьма разные индивидуумы - как талантливейшие ученые, так и полные (по словам одного бывшего сотрудника) cartoon characters. Но я не в той группе работал.

Кстати, технионовский Dan Geiger одно время работал в моей группе в Microsoft Research.

From:

> Но тогда JIT-компиляция будет гораздо более медленной, чем это было приемлемо архитекторам .NET-а

вот это меня изрядно даже забавляет. уж кто-кто а микрософтеры должны бы понимать, на чьей стороне закон Мура. :)

если же серьёзно, то давайте вот рассмотрим проблему внимательно:

. код надо компилировать, что занимает время. байткод компилируется быстро, исходный код несколько медленнее. но по-моему, чем дальше тем разница менее существенна.

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

. исходный код стрёмно передавать по сети. в таком случае его можно закодировать, либо закодировать канал. к тому же исходный код обычно меньше по размеру чем байткод.

From:

Вот (http://caesar.ics.uci.edu/juice/) то, что Вы ищете. Я не был причастен к решению архитекторов .NET-а использовать байткоды, а не деревья, но у него могут быть несколько объяснений - хотя бы то, что байткоды суть tried and tested technology.

From:

> то, что Вы ищете.

забавно, спасибо. (я это ищу? :))

> байткоды суть tried and tested technology

native-compiling Lisp/Smalltalk systems существуют уже пёс знает сколько лет. а код на Лиспе или Смаллтоке -- это же фактически деревья, нет?

(обратите внимание, как забавно выходит. предположим, Вы отвечаете (вполне легитимно, кстати): "нихрена подобного, это не деревья". на это я отвечаю: вот видите, а пользователи вроде на скорость компиляции не очень-то жалуются. когда у меня в споре выходит такое, обычно это означает что я не понял проблемы. чего же я не понял?)

From:

Смоллтока не знаю, а Lisp - деревья, деревья. Я просто всегда думаю об Algol family languages, на котором написано подавляющее большинство существующего кода, и имеющих наибольшую developer mindshare.

From:

> Значит, мы должны делать не полностью программируемую машину. Нес па?

не совсем. (как я понимаю, а я ещё не шибко в этом копался, так что без соли не употребляйте).

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

вот Вам аналогия (точнее, частный случай): Вы всегда можете быть уверены (кроме случаев наличия грубых багов в компиляторе), что скомпилированный Вами C-код не содержит нелегальных инструкций и не будет во время исполнения строить кривые stack-frame'ы. проверять это post-factum, на готовом коде, может быть весьма проблематично (особенно второе свойство), но самому компилятору не составляет особого труда эти свойства обеспечить.

(извините за корявый слог)

From:

голый парсинг, при наличии достаточно регулярной грамматики (LALR, к примеру) -- очень, очень быстрая вещь. интересные фишки начинаются только после этого.

From:

Так я и говорю, что лучше это делать offline.

From:

sova.livejournal.com

it's not a bug, it's a feature

From:

int broken_stack_frame(FILE * socket) { char buf[BUFSIZE]; fscanf(socket, "%s\n", buf); // etc }

From:

Если предыдущий мой пример действительно ошибка, то реализуйте мне, имея одни только прямые stack frame, переключение сопрограмм и обработку исключений. Я уж не говорю про вытесняющую многопоточность.

From: (Anonymous)

Аналогичную шутку я уже встречал.
Некто задался создать _канал_ с огромной пропускной способностью из подручных средств. Решение было таким: загрузить самосвал КДисками без коробочек. У него получались ТераБайты/секунду (он опустил время создания КД и прочее).

PS Для _всех_ языков Пентиум не подходит. Достаточно попробовать перевести (транслятором, частью компилятора) фразу "Naked conductor runs along the bus" любым переводчиком. Например www.translate.ru.

From: (Anonymous)

Перевод с машинного языка на машинный действительно проблем не составляет: существуют всякие flex-ы, которые помогают решить эту задачу.

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

Не говоря уж о безопасности кода...

From:

не должно быть большой проблемой для C-компилятора с проверкой границ и соответствующим образом аннотированной стандартной библиотекой. хотя это уже будет и не совсем C.

(ну и в любом случае: я не претендую на непробиваемость приведённого мною примера, натурально. это только иллюстрация)

From:

> Я уж не говорю про вытесняющую многопоточность

кстати, это принятая русскоязычная терминология? кайф какой. не калькируя обратно на английский, не поймёшь о чём и речь. :)

а только прямые stack frame'ы для этой радости, понятно, недостаточны. ну и что? на языке Ц свет клином не сошёлся.

From:

Вытесняющая - принятая. Многопоточность - раньше говорили многозадачность, но это было в те времена, когда и по англицки процессы назывались задачи, а потоки - процессами. :)

>а только прямые stack frame'ы для этой радости, понятно, недостаточны. ну и что?

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

>на языке Ц свет клином не сошёлся.

Соответственно и создать виртуальную машину, которая имела бы хранимые пруфы и при том была бы достойна схождения на ней клином всего света, невозможно. Я ответил на ваш исходный вопрос?

From:

>C-компилятора с проверкой границ и соответствующим образом аннотированной стандартной библиотекой.

Еще проще:

int broken_stack_frame(char * str) { char buf[BUFSIZE]; strcpy(str, buf); // etc }

>хотя это уже будет и не совсем C.

Это будет совсем не C. В лучшем случае это будет жаба.

Пойнт как раз в том, что непробиваемый пример - это либо система, способная доказывать финитность исполняющихся на ней алгоритмов, либо система, способная исполнять только некоторые алгоритмы. Первое невозможно, второе по построению ограничено в возможностях.

From:

> создать виртуальную машину, которая имела бы хранимые пруфы и при том была бы достойна схождения на ней клином всего света, невозможно. Я ответил на ваш исходный вопрос?

нет, поскольку наши взаимные догадки по поводу терминологии друг друга бьют строго мимо (видимо).

так что давайте перестанем гадать:

. утверждаю ли я, что можно создать "полностью программируемую" архитектуру, правильность любой программы для которой была бы доказуема? если под "полностью программируемой" понимать "под неё можно написать полный C-компилятор", то, натурально, нет, чему-то меня всё-таки в университете научили. если под "полностью программируемой" понимать "достаточно экспрессивная" (пригодная для практичной реализации какого-нибудь доказанно экспрессивного формализма), то да. в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)). ну и, разумеется, мы вынуждены доверять компилятору.

. считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.

From: (Anonymous)

А может
DOOFUS <- DO + (FUSS v FUSE)
?

From:

>"достаточно экспрессивная" (пригодная для практичной реализации какого-нибудь доказанно экспрессивного формализма), то да

Честно говоря, не очень слежу за литературой в этой области - что в данном случае понимается под "экспрессивным формализмом"? (инстинктивно чувствую, что ничего хорошего :)

>в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)).

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

>считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.

На самом деле, проблема тут несколько глубже, чем "достаточная экспрессивность" и С-компилятор. Полностью программируемая - значит, на ней можно реализовать любой конечный автомат с количеством состояний, не превосходящим некоторый объем. Важно и это, и то, чтобы реализация этого автомата была 1. Более умопостижима, чем таблица состояний. 2. Не сильно уступала по скорости "идеальной" реализации того же автомата с одним переходом за такт. Если возможность реализации можно доказать, это хорошо, но треть дела. Остается вопрос умопостижимости предложенного формализма и производительность, которые уже недоказуемы.

Си, даже с учетом своих заморочек - умопостижим и производителен. Жаба попыталась найти компромисс за счет производительности, для многих случаев приемлемый, но в некоторых - обасалютно... (я тут несколько колов времени назад имел счастье трахаться именно с ее гарбаж коллектором при вызове нативных методов. Она меня затрахала). C# страдает тем же самым и по той же самой причине.

Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.

From:

> Честно говоря, не очень слежу за литературой в этой области - что в данном случае понимается под "экспрессивным формализмом"? (инстинктивно чувствую, что ничего хорошего :)

инстинкта хватит.

вот у Вас проблема с Жабой какая? native method медленно зовётся? а нафига Вам этот самый native method? варианты:

. потому что Жабина виртуальная машина органически неспособна выразить нужную функциональность
. потому что выражать нужную функциональность на Жабиной виртуальной машине будет неэффективно
. потому что нужная функциональность уже реализована не на Жабе, и проще позвать её

подозреваю, что здесь мы имеем смесь второго и третьего, не так ли? то есть экспрессивность Жабиной виртуальной машины нас в общем устраивает, за исключением возможно немаловажных, но непринципиальных ограничений. мы ж тут типа академическими пальцами шевелим, да? :)

> Это очень важная деталь, потому что требует автоматической генерации доказательства. Что невозможно.

дык вот вроде бы возможно, хотя пока ещё непрактично.

> Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.

ой, мама. а что такое "интерпретируемый язык"?

From:

>инстинкта хватит.

Инстинкт и доказательство - две вещи несовместные. :)

>вот у Вас проблема с Жабой какая? native method медленно зовётся?

Нет, сложнее. Нативный метод размещает некоторые (весьма дорогостоящие) системные ресурсы, Notes C API handle, если это интересно. Из деструктора объекта эти ресурсы освобождаются. Деструктор не зовется, пока гарбаж коллектор не соизволит найти этот объект, в результате системные ресурсы накапливаются практически неограниченно.

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

>потому что нужная функциональность уже реализована не на Жабе, и проще позвать её

Ну, в данном случае можно сказать и "проще", но переписать Нотуса на Жабе - это, как бы, с одной стороны не более, чем "сложно", но для большинства контекстов это слишком слабое выражение.

>интерпретируемый язык

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

From:

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

ну в общем, представьте что я это красиво и уважительно сказал. спасибо. :)

From:

Будучи практиком, я не могу не думать о прагматике.

Программирование вообще дело такое, что в нем абстракции ценны ровно постольку, поскольку прагматичны. И наоборот. Поэтому в их смешивании греха не вижу. Элемент издевательства присутствует. Фраза про терминологию вообще-то обратима. :) Поэтому не вижу в ваших словах ничего такого уж несправедливого.

From:

Если кого-нибудь это интересует, вот (http://www.research.microsoft.com/vault/) безопасный, но не managed язык - множество корректных программ на нем сильно ограничено по сравнению с C++, т.к. любая программа, использующая класс, содержащий в себе ресурс, например, файл или сокет, должна гарантировать, что он будет использоваться согласно соответствующеему протоколу, т.е. закрытый файл не будет закрываться дважды, или закрываться в крыле then if-оператора, но оставаться открытым в крыле else.

Vault не позволяет ЛАПТЯМ и невинность соблюсти, и капитал приобрести - но он делает это иначе, чем Java, .NET и иже с ними.

From:

Пардон, а почему нельзя иметь метод close, и вызывать его в крыле finally оператора try {...} finally { rsrc.close(); } ?

From: