Есть ли будущее у Native Code? - Философия программирования

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
S>Это всё малоинтересно. С точки зрения пользователя, самое страшное уже произошло — в коде оказалась ошибка, и запрошенную операцию выполнить не удалось. То, что ядро системы продолжает успешно работать, никому (кроме авторов ядра) неинтересно*.

Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

>Это и есть та причина (а вовсе не производительность), по которой обеспечение иммутабельности переменной при помощи аппаратной защиты никому не нужно.
S>Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.

Ха! А гарантии , что файл на диске есть, ты не хочешь ? Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ? А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.

S>(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может.

Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, IID, Вы писали:

WH>С программной изоляцией такого не случится благодаря значительно более мелкой гранулярности проверок и значительно более широкому классу этих проверок.
WH>В отличии от аппаратной защиты которая контролирует чтение/запись/исполнение с гранулярностью 4К

Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

Здравствуйте, Serginio1, Вы писали:

S>Так снимается нагрузка с GC, а сами эти массивы используй как пул для повторного использования.

И про это я думал... Тут ньюансов два: в пуле можно выделять объекты разных структур, если они имеют одинаковый размер. Во-вторых, работа с индексами вместо указателей будет менее удобна, как по мне. Плюс вопрос с производительностью (выход за пределы диапазона).

Я не говорю, что написать производительный движок под .NET в принципе нельзя. Сделать можно, но при этом наблюдается очень неприятный эффект: работая с абстрактными структурами я должен постоянно как бы компилировать возникающий код и смотреть, а что получится на более низком уровне. Все это делает работу менее удобной. Иногда я должен
в верифицируемом коде использовать всякие трюки, как-то GlobalPositions[GlobalPositions[CurrentIndex].Next], вместо CurrentPosition->Next.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

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

PD>Ха! А гарантии , что файл на диске есть, ты не хочешь ?
Хочу. И есть способ построить систему, которая гарантирует мне отсутствие FileNotFoundException в принципе. Потому как в ней не предусмотрен способ обращаться к несуществующим файлам.

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

S>>(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может.

PD>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.
Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
А про ограниченность — мы же вроде в этой ветке говорим о будущем? Ну так почему бы нам не захотеть доказательства всё более сильных утверждений о наших программах?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

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

Здравствуйте, Sinclair, Вы писали:

S>Гм. Это опять "мы хотим, чтобы не было богатых" против "дедушка хотел, чтобы не было бедных".
S>Ты хочешь, чтобы упавшая программа не могла сломать еще не упавшие (и дать им упасть самостоятельно), а мы хотим, чтобы программы вообще не падали.

Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно. А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит. Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.

PD>>Ха! А гарантии , что файл на диске есть, ты не хочешь ?
S>Хочу. И есть способ построить систему, которая гарантирует мне отсутствие FileNotFoundException в принципе. Потому как в ней не предусмотрен способ обращаться к несуществующим файлам.

Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

PD>>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?
S>Меня устраивают все они, но я хочу минимизировать объем кода, связанного с обработкой нештатных ситуаций. Просто потому, что их всегда гораздо больше, чем штатных.

Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

PD>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.
S>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.

Вот именно. +1

S>А про ограниченность — мы же вроде в этой ветке говорим о будущем? Ну так почему бы нам не захотеть доказательства всё более сильных утверждений о наших программах?

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

А ДОСа не будет. Система будет более устойчивой чем сейчас.
Если в неком процессе будет ошибка то можно просто прибить этот процесс и все.
Система как работала так и будет работать.
Причем это касается не только рядовых процессов как в венде, а всех включая драйверы.

S>>Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.
PD>Ха! А гарантии , что файл на диске есть, ты не хочешь ?
Лично я хочу но не очень понятно как этого добиться.

PD>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?
По тому что от FileNotFoundException не избавится, а вот без AccessViolationException можно спокойно жить.

PD>А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.
Второе нужно только менеджеру памяти ОС.

PD>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите
Чем конкретно мы за нее платим?
Отказом от С++? Ну да и хрен бы с ним.

PD>и слишком она ограничена.
А конкретно?

Здравствуйте, Mystic, Вы писали:

M>Я не говорю, что написать производительный движок под .NET в принципе нельзя. Сделать можно, но при этом наблюдается очень неприятный эффект: работая с абстрактными структурами я должен постоянно как бы компилировать возникающий код и смотреть, а что получится на более низком уровне. Все это делает работу менее удобной. Иногда я должен
M>в верифицируемом коде использовать всякие трюки, как-то GlobalPositions[GlobalPositions[CurrentIndex].Next], вместо CurrentPosition->Next.
Ты можешь определить эти методы в самой структуре (массив,индекс), аля курсор.
например

    internal struct Bookmark<K, V>
    {
        internal LeafPage<K, V> _page;
        internal int _index;

        public bool IsNull
        {
            get { return _page == null; }
        }

        public bool Next()
        {
            _index++;
            if (_index >= _page.Count)
            {
                if (_page.NextPage == null)
                    return false;
                else
                {
                    _index = 0;
                    _page = _page.NextPage;
                }
            }
            return true;
        }

        public bool Prior()
        {
            _index--;
            if (_index < 0)
            {
                if (_page.PriorPage == null)
                { return false; }
                else
                {
                    _page = _page.PriorPage;
                    _index = _page.Count - 1;
                }
            }
            return true;
        }

        public bool Selected
        {
            get
            {
                return ((_page != null) && (_page.Count > 0) && (_index >= 0)
                        && (_index < _page.Count));
            }
        }

        public bool Delete()
        {
            if ((_page.Count > BTConst.MidlCount) && (_index > 0))
            {
                if (_index == (_page.Count - 1))
                {
                    _page.Count--;
                    _page.PageItems[_index] = KeyValuePair<K, V>.default;
                    if (_page.NextPage != null)
                    {
                        _page = _page.NextPage;
                        _index = 0;
                    }
                }
                else
                {
                    _page.Count--;
                    Array.Copy(_page.PageItems, _index + 1, _page.PageItems,
                    _index, _page.Count - _index);

                    _page.PageItems[_page.Count] = KeyValuePair<K, V>.default;
                }

                return true;
            }
            else
                return false;
        }

        public V Value
        {
            get { return _page.PageItems[_index].Value; }
            set { _page.PageItems[_index].Value = value; }
        }

        public K Key
        {
            get { return _page.PageItems[_index].Key; }
        }
    }

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

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

достаточно скомпилить вирус "косячным" компилятором, чтобы убить незащищенную систему с легкостью. runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно.
А еще можно сделать бесплатную сборку мусора в С.
Знаешь как?
Запускаем программу на 64х битной системе.
Вся неиспользуемая память будет навсегда оседать в свопе.
Далее смотрим если в свопе лежит страница к которой не обращались неделю значит она не нужна и выкидываем ее.

PD>А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.
Тут согласен.

PD>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.
А тут не совсем.
Зависимые типы могут очень много чего ловить.

PD>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.
Чтобы совсем не было исключений не получится. Но вот убить почти все исключения можно.

PD>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.
Когда я писал числомолотилки то меня тоже мало заботили нештатные ситуации ибо в числомолотилках они почти не встречаются.
А вот шаг в сторону и приплыли.

PD>>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.
S>>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
PD>Вот именно. +1
Приехали. Ты уже сам с собой споришь...

PD>Под ограниченностью я имею в виду, что вы накладываете серьезные требования на иммутабельные типы, а поэтому большинство типов таковыми не будет.
Ты просто привык к императивному базису и ничего другого не понимаешь.
А у тех кто понимает большинство типов именно такими и будут.

PD>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.
Не мы, а вы!
У меня в программах переменных весьма не много даже если приходится писать на С++.
А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.

PD>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

Для этого есть SIPы http://rsdn.ru/article/singularity/singularity.xml#EYC

Здравствуйте, swined, Вы писали:

S>достаточно скомпилить вирус "косячным" компилятором, чтобы убить незащищенную систему с легкостью.
Недостаточно. Код просто не пройдет верификацию и все. И никаких прав не хватит чтобы его запустить.

S>runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.
Ну так проверки времени установки и будут. А вот проверки времени исполнения будут практически полностью устранены зависимыми типами.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно.
PD> А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.
Я уже заметил, что для тебя статистические вещи малопонятны.
PD>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.
Я, в общем-то, согласен и на 99%.

PD>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.
Видишь ли, уровень безошибочности, достижимый при помощи K&R С, был достигнут уже давно. И мне как раз неинтересно рассуждать на тему "а потому работай-не работай, всё едино".
Мне интересно думать на тему "а что еще можно улучшить?"

PD>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.
Просто в твоих задачах, значит, эти ситуации малосущественны.

PD>Под ограниченностью я имею в виду, что вы накладываете серьезные требования на иммутабельные типы, а поэтому большинство типов таковыми не будет.
Да ладно! Это ты как считал?
PD>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.
Гм. Как бы так тебе объяснить... Ты под термином "программа" всё время подразумеваешь "программа на языке С".
В лучшем случае — "алгоритм", то есть Тьюринговский формализм программирования. Это только один, и очень узкий взгляд. Как ты, возможно, знаешь, любой алгоритм можно выразить не только в виде программы для машины Тьюринга, но и в виде частично вычислимых функций. А там, извини, никаких переменных вовсе нет. Поэтому то, что вы имеете в программе намного больше переменных — это лично ваша заслуга, а отнюдь не неотъемлемое свойство самих программ

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mystic, Вы писали:

M>>Да никаких не надо, надо выполнить одну ассемблерную команду.
S>Хм. И насколько она будет быстрее, чем вот такой код:
...
S>?

Девять тактов против пяти условий (первое условие можно смело выкинуть, потому что в большинстве битовых масок поле A1 будет сброшено) а в худшем случае еще десять битовых операций... При чем худший случай совсем не теоретический (например, в начальной позиции маска черных ладей равна 0x8100000000000000). И по алгоритму мы вначале получаем индекс первой ладьи, сбрасываем его и получаем индекс второй...

Чтобы было понятно, как будет использоваться этот код, приведу фрагмент обычного кода генерации ходов:

uint64 bitboard = GetRooks(); // Получение ладей (аналогично слоны, ферзи и кони)
while (bitboard) 
{
  // Получаем первую ладью и одновременно очищаем этот бит в bitboard
  from = ExtractFirstOne(bitboard); 

  // Тут скрыто много ньюансов, но AttacksRook возвращает битовую маску полей, куда может походить ладья
  // Если используются повернутые битовые маски, то хранится bitboard всех фигур не только в обычном порядке A1, B1, C1, ...
  // Но и в порядке A1, A2, A3, ..., A8, B1, ..., что позволяет получить поля, куда может пойти ладья, по таблице
  // Аналогично работает и для слонов (там используются bitboard-ы, повернутые на 45 и 135 градусов, как-то 
  // A8, A7, B8, .... A1, B2, C3, ... Для коней все проще, можно заранее посчитать битовую маску куда он может 
  // прыгнуть для каждого поля.
  moves = AttacksRook(from, OccupedSquares); 

  // Ну и дальше просто. Пока есть куда пойти
  while (moves)
  {
    // Получает первое поле
    to = ExtractFirstOne(moves);

    // Делаем ход
    DoMove(from, to);
  }
}

В цифрах насколько медленнее будет, сказать не могу... Потому как мне проще написать ассемблерную вставку. А проблема получения первого бита, увы не единственная в управляемом коде...

Ну а к сведению, наиболее близок по производительности этот вариант, но... Я такой код только содрать могу...

Здравствуйте, WolfHound, Вы писали:

WH>Недостаточно. Код просто не пройдет верификацию и все. И никаких прав не хватит чтобы его запустить.

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

S>>runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.
WH>Ну так проверки времени установки и будут. А вот проверки времени исполнения будут практически полностью устранены зависимыми типами.

бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?

Здравствуйте, Serginio1, Вы писали:

S>Ты можешь определить эти методы в самой структуре (массив,индекс), аля курсор.
S>например

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:

WH>А еще можно сделать бесплатную сборку мусора в С.
WH>Знаешь как?
WH>Запускаем программу на 64х битной системе.
WH>Вся неиспользуемая память будет навсегда оседать в свопе.

Ты сначала разберись, чем отличается виртуальная память от физической (включая своп), чтобы не говорить такое. То, о чем ты говоришь, есть управление физической памятью в ОС, своп файл и RAM исключительно под ее контролем, я туда никак из 3 кольца попасть не могу. А сборка мусора есть действие исключительно в виртуальной памяти процесса.

WH>Далее смотрим если в свопе лежит страница к которой не обращались неделю значит она не нужна и выкидываем ее.

А если не секрет, как из программы 3 кольца узнать, как давно мы не обращались к этой странице ? Мне это очень интересно знать

Более того, мне вообще интересно знать, как я смогу найти эту страницу в своп-файле из приложения 3 кольца ? Где она хранится — я узнать вообще-то могу и ее атрибуты тоже, только для этого надо в нулевое кольцо как-то перебраться, а это только вирусы, по твоему мнению, умеют, а я их не пишу

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

WH>

Юмор могу и оценить, но честное слово, кончай высказываться по вопросам, в которых ты не разбираешься! У тебя есть области, в которых ты разбираешься неплохо, зачем тебе лезть туда, где ты ничего не понимаешь и говорить чепуху ?

PD>>А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.
WH>Тут согласен.

PD>>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.
WH>А тут не совсем.
WH>Зависимые типы могут очень много чего ловить.

И все же, если в формуле для корней квадратного уравнения я напишу sqrt(b*b+4*a*c), какие зависимые типы это отловят ? А может, мне именно так и надо ?

PD>>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.
WH>Чтобы совсем не было исключений не получится. Но вот убить почти все исключения можно.

Да все можно — в теории. И твоя тотально управляемая ОС в теории тоже не так уж плоха. Как идея. Но реально тебе накидали немало возражений (DMA, текстуры, внешние устройства), могу еще и свое добавить — CUDA, там надо резидентную память иметь. И т.д. И практически чтобы твою идею о тотальном управлении реализовать, нужен иной процессор, иная периферия, в общем, глобальная революция. Революции не так уж плохи, но надо отдавать себе отчет, во имя чего ее будут делать, тратить миллиарды долларов. Во имя перехода от ужасной 16-битной модели к нормальной 32-битной — да. Во имя перехода от нормальной 32-битной модели, но ограничения которой начинают мешать, к 64-битной — да ,хотя, кстати, так и не перешли до сих пор. А ты чем заплатишь ? Некоторой (и то в теории, никто же не проверял) надеждой на улучшение надежности программ, которые не будут лезть куда не надо ? И ради этого переписать все ПО, переделать всю аппаратуру ? И ради этого миллиарды долларов ? Не дадут.

PD>>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.
WH>Когда я писал числомолотилки то меня тоже мало заботили нештатные ситуации ибо в числомолотилках они почти не встречаются.
WH>А вот шаг в сторону и приплыли.

Именно. Я же об этом и говорю. Разные есть задачи. А машина одна

PD>>>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.
S>>>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
PD>>Вот именно. +1
WH>Приехали. Ты уже сам с собой споришь...

Почему ? Я согласен, что плата за иммутабельные объекты в моих задач слишком большая, и, как говорит Антон, перевесит выручку. В чем я себе противоречу ?

PD>>Под ограниченностью я имею в виду, что вы накладываете серьезные требования на иммутабельные типы, а поэтому большинство типов таковыми не будет.
WH>Ты просто привык к императивному базису и ничего другого не понимаешь.
WH>А у тех кто понимает большинство типов именно такими и будут.

Так разные же есть задачи. Вот ты писал, как говоришь, числодробилки. Там констант много было ? Как бы все не кончилось 4 константами — 0 , 1 pi и e

PD>>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.
WH>Не мы, а вы!
WH>У меня в программах переменных весьма не много даже если приходится писать на С++.

Так, стоп. Под переменными я имею в виду отнюдь не описания

List* pL;

безусловно формально одна переменная, но в действительности их тут столько, сколько полей у всех элементов списка.

WH>А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.

Я с немерле не знаком, поэтому спорить не буду. Но по существу, думаю, они и там есть, хотя формально, может, и нет.

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

	От:	Pavel Dvorkin
	Дата:	24.06.09 09:28
	Оценка:

	От:	WolfHound
	Дата:	24.06.09 09:30
	Оценка:

	От:	Воронков Василий
	Дата:	24.06.09 09:36
	Оценка:

	От:	Pavel Dvorkin
	Дата:	24.06.09 09:37
	Оценка:

	От:	Pavel Dvorkin
	Дата:	24.06.09 09:44
	Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	24.06.09 09:49
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	24.06.09 09:56
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	24.06.09 10:07
Оценка:	1 (1)