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

DG>другие разработки, например, ПО для самолета C-130 делается на языке Spark (это расширение Ada-ы со статическим контролем pre/post-условий)

И как тебе pre/post условия помогают понять какие варианты надо рассмотреть? Как, к примеру, они помогают понять какие варианты надо рассмотреть для контроля расписаний?

DG>базовые операции a+b, if, for и т.д. считаются верными на фиксированном классе значений, а дальше вперед:
DG>для каждого куска кода фиксируется pre/post-условия, инвариант.

Что это дает-то? Что ты вообще собрался доказывать для функции контроля расписания? Соответствие ответа чему?

DG>при использовании динамического программирования — доказательство элементарное.
DG>этим способом, например, легко доказать верность алгоритма сортировки прямого выбора.

Ну да, потратив кучу времени таким способом можно доказать какую-нибудь примитивную ерунду, которая и так очевидна.

DG>ты хоть чуть-чуть теорию программирование ботал? не практику, а именно теорию.
DG>хотя бы кнута, таха и т.д. — а у них там сплошные доказательства правильности работы алгоритма.

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

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

DG>>базовые операции a+b, if, for и т.д. считаются верными на фиксированном классе значений, а дальше вперед:
DG>>для каждого куска кода фиксируется pre/post-условия, инвариант.

U>Что это дает-то? Что ты вообще собрался доказывать для функции контроля расписания? Соответствие ответа чему?

Если ответ ничему не должен соответствовать, то нафик он нужен?
return 42;
и все счастливы.

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

L>Угу! Потому что с объектами на Ocaml и F# работают столь же активно, как и на ОО-языках, я прав? А на C# и VB.NET в функциональном стиле разработка ведётся как минимум для большей части методов. Т.е. разработка на этих языках ведётся как ты описал — "абстракциях верхноего уровня — ООП, реализация — ФП + где надо ИП". Или всё таки эти слова применимы только к гибридным языкам?

Тут проблема в том, что ФП можно понимать очень сильно по-разному. То, что сейчас действительно происходит в мейнстриме — это на мой взгляд взгляд не популяризация ФП как такового, а популяризация ряда приемов, паттернов из ФП, отдельных концепций. Можно сказать проще — такие императивные языки как C#, VB.NET и иже с ними как были, так и остаются по сути глубоко императивными, просто в них добавили "фишек".

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

Я лично не видел кода, который успешно совмещал бы ООП и ФП, т.е. реальное ООП и реальное ФП. Да и, честно говоря, я вообще не представляю, как это должно выглядеть. Принцип "снаружи ООП, а внутри методов — ФП", который тут рекламируется, это по-моему какой-то бред. Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.

Это опять же лишнее подтверждение тому, что ФП ассоциируется лишь с какими-то конкретными фишками, который в действительности имеют слабое отношение к ФП.

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

K>>А что мощнее — возможность проводить корректные операции или отсутствие возможности проводить корректные операции?

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

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

DG>что такое "второе мощнее первого"?

Означает, что то что описано в пункте 2) мощнее того, что описано в пункте 1)

K>>На что заменять, если все компиляторы плохие?
DG>на менее плохой (либо на комбинацию плохих — которая в сумме менее плохая, чем каждый по отдельности).

И как вы сумму посчитаете?

K>>Неэффективное по каким критериям?
DG>по всем с точностью до парето-фронта

Еще раз, чтоб говорить о какой-то точности нужно и критерии задавать точно. И измерять характеристики точно. Как вы будете, например, агрегировать время работы программы в тиках, используемую память в байтах/тик и затраченый труд программистов в долларах/мес.?

K>>Ну приведите пример: язык, разработчик, "сокрытие возможности доступа", обоснование.

DG>1. assembler->маш.код, разработчик каждого ассемблера, отсутствие возможности влиять на трансляцию, преобразование эквивалентное и там нечего менять.

Это вообще не язык, раз преобразование эквивалентное.

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

Какого процессора?

