Здравствуйте, Klapaucius, Вы писали:
I>>Надо определиться имеют ли смысл ЯП в отрыве от задач.
K>Никакой инструмент не имеет смысла в отрыве от задач. Проблема в том, что вы не понимаете для каких задач существуют обсуждаемые инструменты. Языки общего назначения — это инструменты для разработки инструментов: библиотек, ДСЛ, других языков общего назначения. Это и есть задача.
Задачи это конкретные действия необходимые человеку для достижения определенной цели. Цель у человека это не написание библиотеки, и даже не обработка данных. Написание библиотеки как задача имеет смысл только в контексте конкретной задачи, анпример обработки видео и тд и тд. Потому твои задачи это просто мусор в обсуждаемом контексте.
>Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
Зайди в форум немерле
K>Выбор языка происходит не под задачу, а так: K>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
ну вот, "можем себе позволить" ты определил через "можем себе позволить"
I>>Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
K>Конечно ухудшает. Как и сам стек. Но, разумеется, не так сильно, как управляемая куча. Озвученным требованиям полностью отвечает только статическое распределение памяти. Как в раннем фортране. K>Короче говоря, вы даже не попытались обосновать нужность (которую я и просил обосновывать) передачи функции вниз. Вы только попытались обосновать ее безвредность. Но и это не удалось. При этом вы сами обосновывали это не в своей парадигме "языка под задачу" а в моей "берем лучшее из того, что можем себе позволить на данном этапе".
Передача вниз нужна для упрощения связывания Передача вверх нужна для этого же Разница между ними в том передача вниз безвредна для управления ресурсами и вычислениями и это вобщем то свойство этой самой передачи как способа использования а не замыканий.
I>>Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.
K>Можно не бороться со свойствами замыканий, а бороться с замыканиями. Про лямбда-лифтинг слышали? Вот только это требует качественной и более затратной при разработке реализации, а не наивной, в которой все замыкания в куче.
Зеваю — лямбда-лифтинг в общем случае не поможет.
I>>Внятно сказано — стек был и до алгола K>Где?
Мне не интересно, я показал тебе слова автора алгола, а ты думай сам.
I>>Напиши хорошую библиотеку на хаскеле с помощью которой можно будет легко и эффективно обрабатывать что нибудь из видео, текст, графику, звук и тд.
K>"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.
То есть, хаскель непригоден для решения таких задач, ЧТД.
I>>Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.
K>Разделение на замыкание и static chain вполне имеет смысл. Это вы сами обосновали выше, сравнивая их. Это необходимые сущности, их введение обосновано.
Я вобщем то и написал что это одно и то же. А то что свойства различные если по разному использовать — так это и ежу понятно, то есть разница в свойствах операций а не самих замыканий. Операции — передача ввехр или вниз.
I>>Пустой контекст это просто конкретный случай а не новое понятие.
K>Новое понятие, которое вы вводите, для объединения замыкания с "не замыканием" — действие не только бесполезное, но и вредное, согласно вашему же обоснованию.
Выделеное прочесть не алё ? Эдак у тебя каждое натуральное число станет новым понятием. С таким подходом математику не освоить
Здравствуйте, Klapaucius, Вы писали:
I>>Вместо просты и понятных терминов "предназначен", "пригоден", "соответствует" ты несешь какую то ахинею "не можем себе позволить" и не можешь внятно даже пояснить, что заключается в этом термине
K>Объяснил уже три раза — последний раз здесь
. Зато у вас вечно получаются какие-то задачи вроде "алгоритмических" и "обработки данных" под которые подвести можно все что угодно, при наличи достаточного числа "пустых контекстов".
По ссылке у тебя определение "что можем себе позволить" через "что можем себе позволить" Если ничего другого у тебя нет, можно и закругляться.
I>>в отличие от задач обработки данных
K>Не понятно, в чем отличие.
Для этой области важны нефункциональные требования + инструмент для работы с гигантскими приложениями, потому как старые требования что характерно никуда не бывают. С вычислительными задачами можно спокойно выбросить бОльшую часть кода если найдено хорошее решение которое закрывает общий случае. Здесь все операции растут из эвристик "давайте здесь прибавим, а здесь отнимем, а тут сделаем как там".
K>Насчет "в хлам" — это сомнительно, но думаю, что C# на CLR порвет, а C# на Mono — наоборот, глотнет пыли на обочине. Идея ясна?
Нет, не ясно зачем ты смешиваешь в кучу все подряд. Берешь самую лучшую реализацию платформы и сравниваешь. А в твоем случае получится результат "хорошее лучше плохого".
I>>Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.
K>Пригодность реализации. До сравнения языков дело вообще не доходит.
Сравнение языков во все времена было сравнением текущих на момент сравнения реализаций. Я вообще думал это очевидно. Сами языки в чистом виде сравнивать нет смысла в принципе.
Приведи хороший пример как можно сравнить языки в отрыве от задач, т.е. язык против языка.
Компактность реализации как аргумент использовать нельзя ибо "черз 1000 лет вот н там будет убер-ФП за счет убер-адского мега-супер-ГЦ".
Валяй, пример сравнения в студию.
I>>Пока пишут, и доля С++ в этих областях сокращается.
K>Как же так? Ведь в вашей теории: K>1) Один язык не может занимать несколько областей. Одна область — один идеально подходящий для нее язык.
Нету этого в моей теории. Более того, из примеров что я привел ясно следует несколько областей.
K>2) Доля в области не может сократится. Язык — это ответ на появление новой области и пока существует область ее будет занимать один и тот же язык.
И этого в моей теории нет. Более того, я говорил и объяснял на примере того же С++.
K>Вы эти следствия своей теории понимаете? В реальности их наблюдаете?
В итоге ты сам с собой чего то споришь.
I>>Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.
K>Я знал! Я знал! K>
K>Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?
А чего тут спорить ? марсоход нужен для сбора данных и больше ни для чего. Посмотри по ветку выше, где я упомянул "сбор данных".
I>>С++ распространился в ответ на растущую сложность программ + сохранил все ниши что были за С.
K>Сохранил не все, но это не существенно. Существенно то, что более продвинутый язык распространяющийся в ответ на растущую сложность — это почти моя теория, но наоборот.
"почти моя теория, но наоборот" — это сильно. Как это понять ?
>На самом деле это сложность может вырасти, когда появляется язык, который с этой сложностью справится.
Если у человека есть цели для которых нужны задачи такой сложности и язык пригоден для этих задач, то естественно появятся решения задач такой сложности.
K>В вашей теории язык появляется в ответ на задачу, для которой он иделаьно подходит. О каком распространении идет речь?
Ты похоже не можешь запомнить простые вещи. Вместо того, что бы переспросить ты начинаешь строить предположения основаные на твоих трактовках
>Есть задача — есть распространение. нет задачи — нет распространения.
Правильно, нет задачи нет и распространения. У С++ все в порядке. только у меня язык не обязательно должен появляться в ответ на задау. Это местные немерлисты хотят видеть по дсл на каждую задачу.
I>>Чисто экономические причины. Думаю вместо лиспа мог бы быть какой угодно язык, в т.ч. С++. Яха купил фактически пользовательскую базу, то есть бизнес, а сам язык никого не интересует, абы работало.
K>Если бы язык не интересовал — все бы оставили как есть. Но ведь переписали — потому, что язык интересовал. Только Грема один, а Яху — другой.
Потому что у яхи есть несколько тысяч инженеров + свои наработки в этой области + инфраструктура. Подумали да и забили на лисп.
I>>То есть, даже единичное использование означает что "задачи решали на С" ?
K>Куда больше, чем просто единичное. Куда деваться-то если "других языков у меня для вас нет"? Единичное использование для практически всех ниш — такое почти для каждого языка можно найти.
Нужно рассматривать ниши в которых язык является доминирующим. Будь такое с языкаом Си то и спора не было.
K>>>Во-первых, я говорил про ФЯ, а не гибриды. I>>Тут можно и заканчивать, ибо нет ни одного языка не-гибрида
K>Ладно, под "гибридом" я имею в виду то, что обычно тут имеют в виду — императивный язык с несколькими функциональными финтифлюшками. Когда я говорил ФЯ в этой ветке я подразумевал полноценную поддержку ФП.
Я честно говоря не знаю, какие ФЯ ты считаешь имеющими полноценную поддержку ФП
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, icWasya, Вы писали:
I>>>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.
W>>Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было
I>Почти. Вниз все работает: I>
I>program test;
I>uses crt;
I>type
I> MegaProc = procedure(s:string);
I> procedure Main;
I> procedure Suxx(p:Pointer);
I> var proc:MegaProc;
I> begin
I> proc := MegaProc(p);
I> proc('hello world');
I> end;
I> procedure Print(s:string);far;
I> begin
I> WriteLn(s);
I> end;
I> begin
I> Suxx(@Print); {вызываем вложеную и передем как параметр вложуную}
I> end;
I> begin
I> Main;
I>end.
I>
Ну ваша процедура Print не использует накаких переменных, которые локальны для Main и глобальны для Print.
С таким же успехом она могла быть описана и вне Main.
Здравствуйте, icWasya, Вы писали:
W>Ну ваша процедура Print не использует накаких переменных, которые локальны для Main и глобальны для Print. W>С таким же успехом она могла быть описана и вне Main.
О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор Что это значит ?
> I>>Это тоже нормально реализуется в ООП > S>Но не в таком ООП, которое приходит в голову наивному проектировщику. Обработка WM_PAINT тысячами WindowProc — это худший способ добиться результата. > > Проектирование глобального рендерера это задача мягко говоря не простая. В WPF микрософт отказались той моджели что WinForms и во многих сценариях перформанс стал ещё хуже.
Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка.
Здравствуйте, grosborn, Вы писали:
G>Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка.
Рендеринг работает быстро только теоретически и никаких "два порядка" там нет и близко, ибо GDI+ рендеринг во многих сценариях тупо даёт лучший эффект.
> G>Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка. > > Рендеринг работает быстро только теоретически и никаких "два порядка" там нет и близко, ибо GDI+ рендеринг во многих сценариях тупо даёт лучший эффект.
Понятно. А ты оказывается читать не умеешь. Досвидания.
Здравствуйте, Ikemefula, Вы писали:
... I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор Что это значит ?
А это примерно как разница между свободной функцией и методом.
У метода есть неявный параметр, в качестве которого передаётся указатель на объект.
Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь.
Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
Здравствуйте, icWasya, Вы писали:
W>А это примерно как разница между свободной функцией и методом. W>У метода есть неявный параметр, в качестве которого передаётся указатель на объект. W>Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь. W>Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст. W>И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
То есть, компилер паскаля умеет захват в самом православном виде ?
> I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор Что это значит ? > > А это примерно как разница между свободной функцией и методом. > У метода есть неявный параметр, в качестве которого передаётся указатель на объект. > Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь. > Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст. > И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
Давай пруфлинк на контекст и указатель на контекст. не помню я там такого.
В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.
Здравствуйте, grosborn, Вы писали:
>> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст. >> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
G>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого. G>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.
Запусти программу из моего примера и объясни эффект.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, grosborn, Вы писали:
>>> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст. >>> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
G>>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого. G>>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.
I>Запусти программу из моего примера и объясни эффект.
Перепишем Ваш пример вот так:
type
MegaProc = procedure(s:string); stdcall;
var
GlobalParam:string;
procedure GlobalPrint(s:string); stdcall;
begin
WriteLn(s,' GlobalParam = ',GlobalParam);
end;
procedure Main;stdcall;
var
LocalParam:String;
procedure Print(s:string);stdcall;
begin
WriteLn(s,' LocalParam = ',LocalParam);
end;
procedure Suxx(p:Pointer);stdcall;
var proc:MegaProc;
begin
proc := MegaProc(p);
Print('Local Ok!'); // 1 вызываем вложеную
GlobalPrint('Global Ok'); // 2 вызываем глобальную
proc('Pointer'); // 3 вызываем по указателюend;
begin
LocalParam:=' Hello World!';
GlobalParam:=' Hello Delphi!';
Print('Main'); // 4
Suxx(@GlobalPrint); // 5 {вызываем вложеную и передем как параметр свободную}
Suxx(@Print); // 6 {вызываем вложеную и передем как параметр вложеную}end;
stdcall — что бы параметры для наглядности передавались через стек.
тогда
в точке 1 генерится такой код
mov eax,[ebp+$0c] // копируем в регистр переданный контекст
push eax // кладётся в стек контекст
push offset('Local Ok!') // кладётся в стек строка
call Print // собственно вызов
pop ecx; // убираем лишний параметр из стека
в точке 2 генерится такой код
pust ofset('Global Ok') // кладётся в стек строка
call GlobalPrint; // собственно вызов
в точке 3 генерится такой код
pust ofset('Pointer') // кладётся в стек строка
mov ebx,[ebp+$08] // кладётся в регистр адрес процедуры
call ebx; // собственно вызов
в точке 4 генерится такой код
push ebp; // кладётся в стек контекст
pust ofset('Local Ok!') // кладётся в стек строка
call Print; // собственно вызов
pop ecx; // убираем лишний параметр из стека
в точке 5 генерится такой код
push ebp // кладётся в стек контекст
pust ofset(GlobalPrint) // кладётся в стек адрес процедуры
call Sucxx; // собственно вызов
pop ecx; // убираем лишний параметр из стека
в точке 6 генерится такой код
push ebp // кладётся в стек контекст
pust ofset(Print) // кладётся в стек адрес процедуры
call Sucxx; // собственно вызов
pop ecx; // убираем лишний параметр из стека
отсюда видим — для вызова функции Print генерируется правильный код в точках 1 и 4
а в точке 3 — в стек НЕ кладётся нужный для процедуры параметр
Когда не ставится stdcall, то некоторые параметры кладутся в регистры,
и это несколько маскирует ошибку.
Функция GlobalPrint вызывается правильно отовсюду.
>> I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор Что это значит ? >> >> А это примерно как разница между свободной функцией и методом. >> У метода есть неявный параметр, в качестве которого передаётся указатель на объект. >> Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь. >> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст. >> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.
G>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого. G>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.
По примеру — в точке вызова Sucxx локального контекста для Print и Succ действительно не существует.
Но функция Main уже вызвана и для неё стек уже выделен.
Если функция Print должна использовать какие-то локальные переменные функции Main,
то для Print эти переменные не локальные(которые адресуются через SP:ebp+offset) и не глобальные (DS:offset)
И что бы Print могла до них добраться, ей нужно как-то передать адрес фрейма стека функции Main.
Здравствуйте, Klapaucius, Вы писали:
K>Никто не изобретает языки, например, для разработки компиляторов,
Я изобретаю. Ибо это гораздо эффективнее чем: K>но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, grosborn, Вы писали:
G>В твоем представлении что-нибудь кроме моделей существует? Или в твоем представлении мы все созерцательные кони в вакууме? Что, никак-никаких-совсем никаких средств воздействия на окружающий мир? Совсем никаких новых сущностей, только отражение "реального мира"?
Необязательно реального. Придумай модель нереального. Все-равно, ты должен будешь для начала придумать ту самую Модель для целей разработки ПО, а потом реализовать ее. Процесс разработки ПО наоборот я даже не могу представить. ))
Просто, коль речь шла о прикладном ПО, то я считаю, что всегда речь идет о моделях реального Мира (с точностью до абстракции) или о нашем представлении о Мире (что одно и то же).
>> G>И не является частью модели. >> Модель всегда работает по неким законам.
G>Ну по крайней мере я умею разделять модели и понятия,
"Понятия" — это алфавит модели. ОК, ты умеешь отделять алфавит от слов. А как же насчет грамматики? )))
Я тебя поправил в том плане, что речь была о связи участников модели и законов, по которым участники модели взаимодействуют. ИМХО, это неразрывные вещи для любой динамической системы: участники + правила игры.
G>отделяю инструментальные средства от объектов их применения. А ты этого не можешь.
В этом отделении нет никакого смысла. Например, какой толк от закона всемирного тяготения без понятия массы тел и самих тел?
Ес-но я отделяю такую цещь как "закон тяготения" от понятия "массы" и от понятия "тел", обладающих "массой". Но в моём понимании Мира перечисленные вещи неразрывно связаны и не имеют смысла один без другого. То бишь, они составляют полноценную "модель" только сообща. Грубо говоря, описание упомянутой модели состоит из 3-х разделов. И какой же из этих 3-х разделов, по-твоему, "инструмент" для остальных двух?
>> По русски можно? G>По русски тут будет три буквы.
Кто из нас не умеет считать:
G>В программировании инструментальных средств — внезапно! — большая часть.
)))
Зря ты искал подвох. Я понял о чем ты, но хотел твоей самоличной перефразировки на нормальный русский, дабы не быть обвиненным в додумывании за оппонента.
Здравствуйте, samius, Вы писали:
V>>Странная у тебя манера ведения пора — половинчатая. Несогласие ты высказал, но я не увидел твоих альтернатив. Как же назвать технику, на которой работают вложенные ф-ии Паскаля? S>Я ее называю "указатель на фрейм стека".
А на самом деле это указатель на фрейм локальных переменных. Ууупс? )))
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.
ВВ>Вообще в Хаскелле кортежи это:
...
Это из-за бедности системы типов. Берут АлгТД с всего одним дискриминатором и пользуют его аргументы как тупл, игнорируя сам дискриминант. В общем, чем-то смахивает на матлаб, где скаларные значения на самом деле матрицы [1,1]. ))
И по-хорошему надо писать так: ВВ>
ВВ>data Pair a b = PairCtor a b
ВВ>data Triple a b c = TripleCtor a b c
ВВ>
ВВ>и т.д. ВВ>А (,) и (,,) — это просто такие конструкторы вместо Pair и Triple. Они, кстати, так и описываются в инстансах.
Веселый у тебя пост получился. Ты решил сдуться сразу по половине вопросов и вместо аргументов ухватился за последнюю соломинку — за "идентичность"? ))
Ню-ню..
[скипнул 50 вопросов "а где идентичность?"]
V>>Двойка тебе еще и по дизайну. Для того медиатор и нужен, чтобы источник информации ничего не знал о получателе. S>Двойку оставь себе. Получателем сообщения отправителя будет медиатор, и медиатор будет отправлять сообщения другим получателям с помощью их идентичностей.
Да двойка опять, се ля ви. Идентичность — это тоже элемент модели, то бишь тоже результат абстрагирования.
Кароч, ликбез: тела в рж могут состоять из разнородных элементов — частиц, те в свою очередь из более мелких и т.д... и даже на сегодня науке ХЗ из чего состоят кварки. Набор тел, в свою очередь, может образовывать некую макросистему. Задача "идентити" в модели — представить экземпляр некоей логической сущности как неделимое понятие, асбтрагировавшись от её устройства. Всё!
Идентити объекта-наблюдателя из нашей модели может соответствовать экземпляр человека или экземпляр датчика положения двери. Посылка сообщения такому экземпляру — это абстракция над всеми процессами, связанными с передачей и получением информации в рж. Ключевое выделил. Да, вся куча сверхсложных процессов по передаче информации в рж в нашей модели выглядит как элеметарная отсылка сообщения некоей неделимой сущности. Но ведь на то она и модель, чтобы сложные вещи выглядели просто, не?
V>>ОК, Геометрическая оптика S>Причем тут идентичность, казалось бы?
При том, что ты уже давно так не юлил. Ты просил про механику происходящего в рж? Получи... Но фигли теперь сувать вопрос про "идентичность" во все абзацы, вопреки собственным же предыдущим рассуждениям? Это уже 80-й лвл по замыливанию темы.
V>>Асбтракция — это естественное для человека понятие, т.к. сам человек склонен мыслить абстрактно, выкидывая ненужные детали. S>Ну т.е. уже переметнулся в мой лагерь и пытаешься меня из него выбить, будто так все и было...
Нет уж, это не твой лагерь. Ты же не понимаешь как модель в технике ООП отображается на рж, дык я тебе терпеливо объясняю. Асбтракция — это ключевой прием любого моделирования. В любой технике, не только в ООП.
V>>Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить? S>Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?
Ес-но юлишь только ты, я готов подробно и терпеливо отвечать на что угодно. Конкретно здесь я тебе на это уже неоднократно возражал: если мы можем повторить все побочные эффекты без бэкдоров, то какая разница, что некий отдельный кусочек твоего кода чист? А вот ты, увы, на это ответить не смог ни разу. Ты лишь способен цепляться за тот факт, кто некая выделенная ф-ия в Хаскеле чиста. И, выждав паузу после очередного неотвеченного возражения, приводишь этот факт опять. Детсад... потому что дальше этого полный ступор в рассуждениях. Разве не видишь перехода от комбинации чистых ф-ий к точно таким же побочным эффектам, как в императиве? Это же простейший переход через трюк ассоциативности. Что здесь сложного? Этот трюк в наверняка используется в любой более-менее большой программе многократно.
V>>Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью. S>Опять подмена тезиса
Да нет подмены. Я вижу непонимание, что такое есть модель. Вот попробуй дать своими словами определение "модели".
Потому как пока что ты изо всех сил пытался на понятие "модель" наложить кучу высосанных из пальца ограничений.
V>>Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально. S>Я не пытался это опровергнуть. Хорош спорить с голосами.
Ес-но пытался, но был пойман.
S>>>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.
V>>Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения? Это уже какой-то полный П. S>Походу ты не знаешь что такое особая форма, раз ты уже спалился с тем что в хаскеле if функцией не записать.
Ты читать не умеешь? Как это в Хаскеле не записать if, если я же тебе и сказал, что в Хаскеле if представима в виде обычной ф-ии из-за ленивости?
И конечно, я могу не знать, что есть "особая форма", бо в лямбда-исчислении такого понятия нет. А термины из некоторых конкретных экспериментальных ЯП меня мало волнуют, сорри.
S>>>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.
V>>Ну побегай, побегай... V>>А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. )) S>Ты пиши, пиши, только смотри чем и что аргументируешь.
Здесь я лишь показывал пример, почему стоит знать как всё работает. Меня уже порядком утомляет твой крен в сторону того, чтобы специально стараться быть как можно более нубом, не имеющим понятия об устройстве и принципах работы используемых инструментов. Плох тот программист, для которого эффективность не аргумент, особенно если речь о том, что эта эффективность не стоит трудозатрат в процессе разработки, а лишь требует минимального понимания механики работы конечного сгенеренного инструментом кода.
S>>>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.
V>>Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому. S>Ты опять что-то придумал за меня. Я не говорил что порядок вычислений не важен. Я утверждаю что он в отношении побочных эффектов не интересен, в отличии от нечистых вычислений.
Т.е. ты опять решил убежать? Но я тебе освежу. Я утверждал, что на if происходит та же механика в ФП, что в процедурном подходе (по фундаметальным причинам). Ты сначала пытался возразить, что не та же (как обычно, все возражение я в духе "неужели???" и смайлов ). А когда не смог доказать, то дважды повторил, что тебе это, оказывается, не интересно. Слабовато это как-то выглядит.
На самом деле прикольно получилось, потому как я вначале рассуждал с т.з. программиста, рассматривая процесс мысленной трассировки работы программы на if, и уж мысленно вообще одно и то же выходит, что в ФП, что в ПП. Но еще и в рантайм, получается ровно то же самое. Прямо сейчас можно подниматься далеко наверх и попытаться искать новые аргменты, что ФП далеко убежало от структурного программирования.
S>>>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.
V>>if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе. S>Нет, не десятое. Чистый statement в СП никому не нужен, ибо единственный эффект от него — счета за электричество.
Ну опять тебе двойка. Курить определение чистоты до просветления.
Вот тебе пример мутабельной ф-ии на С++, которая абсолютно чиста:
int sum(int a, int b, int c) {
a += b;
a += c;
return a;
}
Я уже где-то рядом ловил тебя на том, что ты не понимаешь, что есть чистота вычислений. Собственно, о чем ты тогда спорил?
V>>>>Ну а остальное уже подытоживал: V>>>>
V>>>>чистая ф-ия -> порядок вычисления аргументов не важен, так?
S>>>Чистота функции в общем случае не кореллирует с порядком вычисления аргументов. Т.е. легко показать чистую функцию S>>>, для которой порядок вычисления аргументов будет играть роль.
V>>Я не вижу, чтобы ты это показал для чистого ФП. S>Я показал ложность твоего утверждения.
Еще раз, приведи такой пример, который, по твоим же словам:
легко показать чистую функцию для которой порядок вычисления аргументов будет играть роль.
Вот давай самую обычную ф-ию без всяких особых форм. Увидишь, как глубоки твои заблуждения относительно св-в чистоты вычислений.
S>>>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.
V>>Дык, я и так знаю, что придирание шло исключительно к словам... Просто кривое это придирание... или покажи у меня "побочным эффектом в общеизвестном смысле". V>>Я ж говорю: натуральный звездный час блеснуть эрудицией, не? В общем, кому как, а мне порция фана. S>Это не новость для меня, почему-то многие для блеска эрудиции и фана употребляют общеизвестные термины в каком-то скрытом и одним им известном смысле. Странный фан, как по мне. В итоге стало ясно что ты употребляешь термины невпопад.
Акцент был на том, что это упорядочивание вычислений ОБЯЗАТЕЛЬНО, невзирая на всю чистоту. Поэтому и говорилось, что происходящее при ветвлении в ПП и ФП фактически не отличается (ньюансы мы уже обсуждали, в т.ч. ньюансы во время ленивости). Ты прекрасно вначале уловил акцент и оспаривал именно его в течении нескольких постов, пока не понял свою ошибку. Но теперь пытаешься вернуться к самому началу и пытаться начать цепляться к словам. Поздно, все ходы записаны. Я обещал показать аналогичное происходящее в ФП и ПП? — я показал. Будешь опять здесь юлить — попрошу "помощь зала" рассудить, делов-то. Увидишь во всей красе новую тему со всеми твоими цитатами в хронологическом порядке...
V>>Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо. S>Я не отрицал упорядоченность.
Кто-то вскрыл твой аккаунт и писал от твоего имени?
S>>>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.
V>>Я и не собраюсь. Более того, я же и утверждал, что ООП оформило в одну парадигму некоторые уже реально устоявшиеся в процедурном подходе практики. Но понятие контракта на методы типа в современном его смысле выкристаллизовалось именно в ООП. Это медицинский факт. S>Наверное тебя не затруднит привести пруф медицинского факта.
Легко. Курить историю IDL-языков.
Кстате, для начала даже саму аббревиатуру. ))
S>>>>>Что за "экземпляр" монады? V>>>>Это такой функциональный объект. S>>>Что за функциональный объект?
V>>Это пара { ф-ия, контекст }. S>Выглядит как замыкание
Правильно. Но объект выглядит так же, ваш КО. И если ф-ии общие на всех, то контексту присуще понятие экземпляра. Как раз хаскелевские монады таким образом организуют вычисления, что передаваемое от вычисления к вычислению новое состояние контекста можно смело рассматривать как один и тот же экземпляр изменяемого контекста.
S>>>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать. V>>>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли? S>>>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.
V>>Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления. S>Значит опять невпопад.
Значит проблема с восприятием информации.
S>>>Если ты поставил себе цель воплотить все необходимые побочные эффекты в конечной программе, то на что ты жалуешься? V>>Опять, кто тебя спросит? Никто не задается целью воплотить специально, ес-но. Проблемы всегда из-за того, что там, где можно наплодить граблей специально, можно точно так же неспециально. S>Лично для меня неспециально плодить грабли в грязном коде куда проще.
О! Таки перешел уже от утверждения абсолюта к обсужденю оттенков?
Молодец. Не прошло и сотни постов.
А я именно с этого начал.
Ну что, по новой с новым пониманием? Или ты и сам теперь можешь понять то, что я писал выше?
V>>Дык, это я же тебе и говорю, что тебя боле интересуют догмы. А меня интересует исключительно кач-во конечной программы. Поэтому я закоренелый циник. Мне все ср-ва хороши, если они работают. S>Работают практически все средства. Но не все одинаково хороши. Во всяком случае для меня.
Про компроммисы в ФП я уже устал писать. Пока что в реально существующем ФП всё скорее плохо, чем хорошо. Не знаю, что там для себя ты увидел... Как велосипед для ума — ну ОК, одобряю. Как практически применимую вещь — только в виде инструмента написания некоммерческих утилит. И то не всех, бо даже утилиты разные бывают. В общем, только для кода, к которому нефункциональные требования отсутствуют как класс.
V>>Да понимаешь... В современных высокоуровневых программах такая эмуляция может происходить взаимно-многократно через многие слои либ... независимо от твоего желания. Именно поэтому в программах на Хаскеле программисты точно так же допускают кучу ошибок, которые приводят к ошибкам в том самом побочном эффекте, который целевой у всех программ. В общем, ты правильно говоришь насчет того, что "код эмулятора чист". Да, некий кусочек кода может быть чист. S>От, опять. Покажи нечистый кусочек кода-то, наконец.
V>>Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...
S>Это не цинизм, это банальности. Извини, но мысли вроде "все равно ошибки будут" и "все программы грязны" немногого стоят.
Не надо меня упрощать. Я претендовал на то, что у меня есть некая статистика по ошибкам из очень многих проектов. Так вот, доля ошибок по причине приписываемых императиву ужасов настолько ничтожна в общей массе вылавливаемых ошибок, что их обсуждение попахивает откровенным нубством на проф-форуме. А как усиление комичности ситуации выступает тот высмеиваемый мною факт, что ФП некоторыми преподносится как панацея. А какая это может быть панацея от логических ошибок, совершаемых программистом? Да никакая. Когда-то я тщательно спорил с thesz именно вокруг этой темы, а он, скажем прямо, намного более сильный функциональщик, чем многие из моих нынешних оппонентов из ФП лагеря на рсдн. И этим "оппонентам" я уже устал повторять, что не надо вестись как дети на фразы, что мол "чистый код декларативен". Это условности, это недоступные разработчику плюшки, а лишь сугубо св-во досутпных компилятору преобразований... бо реально в современном ФП необходимо описывать ту же степень подробности решения, что и в императиве (ООП). И как раз из-за равенства уровней описания обе техники провоцируют равное кол-во ошибок в реальных проектах с точностью до несущественных погрешностей. Вот и всё кино. Остальное — не более чем религия и дань моде.
Рядом я обсуждал, что именно было бы неплохо добавить в императивный ЯП, чтобы делать меньше тех самых ошибок. Я предлагал для С++ аналог pure из D. И заметь, что ФП в данном случае вообще никаким боком, бо функция/метод может быть чистым, он даже может изменять внешние (поданные по ссылке) данные, но при этом быть абсолютно pure. То бишь, легким движением руки я показывал, как можно преодолевать все "ужасы" императива, не плятя при этом высокую цену в виде ограничений, присущих "чистому ФП".
> Да, вся куча сверхсложных процессов по передаче информации в рж в нашей модели выглядит как элеметарная отсылка сообщения некоей неделимой сущности. Но ведь на то она и модель, чтобы сложные вещи выглядели просто, не?
Вот-вот-ага-ага, удаляем гланды через ж Я немного в цепи рассуждений потерялся, это вы все еще проектируете проверку bool Дверь.Открыта() ?
Передача вверх нужна для этого же 
Что это значит ?
