Категорически не согласен. Это вообще не in-joke. Вот если бы это был анекдот про то, как программист свою жену garbage collector'ом называет, и хочет её перевести на алгоритм mark-n-sweep, тогда да, это была бы типичная убогая in-joke.
Виртуальную - почему нет, но останется неразрешенной проблема с безопасностью, на которой и споткнулись дуфусы (как, кстати, правильно переводится?). Если цель - система команд, в которую компилится все и может с разумными затратами JIT-компилироваться на любом процессоре, то надо брать за основу insn'ы GNU C или другое внутреннее представление современных компиляторов, а не байткоды. Если же цель - "песочница", в которой можно секюрно исполнять посторонний код, то это совсем другая сказка. Попытка же и рыбку съесть, и на [] сесть кончается.... собственно, сам факт того, что попытка предпринимается, свидетельствует о непонимании проблемы.
> Виртуальную - почему нет, но останется неразрешенной проблема с безопасностью
не-дуфусы по всяким университетам этой тематикой активно заняты, кстати. тематика называется proof-carrying code, вроде даже там кто-то чего-то уже добился.
> Если цель - система команд, в которую компилится все и может с разумными затратами JIT-компилироваться на любом процессоре, то надо брать за основу insn'ы GNU C или другое внутреннее представление современных компиляторов, а не байткоды.
факт. даже в .net байткоды определены только для "ментальной совместимости" с Жабой, по-моему, а так можно и без байткодов обойтись. и вообще в Microsoft Research вроде не полные идиёты сидят, они же до этого C-- делали...
Ну, вы же про дуфусов-то читали. :) Если мы ставим задачу реализовать полностью программируемую машину, то все эти ношения пруфов сводятся к задаче автоматического доказательства финитности исполнения. Значит, мы должны делать не полностью программируемую машину. Нес па?
Выход если и есть, то в поиске новой парадигмы вычислений, не эквивалентной дискретному автомату. А остальное - так, развлечения для дуфусов. :)
Вон, кстати, как раз ilyavinarsky постил воспроизведение бага в человеческой зрительной подсистеме (http://www.livejournal.com/talkread.bml?journal=ilyavinarsky&itemid=206270): ведь, зараза, любая джава в такой ситуации просто скажет унхандлед эксепшн и пятки остыли, а человеческий wetware - плющится, колбасится, но работает. И глаза отведешь - тут же колбаситься перестает.
>в Microsoft Research вроде не полные идиёты сидят
У эпилептиков, бывает, активация бага в зрительной системе (напр. периодически мерцающий фонарик) может привести к general protection fault (припадку).
В Microsoft Research сидят весьма разные индивидуумы - как талантливейшие ученые, так и полные (по словам одного бывшего сотрудника) cartoon characters. Но я не в той группе работал.
Кстати, технионовский Dan Geiger одно время работал в моей группе в Microsoft Research.
> Значит, мы должны делать не полностью программируемую машину. Нес па?
не совсем. (как я понимаю, а я ещё не шибко в этом копался, так что без соли не употребляйте).
там вся фишка в том чтобы генерировать гарантированно "безопасный" код, с приложенным к нему "доказательством". при этом экспрессивность данного кода совершенно не обязана быть чем-то жёстко ограничена.
вот Вам аналогия (точнее, частный случай): Вы всегда можете быть уверены (кроме случаев наличия грубых багов в компиляторе), что скомпилированный Вами C-код не содержит нелегальных инструкций и не будет во время исполнения строить кривые stack-frame'ы. проверять это post-factum, на готовом коде, может быть весьма проблематично (особенно второе свойство), но самому компилятору не составляет особого труда эти свойства обеспечить.
не должно быть большой проблемой для C-компилятора с проверкой границ и соответствующим образом аннотированной стандартной библиотекой. хотя это уже будет и не совсем C.
(ну и в любом случае: я не претендую на непробиваемость приведённого мною примера, натурально. это только иллюстрация)
Это будет совсем не C. В лучшем случае это будет жаба.
Пойнт как раз в том, что непробиваемый пример - это либо система, способная доказывать финитность исполняющихся на ней алгоритмов, либо система, способная исполнять только некоторые алгоритмы. Первое невозможно, второе по построению ограничено в возможностях.
Если предыдущий мой пример действительно ошибка, то реализуйте мне, имея одни только прямые stack frame, переключение сопрограмм и обработку исключений. Я уж не говорю про вытесняющую многопоточность.
Вытесняющая - принятая. Многопоточность - раньше говорили многозадачность, но это было в те времена, когда и по англицки процессы назывались задачи, а потоки - процессами. :)
>а только прямые stack frame'ы для этой радости, понятно, недостаточны. ну и что?
Ну и то, что возвращаемся к моему исходному тезису: если мы делаем машину не полностью программируемой, она оказывается недостаточной для каких-то целей. Собственно, это и есть определение "неполной программируемости". А если машина полностью программируема, то "правильность" (что бы под этим ни подразумевалось) написанной на ней программы недоказуема. Во всяком случае, автоматически. Вот и приехали.
>на языке Ц свет клином не сошёлся.
Соответственно и создать виртуальную машину, которая имела бы хранимые пруфы и при том была бы достойна схождения на ней клином всего света, невозможно. Я ответил на ваш исходный вопрос?
> создать виртуальную машину, которая имела бы хранимые пруфы и при том была бы достойна схождения на ней клином всего света, невозможно. Я ответил на ваш исходный вопрос?
нет, поскольку наши взаимные догадки по поводу терминологии друг друга бьют строго мимо (видимо).
так что давайте перестанем гадать:
. утверждаю ли я, что можно создать "полностью программируемую" архитектуру, правильность любой программы для которой была бы доказуема? если под "полностью программируемой" понимать "под неё можно написать полный C-компилятор", то, натурально, нет, чему-то меня всё-таки в университете научили. если под "полностью программируемой" понимать "достаточно экспрессивная" (пригодная для практичной реализации какого-нибудь доказанно экспрессивного формализма), то да. в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)). ну и, разумеется, мы вынуждены доверять компилятору.
. считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.
>"достаточно экспрессивная" (пригодная для практичной реализации какого-нибудь доказанно экспрессивного формализма), то да
Честно говоря, не очень слежу за литературой в этой области - что в данном случае понимается под "экспрессивным формализмом"? (инстинктивно чувствую, что ничего хорошего :)
>в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)).
Это очень важная деталь, потому что требует автоматической генерации доказательства. Что невозможно. :) (подход, когда доказательство корректности должен проводить программист, я отбрасываю из-за очевидной непрактичности)
>считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.
На самом деле, проблема тут несколько глубже, чем "достаточная экспрессивность" и С-компилятор. Полностью программируемая - значит, на ней можно реализовать любой конечный автомат с количеством состояний, не превосходящим некоторый объем. Важно и это, и то, чтобы реализация этого автомата была 1. Более умопостижима, чем таблица состояний. 2. Не сильно уступала по скорости "идеальной" реализации того же автомата с одним переходом за такт. Если возможность реализации можно доказать, это хорошо, но треть дела. Остается вопрос умопостижимости предложенного формализма и производительность, которые уже недоказуемы.
Си, даже с учетом своих заморочек - умопостижим и производителен. Жаба попыталась найти компромисс за счет производительности, для многих случаев приемлемый, но в некоторых - обасалютно... (я тут несколько колов времени назад имел счастье трахаться именно с ее гарбаж коллектором при вызове нативных методов. Она меня затрахала). C# страдает тем же самым и по той же самой причине.
Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.
> Честно говоря, не очень слежу за литературой в этой области - что в данном случае понимается под "экспрессивным формализмом"? (инстинктивно чувствую, что ничего хорошего :)
инстинкта хватит.
вот у Вас проблема с Жабой какая? native method медленно зовётся? а нафига Вам этот самый native method? варианты:
. потому что Жабина виртуальная машина органически неспособна выразить нужную функциональность . потому что выражать нужную функциональность на Жабиной виртуальной машине будет неэффективно . потому что нужная функциональность уже реализована не на Жабе, и проще позвать её
подозреваю, что здесь мы имеем смесь второго и третьего, не так ли? то есть экспрессивность Жабиной виртуальной машины нас в общем устраивает, за исключением возможно немаловажных, но непринципиальных ограничений. мы ж тут типа академическими пальцами шевелим, да? :)
> Это очень важная деталь, потому что требует автоматической генерации доказательства. Что невозможно.
дык вот вроде бы возможно, хотя пока ещё непрактично.
> Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.
Инстинкт и доказательство - две вещи несовместные. :)
>вот у Вас проблема с Жабой какая? native method медленно зовётся?
Нет, сложнее. Нативный метод размещает некоторые (весьма дорогостоящие) системные ресурсы, Notes C API handle, если это интересно. Из деструктора объекта эти ресурсы освобождаются. Деструктор не зовется, пока гарбаж коллектор не соизволит найти этот объект, в результате системные ресурсы накапливаются практически неограниченно.
Проблема именно в "экспрессивности", в самой семантике жабной виртуальной машины, а именно в том, что интервал от освобождения объекта (выхода из области видимости последней ссылки на) до вызова деструктора велик, зачастую недопустимо велик, а все средства его сокращения - палка об двух, а то и более концах.
>потому что нужная функциональность уже реализована не на Жабе, и проще позвать её
Ну, в данном случае можно сказать и "проще", но переписать Нотуса на Жабе - это, как бы, с одной стороны не более, чем "сложно", но для большинства контекстов это слишком слабое выражение.
>интерпретируемый язык
Который рассчитан на исполнение "виртуальной машиной", а не пентиумом. :) Согласитесь, что хотя можно и си в байткоды компилировать, но этого почему-то никто не делает. :) То есть классификация "инстинктивная", но в крайних случаях (как С и PHP) бесспорная. Наличие гарбаж коллектора - сильный довод в пользу отнесения языка к интерпретируемым.
есть ли какой-то способ красиво и уважительно сказать "у Вас полная катастрофа с терминологией, Вы смешиваете в Ваших рассуждениях прагматику с абстракциями, не исключено также что Вы просто издеваетесь. короче Вы неправы но я элементарно устал спорить."?
ну в общем, представьте что я это красиво и уважительно сказал. спасибо. :)
Будучи практиком, я не могу не думать о прагматике.
Программирование вообще дело такое, что в нем абстракции ценны ровно постольку, поскольку прагматичны. И наоборот. Поэтому в их смешивании греха не вижу. Элемент издевательства присутствует. Фраза про терминологию вообще-то обратима. :) Поэтому не вижу в ваших словах ничего такого уж несправедливого.
В итоге к этому и пришли. Только... как бы это сказать помягче... если делать это по грамотному, то надо ведь после такого делать все методы объекта throwing ObjectIsClosed, правильно - а то мы сделаем close, а потом кто-нибудь метод возьмет и позовет? Ведь если деструктор не отработал, значит кто-то может держать на нас живую ссылку, правильно? Проблема висячих ссылок, только в профиль. И спрашивается, ради чего тогда мы выдумывали деструкторы и сборщик мусора?
А какая есть альтернатива байт-кодам? Про-parse-анные деревья? Но тогда JIT-компиляция будет гораздо более медленной, чем это было приемлемо архитекторам .NET-а.
> Но тогда JIT-компиляция будет гораздо более медленной, чем это было приемлемо архитекторам .NET-а
вот это меня изрядно даже забавляет. уж кто-кто а микрософтеры должны бы понимать, на чьей стороне закон Мура. :)
если же серьёзно, то давайте вот рассмотрим проблему внимательно:
. код надо компилировать, что занимает время. байткод компилируется быстро, исходный код несколько медленнее. но по-моему, чем дальше тем разница менее существенна.
. код должен быстро бегать. понятно, что исходный код можно соптимизировать лучше.
. исходный код стрёмно передавать по сети. в таком случае его можно закодировать, либо закодировать канал. к тому же исходный код обычно меньше по размеру чем байткод.
Вот (http://caesar.ics.uci.edu/juice/) то, что Вы ищете. Я не был причастен к решению архитекторов .NET-а использовать байткоды, а не деревья, но у него могут быть несколько объяснений - хотя бы то, что байткоды суть tried and tested technology.
native-compiling Lisp/Smalltalk systems существуют уже пёс знает сколько лет. а код на Лиспе или Смаллтоке -- это же фактически деревья, нет?
(обратите внимание, как забавно выходит. предположим, Вы отвечаете (вполне легитимно, кстати): "нихрена подобного, это не деревья". на это я отвечаю: вот видите, а пользователи вроде на скорость компиляции не очень-то жалуются. когда у меня в споре выходит такое, обычно это означает что я не понял проблемы. чего же я не понял?)
Смоллтока не знаю, а Lisp - деревья, деревья. Я просто всегда думаю об Algol family languages, на котором написано подавляющее большинство существующего кода, и имеющих наибольшую developer mindshare.
голый парсинг, при наличии достаточно регулярной грамматики (LALR, к примеру) -- очень, очень быстрая вещь. интересные фишки начинаются только после этого.
Перевод с машинного языка на машинный действительно проблем не составляет: существуют всякие flex-ы, которые помогают решить эту задачу.
Но вот вопрос о самоидентификации кода (чтобы код служил подписью к себе) напоминает задачу о программе, пишущей самою себя. Не в том смысле, как её обычно решают, а в смысле эволюции. Лучшее, что известно из этой области -- всякие Компьютерные Войны, черви и вирусы. Пока процесс без участия человека не идёт.
Аналогичную шутку я уже встречал. Некто задался создать _канал_ с огромной пропускной способностью из подручных средств. Решение было таким: загрузить самосвал КДисками без коробочек. У него получались ТераБайты/секунду (он опустил время создания КД и прочее).
PS Для _всех_ языков Пентиум не подходит. Достаточно попробовать перевести (транслятором, частью компилятора) фразу "Naked conductor runs along the bus" любым переводчиком. Например www.translate.ru.
Если кого-нибудь это интересует, вот (http://www.research.microsoft.com/vault/) безопасный, но не managed язык - множество корректных программ на нем сильно ограничено по сравнению с C++, т.к. любая программа, использующая класс, содержащий в себе ресурс, например, файл или сокет, должна гарантировать, что он будет использоваться согласно соответствующеему протоколу, т.е. закрытый файл не будет закрываться дважды, или закрываться в крыле then if-оператора, но оставаться открытым в крыле else.
Vault не позволяет ЛАПТЯМ и невинность соблюсти, и капитал приобрести - но он делает это иначе, чем Java, .NET и иже с ними.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
Вау!!!!!
Brilliant!
no subject
Date: 2002-06-17 06:26 am (UTC)Re:
Date: 2002-06-17 08:04 am (UTC)sawa;)
Date: 2002-06-17 06:28 am (UTC)действительно нельзя написать виртуальную машину для всех языков?
Программист 1
Re: sawa;)
Date: 2002-06-17 06:32 am (UTC). реализуйте машину тьюринга с конечной лентой (что нетрудно сделать).
. напишите компиляторы source->MT для интересующих Вас языков.
hope that helps. :)
Re: sawa;)
Re: sawa;)
Date: 2002-06-17 06:57 am (UTC)не-дуфусы по всяким университетам этой тематикой активно заняты, кстати. тематика называется proof-carrying code, вроде даже там кто-то чего-то уже добился.
> Если цель - система команд, в которую компилится все и может с разумными затратами JIT-компилироваться на любом процессоре, то надо брать за основу insn'ы GNU C или другое внутреннее представление современных компиляторов, а не байткоды.
факт. даже в .net байткоды определены только для "ментальной совместимости" с Жабой, по-моему, а так можно и без байткодов обойтись. и вообще в Microsoft Research вроде не полные идиёты сидят, они же до этого C-- делали...
Добро пожаловать в клуб
Ну, вы же про дуфусов-то читали. :) Если мы ставим задачу реализовать полностью программируемую машину, то все эти ношения пруфов сводятся к задаче автоматического доказательства финитности исполнения. Значит, мы должны делать не полностью программируемую машину. Нес па?
Выход если и есть, то в поиске новой парадигмы вычислений, не эквивалентной дискретному автомату. А остальное - так, развлечения для дуфусов. :)
Вон, кстати, как раз
>в Microsoft Research вроде не полные идиёты сидят
Вот в этом я как раз не убежден. :)
Re: Добро пожаловать в клуб
Re: Добро пожаловать в клуб
Date: 2002-06-17 08:14 am (UTC)Кстати, технионовский Dan Geiger одно время работал в моей группе в Microsoft Research.
Re: Добро пожаловать в клуб
Date: 2002-06-17 09:52 am (UTC)не совсем. (как я понимаю, а я ещё не шибко в этом копался, так что без соли не употребляйте).
там вся фишка в том чтобы генерировать гарантированно "безопасный" код, с приложенным к нему "доказательством". при этом экспрессивность данного кода совершенно не обязана быть чем-то жёстко ограничена.
вот Вам аналогия (точнее, частный случай): Вы всегда можете быть уверены (кроме случаев наличия грубых багов в компиляторе), что скомпилированный Вами C-код не содержит нелегальных инструкций и не будет во время исполнения строить кривые stack-frame'ы. проверять это post-factum, на готовом коде, может быть весьма проблематично (особенно второе свойство), но самому компилятору не составляет особого труда эти свойства обеспечить.
(извините за корявый слог)
Кривой stack frame? Легко
Re: Кривой stack frame? Легко
Date: 2002-06-18 12:30 am (UTC)(ну и в любом случае: я не претендую на непробиваемость приведённого мною примера, натурально. это только иллюстрация)
Re: Кривой stack frame? Легко
Date: 2002-06-18 12:55 am (UTC)Еще проще:
int broken_stack_frame(char * str) { char buf[BUFSIZE]; strcpy(str, buf); // etc }
>хотя это уже будет и не совсем C.
Это будет совсем не C. В лучшем случае это будет жаба.
Пойнт как раз в том, что непробиваемый пример - это либо система, способная доказывать финитность исполняющихся на ней алгоритмов, либо система, способная исполнять только некоторые алгоритмы. Первое невозможно, второе по построению ограничено в возможностях.
Еще к теме кривых stack frame
Re: Еще к теме кривых stack frame
Date: 2002-06-18 12:34 am (UTC)кстати, это принятая русскоязычная терминология? кайф какой. не калькируя обратно на английский, не поймёшь о чём и речь. :)
а только прямые stack frame'ы для этой радости, понятно, недостаточны. ну и что? на языке Ц свет клином не сошёлся.
Re: Еще к теме кривых stack frame
>а только прямые stack frame'ы для этой радости, понятно, недостаточны. ну и что?
Ну и то, что возвращаемся к моему исходному тезису: если мы делаем машину не полностью программируемой, она оказывается недостаточной для каких-то целей. Собственно, это и есть определение "неполной программируемости". А если машина полностью программируема, то "правильность" (что бы под этим ни подразумевалось) написанной на ней программы недоказуема. Во всяком случае, автоматически. Вот и приехали.
>на языке Ц свет клином не сошёлся.
Соответственно и создать виртуальную машину, которая имела бы хранимые пруфы и при том была бы достойна схождения на ней клином всего света, невозможно. Я ответил на ваш исходный вопрос?
Re: Еще к теме кривых stack frame
Date: 2002-06-18 01:39 am (UTC)нет, поскольку наши взаимные догадки по поводу терминологии друг друга бьют строго мимо (видимо).
так что давайте перестанем гадать:
. утверждаю ли я, что можно создать "полностью программируемую" архитектуру, правильность любой программы для которой была бы доказуема? если под "полностью программируемой" понимать "под неё можно написать полный C-компилятор", то, натурально, нет, чему-то меня всё-таки в университете научили. если под "полностью программируемой" понимать "достаточно экспрессивная" (пригодная для практичной реализации какого-нибудь доказанно экспрессивного формализма), то да. в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)). ну и, разумеется, мы вынуждены доверять компилятору.
. считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.
Re: Еще к теме кривых stack frame
Date: 2002-06-18 04:03 am (UTC)Честно говоря, не очень слежу за литературой в этой области - что в данном случае понимается под "экспрессивным формализмом"? (инстинктивно чувствую, что ничего хорошего :)
>в определении архитектуры я бы ещё пояснил, что никакая программа без приложенного доказательства принята к исполнению не будет (важная деталь, да :)).
Это очень важная деталь, потому что требует автоматической генерации доказательства. Что невозможно. :) (подход, когда доказательство корректности должен проводить программист, я отбрасываю из-за очевидной непрактичности)
>считаю ли я, что без полного C-компилятора архитектура недостойна рассмотрения? нет, не считаю.
На самом деле, проблема тут несколько глубже, чем "достаточная экспрессивность" и С-компилятор. Полностью программируемая - значит, на ней можно реализовать любой конечный автомат с количеством состояний, не превосходящим некоторый объем. Важно и это, и то, чтобы реализация этого автомата была 1. Более умопостижима, чем таблица состояний. 2. Не сильно уступала по скорости "идеальной" реализации того же автомата с одним переходом за такт. Если возможность реализации можно доказать, это хорошо, но треть дела. Остается вопрос умопостижимости предложенного формализма и производительность, которые уже недоказуемы.
Си, даже с учетом своих заморочек - умопостижим и производителен. Жаба попыталась найти компромисс за счет производительности, для многих случаев приемлемый, но в некоторых - обасалютно... (я тут несколько колов времени назад имел счастье трахаться именно с ее гарбаж коллектором при вызове нативных методов. Она меня затрахала). C# страдает тем же самым и по той же самой причине.
Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.
Re: Еще к теме кривых stack frame
Date: 2002-06-18 04:31 am (UTC)инстинкта хватит.
вот у Вас проблема с Жабой какая? native method медленно зовётся? а нафига Вам этот самый native method? варианты:
. потому что Жабина виртуальная машина органически неспособна выразить нужную функциональность
. потому что выражать нужную функциональность на Жабиной виртуальной машине будет неэффективно
. потому что нужная функциональность уже реализована не на Жабе, и проще позвать её
подозреваю, что здесь мы имеем смесь второго и третьего, не так ли? то есть экспрессивность Жабиной виртуальной машины нас в общем устраивает, за исключением возможно немаловажных, но непринципиальных ограничений. мы ж тут типа академическими пальцами шевелим, да? :)
> Это очень важная деталь, потому что требует автоматической генерации доказательства. Что невозможно.
дык вот вроде бы возможно, хотя пока ещё непрактично.
> Я, собственно, к тому, что все это тришкин кафтан - решать одно за счет другого. Подобрать оптимум для узкого класса задач - почему нет, но это не может быть next big thing. Просто - раньше интерпретируемые языки были с фортраноподобным синтаксисом (IBM REXX), потом появилось несколько относительно удачных с BASIC-подобным (визуальный васик, лотусскрипт), теперь - с C-подобным. Вот и весь эволюционный прорыв жабы и C#. Сшить еще одну версию тришкина кафтана, которая не покрывается по отдельности ни жабой, ни перлом, ни PHP, ни дельфями - может быть и можно.
ой, мама. а что такое "интерпретируемый язык"?
Re: Еще к теме кривых stack frame
Инстинкт и доказательство - две вещи несовместные. :)
>вот у Вас проблема с Жабой какая? native method медленно зовётся?
Нет, сложнее. Нативный метод размещает некоторые (весьма дорогостоящие) системные ресурсы, Notes C API handle, если это интересно. Из деструктора объекта эти ресурсы освобождаются. Деструктор не зовется, пока гарбаж коллектор не соизволит найти этот объект, в результате системные ресурсы накапливаются практически неограниченно.
Проблема именно в "экспрессивности", в самой семантике жабной виртуальной машины, а именно в том, что интервал от освобождения объекта (выхода из области видимости последней ссылки на) до вызова деструктора велик, зачастую недопустимо велик, а все средства его сокращения - палка об двух, а то и более концах.
>потому что нужная функциональность уже реализована не на Жабе, и проще позвать её
Ну, в данном случае можно сказать и "проще", но переписать Нотуса на Жабе - это, как бы, с одной стороны не более, чем "сложно", но для большинства контекстов это слишком слабое выражение.
>интерпретируемый язык
Который рассчитан на исполнение "виртуальной машиной", а не пентиумом. :) Согласитесь, что хотя можно и си в байткоды компилировать, но этого почему-то никто не делает. :) То есть классификация "инстинктивная", но в крайних случаях (как С и PHP) бесспорная. Наличие гарбаж коллектора - сильный довод в пользу отнесения языка к интерпретируемым.
Re: Еще к теме кривых stack frame
Date: 2002-06-18 05:02 am (UTC)ну в общем, представьте что я это красиво и уважительно сказал. спасибо. :)
Пожалуйста
Программирование вообще дело такое, что в нем абстракции ценны ровно постольку, поскольку прагматичны. И наоборот. Поэтому в их смешивании греха не вижу. Элемент издевательства присутствует. Фраза про терминологию вообще-то обратима. :) Поэтому не вижу в ваших словах ничего такого уж несправедливого.
Re: Еще к теме кривых stack frame
Date: 2002-06-20 07:26 pm (UTC)Re: Еще к теме кривых stack frame
Ведь если деструктор не отработал, значит кто-то может держать на нас живую ссылку, правильно?
Проблема висячих ссылок, только в профиль. И спрашивается, ради чего тогда мы выдумывали деструкторы и сборщик мусора?
Re: Добро пожаловать в клуб
Date: 2002-06-17 10:44 am (UTC)Re: sawa;)
Date: 2002-06-17 07:58 am (UTC)Re: sawa;)
Date: 2002-06-17 08:38 am (UTC)вот это меня изрядно даже забавляет. уж кто-кто а микрософтеры должны бы понимать, на чьей стороне закон Мура. :)
если же серьёзно, то давайте вот рассмотрим проблему внимательно:
. код надо компилировать, что занимает время. байткод компилируется быстро, исходный код несколько медленнее. но по-моему, чем дальше тем разница менее существенна.
. код должен быстро бегать. понятно, что исходный код можно соптимизировать лучше.
. исходный код стрёмно передавать по сети. в таком случае его можно закодировать, либо закодировать канал. к тому же исходный код обычно меньше по размеру чем байткод.
Re: sawa;)
Date: 2002-06-17 09:25 am (UTC)Re: sawa;)
Date: 2002-06-17 09:38 am (UTC)забавно, спасибо. (я это ищу? :))
> байткоды суть tried and tested technology
native-compiling Lisp/Smalltalk systems существуют уже пёс знает сколько лет. а код на Лиспе или Смаллтоке -- это же фактически деревья, нет?
(обратите внимание, как забавно выходит. предположим, Вы отвечаете (вполне легитимно, кстати): "нихрена подобного, это не деревья". на это я отвечаю: вот видите, а пользователи вроде на скорость компиляции не очень-то жалуются. когда у меня в споре выходит такое, обычно это означает что я не понял проблемы. чего же я не понял?)
Re: sawa;)
Date: 2002-06-17 09:47 am (UTC)Re: sawa;)
Date: 2002-06-17 09:54 am (UTC)Re: sawa;)
Date: 2002-06-17 10:04 am (UTC)sawa :(
Date: 2002-06-18 12:21 am (UTC)Но вот вопрос о самоидентификации кода (чтобы код служил подписью к себе) напоминает задачу о программе, пишущей самою себя. Не в том смысле, как её обычно решают, а в смысле эволюции. Лучшее, что известно из этой области -- всякие Компьютерные Войны, черви и вирусы. Пока процесс без участия человека не идёт.
Не говоря уж о безопасности кода...
Re: sawa;)
Date: 2002-06-17 08:10 am (UTC)sawa
Date: 2002-06-18 03:45 am (UTC)DOOFUS <- DO + (FUSS v FUSE)
?
Re: sawa;)
Date: 2002-06-17 06:38 am (UTC)sawa;)
Date: 2002-06-17 11:59 pm (UTC)Некто задался создать _канал_ с огромной пропускной способностью из подручных средств. Решение было таким: загрузить самосвал КДисками без коробочек. У него получались ТераБайты/секунду (он опустил время создания КД и прочее).
PS Для _всех_ языков Пентиум не подходит. Достаточно попробовать перевести (транслятором, частью компилятора) фразу "Naked conductor runs along the bus" любым переводчиком. Например www.translate.ru.
no subject
Vault не позволяет ЛАПТЯМ и невинность соблюсти, и капитал приобрести - но он делает это иначе, чем Java, .NET и иже с ними.