K>>Для кого вредная? Если разработчик что-то инкапсулирует — это развязывает ему руки, позволяя что-то менять за "стенами" инкапсуляции и это облегчает для него соблюдения каких-то инвариантов.
DG>для определенного круга пользователей

Для пользователей это тоже полезно. Когда разработчик меняет что-то по ту сторону инкапсуляции код пользователя не ломается.

DG>(и кстати отсутствием лишних инкапсуляций обосновывается преимущество open-source над closed-source).

Умопомрачительно.

DG>т.е. разработчик не уверен, что его решение после выпуска идеальное

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

DG>и хочет его менять параллельно с тем, как другие его используют?

Да какая разница, хочет он этого или нет? Факт, что ему придется так делать.

DG>а если оно идеальное, то зачем он его хочет переписывать?

А если программист — фея, то зачем что-то писать/переписывать? Взмах волшебной палочкой — и все довольны без всякого программирования.

DG>введение инкапсуляции всегда ухудшает параметр гибкость.

Да вы что? Инкапсуляция, а точнее абстракция вводится для увеличения гибкости. Код без изоляции частей друг от друга не обладает гибкостью вообще.

DG>поэтому да с точки зрения гибкости инкапсуляция это всегда плохо.

Наоборот.

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

Наоборот, можно. И благодаря нормальной инкапсуляции и абстракции.

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

И потерять возможность заменить массив в памяти на другую структуру!

K>>Что означают словосочетания "язык уровня компиляции" и "runtime уровня компиляции"?
DG>язык уровня компиляции — понятия которого существуют только на уровне компиляции, и не существуют при выполнении.

Т.е. любой компилируемый язык?

DG>runtime уровня компиляции — исполняемый код, который работает только на уровне компиляции, и отсутствует на этапе выполнения.

Это называется компайл-тайм вычисления. А рантайм компайлтайма — это оксюморон.

DG>простейшим примером первого и второго является допустим язык макросов в C и макро-процессор в C

Язык макро-препроцессора и C — разные языки. Первым вы можете хоть Хаскель препроцессить. Какой смысл их смешивать в один язык? Чтоб получать словесных монстров вроде "runtime уровня компиляции"?

DG>более сложным примером является исполняемый код, который выводит тип результата. языком для этого исполнителя(runtime-а) — будет система значков, которая упрощает вывод типа результата.

Ничего не понимаю. Речь идет о, например, JIT динамического языка с выводом типа и специальных аннотациях, расширяющих динамический язык и делающий этот вывод возможным?

DG>чего? что такое "А"?

Что угодно.

DG>а вообще это фиксируется сплошь и рядом.

Или не фиксируется. Вот представьте, что вы знаете, как зафиксировать A на языке B. Но фиксация потребует миллиард строк на языке B и ~100000 человекомесяцев. Зафиксируете?

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

U>Что это дает-то? Что ты вообще собрался доказывать для функции контроля расписания? Соответствие ответа чему?
S>Если ответ ничему не должен соответствовать, то нафик он нужен?

Ответ должен соответствовать представлениям диспетчеров о прохождении расписании и здравому смыслу. Соответственно для каждого конкретного случая диспетчер может разъяснить каким должен быть ответ. И как ты будешь доказывать соответствие ответа представлениям диспетчера и здравому смыслу?

Есть задачи, в которых проверка ответа на правильность проще, чем само решение задачи (например, сортировка), в таких задачах математическое доказательство иногда применимо. А есть задачи, в которых проверка ответа на правильность сравнима по сложности с решением самой задачи, вот в таких задачах от математических доказательств толку ноль.

S>return 42;
S>и все счастливы.

Ответ 42 противоречит и представлениям диспетчеров и здравому смыслу, соответственно никто не счастлив.

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

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

U>>Что это дает-то? Что ты вообще собрался доказывать для функции контроля расписания? Соответствие ответа чему?
S>>Если ответ ничему не должен соответствовать, то нафик он нужен?

