Если предыдущий мой пример действительно ошибка, то реализуйте мне, имея одни только прямые 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, а потом кто-нибудь метод возьмет и позовет? Ведь если деструктор не отработал, значит кто-то может держать на нас живую ссылку, правильно? Проблема висячих ссылок, только в профиль. И спрашивается, ради чего тогда мы выдумывали деструкторы и сборщик мусора?
![[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
Еще к теме кривых 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
Ведь если деструктор не отработал, значит кто-то может держать на нас живую ссылку, правильно?
Проблема висячих ссылок, только в профиль. И спрашивается, ради чего тогда мы выдумывали деструкторы и сборщик мусора?