Здравствуйте, Sinclair, Вы писали:
S>Как в C# или Java — происходит статическая верификация кода. "Случайных" указателей в коде не бывает. Нельзя просто взять квадратный корень из Pi и использовать в качестве указателя.
Спасибо, я не знал
PD>>Вопрос не в ограничениях, а в архитектуре. Тебе не кажется, что тот же интерфейс GET с параметрами можно бы на что-то более элегантное заменить ? И заодно Header переделать. S>У GET нет никаких параметров. Там же только URI. Куда элегантнее-то? Расширить набор поддерживаемых символов? Зачем?...
c упаковкой параметров через '&" и знаком вопроса не кажется особенно элегантным. Для 1990 года он был хорош, но сейчас все же можно и что-то лучше структурированное предложить.
Напоминаю, что речь идет о демиурге — аргументы о том, что это в каждом месте, не принимаются.
S>С заголовками тоже всё хорошо.
И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить.
По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать.
Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ?
Здравствуйте, WolfHound, Вы писали:
WH>То что ты не знаешь как не значит что это сделать нельзя. WH>Твоя проблема в том, что ты за пределами С++ ничего даже не пытаешься изучать.
Ответить мог бы, но твоя манера сразу переходить на личности отбивает желание отвечать.
Скажу лишь, что на С++ я уже несколько лет, увы, не пишу.
Здравствуйте, Pavel Dvorkin, Вы писали:
ARK>>Вы забываете про переключения контекста, которые очень сильно снижают производительность и выполняются в стстемах с аппаратной защитой _постоянно_. Статическая верификация позволяет выполнять весь код в одном «кольце» (да, собственно, кольца вообще не нужны).
PD>Почему они выполняются постоянно ? Они выполняются при переключении процессов, при системных вызовах и еще в некоторых случаях. Если я просто обращаюсь к юзермодным страницам памяти — никаких переключений контекста не будет.
Планировщик ОС работает постоянно и переключения контекста происходят много раз в секунду. В Singularity замеряли — скорость переключения между процессами в 3 раза быстрее, чем переключение контекста в традиционных системах.
Да если даже говорить только о системных вызовах — много ли вы сможете сделать без них? В типичных приложениях они происходят постоянно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ответить мог бы, но твоя манера сразу переходить на личности отбивает желание отвечать.
Это по тому что тебе ответить нечего.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
·>Поясни, плиз, немного. Как доказать, что в этом доказательстве нет ошибки?
Компилятор проверяет.
Для того чтобы доказать, что в компиляторе нет ошибок достаточно доказать очень простую и маленькую часть компилятора.
А её доказывают так же как доказывают математические теоремы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Я за то чтобы разработчики использовали только ООП или декларативное программирование (ДП) и как можно реже опускались на уровень процедурного программирования. Я не против процедурного программирования в принципе, иногда статические классы или синглтоны упрощают решение задачи, но они не должны быть основой архитектуры. Архитектура должна быть объектно-ориентированной или декларативной, но не процедурно-ориентированной. Тем не менее сейчас в ходу SOA, в которой сервисы процедурные. При взаимодействие с БД, современное декларативное богатство SQL скрывается за первобытным процедурным подходом (SOAP или хранимые процедуры). Я за то чтобы БД была SQL сервисом. Для взаимодействия с no SQL компонентом архитектуры я бы развивал что-то наподобие DCOM.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Sinclair, Вы писали:
S>Возможностями по декомпозиции и по диагностике ошибок.
Если не правильно составил запрос -- логическая ошибка, как типизация поможет? А вот жизнь всем разработчикам субд осложнила бы. Да и от диалектов это бы не спасло.
Про декомпозицию вообще не понял.
Здравствуйте, AlexRK, Вы писали:
ARK>Планировщик ОС работает постоянно и переключения контекста происходят много раз в секунду.
Совершенно верно, много раз в секунду. Именно много раз. Но по сравнению с временем выполнения команд это очень редко делается.
>В Singularity замеряли — скорость переключения между процессами в 3 раза быстрее, чем переключение контекста в традиционных системах.
Вполне возможно, вот только вопрос в проценте времени, уходящем на эти переключения процессов. В Windows WorkStation размер кванта 2 таймерных интервала, в Server — 12. Если за это время поток сам не освободит процессор (сон, ожидание и т.п.), то посчитай, сколько команд он успеет выполнить за эти 2 или 12 таймерных интервала(ов) , и без всякого переключения контекста, если не будет того, о чем пишу ниже.
Ну и еще один момент. Переключение процессов в настольной системе — это (не всегда, конечно) следствие того, что пользователь выбрал иное окно. По той причине, что потоки оконных приложений, пока пользователь с их окнами не работает, в Windows обычно спят и процессор не загружают. А активация окна спящего GUI — потока — это такое количество всяких действий, на фоне которого переключение контекста есть всего лишь мелочь. Одна отрисовка окна чего стоит.
ARK>Да если даже говорить только о системных вызовах — много ли вы сможете сделать без них? В типичных приложениях они происходят постоянно.
Постоянно, но очень редко. В основном при системных вызовах, ну и, конечно, при SEH исключениях. Тут и впрямь много. Но все же количество системных вызовов в секунду крайне невелико по сравнению с количеством обычных операций.
1)Запретить языки с динамической типизацией.
Недостатки:
а)Тормоза.
б)Потребление памяти на ровном месте.
в)Не ловят ошибки программистов.
г)Невозможно создать качественную IDE.
Достоинство:
Нужно писать меньше кода по сравнению с явой.
По сравнению с немерле разница становится минимальной. И на практике не всегда в пользу динамически типизированных языков. Ибо они примитивные.
2)Запретить нативный код.
Проблема нативного кода в том, что он не даёт заменять систему команд процессоров.
Через пару лет после того как не станет нативного кода x86 сдохнет.
Исключение можно сделать только для совсем дохлых микропроцессоров где даже ОС нет.
mutable, readonly и immutable становятся атрибутами кластеров.
в)Добавляем http://halide-lang.org/ для параллельного программирования.
г)Заменяем контракты на это: https://www.microsoft.com/en-us/research/project/dafny-a-language-and-program-verifier-for-functional-correctness/
Учим компилятор вставлять рантайм проверки в тех местах где он не смог статически доказать корректность.
Если проверка провалилась, то молча прибиваем процесс.
Если статически доказано что ошибка будет всегда, то выдаём ошибку компиляции.
Обоснование тут: http://joeduffyblog.com/2016/02/07/the-error-model/
Делаем 3 уровня:
1)Никогда не вставлять. Если программист что-то не доказал выдаём ошибку.
2)Всегда вставлять, но вместо ошибки выдавать предупреждение.
3)Молча вставлять.
Большая часть кода будет всегда жить в третьем режиме. В этом случае мы получаем код в стиле явы и C#. Но так как пред и пост условия всё равно можно будет писать то большая часть проверок будет выполнена статически. И код будет быстрее.
Более того ошибки будут обнаружены там, где они произошли, а не где попало.
Второй режим нужен при начальном написании ответственного кода.
Сначала пишем в третьем режиме. Ибо писать сразу в первом довольно трудно. Когда код написан переходим во второй и начинаем доказывать. Когда все предупреждения закончились переключаем в первый.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>·>Поясни, плиз, немного. Как доказать, что в этом доказательстве нет ошибки? WH>Компилятор проверяет. WH>Для того чтобы доказать, что в компиляторе нет ошибок достаточно доказать очень простую и маленькую часть компилятора. WH>А её доказывают так же как доказывают математические теоремы.
Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CoderMonkey, Вы писали:
CM>Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями.
Я бы иначе сказал. Развитие, да, если не прекратилось, то сильно затормозилось. Но ни из чего не следует, что он должно продолжаться вечно. Возможно, мы просто пришли к пределу. А он гарантированно есть по крайней мере пока в силах ОТО и 300000 км/сек.
В конце концов все технологии на данной материальной основе раньше или позже подходят к своему пределу, чем-то обусловленному.
CM>Нужно новое железо!
Смайлик заметил, но если серьезно, то ни из чего не следует, что при нынешней элементной базе оно вообще возможно.
Здравствуйте, Sharov, Вы писали:
S>В чем проблема пересобрать? Исполняющая среда по-любому будет пересобрана. Ну да, выигрыш в кол-ве пересборов. Не думаю, что это так критично.
Это фатально.
Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее.
А теперь попробуй заставить всех разработчиков программ выпускать свои программы еще и под новый процессор. Это не реально. Итаниум сдох по тому что народ не захотел пересобрать программы.
Особенно если вспомнить что есть программы, на поддержку которых разработчик давно забил, разработчика больше нет или исходники потерялись.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ·, Вы писали:
·>Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например?
Такое быть не может.
Ибо у индексера массива есть вот такое предусловие
0 <= i < array.Length
И если это условие не доказано программа просто не скомпилируется.
Можешь поиграть с онлайн компилятором: https://rise4fun.com/Dafny/pX4N
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее.
Не вижу проблемы, учитывая что реально новый процессоры появляются раз в 10,а то и 20 лет.
WH>А теперь попробуй заставить всех разработчиков программ выпускать свои программы еще и под новый процессор. Это не реально. Итаниум сдох по тому что народ не захотел пересобрать программы.
Если не ошибаюсь, Итаниум сдох не дойдя до народа -- для него крайне сложно оказалось написать хороший компилятор.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Что из первых двух выбираешь ? S>>Но это ведь не взаимоисключающие вещи.
PD>Хорошо, давай свой гибрид.
Гибрид необязателен. Берем C++ и верификатор. Я не призываю его брать после пропажи всего софта, я просто показываю что выбор не ограничен двумя пунктами.
S>>А разве статическая верификация программы на нативном языке как-то ограничивает мощь процессора?
PD>Нет, конечно, но я не уверен, что она гарантирует то, что требуется.
Если не гарантирует, то значит программу нельзя запускать одновременно с теми, которые требуют гарантии недоступа.
S>>Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти.
PD>И на каждую программу ставится клеймо, а в ОС вводим 2 режима и переключаемся между ними для того, чтобы запустить какую-то программу, которая текущему режиму не соответствует
Это не два режима, это чуть по-другому работающий шедулер. Все равно его с нуля писать.
Здравствуйте, samius, Вы писали:
S>Гибрид необязателен. Берем C++ и верификатор. Я не призываю его брать после пропажи всего софта, я просто показываю что выбор не ограничен двумя пунктами.
Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
S>Если не гарантирует, то значит программу нельзя запускать одновременно с теми, которые требуют гарантии недоступа. S>>>Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти. PD>>И на каждую программу ставится клеймо, а в ОС вводим 2 режима и переключаемся между ними для того, чтобы запустить какую-то программу, которая текущему режиму не соответствует S>Это не два режима, это чуть по-другому работающий шедулер. Все равно его с нуля писать.
Вот тут не понял. Писать с нуля, конечно, придется. Но в итоге хочу я одновременно иметь 2 работающих приложения. И вариант, что мы с одного на другое переключаемся так, что когда одно работает, другое работать не имеет права, не принимается — это уже не многопрограммный режим, а бог знает что. Одно приложение с недоказанной корректностью обращений к памяти (какой-то фоновый процесс, которому часами работать надо), другое — нужна гарантия недоступности их памяти. И что делать ?
Здравствуйте, WolfHound, Вы писали:
WH>·>Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например? WH>Такое быть не может.
Угу, конечно. Ошибок в доказательстве быть не может.
Запросто может быть что угодно, причем доказать доказательство будет на порядки сложнее, чем обычный код.
WH>Можешь поиграть с онлайн компилятором: https://rise4fun.com/Dafny/pX4N
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
Ну так а в чем разница с дырой в процессоре?
Одна дыра — и мало не покажется, не заштопаешь. Процессор уже на компьютере пользователя, этап разработки и производства процессора позади, иной защиты нет, не поправишь, как Meltdown.
Здравствуйте, Sharov, Вы писали:
WH>>Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее. S>Не вижу проблемы, учитывая что реально новый процессоры появляются раз в 10,а то и 20 лет.
Так я и говорю, что проблемы не будет если убрать нативный код.
Не пойму ты со мной споришь или соглашаешься.
S>Если не ошибаюсь, Итаниум сдох не дойдя до народа -- для него крайне сложно оказалось написать хороший компилятор.
Компилятор дело техники. Если нет нативного кода, то его нужно написать один раз. И интел в конце концов написал.
А вот то что он тормозил в 10 раз на исполнении x86'ого кода его и убило.
Emulation to run existing x86 applications and operating systems was particularly poor, with one benchmark in 2001 reporting that it was equivalent at best to a 100 MHz Pentium in this mode (1.1 GHz Pentiums were on the market at that time).
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