U>Ответ должен соответствовать представлениям диспетчеров о прохождении расписании и здравому смыслу. Соответственно для каждого конкретного случая диспетчер может разъяснить каким должен быть ответ.
Хорошо, что хоть нашли, чему должен ответ соответствовать.

U>И как ты будешь доказывать соответствие ответа представлениям диспетчера и здравому смыслу?
Как — это уже отдельный вопрос. Но важно то, что доказанно соответствующий ответ гораздо ценнее, чем любой другой, в том числе соответствующий практически. Особенно для диспетчеров.
Если за диспетчерские ошибки "сушить" будут программистов, я думаю, что ты со мной согласишься.

U>Ответ 42 противоречит и представлениям диспетчеров и здравому смыслу, соответственно никто не счастлив.
странно что не соответствует сюда сюда

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

кто сказал — что это разделение было единственно верным, и откуда следует что нельзя провести другое разделение на контексты?

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

K>>>На что заменять, если все компиляторы плохие?
DG>>на менее плохой (либо на комбинацию плохих — которая в сумме менее плохая, чем каждый по отдельности).

K>И как вы сумму посчитаете?

с помощью функции newsystem sum(system1/part4, system2/part2)

K>Еще раз, чтоб говорить о какой-то точности нужно и критерии задавать точно. И измерять характеристики точно. Как вы будете, например, агрегировать время работы программы в тиках, используемую память в байтах/тик и затраченый труд программистов в долларах/мес.?

из использованим парето следует, что нет необходимости считать абсолютные величины, достаточно уметь сравнивать — что вот в этом случае затраты будут больше, чем в этом случае, в этом наоборот.
а операции сравнения для оценки в тиках, в байтах и программистах вводятся достаточно легко.
хотя бы что: F(A+B) > F(A) и F(A+B) > F(B)

K>Это вообще не язык, раз преобразование эквивалентное.

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

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

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

K>Какого процессора?

любого регистрового процессора со следующими ограничениями:
а) для языков с фиксированной размерностью типа number(и его аналогов) такой процессоров должен соблюдать правило, что в байте 8 бит, а word-ы и более состоят из byte-ов.
b) для языков с нефиксированной размерностью — достаточно ограничения, что размерность регистров достаточен для хранения размерности типа данных используемого в программе.

K>Для пользователей это тоже полезно. Когда разработчик меняет что-то по ту сторону инкапсуляции код пользователя не ломается.

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


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

дальше у тебя пошли сплошные эмоции.
обоснуй почему программа не может быть идеальной?


K>>>Что означают словосочетания "язык уровня компиляции" и "runtime уровня компиляции"?
DG>>язык уровня компиляции — понятия которого существуют только на уровне компиляции, и не существуют при выполнении.

K>Т.е. любой компилируемый язык?

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

соответственно язык шаблонов — это чисто "язык уровня компиляции".

DG>>runtime уровня компиляции — исполняемый код, который работает только на уровне компиляции, и отсутствует на этапе выполнения.

K>Это называется компайл-тайм вычисления. А рантайм компайлтайма — это оксюморон.

и тот же препроцессор входит в понятие компайл-тайм вычисления?

DG>>простейшим примером первого и второго является допустим язык макросов в C и макро-процессор в C

K>Язык макро-препроцессора и C — разные языки. Первым вы можете хоть Хаскель препроцессить. Какой смысл их смешивать в один язык? Чтоб получать словесных монстров вроде "runtime уровня компиляции"?

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

DG>>а вообще это фиксируется сплошь и рядом.

K>Или не фиксируется. Вот представьте, что вы знаете, как зафиксировать A на языке B. Но фиксация потребует миллиард строк на языке B и ~100000 человекомесяцев. Зафиксируете?

и что этот пример доказывает?

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

U>Ответ должен соответствовать представлениям диспетчеров о прохождении расписании и здравому смыслу. Соответственно для каждого конкретного случая диспетчер может разъяснить каким должен быть ответ.

здравый смысл формализуется, и сводится в полную непротиворечивую систему.

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

и соответственно для каждого варианта входной последовательности тебе либо необходимо зафиксировать валидность такой последовательности
(и это у тебя пред-условие)

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

зы
и как я уже говорил, та же система тестов строится этим же путем

U> И как ты будешь доказывать соответствие ответа представлениям диспетчера и здравому смыслу?

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

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

K>>Я говорил о разрушении контекста, в котором возможно проводить только корректные операции. Получая доступ на нижний уровень мы портим разделение на контексты, установленное верхним уровнем.
DG>кто сказал — что это разделение было единственно верным, и откуда следует что нельзя провести другое разделение на контексты?

Ниоткуда не следует. Берите и проводите другие. Но это деалется на верхнем уровне — на нижнем нечего проводить — там нет средств проведения.

DG>ты кстати вообще понимаешь, что инкапсуляция делается только из-за того, что разработчик не всё записывает в коде, а большую часть знаний о работе кода оставляет у себя в голове?

Вообще, я понимаю, что это ваше утверждение не соотвествует действительности.

K>>>>На что заменять, если все компиляторы плохие?
DG>>>на менее плохой (либо на комбинацию плохих — которая в сумме менее плохая, чем каждый по отдельности).
K>>И как вы сумму посчитаете?
DG>с помощью функции newsystem sum(system1/part4, system2/part2)

Ну конечно. Приведите пример расчета для любой пары компиляторов и сравните с оценкой для любого одного.

K>>Еще раз, чтоб говорить о какой-то точности нужно и критерии задавать точно. И измерять характеристики точно. Как вы будете, например, агрегировать время работы программы в тиках, используемую память в байтах/тик и затраченый труд программистов в долларах/мес.?
DG>из использованим парето следует, что нет необходимости считать абсолютные величины, достаточно уметь сравнивать — что вот в этом случае затраты будут больше, чем в этом случае, в этом наоборот.
DG>а операции сравнения для оценки в тиках, в байтах и программистах вводятся достаточно легко.
DG>хотя бы что: F(A+B) > F(A) и F(A+B) > F(B)

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

K>>Это вообще не язык, раз преобразование эквивалентное.
DG>обоснуй, пожалуйста, утверждение, что если преобразование эквивалентное, то языка — нет.

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

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

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

DG>>>2. почти все языки,, сокрытие возможности менять встроенные типы, они один в один ложатся на регистры процессора и с точки зрения эффективности выполнения менять по большому счету нечего.
K>>Какого процессора?
DG>любого регистрового процессора со следующими ограничениями:
DG>а) для языков с фиксированной размерностью типа number(и его аналогов) такой процессоров должен соблюдать правило, что в байте 8 бит, а word-ы и более состоят из byte-ов.
DG>b) для языков с нефиксированной размерностью — достаточно ограничения, что размерность регистров достаточен для хранения размерности типа данных используемого в программе.

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

K>>Для пользователей это тоже полезно. Когда разработчик меняет что-то по ту сторону инкапсуляции код пользователя не ломается.
DG>это можно гарантировать и еще миллионом способов. инкапсуляция с точки зрения гибкости и эффективности — худший из них.

Хотелось бы увидеть пару примеров более хороших способов.

DG>обоснуй почему программа не может быть идеальной?

Дайте сначала определение идеальной программы.

DG>я утверждаю, что это различные движки управляемые разными языками.
DG>и движки — которые делает вывод типов, определение размера типа, паттерн-матчинга, шаблонов и т.д. — это все разные движки, каждый из которых управляется своим языком (который является подмножеством языка программирования, как мы его понимаем)

Такое разделение — это чистая условность. Если нам удобно рассматривать что-то как встроенный язык — можем рассматривать. Если нам это ничего не дает — можем не рассматривать.

DG>и что этот пример доказывает?

Этот пример иллюстрирует разницу между уметь и мочь.

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

Привести несколько подтвеждающих такие заявления цитат сможете?

DG>>ты кстати вообще понимаешь, что инкапсуляция делается только из-за того, что разработчик не всё записывает в коде, а большую часть знаний о работе кода оставляет у себя в голове?

K>Вообще, я понимаю, что это ваше утверждение не соотвествует действительности.

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

где ошибка в данных выводах?

K>Ну понятно, пока нужно определять что лучше — быть богатым и здоровым или бедным и больным все просто. Когда понадобится сравнить что лучше быть бедным и здоровым или богатым и больным, например, уже начнутся сложности.

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


K>>>Это вообще не язык, раз преобразование эквивалентное.
DG>>обоснуй, пожалуйста, утверждение, что если преобразование эквивалентное, то языка — нет.

K>Тут я, конечно, рассуждал неверно. Во-первых, я перепутал эквивалентное с тривиальным. Это не язык, разумеется, не потому, что преобразование эквивалентное, а потому что оно тривиальное. А во-вторых, тривиальность преобразования не гарантирует нам наибольшую эффективность. Можно получить более эффективную программу если не транслировать тривиально, а производить некоторые трансформации-оптимизации. Т.е. утверждение о том, что "менять там нечего" не соотвествует действительности. Менять там можно много чего и процессор может производить нетривиальные трансформации кода в свое внутреннее представление и выполнять уже другую оптимизированную команду. При этом доступ к своему внутреннему транслятору процессор, как правило, ограничивает.
K>Пример с ассемблером, таким образом, отметается — максимальная эффективность там при преобразовании не гарантируется.

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

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

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

причем есть важное отличие: разработчик при "исполнении" кода оперирует классами элементов, а не самими элементами.
и соответственно в том числе, может за секунду "исполнить" и бесконечные циклы определенных видов (например, следующий цикл for(int x=0;){x++;})

K>>>Для пользователей это тоже полезно. Когда разработчик меняет что-то по ту сторону инкапсуляции код пользователя не ломается.
DG>>это можно гарантировать и еще миллионом способов. инкапсуляция с точки зрения гибкости и эффективности — худший из них.

K>Хотелось бы увидеть пару примеров более хороших способов.

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

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

K>Привести несколько подтвеждающих такие заявления цитат сможете?

даже в этом сообщении — (если позволяться твоей терминологий) ты пишешь в основном "тривиальные" вещи (из которых ничего нового не следует):

K>Вообще, я понимаю, что это ваше утверждение не соотвествует действительности.

K>Ну конечно. Приведите пример расчета для любой пары компиляторов и сравните с оценкой для любого одного.

K>Такое разделение — это чистая условность. Если нам удобно рассматривать что-то как встроенный язык — можем рассматривать. Если нам это ничего не дает — можем не рассматривать.

K>Этот пример иллюстрирует разницу между уметь и мочь.

K>Ну понятно, пока нужно определять что лучше — быть богатым и здоровым или бедным и больным все просто. Когда понадобится сравнить что лучше быть бедным и здоровым или богатым и больным, например, уже начнутся сложности.

не тривиальным было только вот это утверждение

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

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

DG>и соответственно для каждого варианта входной последовательности тебе либо необходимо зафиксировать валидность такой последовательности
DG>(и это у тебя пред-условие)

Что конкретно нужно фиксировать в предусловии контроля расписаний?

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

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

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

Что конкретно должно быть в постусловии контроля расписаний? И чем это постусловие будет отличаться от полного или частичного решения задачи?

DG>зы
DG>и как я уже говорил, та же система тестов строится этим же путем

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

U>> И как ты будешь доказывать соответствие ответа представлениям диспетчера и здравому смыслу?
DG>здесь доказывается — что программа получает результат, который удовлетворяет формальной системе из предыдущего пункта.

Какой формальной системе должен удовлетворять результат контроля расписаний?

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

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

Наоборот. Чтобы изменения в этом скрытом не сломали остальное. Ну и дальше идут не верные выводы.

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

DG>где ошибка в данных выводах?

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

DG>а теперь оцени потери производительности по сравнению с исходной версией на императивном языке (C/C++/Java/CSharp и т.д.)
DG>проблема в том, что если алгоритм не свернуть в более емкую форму родную для данного языка, то потеря производительности может быть на пару порядков.

А сам-то ты, какие проблемы в этом коде видишь? Он вообще должен компилироваться в код, практически идентичный приведенному тобой императивному примеру. А вот Линковое "items.Where(item=>item > 10).ToArray()" таки к потерям неизбежно приведет.

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

DG>зачем делается инкапсуляция? зачем что-то скрывается? чтобы это скрытое не сломали

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

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

инкапсуляция инкапсуляции рознь.

хорошая инкапсуляция — это рекомендация вида: для решения большинства задач достаточно пользоваться интерфейсом вот из этих двух функций, но при необходимости есть еще десять, а может еще залезть под капот — будет 50, а если перейдете на следующий уровень — то и все 375.

плохая инкапсуляция — это запрет. вот вам две функции, а остальное вы не должны хотеть.

банальный пример Stack
Stack — может предоставлять только функции Push/Pop — и это будет достаточно для 80% примений, но всегда остается 20% или 2%, или 0.2% задач, когда нужно большее, например, нужны PushRange/PopRange, RemoveAll, RemoveIf и т.д.

U>И как тебе pre/post условия помогают понять какие варианты надо рассмотреть? Как, к примеру, они помогают понять какие варианты надо рассмотреть для контроля расписаний?

есть такая наука, называется математика — встречал такое слово? и она такую задачу решило еще лет 200-300 назад

это есть задача отображения одного пространства на другое. а программа — это лишь один из способов задания правил отображения.

DG>>базовые операции a+b, if, for и т.д. считаются верными на фиксированном классе значений, а дальше вперед:
DG>>для каждого куска кода фиксируется pre/post-условия, инвариант.

U>Что это дает-то? Что ты вообще собрался доказывать для функции контроля расписания? Соответствие ответа чему?

критерию правильности, который ты должен был, как постановщик задачи, зафиксировать.

не зафиксировал? садись — два. следующий.

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

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

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

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


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

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

соответственно на этапе постановки задачи есть задача выделение общей части задачи.

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

int F(int x)
{
  switch (x)
  {
    case 1:
      return 5;
    case 2:
      return -5;
    case 3:
      return 4;
    case 4:
      return 7;
    case 5:
      return 12;
    case 6:
      return 5;
    case 7:
      return 3;
    case 8:
      return -3;
   //и т.д.
  }
}

КБ>Наоборот. Чтобы изменения в этом скрытом не сломали остальное. Ну и дальше идут не верные выводы.

т.е. разработчик для остального кода — не зафиксировал когда он ломается?

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

U>>И как тебе pre/post условия помогают понять какие варианты надо рассмотреть? Как, к примеру, они помогают понять какие варианты надо рассмотреть для контроля расписаний?
DG>есть такая наука, называется математика — встречал такое слово? и она такую задачу решило еще лет 200-300 назад

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

Так откуда у тебя берется уверенность, что подход математики, не всегда работающий даже в своем мирке, будет работать в куда более сложном реальном мире?

DG>критерию правильности, который ты должен был, как постановщик задачи, зафиксировать.

Ты конкретно можешь сказать, что нужно зафиксировать в задаче контроля расписаний? В чем смысл общими словесами сыпать, если ты даже конкретную задачу не можешь решить?

DG>у тебя на самом деле есть знание, когда алгоритм правильно работает.
DG>и соответственно ты либо его не хочешь фиксировать (и тогда тебе ничем помочь нельзя), либо не умеешь его осозновать и фиксировать.

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

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

Именно по этой причине тесты не могут ничего гарантировать и соответственно не имеют никакого отношения к доказательству правильности кода.

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

DG>хорошая инкапсуляция — это рекомендация вида: для решения большинства задач достаточно пользоваться интерфейсом вот из этих двух функций, но при необходимости есть еще десять, а может еще залезть под капот — будет 50, а если перейдете на следующий уровень — то и все 375.

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

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

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

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