Re[38]: Оберон круче всех! - Философия программирования

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

M>Так. Так ты про «мы ускакали на много лет вперед» или «мы унылый язык, который ничем от других не отличается, и, по сути, даром никому не нужен»?

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

V>>Если встроено в язык/платформу, да еще с GC, то это примерно тоже самое, что "самое ожидаемое" сегодня для дотнета. Асинхронность с GC и без GC это две большие разницы.
M>Да нифига там не встроено нормально. Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

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

M>И да, я все езе жду ссылку на «интересные рассказы про Оберон, показывающие его преимущество и прогрессивность по сравнению с другими языками» на РСДН.

А я обещал? Я выразил реверанс относительно идеологии языка, сравнительно с вектором развития современных популярных языков, заметив, что некоторые идеологии приходят в мейнстрим позже Оберона. Существует мнение, что Джаву во многом слизали с Оберона, но не принципиально... Хотя со стороны очень похоже. )))

Не заметил, что обсуждается прошлое время? То, что язык не развивается (развивается медленно) последние несколько лет — это известный факт. У него же нет такого "двигателя" как у дотнета. Например, если сравнить дотнет на момент его выхода, то унылее Г еще поискать. Это аргумент в сегодняшнем споре?

Я ответил на самом деле от того, что хамовитый товарищ гонит недалекую пургу насчет "О современном состоянии в разработке ПО". Современное состояния разработки ПО таково, что всерьез стоит рассматривать только мейнстрим, а в этом мейнстриме только последние несколько лет активно воплощаются идеи, которые уже лет 20 как были обкатаны на других языках, в т.ч. на Обероне. Ну и то, что автор прототипа турбо-Паскаля, а затем языка-платформы Дельфи разрабатывал язык C#, саму идеологию построения метаинформации и т.д. — это известный факт. Т.е. влияние исходных виртовских идей организации модульного/компонентного ПО на современное состояние дел в мейнстриме де-факто определяющее. Всё остальное — это лишь градации по степени имплементации деталей.

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

G>Так ты что, хочешь сказать, что не натуральный хам?

Небезобидный человек не значит хам.

G>То есть это адаптация к стилю общения?

Не в вакууме живём.

G>А как же ситуации, когда ты хамство начинаешь?

Я тут скоро 10 лет как, найди на этом сайте хоть одну такую ситуацию.

G>А вот было где-то что дескать привязку на рассыпухе делали и никто это не считал сложным делом (что само по себе неверное утверждение), а кто не согласен с моим мнением, тот дурак?

Была демагогия насчет общего кол-ва вентилей. На основе этой демагогии было загибание пальцев и попытка принизить собеседника. Если бы читал ветку сначала, то увидел, что пришлось доказывать демагогичность этого приёма, т.е. оправдываться что сам не дурак. Разговор вначале проходил довольно ровно... ровно до тех пор, пока собеседник не решил начать кидать понты. Далее без проблем пошло в предложенном им стиле общения...

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

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

C>>>В Обероне нет:
C>>>1) Алгебраических типов и Pattern Matching
V>>Ничего не перепутал? Сможешь показать, в каких популярных императивных языках оно есть?
C>Мы говорим о передовом крае развития IT.

C>Из популярных языков — Скала.

Скала сидит на готовом фреймворке.

C>>>2) Generic'ов — нельзя даже сделать банальный типобезопасный map.
V>>Генериков в той же Джаве лет 10 не было... а сейчас это кривой кодогенератор, который можно натянуть на любой язык при желании.
C>Мы говорим о передовом крае развития IT.
C>Мы говорим о передовом крае развития IT.
C>Мы говорим о передовом крае развития IT.
C>Мы говорим о передовом крае развития IT.

Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2. На Обероне же куча реально работающего софта.

C>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.

И нигде не было реализации промышленного уровня.

C>В итоге, в Обероне нет ничерта совершенно из того, что сейчас является передовым краем развития.

Угу, у меня как раз пост был на эту тему, облом повторяться: http://www.rsdn.ru/forum/philosophy/4247637.1.aspx

M>>Так. Так ты про «мы ускакали на много лет вперед» или «мы унылый язык, который ничем от других не отличается, и, по сути, даром никому не нужен»?

V>Ну дык мне как аргумент приводят обсуждения тех лет, когда в той же джаве генериков еще не было.

А причем тут Java. Ну и, в отличие от Оберона, Java и C# не стоят на месте, а развиваются и получают те же generics и т.п.

V>Вопросы про макросистемы, зависимые типы и АлгТД применительно к императивному языку вообще поверхностностью отдают...

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

V>>>Если встроено в язык/платформу, да еще с GC, то это примерно тоже самое, что "самое ожидаемое" сегодня для дотнета. Асинхронность с GC и без GC это две большие разницы.
M>>Да нифига там не встроено нормально. Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

V>Я думаю, что ты не понял как работает ActiveOberon. Объяснять не буду, даже на этом сайте объясняли не раз.

Ссылку на объяснение в студию. Заметь, второй раз прошу.

M>>И да, я все езе жду ссылку на «интересные рассказы про Оберон, показывающие его преимущество и прогрессивность по сравнению с другими языками» на РСДН.

V>А я обещал?

Ты утверждал, что так было. Хотя я точно помню, что не было. Ссылки в студию.

V>Я выразил реверанс относительно идеологии языка, сравнительно с вектором развития современных популярных языков, заметив, что некоторые идеологии приходят в мейнстрим позже Оберона. Существует мнение, что Джаву во многом слизали с Оберона, но не принципиально... Хотя со стороны очень похоже. )))

И описанное приходит они туда не из Оберона, а из Лиспа, Смолтолка, ML'я, Erlang'а наконец, но точно не из Оберона.

V>Не заметил, что обсуждается прошлое время? То, что язык не развивается (развивается медленно) последние несколько лет — это известный факт. У него же нет такого "двигателя" как у дотнета. Например, если сравнить дотнет на момент его выхода, то унылее Г еще поискать. Это аргумент в сегодняшнем споре?

Ну а что было в Обероне на 2001-й год? И да, всякие Руби и Питоны развивались безо всякого двигателя.

V>Я ответил на самом деле от того, что хамовитый товарищ гонит недалекую пургу насчет "О современном состоянии в разработке ПО". Современное состояния разработки ПО таково, что всерьез стоит рассматривать только мейнстрим, а в этом мейнстриме только последние несколько лет активно воплощаются идеи, которые уже лет 20 как были обкатаны на других языках, в т.ч. на Обероне.

Да не было 20 лет тому назад ничего такого в Обероне, что уже не было бы обкатано в других языках. Не надо рассказывать про мегасуперязык, обогнавший свое время.

V>Ну и то, что автор прототипа турбо-Паскаля, а затем языка-платформы Дельфи разрабатывал язык C#, саму идеологию построения метаинформации и т.д. — это известный факт.

Известный. Только вот Паскаль в Delphi и Паскаль Вирта – это две достаточно разные вещи. И не надо притягивать сюда за уши еще и Оберон.

V>Т.е. влияние исходных виртовских идей организации модульного/компонентного ПО на современное состояние дел в мейнстриме де-факто определяющее. Всё остальное — это лишь градации по степени имплементации деталей.

Помимо модулей и компонентов в современном программировании (в том числе и мейнстримном) есть еще вагон и маленькая тележка всего, до чего Оберону — как до Пекина раком.

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

C>>Из популярных языков — Скала.
V>Скала сидит на готовом фреймворке.
Плевать.

C>>>>2) Generic'ов — нельзя даже сделать банальный типобезопасный map.
V>>>Генериков в той же Джаве лет 10 не было... а сейчас это кривой кодогенератор, который можно натянуть на любой язык при желании.
C>>Мы говорим о передовом крае развития IT.
C>>Мы говорим о передовом крае развития IT.
C>>Мы говорим о передовом крае развития IT.
C>>Мы говорим о передовом крае развития IT.
V>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2.
Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.

V>На Обероне же куча реально работающего софта.
Я от смеха пролил чай на пол.

C>>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.
V>И нигде не было реализации промышленного уровня.
Ага, в том числе и у Оберона.

C>>В итоге, в Обероне нет ничерта совершенно из того, что сейчас является передовым краем развития.
V>Угу, у меня как раз пост был на эту тему, облом повторяться: http://www.rsdn.ru/forum/philosophy/4247637.1.aspx
И что же в Обероне такого нового?

V>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2. На Обероне же куча реально работающего софта.

C>>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.

V>И нигде не было реализации промышленного уровня.

Erlang. Только вот реализация уровня Erlang'а Оберону может только сниться

> Была демагогия насчет общего кол-ва вентилей. На основе этой демагогии было загибание пальцев и попытка принизить собеседника. Если бы читал ветку сначала, то увидел, что пришлось доказывать демагогичность этого приёма, т.е. оправдываться что сам не дурак. Разговор вначале проходил довольно ровно... ровно до тех пор, пока собеседник не решил начать кидать понты. Далее без проблем пошло в предложенном им стиле общения...

Ну предположим это был не симметричный ответ.

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

Posted via RSDN NNTP Server 2.1 beta

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

G>А как пример с чуваком? Чувак никогда не был мудак,

Эти тонкости держите при себе. На улице я не позволяю к себе так обращаться.

G>но ты тут свое личное понимание использовал для перевода в хамскую плоскость.

Оба обращения используются для принижения того, к кому обращаются.

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

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

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

V>Коль структурное программирование — это система ограничений на конструкции программы, то развитие структурного программирования может быть только в сторону усилениятрансляци ограничений. В общем, хотел сказать, что если некий кусок кода нарушает ограничения структурного программирования, то он нарушает ограничения ДРАКОНа и подавно.

Не согласен.

V>развитие структурного программирования может быть только в сторону усиления ограничений.

Это неверно. ДРАКОН снимает часть ограничений. То есть развитие идет не в сторону усиления ограничений,
а в сторону снятия части ограничений

Вы исходите из того, что кусок кода первичен, а дракон-схема вторична.

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

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

Это не так. См. пример на стр. 456.
На рис. 259 — классическое структурное программирование.
На рис. 260 — НЕклассическое структурное программирование, принятое в ДРАКОНе.
http://drakon.su/_media/biblioteka/chast_7._425-472_teoreticheskie_osnovy_jazyka_drakon.pdf
.
.

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

M>А причем тут Java. Ну и, в отличие от Оберона, Java и C# не стоят на месте, а развиваются и получают те же generics и т.п.

V>>Вопросы про макросистемы, зависимые типы и АлгТД применительно к императивному языку вообще поверхностностью отдают...
M>Нет, не отпадают. Можно иметь императивный язык со всем вышеперечисленным.

Можно, но не нужно. Полезность сильно снижается без встроенных в язык гарантий иммутабельности. Опять же, АлгТД вступает в противоречие с инкапсуляцией ООП.... Хотя прекрасно эмулируется ОО-ср-вами. См. реализацию АлгТД в Nemerle или boost::variant.

V>>Я думаю, что ты не понял как работает ActiveOberon. Объяснять не буду, даже на этом сайте объясняли не раз.
M>Ссылку на объяснение в студию. Заметь, второй раз прошу.

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

И да, диалектов Оберона действительно много. Так что народ не в показаниях путался, а вы не вопринимали само наличие диалектов. Хотя казалось бы... Диалектов того же C# уже 3 шт сменилось.

M>>>И да, я все езе жду ссылку на «интересные рассказы про Оберон, показывающие его преимущество и прогрессивность по сравнению с другими языками» на РСДН.
V>>А я обещал?
M>Ты утверждал, что так было. Хотя я точно помню, что не было. Ссылки в студию.

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

V>>Я выразил реверанс относительно идеологии языка, сравнительно с вектором развития современных популярных языков, заметив, что некоторые идеологии приходят в мейнстрим позже Оберона. Существует мнение, что Джаву во многом слизали с Оберона, но не принципиально... Хотя со стороны очень похоже. )))

M>И описанное приходит они туда не из Оберона, а из Лиспа, Смолтолка, ML'я, Erlang'а наконец, но точно не из Оберона.

Стиль библиотек и публичных интерфейсов что в джаве, что в дотнете — это чисто виртовский-паскалевский стиль. Сравни с библиотеками из языков, приведенных тобой пример — это другая вселенная. Всё мимо. ИМХО, оберон, джаву и дотнет можно отнести в одну группу языков, а ни один твой пример в эту группу не попадает.

Даже сугубо сишный COM по стилю всяко ближе к Паскалю, чем к С++.

V>>Не заметил, что обсуждается прошлое время? То, что язык не развивается (развивается медленно) последние несколько лет — это известный факт. У него же нет такого "двигателя" как у дотнета. Например, если сравнить дотнет на момент его выхода, то унылее Г еще поискать. Это аргумент в сегодняшнем споре?

M>Ну а что было в Обероне на 2001-й год? И да, всякие Руби и Питоны развивались безо всякого двигателя.

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

V>>Я ответил на самом деле от того, что хамовитый товарищ гонит недалекую пургу насчет "О современном состоянии в разработке ПО". Современное состояния разработки ПО таково, что всерьез стоит рассматривать только мейнстрим, а в этом мейнстриме только последние несколько лет активно воплощаются идеи, которые уже лет 20 как были обкатаны на других языках, в т.ч. на Обероне.

M>Да не было 20 лет тому назад ничего такого в Обероне, что уже не было бы обкатано в других языках. Не надо рассказывать про мегасуперязык, обогнавший свое время.

Ха, здрасьте! В Паскале и было обкатано. Автором Оберона и Паскаля.

V>>Ну и то, что автор прототипа турбо-Паскаля, а затем языка-платформы Дельфи разрабатывал язык C#, саму идеологию построения метаинформации и т.д. — это известный факт.
M>Только вот Паскаль в Delphi и Паскаль Вирта – это две достаточно разные вещи. И не надо притягивать сюда за уши еще и Оберон.

Не настолько и разные. Как и Оберон. Диалекты C# больше друг от друга отличаются.

V>>Т.е. влияние исходных виртовских идей организации модульного/компонентного ПО на современное состояние дел в мейнстриме де-факто определяющее. Всё остальное — это лишь градации по степени имплементации деталей.

M>Помимо модулей и компонентов в современном программировании (в том числе и мейнстримном) есть еще вагон и маленькая тележка всего, до чего Оберону — как до Пекина раком.

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

Здравствуйте, Владимир Паронджанов, Вы писали:

V>>развитие структурного программирования может быть только в сторону усиления ограничений.
ВП>Это неверно. ДРАКОН снимает часть ограничений. То есть развитие идет не в сторону усиления ограничений,

Тогда не факт, что это развитие структурного программирования... на котором зиждется современное ООП и ФП из мейнстрима.

ВП>а в сторону снятия части ограничений

Хотя обсуждаемый момент сугубо филосовский... но мне представлялось, что если говорят о развитие "чего-то" — то это движение в том же направлении, что и упомянутое "что-то". На мой взгляд, снятие ограничений будет противоположным вектором относительно направления движения структурного программирования. Скажем так, ФП и ООП пошли по пути усиления ограничений над структурным программированием.

ВП>Вы исходите из того, что кусок кода первичен, а дракон-схема вторична.

Первично, как это у нас возникает в сознании. Я все-равно себе представляю потоки исполнения кода как минимум двумерно (ну, или думаю, что так их представляю

), поэтому и отношусь с интересом к графическому представлению как алгоритмов так и устройства систем.

ВП>Дело обстоит как раз наоборот. Дракон схема первична, а код вторичен.
ВП>Код образуется в результате трансляции дракон-схемы.

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

Т.е. без обид, но я воспринимаю ДРАКОН как движение в нужном направлении, но не как конечную его точку. По крайней мере, пользоваться им для для реальных разработок я смогу только в очень некоторых сценариях. (Они уже созрели).

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

ВП>Это не так. См. пример на стр. 456.
ВП>На рис. 259 — классическое структурное программирование.
ВП>На рис. 260 — НЕклассическое структурное программирование, принятое в ДРАКОНе.
ВП>http://drakon.su/_media/biblioteka/chast_7._425-472_teoreticheskie_osnovy_jazyka_drakon.pdf

OK, почитаем ваши взгляды на проблему.

===============================
Владимир, подозреваю, что у вас "плоский" вид просмотра форума. Для эпичных форумов RSDN это не лучший их вид. В общем, просьба отвечать в конкретных подветках.

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

V>>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2.
C>Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.

Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля. В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.

V>>На Обероне же куча реально работающего софта.
C>Я от смеха пролил чай на пол.

Хорошо не на системник.

C>>>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.
V>>И нигде не было реализации промышленного уровня.
C>Ага, в том числе и у Оберона.

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

C>>>В итоге, в Обероне нет ничерта совершенно из того, что сейчас является передовым краем развития.
V>>Угу, у меня как раз пост был на эту тему, облом повторяться: http://www.rsdn.ru/forum/philosophy/4247637.1.aspx
C>И что же в Обероне такого нового?

Э нет, не переиначивай меня. Это ты сказал, что в нем нет ничего нового, а я тебе ответил, что в нем давно ровно то, что в популярные языки только собирается приходить. Например — функцинальный тип и делегаты. Как же их не хватало, чтобы выпрямить кривизну джавы... Зато в дотнете потом появилось... Случайно что ле? От того самого разработчика Турбо-Паскаля и Дельфи?

Нет, ес-но, не случайно. А вот теперь готовят штуку, которая "взорвет" дотнет и "заставит вас переосмыслить подход к разработке программ" (С) — речь об новомодном async/await. Которые опять же из активного оберона. И опять тот же самый паскалевский автор. Опять совпадения? Заканчивайте вы уже эти умозрительные эксперименты. Разработчик одного из самых популярных на сегодня языков вырос на идеях Вирта что аж компилятор к ним разработал как хобби (прототип Турбо-паскаля). И я уверен, что, в отличие от тебя, он относится к виртовскому подходу как минимум с вниманием. И это он будет определять мейнстрим, а не ты и твоя пролитая чашка с чаем. В общем, где-то так...

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

V>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2. На Обероне же куча реально работающего софта.

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

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

V>>И нигде не было реализации промышленного уровня.

M>Erlang. Только вот реализация уровня Erlang'а Оберону может только сниться

Ради справедливости во время Oberon срачей я скачивал компилятор Oberon XDS который
давал весьма качественный код, скажем VC так в compile time тогда работать не умел.

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

V>Сравнил интерпретаторы и компиляторы. )))
V>Даже мне приходилось простые интерпретаторы писать, но замахнуться на компилятор я пока не решился, так и продолжаю кое-какие свои эксперименты, понимая, что это совсем другой уровень задачи.

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

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

FR>Я компиляторы писать не собирался и не собираюсь, но судя по размеру описания языка и рантайма, компилятор оберона
FR>гораздо проще чем интерпретатор питона, тем более сейчас когда есть такие штуки как llvm.

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

M>>А причем тут Java. Ну и, в отличие от Оберона, Java и C# не стоят на месте, а развиваются и получают те же generics и т.п.

V>>>Вопросы про макросистемы, зависимые типы и АлгТД применительно к императивному языку вообще поверхностностью отдают...
M>>Нет, не отпадают. Можно иметь императивный язык со всем вышеперечисленным.

V>Можно, но не нужно. Полезность сильно снижается без встроенных в язык гарантий иммутабельности. Опять же, АлгТД вступает в противоречие с инкапсуляцией ООП.... Хотя прекрасно эмулируется ОО-ср-вами. См. реализацию АлгТД в Nemerle или boost::variant.

В Немерле как раз гарантии иммутабельности, емнип. И ничего, мультипарадигменный язык без сказок про «не нужность» и «императивность»

V>>>Я думаю, что ты не понял как работает ActiveOberon. Объяснять не буду, даже на этом сайте объясняли не раз.
M>>Ссылку на объяснение в студию. Заметь, второй раз прошу.

V>Да хоть три раза. Не дам.

Ну значит это твое заявление ложь:

Про Active Oberon несколько раз рассказывали очень интересно. Просто местная публика своими низкопробными улюлюканиями и прочими "ату его!" отбивает у вменяемых людей желание продолжать обсуждение.

V>Вызвались пообсуждать язык? — извольте предварительно ознакомиться. Самостоятельно. А потом уже можно предметно. Я с тобой не согласен потому, что "мьютексы и локи на ровном месте" этот вовсе не основная фишика активного оберона, т.е. вовсе не то, что отличает его от неактивного.

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

V>И да, диалектов Оберона действительно много. Так что народ не в показаниях путался, а вы не вопринимали само наличие диалектов. Хотя казалось бы... Диалектов того же C# уже 3 шт сменилось.

Да нет, именно что народ в показаниях путался. Общее обсуждение выглядело так:
— Можно сделать что-то в Обероне?
— Да, только в активном обероне.
— эээ. хм, а вот это?
— Да, в компонентном паскале
— эээ
— дадада, в Зонноне

Люди, «интересно рассказываюзщие про Оберон» так и не родили внятного описания, что это такое, чем все эти диалекты друг от друга отличаются, и зачем они нужны.

Как пример показательной цитаты:

C> кстати, а в Oberon'е есть volatile?
Нету.
Если Вам так интересна многопоточность, то есть специально придуманный для нее Оберон под названием Active Oberon. Там объекты активные, то есть объект = поток.
Операционка написанная на нем тут: http://bluebottle.ethz.ch/
Так же есть дальний родственник Оберона — Zonnon это переосмысление Active Oberon for .NET http://www.zonnon.ethz.ch/

В трез предложениях три разных яызка. И так — по всему форуму. Когда надо, говорится про Modula. Когда надо — про Оберон. Когда надо — про Active Oberon.

В то время как про «диалекты C#» тебе расскажет каждый второй.

M>>>>И да, я все езе жду ссылку на «интересные рассказы про Оберон, показывающие его преимущество и прогрессивность по сравнению с другими языками» на РСДН.
V>>>А я обещал?
M>>Ты утверждал, что так было. Хотя я точно помню, что не было. Ссылки в студию.

V>Тогда стоит процитировать меня не своими словами, а точнее... и закрыть тему.

Могу процитировать тебя твоими словами:

Про Active Oberon несколько раз рассказывали очень интересно.

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

V>>>Я выразил реверанс относительно идеологии языка, сравнительно с вектором развития современных популярных языков, заметив, что некоторые идеологии приходят в мейнстрим позже Оберона. Существует мнение, что Джаву во многом слизали с Оберона, но не принципиально... Хотя со стороны очень похоже. )))

M>>И описанное приходит они туда не из Оберона, а из Лиспа, Смолтолка, ML'я, Erlang'а наконец, но точно не из Оберона.

V>Стиль библиотек и публичных интерфейсов что в джаве, что в дотнете — это чисто виртовский-паскалевский стиль. Сравни с библиотеками из языков, приведенных тобой пример — это другая вселенная. Всё мимо. ИМХО, оберон, джаву и дотнет можно отнести в одну группу языков, а ни один твой пример в эту группу не попадает.

Что значит «стиль»?

V>Даже сугубо сишный COM по стилю всяко ближе к Паскалю, чем к С++.

Что значит «стиль»?

V>>>Не заметил, что обсуждается прошлое время? То, что язык не развивается (развивается медленно) последние несколько лет — это известный факт. У него же нет такого "двигателя" как у дотнета. Например, если сравнить дотнет на момент его выхода, то унылее Г еще поискать. Это аргумент в сегодняшнем споре?

M>>Ну а что было в Обероне на 2001-й год? И да, всякие Руби и Питоны развивались безо всякого двигателя.

V>Сравнил интерпретаторы и компиляторы. )))

Учитывая, что Руби по сложности языка заткнет Оберон за пояс, сравнить можно.

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

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

V>>>Я ответил на самом деле от того, что хамовитый товарищ гонит недалекую пургу насчет "О современном состоянии в разработке ПО". Современное состояния разработки ПО таково, что всерьез стоит рассматривать только мейнстрим, а в этом мейнстриме только последние несколько лет активно воплощаются идеи, которые уже лет 20 как были обкатаны на других языках, в т.ч. на Обероне.

M>>Да не было 20 лет тому назад ничего такого в Обероне, что уже не было бы обкатано в других языках. Не надо рассказывать про мегасуперязык, обогнавший свое время.

V>Ха, здрасьте! В Паскале и было обкатано. Автором Оберона и Паскаля.

Дадада. В Паскале и ООП было, и актеры, и функциональные типы. Нуну. Ты эта, ври но не завирайся.

V>>>Ну и то, что автор прототипа турбо-Паскаля, а затем языка-платформы Дельфи разрабатывал язык C#, саму идеологию построения метаинформации и т.д. — это известный факт.
M>>Только вот Паскаль в Delphi и Паскаль Вирта – это две достаточно разные вещи. И не надо притягивать сюда за уши еще и Оберон.

V>Не настолько и разные. Как и Оберон. Диалекты C# больше друг от друга отличаются.

Что такое «диалекты C#» известно только тебе. И мы не телепаты, чтобы разобраться, что весь этот десяток называний разных языков каким-то образом связан и может (а может ли?) считаться одним языком.

V>>>Т.е. влияние исходных виртовских идей организации модульного/компонентного ПО на современное состояние дел в мейнстриме де-факто определяющее. Всё остальное — это лишь градации по степени имплементации деталей.

M>>Помимо модулей и компонентов в современном программировании (в том числе и мейнстримном) есть еще вагон и маленькая тележка всего, до чего Оберону — как до Пекина раком.

V>Например? Новомодные лямбды? yield return? До чего именно ему раком? Все что есть дополнительного в джаве и дотнете — это из-за природы виртуальной машины. И я не уверен, что это такой уж плюс, по сравнению с нейтивными языками. Ну и есть Обероны для дотнета и джавы, то бишь это рассуждения вникуда.

Ну да, весь мир клином сошелся только на Java и .NET'е.

«Новомодным лямбдам» в этом году 50 лет, кури Лисп. И в то время, как Java и .NET, развиваясь, получают новые возможности (и не только они), Оберон остается застывшим в 80-х гуаном с претензиями на величие. Что мешает Оберону, например, получить ФВП(необходимость для лямбд)? Ничего, кроме завышенного ЧСВ и зашоренности атворов, которые уверены в мегакрутости своей поделки.

V>речь об новомодном async/await. Которые опять же из активного оберона. И опять тот же самый паскалевский автор. Опять совпадения?

Да нет в этом Оберона даже близко. async/await появляются не благодаря Оберону, а благодаря общему развитию индустрии. И скорее всего с оглядкой на тот же Erlang, который, в отличие от Оберона, действительно может похвастаться работающей системой этих самых акторов.

А async/await — эти два слова появились в компьютерной среде еще наверное в 60-х

V>>>И нигде не было реализации промышленного уровня.

M>>Erlang. Только вот реализация уровня Erlang'а Оберону может только сниться

FR>Ради справедливости во время Oberon срачей я скачивал компилятор Oberon XDS который
FR>давал весьма качественный код, скажем VC так в compile time тогда работать не умел.

Ну, опять же, справедливости ради, Oberon и язык попроще

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

M>Ну значит это твое заявление ложь:
M>

M>Про Active Oberon несколько раз рассказывали очень интересно. Просто местная публика своими низкопробными улюлюканиями и прочими "ату его!" отбивает у вменяемых людей желание продолжать обсуждение.

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

Получи и распишись.

V>>Вызвались пообсуждать язык? — извольте предварительно ознакомиться. Самостоятельно. А потом уже можно предметно. Я с тобой не согласен потому, что "мьютексы и локи на ровном месте" этот вовсе не основная фишика активного оберона, т.е. вовсе не то, что отличает его от неактивного.

M>А, ну да. Классическая оберонкоровская поза: вы все тупые, а мы самые умные, отвечать на вопросы не будем, но максимально громкие заявления делать будем.

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

M>>Ну значит это твое заявление ложь:
M>>

M>>Про Active Oberon несколько раз рассказывали очень интересно. Просто местная публика своими низкопробными улюлюканиями и прочими "ату его!" отбивает у вменяемых людей желание продолжать обсуждение.

V>Значит ты напрашиваешься на комплимент. Сдается мне, что предоставление тебе такой ссылки недалеко ушло от банального оскорбления.

V>Получи и распишись.

Нуну. По какой из этой сотни ссылок есть «интересный рассказ»? В общем, подтверждение своим собственным словам ты так и не привел. Что и не удивительно.

V>>>Вызвались пообсуждать язык? — извольте предварительно ознакомиться. Самостоятельно. А потом уже можно предметно. Я с тобой не согласен потому, что "мьютексы и локи на ровном месте" этот вовсе не основная фишика активного оберона, т.е. вовсе не то, что отличает его от неактивного.

M>>А, ну да. Классическая оберонкоровская поза: вы все тупые, а мы самые умные, отвечать на вопросы не будем, но максимально громкие заявления делать будем.

V>Блин, да ты же натуральный тролль. ))
V>Ладно, это уже без меня... По приведенной сверхсекретной ссылке тебе должно хватить полезной инфы. Было бы желание вникать.

Было бы у захитничков Оберона и прочих оберонкоровцев желание отвечать хоть на один прямо поставленный вопрос, была бы инфа. Но — увы. Есть только поза «вы все тупые, мы — в белом платье».

ЗЫ. За всю историю Оберона на RSDN что-либо внятное про Оберон говорил ровно один человек — AVC, и то мало. Но зачем я буду выполнять за тебя работу по поиску каких-либо подтверждений твоим же словам? Если все, на что ты способен — это пафосные заявления без подтверждений, то увы.

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

C>>Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.
V>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
Ты читаешь через слово? В языках ML-семейства разные попытки параллелизации начались в 80-х. http://cml.cs.uchicago.edu/ — ConcurrentML начался в 96-м году. Его разработчики так же участвовали в создании одной из самых быстрых реализаций Smalltalk'а, с JIT-компиляцией и быстрым GC. В начале 90-х.

Не нравится ML?

У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.

Так что не надо говорить, что Oberon опередил время. В 97-м году активные объекты были примерно такой же новостью, как и GC.

C>>Ага, в том числе и у Оберона.
V>Дык наоборот, самый обычный промышленный уровень и промышленное использование в реальных проектах, в т.ч. в виде начинки в железках. Про Хаскель такого сказать нельзя, а веь Хаскель почти ему ровесник.
Нету на Обероне никакого существенного объёма кода. Сам язык скончался ещё 6 лет назад — последние релизы датированы 2004-м годом.

Даже на D уже больше написано.

C>>И что же в Обероне такого нового?
V>Э нет, не переиначивай меня. Это ты сказал, что в нем нет ничего нового, а я тебе ответил, что в нем давно ровно то, что в популярные языки только собирается приходить. Например — функцинальный тип и делегаты.
Как же их не хватало, чтобы выпрямить кривизну джавы... Зато в дотнете потом появилось... Случайно что ле? От того самого разработчика Турбо-Паскаля и Дельфи?

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

M>Нуну. По какой из этой сотни ссылок есть «интересный рассказ»? В общем, подтверждение своим собственным словам ты так и не привел. Что и не удивительно.

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

M>Было бы у захитничков Оберона и прочих оберонкоровцев желание отвечать хоть на один прямо поставленный вопрос, была бы инфа. Но — увы. Есть только поза «вы все тупые, мы — в белом платье».

Классика жанра — "не читал, но осуждаю". Похлеще демагогии еще поискать. Ты зачем вообще сюда пишешь? У тебя личная неприязнь к Оберону или как?

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

M>ЗЫ. За всю историю Оберона на RSDN что-либо внятное про Оберон говорил ровно один человек — AVC, и то мало. Но зачем я буду выполнять за тебя работу по поиску каких-либо подтверждений твоим же словам? Если все, на что ты способен — это пафосные заявления без подтверждений, то увы.

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

Глубоких-преглубоких подробностей реализации AOS я и сам не знаю и не собираюсь узнавать, но приводимых неоднократно подробностей должно было хватить, чтобы понять основные идеи. Ради прикола предлагаю (после того, как ты наконец одолеешь собственную лень) сравнить идеи, заложенные в AOS с идеями, заложенными в ту самую Сингулярити, которую Wolfhound рекламируют как "самую-самую грань прогресса" (С). Обещаю, что при самостоятельном сравнении получишь достаточно фана.

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

M>>Нуну. По какой из этой сотни ссылок есть «интересный рассказ»? В общем, подтверждение своим собственным словам ты так и не привел. Что и не удивительно.

V>Да привел, привел. Попробуй сузить по AOS, если ты не способен пройти дальше второй строчки первой страницы гугля.

Ну да ну да. Позиция «ты тупой, я в белом платье» мне уже известна. Конкретики, я так понимаю, от тебя не дождаться.

M>>Было бы у захитничков Оберона и прочих оберонкоровцев желание отвечать хоть на один прямо поставленный вопрос, была бы инфа. Но — увы. Есть только поза «вы все тупые, мы — в белом платье».

V>Классика жанра — "не читал, но осуждаю". Похлеще демагогии еще поискать. Ты зачем вообще сюда пишешь? У тебя личная неприязнь к Оберону или как?

Я, вообзе-то, в тех всех спорах участвовал. И я прекрасно помню демагогию защитничков Оберона (кроме AVC).

V>Как же так вышло, что не успев даже пообсуждать технологию (сугубо из-за своей лени, ес-но) ты быстро скатился на обсуждение личностей? Трольство как оно есть.

Технологию тут обсуждали. Личность я не обсуждаю, опираюсб сугубо на факты.

M>>ЗЫ. За всю историю Оберона на RSDN что-либо внятное про Оберон говорил ровно один человек — AVC, и то мало. Но зачем я буду выполнять за тебя работу по поиску каких-либо подтверждений твоим же словам? Если все, на что ты способен — это пафосные заявления без подтверждений, то увы.

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

Про Active Oberon несколько раз рассказывали очень интересно.

Этот «фактический материал» фактами не пожтверждается.

V>Глубоких-преглубоких подробностей реализации AOS я и сам не знаю и не собираюсь узнавать, но приводимых неоднократно подробностей должно было хватить,

Ссылка хоть на одну такую подробность будет? Нет, не будет. Ведь языком молоть — это не мешки таскать.

V>чтобы понять основные идеи. Ради прикола предлагаю (после того, как ты наконец одолеешь собственную лень) сравнить идеи, заложенные в AOS с идеями, заложенными в ту самую Сингулярити, которую Wolfhound рекламируют как "самую-самую грань прогресса" (С). Обещаю, что при самостоятельном сравнении получишь достаточно фана.

Для того, чтобы что-то сравнивать, нужно, чтобы обе стороны хоть что-то рассказали. Хотя бы тут на форуме. Про Оберон внятного не рассказано ничего.

V>Если же опять попросишь предоставить тебе материал уровня 0 на блюдечке — реакция будет та же. Сорри, совесть надо иметь и не отнимать у людей время. Все входы и выходы уже даны. Дерзай.

Пока что от тебя идет только поток лжи (пок ане доказано обратное). Ложь заключается в следующем:

Про Active Oberon несколько раз рассказывали очень интересно.

При том, что ты оказался неспособен найти даже одного примера этого заявления

Глубоких-преглубоких подробностей реализации AOS я и сам не знаю и не собираюсь узнавать, но приводимых неоднократно подробностей должно было хватить

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

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

C>Не нравится ML?

Нет, по приведенной ссылке я свое мнение уже сказал:

Да и есть ML-языки, которые пытаются реализовать эти наработки. И что эти яыки из себя представляют мы прекрасно знаем: неудобство для общеприкладных задач и тормозной получаемый код, требующих дохрена памяти. Был бы этот сыр бесплатный, весь этот материал давно был бы в мейнстриме.

Вычислительная модель ML-языков не ложится на современную архитектуру. Поэтому тормоза и перерасход памяти. Есть другие модели, типа data-flow, вот там им будет место, если когда-нить эти идеи получат распространение.

C>У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.

Это компроммис и он не имеет быстрых реализаций. Почему? Курить кодирование целочисленных и ссылочных типов в oCaml.

C>Так что не надо говорить, что Oberon опередил время. В 97-м году активные объекты были примерно такой же новостью, как и GC.

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

C>>>Ага, в том числе и у Оберона.
V>>Дык наоборот, самый обычный промышленный уровень и промышленное использование в реальных проектах, в т.ч. в виде начинки в железках. Про Хаскель такого сказать нельзя, а веь Хаскель почти ему ровесник.
C>Нету на Обероне никакого существенного объёма кода.

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

C>Сам язык скончался ещё 6 лет назад — последние релизы датированы 2004-м годом.

Это аргумент скорее в мою пользу, чем твою, коль речь о прошедшем времени.

C>Даже на D уже больше написано.

Чего именно написано? Экспериментов или реальных проектов? Уже на нем летают беспилотники и он используется в ПО спутников? Не говори ерунды, кароч, у них еще тонна багов компилятора не закрыта.

C>>>И что же в Обероне такого нового?
V>>Э нет, не переиначивай меня. Это ты сказал, что в нем нет ничего нового, а я тебе ответил, что в нем давно ровно то, что в популярные языки только собирается приходить. Например — функцинальный тип и делегаты.
C>Как же их не хватало, чтобы выпрямить кривизну джавы... Зато в дотнете потом появилось... Случайно что ле? От того самого разработчика Турбо-Паскаля и Дельфи?

Нет, ес-но, не случайно. А вот теперь готовят штуку, которая "взорвет" дотнет и "заставит вас переосмыслить подход к разработке программ" (С) — речь об новомодном async/await. Которые опять же из активного оберона.
C>Хватит уже врать про "из Активного Оберона". К 97-му году модели CSP было уже 20 лет и никакой новостью она не была.

В промышленной реализации была новостью. Обошел их по распространенности только Эрланг малость позже. (этот факт тоже в мою пользу, а не твою).

А так-то основные принципы совремнного ПО известны с 50-х годов, но они же не были обкатаны на практике в промышленном масштабе.

C>Более того, про produciton-реализацию — это вообще смешно. ActiveOberon — это обычный выдисер обычного академика, и дальше начального выпуска он никуда не пошёл.

Немерле тоже обычный диссер. Сингулярити и подавно. Хороши твои аргументы.

C>Я тут почитал о так называемой "production-quality" реализации Оберона. Так они не ушли дальше mark&sweep GC, у них, блин, статьи о том, как они туда героически добавили трёхцветный GC для параллельности. LOL.

Это всё, что ты прочитал? Негусто.

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

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

==============
Кароч, я прекрасно помню личность Губанова тут. Личность эпическая, согласен, но вы тут, похоже, заразились.

Пока что от тебя идет только поток лжи (пок ане доказано обратное). Ложь заключается в следующем:

Про Active Oberon несколько раз рассказывали очень интересно.

При том, что ты оказался неспособен найти даже одного примера этого заявления

Глубоких-преглубоких подробностей реализации AOS я и сам не знаю и не собираюсь узнавать, но приводимых неоднократно подробностей должно было хватить

V>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки

V>Ха, здрасьте! В Паскале и было обкатано. Автором Оберона и Паскаля.

Дадада. В Паскале и ООП было, и актеры, и функциональные типы. Нуну. Ты эта, ври но не завирайся.

V> речь об новомодном async/await. Которые опять же из активного оберона.
Хватит уже врать про "из Активного Оберона". К 97-му году модели CSP было уже 20 лет и никакой новостью она не была.

V>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
Ты читаешь через слово? В языках ML-семейства разные попытки параллелизации начались в 80-х. http://cml.cs.uchicago.edu/ — ConcurrentML начался в 96-м году. Его разработчики так же участвовали в создании одной из самых быстрых реализаций Smalltalk'а, с JIT-компиляцией и быстрым GC. В начале 90-х.

Не нравится ML?

У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.

Так что не надо говорить, что Oberon опередил время. В 97-м году активные объекты были примерно такой же новостью, как и GC.

V>Сравнил интерпретаторы и компиляторы.
Судя по размеру описания языка и рантайма, компилятор оберона
гораздо проще чем интерпретатор питона

Ну и т.п.

Но ты продолжай, продолжай. «Ты такой умный, с тобой так интересно» ©

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

За тебя там бот ключевые слова в форум ложит или как? Или гугл не той системы.

http://www.rsdn.ru/forum/design/816814.1.aspx
http://www.oberon.ethz.ch/bibliography/publications

Ну и полно обсуждений от 2004-го года. В которых ты тоже участвовал (горадо более предметно, кстате). Но, похоже, ты уже забыл как собственные аргументы так и приведенные ответы на твои аргументы. Я все-равно не буду начинать те треды заново.

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

M>При том, что ты не будещь способен привести хотябы пару та ких подробностей (раз уже их приводили неоднократно).

Ты действительно забодал, ссылки рядом привел.

M>

V>>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки

V>>Ха, здрасьте! В Паскале и было обкатано. Автором Оберона и Паскаля.

M>Дадада. В Паскале и ООП было, и актеры, и функциональные типы. Нуну. Ты эта, ври но не завирайся.

Угу, вырвал фразы из разных постов и слепил из них один новый. Мои позравления.

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

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

M>>

V>>>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки

V>>>Ха, здрасьте! В Паскале и было обкатано. Автором Оберона и Паскаля.

M>>Дадада. В Паскале и ООП было, и актеры, и функциональные типы. Нуну. Ты эта, ври но не завирайся.

V>Угу, вырвал фразы из разных постов и слепил из них один новый. Мои позравления.

Контекст не потерян, не бойся.

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

FR>Оберон семейство можно сравнить скажем с ML семейством, степень маргинальности и количество софта вполне
FR>сопоставимое, но по всем параметрам по моему обероны пролетают.

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

FR>Притом ML ровесник паскаля, и в нем уже было практически все чем мог похвалится оберон через 15 лет.

Зато ML-языки не могли похвастаться тем, что их взяли вместо Ады, например.

Потому что язык программирования для вещей повышенной надежности должен быть читабельным, а не птичьим. В до-дотнетные времена кроме как на VB или на Дельфи клепеать по-быстрому UI было фактически не на чем... Не помню я, чтобы UI клепали на ML-языках. Тоже факт для медитации.

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

M>Контекст не потерян, не бойся.

Дык, за тебя боюсь. Там было два контекста. Если говоришь в единственном числе, таки потерял и не заметил. Провалы?

V>За тебя там бот ключевые слова в форум ложит или как? Или гугл не той системы.

Отсылка в гугл == посыл на три известные буквы. Если ты не способен сам найти подтверждение своим словам, никто за тебя это делать не станет

V>http://www.rsdn.ru/forum/design/816814.1.aspx
V>http://www.oberon.ethz.ch/bibliography/publications

Ну наконец-то. Не прошло и трех дней, как ты смок выкопать одну ссылку.

V>Ну и полно обсуждений от 2004-го года. В которых ты тоже участвовал (горадо более предметно, кстате). Но, похоже, ты уже забыл как собственные аргументы так и приведенные ответы на твои аргументы.

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

V>Я все-равно не буду начинать те треды заново.

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

Это не я пытаюсь навязать, это естесвенная реакция на тебя и прочих «защитничков», которые выставляют Оберон панацеей, самым мегакрутым и вообще первым и единственным языком в мире, ибо! И при этом не могут нормально и внятно ответить на простейшие вопросы.

Обрати внимание, ты привел ссылку, где есть действительно внятное объяснение. Где «крики» и «хамство», которое ты упорно видишь в каждом топике? Нет и близко. Только вот таких нормальных объяснений своей позиции за все время Оберона на РСДН было штуки две-три, а не «множество» или «много раз», как ты пытаешься тут рассказать.

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

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

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

M>>Контекст не потерян, не бойся.

V>Дык, за тебя боюсь. Там было два контекста. Если говоришь в единственном числе, таки потерял и не заметил. Провалы?

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

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

FR>>Оберон семейство можно сравнить скажем с ML семейством, степень маргинальности и количество софта вполне
FR>>сопоставимое, но по всем параметрам по моему обероны пролетают.
V>Да нельзя их сравнить. Для начально обучения ML-языки непригодны. Эффективность кода ML-языков ниже плинтуса и т.д.
Давай мы сравним MoscowML образца 99-го года и Оберон того же года? Ты очень удивишься.

V>Генерируемый код не удовлетворяет нкаким требованиям.
Ври, да не завирайся. Каким требованиям не удовлетворяет скомпилированный код ML?

FR>>Притом ML ровесник паскаля, и в нем уже было практически все чем мог похвалится оберон через 15 лет.
V>Зато ML-языки не могли похвастаться тем, что их взяли вместо Ады, например.

И?

V>Потому что язык программирования для вещей повышенной надежности должен быть читабельным, а не птичьим. В до-дотнетные времена кроме как на VB или на Дельфи клепеать по-быстрому UI было фактически не на чем... Не помню я, чтобы UI клепали на ML-языках. Тоже факт для медитации.
А можно UI на Обероне? Кроме БлеватьБоттле.

C>>Не нравится ML?

V>Нет, по приведенной ссылке я свое мнение уже сказал:
V>

V>Да и есть ML-языки, которые пытаются реализовать эти наработки. И что эти яыки из себя представляют мы прекрасно знаем: неудобство для общеприкладных задач и тормозной получаемый код, требующих дохрена памяти. Был бы этот сыр бесплатный, весь этот материал давно был бы в мейнстриме.

V>Вычислительная модель ML-языков не ложится на современную архитектуру. Поэтому тормоза и перерасход памяти. Есть другие модели, типа data-flow, вот там им будет место, если когда-нить эти идеи получат распространение.

Ах, какаой классический уход от контекста. Как и на протяжении всего скипнутого сообщения

C>Мы говорим о передовом крае развития IT.

V> Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2. На Обероне же куча реально работающего софта.

C>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.

C> И нигде не было реализации промышленного уровня.

Потом

V>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2.
Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.

Потом

C>Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.

Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля. В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.

Потом

V>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
Ты читаешь через слово? В языках ML-семейства разные попытки параллелизации начались в 80-х. http://cml.cs.uchicago.edu/ — ConcurrentML начался в 96-м году. Его разработчики так же участвовали в создании одной из самых быстрых реализаций Smalltalk'а, с JIT-компиляцией и быстрым GC. В начале 90-х.

Не нравится ML?

У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.

Так что не надо говорить, что Oberon опередил время. В 97-м году активные объекты были примерно такой же новостью, как и GC.

И потом ВНЕЗАПНО

C>Не нравится ML?
Вычислительная модель ML-языков не ложится на современную архитектуру.

Что ни сделаешь, лишь бы защитить иллюзию того, что Оберон — передовой язык!

Ну и да. Добавлю. Erlang начал развиваться в 1986-м году на основе исследований 1981-го года. Развитие опиралось на опыт существоваших на тот момент промышленных и экспериментальных языках (PLEX, Parlog и т.п.).

Первый промышленный продукт на Erlang'е — 1998-й год. Год, когда Active Oberon только только появился. Но да, но да. AO — впереди планеты всей, естественно.

Если реальность не соответствует фантазиям, тем хуже для реальности.

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

V>>За тебя там бот ключевые слова в форум ложит или как? Или гугл не той системы.
M>Отсылка в гугл == посыл на три известные буквы.

Если речь об инфе с первых страниц гугля — то заслужено.

M>Если ты не способен сам найти подтверждение своим словам, никто за тебя это делать не станет

Ключевые слова и технологии я перечислял. Есть опровержения — опровергай. Нет — свободен.

V>>http://www.rsdn.ru/forum/design/816814.1.aspx
V>>http://www.oberon.ethz.ch/bibliography/publications

M>Ну наконец-то. Не прошло и трех дней, как ты смок выкопать одну ссылку.

Да их мильон, ссылок, включая по zonnon. Я и сам ХЗ зачем я ссылку кинул с первой страницы гугля... слабину дал. Мне даже пофиг тот факт, что ты со своим мнением насчет АО сел в самую глубокую лужу во всём этом топике. Вот твой уровень:

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

Всерьез я на таком уровне обсуждать не намерен. В гугл!

M>Ничего я не забыл. Поэтому и говорю, что нормально про Оберон тут никто ничего не рассказывал.

1. Тебе никто ничего не должен.
2. Рассказывали достаточно.

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

V>>Я все-равно не буду начинать те треды заново.

Покажи, где я выставляю панацеей?

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

Ибо такого баланса простоты внешней, но достаточно мощный заложенных ср-в, при этом надежности программ и эффективности целевого бинарного кода, как у виртовских языков, у других языков-совремнников НЕ БЫЛО. Это медицинский факт. Ну и скорость компиляции опять же. Я ведь вижу, что ты даже не задумался над тем вопросом, что найти этот баланс — непростая задача сама по себе.

Даже посмотри на то, во что превратился исходный BASIC — в VB. Это же фактически Паскаль и есть, близнецы-браться. Даже опреатор WITH слизали... И этот язык тоже считался в нейтивные времена одним из самых надежных, почему на нем и было сделано куча бизнес-логики.

По мне самый удобный язык — С++, я тут в срачах всегда его отстаиваю. Но это не значит, что я не понимаю решений, заложенных в других языках. Поэтому и пользовал тот паскаль и дельфи мпериодически в своё время, когда им не было реальной альтернативы на многих нишах. Аналогично с VB. Аналогично потом с C#. Это же объектный паскаль с си-подобным синтаксисом. Ты разве не заметил? Но у меня, сишника с 20-тилетним стажем, никаких комплексов по этому поводу... А у тебя и остальных хулителей виртовского направления я вижу только комплексы и ничего более. И вызванную этими комплексами избирательную слепоту. Ваши проблемы. Своё мение я уже высказал, добавить нечего. Если не обсуждать сфероконей, то виртовские языки — это были пригодные к промышленной разарботки системы в своё время. Тыкать в меня неработающими прототипам "старых идей", как пытается это делать Cyberax — бесполезно. Это всё было на моих глазах.

M>Обрати внимание, ты привел ссылку, где есть действительно внятное объяснение. Где «крики» и «хамство», которое ты упорно видишь в каждом топике? Нет и близко. Только вот таких нормальных объяснений своей позиции за все время Оберона на РСДН было штуки две-три, а не «множество» или «много раз», как ты пытаешься тут рассказать.

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

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

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

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

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

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

V>>Да нельзя их сравнить. Для начально обучения ML-языки непригодны. Эффективность кода ML-языков ниже плинтуса и т.д.
C>Давай мы сравним MoscowML образца 99-го года и Оберон того же года? Ты очень удивишься.

Давай, сравнивай.

V>>Генерируемый код не удовлетворяет нкаким требованиям.
C>Ври, да не завирайся. Каким требованиям не удовлетворяет скомпилированный код ML?

Любым:
— объем бинарного кода;
— эффектвность;
— требования к оперативной памяти.

Из-за всего этого на ML невозможно писать для каких-нить военных железок.

FR>>>Притом ML ровесник паскаля, и в нем уже было практически все чем мог похвалится оберон через 15 лет.
V>>Зато ML-языки не могли похвастаться тем, что их взяли вместо Ады, например.

C>И?

Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.

V>>Потому что язык программирования для вещей повышенной надежности должен быть читабельным, а не птичьим. В до-дотнетные времена кроме как на VB или на Дельфи клепеать по-быстрому UI было фактически не на чем... Не помню я, чтобы UI клепали на ML-языках. Тоже факт для медитации.
C>А можно UI на Обероне? Кроме БлеватьБоттле.

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

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

V>>Вычислительная модель ML-языков не ложится на современную архитектуру. Поэтому тормоза и перерасход памяти. Есть другие модели, типа data-flow, вот там им будет место, если когда-нить эти идеи получат распространение.

M>Ах, какаой классический уход от контекста. Как и на протяжении всего скипнутого сообщения

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

C>>Мы говорим о передовом крае развития IT.
V>> Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2. На Обероне же куча реально работающего софта.

Ну да, мне же зависимыми типами тыкали. Ты в курсе, что это?

C>>Мы говорим о передовом крае развития IT. Да, к 97-му году модели активных объектов уже было примерно 20 лет.

Я уже на это ответил, зачем ты дублируешь опровергнутую фразу?

M>Потом
M>

V>>Ни один "передовой край" не продвинулся дальше тормознутого прототипа компилятора. Даже если брать самые передовые навроде Adga2.
M>Враньё. Есть быстрые Rust и Golang (у него в GCC компилятор). Есть классические OCaml и Haskell — оба достаточно быстрые и имели почти все перечисленные фичи ещё в 90-х.

А что, у Rust есть зависимые типы? Или в Golang? И где ты увидел хоть одну передовую идею Rust?
Че за поток бреда?

M>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля. В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.

И где твой технический коммент-опровержение?

V>>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
M>Ты читаешь через слово? В языках ML-семейства разные попытки параллелизации начались в 80-х. http://cml.cs.uchicago.edu/ — ConcurrentML начался в 96-м году. Его разработчики так же участвовали в создании одной из самых быстрых реализаций Smalltalk'а, с JIT-компиляцией и быстрым GC. В начале 90-х.

M>Не нравится ML?

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

И вообще, если ты привел конкретный ход обсуждения, то собеседник предложил Хаскель как аргумент, на него и ответил. Ты уже 3-й раз теряешь контекст.

M>У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.

Тоже там же ответил. Не имеет быстрые реализации. Сказки. У OCAML есть кое-какое важное ограничение. Подсказку там же дал.

M>Так что не надо говорить, что Oberon опередил время. В 97-м году активные объекты были примерно такой же новостью, как и GC.

M>И потом ВНЕЗАПНО
M>

C>>Не нравится ML?
M>Вычислительная модель ML-языков не ложится на современную архитектуру.

Дык, где внезапно-то? Спросили — ответил. У тебя есть что возразить — попробуй возразить. Нет — свободен.

M>Что ни сделаешь, лишь бы защитить иллюзию того, что Оберон — передовой язык!

Мде, клиника.

M>Ну и да. Добавлю. Erlang начал развиваться в 1986-м году на основе исследований 1981-го года. Развитие опиралось на опыт существоваших на тот момент промышленных и экспериментальных языках (PLEX, Parlog и т.п.).

M>Первый промышленный продукт на Erlang'е — 1998-й год. Год, когда Active Oberon только только появился. Но да, но да. AO — впереди планеты всей, естественно.

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

M>Если реальность не соответствует фантазиям, тем хуже для реальности.

Ты просто пытаешься жонглировать и домысливать за оппонента. Я говорил только то, что говорил.

V>Ну дык впереди мейнстрима всвоё время точно, утверждалось именно это. Эрланг в упомянутом году считай что не существовал в сообществе, в отличие от паскаля, дельфи, оберона.

В каком мифическом обзестве сузествовал Оберон, что ты его упорно пытаешься сравнить с мейнстримом?

V>>>За тебя там бот ключевые слова в форум ложит или как? Или гугл не той системы.
M>>Отсылка в гугл == посыл на три известные буквы.
V>Если речь об инфе с первых страниц гугля — то заслужено.

Позиция «Ты тупой, я в белом платье» становится у тебя чертой характера

M>>Если ты не способен сам найти подтверждение своим словам, никто за тебя это делать не станет
V>Ключевые слова и технологии я перечислял. Есть опровержения — опровергай. Нет — свободен.

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

V>>>http://www.rsdn.ru/forum/design/816814.1.aspx
V>>>http://www.oberon.ethz.ch/bibliography/publications

M>>Ну наконец-то. Не прошло и трех дней, как ты смок выкопать одну ссылку.

V>Да их мильон, ссылок, включая по zonnon.

1) Мы говорили про РСДН
2) Я не собираюсь искать в этом миллионе ссылок сплошной бредятины одно-два нормальных сообщения

V>Я и сам ХЗ зачем я ссылку кинул с первой страницы гугля... слабину дал. Мне даже пофиг тот факт, что ты со своим мнением насчет АО сел в самую глубокую лужу во всём этом топике. Вот твой уровень:
V>

V>Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

V>Всерьез я на таком уровне обсуждать не намерен. В гугл!

В **югл. две с половиной страницы — это все, что есть в документации на сайте.

M>>Ничего я не забыл. Поэтому и говорю, что нормально про Оберон тут никто ничего не рассказывал.
V>1. Тебе никто ничего не должен.
V>2. Рассказывали достаточно.

Пункт второй является ложью, пока не доказано обратного.

V>Любому вменяемому спецу должно быть достаточно лишь упоминания ключевых фраз о технологиях, а дальше он копает сам... при желании. Ты же требуешь прожевать и в рот тебе положить. Т.е. желание пообщаться на форуме есть, а предварительно подготовиться — нет. Сразу свободен.

Я уже прекрасно подготовлен. д'Артаньяны от Оберона постарались.

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

V>Ибо такого баланса простоты внешней, но достаточно мощный заложенных ср-в, при этом надежности программ и эффективности целевого бинарного кода, как у виртовских языков, у других языков-совремнников НЕ БЫЛО. Это медицинский факт. Ну и скорость компиляции опять же. Я ведь вижу, что ты даже не задумался над тем вопросом, что найти этот баланс — непростая задача сама по себе.

1. Мощность вложенных средств — по сравнению с чем? Помнится, ни один защитничек не смог родить ответа на простейший вопрос типа «как мне сделать полиморфный map»
2. Скоростью компиляции давно (годов с 60-х прошлого века, наверное) никого не удивишь
3. Надежность программ на Обероне — миф. Можешь сам поискать эпические «ах, не подключайте модуль SYSTEM или модули, его использующие, будет плохо»

V>Даже посмотри на то, во что превратился исходный BASIC — в VB. Это же фактически Паскаль и есть, близнецы-браться. Даже опреатор WITH слизали... И этот язык тоже считался в нейтивные времена одним из самых надежных, почему на нем и было сделано куча бизнес-логики.

Думаю, если тебе показать J/K, то ты и там Оберон найдешь.

V>По мне самый удобный язык — С++, я тут в срачах всегда его отстаиваю. Но это не значит, что я не понимаю решений, заложенных в других языках. Поэтому и пользовал тот паскаль и дельфи мпериодически в своё время, когда им не было реальной альтернативы на многих нишах. Аналогично с VB. Аналогично потом с C#. Это же объектный паскаль с си-подобным синтаксисом. Ты разве не заметил?

Нет, не заметил. Потмоу что C# в разы сложнее и мощнее Паскаля.

V>Но у меня, сишника с 20-тилетним стажем, никаких комплексов по этому поводу... А у тебя и остальных хулителей виртовского направления я вижу только комплексы и ничего более.

Наши «комплексы», как ты их называешь подкрепляются солидными аргументами, которые ни ты, ни оберонщики тупо не видят, твердя «ах, в 98-м у нас все было», несмотря на то, что «все было» в других языках, и раньше, или не было в Обероне никогда, и не предвидится.

V>И вызванную этими комплексами избирательную слепоту. Ваши проблемы. Своё мение я уже высказал, добавить нечего. Если не обсуждать сфероконей, то виртовские языки — это были пригодные к промышленной разарботки системы в своё время. Тыкать в меня неработающими прототипам "старых идей", как пытается это делать Cyberax — бесполезно. Это всё было на моих глазах.

Что было на твоих глазах? Маргнальный Оберон, который «вобрал» в себя идеи 15-летней давности, и который ты пытаешься упорно сравнить с мейнстримом при том, что Оберон никогда мейнстримом не был? Нуну.

M>>Обрати внимание, ты привел ссылку, где есть действительно внятное объяснение. Где «крики» и «хамство», которое ты упорно видишь в каждом топике? Нет и близко. Только вот таких нормальных объяснений своей позиции за все время Оберона на РСДН было штуки две-три, а не «множество» или «много раз», как ты пытаешься тут рассказать.

V>Я пока на склероз не жалуюсь и помню всяко более одного внятного объяснения и обсуждения в те годы. Ну и когда ты стал ломать комедию насчет гугля — я проверил и увидел на первой странице на первых строчках требуемое. Сорри, но ты банальный тролль.

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

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

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

V>Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

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

Сорри, но если оф. документация содержит по этому поводу ровно две с половиной страницы, это не моя проблема, а документации — это раз.
Два: на данный момент Оберон и его «мегапробивные идеи» не нужны даже даром, по объективным причинам. Если ты желаешь поныть о крутых 90-х, и о том, как все было хорошо в 80-х — иди на оберонкор, где только этим и занимаются.

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

V>>>Да нельзя их сравнить. Для начально обучения ML-языки непригодны. Эффективность кода ML-языков ниже плинтуса и т.д.
C>>Давай мы сравним MoscowML образца 99-го года и Оберон того же года? Ты очень удивишься.
V>Давай, сравнивай.
Какую версию Оберона взять?

V>>>Генерируемый код не удовлетворяет нкаким требованиям.
C>>Ври, да не завирайся. Каким требованиям не удовлетворяет скомпилированный код ML?
V>Любым:
V>- объем бинарного кода;
Обычный объём.

V>- эффектвность;
Вполне эффективен.

V>- требования к оперативной памяти.
ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).

V>Из-за всего этого на ML невозможно писать для каких-нить военных железок.
Да ну?

V>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
Так, а теперь вопрос ребром:
ГДЕ КОД НА ОБЕРОНЕ?

V>На Дельфи можно. Ты же тыкаешь в меня ML-семейством, хотя его представители отличаются друг от друга всяко поболе, чем отличаются языки паскалевского семейства. Оставляешь себе некое пространство для маневра. Ну и я позволю.
ML-семейство — они обратно совместимы. Ну и Delphi похожа на Оберон примерно так же, как C++ похож на Алгол.

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

V>

V>Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

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

Аууууу?

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

V>>>>За тебя там бот ключевые слова в форум ложит или как? Или гугл не той системы.
M>>>Отсылка в гугл == посыл на три известные буквы.
V>>Если речь об инфе с первых страниц гугля — то заслужено.

M>Позиция «Ты тупой, я в белом платье» становится у тебя чертой характера

Да нет, это у тебя в последние 2-3 года сформировалась странная позиция "вот объясните мне, тупому"...
Уже сказал — тебе никто ничего не должен. Мы все на этом форуме работаем за интерес.

M>>>Если ты не способен сам найти подтверждение своим словам, никто за тебя это делать не станет
V>>Ключевые слова и технологии я перечислял. Есть опровержения — опровергай. Нет — свободен.

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

Тебе никто ничего не должен.

V>>>>http://www.rsdn.ru/forum/design/816814.1.aspx
V>>>>http://www.oberon.ethz.ch/bibliography/publications

M>>>Ну наконец-то. Не прошло и трех дней, как ты смок выкопать одну ссылку.
V>>Да их мильон, ссылок, включая по zonnon.

M>1) Мы говорили про РСДН
M>2) Я не собираюсь искать в этом миллионе ссылок сплошной бредятины одно-два нормальных сообщения

Тебе никто ничего не должен.

Когда я не собираюсь искать информацию по какому-то вопросу, я не лезу по этому вопросу спорить. Медитировать над этой фразой до просветления. Ведь мне, выходит, искомая информаци НЕИНТЕРЕСНА. Сейчас же твои мотивы для спора попахивают чем-то нехорошим и зеленым. Решил потыкать в меня палочкой? Понаблюдать за реакций?

M>В **югл. две с половиной страницы — это все, что есть в документации на сайте.

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

M>>>Ничего я не забыл. Поэтому и говорю, что нормально про Оберон тут никто ничего не рассказывал.
V>>1. Тебе никто ничего не должен.
V>>2. Рассказывали достаточно.

M>Пункт второй является ложью, пока не доказано обратного.

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

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

V>>Любому вменяемому спецу должно быть достаточно лишь упоминания ключевых фраз о технологиях, а дальше он копает сам... при желании. Ты же требуешь прожевать и в рот тебе положить. Т.е. желание пообщаться на форуме есть, а предварительно подготовиться — нет. Сразу свободен.

M>Я уже прекрасно подготовлен. д'Артаньяны от Оберона постарались.

Странно, что объектный паскаль и дельфи не вызывали такую же реакцию, хотя оберон-2, к примеру, это более "вылизанный" вариант того же самого. Неужели личность некоего расказчика способна повлиять на мнение о технологии? Что за бред? А самостоятельно поинтересоваться уже никак, если расказчик раздражает?

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

V>>Ибо такого баланса простоты внешней, но достаточно мощный заложенных ср-в, при этом надежности программ и эффективности целевого бинарного кода, как у виртовских языков, у других языков-совремнников НЕ БЫЛО. Это медицинский факт. Ну и скорость компиляции опять же. Я ведь вижу, что ты даже не задумался над тем вопросом, что найти этот баланс — непростая задача сама по себе.

M>1. Мощность вложенных средств — по сравнению с чем?

С мейнстримом. См. начало этой подветки.

M>Помнится, ни один защитничек не смог родить ответа на простейший вопрос типа «как мне сделать полиморфный map»

На полиморфных типах, вестимо. Хочешь большего — уточни интересующий вид полиморфизма.

M>2. Скоростью компиляции давно (годов с 60-х прошлого века, наверное) никого не удивишь

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

M>3. Надежность программ на Обероне — миф. Можешь сам поискать эпические «ах, не подключайте модуль SYSTEM или модули, его использующие, будет плохо»

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

V>>Даже посмотри на то, во что превратился исходный BASIC — в VB. Это же фактически Паскаль и есть, близнецы-браться. Даже опреатор WITH слизали... И этот язык тоже считался в нейтивные времена одним из самых надежных, почему на нем и было сделано куча бизнес-логики.

M>Думаю, если тебе показать J/K, то ты и там Оберон найдешь.

Я думаю, что ты всерьез VB/VBA не видел. Если интересно — можно побсуждать изменение конструкций языка при движении его от BASIC к VB.

V>>По мне самый удобный язык — С++, я тут в срачах всегда его отстаиваю. Но это не значит, что я не понимаю решений, заложенных в других языках. Поэтому и пользовал тот паскаль и дельфи мпериодически в своё время, когда им не было реальной альтернативы на многих нишах. Аналогично с VB. Аналогично потом с C#. Это же объектный паскаль с си-подобным синтаксисом. Ты разве не заметил?

M>Нет, не заметил. Потмоу что C# в разы сложнее и мощнее Паскаля.

Какой именно C#? Вот буквально последних несколько версий? И в чем для тебя сложность C#? Поделись, растолкуем тебе любую сложность. C# отличается от объектных паскалей только сиподобным синтаксисом и немного новомодным сахарком вокруг yied и лямбд. А всё остальное содрано с виртовских языков под копирку. Даже точно такие же обероновские делегаты были введены в систему типов с одноименным названием.

V>>Но у меня, сишника с 20-тилетним стажем, никаких комплексов по этому поводу... А у тебя и остальных хулителей виртовского направления я вижу только комплексы и ничего более.

M>Наши «комплексы», как ты их называешь подкрепляются солидными аргументами, которые ни ты, ни оберонщики тупо не видят,

Да, я не вижу ни одного твоего аргумента. Давай хотя бы относительно C#, похоже ты видел его в глаза. Вот давай посравниваем твои "аргументы". Я вижу целиком виртовскую парадигму в другом синтаксисе, покажи чего там сверху или сложного?

V>>И вызванную этими комплексами избирательную слепоту. Ваши проблемы. Своё мение я уже высказал, добавить нечего. Если не обсуждать сфероконей, то виртовские языки — это были пригодные к промышленной разарботки системы в своё время. Тыкать в меня неработающими прототипам "старых идей", как пытается это делать Cyberax — бесполезно. Это всё было на моих глазах.

M>Что было на твоих глазах? Маргнальный Оберон, который «вобрал» в себя идеи 15-летней давности, и который ты пытаешься упорно сравнить с мейнстримом при том, что Оберон никогда мейнстримом не был? Нуну.

Разве Паскаль и Дельфи не были мейнстримом? Не хочешь показать список отличий оберона от привычного тебе паскаля? А то вы тут так резво наглухо отличающимися ML-языками размахивали, что пора вас в это ткнуть носом.

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

M>Я ссылки на то, о чем говорил, привожу. Ты способен только пожаловаться, что «в гугле все есть» и потратить три дня на поиски единственной ссылки, которая хоть как-то подтверждает твои слова.

Кто три дня потратил? Ты? Ты и минуты не потратил. Я тебя не просто в гугль отправил, а с нужным запросом, где нужный результат был во второй строчке сверху. Эти три дня — цена твоей лени и безалаберности.

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

Чего-чего?

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

V>>Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

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

M>Сорри, но если оф. документация содержит по этому поводу ровно две с половиной страницы, это не моя проблема, а документации — это раз.

Чего-чего?
http://www.ethoberon.ethz.ch/compiler/index.html
Тебе вообще не стыдно светить такой поверхностостью на весь и-нет? Опять с гуглем проблемы?

M>Два: на данный момент Оберон и его «мегапробивные идеи» не нужны даже даром, по объективным причинам.

Объясни это разработчикам Сингулярити и разработчикам C#, которые сделают очередное изменение в этом языке. И все признают, что для мейнстрима это круто.

M>Если ты желаешь поныть о крутых 90-х, и о том, как все было хорошо в 80-х — иди на оберонкор, где только этим и занимаются.

Ноешь только ты, цепляясь за островки своей эрудиции. Тебя раздражает ЛЮБАЯ необходимость что-то просмотреть самостоятельно. Мне даже трудно подобрать слова, чтобы описать полезность таких манер для целей профпригодности...

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

V>>

V>>Посмотрел я на две с половиной страницы документации по ActiveOberon. мьютексы и локи на ровном месте, попытка параллелить циклы инструкциями к компилятору и... все.

C>Ну если ты так уверен, что Оберон — это передовой край, то расскажи что же такого в AO нового. Покажи нам промышленный код, который его использует, расскажи истории успеха.

Новое в нем было понимание небходимости делать специальную ОСь по это дело. Для сравнения, современный Эрланг, работающий поверх традиционных ОСей имеет кучу граблей (например, вокруг ввода-вывода), которые (грабли) не имеет АОС. Второй раз на сравнимом уровне те же самые идеи АОС были повторены уже в рамках Сингулярити. Дургих сравнимых по готовности проектов на этоу тему в природе НЕТ.

Почему бы тебе не попытаться понасмехаться над Сингулярити? Я тут знаю человека, который тебя в блин за неё раскатает.

Мне то банально лень, с вами, беспокойными, спорить. Я делюсь полезной инфой — показываю на замеченную идентичногсть идей, лежащих в основе различных разработок. Ты изучал репорт по Сингулярити? А изучал репорт по АО? Если и после этого ты не видишь идентичность идей, то говорить не о чем.

C>Аууууу?

Совсем потерялся?

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

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

Я конечно все понимаю срач (и поэтому стараюсь только читать) но "недотипизированный OCaml" меня просто убил, так что даже
конструктивно возражать тебе расхотелось

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

V>Новое в нем было понимание небходимости делать специальную ОСь по это дело. Для сравнения, современный Эрланг, работающий поверх традиционных ОСей имеет кучу граблей (например, вокруг ввода-вывода), которые (грабли) не имеет АОС. Второй раз на сравнимом уровне те же самые идеи АОС были повторены уже в рамках Сингулярити. Дургих сравнимых по готовности проектов на этоу тему в природе НЕТ.
Я понимаю, Гуглом ты пользоваться не умеешь. Hint: Smalltalk и LISP.

V>Мне то банально лень, с вами, беспокойными, спорить. Я делюсь полезной инфой — показываю на замеченную идентичногсть идей, лежащих в основе различных разработок. Ты изучал репорт по Сингулярити? А изучал репорт по АО? Если и после этого ты не видишь идентичность идей, то говорить не о чем.

Я вижу, что в Обероне — унылое Г. И в отличие от тебя я его реально смотрел.

C>>Аууууу?
V>Совсем потерялся?
Так где там production-софт? ГДЕ?

V>>>Любому вменяемому спецу должно быть достаточно лишь упоминания ключевых фраз о технологиях, а дальше он копает сам... при желании. Ты же требуешь прожевать и в рот тебе положить. Т.е. желание пообщаться на форуме есть, а предварительно подготовиться — нет. Сразу свободен.

M>>Я уже прекрасно подготовлен. д'Артаньяны от Оберона постарались.

V>Странно, что объектный паскаль и дельфи не вызывали такую же реакцию, хотя оберон-2, к примеру, это более "вылизанный" вариант того же самого. Неужели личность некоего расказчика способна повлиять на мнение о технологии? Что за бред? А самостоятельно поинтересоваться уже никак, если расказчик раздражает?

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

V>>>Ибо такого баланса простоты внешней, но достаточно мощный заложенных ср-в, при этом надежности программ и эффективности целевого бинарного кода, как у виртовских языков, у других языков-совремнников НЕ БЫЛО. Это медицинский факт. Ну и скорость компиляции опять же. Я ведь вижу, что ты даже не задумался над тем вопросом, что найти этот баланс — непростая задача сама по себе.

M>>1. Мощность вложенных средств — по сравнению с чем?
V>С мейнстримом. См. начало этой подветки.

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

Например, про Java: http://rsdn.ru/forum/philosophy/1420819.1.aspx. Вся, ну абсолютно вся слизана с Оберона, настолько, что Оберон вообще нигде не упоминается, даже как источник вдохновения. Да и Паскаль там тоже наравне с другими языками. Ну и здесь и здесь правильно сказано.

Про C# сложнее, потому что имя Хейлсберг тебе затуманит весь взор. http://www.se-radio.net/2008/05/episode-97-interview-anders-hejlsberg/ Из Delphi в C# пришли properties и events as first-class notions. Жалко, сказано мало, но модульность явно было не ключевым моментом. Есть еще интервью тут: http://www.mindviewinc.com/mediacast/interviews/Index.php но лень слушать.

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

M>>Помнится, ни один защитничек не смог родить ответа на простейший вопрос типа «как мне сделать полиморфный map»
V>На полиморфных типах, вестимо. Хочешь большего — уточни интересующий вид полиморфизма.

Ссылку на вопрос я приводил. Сколько лет прошло, так никто и не ответил.

M>>2. Скоростью компиляции давно (годов с 60-х прошлого века, наверное) никого не удивишь
V>Второй столько же универсальный и эффективный в конечном коде инструмент Си — сливал очень сильно по многим параметрам. Влючая типизацию ивыразительность. Да и С++ был тогда еще не в лучшем виде, не сравнить с сейчас.

Ну да, у нас же принято сравнивать только с С++.... Ну и да, этот вопрос уже тоже обсуждался.

M>>3. Надежность программ на Обероне — миф. Можешь сам поискать эпические «ах, не подключайте модуль SYSTEM или модули, его использующие, будет плохо»
V>Не миф. Мне есть с чем сравнить. На паскалеподобных языках меньше делают ошибок на каждый чих, в сравнении с недотипизированными OCaml или Си. А упоминания тобой динамических языков я вообще позволю себе проигнорировать.

Мифическая безопасность:
http://rsdn.ru/forum/philosophy/1002532.aspx
http://rsdn.ru/forum/philosophy/1002592.aspx
http://rsdn.ru/forum/philosophy/1006880.aspx (это завершение эпической подветки)
и т.п.

V>>>По мне самый удобный язык — С++, я тут в срачах всегда его отстаиваю. Но это не значит, что я не понимаю решений, заложенных в других языках. Поэтому и пользовал тот паскаль и дельфи мпериодически в своё время, когда им не было реальной альтернативы на многих нишах. Аналогично с VB. Аналогично потом с C#. Это же объектный паскаль с си-подобным синтаксисом. Ты разве не заметил?

M>>Нет, не заметил. Потмоу что C# в разы сложнее и мощнее Паскаля.

V>Какой именно C#? Вот буквально последних несколько версий? И в чем для тебя сложность C#? Поделись, растолкуем тебе любую сложность. C# отличается от объектных паскалей только сиподобным синтаксисом и немного новомодным сахарком вокруг yied и лямбд. А всё остальное содрано с виртовских языков под копирку. Даже точно такие же обероновские делегаты были введены в систему типов с одноименным названием.

Берешь в руки спеки одного языка и другого языка и сравниваешь.

V>>>И вызванную этими комплексами избирательную слепоту. Ваши проблемы. Своё мение я уже высказал, добавить нечего. Если не обсуждать сфероконей, то виртовские языки — это были пригодные к промышленной разарботки системы в своё время. Тыкать в меня неработающими прототипам "старых идей", как пытается это делать Cyberax — бесполезно. Это всё было на моих глазах.

M>>Что было на твоих глазах? Маргнальный Оберон, который «вобрал» в себя идеи 15-летней давности, и который ты пытаешься упорно сравнить с мейнстримом при том, что Оберон никогда мейнстримом не был? Нуну.

V>Разве Паскаль и Дельфи не были мейнстримом?

Где в слове Паскль и Дельфи есть слово Оберон?

V>Не хочешь показать список отличий оберона от привычного тебе паскаля? А то вы тут так резво наглухо отличающимися ML-языками размахивали, что пора вас в это ткнуть носом.

Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

Что из этого есть в Паскале, что есть в Дельфи?

V>Оберон — это отполированный результат по факту исопльзования паскалеподобных языков в мейнстриме. Не более того. А ты пытаешься делать вид, что это какой-то совершенно новый язык, упавший с Луны.

Только к мейнстриму он не имеет ни малейшего отношения.

M>>Два: на данный момент Оберон и его «мегапробивные идеи» не нужны даже даром, по объективным причинам.
V>Объясни это разработчикам Сингулярити и разработчикам C#, которые сделают очередное изменение в этом языке. И все признают, что для мейнстрима это круто.

Покажи изменения в C#, которые «скопированы из Оберона». Можешь начинать с лямбд.

M>>Если ты желаешь поныть о крутых 90-х, и о том, как все было хорошо в 80-х — иди на оберонкор, где только этим и занимаются.

V>Ноешь только ты, цепляясь за островки своей эрудиции. Тебя раздражает ЛЮБАЯ необходимость что-то просмотреть самостоятельно. Мне даже трудно подобрать слова, чтобы описать полезность таких манер для целей профпригодности...

Удивительно, как это я на Erlang'е стал программировать, если меня раздражает необходимость что-то посмотреть самосотятельно

Это к вопросу о твоих способностях фантазировать.

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

V>>Новое в нем было понимание небходимости делать специальную ОСь по это дело. Для сравнения, современный Эрланг, работающий поверх традиционных ОСей имеет кучу граблей (например, вокруг ввода-вывода), которые (грабли) не имеет АОС. Второй раз на сравнимом уровне те же самые идеи АОС были повторены уже в рамках Сингулярити. Дургих сравнимых по готовности проектов на этоу тему в природе НЕТ.
C>Я понимаю, Гуглом ты пользоваться не умеешь. Hint: Smalltalk и LISP.

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

Ты вообще на каких языках большей частью пишешь, если не секрет?

V>>Мне то банально лень, с вами, беспокойными, спорить. Я делюсь полезной инфой — показываю на замеченную идентичногсть идей, лежащих в основе различных разработок. Ты изучал репорт по Сингулярити? А изучал репорт по АО? Если и после этого ты не видишь идентичность идей, то говорить не о чем.

C>Я вижу, что в Обероне — унылое Г. И в отличие от тебя я его реально смотрел.

Значит так смотрел. А много ли ты писал в на паскалевских языках? Или только смотрел?

К тому же, игнор сравения с Сингулярити подтверждает мои догадки, что ты всё это время даже не в курсе, о чём я тут. ИМХО, обсуждение моделей различных оберонов можно на этом свернуть. Спорить с "не читал, но осуждаю" бессмысленно.

>>>Аууууу?
V>>Совсем потерялся?
C>Так где там production-софт? ГДЕ?

Примеры приводились не раз. Раз в год спрашивать будете? LapteVV приводил список когда-то. Ты-то хоть умеешь гуглом пользоваться?

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

V>>Ну дык впереди мейнстрима всвоё время точно, утверждалось именно это. Эрланг в упомянутом году считай что не существовал в сообществе, в отличие от паскаля, дельфи, оберона.

M>В каком мифическом обзестве сузествовал Оберон, что ты его упорно пытаешься сравнить с мейнстримом?

Я тебе отвечу после твоего домашнего задания — сравнить паскалевские языки м/у собой. В мейнстриме было целое их семейство. И я лично наблюдал, как паскалисты-дельфисты юзали в т.ч. Оберон по накатанной. По мне это всё близнецы-братья. Я ХЗ почему ты решил что Оберон — это какой-то совершенно другой язык. Тот же самый, слегка отшлифованный. Или ты не застал эпоху Паскалей?

V>>>Ну дык впереди мейнстрима всвоё время точно, утверждалось именно это. Эрланг в упомянутом году считай что не существовал в сообществе, в отличие от паскаля, дельфи, оберона.

M>>В каком мифическом обзестве сузествовал Оберон, что ты его упорно пытаешься сравнить с мейнстримом?

V>Я тебе отвечу после твоего домашнего задания — сравнить паскалевские языки м/у собой. В мейнстриме было целое их семейство. И я лично наблюдал, как паскалисты-дельфисты юзали в т.ч. Оберон по накатанной. По мне это всё близнецы-братья. Я ХЗ почему ты решил что Оберон — это какой-то совершенно другой язык. Тот же самый, слегка отшлифованный. Или ты не застал эпоху Паскалей?

Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

Что из этого есть в Паскале, что есть в Дельфи?

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

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

FR>Я конечно все понимаю срач (и поэтому стараюсь только читать) но "недотипизированный OCaml" меня просто убил, так что даже
FR>конструктивно возражать тебе расхотелось

А что тут можно возразить-то?

Что есть, то есть... Не напомнишь другим читателем, с какой радости у него целое число 31-битное на 32-хбитной архитектуре. Или почему в ML-языке есть конструкции по обходу системы типов, ничем не лучших произвольной реинтерпретации в стиле Си? Для каких целей дизайна языка существует модуль Obj?

Давай, попытайся конструктивно. Успехов.

Потом можно поговорить о тормозах конечного бинарника. Там вообще туши свет.

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

V>>Странно, что объектный паскаль и дельфи не вызывали такую же реакцию, хотя оберон-2, к примеру, это более "вылизанный" вариант того же самого. Неужели личность некоего расказчика способна повлиять на мнение о технологии? Что за бред? А самостоятельно поинтересоваться уже никак, если расказчик раздражает?

M>Когда рассказчики не могут сами внятно понять, о каком языке они ведут речь — о Паскале ли, о Компонентном Паскале ли, об Обероне, об Активном Обероне, о Зонноне, о Модуле и т.п.,

И что? Я писал когда-то одновременно на нескольких диалектах С++, по диалекту на каждый используемый компилятор. Более-менее различные компиляторы стали близки только примерно в 2005-м году... А до этого даже банальное наличие или отсутствие частичной специализации значили гораздо более кардинальные отличия в принципах исопльзования диалектов С++, чем отличия всех языков из твоего списка. И ничего, живы здоровы.

Да и С# уже трижды на моей памяти менял диалекты и т.д. и т.п. Но тебе, ес-но, наличие диалектов мешает толькол в случае Оберона. ЧТД.

M>и не способны ответить на простейшие вопросы, то да, может повлиять.

Твои вопросы не простейшие, а тупейшие. ИМХО, ты специально так ведешь беседу, чтобы раздражать оппонента. Задавай более предметные вопросы или испарись.

M>>>1. Мощность вложенных средств — по сравнению с чем?
V>>С мейнстримом. См. начало этой подветки.

M>На какой-нибудь 98-й год может быть — и то вряд ли.

Никаких вряд ли. VB и паскалевское семейство заруливали в мейнстриме всех еще в 98-м.

M>На 2012-й год это воспоминанья старины глубокой.

Мде, и что у нас в альтернативе? С++? У которого 10 лет стадарт принять не могли? Или C#, который каждый раз разный?
Я наоборот вижу полнейший застой последние лет 12 в IT, в сравнении с мощным развитием в конце 80-х и все 90-е. И только буквально последние 2-3 года идут какие-то шевеления.

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

С таким балансом качеств (уже перечислял) он был таки лучшим. С этим даже глупо спорить. Хоть я и терпеть не мог Дельфи (и мне удалось избегать его по работе все годы его расцвета), но такого уровня систему на тех плюсах было не поднять. Одно это уже немаловажный факт. На никаком другом языке тоже. Даже тот момент, что АПИ виндов и OLE имеют паскалевские соглашения о вызовах, как бэ много о чем намекает о корнях этой операционки.

M>Например, про Java: http://rsdn.ru/forum/philosophy/1420819.1.aspx. Вся, ну абсолютно вся слизана с Оберона, настолько, что Оберон вообще нигде не упоминается, даже как источник вдохновения.

Мде? Чукча писатель?

Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal. Моя заслуга в том, что я смог их совместить. (Джеймс Гослинг)

M>Да и Паскаль там тоже наравне с другими языками.

Да нет никакого наравне. От ЛИСПА там аж нихрена, кроме подхода к коду как к данным, но это относится к архитектуре VM, а не к языку. Насчет Smalltalk он себе явно льстит. В Джаве такой же точно механизм рантайм-полиморфизма как в объектных паскалях с точностью до деталей реализации. И даже наследование интерфейсов вместо МН реализаций. Это в каком Лиспе он такое подсмотрел? В других упомянутых языках полиморфизм устроен существенно иначе, чем в джаве и паскале. А фишка Джавы, если забыл — это все методы по-умолчанию полиморфны. Ну ты понял, куда акцент.

M>Ну и здесь

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

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

M>и здесь правильно сказано.

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

Ну и я помню, что у нас в ВУЗе преподавался Паскаль первые пол-года... Тут даже обсуждать нечего, ес-но лучше преподавать сразу Оберон по императивным языкам.
Даже такая новая мелочь как:

В Обероне экспортируемые имена просто помечаются звездочкой (*)

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

M>Про C# сложнее, потому что имя Хейлсберг тебе затуманит весь взор. http://www.se-radio.net/2008/05/episode-97-interview-anders-hejlsberg/ Из Delphi в C# пришли properties и events as first-class notions. Жалко, сказано мало, но модульность явно было не ключевым моментом.

Все моменты ключевые:
— принципы модульности (сравни с джавой, где только пакеты-неймспейсы, а модули дотнета ортогональны неймспейсам);
— механика рантайм-полиморфизма;
— делегаты;
— события и св-ва;
— развитый RTTI;
— одиночное наследование классов и можественное интерфейсов;
— "родная" стыковка с COM и основными value-типами OLE;

Пририсуй сюда Си-подобный синтаксис и ты получишь первый дотнет и первый C#. Вот с этой точки они начали плясать и на этом стали строить далее. И не говорите мне, что это не Паскаль с сишным синтаксисом.

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

M>Ах, и не забыть про Simula.

Забудь, мимо. Полиморфизм не такой. Как в Objective-C. Ну и основные идеи Паскаля таки не в ООП, а в некоем балансе характеристик языка.

M>Но да, но да, именно Оберон был первым исключительно во всем!

Не изобретай, лишнего. Было сказано, что не первым, а раньше. И в промышленных масштабах. Просто в Паскале все эти подходы нехило обкатали в 80-90-е... Что даже Гейтс привёл свой первоначальный Бейсик к чисто паскалевскому виду.

M>Все остальные — лишь нагло копируют!

Про копиорвание речи не было, мне это неинтересно. См. начало этой ветки.

M>>>Помнится, ни один защитничек не смог родить ответа на простейший вопрос типа «как мне сделать полиморфный map»
V>>На полиморфных типах, вестимо. Хочешь большего — уточни интересующий вид полиморфизма.

M>Ссылку на вопрос я приводил. Сколько лет прошло, так никто и не ответил.

Я тебе ответил только что. Еще вопросы? Или ты решил не уточнять требуемый тебе вид полиморфизма?

M>Ну да, у нас же принято сравнивать только с С++....

Дык, а куда ты от мейнстрима денешься? Остальное существует постольку-поскольку...

M>Мифическая безопасность:
M>http://rsdn.ru/forum/philosophy/1002532.aspx

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

M>http://rsdn.ru/forum/philosophy/1006880.aspx (это завершение эпической подветки)

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

M>и т.п.

Мде, круто, что сказать...
Но зато славно пособачились, правда? Мои поздравления, "коллеги".

V>>Какой именно C#? Вот буквально последних несколько версий? И в чем для тебя сложность C#? Поделись, растолкуем тебе любую сложность. C# отличается от объектных паскалей только сиподобным синтаксисом и немного новомодным сахарком вокруг yied и лямбд. А всё остальное содрано с виртовских языков под копирку. Даже точно такие же обероновские делегаты были введены в систему типов с одноименным названием.

M>Берешь в руки спеки одного языка и другого языка и сравниваешь.

Сам текст спек сравнивать или что? У тебя есть ссылка на "авторитетное сравнение спек"? А может, ты врешь?

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

V>>>>И вызванную этими комплексами избирательную слепоту. Ваши проблемы. Своё мение я уже высказал, добавить нечего. Если не обсуждать сфероконей, то виртовские языки — это были пригодные к промышленной разарботки системы в своё время. Тыкать в меня неработающими прототипам "старых идей", как пытается это делать Cyberax — бесполезно. Это всё было на моих глазах.

M>>>Что было на твоих глазах? Маргнальный Оберон, который «вобрал» в себя идеи 15-летней давности, и который ты пытаешься упорно сравнить с мейнстримом при том, что Оберон никогда мейнстримом не был? Нуну.

V>>Разве Паскаль и Дельфи не были мейнстримом?

M>Где в слове Паскль и Дельфи есть слово Оберон?

Примерно там же, где в слове Delphi есть слово Object Pascal. Только Оберон к исходному Паскалю даже ближе.

V>>Не хочешь показать список отличий оберона от привычного тебе паскаля? А то вы тут так резво наглухо отличающимися ML-языками размахивали, что пора вас в это ткнуть носом.

M>

M> Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>Что из этого есть в Паскале, что есть в Дельфи?

А с чего ты решил, что в одном предложении перечислил все идеи?

V>>Оберон — это отполированный результат по факту исопльзования паскалеподобных языков в мейнстриме. Не более того. А ты пытаешься делать вид, что это какой-то совершенно новый язык, упавший с Луны.
M>Только к мейнстриму он не имеет ни малейшего отношения.

1. Как диалект Паскаля — имеет.
2. Вся ветка началась не с бсуждения того, является Оберон мейнстримом или нет, а чуть с другого. Ты сам только что привел, а теперь пытаешься нелепо жонглировать. Не выйдет.

M>>>Два: на данный момент Оберон и его «мегапробивные идеи» не нужны даже даром, по объективным причинам.
V>>Объясни это разработчикам Сингулярити и разработчикам C#, которые сделают очередное изменение в этом языке. И все признают, что для мейнстрима это круто.

M>Покажи изменения в C#, которые «скопированы из Оберона». Можешь начинать с лямбд.

Можешь сходить до ветра. Говорить про лямбды в будущем числе, как в исходном предложении я не сумею, увы. Если сумеешь ты — просим.

V>>Ноешь только ты, цепляясь за островки своей эрудиции. Тебя раздражает ЛЮБАЯ необходимость что-то просмотреть самостоятельно. Мне даже трудно подобрать слова, чтобы описать полезность таких манер для целей профпригодности...

M>Удивительно, как это я на Erlang'е стал программировать, если меня раздражает необходимость что-то посмотреть самосотятельно

Это к вопросу о твоих способностях фантазировать.

А фигли на динамических языках программировать? При наличии полноценного REPL? Дуй да нажимай посильней. Я не помню ни одного динамического языка, хотя писал местами довольно объемно на питоне, перле, рексе, баше, JS, Схеме и т.д... Отладил в репле/тестах и благополучно спустя месяц-другой забыл... При наличии интернета под боком это х-ня на палочке, на которую жалко тратить кванты внимания.

V>>>Не хочешь показать список отличий оберона от привычного тебе паскаля? А то вы тут так резво наглухо отличающимися ML-языками размахивали, что пора вас в это ткнуть носом.

M>>

M>> Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>>Что из этого есть в Паскале, что есть в Дельфи?

V>А с чего ты решил, что в одном предложении перечислил все идеи?

Все скипнуто, пока ты не ответишь на выделенное.

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

M>

M>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>Что из этого есть в Паскале, что есть в Дельфи?

А что из этого утверждалось, что есть в Паскале и есть в Дельфи?

M>>

M>>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>>Что из этого есть в Паскале, что есть в Дельфи?

V>А что из этого утверждалось, что есть в Паскале и есть в Дельфи?

Чтобы не вести две параллельные ветки, тут: http://rsdn.ru/forum/philosophy/4808935.1.aspx

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

V>А что тут можно возразить-то?

Что есть, то есть... Не напомнишь другим читателем, с какой радости у него целое число 31-битное на 32-хбитной архитектуре.

Это не имеет никакого отношения к "типизированости".

V>Или почему в ML-языке есть конструкции по обходу системы типов, ничем не лучших произвольной реинтерпретации в стиле Си? Для каких целей дизайна языка существует модуль Obj?

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

V>Давай, попытайся конструктивно. Успехов.

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

V>Потом можно поговорить о тормозах конечного бинарника. Там вообще туши свет.

Для современного уровня согласен, плохо примерно как у плохо оптимизирующих С/C++ компиляторов.
Но это точно не изъян языка, банально недостаток ресурсов для написания нормальных оптимизирующих
компиляторов.

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

V>Или почему в ML-языке есть конструкции по обходу системы типов, ничем не лучших произвольной реинтерпретации в стиле Си?

??

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

V>А что тут можно возразить-то?

Что есть, то есть... Не напомнишь другим читателем, с какой радости у него целое число 31-битное на 32-хбитной архитектуре.
Какое это имеет отношение к типизированности?

Да, не во всех реализациях ML теряется один бит.

V>Или почему в ML-языке есть конструкции по обходу системы типов, ничем не лучших произвольной реинтерпретации в стиле Си? Для каких целей дизайна языка существует модуль Obj?
Для каких целей в Обероне существует модуль SYSTEM?

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

V>>А что тут можно возразить-то?

Что есть, то есть... Не напомнишь другим читателем, с какой радости у него целое число 31-битное на 32-хбитной архитектуре.
FR>Это не имеет никакого отношения к "типизированости".

Разве? Это прямое следствие возможности в runtime недостоверно знать типы объектов.

V>>Или почему в ML-языке есть конструкции по обходу системы типов, ничем не лучших произвольной реинтерпретации в стиле Си? Для каких целей дизайна языка существует модуль Obj?
FR>В любом языке который хоть как-то используется на практике такие конструкции есть и будут, но
FR>используются они только в крайних случаях.

В Хаскеле же нет. И во многих ML-диалектах тоже.

FR>Как будто в обероне такого нет, есть и скорее всего используется гораздо чаще.

В самом Обероне, как в языке — нет. Такой модуль возник позже для целей написания операционных систем на Обероне. Надо же как-то обработчик на аппаратное прерывание посадить... А вот для чего такой модуль существует в платформе OCaml — большой вопрос.

FR>С тобой тем более сейчас бесполезно, скорее всего опять начнешь отыскивать что-то в дебрях реализации
FR>в стиле в OCaml есть goto так как в ассемблерном листинге полно jmp, и упираться до конца

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

V>>Потом можно поговорить о тормозах конечного бинарника. Там вообще туши свет.
FR>Для современного уровня согласен, плохо примерно как у плохо оптимизирующих С/C++ компиляторов.

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

FR>Но это точно не изъян языка, банально недостаток ресурсов для написания нормальных оптимизирующих компиляторов.

Нет, это язъян языка, преодолеть который можено только его редизайном. Это исскуственное ограничение сверху нафик не нужное. Мы тут где-то рядом с Вльфхаундом обсуждали принципы работы GC и возможные варианты обслуживания метаинформации при обобщенном GC. Хотя, само обсуждение не ахти, но любую из озвученных полезных идей должно было бы быть несложно вставить в OCaml. Это было бы действительно современно. А так... без обид, по мне OCaml такое же г-но мамонта, как Паскаль образца 88-го года.

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

M>Все скипнуто, пока ты не ответишь на выделенное.

Вот и отлично. Рзабираться в твоём жонглировании фразами из всевозможных веток и контекстов мне надоело.

M>>Все скипнуто, пока ты не ответишь на выделенное.

V>Вот и отлично. Рзабираться в твоём жонглировании фразами из всевозможных веток и контекстов мне надоело.

Что и ожидалось: ответить на простейший вопрос ты не в состоянии.

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

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

V>>>>Да нельзя их сравнить. Для начально обучения ML-языки непригодны. Эффективность кода ML-языков ниже плинтуса и т.д.
C>>>Давай мы сравним MoscowML образца 99-го года и Оберон того же года? Ты очень удивишься.
V>>Давай, сравнивай.
C>Какую версию Оберона взять?

Самую лучшую на твой взгляд.

V>>>>Генерируемый код не удовлетворяет нкаким требованиям.
C>>>Ври, да не завирайся. Каким требованиям не удовлетворяет скомпилированный код ML?
V>>Любым:
V>>- объем бинарного кода;
C>Обычный объём.

Конкретно OCaml — хреновый объем.

V>>- эффектвность;
C>Вполне эффективен.

Нет.

V>>- требования к оперативной памяти.
C>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).

Я видел как даже сугубо вычислительные алгоритмы на динамических языках обкатывались и какой из этого вывод? Аж никакой.

V>>Из-за всего этого на ML невозможно писать для каких-нить военных железок.
C>Да ну?

Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.

V>>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
C>Так, а теперь вопрос ребром:
C>ГДЕ КОД НА ОБЕРОНЕ?

Был там же в тех же обсуждениях, в которых ты участвовал. ЛаптевВВ приводил примеры.

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

C>>Какую версию Оберона взять?
V>Самую лучшую на твой взгляд.
Ткни пальцем.

V>>>- объем бинарного кода;
C>>Обычный объём.
V>Конкретно OCaml — хреновый объем.
Врёшь.

V>>>- эффектвность;
C>>Вполне эффективен.
V>Нет.
Врёшь.

V>>>- требования к оперативной памяти.
C>>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).
V>Я видел как даже сугубо вычислительные алгоритмы на динамических языках обкатывались и какой из этого вывод? Аж никакой.
Слушай, после "слаботипизированного ML" с тобой говорить не о чем.

V>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?

V>>>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
C>>Так, а теперь вопрос ребром:
C>>ГДЕ КОД НА ОБЕРОНЕ?
V>Был там же в тех же обсуждениях, в которых ты участвовал. ЛаптевВВ приводил примеры.
ГДЕ КОД НА ОБЕРОНЕ?
ГДЕ КОД НА ОБЕРОНЕ?
ГДЕ КОД НА ОБЕРОНЕ?
ГДЕ КОД НА ОБЕРОНЕ?
ГДЕ КОД НА ОБЕРОНЕ?
ГДЕ КОД НА ОБЕРОНЕ?

Достаточно? Приведи хотя бы штук 5-7 ссылок на проекты с достаточно большим (десятки тысяч строк) объёмом кода на Oberon.

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

V>Разве? Это прямое следствие возможности в runtime недостоверно знать типы объектов.

К типизации никакого отношения не имеет. Имеет отношение только к реализации, которая выжимала из
тогдашних машинок максимум возможного.

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

V>В Хаскеле же нет. И во многих ML-диалектах тоже.

Реинтерпретация памяти в том или ином виде есть. Тегового бита нет конечно.

FR>>Как будто в обероне такого нет, есть и скорее всего используется гораздо чаще.

V>В самом Обероне, как в языке — нет. Такой модуль возник позже для целей написания операционных систем на Обероне. Надо же как-то обработчик на аппаратное прерывание посадить... А вот для чего такой модуль существует в платформе OCaml — большой вопрос.

В OCaml в самом языке тоже нет. Модуль Obj.magic содержит такое предупреждение:

Operations on internal representations of values.
Not for the casual user.

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

V>Ну дык, оппоненты именно этим заняты, хотя изначально речь шла о том, насколько Оберон отстал от современного состояния в IT. То бишь, по-хорошему стоило рассуждать крупными мазками на уровне заложенных в язык идей и их следствий. Однако же, имеем что имеем в обсуждении... Еще бы "синтаксический оверхед" опять начали обсуждать и можно сразу всю ветку в мусорку.

Ты тоже ведешь себя предельно неконструктивно. Тот же дурацкий наезд на OCaml хотя бы.

V>Дык, а куда ты денешься от пары обязательных сдвигов (вправо-влево) при любых целочисленных операциях над полями структур?

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

FR>>Но это точно не изъян языка, банально недостаток ресурсов для написания нормальных оптимизирующих компиляторов.

V>Нет, это язъян языка, преодолеть который можено только его редизайном. Это исскуственное ограничение сверху нафик не нужное. Мы тут где-то рядом с Вльфхаундом обсуждали принципы работы GC и возможные варианты обслуживания метаинформации при обобщенном GC. Хотя, само обсуждение не ахти, но любую из озвученных полезных идей должно было бы быть несложно вставить в OCaml.

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

V>Это было бы действительно современно. А так... без обид, по мне OCaml такое же г-но мамонта, как Паскаль образца 88-го года.

По моему ты тролишь, да ладно я готов согласится что OCaml к сожалению устарел, но Оберон в той же категории, если не хуже.

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

V>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.

http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

The PIC microcontrollers:
PIC = Programmable Integrated Circuit.
Low power consumption: a few milliwatts.
Low cost: a few dollars.
RAM memory: a few kB.
Flash memory: a few tens of kB.
Clock: a few MHz

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

V>>>- объем бинарного кода;
C>>Обычный объём.

V>Конкретно OCaml — хреновый объем.

Ну точно тролишь

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

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

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

V>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
C>Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?

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

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

V>А так... без обид, по мне OCaml такое же г-но мамонта, как Паскаль образца 88-го года.

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

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

V>>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
C>>Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?
ARK>Насколько я помню, программы на Обероне могут линковаться без сборщика. Естественно, в этом случае динамическое выделение памяти использоваться не может. Но в беспилотниках оно и не нужно.
Афигеть. Где же тогда все такие премущества Оберона?

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

FR>Сегодня дай думаю oberon поставлю, может конструктивный срач пойдет, репозиторий убунты
FR>про такой язык не знает, про окамл и другие ML знает, про паскали и модулу тоже, даже
FR>про брейнфак в курсе а оберона нет, вполне показатель мамонтофекальности по моему.
Ты думаешь я зря спросил у vdimas'а какую версию Оберона взять?

Я всё жду пока он попытется найти работающий компилятор на их сайте. Муахахахаха.

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

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

V>>>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
C>>>Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?
ARK>>Насколько я помню, программы на Обероне могут линковаться без сборщика. Естественно, в этом случае динамическое выделение памяти использоваться не может. Но в беспилотниках оно и не нужно.
C>Афигеть. Где же тогда все такие премущества Оберона?

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

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

V>Глубоких-преглубоких подробностей реализации AOS я и сам не знаю и не собираюсь узнавать, но приводимых неоднократно подробностей должно было хватить, чтобы понять основные идеи. Ради прикола предлагаю (после того, как ты наконец одолеешь собственную лень) сравнить идеи, заложенные в AOS с идеями, заложенными в ту самую Сингулярити, которую Wolfhound рекламируют как "самую-самую грань прогресса" (С). Обещаю, что при самостоятельном сравнении получишь достаточно фана.
Еще во время обероновых разборок разобрали по косточкам.
Они похожи друг на друга как паскаль на хаскель.
Общего только безопасность на уровне языка. Всё остальное разное.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

FR>Ты тоже ведешь себя предельно неконструктивно. Тот же дурацкий наезд на OCaml хотя бы.

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

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

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

FR>Плохо то что оптимизаций почти никаких нет, все на уровне какого нибудь борланд си 9X годов

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

FR>Ты путаешь реализацию и сам язык (как всегда впрочем).

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

FR>Но в любом случае редизайн необходим, без многопоточности сейчас уже никуда.

Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
— безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
— плоская память;
— миллионы дешевых агентов;
— GC на уровне ОС;
— бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
— юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
— эффективнейший в природе ввод-вывод и обмен данными м/у процессами.

Кароч, я действительно некорретно себя вёл, что повелся на провокации и вообще что-то там обсуждал с людьми, которые представляли суть АОС как набор локов, мьютексов и прочего своего беспробудного невежества... Показанный выше список — это непременный атрибут будущих ОСей на многих ядрах. Уже прямо сейчас с этим глупо спорить. Иначе многоядерность не взлетает, увы. Ес-но, в будущих разработках это может быть доведено до совершенства... но называть устаревшими идеи ПО будущих поколений, да еще в такой хамовитой манере — это был явный перебор.

V>>Это было бы действительно современно. А так... без обид, по мне OCaml такое же г-но мамонта, как Паскаль образца 88-го года.
FR>По моему ты тролишь, да ладно я готов согласится что OCaml к сожалению устарел, но Оберон в той же категории, если не хуже.

Твои заявления ничем не лучше заявлений Киберакса... Т.е. еще не факт, кто тут троллит. Ключевой список идей с т.з. моего ИМХО я привел. Если тебе действительно охота что-то обсуждать — прошу обсуждать более предметно. Жду твоего "ИМХО" по этим технологиям.

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

V>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
LISP, 69.

V>- плоская память;
LISP, 69.

V>- миллионы дешевых агентов;
Нету. В Обероне обычные потоки.

V>- GC на уровне ОС;
LISP, 69.

V>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
В Обероне нет контекстов. Весь код (в том числе и хакерский SYSTEM) работает в режиме ядра. Любое приложение легко может уронить всю систему.

V>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
Нету.

V>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.
Нету.

V>Кароч, я действительно некорретно себя вёл
Точно. Сказки-то какие рассказываешь.

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

FR>Сегодня дай думаю oberon поставлю, может конструктивный срач пойдет, репозиторий убунты
FR>про такой язык не знает, про окамл и другие ML знает, про паскали и модулу тоже, даже
FR>про брейнфак в курсе а оберона нет, вполне показатель мамонтофекальности по моему.

Продложаешь убивать наповал.. Ты ведь мог поставить Фортран, Аду и другие языки, которые 100% говны мамонтов... Но по твоим признакам получится — что вовсе нет?

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

FR>>Сегодня дай думаю oberon поставлю, может конструктивный срач пойдет, репозиторий убунты
FR>>про такой язык не знает, про окамл и другие ML знает, про паскали и модулу тоже, даже
FR>>про брейнфак в курсе а оберона нет, вполне показатель мамонтофекальности по моему.
V>Продложаешь убивать наповал.. Ты ведь мог поставить Фортран, Аду и другие языки, которые 100% говны мамонтов... Но по твоим признакам получится — что вовсе нет?

Ада — это само совершенство по сравнению с Обероном. А Фортран — это рабочая лошадка.

Ну а Оберон — это просто груда навоза.

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

C>Ты думаешь я зря спросил у vdimas'а какую версию Оберона взять?
C>Я всё жду пока он попытется найти работающий компилятор на их сайте. Муахахахаха.

Тебя тоже в гугл больше не пускают как и Мамута? Вот уже точно муа... ))
http://www.ethoberon.ethz.ch/download.html
http://bluebottle.ethz.ch/download.html

Заодно держи список проектов, обленившийся зануда:
http://oberoncore.ru/wiki/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

Не знать про ГЛОНАС — это залет, курсант. Хотя я про спутники намекал не раз... И не знать, кто и для чего изначально разработал популярный сейчас для VS2010 шрифт Excelsior это тоже муа... и далее по тексту.

Кароч, спорить с тобой банально не о чем, ты не в теме.

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

V>>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
C>LISP, 69.

-1
Даже лучшие компиляторы (не интерпретаторы!!!) Схемы не умеют. Есть кое-какие проблемы из-за низкой типизированности. А для Лиспа в природе таких вообще не существует.

V>>- плоская память;
C>LISP, 69.

-1
Речь о защищенном коде. В LISP, напомню, можно выполнять любые данные.

V>>- миллионы дешевых агентов;
C>Нету. В Обероне обычные потоки.

-1
Обычные только родные аппаратные потоки. Сравнить с потоками традиционных ОС.

V>>- GC на уровне ОС;
C>LISP, 69.

-1
Нет модулей и возможности подбирать их GC.

V>>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
C>В Обероне нет контекстов.

+1
Ес-но, иначе не было бы бесплатности

C>Весь код (в том числе и хакерский SYSTEM) работает в режиме ядра. Любое приложение легко может уронить всю систему.
-1
Зависимости от модулей явные, нет никакой принципиальной невозможности запретить зависимости от SYSTEM.

V>>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
C>Нету.

-1

V>>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.
C>Нету.

-1

V>>Кароч, я действительно некорретно себя вёл
C>Точно. Сказки-то какие рассказываешь.

Гы-гы, ты промазал вообще все разы.

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

C>Ада — это само совершенство по сравнению с Обероном.

Это уже клиника, однако.

C>А Фортран — это рабочая лошадка.

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

C>Ну а Оберон — это просто груда навоза.

Оберон язык или Оберон ОС?

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

C>>Ада — это само совершенство по сравнению с Обероном.
V>Это уже клиника, однако.
Однако, в Аде есть:
1) Generic'и
2) Нормальный ООП с интерфейсами
3) Та же безопасность на уровне языка
4) Встроенная многопоточность.

Да, в твоём духе ещё добавлю: Ада работает на космических аппаратах!

C>>Ну а Оберон — это просто груда навоза.
V>Оберон язык или Оберон ОС?
Оба.

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

V>Даже лучшие компиляторы (не интерпретаторы!!!) Схемы не умеют. Есть кое-какие проблемы из-за низкой типизированности. А для Лиспа в природе таких вообще не существует.
Да ну? А если я тебе покажу?

V>>>- плоская память;
C>>LISP, 69.
V>-1
V>Речь о защищенном коде. В LISP, напомню, можно выполнять любые данные.
Опять ты ничерта не понял. Я встраиваю в Оберон интерпретатор JS и Оберон может выполнять любые данные!!!

V>>>- GC на уровне ОС;
C>>LISP, 69.
V>-1
V>Нет модулей и возможности подбирать их GC.
Symbolics'ы — 80-е годы. GC на уровне всей системы, с возможностью мусоросборки неиспользуемых файлов.

C>>Весь код (в том числе и хакерский SYSTEM) работает в режиме ядра. Любое приложение легко может уронить всю систему.
V>-1
V>Зависимости от модулей явные, нет никакой принципиальной невозможности запретить зависимости от SYSTEM.
Аналога CAS нету.

V>>>Кароч, я действительно некорретно себя вёл
C>>Точно. Сказки-то какие рассказываешь.
V>Гы-гы, ты промазал вообще все разы.
А теперь для каждого -1 — доказательство со ссылками на исходный код ОберонОС. Слабо?

Да, ты мне всё ещё не сказал с каким компилятором Оберона сравнивать ML.

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

C>>>Какую версию Оберона взять?
V>>Самую лучшую на твой взгляд.
C>Ткни пальцем.

А смысл? Ты даже не сумел скачать ни одной версии.

Скажем так, моё мение о тебе после этого спора малость изменилось... Сплошное нубство в каждой ситуации...

V>>>>- объем бинарного кода;
C>>>Обычный объём.
V>>Конкретно OCaml — хреновый объем.
C>Врёшь.
V>>>>- эффектвность;
C>>>Вполне эффективен.
V>>Нет.
C>Врёшь.

Добро пожаловать в реальность, Нео.

V>>>>- требования к оперативной памяти.
C>>>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).
V>>Я видел как даже сугубо вычислительные алгоритмы на динамических языках обкатывались и какой из этого вывод? Аж никакой.
C>Слушай, после "слаботипизированного ML" с тобой говорить не о чем.

На больной мозоль наступил? Дык, заслуженно. Что есть, то есть, увы.

V>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
C>Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?

Нахрена беспилотнику мусоросборщик?

V>>>>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
C>>>Так, а теперь вопрос ребром:
C>>>ГДЕ КОД НА ОБЕРОНЕ?
V>>Был там же в тех же обсуждениях, в которых ты участвовал. ЛаптевВВ приводил примеры.
C>ГДЕ КОД НА ОБЕРОНЕ?
C>ГДЕ КОД НА ОБЕРОНЕ?
C>ГДЕ КОД НА ОБЕРОНЕ?
C>ГДЕ КОД НА ОБЕРОНЕ?
C>ГДЕ КОД НА ОБЕРОНЕ?
C>ГДЕ КОД НА ОБЕРОНЕ?

C>Достаточно? Приведи хотя бы штук 5-7 ссылок на проекты с достаточно большим (десятки тысяч строк) объёмом кода на Oberon.

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

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

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

C>>>>Какую версию Оберона взять?
V>>>Самую лучшую на твой взгляд.
C>>Ткни пальцем.
V>А смысл? Ты даже не сумел скачать ни одной версии.

Я скачал. Более того, даже смог запустить. А теперь прошу показать, что ты не языком треплешь и показать хотя бы какую версию Оберона взять.

C>>>>Вполне эффективен.
V>>>Нет.
C>>Врёшь.
V>Добро пожаловать в реальность, Нео.
ML — это самый быстрый язык в мире.
Опровергай.

V>>>Я видел как даже сугубо вычислительные алгоритмы на динамических языках обкатывались и какой из этого вывод? Аж никакой.
C>>Слушай, после "слаботипизированного ML" с тобой говорить не о чем.
V>На больной мозоль наступил? Дык, заслуженно. Что есть, то есть, увы.
Нет, ML — это фактически "родина" (язык, популяризовавший их) алгебраических типов и PM. Называть его "слаботипизированным" — это примерно как Тихий океан называть "небольшой лужей".

V>>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.
C>>Какие беспилотники? Как Оберон в 4Кб ПЗУ поместил мусоросборщик?
V>Нахрена беспилотнику мусоросборщик?
Нахрена ему Оберон? Ocaml для PIC'ов тут уже привели, кстати.

C>>Достаточно? Приведи хотя бы штук 5-7 ссылок на проекты с достаточно большим (десятки тысяч строк) объёмом кода на Oberon.
V>Я уже привел там, где ты жаловался о своём неумении пользоваться интернетом. Наслаждайся. Принципиально не хотел вестись на подобного рода херню, но ты же дошел натурально до клиники.

Ну да. Я тормоз и не могу найти. Сложно ткнуть пальцем?

Можно мне ссылочки на эти проекты на github? Они же активно развиваются, так?

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

V>>Да. Требования к памяти и результирующее быстродейтсвие не удовлетворяют. В embeded-применении особенно жестко с памятью. Я делал кучу проектов, где вся ОП — это встроенная на кристалле из сотни свободных ячеек. И 4..16к кода в ПЗУ. На императивных языках и глобальных константных данных в той же ПЗУ где лежит код — ноу проблема. Но ML не взлетает. А на Обероне летают беспилотники.

FR>http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

FR>

FR>The PIC microcontrollers:
FR>PIC = Programmable Integrated Circuit.
FR>Low power consumption: a few milliwatts.
FR>Low cost: a few dollars.
FR>RAM memory: a few kB.
FR>Flash memory: a few tens of kB.
FR>Clock: a few MHz

Тебя тоже в гугле забанили? ))
http://microchip.com.ru/PIC18F/PIC18%20general.html

У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.

Я много кодил на различных семействах пиков на их асмах + специальных Си под них в своё время (последний раз в 99-м). В общем, ситуация по PICам такова:
1. Упомянутая 18-я серия одна из самых дорогих (на тот момент была самая дорогая, я даже не интересовался на сегодня, есть ли более старшие модели).
2. Даже внутри этой серии цены отличаются заметно;
3. Если бы я предложил использовать намного более дорогой PIC со встроенной памятью, или, не дай бог, со встроенным контроллером памяти, + лишними ногами (для адресоной шины и шины данных) и присобачить на плату еще внешнее ОЗУ... И объяснил это только желанием покодить на "любимом языке"... то, боюсь, диагноз "инженерный идиотизм" — это самое малое, что я бы заслужил...

Вот, примерно так.

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

V>>Конкретно OCaml — хреновый объем.

FR>Ну точно тролишь

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

Ну и кто из нас троллит?

FR>Если брать байт код то он еще компактней.

Вот опять...

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

В догонку, статья Вирта об Обероне на тех же PIC-ах.

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

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

Контекст тут не имеет значения, извини (понимаю в пылу спора), но ты ляпнул феерическую глупость про "недопитизированный ocaml".
Ладно бы ты сравнивал с какой нибудь агдой, но с паскалем или обероном, да они все слабо типизированые относительно OCamla или SML.

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

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

Если будет бегать по памяти относительные расходы на арифметику будут стремится к нулю.
С нормальным оптимизатором отставало бы только на синтетических числодробильных тестах и то не в разы.

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

Кстати что оберон быстрее окамла еще доказать надо, мне например интересно было бы тесты посмотреть.

FR>>Ты путаешь реализацию и сам язык (как всегда впрочем).

V>Никто ничего не путает, см. контекст целиком. Обсуждение реализаций мне было навязано, хотя я всячески пытался от этого уйти.

Угу "только не бросай меня в терновый куст".

FR>>Но в любом случае редизайн необходим, без многопоточности сейчас уже никуда.

V>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
V>- плоская память;
V>- миллионы дешевых агентов;
V>- GC на уровне ОС;
V>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
V>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
V>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.

Active Oberon это уже 2000 год когда все это было далеко не новостью.
Если уж так охота сравнить можно сравнить форк Active Oberon для NET — Zonnon и форк OCaml' для того же NET — F#.

FR>>По моему ты тролишь, да ладно я готов согласится что OCaml к сожалению устарел, но Оберон в той же категории, если не хуже.

V>Твои заявления ничем не лучше заявлений Киберакса... Т.е. еще не факт, кто тут троллит. Ключевой список идей с т.з. моего ИМХО я привел. Если тебе действительно охота что-то обсуждать — прошу обсуждать более предметно. Жду твоего "ИМХО" по этим технологиям.

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

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

V>Продложаешь убивать наповал.. Ты ведь мог поставить Фортран, Аду и другие языки, которые 100% говны мамонтов... Но по твоим признакам получится — что вовсе нет?

Ada — Оберон

Фортран — Оберон

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

V>Вот, примерно так.

Нет начиналось все с мифических огромных требований ML к памяти:

Любым:
— объем бинарного кода;
— эффектвность;
— требования к оперативной памяти.

Из-за всего этого на ML невозможно писать для каких-нить военных железок.

ocapic это вполне опровергает.

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

V>Ну и кто из нас троллит?

Конечно ты, я же не наблюдаю в природе то что ты утверждаешь:

Конкретно OCaml — хреновый объем.

объективных доказательств от тебя нет, если не согласен давай замеры объема кода.

FR>>Если брать байт код то он еще компактней.

V>Вот опять...

Что? Приборы?

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

V>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
Мне, как и FR, очень лень вторгаться в оберон-болото, но мимо такого наезда на Хаскел пройти не могу. Активные объекты появились в 1996 году, смотри Concurrent Haskell.

V>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.
Можно кусок кода на Обероне с продолжениями, который "невозможно" сделать один в один на Хаскеле?

Вообще наблюдается такой парадокс программисты почему-то не хотят писать на обероне, иначе были бы хоть какие-то
open source инструменты под него и проекты, но их практически нуль.
При том тот же виртовский паскаль (его потомки) вполне жив, и даже модула местами еще шевелится:

Такое ощущение что на обероне пишут или те кто по привычке перешел с модулы (те же космические проекты) или
укушенные Виртом, притом вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
а написание статей, защиту диссертаций и срачи на форумах.

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

V>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.

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

FR>вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
FR>а написание статей, защиту диссертаций и

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

FR>срачи на форумах.

Вот это более правдоподобно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

V>В Хаскеле же нет. И во многих ML-диалектах тоже.

Как бы не так.

-- GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
> Unsafe.Coerce.unsafeCoerce Nothing :: Bool
False
> Unsafe.Coerce.unsafeCoerce $ Just 42 :: Bool
True

(* Standard ML of New Jersey v110.73 [built: Mon May 16 06:14:15 2011] *)
- Unsafe.cast false : int;
val it = 0 : int
- Unsafe.cast true : int;
val it = 1 : int

Вот только к слабой типизации это не имеет отношения. Слабая типизация — это когда такие преобразования происходят неявно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде. async/await.

Зачем увлекательные преключения с продолжениями, async/await и прочим для организации "работы в агентской среде", если есть легкие потоки, позвольте спросить?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

M>>У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.
V>Тоже там же ответил. Не имеет быстрые реализации. Сказки. У OCAML есть кое-какое важное ограничение. Подсказку там же дал.

Occam и OCaml не родственники и даже не однофамильцы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

C>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).

Ну да. ФЯ очень любят возраст натягивать. ML разрабатывался, разрабатывался и разработался как следует только к началу 90-х. При этом алгебраические типы и паттерн-матчинг для которых он якобы "является "родиной"" (кавычки поставлены не зря) попали в него из другого языка (Hope, если интересно). А region inference вовсе в 2000-ных обкатывали.
Это, впрочем, пустяки по сравнению с хаскелем, который считается "разработанным" прямо с того момента, когда Худак и Пейтон-Джонс решили сообразить на троих с Тернером, да только тот отказался. Так что в этом треде хаскель уже оказывается ровестником оберона.

V>>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
C>Так, а теперь вопрос ребром:
C>ГДЕ КОД НА ОБЕРОНЕ?

А разгадка проста: в "космических разработках" действительно применяют, насколько я знаю, язык Modula-2. Для которого действительно существуют (до сих пор) компиляторы промышленногог качества типа XDS. Казалось бы, при чем тут Оберон? Дело в том, что Оберон — это такой угол для программистов, в котором они должны стоять и не хныкать, потому что, проказники эдакие, не слушаются Вирта. Раз уж очередной язык от Вирта содержит, обычно, новые кары и унижения, а не пироги и пышки, (как это бывает в случае разработчиков языков, которые программистов не хотят воспитывать как следует, а балуют сладостями) — реализовать его, имея релизацию предыдущего, не так и сложно. Поэтому его и реализовали "чтоб было". Ни кто же не знал, что Оберон не нужен. Понятно, что раз разработчики какого-нибудь ГЛОНАССа используют компилятор модулы и оберона, то было бы как-то странно со стороны оберон-фанатиков не трубить о том, что используется оберон, нес па? И даже если действительно используется Оберон, то используется он, как подсказывает здравый смысл, из-за совместимости с имеющимся Модула-кодом, а не из-за каких-то мифических преимуществ Оберона перед нормальными языками.

C>ML-семейство — они обратно совместимы.

Нет, не совместимы. Правда, зависит от того, что считать ML-семейством. Если это многочисленные реализации SML со своими расширениями языка, и какие-то диалекты типа SML# (не имеет к .net никакого отношения) и Alice — то кое-какая совместимость есть. Можно, также, вполне представить себе кусок кода, который скомпилируется и OCaml и F# (в режиме совместимости с окамлом), но с нетривиальной программой так не получится, потому что в F# нет эмэльных параметризуемых модулей/функторов, да и ОО-подсистемы у них совсем разные. Сходство между SML и OCaml весьма отдаленное, а про Haskell, который некоторые классификаторы к ML-семейству причисляют как-то неудобно и говорить. Некоторое синтаксического сходство у него с SML есть, но семантическое — как у фортрана с прологом, примерно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

FR>>вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
FR>>а написание статей, защиту диссертаций и
K>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
Есть-есть. Тот же пресловутый ActiveOberon — это то, что немного выросло из дисера.
http://bluebottle.ethz.ch/languagereport/node5.html#Gut97

P. Fröhlich.
Projekt Froderon: Zur weiteren Entwicklung der Programmiersprache Oberon-2.
Master's thesis, Fachhochschule München, 1997.

Правда, кроме дисеров особо больше ничего и нету.

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

C>>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).
K>Ну да. ФЯ очень любят возраст натягивать. ML разрабатывался, разрабатывался и разработался как следует только к началу 90-х. При этом алгебраические типы и паттерн-матчинг для которых он якобы "является "родиной"" (кавычки поставлены не зря) попали в него из другого языка (Hope, если интересно).
"Родину" в кавычки я сам поставил. Но таки ML-семейство сделало их популярными.

K>А region inference вовсе в 2000-ных обкатывали.
Конец 80-х: http://en.wikipedia.org/wiki/Region-based_memory_management#Region_inference

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

C>>Так, а теперь вопрос ребром:
C>>ГДЕ КОД НА ОБЕРОНЕ?
K>А разгадка проста: в "космических разработках" действительно применяют, насколько я знаю, язык Modula-2. Для которого действительно существуют (до сих пор) компиляторы промышленногог качества типа XDS.
Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.

К примеру, поддерживаемых компиляторов Оберона в природе сейчас не находится.

C>>ML-семейство — они обратно совместимы.
K>Нет, не совместимы. Правда, зависит от того, что считать ML-семейством.
Семейство SML. Понятно, что .NET-вариации не будут совместимы. Ну и Хаскелл — это нифига таки не ML.

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

C>А теперь для каждого -1 — доказательство со ссылками на исходный код ОберонОС. Слабо?
Кстати, теперь есть "Проект Оберон" и на русском.. где тексты почти все опубликованы...
И репозиторий у оберонщиков вроде как свой как основной... впрочем, тут уже говорили...

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

K>>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
C>Есть-есть.

Я знаю, что они есть. Я сомневаюсь, что их количество значительно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

C>"Родину" в кавычки я сам поставил.

Ну я так и написал, что кавычки правильно поставлены. Суть же возражения в том, что "языки ML семейства" — как эти слова не понимай — это языки, более-менее сформировавшиеся и получившие хоть сколько нибудь практичные реализации скорее в 90-е годы, а вовсе не в 70-е. И судить о ML-е 70-х по SML 97 — это примерно то же самое, что судить о C 70-х по C++11.

C>Но таки ML-семейство сделало их популярными.

К сожалению, популярными они пока не стали.

K>>А region inference вовсе в 2000-ных обкатывали.
C>Конец 80-х: http://en.wikipedia.org/wiki/Region-based_memory_management#Region_inference

То, что было до MLKit едва ли можно назвать "обкатывали".

C>Оберон может быть немного моложе, но не сильно.

ОК, когда появился Оберон (и Оберон-2) понятно. А когда, по-вашему, появился хаскель? В википедии указан 90-й год — это время публикации первого описания языка, который не особенно похож даже на Haskell 98. В нем, к примеру, не просто отсутствуют монады в стандартной библиотеке — такие классы типов на этом языке вообще описать невозможно. Может это был 96-й, когда привычный теперь хаскель-минимум уже появился? Или 99 (да, Haskell 98 — стандарт 99-го года, если не 2002, считая дополнения по FFI), когда он был "стандартизирован"? Или 2001-й, когда была в первом приближении решена, наверное, основная дизайн-проблема хаскеля с многопараметрическими классами типов (во втором приближении она только сейчас решается). Или примерно 2008, когда появилось уже то, что сейчас собственно под хаскелем и понимают? Может 2010-й, когда реализацию можно уже назвать практичной, без особых оговорок? Если в Виртовском языке хоть что-то меняется — его уже называют по-другому. В случае хаскеля же требуются дополнительные пояснения, потому что различия между языками, компилируемым GHC 7.0 и GHC 7.4 (16 месяцев разницы) больше различий между паскалем и обероном-2.

C>Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.
C>К примеру, поддерживаемых компиляторов Оберона в природе сейчас не находится.

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

C>Семейство SML. Понятно, что .NET-вариации не будут совместимы.

Ничего особо понятного тут нет — для .net была реализация нормального sml.

C>Ну и Хаскелл — это нифига таки не ML.

Это-то очевидно. А OCaml — ML? К "SML семейству" он точно не относится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

FR>Контекст тут не имеет значения, извини (понимаю в пылу спора), но ты ляпнул феерическую глупость про "недопитизированный ocaml".
FR>Ладно бы ты сравнивал с какой нибудь агдой, но с паскалем или обероном, да они все слабо типизированые относительно OCamla или SML.

Дык, теперь ты заявляешь глупость относительно Оберона. Он ничуть не меньше типизирован. Это в Паскале и Объектном Паскале возможны опасные преобразования типов, а в Обероне — нет.

FR>Если будет бегать по памяти относительные расходы на арифметику будут стремится к нулю.

Если брать какую-нить линейную пробежку по массиву — то не будет.

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

Кто мешает мешает нарисовать и посмотреть?

FR>>>Но в любом случае редизайн необходим, без многопоточности сейчас уже никуда.

V>>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
V>>- плоская память;
V>>- миллионы дешевых агентов;
V>>- GC на уровне ОС;
V>>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
V>>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
V>>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.

FR>Active Oberon это уже 2000 год когда все это было далеко не новостью.

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

FR>Если уж так охота сравнить можно сравнить форк Active Oberon для NET — Zonnon и форк OCaml' для того же NET — F#.

Zonnon является форком АО с очень большой натяжкой. Исходный АО без специальной операционки под него не имеет смысла. Совсем.

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

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

Положа руку на куда-нибудь, мне кажется, что основная ошибка Вирта — это его синтаксис из Модулы. Как не смешон был тред о синтаксическом оверхеде... Но таки стабильно Си-подобный синтаксис или ML-синтаксис становились все более популярными. Никто не мешал Вирту разработать совместимого по компонентной модели близнеца-брата для Оберона в Си-подобном и/или ML-подобном синтаксисе и "влиться в струю". ИМХО, шансов на популярность было бы намного больше.

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

K>>>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
C>>Есть-есть.
K>Я знаю, что они есть. Я сомневаюсь, что их количество значительно.
Оно заметно больше объёма кода на Обероне.

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

V>Положа руку на куда-нибудь, мне кажется, что основная ошибка Вирта — это его синтаксис из Модулы. Как не смешон был тред о синтаксическом оверхеде... Но таки стабильно Си-подобный синтаксис или ML-синтаксис становились все более популярными.

Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем. Синтаксис ML удобен для применения функций и комбинирования комбинаторов. Синтаксис алгола 60, который Вирт потом последовательно ухудшал, не разрабатывался с какой-бы то ни было целью. Это был первоначальный набросок, от которого потом довольно быстро ушли. Собственно, и ML-ный синтаксис (через ISWIM и Hope) и Сишный (через алгол 68 и CPL) произошли от синтаксиса алгол 60, но изменения делались с целью сделать что-то удобно. Изменения которые делал Вирт, по всей видимости, делались с целью "показать им всем". Результат очевиден.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

FR>>Контекст тут не имеет значения, извини (понимаю в пылу спора), но ты ляпнул феерическую глупость про "недопитизированный ocaml".
FR>>Ладно бы ты сравнивал с какой нибудь агдой, но с паскалем или обероном, да они все слабо типизированые относительно OCamla или SML.

V>Дык, теперь ты заявляешь глупость относительно Оберона. Он ничуть не меньше типизирован. Это в Паскале и Объектном Паскале возможны опасные преобразования типов, а в Обероне — нет.

12. The Module SYSTEM

facilities to break the data type compatibility rules otherwise imposed by the language definition.

K>>>>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
C>>>Есть-есть.
K>>Я знаю, что они есть. Я сомневаюсь, что их количество значительно.
C>Оно заметно больше объёма кода на Обероне.

Ну это естественно

В диссертациях есть синтаксический оверхед, а в в Обероне — нет. Очевидно же

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

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

V>>Положа руку на куда-нибудь, мне кажется, что основная ошибка Вирта — это его синтаксис из Модулы. Как не смешон был тред о синтаксическом оверхеде... Но таки стабильно Си-подобный синтаксис или ML-синтаксис становились все более популярными.

K>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.

То есть в настоящее время он не нужен?

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

Хм. А что именно Вирт ухудшил?
И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

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

FR>Вообще наблюдается такой парадокс программисты почему-то не хотят писать на обероне, иначе были бы хоть какие-то
FR>open source инструменты под него и проекты, но их практически нуль.

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

FR>При том тот же виртовский паскаль (его потомки) вполне жив, и даже модула местами еще шевелится:
FR>

Увы, популярные VCS не подходят для Оберона, поэтому сравнивать в приведенном тобой виде абсолютно бесполезно. Я не говорю, что одобряю такое положение дел, просто констатирую факт. Точно так же ты не найдешь кучи проектов на VBA (именно VBA, а не VB), хотя таких проектов немеряно были и есть. Просто потому что файлы Офиса неудобно было хранить в популярных бесплатных VCS. И ведь до дотнета проекты на VB и VBA на западе абсолютно лидировали в общем кол-ве коммерческих проектов. Просто есть коммерческие VCS, которые умеют в т.ч. офисные док-ты со встроенным VBA-кодом.

FR>Такое ощущение что на обероне пишут или те кто по привычке перешел с модулы (те же космические проекты) или
FR>укушенные Виртом, притом вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
FR>а написание статей, защиту диссертаций и срачи на форумах.

Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop, да и тот вовсе не с 0-ля писан, а форк другой относительно старой среды разработки. Гораздо лучше из всех опенсорсов выглядит только Eclipse, в который IBM и Co вкладывали немерянную кучу ресурсов в 2000-е.

Ну и опять же, ссылки на проекты на Обероне уже давали. Просмотрев все эти проекты их можно накрыть одним общим определением "требуется надежность". Заметь, в опенсорсе этого вообще никогда не требуется... Т.е. непонятно что с чем сравнивать.

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

V>>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
N>Мне, как и FR, очень лень вторгаться в оберон-болото, но мимо такого наезда на Хаскел пройти не могу. Активные объекты появились в 1996 году, смотри Concurrent Haskell.

Ну, посмотрел, увидел добавленные в язык мутабельные типы данных (MVar):

type Account = MVar Integer
 
credit :: Integer -> Account -> IO ()
credit amount account = do
    current <- takeMVar account
    putMVar account (current + amount)

Обыкновенная императивная хрень на мутабельных типах данных. Фтопку такой Хаскель.

V>>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.
N>Можно кусок кода на Обероне с продолжениями, который "невозможно" сделать один в один на Хаскеле?

Бери любой мутабельный объект, к которому идут асинхронные вызовы. Я ХЗ что тут может быть непонятного про продолжения и иммутабельность. В условиях иммутабельного кода у нас не может быть явно выраженого в языке состояния, у нас могут быть только потоки исполнения. А состояния могут быть организованы разве что над этими потоками в виде сохраненных продолжений.

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

V>>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде. async/await.
K>Зачем увлекательные преключения с продолжениями, async/await и прочим для организации "работы в агентской среде", если есть легкие потоки, позвольте спросить?

Угу, зачем мне масло, если у меня есть масло.

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

V>>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
C>И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.

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

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

V>>>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
C>>И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.
V>Активный не влазит, бо он в контроллере не нужен. В контроллерах вообще всё на глобальных переменных, увы и ах. Бо лишняя косвенность и нафик не сдалась в среде, где нет динамической загрузки приложений.
1) Таки влазит при желании.
2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.
3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
4) Причём косвенности и динамическая загрузка — х.з.

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

V>Обыкновенная императивная хрень на мутабельных типах данных. Фтопку такой Хаскель.
Я не знаю, что ты подразумеваешь под "активными обьектами". ИМХО это зеленые потоки и fifo, что и реализовано в Concurrent Haskell. MVar это просто кирпич для построения fifo (channels) и семафоров.

V>Бери любой мутабельный объект, к которому идут асинхронные вызовы. Я ХЗ что тут может быть непонятного про продолжения и иммутабельность. В условиях иммутабельного кода у нас не может быть явно выраженого в языке состояния, у нас могут быть только потоки исполнения. А состояния могут быть организованы разве что над этими потоками в виде сохраненных продолжений.

Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

chanExample = do
  ch <- newChan
  forkIO $ agent ch 0

agent :: Chan Int -> Int -> IO ()
agent c sum = do n <- readChan ch
                 let newsum = sum + n
                 print newsum
                 agent c newsum

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

V>>>>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
C>>>И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.
V>>Активный не влазит, бо он в контроллере не нужен. В контроллерах вообще всё на глобальных переменных, увы и ах. Бо лишняя косвенность и нафик не сдалась в среде, где нет динамической загрузки приложений.
C>1) Таки влазит при желании.

При желании можно передвигаться раком.

C>2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.

На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.

C>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).

Можно не значит нужно.

C>4) Причём косвенности и динамическая загрузка — х.з.

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

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

N>MVar это просто кирпич для построения fifo (channels) и семафоров.

Это просто мутабельная переменная, огорожденная автоматическим локом.

V>>Бери любой мутабельный объект, к которому идут асинхронные вызовы. Я ХЗ что тут может быть непонятного про продолжения и иммутабельность. В условиях иммутабельного кода у нас не может быть явно выраженого в языке состояния, у нас могут быть только потоки исполнения. А состояния могут быть организованы разве что над этими потоками в виде сохраненных продолжений.

N>Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

N>

N>chanExample = do
N>  ch <- newChan
N>  forkIO $ agent ch 0

N>agent :: Chan Int -> Int -> IO ()
N>agent c sum = do n <- readChan ch
N>                 let newsum = sum + n
N>                 print newsum
N>                 agent c newsum
N>

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

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

K>>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.
ARK>То есть в настоящее время он не нужен?

Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай.

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

ARK>Хм. А что именно Вирт ухудшил?
ARK>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

Домыслы ес-но.
У Оберона философия навроде джавы, только чуть удобней.

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

N>>Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

N>>

N>>chanExample = do
N>>  ch <- newChan
N>>  forkIO $ agent ch 0

N>>agent :: Chan Int -> Int -> IO ()
N>>agent c sum = do n <- readChan ch
N>>                 let newsum = sum + n
N>>                 print newsum
N>>                 agent c newsum
N>>

V>В канале, ес-но.
V>Я ХЗ какой смыл сравнивать язык с мутабельными переменными в кач--ве представителя функционального лагеря. Это же профанация.

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

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

V>>>Активный не влазит, бо он в контроллере не нужен. В контроллерах вообще всё на глобальных переменных, увы и ах. Бо лишняя косвенность и нафик не сдалась в среде, где нет динамической загрузки приложений.
C>>1) Таки влазит при желании.
V>При желании можно передвигаться раком.
Ну вот. ЛИСП рулит, Оберон — ацтой.

C>>2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.
V>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.
ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось.

C>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
V>Можно не значит нужно.
Ага, см.: "Оберон"

C>>4) Причём косвенности и динамическая загрузка — х.з.
V>При том, что принципы использования памяти в системах, скомпиленых по жестким адресам, существенно отличаются от привычных тебе. И обсуждаемый АО — это заведомо косвенные адресации на каждый чих. Почему так — медитировать.

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

N>Становиться все интересней..В активном обероне значиться обьекты общаются асинхронно при помощи иммутабельных мэйлбоксов.

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

N>Можно переписать мой код?

Он у тебя не целиком.

Где та часть, что пишет в канал?

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

C>Ну вот. ЛИСП рулит, Оберон — ацтой.

Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.

V>>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.
C>ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось.

Не может Лисп компиллироваться, не говори ерунды. 50% возможностей языка — заведомая динамика. Если там была полноценная компиляция, то речь могла идти о другом языке. Даже если у этого языка был синтаксис Лиспа (с высоты птичьего полета), это не делало его Лиспом. Даже банальные замыкания в Лиспе требуют динамики, потому что должны замыкаться by name.

C>>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
V>>Можно не значит нужно.
C>Ага, см.: "Оберон"

Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет, то брать более дорогой чип лишь бы покодить на выученном языке — это и есть тот самый инженерный идиотизм. Профнепригодность, в общем. Нормальному спецу язык должен быть до лампочки.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Угу, зачем мне масло, если у меня есть масло.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Это какие-то странные предрассудки.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ARK>Хм. А что именно Вирт ухудшил?

Навскидку — КРИЧАЩИЕ КЛЮЧЕВЫЕ СЛОВА. В алголах, насколько я помню, способ выделения ключевых слов среди прочих оставался на усмотрения имплементатора. Вирт (впрочем, не исключено, что это кто-то другой придумал) безошибочно выбрал и зафиксировал неправильный способ, а все остальные — правильный.

Справедливости ради нужно сказать, что синтаксические улучшения по сравнению с алголом все-таки есть. Например, "идентификатор : Тип" у Вирта (но это точно не он придумал) против "Тип идентификатор" в алголе.

ARK>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай.

А по-моему, все заточено под блоки памяти, оканчивающиеся нулем. Для работы с просто блоками памяти удобный синтаксис для работы с диапазонами подходил бы лучше.

V>У Оберона философия навроде джавы, только чуть удобней.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Не может Лисп компиллироваться

Тут все правильно.

V>Нормальному спецу язык должен быть до лампочки.

А вот это — серьезная ошибка.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

> V>Нормальному спецу язык должен быть до лампочки.

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

Posted via RSDN NNTP Server 2.1 beta

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

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

K>>>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.
ARK>>То есть в настоящее время он не нужен?

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

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

ARK>>Хм. А что именно Вирт ухудшил?

K>Навскидку — КРИЧАЩИЕ КЛЮЧЕВЫЕ СЛОВА. В алголах, насколько я помню, способ выделения ключевых слов среди прочих оставался на усмотрения имплементатора. Вирт (впрочем, не исключено, что это кто-то другой придумал) безошибочно выбрал и зафиксировал неправильный способ, а все остальные — правильный.

В принципе, тут можно согласиться, хотя я особого криминала не вижу в верхнем регистре.

K>Справедливости ради нужно сказать, что синтаксические улучшения по сравнению с алголом все-таки есть. Например, "идентификатор : Тип" у Вирта (но это точно не он придумал) против "Тип идентификатор" в алголе.

Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.), ну и криптованного синтаксиса в целом?

ARK>>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

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

Это вы лихо по результату вычислили аргументы.

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

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

V>Нет у тебя никаких иммутабельных мейлбоксов.
У меня нет, но ты вроде утверждаешь что это полное г... и в активном обероне активные объекты работают по другому. Покажи как.

N>>Можно переписать мой код?
V>Он у тебя не целиком.

V>Где та часть, что пишет в канал?
Думал она самоочевидна, но если нет, то вот:

chanExample = do
  c <- newChan
  forkIO $ agent c 0
  forkIO $ writer c [1..10]
  forkIO $ writer c [10..1]

writer :: Chan Int -> IO ()
writer c s = forM_ s $ \e -> writeChan c e >> threadDelay e

agent :: Chan Int -> Int -> IO ()
agent c sum = do n <- readChan c
                 let newsum = sum + n
                 print newsum
                 agent c newsum

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

C>>Ну вот. ЛИСП рулит, Оберон — ацтой.
V>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.
Можно посмотреть на emacs на Обероне?

Спасибо.

V>>>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.
C>>ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось.
V>Не может Лисп компиллироваться, не говори ерунды.
Может. С помощью вывода типов и их явной аннотации.

Плюс к этому — динамическая рекомпиляция при необходимости, как сейчас для JS делают.

C>>>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
V>>>Можно не значит нужно.
C>>Ага, см.: "Оберон"
V>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет
Умеет. Тебе уже привели ссылку.

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

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

Да это вообще не важно — нужен он сейчас или нет. Сейчас уже этот синтаксис, к сожалению, популярен и приходится есть кактус. Важно то, что хоть какой-то код, написанный на C может выглядеть хорошо (или выглядел хорошо в свое время) и это создало необходимый рекламный эффект для раскрутки синтаксиса. Вирт же этого, по видимому, не понимает. Его синтаксис не выглядит хорошо ни в каком случае. Вместо того, чтоб изменить его соотвествующим образом, он доказывает, что он и должен выглядеть плохо. Т.е все так и запланировано. Можно сколько угодно доказывать людям, что быть бедным и больным лучше, чем богатым и здоровым — эффекта не будет никакого. Зато можно обманом склонить людей к этому, приманить эффектной приманкой и потом они сами всем будут доказывать, что бедным и больным быть лучше — когда у них выбора не будет. Если выбора нет, базу подведут под что угодно, чтоб обосновать что вот это единственное — и есть то что нужно. Вирт же сначала пытается подвести базу под нездоровые идеи, но пока идеи эти не стали общераспространенными — от них можно просто промахнуться.
Впрочем, то, что Вирт не способен заставить делать так как он считает нужным хоть сколько нибудь заметное кол-во людей — это положительная черта, это делает его безвредным.

ARK>Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.),

Не уверен, что это он (Ричи) их все придумал. К тому же, ничего плохого в них нет.

ARK>ну и криптованного синтаксиса в целом?

Я бы не сказал, что он в целом "криптованный". В частностях (вроде аннотации типов, особенно в случае указателей на функции) да, а в целом все просто.

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

Результат хуже некуда. Известен он, в основном, как какой-то нелепый язык из глубин прошлого, который пропагандируется зелотами, кидающимися на людей по TCP/IP, чтоб их покусать. Ну и, соотвественно, короткий ассоциативный ряд от "Оберон" до "Диантетика", "Heaven's Gate", "Газовая атака в Токийском метро".

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

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

K>Да это вообще не важно — нужен он сейчас или нет. Сейчас уже этот синтаксис, к сожалению, популярен и приходится есть кактус.

Это верно.

K>Его синтаксис не выглядит хорошо ни в каком случае. Вместо того, чтоб изменить его соотвествующим образом

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

ARK>>Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.),

K>Не уверен, что это он (Ричи) их все придумал. К тому же, ничего плохого в них нет.
K>Я бы не сказал, что он в целом "криптованный". В частностях (вроде аннотации типов, особенно в случае указателей на функции) да, а в целом все просто.

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

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

K>Результат хуже некуда.

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

K>Известен он, в основном, как какой-то нелепый язык из глубин прошлого, который пропагандируется зелотами, кидающимися на людей по TCP/IP, чтоб их покусать. Ну и, соотвественно, короткий ассоциативный ряд от "Оберон" до "Диантетика", "Heaven's Gate", "Газовая атака в Токийском метро".

Это, наверное, только на RSDN.

А вот, например, создатели Go вряд ли так думают.

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

ARK>Не думаю, что синтаксис Вирта выглядит плохо, за исключением спорного обероновского решения о верхнем регистре. Лично мне Pascal-подобный синтаксис нравится больше C-подобного.

Это понятно.

ARK>Он более последователен и менее подвержен разночтениям.

А вот это — попытка подвести базу под вкусовщину. Последовательность не измеришь, да и кашу из нее не сваришь: что толку, что синтаксис "последовательный", если код многословный и обвешанный ничего не значащими финтифлюшками.

ARK>Ну не знаю, не знаю. У меня от этих значков и крючков в глазах рябит. Кажется, нет ни одного спецсимвола, который бы не применялся в алфавите C, а некоторые еще и особо извращенным образом (таки да, всякие формы указателей).

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

ARK>Я бы все-таки сказал, что хуже некуда — это у прорвы языков, канувших в лету. Оберон к таким явно не относится.

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

ARK>Это, наверное, только на RSDN.

Ну а там, где не изестен в таком ключе — не известен вообще. Пример:
stackoverflow.com
[oberon] 7 вопросов, 7 фолловеров.
эзотерический [haskell] 7436 вопросов, 3.8k фолловеров.
мейнстримная [java] 269977 вопросов 28.8k фолловеров.

ARK>А вот, например, создатели Go вряд ли так думают.

Я бы попросил ссылку на одобрительные высказывания Роба Пайка об Обероне, да вот только я не могу заботиться меньше о мнении Роба Пайка.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
Не новость.

V>- плоская память;
Единое объектное пространство на всю систему это приговор масштабируемости и безопасности.
Ну и возможность уронить всю ОС одним кривым модулем.
Re[41]: Нужна ли Оберон-ОС защита памяти?
И ничего ты с этим не сделаешь.

При этом в сингулярити с этим проблем нет.
Если один процесс начнет жрать память его можно просто прибить. Можно даже на каждый процесс повесить ограничение по памяти.
Бутылка так не может.

А еще сингулярити можно запустить на кластере.
Распределив процессы между узлами.
Процессы драйверов конечно будут прибиты к конкретным железкам. Но все остальные процессы можно прямо во время работы переносить между узлами. Причем даже если на узлах процессоры разные.
Бутылка так тоже не может.

V>- миллионы дешевых агентов;
Не новость.

V>- GC на уровне ОС;
Очень плохо.
Ибо сборка мусора будет тормозить всю ОС.

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

V>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
Там нет контекстов.

V>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
Там нет юзерлевел.
И асинхронности в твоем "понимании" там тоже нет.

V>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.
Который построен на механизмах делающих ОС неработоспособной.
А ведь можно добиться того же не ломая изоляцию.
Авторам сингулярити это удалось.

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

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

V>Кароч, я действительно некорретно себя вёл, что повелся на провокации и вообще что-то там обсуждал с людьми, которые представляли суть АОС как набор локов, мьютексов и прочего своего беспробудного невежества...
Тут про это прямым текстом пишут.
http://bluebottle.ethz.ch/languagereport/node3.html#SECTION00031000000000000000

V>Показанный выше список — это непременный атрибут будущих ОСей на многих ядрах. Уже прямо сейчас с этим глупо спорить. Иначе многоядерность не взлетает, увы. Ес-но, в будущих разработках это может быть доведено до совершенства... но называть устаревшими идеи ПО будущих поколений, да еще в такой хамовитой манере — это был явный перебор.
Учитывая, что ты не понял, почему бутылка в реальных условиях работать не может...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ARK>>Он более последователен и менее подвержен разночтениям.

K>А вот это — попытка подвести базу под вкусовщину. Последовательность не измеришь, да и кашу из нее не сваришь: что толку, что синтаксис "последовательный", если код многословный и обвешанный ничего не значащими финтифлюшками.

Да нет. С-синтаксис содержит больше слабых мест. Fallthrough в switch (это вообще за гранью добра и зла), путаница с объявлением указателей (char* s1, s2) и прочая. Оберон многословный — ну и ладно, не вижу криминала в этом...

ARK>>Ну не знаю, не знаю. У меня от этих значков и крючков в глазах рябит. Кажется, нет ни одного спецсимвола, который бы не применялся в алфавите C, а некоторые еще и особо извращенным образом (таки да, всякие формы указателей).

K>Ну так что плохого-то? Я еще понял бы, если б альтернатива была в возможности применять префиксно/инфиксно/постфиксно функции с буквенными идентификаторами. А реализовывать, например, постинкремент как префиксную операцию — это анекдот вроде фотографии, на которой на две трубы одного цвета приклеены таблички "красная" и "синяя".

Что плохого? Ну не особо читабельно оно, на мой вкус (и не только на мой). А постинкремент можно и обычной функцией реализовать.

ARK>>Я бы все-таки сказал, что хуже некуда — это у прорвы языков, канувших в лету. Оберон к таким явно не относится.

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

ARK>>Это, наверное, только на RSDN.

K>Ну а там, где не изестен в таком ключе — не известен вообще. Пример:
K>stackoverflow.com
K>[oberon] 7 вопросов, 7 фолловеров.
K>эзотерический [haskell] 7436 вопросов, 3.8k фолловеров.
K>мейнстримная [java] 269977 вопросов 28.8k фолловеров.

ARK>>А вот, например, создатели Go вряд ли так думают.

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

Пайк признавал, что взял из Оберона ряд концепций.

19 июня 2012
Недавнее обсуждение Blockly (на английском) — 93 комментария
http://www.metafilter.com/117096/Blockly

Blockly
June 19, 2012 10:49 AM Subscribe

Blockly is a visual programming editor from Google.

Blockly was developed by Neil Fraser, who has appeared previously on Metafilter.
posted by alby (93 comments total) 40 users marked this as a favorite

В этом обсуждении, в частности, упомянут и ДРАКОН:

The programming for the russian space program was done
in a visual programming language DRAKON.
posted by Ad hominem at 11:32 AM on June 19 [3 favorites]

http://www.metafilter.com/117096/Blockly

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

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

Исходно зацепились за это:

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

Как вывод: в Хаскель необходимо добавить либо мутабельный тип данных, либо продолжения. Насколько я вижу, то бишь не вижу ничего интересного на Concurrent Haskell, попытка пойти по пути наименьшего сопротивления (добавления мутабельного типа данных) не вызвала поддержки масс. Предлагаю эксперименты с мутабельностью в Хаскеле сразу в топку как противоречащие концепции языка и сделать таки нормальные продолжения. ))

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

V>>Нет у тебя никаких иммутабельных мейлбоксов.
N>У меня нет,

Поторопимшись ты утверждал, что есть.

N>но ты вроде утверждаешь что это полное г... и в активном обероне активные объекты работают по другому.

Ес-но, по другому чем в чистых ф-ых языках. Уже полностью расшифровал "до самого дна", в чем отличие. Вопросы?

N>Покажи как.

Гы, а что с чем ты хотел сравнить? Один императивный язык с другим? Молодец. И это там, где речь была о принципиальном отличии подходов к асинхронности в языках с иммутабельностью. А то, что ты показал, Хаскелем никак не является, не смотря на плагиат в одном из слов в названии. Это просто императивный язык с хаскелеподобным синтаксисом. И не факт, что хаскелеподобный синтаксис так уж удобен для императивности. Просто ты не понял философия Хаскеля — его выразительность заведомо заточена под чистые ленивые вычисления и тут он фактически вне конкуренции. А иначе такой Хаскель не нужен, хотя бы из-за "синтаксического оверхеда". Сравни исходный пример с банковским счетом с таким на С++:

atomic<money_t> account;
account += amount;

Вот эффект того, что императивные операции встроены в язык, а не стеснительно проэмулированы через одно место, как в Concurrent Haskell...

N>>>Можно переписать мой код?
V>>Он у тебя не целиком.

V>>Где та часть, что пишет в канал?
N>Думал она самоочевидна, но если нет, то вот:

Это было нужно не мне, а тебе, т.к. ты поначалу считал, что мейлбоксы иммутабельны. И да, тебе было бы всяко полезней посмотреть на устройство readChan, writeChan, чем на высокоуровневый пример на их основе.

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

K>Легкие потоки и продолжения не одно и то же.

Фактически одно и то же когда продолжения делаются не в языке-интерпретаторе, а в компиллируемом в нейтивный код. В этом случае продолжения делаются именно через полное дублирование контекста исполнения (и "родного" стека машины в т.ч.). Разница лишь в том, какой вид многозадачности доступен в такой системе — кооперативный, или полноценный с вытеснениями. ИМХО, для обсуждаемой задачи, когда агенты должны постоянно сидеть в ожидании сигналов ввода-вывода каналов (прямо по условию) разница м/у видами многозадачности не столь принципиальна.

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

G>Ты там на бороду себе что ли наступил, так ругаешься?
G>В давние-давние времена, когда языки были простыми, библиотек было две или три, а фреймворков вообще не было, грамотный специалист мог писать на любом языке. Сейчас такого нет. Вылезай из музея.

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

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

V>>Нормальному спецу язык должен быть до лампочки.

K>А вот это — серьезная ошибка.

Увы, бывают такие области, где акценты расставлены не так, как ты привык. По моему опыту — сложность собственно кодирования невелика в embedded. Все-равно задачи обыгрываются на модели (из области цифровой радиосвязи, например), много математики и т.д. Разница трудозатрат, даваемая языками исполнения не видна и под микроскопом в общем объеме труозатрат. Ну и к тому же всегда было стремление породить минимальный футпринт, это влияло на стоимость подходящего чипа.

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

V>>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.
C>Можно посмотреть на emacs на Обероне?

Дык, BlakcBox как бэ многократно покруче будет.

C>Спасибо.

Да не за что.

V>>Не может Лисп компиллироваться, не говори ерунды.
C>Может.

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

C>С помощью вывода типов и их явной аннотации.

Я так и думал, что имел ввиду какой-то другой язык, в котором тоже много скобок.

C>Плюс к этому — динамическая рекомпиляция при необходимости, как сейчас для JS делают.

К чему плюс-то? )))

V>>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет
C>Умеет. Тебе уже привели ссылку.

Угу, привели. Взяли 512 ОЗУ байт для минимального примера. Для реального там нужны будут килобайты. Как раз во времена обсуждаемого Оберона чипы с таким объемом памяти стоили 3-5-ти раз дороже стандартного.

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

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

В Обероне с указателями все-нормально. Мне эта идея нравится точно так же, как типизированные файлы ввода-вывода. Невозможно ошибиться.

K>а то, что появилось нового, по сравнению с модулой — использовать в контролерах нельзя.

А что там нового? Просто шлифовка. Упрощенное описание интерфейса импорта модулей разве нельзя использовать?

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

V>>Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай.
K>А по-моему, все заточено под блоки памяти, оканчивающиеся нулем. Для работы с просто блоками памяти удобный синтаксис для работы с диапазонами подходил бы лучше.

Есть и так и как угодно. Да и несерьезно обсуждать отличия навроде таких:

while(*ptr1++ = *ptr2++) {}
// vs
while(ptr2 != endPtr) *ptr1++ *= ptr2++;

V>>У Оберона философия навроде джавы, только чуть удобней.
K>Ну да. У Джавы философия заключается в том, что все программисты глупы, а у оберона в том, что Вирт знает как лучше. Первое обидно, но для всех, а потому демократично. А второе просто обидно.

Спасибо, поржал. Без иронии, просто прикольный ход мыслей.

K>Но это не причина неуспеха. По крайней мере, у питона философия та же, только вместо Вирта — Ван-Россум. А питон вполне успешен. Причина неуспеха в том, что Вирт не знает как лучше.

Обилие языков программирования и бесконечный процесс их изобретения говорит о том, что никто не знает как лучше. Тем не менее, общие принципы в современных императивных языках шлифовались не без заимствований... и у Вирта в т.ч.

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

V>>Показанный выше список — это непременный атрибут будущих ОСей на многих ядрах. Уже прямо сейчас с этим глупо спорить. Иначе многоядерность не взлетает, увы. Ес-но, в будущих разработках это может быть доведено до совершенства... но называть устаревшими идеи ПО будущих поколений, да еще в такой хамовитой манере — это был явный перебор.
WH>Учитывая, что ты не понял, почему бутылка в реальных условиях работать не может...

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

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

K>Если в Виртовском языке хоть что-то меняется — его уже называют по-другому. В случае хаскеля же требуются дополнительные пояснения, потому что различия между языками, компилируемым GHC 7.0 и GHC 7.4 (16 месяцев разницы) больше различий между паскалем и обероном-2.

Угу, это ключевое во всем споре. Я ХЗ откуда такая реакция именно на слово "Оберон".

C>>Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.

Вот, подтверждение. Про модулу-2 вопросов у него нет, про компонентный паскаль тоже наверняка нет, а про точно такой же оберон — есть. ЧТД.

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

V>Дык, даже ты обсуждал не сами идеи а их реализацию. Т.е. даже если я и согласен почти со всем твоими замечаниями (кроме глобального ГЦ — это отдельная тема), то ты лишь подтверждаешь мой изначальный тезис.
Всё что я написал это про идеологию.
Синхронизация на мониторах это идеология.
Единое объектное пространство это идеология.
Один экземпляр модуля на всю систему это идеология.
Единственная здравая мысль во всей бутылке это защита памяти на уровне языка. Причем эта идея настолько очевидна, что даже говорить не о чем.
Все остальное мусор.
Причем тебе на это даже возразить нечего.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.
C>>Можно посмотреть на emacs на Обероне?
V>Дык, BlakcBox как бэ многократно покруче будет.
Там есть текстовый редактор?

C>>Может.
V>Ну ты бы хотя б посмотрел на то, что производят лучшие компиляторы Схемы. Да, кое-где (мало где) идет прямо машинный код, а по большей части встроенный в конечный образ движок выполняет eval значений динамического типа.
А ты бы глянул на SBCL, чтоле.

C>>С помощью вывода типов и их явной аннотации.
V>Я так и думал, что имел ввиду какой-то другой язык, в котором тоже много скобок.
Нет, просто особое подмножество Лиспа.

V>>>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет
C>>Умеет. Тебе уже привели ссылку.
V>Угу, привели. Взяли 512 ОЗУ байт для минимального примера. Для реального там нужны будут килобайты. Как раз во времена обсуждаемого Оберона чипы с таким объемом памяти стоили 3-5-ти раз дороже стандартного.
Приведи пример реального устройства с Обероном на борту и 512 байт ОЗУ.

Нету таких.

V>>>>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет
C>>>Умеет. Тебе уже привели ссылку.
V>>Угу, привели. Взяли 512 ОЗУ байт для минимального примера. Для реального там нужны будут килобайты. Как раз во времена обсуждаемого Оберона чипы с таким объемом памяти стоили 3-5-ти раз дороже стандартного.
C>Приведи пример реального устройства с Обероном на борту и 512 байт ОЗУ.

Самое смешное, что он, возможно, приведет. Только это будет очередной Оберон X, которые такой же, как Оберон Y, но совсем другой (то есть в нем не будет ни активных объектов, ни защиты памяти, ни еще чего-то). В общем, то, что Klapaucius описал.

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

V>Поторопимшись ты утверждал, что есть.

Оставь демагогию и сконцентрируйся на теме. Вернемся к началу...

V>И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля. В Хаскеле даже продолжений нормальных нет,..

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

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

V>>>>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.
C>>>Можно посмотреть на emacs на Обероне?
V>>Дык, BlakcBox как бэ многократно покруче будет.
C>Там есть текстовый редактор?

Он там гипертекстовый: http://upload.wikimedia.org/wikipedia/ru/3/34/Bb-screen-4.png

Гипертестовую документацию с рич-оформлением можно вставлять прямо в исходник.

C>>>Может.
V>>Ну ты бы хотя б посмотрел на то, что производят лучшие компиляторы Схемы. Да, кое-где (мало где) идет прямо машинный код, а по большей части встроенный в конечный образ движок выполняет eval значений динамического типа.
C>А ты бы глянул на SBCL, чтоле.

Глядел, до компиляторов схем по эффективности не дотягивает. И да, утвердждается, что в машинный код переводится большая часть кода, но по моим наблюдениям — это преувеличение. Как минимум зависит от задачи. В типичных задачах, где порядка 5-10-ти уровней вложенности вызовов оно уже не умеет выводить типы.

C>>>С помощью вывода типов и их явной аннотации.
V>>Я так и думал, что имел ввиду какой-то другой язык, в котором тоже много скобок.
C>Нет, просто особое подмножество Лиспа.

Угу, как джава — особое подмножество Оберона.

V>>Угу, привели. Взяли 512 ОЗУ байт для минимального примера. Для реального там нужны будут килобайты. Как раз во времена обсуждаемого Оберона чипы с таким объемом памяти стоили 3-5-ти раз дороже стандартного.
C>Приведи пример реального устройства с Обероном на борту и 512 байт ОЗУ.

Ты нихрена не понял. 512 байт для минимального примера — это уже epic fail сам по себе. И если речь про спутники образца до 2000-го года, то там ОЗУ на контроллер поменее будет, ес-но. Типичные размеры ОЗУ я приводил. Например, для начинки самолетов сделали примерно в это же время системку, в среднем один контроллер выполнял до 3-х независимых функций, в распоряжении на все про все порядка полусотни свободных ячеек ОЗУ на контроллер. Идет обязательное дублирование, автомониторинг и прочие плюшки.

В общем, боюсь, коммерческие разработки на твоём github-е, на который ты регулярно ссылаешься, не найти. Можешь считать меня за первоисточник и говорить спасибо за информацию. См UNet здесь, разработал приличную часть разнообразной контроллерной софтовой начинки под всевозможные сервисы когда-то.

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

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

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

V>Исходно зацепились за это:
V>

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

V>Как вывод: в Хаскель необходимо добавить либо мутабельный тип данных, либо продолжения.
Что за каша? Никакого "или" тут нет. Продолжения никоим образом не избавят тебя от необходимости синхронизации мэйлбоксов в агентской среде.

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

V>>Дык, даже ты обсуждал не сами идеи а их реализацию. Т.е. даже если я и согласен почти со всем твоими замечаниями (кроме глобального ГЦ — это отдельная тема), то ты лишь подтверждаешь мой изначальный тезис.
WH>Всё что я написал это про идеологию.
WH>Синхронизация на мониторах это идеология.

Это терминология, а не идеология. Какая может быть идеология в мониторах того же дотнета? Аж никакая. Это все-навсего выбранный способ переиспользовать экземпляры мьютексов, потому что на привычных ОСях создание мьютексов — дорогое удовольствие. Даже таких, которые CriticalSection в Windows, бо там в ленивой манере создается семафор, если надо войти в ядерное ожидание.

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

WH>Единое объектное пространство это идеология.
WH>Один экземпляр модуля на всю систему это идеология.

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

Твоя Сингулярити и GAC в Windows ес-но хранят тоже ровно одну версию каждого модуля. Это принципиально. Почему так — медитировать до просветления. А ты тут на весь интернет путаешь полное имя модуля и сокращенное. Приплызд.

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

Это вовсе было неочевидно. Защищенная память только лет 10 как вытеснила все остальные и шла побеным шагом. Потому что ПО того времени содержит заведомо много низкоуровневых ошибок.

WH>Все остальное мусор.

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

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

WH>Причем тебе на это даже возразить нечего.

Да есть чего, собсно что и по всем твоим постам — твоё витание в облаках. Сингулярити НЕ является готовым к использованию продуктом, в отличие от Оберон-ОСей, которые сугубо практичные. И никогда не будет им являться. Многое из того, на чем ты пытаешься делать акцент — оно не обкатано толком даже в рамках Сингулярити, т.е. говорить не о чём совершенно. Бла-бла и сферокони. Т.е. заметь, никто не критиковал особо, ровно наоборот — с любопытством ожидали продолжения эксперимента и результатов хоть каких-то практических применений... А вышло как всегда. При всей заявленной потенциальной полезности они не сподобились развернуть хотя бы вшивую ферму веб-хостинга и погонять это дело на практике с независимыми клиентами.

Далее, не факт что каждую ОСь обязательно рассматривать как ОСь для сервера-помойки общего назначения, где мильон версий одного и того же софта должны как-то сосуществовать. Для какой-нить выделенной железки со своей задачей и автообновлением прошивки Оберон-ОСи — отличные варианты. Что и показывает популярность диалектов Оберона в военке и космосе. А вот дотнета и Сингулярити там нет и не предвидится, увы.

Ты еще упоминал вирусы, забыл напомнить. Гы, очередная поверхностность, от которой уже просто плющит. Современные вирусы — это не ошибки в ПО, это брешь в системе распространения ПО. Это насколько надо было отстать от текущего положения дел в вирусологии, чтобы упоминать вирусы рядом с верификацией... Причем, эта упомянутая брешь существует by design пока существуют вендоры независимого ПО на некую железку. И этот момент никак не перешагнуть. Никто не запрещает предположить сценарий, где "честное и лицензрованное ПО" содержит в себе специально подложенную "мину замедленного действия"... вплоть до уровня драйвера жесткого диска, например. Потом хлоп — и слив образа диска через драйвер сетевухи от того же поставщика или еще что угодно... Поэтому все эти рассуждения о вирусах можно сразу фтопку.

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

M>Самое смешное, что он, возможно, приведет. Только это будет очередной Оберон X, которые такой же, как Оберон Y, но совсем другой (то есть в нем не будет ни активных объектов, ни защиты памяти, ни еще чего-то). В общем, то, что Klapaucius описал.

Ту вообще некоторые пропагандируют, чтобы писать все на DSL, а ты встрял на каких-то смешных косметических отличиях диалектов. Не писал никогда под разные компиляторы С++? Особенно до 2003-го года (примерно)? Вот уж где натуральная помойка диалектов была, похлеще, чем в Паскале-Обероне. Или тебя смущает, что Вирт каждому диалекту своего языка придумывает другое слово-название? ИМХО, это где-то даже удобно — меньше путаницы.

M>>Самое смешное, что он, возможно, приведет. Только это будет очередной Оберон X, которые такой же, как Оберон Y, но совсем другой (то есть в нем не будет ни активных объектов, ни защиты памяти, ни еще чего-то). В общем, то, что Klapaucius описал.

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

О «косметических» отличиях говоришь только ты. При том, что понятно, что в тех же микроконтроллерах не было ни GC ни активных объектов, например. Но отличия же косметические!!! Ага-ага.

V>Не писал никогда под разные компиляторы С++? Особенно до 2003-го года (примерно)? Вот уж где натуральная помойка диалектов была, похлеще, чем в Паскале-Обероне. Или тебя смущает, что Вирт каждому диалекту своего языка придумывает другое слово-название? ИМХО, это где-то даже удобно — меньше путаницы.

Ты так и не ответил, если разница действительно только косметическая, то в Паскале было перечисленное тобой:

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

или не было? Ведь изменения, по твоим словам, лишь косметические.

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

V>>Поторопимшись ты утверждал, что есть.
N>Оставь демагогию и сконцентрируйся на теме.

Угу, как в том анекдоте. Не демагогия, а юление... не у меня, а у тебя. ))

N>

V>>И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля. В Хаскеле даже продолжений нормальных нет,..

N>Я ничего не утжерждал, кроме того, что активные обьекты существуют в Хаскеле с 90-х.

Не существуют. Ты показал не Хаскель, а другой язык с Хаскелеподобным синтаксисом. Не хочешь попытаться объяснить, что в Хаскеле означает монада IO? Почему это именно монада, а не модификатор типа? Что происходит с IO-вычислениями? Зачем? Почему тут в сигнатуре IO?

credit :: Integer -> Account -> IO ()

Что будет, если не поставить IO, но пользовать Account, который содержит MVar?

В общем, если это Хаскель, то я балерина.

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

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

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

V>Это терминология, а не идеология.
Это именно идеология. А ты полез в детали реализации. Которые никого не волнуют.

V>Какая может быть идеология в мониторах того же дотнета? Аж никакая.
Как это никакая?
Идеология очень простая.
Многопоточность строится поверх разделяемой памяти с ручной синхронизацией.
Если сравнивать с сингулярити то там мы имеем изолированные процессы, в которых строго один поток и общение при помощи посылки сообщений.
Идеологии диаметрально противоположные.

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

Я просто фигею с тебя.

V>Твоя Сингулярити и GAC в Windows ес-но хранят тоже ровно одну версию каждого модуля. Это принципиально. Почему так — медитировать до просветления. А ты тут на весь интернет путаешь полное имя модуля и сокращенное. Приплызд.
Не правильно.
В .НЕТ мы имеем приватную копию статических переменных в каждом домене.
В бутылке статические переменные модуля глобальны для всей ОС.
Те одни и те же переменные будут и для рута и для гостя.
Вот это приплызд.
И самое главное, что ты его не заметил.
И при этом строишь из себя не пойми что.
В который раз уже.

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

V>Нет никакой версионности, есть уникальное составное имя модуля, где версия — сугубо вербальное соглашения о назначении части этого составного имени.
Ты с бутылкой то разберись.

Приплызд в каждой букве.

V>Да есть чего, собсно что и по всем твоим постам — твоё витание в облаках. Сингулярити НЕ является готовым к использованию продуктом, в отличие от Оберон-ОСей, которые сугубо практичные.
Оберон ОСи невозможно использовать в реальном мире.
Их даже допилить до готовности нельзя в отличие от сингулярити.

V>При всей заявленной потенциальной полезности они не сподобились развернуть хотя бы вшивую ферму веб-хостинга и погонять это дело на практике с независимыми клиентами.
Ты говоришь так как будто бутылка на это способна

V>Что и показывает популярность диалектов Оберона в военке и космосе.
Какой только хрени там нет.

V>А вот дотнета и Сингулярити там нет и не предвидится, увы.
Ты занимаешься демагогией в стиле "сперва добейся", а не анализом технических решений.
Что не удивительно. Ведь ты раз за разом показываешь, что ты на это не способен.

V>Ты еще упоминал вирусы, забыл напомнить. Гы, очередная поверхностность, от которой уже просто плющит. Современные вирусы — это не ошибки в ПО, это брешь в системе распространения ПО.
Да ладно. Открываешь не правильный сайт и привет зверьки.

V>Это насколько надо было отстать от текущего положения дел в вирусологии, чтобы упоминать вирусы рядом с верификацией...
Ты еще и в вирусологии специалист?

V>Причем, эта упомянутая брешь существует by design пока существуют вендоры независимого ПО на некую железку.
Не существует.
Все что нужно это IOMMU и не сложный верификатор. И даже драйверы не смогут безобразничать.

При этом в бутылке защиты нет. Совсем.

V>И этот момент никак не перешагнуть. Никто не запрещает предположить сценарий, где "честное и лицензрованное ПО" содержит в себе специально подложенную "мину замедленного действия"... вплоть до уровня драйвера жесткого диска, например. Потом хлоп — и слив образа диска через драйвер сетевухи от того же поставщика или еще что угодно... Поэтому все эти рассуждения о вирусах можно сразу фтопку.
Так не сможет драйвер диска поговорить с драйвером сетевухи.
Разорвало шаблон?
Не понимаешь как?
Десять раз прочитай про сингулярити. Может тогда поймешь.

В любом случае в бутылке это может сделать любая программа. Даже калькулятор. Который по хорошему вообще никуда доступа иметь не должен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Как вывод: в Хаскель необходимо добавить либо мутабельный тип данных, либо продолжения.
N>Что за каша? Никакого "или" тут нет. Продолжения никоим образом не избавят тебя от необходимости синхронизации мэйлбоксов в агентской среде.

Синхронизацию можно доверить платформе, типа как апартментам в COM. Ключевое в том, что продолжения избавят от необходимости расширять систему типов мутабельными значениями. Достаточно будет имеющегося IO.

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

M>>>Самое смешное, что он, возможно, приведет. Только это будет очередной Оберон X, которые такой же, как Оберон Y, но совсем другой (то есть в нем не будет ни активных объектов, ни защиты памяти, ни еще чего-то). В общем, то, что Klapaucius описал.

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

M>О «косметических» отличиях говоришь только ты.

Оно так и есть, кто бы об этом не говорил.

M>При том, что понятно, что в тех же микроконтроллерах не было ни GC ни активных объектов, например. Но отличия же косметические!!! Ага-ага.

Нахрена контроллеру GC и АО? Этот вопрос уже взучал неоднократно. Еще раз — нахрена?

V>>Не писал никогда под разные компиляторы С++? Особенно до 2003-го года (примерно)? Вот уж где натуральная помойка диалектов была, похлеще, чем в Паскале-Обероне. Или тебя смущает, что Вирт каждому диалекту своего языка придумывает другое слово-название? ИМХО, это где-то даже удобно — меньше путаницы.

M>Ты так и не ответил, если разница действительно только косметическая, то в Паскале было перечисленное тобой:
M>

M>GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность изкаробки.

M>или не было? Ведь изменения, по твоим словам, лишь косметические.

Похоже, что ты окончательно запутался и нас пытаешься запутать. Ты определись — что именно тебе не нравится, что несколько ОСей были написаны на Оберонt? Т.е. что именно тебя беспокоит — язык или операционка на нем? Или ты до сих пор не сообразил, что слово "Оберон" содержится как в названиях языков так и ОСей, на нем написанных? Я прав? Т.е. из-за своей несообразительности ты просто не понимаешь, в какой подветке обсуждается Оберон-ОСи, а в каких Оберон-языки? Это залёт, курсант.

В этой подветке речь идёт сугубо о языке.

M>>При том, что понятно, что в тех же микроконтроллерах не было ни GC ни активных объектов, например. Но отличия же косметические!!! Ага-ага.

V>Нахрена контроллеру GC и АО? Этот вопрос уже взучал неоднократно. Еще раз — нахрена?

В том-то и дело, что
1. Там они не нужны
2.

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

V>>>Не писал никогда под разные компиляторы С++? Особенно до 2003-го года (примерно)? Вот уж где натуральная помойка диалектов была, похлеще, чем в Паскале-Обероне. Или тебя смущает, что Вирт каждому диалекту своего языка придумывает другое слово-название? ИМХО, это где-то даже удобно — меньше путаницы.

M>>Ты так и не ответил, если разница действительно только косметическая, то в Паскале было перечисленное тобой:
M>>

M>>GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность изкаробки.

M>>или не было? Ведь изменения, по твоим словам, лишь косметические.

V>

V>Похоже, что ты окончательно запутался и нас пытаешься запутать.

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

V>Ты определись — что именно тебе не нравится, что несколько ОСей были написаны на Оберонt? Т.е. что именно тебя беспокоит — язык или операционка на нем? Или ты до сих пор не сообразил, что слово "Оберон" содержится как в названиях языков так и ОСей, на нем написанных? Я прав? Т.е. из-за своей несообразительности ты просто не понимаешь, в какой подветке обсуждается Оберон-ОСи, а в каких Оберон-языки? Это залёт, курсант.

В этой подветке речь идёт сугубо о языке.

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

Итак, дано. Ты утверждаешь, что между тем же Паскалем и Обероном разница лишь косметическая. Думаю, пора от тебя требовать определение «косметической разницф»

Ну и напомню то, с чего ты начинал:

Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

Так о чем ты тут говорил? Об Обероне? Об ОСях, написанных на Обероне? О каких-то конкретных версиях Оберона? Или обо всем сразу?

Я, кстати, именно об этом и говорил. Все защитники Оберона крутят этим названием, как хотят — когда надо, они приводят в пример ОСь, когда надо — язык.

Так что ты определись, о чем именно ты говоришь.

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

M>>>При том, что понятно, что в тех же микроконтроллерах не было ни GC ни активных объектов, например. Но отличия же косметические!!! Ага-ага.

V>>Нахрена контроллеру GC и АО? Этот вопрос уже взучал неоднократно. Еще раз — нахрена?

M>В том-то и дело, что
M>1. Там они не нужны

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

Приведенный отрывок НИКАК не показывает, что переходить на Оберон нет смысла. Это просто мнение одного из участников форума. Причем, мнение, насколько я вижу его высказывания об embedded из разных веток и тем, сугубо умозрительное. По мне смысл ес-но есть, т.к. язык более простой (убраны вариантные типы), т.е. по нему можно породить более компактный код. Язык более детерминирован (урезана функциональность указателей, то бишь указатели стали абсолютно безопасны, насколько вообще могут быть безопасны указатели), поэтому получаемый код заведомо более надежен.

M>Понятно, что раз разработчики какого-нибудь ГЛОНАССа используют компилятор модулы и оберона, то было бы как-то странно со стороны оберон-фанатиков не трубить о том, что используется оберон, нес па? И даже если действительно используется Оберон, то используется он, как подсказывает здравый смысл, из-за совместимости с имеющимся Модула-кодом, а не из-за каких-то мифических преимуществ Оберона перед нормальными языками.

Здесь вообще идет сплошной полет мысли. Небезынтересный, но лишь полет. Языки навроде Оберона берут исключительно из-за однозначности и детерминированности порождаемого бинарного кода. Т.е. всё намного-намного проще — Оберон берут из-за требований надежности.

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

V>>Похоже, что ты окончательно запутался и нас пытаешься запутать.
M>Запутался исключительно ты. причем запутался настолько, что неспособен ответить на простейший вопрос.

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

M>Я сугубо о языке и говорю. Покажи мне, где я тут хоть слово говорю про Оберон-ОСь.

Это разве не ты принес цитирование меня в эту подветку?

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

Кроме функциональных типов все остальное перечисленное относится к среде исполнения. Или мне надо объяснять, при чем тут среда исполнения?

M>Итак, дано. Ты утверждаешь, что между тем же Паскалем и Обероном разница лишь косметическая. Думаю, пора от тебя требовать определение «косметической разницф»

Я думаю, что тебе пора бы уже вырасти и самому открыть спецификации, например, Компонентного Паскаля и Оберона-2. Второй раз на такую хрень я не поведусь. Уже и так все ссылки были даны.

M>Ну и напомню то, с чего ты начинал:
M>

M>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>Так о чем ты тут говорил? Об Обероне? Об ОСях, написанных на Обероне? О каких-то конкретных версиях Оберона? Или обо всем сразу?

В процитированном отрывке об ОС ес-но. Но такая ОС возможна лишь на заведомо безопасном языке, которым является, например, Оберон. Если ты и сейчас не смог понять зависимость этих двух ключевых компонент друг от друга, то смысл тебе вообще было участвовать? Разве ты не понял многократно приводимой аналогии с Сингулярити? С какой целью там был разработан свой язык? Или, раз там название языка "Барток" отличается от названия ОС "Сингулярити", то у тебя от этого меньше каши в голове? Думаю, твоя путаница исключительно из-за попытки объять материал поверхностно. А когда поверхностно не получается — ты выплескиеваешь своё раздражение.

Еще раз. Последний. Отсылаю к переведенному и выложенному на этом сайте техническому репору по Сингулярити. Читать и понимать целиком. Технические репорты про Оберон-ОСи ты читать всё-равно не будешь, это понятно и так. В следующий раз, когда тебе опять будет что-то непонятно, я буду отсылать к аналогочным моментам из Сингулярити, и давай договоримся, что к тому моменту ты уже будешь иметь представление, о чем речь, ок?

M>Я, кстати, именно об этом и говорил. Все защитники Оберона крутят этим названием, как хотят — когда надо, они приводят в пример ОСь, когда надо — язык.

1. Из всех участников спора путаешься только ты.
2. Ключевые св-ва ОС (повторюсь), требуют заведомо безопасного языка.

M>Так что ты определись, о чем именно ты говоришь.

Я могу определить тебя: в этой подветке речь шла о применении ЯВУ Оберон в микроконтроллерах.

Еще вопросы?

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

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

V>>Это терминология, а не идеология.
WH>Это именно идеология. А ты полез в детали реализации. Которые никого не волнуют.

V>>Какая может быть идеология в мониторах того же дотнета? Аж никакая.
WH>Как это никакая?
WH>Идеология очень простая.
WH>Многопоточность строится поверх разделяемой памяти с ручной синхронизацией.
WH>Если сравнивать с сингулярити то там мы имеем изолированные процессы, в которых строго один поток и общение при помощи посылки сообщений.
WH>Идеологии диаметрально противоположные.

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

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

V>>Вот эта твоя поверхностность — ответ почему неохота лишний раз обсуждать с тобой подробности. Сначала тебя за твою поверхностность поймаешь, а потом ты будешь изворачиваться и хамить.
WH>

Я просто фигею с тебя.

V>>Твоя Сингулярити и GAC в Windows ес-но хранят тоже ровно одну версию каждого модуля. Это принципиально. Почему так — медитировать до просветления. А ты тут на весь интернет путаешь полное имя модуля и сокращенное. Приплызд.
WH>Не правильно.
WH>В .НЕТ мы имеем приватную копию статических переменных в каждом домене.

Вот опять...
Это в C# так. А в чистой программе на CLR я могу иметь глобальные на процесс, видимые из каждого домена. Подсказать, как это работает, или ты уже понял, пока читал?

WH>В бутылке статические переменные модуля глобальны для всей ОС.

Разница в терминологии.

Ничего, если я домен буду считать эдаким объектом? Можно?

WH>Те одни и те же переменные будут и для рута и для гостя.
WH>Вот это приплызд.

В виндах хенлды тоже одни на всех. И сокеты в Сингулярити тоже. А эти все сокеты где-то хранятся в одном списке, в котором лазят и рутовые программы и юзверские. Не забыл еще, что память в обоих рассматриваемых ОС плоская?

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

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

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

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

V>>Нет никакой версионности, есть уникальное составное имя модуля, где версия — сугубо вербальное соглашения о назначении части этого составного имени.
WH>Ты с бутылкой то разберись.

Да сам разбирись. Там просто развитие системы остановилось. В Windows тоже GAC далеко не сразу появился, но появился очень легко. Там нехрен делать, вообще-то, была бы потребность. Я так думаю, что в первых версиях Оберон-ОСей им никакой DLL-hell пока мест не грозил.

WH>Приплызд в каждой букве.

Просто ты не понимаешь фразы "версия — сугубо вербальное соглашения о назначении части этого составного имени".
Вопрос на засыпку: какой "физический смысл" Public Token Key в виндовом GAC? Зачем рядом с версией есть еще один механим?

V>>Да есть чего, собсно что и по всем твоим постам — твоё витание в облаках. Сингулярити НЕ является готовым к использованию продуктом, в отличие от Оберон-ОСей, которые сугубо практичные.
WH>Оберон ОСи невозможно использовать в реальном мире.
WH>Их даже допилить до готовности нельзя в отличие от сингулярити.

V>>При всей заявленной потенциальной полезности они не сподобились развернуть хотя бы вшивую ферму веб-хостинга и погонять это дело на практике с независимыми клиентами.
WH>Ты говоришь так как будто бутылка на это способна

Бутылка — лишь один из проектов. Просто заведомо безопасный язык развязывает руки.
А вообще все ссылки я уже давал:
http://oberoncore.ru/wiki/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F
http://www.ocp.inf.ethz.ch/wiki/

Утверждается, что на бутылке работали коммерчесские сайты. Она идет со встроенными FTP/HTTP серваками, так что без проблем.

V>>Что и показывает популярность диалектов Оберона в военке и космосе.
WH>Какой только хрени там нет.

Напротив, разнообразие небольшое. И среди этого небольшого разнообразия Оберон выглядит далеко не бедным родственником.

V>>А вот дотнета и Сингулярити там нет и не предвидится, увы.
WH>Ты занимаешься демагогией в стиле "сперва добейся", а не анализом технических решений.
WH>Что не удивительно. Ведь ты раз за разом показываешь, что ты на это не способен.

Влад, ты?

V>>Ты еще упоминал вирусы, забыл напомнить. Гы, очередная поверхностность, от которой уже просто плющит. Современные вирусы — это не ошибки в ПО, это брешь в системе распространения ПО.
WH>Да ладно. Открываешь не правильный сайт и привет зверьки.

Не открывай под админом.

V>>Причем, эта упомянутая брешь существует by design пока существуют вендоры независимого ПО на некую железку.
WH>Не существует.
WH>Все что нужно это IOMMU и не сложный верификатор. И даже драйверы не смогут безобразничать.

1. Если я несмогу автообновлять свой софт в Сингулярити, то Сингулярити заведомо ненужна.
2. А если смогу, и являюсь независимым вендором, то мою личную злонамеренность ни один верификатор не обнаружит.

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

WH>При этом в бутылке защиты нет. Совсем.

В Сингулярити тоже нет. Если ты про верификацию байткода — то это исключительно ради поддержки многих языков программирования. В Обероне точно такая же верификация вынесена на уровень языка. А если же ты имеешь ввиду проверку подписи ПО — это сугубо модель распространения, о которой я говорю. Как уже дважды сказал о том, что нагнуть ЛЮБУЮ систему распространения ПО от независимых вендоров — как 2 пальца об асфальт. Достаточно иметь злонамерения и пройти все необходимые процедуры, не выдавая предварительно свои злонамерения.

V>>И этот момент никак не перешагнуть. Никто не запрещает предположить сценарий, где "честное и лицензрованное ПО" содержит в себе специально подложенную "мину замедленного действия"... вплоть до уровня драйвера жесткого диска, например. Потом хлоп — и слив образа диска через драйвер сетевухи от того же поставщика или еще что угодно... Поэтому все эти рассуждения о вирусах можно сразу фтопку.
WH>Так не сможет драйвер диска поговорить с драйвером сетевухи.
WH>Разорвало шаблон?
WH>Не понимаешь как?
WH>Десять раз прочитай про сингулярити. Может тогда поймешь.

1. Сможет через прикладную программку.
2. Пример на засыпку: по HDMI идут потоки аудио и видео, причем, оба драйвера ОБЯЗАНЫ работать совместно, чтобы правильно выставлять режимы работы одной и той же микросхемы. Т.е. или Сингулярити позволит так делать, или она не сможет подержать HDMI или любой другой комбинированный интерфейс, т.е. Сингулярити будет ненужна.

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

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

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

V>>Это насколько надо было отстать от текущего положения дел в вирусологии, чтобы упоминать вирусы рядом с верификацией...
WH>Ты еще и в вирусологии специалист?

Отдельная тема... Скажем так, специалист в том, как всё утсроено и работает, начиная от физических процессов в p-n переходах, через устройство процов, контролеров, шин, плат, драйверов и т.д. Работа такая была по большей части. Вирусами не балуюсь уже давно, но пару раз антивирусы писать приходилось, когда цепляли гадость на все компы в лаборатории, а обновленный Лозинский или чуть позже DrWeb с нужной сигнатурой еще не вышел. Ну и защиты ломал по молодости, ес-но. А лет 5 назад не по молодости, но захотелось посмотреть в оплный рост работу конкурирующего продукта, и за пару дней нагнул их сверх-навороченную лицензионную защиту. В общем, имею некоторое представление об организации защит и способах их ломания... А твои "знания", которыми ты пальцуешься, похоже, сугубо из технического репорта подчерпнуты.. Ты даже не понимаешь что я имею ввиду, напирая на "модель распространения ПО". На самом деле тут борьба противоположностей: нефик делать вообще запретить обновление/установку дополнительного ПО (банально не оставить в системе ср-в для этого), тогда никакие вирусы не страшны. Или наоборот, когда такие ср-ва есть, то обязательно есть способы ими воспользоваться. Посмотри, кстате, рефлектором на этот детсад в дотнете с правами доступа к различным аспектам ф-сти базовой библиотеки. Сделано для дурачков. Обходится дублирующей реализацией на раз.

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

V>Вот за что я не люблю с тобой что-либо обсуждать в последнее время. Ты утратил присущее тебе когда-то воображение.
Нет. Просто за последние несколько лет я развился, и мое воображение работает на намного более высоком уровне, чем ты в состоянии понять.

V> В обсуждаемом предмете нет никаких противоположностей, есть разная терминология. Тут это назвали процессы, там — активные объекты. А происходит абсолютно одно и то же.
Если не считать того что в одном случае мы имеем изолированные объектные пространства и обмен сообщениями, а в другом общую совершенно не защищенную от гонок кучу и мониторы для синхронизации.
Ну, совсем нет отличий.

V>Это в C# так. А в чистой программе на CLR я могу иметь глобальные на процесс, видимые из каждого домена. Подсказать, как это работает, или ты уже понял, пока читал?
Да плевать. CLR меня вообще не волнует.
Важно то, что в бутылке есть только глобальные на всю ОС.
Причем по большому счету глобальные переменные вообще ошибка.
И в правильной системе их вообще не должно быть. Даже глобальных для процесса.

WH>>В бутылке статические переменные модуля глобальны для всей ОС.
V>Разница в терминологии.

V>Ничего, если я домен буду считать эдаким объектом? Можно?
Специально для тебя: В бутылке всего один домен на всю ОС.
Да и сингулярити от обычного CLR немало отличается.

V>В виндах хенлды тоже одни на всех. И сокеты в Сингулярити тоже. А эти все сокеты где-то хранятся в одном списке, в котором лазят и рутовые программы и юзверские. Не забыл еще, что память в обоих рассматриваемых ОС плоская?
Это полный приплызд.
Плоское там физическое адресное пространство.
При этом логическое пространство в бутелке одно на всех.
А в сингулярити одно на процесс. Плюс куча обмена, которая работает по весьма специфическим правилам.

V>В общем, нет никакого приплызда, если код дает гарантии не хуже, чем гарантии защищенной памяти. Т.е. абсолютно никакой разницы нет.
Разница огромна.

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

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

Эти виды гонок настолько разные, что по-хорошему их нужно называть по-разному.

V>Чтобы я "это заметил" я должен считать железячников умнее программистов. Хотя это так и есть, ес-но,
Это ты так весь форум обосрал?

V> но если дать язык и среду исполнения, которая вообще никак не дает нарушать контракты, то даже глупый программист с глупым модулем не сможет завалить всю систему. Ну разве что в своп всё уйдет, точно так же как в случае глупой программы поверх ащищенной памяти.
В том то и дело, что есть масса способов завалить бутылку.
И ни один из них не работает в случае сингулярити.
Сингулярити даже в своп хрен отправишь.
Просто по тому, что можно прибить зажравшийся процесс.
В бутылке это сделать невозможно. Там объектное пространство одно на всех.
Те если кто-то сожрал всю память, придётся перезагружать всю систему.
Это что так сложно понять?

V>>>Ты еще упоминал вирусы, забыл напомнить. Гы, очередная поверхностность, от которой уже просто плющит. Современные вирусы — это не ошибки в ПО, это брешь в системе распространения ПО.
WH>>Да ладно. Открываешь не правильный сайт и привет зверьки.
V>Не открывай под админом.
Так и без админа пролазят. Я даже не уверен, что каспер всех поймает.

V>В Сингулярити тоже нет. Если ты про верификацию байткода — то это исключительно ради поддержки многих языков программирования.
Лолчто?
Верификация нужна для того чтобы программа не творила что попало.

V>В Обероне точно такая же верификация вынесена на уровень языка.
А бинарник скаченный с инета может делать что угодно.

V>А если же ты имеешь ввиду проверку подписи ПО — это сугубо модель распространения, о которой я говорю.
Зачем подпись калькулятору?
Или игрушке?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Отдельная тема... Скажем так, специалист в том, как всё утсроено и работает, начиная от физических процессов в p-n переходах, через устройство процов, контролеров, шин, плат, драйверов и т.д. Работа такая была по большей части. Вирусами не балуюсь уже давно, но пару раз антивирусы писать приходилось, когда цепляли гадость на все компы в лаборатории, а обновленный Лозинский или чуть позже DrWeb с нужной сигнатурой еще не вышел. Ну и защиты ломал по молодости, ес-но. А лет 5 назад не по молодости, но захотелось посмотреть в оплный рост работу конкурирующего продукта, и за пару дней нагнул их сверх-навороченную лицензионную защиту. В общем, имею некоторое представление об организации защит и способах их ломания... А твои "знания", которыми ты пальцуешься, похоже, сугубо из технического репорта подчерпнуты.. Ты даже не понимаешь что я имею ввиду, напирая на "модель распространения ПО". На самом деле тут борьба противоположностей: нефик делать вообще запретить обновление/установку дополнительного ПО (банально не оставить в системе ср-в для этого), тогда никакие вирусы не страшны. Или наоборот, когда такие ср-ва есть, то обязательно есть способы ими воспользоваться. Посмотри, кстате, рефлектором на этот детсад в дотнете с правами доступа к различным аспектам ф-сти базовой библиотеки. Сделано для дурачков. Обходится дублирующей реализацией на раз.
Ох. Пальцы веером. Сопли пузырями.
Давай великий гуру.
Расскажи мне как прикладному ПО.
Не драйверу винта сломать верификатор?
Ты даже драйвером сетевухи или видюхи это сделать не сможешь.
Память мы испортить не можем.
Глобальных переменных нет. Те вызвать системные функции, откуда попало, мы тоже не можем.
Процессу передается очень урезанный сервис имен. Через который он может обращаться к разрешённой части системы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

Никто не в состоянии понять. Ты уже как домашний питомец — всё понимаешь, но сказать не можешь.

V>> В обсуждаемом предмете нет никаких противоположностей, есть разная терминология. Тут это назвали процессы, там — активные объекты. А происходит абсолютно одно и то же.
WH>Если не считать того что в одном случае мы имеем изолированные объектные пространства и обмен сообщениями, а в другом общую совершенно не защищенную от гонок кучу и мониторы для синхронизации.
WH>Ну, совсем нет отличий.

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

V>>Это в C# так. А в чистой программе на CLR я могу иметь глобальные на процесс, видимые из каждого домена. Подсказать, как это работает, или ты уже понял, пока читал?
WH>Да плевать. CLR меня вообще не волнует.
WH>Важно то, что в бутылке есть только глобальные на всю ОС.
WH>Причем по большому счету глобальные переменные вообще ошибка.
WH>И в правильной системе их вообще не должно быть. Даже глобальных для процесса.

Ты точно уверен, что твое воображение развилось, а не ровно наоборот?

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

WH>>>В бутылке статические переменные модуля глобальны для всей ОС.
V>>Разница в терминологии.

V>>Ничего, если я домен буду считать эдаким объектом? Можно?
WH>Специально для тебя: В бутылке всего один домен на всю ОС.

И? Порассуждай чуть дальше. Одну подсказку я уже дал. Вот вторая: в UML глобальный контекст представляют в виде объекта-синглтона. Вот третья: а что если объект-контекст не будет синглтоном?

WH>Да и сингулярити от обычного CLR немало отличается.

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

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

Непринципиально. Это другой взгляд на одни и те же происходящие процессы. Похоже, аргумент про гарантии до тебя не доходит...

V>>В общем, нет никакого приплызда, если код дает гарантии не хуже, чем гарантии защищенной памяти. Т.е. абсолютно никакой разницы нет.
WH>Разница огромна.

Разница в терминологии.

V>>Я это и не мог заметить, т.к. если уровень гарантий идентичен, то неважно на каком уровне эти гарантии реализованы.
WH>Да правда что ли?
WH>И что же мне помешает устроить гонки в бутылке?
WH>А ничего. Достаточно где-то забыть синхронизацию.

А если мне нужны эти гонки by design? Если читаем и пишем машинное слово? Нахрена мне его синхронизировать?
И вообще, если синхронизация декларативная, то забыть ее трудно — пометил класс и всё. Ведь не надо, как в дотнете, обкладывать мониторами блоки кода вручную.

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

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

V>>Чтобы я "это заметил" я должен считать железячников умнее программистов. Хотя это так и есть, ес-но,
WH>Это ты так весь форум обосрал?

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

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

WH>В бутылке это сделать невозможно. Там объектное пространство одно на всех.
WH>Те если кто-то сожрал всю память, придётся перезагружать всю систему.
WH>Это что так сложно понять?

Можно остановить и удалить активный объект точно так же.

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

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

V>>В Сингулярити тоже нет. Если ты про верификацию байткода — то это исключительно ради поддержки многих языков программирования.
WH>Лолчто?
WH>Верификация нужна для того чтобы программа не творила что попало.

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

V>>В Обероне точно такая же верификация вынесена на уровень языка.
WH>А бинарник скаченный с инета может делать что угодно.

А кто ему даст запуститься-то, бинарнику?
Пусть приходит в виде объектного файла и собирается/линкуется по месту.

V>>А если же ты имеешь ввиду проверку подписи ПО — это сугубо модель распространения, о которой я говорю.
WH>Зачем подпись калькулятору?
WH>Или игрушке?

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

V>>Правильно, потому что основную проблему в ПО не решает даже аппаратная защита памяти. Только модель распространения ПО решает. Можно сделать так, чтобы никакой левый калькулятор не смог попасть в систему. А если же откроешь дверь для всех, то какие бы преграды не городил, они будут отличаться только сложностью преодоления.
WH>Разница между сингулярити и бутылкой в том, что в случае сингулярити нужно сертифицировать очень узкий набор драйверов.

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

WH>Например, драйвера сетевухи и видюхи сертифицировать не нужно.
WH>Они ничего не могут.

Могут. )))
Оба могут органиозвать утечку информации в содействии с другим ПО.

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

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

В общем, ЧТД. Идет спекуляция на уровне "легко-сложно", а не на уровне "возможно-невозможно". Потому что возможно.

WH>В случае с бутылкой нужно сертифицировать абсолютно все.

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

И да, мне таки любопытна работа твоего воображения на этот счет:

2. Пример на засыпку: по HDMI идут потоки аудио и видео, причем, оба драйвера ОБЯЗАНЫ работать совместно, чтобы правильно выставлять режимы работы одной и той же микросхемы. Т.е. или Сингулярити позволит так делать, или она не сможет подержать HDMI или любой другой комбинированный интерфейс, т.е. Сингулярити будет ненужна.

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

WH>Глобальных переменных нет. Те вызвать системные функции, откуда попало, мы тоже не можем.

Мде? А как же драйвер сетевухи будет работать-то? Ему именно системные ф-ии будут нужны в большом кол-ве. И порты и ДМА и таймеры и т.д. т.п.

WH>Процессу передается очень урезанный сервис имен. Через который он может обращаться к разрешённой части системы.

Да пофиг. При наличии "закладок" достаточно будет сделть невинное обращение к разрешенной ф-сти с "магическим" аргументом. Именно так работают современные ботнеты.

V>Здесь вообще идет сплошной полет мысли. Небезынтересный, но лишь полет. Языки навроде Оберона берут исключительно из-за однозначности и детерминированности порождаемого бинарного кода. Т.е. всё намного-намного проще — Оберон берут из-за требований надежности.

Угу. Берется кастрированный примитивный язык, который один-в-один переводится в ассемблер. Вау. Это СИЛА!!!!

M>>Я сугубо о языке и говорю. Покажи мне, где я тут хоть слово говорю про Оберон-ОСь.

V>Это разве не ты принес цитирование меня в эту подветку?
V>

V>GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность изкаробки.

V>Кроме функциональных типов все остальное перечисленное относится к среде исполнения. Или мне надо объяснять, при чем тут среда исполнения?

Ага. То есть к Оберону, как языку, оно не имеет никакого отношения вообще. Что и

M>>Итак, дано. Ты утверждаешь, что между тем же Паскалем и Обероном разница лишь косметическая. Думаю, пора от тебя требовать определение «косметической разницф»

V>Я думаю, что тебе пора бы уже вырасти и самому открыть спецификации, например, Компонентного Паскаля и Оберона-2. Второй раз на такую хрень я не поведусь. Уже и так все ссылки были даны.

Ну да ну да. Ты же у нас единственный, кто

M>>Ну и напомню то, с чего ты начинал:
M>>

M>>Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

M>>Так о чем ты тут говорил? Об Обероне? Об ОСях, написанных на Обероне? О каких-то конкретных версиях Оберона? Или обо всем сразу?

V>В процитированном отрывке об ОС ес-но.

Почему естественно, известно только тебе.

V>Но такая ОС возможна лишь на заведомо безопасном языке, которым является, например, Оберон.

Среда, которая позволяет GC, асинхронные вызовы, динамическую загрузку кода, возможна только на Обероне? Бгггг. Erlang ржет-не-может.

M>>Я, кстати, именно об этом и говорил. Все защитники Оберона крутят этим названием, как хотят — когда надо, они приводят в пример ОСь, когда надо — язык.

V>1. Из всех участников спора путаешься только ты.
V>2. Ключевые св-ва ОС (повторюсь), требуют заведомо безопасного языка.

Нуну. Какие из «ключевых св-в» Оберон-ОСи требуют примитивного языка Оберон?

V>Я утверждаю, что в случае гарантий корректности работы кода разницы нет совсем.

Оберон не гарантирует корректность работы кода.

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

V>Мде? А как же драйвер сетевухи будет работать-то? Ему именно системные ф-ии будут нужны в большом кол-ве. И порты и ДМА и таймеры и т.д. т.п.
Читай про сингулярити. 100 раз.
Все что нужно от железа это IOMMU. И все. Остальное проверит верификатор.

V>Да пофиг. При наличии "закладок" достаточно будет сделть невинное обращение к разрешенной ф-сти с "магическим" аргументом. Именно так работают современные ботнеты.
Откуда бы им взяться?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

Полнейший отрыв от реальности.
Ты не знаешь, ни как работает бутылка. Ни как работает сингулярити.

V>Никто не в состоянии понять. Ты уже как домашний питомец — всё понимаешь, но сказать не можешь.
Данная ветка показывает что это тебя все не понимают.
Может проблема в тебе?
Подумай об этом.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>Все что нужно от железа это IOMMU. И все. Остальное проверит верификатор.

Справедливости ради нужно отметить: невозможно сделать хорошо защищенную систему исключительно программными средствами, и сингулярити тут не панацея. Ну будет у нас монструозный пакет типа MS Office или Photoshop, который затребует при установке разрешение на доступ ко всему (прямо или косвенно). Все будут его ставить — альтернативы-то нет — вот и дыра в этих всех хваленых защитах. Кстати и не обязательно большой пакет — простой пользователь в общем случае вообще не представляет, какие права нужны той или иной программе. Ставит какой-нибудь CD-резак с вирусом, тот его просит — дай права на сервис чтения-записи диска, юзер дает. И все. В общем, потенциальная защищенность сингулярити сильно преувеличена.

Что тут делать — сложно сказать, наверное нужны комплексные меры.

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

C>>>Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.

V>Вот, подтверждение. Про модулу-2 вопросов у него нет, про компонентный паскаль тоже наверняка нет, а про точно такой же оберон — есть. ЧТД.

Думаю, что про компонентный паскаль (если имеется в виду очередной "Оберон", а не Дельфи) у него тоже будут вопросы. Модула-2 — язык полезный и используемый когда-то. Адекватный своему времени. Оберон, с другой стороны, нелепая попытка гальванизировать труп, Кобол++. Язык, совершенно своему времени неадекватный. Программист на модуле-2 озабочен тем, как переползти на С и избавиться от всего этого легаси, а тут ему предлагают то же самое, только без обратной совместимости, с нулевой распространенностью и без очевидных бенефитов. Идея о том, что Оберон способен заинтересовать значительное число из тех, кто не пишет сейчас на Модуле-2 — вообще смехотворна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Как вывод: в Хаскель необходимо добавить либо мутабельный тип данных, либо продолжения. Насколько я вижу, то бишь не вижу ничего интересного на Concurrent Haskell, попытка пойти по пути наименьшего сопротивления (добавления мутабельного типа данных) не вызвала поддержки масс.

Что? Да в GHC-Хаскеле с допотопных времен несколько разновидностей мутабельных типов данных с разными средствами контроля, от ссылочно прозрачных изменений "на месте" и до транзакционной памяти.

V>Предлагаю эксперименты с мутабельностью в Хаскеле сразу в топку как противоречащие концепции языка и сделать таки нормальные продолжения. ))

Эксперименты с контролируемой мутабельностью — одна из основных целей языка.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ARK>Справедливости ради нужно отметить: невозможно сделать хорошо защищенную систему исключительно программными средствами, и сингулярити тут не панацея.
Программными средствами можно закрыть все дырки для молчаливого проникновения.

ARK>Ну будет у нас монструозный пакет типа MS Office или Photoshop, который затребует при установке разрешение на доступ ко всему (прямо или косвенно).
Не затребует.
И тому и другому нужно только локальное для приложение и пользователя хранилище и сервис открытия файлов который открывает системный диалог, в котором пользователь может выбрать файл.

Ничего другого им не надо.

ARK>Все будут его ставить — альтернативы-то нет — вот и дыра в этих всех хваленых защитах.
Первое что этим разработчикам скажут корпоративные админы это: Нахрена вам столько прав?
А учитывая, что основной рынок это корпорации...

ARK>Кстати и не обязательно большой пакет — простой пользователь в общем случае вообще не представляет, какие права нужны той или иной программе. Ставит какой-нибудь CD-резак с вирусом, тот его просит — дай права на сервис чтения-записи диска, юзер дает. И все. В общем, потенциальная защищенность сингулярити сильно преувеличена.
Если пользователя будут просить ввести админский пароль то он 10 раз подумает.
А если не подумает, то тут ничего не поможет. От социальной инженерии ничего не спасет.

ARK>Что тут делать — сложно сказать, наверное нужны комплексные меры.
Пользователей воспитывать.
Но и без программной защиты тоже не жизнь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Мде? А как же драйвер сетевухи будет работать-то? Ему именно системные ф-ии будут нужны в большом кол-ве. И порты и ДМА и таймеры и т.д. т.п.
WH>Читай про сингулярити. 100 раз.
WH>Все что нужно от железа это IOMMU. И все. Остальное проверит верификатор.

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

Или мы говорим с тобой о разных Сингулярити?:

Система ввода/вывода Singularity состоит из трех слоев: HAL, менеджера ввода/вывода и драйверов. HAL – это маленькая доверенная абстракция аппаратного обеспечения РС: абстракции IoPorts, IoDma, IoIrq и IoMemory для доступа к устройствам; интерфейсы к таймерам, контроллер прерываний, часы реального времени и отладочная консоль; заглушка для отладки ядра; регистратор событий, векторы прерываний и исключений; обнаружение ресурсов BIOS и код связывания стека. HAL написан на C#, C++ и ассемблере. Доля ассемблера и C++ в HAL составляет примерно 5% от доверенного кода системы (35 из 561 файла).

Ядро Singularity использует манифест для создания и привязки драйверов устройств. При запуске ядро производит «plug and play»-конфигурирование системы. Ядро использует информацию, полученную загрузчиком из BIOS и от шин, например, PCI, для перечисления устройств, запуска подходящих драйверов и передачи этим драйверам объектов, инкапсулирующих доступ к аппаратному обеспечению.

... и далее по тексту.
Нагнуть всё это — как 2 пальца об асфальт. Происходящее ничем принципиально не отличается от традиционного MMIO, со всеми сопровождаемыми граблями. (Просто IOMMU — это ориентировка на конкретную архитектуру шины).

Еще раз — ключевые моменты безопасности кода находятся в системе распространения ПО и нигде больше. А эта система целиком выходит далеко за рамки ОС.

V>>Да пофиг. При наличии "закладок" достаточно будет сделть невинное обращение к разрешенной ф-сти с "магическим" аргументом. Именно так работают современные ботнеты.
WH>Откуда бы им взяться?

Уже раз 100 писал — из злонамеренного ПО. Даже сертифицированного.
Теперь смотри сюда:

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

Если драйвер может открывать файл, вот тебе каким образом сетевой драйвер попросит у драйвера винта очередную порцию бинарного образа диска — через магические имена файлов. Я был малость в недоумении, что ты сразу не догадался. Не изучал работу современных ботнетов? И да, под админом всё-таки не надо в и-нет шастать. Бот не может сразу встать в виде драйвера, но если у него хватит прав, он пропишет себя в реестре или еще где в юзерском автозапуске и сядет при последующей перезагрузке. Т.е. речь всего-то о доступных боту привилегиях. Не давай их ему.

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

V>>Я утверждаю, что в случае гарантий корректности работы кода разницы нет совсем.
M>Оберон не гарантирует корректность работы кода.

Если ты про "логическую" корректность, то никто не гарантирует. Никакой компилятор за тебя не догадается, если ты хотел написать a+b, но по ошибке написал a-b. Речь идет о типобезопасности и детерминированности. Даже зависимые типы покрывают весьма ограниченный круг логических проверок.

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

WH>Полнейший отрыв от реальности.
WH>Ты не знаешь, ни как работает бутылка. Ни как работает сингулярити.

ЧТД. Уже не первый раз цепляешься за терминологию, на этом всё и заканчивается. Я рассуждаю сугубо о происходящих вещах, а не о том, кто какое им дал именование.

V>>Никто не в состоянии понять. Ты уже как домашний питомец — всё понимаешь, но сказать не можешь.
WH>Данная ветка показывает что это тебя все не понимают.
WH>Может проблема в тебе?
WH>Подумай об этом.

Я бы предпочел конкретику, но ты её не умеешь. Поэтому, увы, питомец.

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

V>Нагнуть всё это — как 2 пальца об асфальт. Происходящее ничем принципиально не отличается от традиционного MMIO, со всеми сопровождаемыми граблями. (Просто IOMMU — это ориентировка на конкретную архитектуру шины).
И как ты собрался это нагнуть?
Особенно меня интересует, как ты собрался нагнуть следующую версию сингулярити которая verve называется.
Там только верификатор доверенный.
Все остальное верифицируется.

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

V>Уже раз 100 писал — из злонамеренного ПО. Даже сертифицированного.
И откуда в сертифицированном ФСБ ПО закладки сделанные по заказу ЦРУ?

V>Если драйвер может открывать файл, вот тебе каким образом сетевой драйвер попросит у драйвера винта очередную порцию бинарного образа диска — через магические имена файлов.
Ох.
Драйвер сетевухи не может открывать файл.
Прав у него таких нет.

V>Я был малость в недоумении, что ты сразу не догадался. Не изучал работу современных ботнетов? И да, под админом всё-таки не надо в и-нет шастать. Бот не может сразу встать в виде драйвера, но если у него хватит прав, он пропишет себя в реестре или еще где в юзерском автозапуске и сядет при последующей перезагрузке. Т.е. речь всего-то о доступных боту привилегиях. Не давай их ему.

И как он это сделает?
Система просто не даст ему установится без того чтобы спросить пользователя.
А если он лезет куда-то, то еще и админский пароль спросит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

V>>>Я утверждаю, что в случае гарантий корректности работы кода разницы нет совсем.
M>>Оберон не гарантирует корректность работы кода.

V>Если ты про "логическую" корректность, то никто не гарантирует. Никакой компилятор за тебя не догадается, если ты хотел написать a+b, но по ошибке написал a-b. Речь идет о типобезопасности

https://student.brighton.ac.uk/burks/language/oberon/o2report/o2report.htm

IMPORT System; 

x : AnotherType;
m : MyType;

m := VAL(MyType, x);
PUT(0, m);

в любом модуле.

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

V>>Я был малость в недоумении, что ты сразу не догадался. Не изучал работу современных ботнетов? И да, под админом всё-таки не надо в и-нет шастать. Бот не может сразу встать в виде драйвера, но если у него хватит прав, он пропишет себя в реестре или еще где в юзерском автозапуске и сядет при последующей перезагрузке. Т.е. речь всего-то о доступных боту привилегиях. Не давай их ему.
WH>

И как он это сделает?
WH>Система просто не даст ему установится без того чтобы спросить пользователя.
WH>А если он лезет куда-то, то еще и админский пароль спросит.

Это я про винды и твой случай, что лезут гадости с сайтов. Админский пароль вводить не надо, достаточно быть пользователем с админскими правами и нажать ОК в диалоге запроса эскалации привилегий.

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

V>>Нагнуть всё это — как 2 пальца об асфальт. Происходящее ничем принципиально не отличается от традиционного MMIO, со всеми сопровождаемыми граблями. (Просто IOMMU — это ориентировка на конкретную архитектуру шины).
WH>И как ты собрался это нагнуть?

Будучи производителем какой-нить железки и драйвера под нее? Элементарно. Даже бери драйвер какого-нить проприетарного VPN с уникальным шифрованием безо всякой железки.

WH>Особенно меня интересует, как ты собрался нагнуть следующую версию сингулярити которая verve называется.

Вот как будет, тогда и посмотрим.

V>>Еще раз — ключевые моменты безопасности кода находятся в системе распространения ПО и нигде больше. А эта система целиком выходит далеко за рамки ОС.
WH>В системе распространения пары критичных драйверов.

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

WH>Все остальное ПО можно распространять как угодно.

Поэтому можно сделать комплекс из драйверов с закладками и юзерского ПО, "умеющего" с этими закладками работать. Впрочем, я уже об этом писал в этой подветке.

V>>Уже раз 100 писал — из злонамеренного ПО. Даже сертифицированного.
WH>И откуда в сертифицированном ФСБ ПО закладки сделанные по заказу ЦРУ?

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

V>>Если драйвер может открывать файл, вот тебе каким образом сетевой драйвер попросит у драйвера винта очередную порцию бинарного образа диска — через магические имена файлов.
WH>Ох.
WH>Драйвер сетевухи не может открывать файл.
WH>Прав у него таких нет.

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

Ну и такой момент:

Единственный небезопасный аспект интерфейса драйвер-устройство – это DMA. Существующая архитектура DMA не содержит никакой защиты памяти, поэтому неправильно работающий драйвер может заставить работающее с DMA устройство переписать любую часть памяти. Разнообразие интерфейсов DMA помешало нам найти хорошую абстракцию для их инкапсуляции. Мы надеемся, что в будущем аппаратное обеспечение будет предоставлять защиту памяти для DMA.

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

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

V>Поэтому, увы, питомец.
Я понять не могу. Ты что на бан нарываешься?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>https://student.brighton.ac.uk/burks/language/oberon/o2report/o2report.htm

Уже отвечал на это. Зависимости от модулей явные. Никто не мешает запретить загрузку юзерских модулей с зависимостями от SYSTEM.

M>>https://student.brighton.ac.uk/burks/language/oberon/o2report/o2report.htm

V>Уже отвечал на это. Зависимости от модулей явные. Никто не мешает запретить загрузку юзерских модулей с зависимостями от SYSTEM.

1. Это значит, что при наличии SYSTEM типобезопасностью в Обероне и не пахнет
2. Каким образом будет происходить этот запрет?

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

V>Будучи производителем какой-нить железки и драйвера под нее? Элементарно. Даже бери драйвер какого-нить проприетарного VPN с уникальным шифрованием безо всякой железки.
Давай конкретно.
Только про винду не надо. Не про нее разговор.

WH>>Особенно меня интересует, как ты собрался нагнуть следующую версию сингулярити которая verve называется.
V>Вот как будет, тогда и посмотрим.
Оно давно есть.

V>Поэтому можно сделать комплекс из драйверов с закладками и юзерского ПО, "умеющего" с этими закладками работать. Впрочем, я уже об этом писал в этой подветке.
Осталось выяснить, откуда же эти закладки возьмутся?

V>Я вообще плохо себе представляю тотальную проверку десятков миллионов строк кода. Сколько не проходили верификацию ПО... я бы сказал, что этот процесс весьма поверхностный.
Да не надо десятки миллионов сертифицировать. Это тебе не винда.
Тут хватит верификатор и пару драйверов проверить.
Или можно даже свой верификатор написать. Для гарантии. И гонять оба.

V>В переведенном техническом репорте прямо говорится, что доступ к файловой системе из драйвера возможен по каналам.
Если чуть изменить политику сервиса имен для драйверов, то невозможен.

V>Т.е. можно заставить устройство записать байты не в ту память. А почему это нельзя проверить? Потому что набор регистров команд и их семантика у контроллеров DMA специфичные. Т.е. операционка понятия не имеет, что там в эти регистры пишут и для чего, а лишь проверяет, чтобы запись была по регистрам из диапазона, указанного в манифесте.
Тебе еще сколько раз слово IOMMU повторить нужно?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>1. Это значит, что при наличии SYSTEM типобезопасностью в Обероне и не пахнет
M>2. Каким образом будет происходить этот запрет?
А никаким. Особенно учитывая то, что бутылка вообще не проверяет бинарники.
Те пропатчив бинарник можно загрузить любой код не сказав, что он от SYSTEM зависит.
Или еще круче. Просто сгенерировать какой угодно код. И делать что захочется.
Защиты то никакой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

V>>Будучи производителем какой-нить железки и драйвера под нее? Элементарно. Даже бери драйвер какого-нить проприетарного VPN с уникальным шифрованием безо всякой железки.
WH>Давай конкретно.
WH>Только про винду не надо. Не про нее разговор.

Дык, всё уже конкретнее некуда рассказал:
— драйвер некоего винта с закладкой;
— сетевой некий драйвер тоже с закладкой;

Если, как ты ниже написал, драйверам прямо открывать файлы можно запрещать, то нужно будет дополнительное юзвеское ПО, например, какой-нить бесплатный калькулятор с плюшками.

V>>Поэтому можно сделать комплекс из драйверов с закладками и юзерского ПО, "умеющего" с этими закладками работать. Впрочем, я уже об этом писал в этой подветке.
WH>Осталось выяснить, откуда же эти закладки возьмутся?

От злых намерений, вестимо.

V>>Я вообще плохо себе представляю тотальную проверку десятков миллионов строк кода. Сколько не проходили верификацию ПО... я бы сказал, что этот процесс весьма поверхностный.
WH>Да не надо десятки миллионов сертифицировать. Это тебе не винда.
WH>Тут хватит верификатор и пару драйверов проверить.
WH>Или можно даже свой верификатор написать. Для гарантии. И гонять оба.

Блин, это уже клиника... Верификатор НЕ проверяет логику, он проверяет корректность обращения к ресурсам. Это всё!!!
Драйвера с закладками относительно ресурсов ведут себя корректней некуда.

V>>В переведенном техническом репорте прямо говорится, что доступ к файловой системе из драйвера возможен по каналам.
WH>Если чуть изменить политику сервиса имен для драйверов, то невозможен.

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

V>>Т.е. можно заставить устройство записать байты не в ту память. А почему это нельзя проверить? Потому что набор регистров команд и их семантика у контроллеров DMA специфичные. Т.е. операционка понятия не имеет, что там в эти регистры пишут и для чего, а лишь проверяет, чтобы запись была по регистрам из диапазона, указанного в манифесте.
WH>Тебе еще сколько раз слово IOMMU повторить нужно?

Да сколько тебе угодно если ты не понимаешь, что это означает. Это обобщенный термин. (Опять термин

)

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

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

V>>Здесь вообще идет сплошной полет мысли. Небезынтересный, но лишь полет. Языки навроде Оберона берут исключительно из-за однозначности и детерминированности порождаемого бинарного кода. Т.е. всё намного-намного проще — Оберон берут из-за требований надежности.

M>Угу. Берется кастрированный примитивный язык, который один-в-один переводится в ассемблер. Вау. Это СИЛА!!!!

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

V>>Кроме функциональных типов все остальное перечисленное относится к среде исполнения. Или мне надо объяснять, при чем тут среда исполнения?
M>Ага. То есть к Оберону, как языку, оно не имеет никакого отношения вообще. Что и

Имеет. Среда исполнения нуждается в безопасном языке для реализации, так же в метаинформации. На самом языке написана среда исполнения программ на нем, какие проблемы?

M>>>Итак, дано. Ты утверждаешь, что между тем же Паскалем и Обероном разница лишь косметическая. Думаю, пора от тебя требовать определение «косметической разницф»
V>>Я думаю, что тебе пора бы уже вырасти и самому открыть спецификации, например, Компонентного Паскаля и Оберона-2. Второй раз на такую хрень я не поведусь. Уже и так все ссылки были даны.
M>Ну да ну да. Ты же у нас единственный, кто

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

V>>В процитированном отрывке об ОС ес-но.
M>Почему естественно, известно только тебе.

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

V>>Но такая ОС возможна лишь на заведомо безопасном языке, которым является, например, Оберон.
M>Среда, которая позволяет GC, асинхронные вызовы, динамическую загрузку кода, возможна только на Обероне? Бгггг. Erlang ржет-не-может.

Угу, опять динамический язык и интерпретатор привел. Надо мне на досуге порыться и найти старый самописный интерпретатор одного из известных динамических языков. Поржешь-не-можешь со смешного размера исходников. Я опять ХЗ, почему тебя тянет сравнивать тупые интерпретаторы с оптимизрующими компиляторами. Уже справшивал тебя, кстате.

V>>1. Из всех участников спора путаешься только ты.
V>>2. Ключевые св-ва ОС (повторюсь), требуют заведомо безопасного языка.

M>Нуну. Какие из «ключевых св-в» Оберон-ОСи требуют примитивного языка Оберон?

Да такие же, которые потребовали не менее примитивного Бартока для Сингулярити.

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

K>Идея о том, что Оберон способен заинтересовать значительное число из тех, кто не пишет сейчас на Модуле-2 — вообще смехотворна.

Где ты увидел эту идею?

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

K>Эксперименты с контролируемой мутабельностью — одна из основных целей языка.

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

Функциональный подход хорош при вычислении данных и плох, когда эти вычисленные данные надо куда-то девать.

ИМХО, наличие мутабельных механизмов диктует соображение практичной применимости языка.

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

V>>>Уже раз 100 писал — из злонамеренного ПО. Даже сертифицированного.
WH>>И откуда в сертифицированном ФСБ ПО закладки сделанные по заказу ЦРУ?
V>Я вообще плохо себе представляю тотальную проверку десятков миллионов строк кода. Сколько не проходили верификацию ПО... я бы сказал, что этот процесс весьма поверхностный.
Это всё из-за того, что Оберон разжижает моск. Нужно проверить небольшой объём кода, который будет затем гарантировать корректность работы остального кода.

Ой да, это оказывается уже сделали! Упс... См.: http://ertos.nicta.com.au/research/l4.verified/

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

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

V>Дык, всё уже конкретнее некуда рассказал:
V>- драйвер некоего винта с закладкой;
Откуда в драйвере винта закладка?

V>Если, как ты ниже написал, драйверам прямо открывать файлы можно запрещать, то нужно будет дополнительное юзвеское ПО, например, какой-нить бесплатный калькулятор с плюшками.
У которого прав будет еще меньше.

V>От злых намерений, вестимо.
Чьих? Ты думаешь мекрософту (или любому другому производителю ОС) оно надо чтобы их по судам затаскали?

V>Блин, это уже клиника... Верификатор НЕ проверяет логику, он проверяет корректность обращения к ресурсам. Это всё!!!
V>Драйвера с закладками относительно ресурсов ведут себя корректней некуда.
Только сделать ничего не могут. Ибо прав нет.

V>Может и можно... но даже банальное логгирование — крайне необходимая в сетевых операциях весчь... Скажем так, оставлять публичный сервак без логгирования опаснее, чем допускать мифическую закладку в сетевом драйвере. Всё не так просто, кароч...
Логирование на уровне драйвера сетевухи?

Да еще так чтобы сам драйвер файлики открывал?
И кто тут про SRP вещал?

V>Под каждую железную архитектуру шины по-прежнему нужен свой драйвер для приведения к общей абстракции. А сейчас, взвязи со всплеском embedded и прочего mobile, эти архитектуры размножаются как грибы в летний дождь. В итоге, те же яйца и опять в профиль.
Ты даже не понял почему авторы сингулярити это не осилили.
А не осилили они по тому, что им нужно не один драйвер на шину, а на каждую конкретную железку, которая в эту шину вставляется. Причем все эти железки работают по-разному.
При этом если бы IOMMU было, то можно было бы сделать очень простую обобщенную абстракцию.
И контролировать все остальные железки при помощи одного драйвера.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Дык, всё уже конкретнее некуда рассказал:
V>- драйвер некоего винта с закладкой;
V>- сетевой некий драйвер тоже с закладкой;
Пусть хоть в штаны закладываются. Пофиг. Всё что они могут делать — это менять данные, проходящие через них или шпионить за ними (в случае сетевого драйвера). Оба вопроса решаются шифрованием и контрольными суммами, которые будут считаться ядром ОС или доверенным железом.

V>Если, как ты ниже написал, драйверам прямо открывать файлы можно запрещать, то нужно будет дополнительное юзвеское ПО, например, какой-нить бесплатный калькулятор с плюшками.
И что оно будет делать?

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

В целом согласен, но есть несколько моментов.

ARK>>Справедливости ради нужно отметить: невозможно сделать хорошо защищенную систему исключительно программными средствами, и сингулярити тут не панацея.
WH>Программными средствами можно закрыть все дырки для молчаливого проникновения.

Да, вот для этого оно по сути и нужно.

ARK>>Ну будет у нас монструозный пакет типа MS Office или Photoshop, который затребует при установке разрешение на доступ ко всему (прямо или косвенно).
WH>Не затребует.
WH>И тому и другому нужно только локальное для приложение и пользователя хранилище и сервис открытия файлов который открывает системный диалог, в котором пользователь может выбрать файл.

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

ARK>>Кстати и не обязательно большой пакет — простой пользователь в общем случае вообще не представляет, какие права нужны той или иной программе. Ставит какой-нибудь CD-резак с вирусом, тот его просит — дай права на сервис чтения-записи диска, юзер дает. И все. В общем, потенциальная защищенность сингулярити сильно преувеличена.
WH>Если пользователя будут просить ввести админский пароль то он 10 раз подумает.
WH>А если не подумает, то тут ничего не поможет. От социальной инженерии ничего не спасет.

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

В сингулярити будет абсолютно то же самое. Обычный режим работы. До социальной инженерии тут далеко, ИМХО.

ARK>>Что тут делать — сложно сказать, наверное нужны комплексные меры.
WH>Пользователей воспитывать.
WH>Но и без программной защиты тоже не жизнь.

Ну да, воспитывать юзеров, создавать магазины-репозитории доверенного софта и прочая. ИМХО, это не менее, а то и более важно, чем программная защита.

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

V>>Я вообще плохо себе представляю тотальную проверку десятков миллионов строк кода. Сколько не проходили верификацию ПО... я бы сказал, что этот процесс весьма поверхностный.
C>Это всё из-за того, что Оберон разжижает моск.

Тебе виднее, я на нем не писал.

C>Нужно проверить небольшой объём кода, который будет затем гарантировать корректность работы остального кода.
C>Ой да, это оказывается уже сделали! Упс... См.: http://ertos.nicta.com.au/research/l4.verified/

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

1. Объем проверенного кода действительно крайне смешной.
2. Математическая модель кода — это и есть исходник. По определению. То бишь они переписали код на другом/других языках (Хаскель/Изабель) и сравнили оба варианта, вот что они сделали.
3. Никакой корректности работы остального кода никто не гарантировал.

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

C>И как же там сверхстабильный Оберон (мёртвое состояние — самое стабильное) до такого не додумался? Видимо из-за того, что Вирт считает, что функциональное программирование — это "программирование без процедур, а только с функциями".

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

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

V>>Дык, всё уже конкретнее некуда рассказал:
V>>- драйвер некоего винта с закладкой;
WH>Откуда в драйвере винта закладка?

Это единственное, что стоило обсуждать.
Откуда угодно.

V>>Если, как ты ниже написал, драйверам прямо открывать файлы можно запрещать, то нужно будет дополнительное юзвеское ПО, например, какой-нить бесплатный калькулятор с плюшками.
WH>У которого прав будет еще меньше.

Т.е. юзерское ПО даже не сможет открывать файлы и писать в сеть? И кто-то запретит исопльзовать "магические" имена для файлов?

V>>От злых намерений, вестимо.
WH>Чьих? Ты думаешь мекрософту (или любому другому производителю ОС) оно надо чтобы их по судам затаскали?

Дрова чаще всего пишет не MS, а производитель железки. У MS рук на всё не хватит.

V>>Блин, это уже клиника... Верификатор НЕ проверяет логику, он проверяет корректность обращения к ресурсам. Это всё!!!
V>>Драйвера с закладками относительно ресурсов ведут себя корректней некуда.
WH>Только сделать ничего не могут. Ибо прав нет.

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

V>>Может и можно... но даже банальное логгирование — крайне необходимая в сетевых операциях весчь... Скажем так, оставлять публичный сервак без логгирования опаснее, чем допускать мифическую закладку в сетевом драйвере. Всё не так просто, кароч...
WH>Логирование на уровне драйвера сетевухи?

Да еще так чтобы сам драйвер файлики открывал?

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

WH>И кто тут про SRP вещал?

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

V>>Под каждую железную архитектуру шины по-прежнему нужен свой драйвер для приведения к общей абстракции. А сейчас, взвязи со всплеском embedded и прочего mobile, эти архитектуры размножаются как грибы в летний дождь. В итоге, те же яйца и опять в профиль.
WH>Ты даже не понял почему авторы сингулярити это не осилили.
WH>А не осилили они по тому, что им нужно не один драйвер на шину, а на каждую конкретную железку, которая в эту шину вставляется. Причем все эти железки работают по-разному.
WH>При этом если бы IOMMU было, то можно было бы сделать очень простую обобщенную абстракцию.
WH>И контролировать все остальные железки при помощи одного драйвера.

Коллега, заканчивай уже размахивать вопиющей своей поверхностностью. IOMMU уже есть, хотя бы взять AMD HyperTransport, но в самом подходе IOMMU точно такая же проблема, как и во всём остальном ПО — стандартов IOMMU больше одного. Т.е., даже при наличии железной реализации IOMMU "все эти железки работают по-разному" (С). Поэтому твоя "обобщенная абстракция", увы, будет перемещена в драйвер конкретной спецификации IOMMU.

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

WH>>Не затребует.
WH>>И тому и другому нужно только локальное для приложение и пользователя хранилище и сервис открытия файлов который открывает системный диалог, в котором пользователь может выбрать файл.
ARK>Помимо хранилища документов могут потребоваться временные файлы
Я не про хранилище документов.
Персональную папку под временные файлы ваще ни разу не проблема предоставить.
Её можно даже заводить на каждый запущенный экземпляр приложения. И убивать по завершению.

ARK>или доступ в сеть для сохранения в облако.
Этим должно заниматься отдельное приложение.

ARK>И почему хранилище локальное для приложения и для пользователя?
По тому, что там будут храниться настройки.

ARK>Может документ нужен нескольким пользователям. Или может читаться-редактироваться несколькими приложениями.
Так я же говорил про сервис открытия файлов. Он для того и нужен чтобы пользователь мог открывать произвольные файлы при этом чтобы приложение не лезло куда попало.

ARK>Кстати, и системный диалог не всегда приемлем. Например, в компьютерных играх...
ARK>Не так все просто.
1)Натянуть скин не проблема.
2)Я что-то не помню таких игр, которым это надо. А сейвы можно и в локальном хранилище сохранять. Это хорошо само по себе, ибо сейчас все сохраняют, где попало. А так будет порядок.
Причем можно будет даже творить такие вещи: Нужно место на винте. Нажал на кнопочку и снес код и ресурсы игры. При этом сохранив сейвы и настройки. Через некоторое время захотел поиграть. Нажал на кнопочку, и оно само с интернета все, что нужно стянуло и стало, как было.

ARK>У меня на маке многие программы при установке просят ввести админский пароль.
А теперь представь, что начали просить не многие, а исчезающе малое количество.

ARK>В сингулярити будет абсолютно то же самое. Обычный режим работы. До социальной инженерии тут далеко, ИМХО.
Нет. Если только очень малое количество программ будут просить админский пароль. При этом будет написано, чем это может грозить.
Большинство народа 100 подумает надо ли им это. Тут уже придется включать социальную инженерию, чтобы пользователь пароль ввел.
А производители ПО будут всеми силами зарезать своим программам требования, чтобы инсталятор страшные вещи пользователям не говорил.
Ибо сейчас заниматься этим, у разработчиков вообще никакой мотивации нет.

ARK>Ну да, воспитывать юзеров, создавать магазины-репозитории доверенного софта и прочая. ИМХО, это не менее, а то и более важно, чем программная защита.
1)Без программной защиты это работать не будет.
2)Программы, которым много прав не надо можно ставить, откуда попало. Никаких проблем они создать не смогут. Даже если очень захотят.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Дык, всё уже конкретнее некуда рассказал:
V>>- драйвер некоего винта с закладкой;
V>>- сетевой некий драйвер тоже с закладкой;
C>Пусть хоть в штаны закладываются. Пофиг. Всё что они могут делать — это менять данные, проходящие через них или шпионить за ними (в случае сетевого драйвера). Оба вопроса решаются шифрованием и контрольными суммами, которые будут считаться ядром ОС или доверенным железом.

Слушай, а что сейчас, по-твоему, делают вирусы? Думаешь, по-прежнему делают "format C:" в черную пятницу?

И что такое "доверенное железо"?

V>>Если, как ты ниже написал, драйверам прямо открывать файлы можно запрещать, то нужно будет дополнительное юзвеское ПО, например, какой-нить бесплатный калькулятор с плюшками.
C>И что оно будет делать?

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

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

M>1. Это значит, что при наличии SYSTEM типобезопасностью в Обероне и не пахнет

Как и в Хаскеле из-за похожего модуля? Как и в OCaml из-за Obj?

M>2. Каким образом будет происходить этот запрет?

Да каким угодно. Система идет в исходниках, загрзчик там простейший. Усложни на свой вкус.

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

M>>1. Это значит, что при наличии SYSTEM типобезопасностью в Обероне и не пахнет
M>>2. Каким образом будет происходить этот запрет?
WH>А никаким. Особенно учитывая то, что бутылка вообще не проверяет бинарники.

Сингулярити тоже не проверяет бинарники ПОСЛЕ установки.

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

Гы, пропатчить можно целиком Сингулярити, не находишь?
Ты всерьез собрался обсуждать сценарии физического доступа к атакуемой машине? Это заведомое нубство. Если у тебя хватило воображения только на это, я подскажу самый простой сценарий — тупо украсть "атакуемый" винт с информацией.

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

WH>>Откуда в драйвере винта закладка?
V>Это единственное, что стоило обсуждать.
V>Откуда угодно.
Понятно. Есть и точка.
Может, еще начнёшь утверждать, что закладки в ядре ОС есть?
Тогда вообще что угодно доказать сможешь.

V>Коллега, заканчивай уже размахивать вопиющей своей поверхностностью. IOMMU уже есть, хотя бы взять AMD HyperTransport, но в самом подходе IOMMU точно такая же проблема, как и во всём остальном ПО — стандартов IOMMU больше одного. Т.е., даже при наличии железной реализации IOMMU "все эти железки работают по-разному" (С). Поэтому твоя "обобщенная абстракция", увы, будет перемещена в драйвер конкретной спецификации IOMMU.
Но модель IOMMU одна.
И сводится она к тому, что вот этой железке можно писать по таким адресам, а другой нет.
Это все что нам нужно знать в драйвере конкретной железки.
И все что должен предоставить драйвер конкретного IOMMU.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Поэтому, увы, питомец.
WH>Я понять не могу. Ты что на бан нарываешься?

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

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

ARK>Ну да, воспитывать юзеров, создавать магазины-репозитории доверенного софта и прочая. ИМХО, это не менее, а то и более важно, чем программная защита.

Именно. Эти меры закрывают бреши заведомо лучше любых строгих ОС.
Как пример — задалбывающие диалоги подтверждения любых чихов в Виста. Юзеры просто лезли в политику и отключали 90% таких проверок. В Win7 политики ослабили изкаробки, чтобы системой можно было хоть как-то пользоваться.

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

WH>>>Откуда в драйвере винта закладка?
V>>Это единственное, что стоило обсуждать.
V>>Откуда угодно.
WH>Понятно. Есть и точка.

Ну дык у вас же в RSDN-тиме безопасник появился, спроси как формулируются ситуации.

WH>Может, еще начнёшь утверждать, что закладки в ядре ОС есть?
WH>Тогда вообще что угодно доказать сможешь.

Да. И могу и делал многократно в разные годы. Я же с самого начала определил координаты — проблема существует принципиально до тех пор, пока существуют независимые вендоры ПО, в т.ч. драйверов. Повторил это не раз, но ты изо всех сил пытаешься игнорить. Самое время гоу ту начало: http://www.rsdn.ru/forum/philosophy/4822413.1.aspx

Скажем так, "закладки" можно вставлять не только в ПО, но вообще в инфраструктуру... А малюсенькая закладка в ПО может быть лишь частью инфраструктуры закладки. Есть опыт вставки закладок даже в банальную клаву от компа. Про что-то более серьезное даже говорить тут не стану — в личку при наличии любопытства.

WH>И сводится она к тому, что вот этой железке можно писать по таким адресам, а другой нет.
WH>Это все что нам нужно знать в драйвере конкретной железки.
WH>И все что должен предоставить драйвер конкретного IOMMU.

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

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

M>>1. Это значит, что при наличии SYSTEM типобезопасностью в Обероне и не пахнет
V>Как и в Хаскеле из-за похожего модуля? Как и в OCaml из-за Obj?

Стоп-стоп. Ты тут кричишь, что в Обероне мегасуперкрутая типобезопасность, которая всем и не снилась. Оказалось, что типобезопасность Оберон не гарантирует.

M>>2. Каким образом будет происходить этот запрет?
V>Да каким угодно. Система идет в исходниках, загрзчик там простейший. Усложни на свой вкус.

То есть запрета не существует.

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

V>Сингулярити тоже не проверяет бинарники ПОСЛЕ установки.
А бутылка не проверяет ваще.

V>Ты всерьез собрался обсуждать сценарии физического доступа к атакуемой машине? Это заведомое нубство. Если у тебя хватило воображения только на это, я подскажу самый простой сценарий — тупо украсть "атакуемый" винт с информацией.

Ты, похоже, уже сам с собой разговариваешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Да как бы не первый год тут встречаемся, ты должен был уже усвоить простое правило — держи свои эпитеты при себе, и оппонент будет держать при себе свои.
Ты ващето первым меня в деградации начал обвинять.
Вот только это не деградация, а прогресс. Причем такой, что ты не можешь понять, о чем я вообще говорю.
Раньше ты меня понимал только по тому, что я говорил о тривиальных вещах. Типа реализации физических размерностей на шаблонах С++.
Сейчас говорю о сложных.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ARK>>или доступ в сеть для сохранения в облако.
WH>Этим должно заниматься отдельное приложение.

А какая разница? Ну будет доступ в сеть через это "отдельное приложение". Главное, что будет возможность слить данные в сеть.

ARK>>И почему хранилище локальное для приложения и для пользователя?
WH>По тому, что там будут храниться настройки.

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

ARK>>Может документ нужен нескольким пользователям. Или может читаться-редактироваться несколькими приложениями.
WH>Так я же говорил про сервис открытия файлов. Он для того и нужен чтобы пользователь мог открывать произвольные файлы при этом чтобы приложение не лезло куда попало.

ОК, обращаемся к общим файлам через "сервис открытия файлов" и похабим там все. Не напрямую, а через сервис — особой разницы не вижу.

ARK>>Кстати, и системный диалог не всегда приемлем. Например, в компьютерных играх...
ARK>>Не так все просто.
WH>1)Натянуть скин не проблема.

Скин не всегда приемлем.

WH>2)Я что-то не помню таких игр, которым это надо.

Эээ... по-моему, сложнее вспомнить игры, которым это не надо. Вот недавно поставил в Wine честно приобретенный Baldur's Gate — институт сохранений на месте.

Причем без системных диалогов.

WH>А сейвы можно и в локальном хранилище сохранять. Это хорошо само по себе, ибо сейчас все сохраняют, где попало. А так будет порядок.
WH>Причем можно будет даже творить такие вещи: Нужно место на винте. Нажал на кнопочку и снес код и ресурсы игры. При этом сохранив сейвы и настройки. Через некоторое время захотел поиграть. Нажал на кнопочку, и оно само с интернета все, что нужно стянуло и стало, как было.

Это да, полезно.

ARK>>У меня на маке многие программы при установке просят ввести админский пароль.
WH>А теперь представь, что начали просить не многие, а исчезающе малое количество.

С чего бы вдруг исчезающе малое? Как минимум — каждая прога начнет требовать доступ к репозиториям со своими файлами. Офису документы, просмотрщику картинки, видеоредактору — соответственно видео... И не факт, что в этих прогах не будет зловредного кода, который сможет испортить данные или передать их в сеть через то самое "отдельное приложение".

ARK>>В сингулярити будет абсолютно то же самое. Обычный режим работы. До социальной инженерии тут далеко, ИМХО.
WH>Нет. Если только очень малое количество программ будут просить админский пароль. При этом будет написано, чем это может грозить.

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

ARK>>Ну да, воспитывать юзеров, создавать магазины-репозитории доверенного софта и прочая. ИМХО, это не менее, а то и более важно, чем программная защита.
WH>1)Без программной защиты это работать не будет.

Ну вон AppStore на iPhone работает как-то. Весьма неплохо, все довольны, эпидемий вирусов пока нет.

WH>2)Программы, которым много прав не надо можно ставить, откуда попало. Никаких проблем они создать не смогут. Даже если очень захотят.

Тут согласен.

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

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

ARK>>Ну да, воспитывать юзеров, создавать магазины-репозитории доверенного софта и прочая. ИМХО, это не менее, а то и более важно, чем программная защита.

V>Именно. Эти меры закрывают бреши заведомо лучше любых строгих ОС.
V>Как пример — задалбывающие диалоги подтверждения любых чихов в Виста. Юзеры просто лезли в политику и отключали 90% таких проверок. В Win7 политики ослабили изкаробки, чтобы системой можно было хоть как-то пользоваться.

Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

V>>>Здесь вообще идет сплошной полет мысли. Небезынтересный, но лишь полет. Языки навроде Оберона берут исключительно из-за однозначности и детерминированности порождаемого бинарного кода. Т.е. всё намного-намного проще — Оберон берут из-за требований надежности.

M>>Угу. Берется кастрированный примитивный язык, который один-в-один переводится в ассемблер. Вау. Это СИЛА!!!!

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

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

V>>>Я думаю, что тебе пора бы уже вырасти и самому открыть спецификации, например, Компонентного Паскаля и Оберона-2. Второй раз на такую хрень я не поведусь. Уже и так все ссылки были даны.
M>>Ну да ну да. Ты же у нас единственный, кто

Ну ты у нас рассказываешь сказки про крутейший Оберон, в котором есть ООП, GC, активные объекты и т.п. А на проверку оказывается, что не в языке (который оказывается туп и примитивен), а в некой VM, которая по совместительству носит то же имя.

V>>>В процитированном отрывке об ОС ес-но.
M>>Почему естественно, известно только тебе.

V>Наверно потому, что уже десяток постов обсуждается именно язык для контроллеров, а не операционка для них же.

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

V>>>Но такая ОС возможна лишь на заведомо безопасном языке, которым является, например, Оберон.
M>>Среда, которая позволяет GC, асинхронные вызовы, динамическую загрузку кода, возможна только на Обероне? Бгггг. Erlang ржет-не-может.

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

Стоп-стоп-стоп. А какой, по-твоему, Оберон в BlueBottle? Напомню: ты утверждаешь, что GC, синхронизация объектов и прочие плюшки реализуются не языком, а средой:

M>Так о чем ты тут говорил? Об Обероне? Об ОСях, написанных на Обероне? О каких-то конкретных версиях Оберона? Или обо всем сразу?

В процитированном отрывке об ОС ес-но.

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

Одно или оба из этих двух утверждений являются ложью.

Если Оберон компилируемый, то в нем не будет ни GC, ни активных объектов — ни-че-го, потому что ты утверждаешь, что эти фишки — прерогатива VM.
Если эти фишки — прерогатива VM, то Оберон не компилируемый, ну или компилируемый в некоторое внутреннее представление этой самой VM (что и происходит — модули хранятся в некоем внутреннем двоичном представлении). Но для получения плюшек такой VM (GC, асинхронные сообщения и т.п.) Оберон и не нужен, что прекрасно видно на примере Erlang'а.

V>>>1. Из всех участников спора путаешься только ты.
V>>>2. Ключевые св-ва ОС (повторюсь), требуют заведомо безопасного языка.

M>>Нуну. Какие из «ключевых св-в» Оберон-ОСи требуют примитивного языка Оберон?

V>Да такие же, которые потребовали не менее примитивного Бартока для Сингулярити.

По пунктам, пожалуйста.

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

V>Да. И могу и делал многократно в разные годы. Я же с самого начала определил координаты — проблема существует принципиально до тех пор, пока существуют независимые вендоры ПО, в т.ч. драйверов. Повторил это не раз, но ты изо всех сил пытаешься игнорить. Самое время гоу ту начало: http://www.rsdn.ru/forum/philosophy/4822413.1.aspx
Да не существует.
Проверять на закладки нужно исчезающе маленькое количество софта.
Остальной ничего сделать не сможет.

V>Скажем так, "закладки" можно вставлять не только в ПО, но вообще в инфраструктуру...
Как?

V>А малюсенькая закладка в ПО может быть лишь частью инфраструктуры закладки. Есть опыт вставки закладок даже в банальную клаву от компа. Про что-то более серьезное даже говорить тут не стану — в личку при наличии любопытства.
Ох. И как это относится к скаченному из инета коду?
Ты точно сам с собой разговариваешь.

V>Ну хорошо, хоть ты согласился, что само IOMMU требует драйвера, а не сидит в микро-ядре исходников ОСи.
В микроядре заложена модель IOMMU. И верификатор драйверов о ней осведомлен.

V>Ну а раз требует драйвера, то гоу ту на показанную ссылку и всё с начала.
Ну да. К сертификации драйвера винта добавилась еще сертификация драйвера IOMMU.
Объем работ остался практически таким же.

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

V>В общем, в моей позиции ты, наконец, разобрался.
Ты точно сам с собой разговариваешь.

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

V>а натягивать Сингулярити на вирусную безопасность — это обсуждать устаревшее положение дел.
В каком месте?

V>Заметь, сами авторы этой попытки не делали, а отличие от тебя.
И чем же они занимались?

V>Давным давно вирусы не садятся на комп через переполнение стека или ошибки адресации.
Вот это новости.

V>Они садятся исключительно из-за неверных политик распространения привилегий и действий пользователя.
Ну да. Пользователь запустил софтину. Которая из-за переполнения начала исполнять код внутри jpeg'а.
После чего все пропало.

V>А этот фактор применим абсолютно к любым ОС, в т.ч. к Сингулярити.
Не применим.

V>Снгулярити хороша в плане предварительных выявлений конфликтов в ПО, вот тут она на высоте, это да... Т.е. это тот раздел безопасности, который касается работоспособности системы и ничего более.
Ты так и не сказал, как атаковать сингулярити.
Все что мог придумать это закладку в паре драйверов, которые отвечают за жизнеспособность системы. Но пару драйверов не проблема сертифицировать. Причем если их одновременно сертифицирует и ФСБ и ЦРУ, я буду на 120% процентов уверен, что закладок там нет.
Но ни одной атаки на уровне обычных приложений не продемонстрировал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Да как бы не первый год тут встречаемся, ты должен был уже усвоить простое правило — держи свои эпитеты при себе, и оппонент будет держать при себе свои.
WH>Ты ващето первым меня в деградации начал обвинять.
WH>Вот только это не деградация, а прогресс. Причем такой, что ты не можешь понять, о чем я вообще говорю.

Деградация подхода к общению налицо. Даже здесь и сейчас.

Почитай себя со стороны.

WH>Раньше ты меня понимал только по тому, что я говорил о тривиальных вещах. Типа реализации физических размерностей на шаблонах С++.
WH>Сейчас говорю о сложных.

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

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

ARK>А какая разница? Ну будет доступ в сеть через это "отдельное приложение". Главное, что будет возможность слить данные в сеть.
В тихую не будет.

ARK>ОК, обращаемся к общим файлам через "сервис открытия файлов" и похабим там все. Не напрямую, а через сервис — особой разницы не вижу.
Так этот сервис без диалога файлик не откроет.

ARK>Эээ... по-моему, сложнее вспомнить игры, которым это не надо. Вот недавно поставил в Wine честно приобретенный Baldur's Gate — институт сохранений на месте.

Причем без системных диалогов.
Ну, так и пусть сохраняет в приватном хранилище.
Этого достаточно в 100% случаев.

ARK>С чего бы вдруг исчезающе малое? Как минимум — каждая прога начнет требовать доступ к репозиториям со своими файлами.
Это право программе будет предоставляться молча.
Ибо оно безопасно.
Так же как персональная папка для временных файлов, доступ к OpenFileDialog и много чему еще.

ARK>Офису документы, просмотрщику картинки, видеоредактору — соответственно видео...
OpenFileDialog

ARK>И не факт, что в этих прогах не будет зловредного кода, который сможет испортить данные или передать их в сеть через то самое "отдельное приложение".
Молча не сможет.

ARK>Ну вон AppStore на iPhone работает как-то. Весьма неплохо, все довольны, эпидемий вирусов пока нет.

Пока просто не выгодно под него вирусы писать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Стоп-стоп. Ты тут кричишь, что в Обероне мегасуперкрутая типобезопасность, которая всем и не снилась. Оказалось, что типобезопасность Оберон не гарантирует.

Гарантирует не хуже Хаскеля. Такой уровень гарантий тебя устроит? Или в природе существуют гарантии еще выше?

M>>>2. Каким образом будет происходить этот запрет?
V>>Да каким угодно. Система идет в исходниках, загрзчик там простейший. Усложни на свой вкус.

M>То есть запрета не существует.

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

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

ARK>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

Угу, осталась сущая ерунда — переписать весь существующий код на верифицируемых языках. При этом сами компиляторы таких языков сделать именными на каждого разработчика, и сделать так, чтобы компиляторы ВСЕГДА подписывали код при компиляции, используя ту самую именную сигнатуру. )))

Ну реально, при всей кажущейся утопичности, другого выхода нет. Знаешь, как в продуктах питания вкладыш: "Упаковано такого-то числа, упаковщик Вася Такой-то". Просто производство IT-продукта всё еще находится в зачаточном состоянии.

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

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

WH>В тихую не будет.
WH>Молча не сможет.

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

WH>Это право программе будет предоставляться молча.
WH>Ибо оно безопасно.
WH>Так же как персональная папка для временных файлов, доступ к OpenFileDialog и много чему еще.

Речь про редактирование/сохранение файлов. Оно совсем не безопасно.

ARK>>ОК, обращаемся к общим файлам через "сервис открытия файлов" и похабим там все. Не напрямую, а через сервис — особой разницы не вижу.
WH>Так этот сервис без диалога файлик не откроет.
WH>OpenFileDialog

Тут речь не про открытие, а про сохранение. Тогда уж SaveFileDialog. Но опять же не круто как-то. Работаю я в ворде и постоянно тыркаю Ctrl+S. И что, каждый раз будет вылезать SaveFileDialog? Не вариант, ИМХО.
Вердикт — вредоносное ПО, которому мы лично дали права на репозиторий с документами (а иначе работать как?), вполне в состоянии эти документы попортить, причем втихую.

ARK>>Ну вон AppStore на iPhone работает как-то. Весьма неплохо, все довольны, эпидемий вирусов пока нет.

WH>Пока просто не выгодно под него вирусы писать.

Фиг знает. Рынок вроде большой — самый большой на мобилах. Почему не выгодно — непонятно.

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

V>Угу, осталась сущая ерунда — переписать весь существующий код на верифицируемых языках.

Ну почему, можно еще написать компиляторы в верифицируемый байткод и перекомпилировать все ПО. В теории. На практике С++ настолько монструозен и низкоуровнев, что проще действительно переписать.

Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?

V>При этом сами компиляторы таких языков сделать именными на каждого разработчика, и сделать так, чтобы компиляторы ВСЕГДА подписывали код при компиляции, используя ту самую именную сигнатуру. )))

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

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

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

WH>>Так же как персональная папка для временных файлов, доступ к OpenFileDialog и много чему еще.
ARK>Речь про редактирование/сохранение файлов. Оно совсем не безопасно.
Ну так оно и будет происходить через OpenFileDialog.
OpenFileDialog будет возвращать не строку как сейчас, а файл.
И уже с файлом можно будет работать.
Другой файл (без запуска OpenFileDialog) программа открыть не сможет.

ARK>Тут речь не про открытие, а про сохранение. Тогда уж SaveFileDialog. Но опять же не круто как-то. Работаю я в ворде и постоянно тыркаю Ctrl+S. И что, каждый раз будет вылезать SaveFileDialog? Не вариант, ИМХО.
Ну, так один раз открыл файл и вперед.
В чем проблема то?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ARK>>Наверное все же такие права будут даваться при установке программы. Но тогда и фотошоп сможет тихо "слить" данные, если ему такие права дали.
WH>Не сможет.
WH>Просто по тому, что для этого ему придется запустить программу и сказать ей какие файлы отправлять.
WH>И никто ему это не разрешит.

А как будет работать скайп? Он никаких файлов не передает, идет поток байт.

WH>Ну так оно и будет происходить через OpenFileDialog.
WH>OpenFileDialog будет возвращать не строку как сейчас, а файл.
WH>И уже с файлом можно будет работать.
WH>Другой файл (без запуска OpenFileDialog) программа открыть не сможет.

WH>Ну, так один раз открыл файл и вперед.
WH>В чем проблема то?

Ну хорошо. Хотя я пока не уверен, что все можно уместить в этот сценарий.

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

ARK>Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?
Как?

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

Простым и дубовым должно быть промежуточное представление.
Ибо верифицируют его.
Язык и компилятор могут быть сколь угодно сложными.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

V> Это залет. Ты показывал, что не умел самостоятельно разобраться в сути происходящего, а цеплялся за внешнюю форму, АПИ, термины и т.д.
Залет это:
Слаботипизаронный OCaml.
GLR быстрый парсер.
Равноправный альфаканал.
Мониторы с глобальной кучей то же самое, что посылка сообщений между изолированными процессами.
И еще много чего что я так сразу не вспомню.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ARK>А как будет работать скайп? Он никаких файлов не передает, идет поток байт.
Получит разрешение работать с сетью и все.
Ничего слить не сможет.
Ибо доступа к файлам без OpenFileDialog не получит.

ARK>Ну хорошо. Хотя я пока не уверен, что все можно уместить в этот сценарий.
Максимум что понадобится это OpenDirectoryDialog.
Для программ, которые работают с кучей фалов в директории.
Но таких не много.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ARK>>А как будет работать скайп? Он никаких файлов не передает, идет поток байт.
WH>Получит разрешение работать с сетью и все.
WH>Ничего слить не сможет.
WH>Ибо доступа к файлам без OpenFileDialog не получит.

Минутку. Стало быть, в API будет такой сервис, который предоставляет возможность слать поток байт в сеть.
Наш вредоносный редактор документов открывает файл через OpenFileDialog (точнее пользователь открывает для работы) и шлет все его байты в сеть. Ну, дали мы редактору при установке такое право, он попросил. Такой сценарий возможен?

ARK>>Ну хорошо. Хотя я пока не уверен, что все можно уместить в этот сценарий.
WH>Максимум что понадобится это OpenDirectoryDialog.
WH>Для программ, которые работают с кучей фалов в директории.
WH>Но таких не много.

Максимум ли... Архиватор как будет работать? На вход один файл, на выходе — 100 других.

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

ARK>Минутку. Стало быть, в API будет такой сервис, который предоставляет возможность слать поток байт в сеть.
А как без него?

ARK>Наш вредоносный редактор документов открывает файл через OpenFileDialog (точнее пользователь открывает для работы) и шлет все его байты в сеть. Ну, дали мы редактору при установке такое право, он попросил. Такой сценарий возможен?
Такой возможен.
Но не реалистичен.
Ибо, зачем ему доступ в сеть?
Такой редактор первый же корпоративный админ завернет.
А учитывая, что корпорации это основной рынок для всяких там офисов то...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>А малюсенькая закладка в ПО может быть лишь частью инфраструктуры закладки. Есть опыт вставки закладок даже в банальную клаву от компа. Про что-то более серьезное даже говорить тут не стану — в личку при наличии любопытства.
WH>Ох. И как это относится к скаченному из инета коду?

Так же точно, как автообновление софта.

V>>Ну хорошо, хоть ты согласился, что само IOMMU требует драйвера, а не сидит в микро-ядре исходников ОСи.
WH>В микроядре заложена модель IOMMU. И верификатор драйверов о ней осведомлен.

V>>Ну а раз требует драйвера, то гоу ту на показанную ссылку и всё с начала.
WH>Ну да. К сертификации драйвера винта добавилась еще сертификация драйвера IOMMU.

Вот так, шаг за шагом приходится вести тебя к пониманию положения дел. А ведь казалось бы — интернет большой, всё написано.

WH>Объем работ остался практически таким же.

Но заставить тебя отказаться от спекулирований на "больше-меньше" я не могу, к сожалению.

WH>Сертификацию пары драйверов и ядра все переживут.
WH>То что предлагаешь ты абсолютно не реально.

Да какие пару? Сколько платформ, столько драйверов. А каждый год появляются всё новые и новые платформы и всё новые и новые железки.

V>>В общем, в моей позиции ты, наконец, разобрался.
WH>Ты точно сам с собой разговариваешь.

Дык, игнор вопросов по-существу я принимаю за согласие. Если нет — велкам ответить по-существу хотя бы насчет комбинированного интерфейса HDMI.

V>>Мне добавить нечего, бо остальное — неинтересные подробности. Просто хотел обратить твоё внимание, что про абсолютную безопасность говорить смешно,
WH>Это я хотел обратить твое внимаение на то что в сингулярити безопасность можно обеспечить проверив очень маленькое колличество кода.
WH>При этом в бутылке ее не обеспечить никак.

Бутылка — это вообще мини-ОС, считай, что интересно там только ядро АОС. А ограничения на установку приложений и прочее — это довольно высокоуровневые плюшки, никто не мешает эти плюшки добавить сверху. Просто ты игноришь аргументы по-существу. Нахрена, например, встраиваемой АОС озаботиться проблемами вирусов, если в бинарном образе нет физической возможности закачать и запустить произвольный файл? Или спутники связи в свободное от работы время смотрят ролики по ю-туб? В общем, сверху на бутылку натяни ограничения по закачке и установке софта, проверь только этот код и будет тебе счастье. ИМХО, цель Оберон ОС и его расширения (АОС) была несколько в ином, дать ИНСТРУМЕНТ для разработки максимально эффективного софта с высокой надежностью, работающего напрямую с железом. На момент разработки ОберонОС и спец-железа для него просто не было равных как по скорости, надежности, так и по требуемой памяти. Бутылка — это просто попытка натянуть графический рабочий стол на АОС и не более того. Просто современные ОСи, даже встаиваемые (я уже молчу про серверные и десктопные), крайне неэффективные и еще больше ненадежные. Поэтому Оберон-ОС и АОС несомненно были для своего времени интересны.

V>>Давным давно вирусы не садятся на комп через переполнение стека или ошибки адресации.
WH>Вот это новости.

Ну да, таких дыр в самой популярной операционке изчезающе мало, в основном из легаси-кода. Вряд ли есть в новом коде, т.к. в компиляторе от MS стоят все эти проверки по опасному АПИ CRT.

V>>Они садятся исключительно из-за неверных политик распространения привилегий и действий пользователя.
WH>Ну да. Пользователь запустил софтину. Которая из-за переполнения начала исполнять код внутри jpeg'а.
WH>После чего все пропало.

Боюсь, сегодня у тебя не получится привести ссылку на работающий пример под Win7.

V>>Снгулярити хороша в плане предварительных выявлений конфликтов в ПО, вот тут она на высоте, это да... Т.е. это тот раздел безопасности, который касается работоспособности системы и ничего более.
WH>Ты так и не сказал, как атаковать сингулярити.
WH>Все что мог придумать это закладку в паре драйверов, которые отвечают за жизнеспособность системы. Но пару драйверов не проблема сертифицировать. Причем если их одновременно сертифицирует и ФСБ и ЦРУ, я буду на 120% процентов уверен, что закладок там нет.

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

WH>Но ни одной атаки на уровне обычных приложений не продемонстрировал.

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

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

V>>Да не говоришь ты ничего. Минимум дважды за последнее время ты начинал общение с того, что называл окружающих нубами, а когда из тебя клещами таки вытягивали подробности, то выяснялось, что ты говорил фактически об одном и том же, вид в профиль.
WH>Не надоело о себе во множественном числе говорить?

Нет, в теме про GC было больше двух участников.

V>> Это залет. Ты показывал, что не умел самостоятельно разобраться в сути происходящего, а цеплялся за внешнюю форму, АПИ, термины и т.д.
WH>Залет это:
WH>Слаботипизаронный OCaml.

Это не ко мне, это в ответ на подобного рода неоднократные заявления: http://www.rsdn.ru/forum/philosophy/4823144.1.aspx
Абсолютно тоже самое в OCaml.
Правда в ИДЕ под Оберон этот SYSTEM хоть специально подсвечивается, а где такое же для модуля Obj в OCaml или unchecked (или как его там) в Haskell?

WH>GLR быстрый парсер.

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

WH>Равноправный альфаканал.

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

(И да, словосочетание "равноправный альфаканал" в области обработки изображений звучит как "бердовый бред". Кому и как он равноправен? Соседним битам в кодировке? )

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

Это не тоже самое, ес-но. Это местами эффективней, местами нет. Как раз по работе довожу эффективность различных способов передачи данных/сигналов м/у потоками. В каких-то сценариях рулят lock-free буфера (аналоги твоих каналов), а в каких-то всех заруливает обыкновенный shared доступ с короткими блокировками. Думать, что есть единое лекарство на все случаи — это ммм... как минимум непрофессионально, если не сказать покрепче.

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

WH>И еще много чего что я так сразу не вспомню.

Дык, меньше бы линял, меньше бы надо было запоминать незакрытых тем.

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

ARK>>Речь про редактирование/сохранение файлов. Оно совсем не безопасно.
WH>Ну так оно и будет происходить через OpenFileDialog.
WH>OpenFileDialog будет возвращать не строку как сейчас, а файл.

Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?

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

ARK>Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?

Дык, я же уже сказал что делать — личная ответственность. )))
Аналогично как с продуктами, чтобы народ не потравить бактериями и вирусами — через карательные меры. Только так.

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

Это не спасет от злонамерений.

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

M>Стоп-стоп-стоп. А какой, по-твоему, Оберон в BlueBottle? Напомню: ты утверждаешь, что GC, синхронизация объектов и прочие плюшки реализуются не языком, а средой:

Да.

M>То есть Bluebottle банально является VM для некоего языка Оберон.

Нет, это десктоп над AOS. А сама AOS — среда исполнения программ на АО. Соответственно просто ОберонОС — это среда исполнения ропграмм на просто Обероне. BlackBox — это среда исполнения программ на Компонентном Паскале, который есть тоже Оберон на самом деле. Который есть развитие Модулы, которая есть развитие первоначального Паскаля. Вот такой винигрет. Запутаться можно, согласен, но это же не повод для поливания г-ном, не?

M>Ты тут начинаешь рассказывать сказки про компилируемость этого языка,

Это не сказки, это так и есть.

M>про то, что для создания этой VM нужен только и исключительно Оберон и т.п.

Это уже ты придумал. Я наоборот высказывался, что было бы неплохо прилепить к Оберону языки-близнецы в Си-подобном и ML-подобном синтаксисе, совместимые по формату модулей, типа как VB.Net и C#. Это могло бы драмматически именить ситуацию вокруг популярности Оберон как среды исполнения.

M>Одно или оба из этих двух утверждений являются ложью.

Ничего не является ложью. Компиллируемость в байт-код НЕ является чем-то обязательным. Есть Обероны с байт-кодом (для изоляции от аппаратной платформы), а есть без промежуточного байт-кода. Ничего принципиально не меняется. Модули в любом случае хранят одну и ту же метаинформацию, которая для Оберона крайне компактна и быстро парсится, в отличие от метаинформации дотнета. Да, где используется байт-код, там работает JIT-загрузка этого байт-кода. Причем, эта загрузка работает по-требованию, причем, это работает с 80-х годов. Второй раз один-в-один мы увидели всё тоже самое в дотнете от второго после Вирта всемирно известного турбо-дельфи-паскалиста. Но дотнет у тебя, судя по другим постам, таких возражений не вызывает.

M>Если Оберон компилируемый, то в нем не будет ни GC, ни активных объектов — ни-че-го, потому что ты утверждаешь, что эти фишки — прерогатива VM.

Среда исполнения — это не обязательно VM. Это метаинформация + механизм по ее обслуживанию. А будет ли эта метаинформация о виртуальном байт-коде или реальном для конкретной железки — не принципиально. Похоже, в этом месте у тебя сидит глобальное непонимание работы того же дотнета. У него унутре сосуществуют две метаинформации: одна исходная из объектного файла, вторая — реальное расположение данных и кода после JIT.

M>Если эти фишки — прерогатива VM, то Оберон не компилируемый, ну или компилируемый в некоторое внутреннее представление этой самой VM (что и происходит — модули хранятся в некоем внутреннем двоичном представлении). Но для получения плюшек такой VM (GC, асинхронные сообщения и т.п.) Оберон и не нужен, что прекрасно видно на примере Erlang'а.

Нет никакой VM даже в байт-кодном Обероне. Есть загрузчик, который работает со скоростью обычного загрузчика ОС (!!!), переводя виртуальные байт-коды в реальные железные. Нет никакой рантайм-интерпретации, нет никакой динамики. Только статика.

V>>Да такие же, которые потребовали не менее примитивного Бартока для Сингулярити.
M>По пунктам, пожалуйста.

Т.е. возражений насчет такого же примитивного Бартока нет? ЧТД.
А пункты приводил минимум дважды рядом, поищи.

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

V>>>А малюсенькая закладка в ПО может быть лишь частью инфраструктуры закладки. Есть опыт вставки закладок даже в банальную клаву от компа. Про что-то более серьезное даже говорить тут не стану — в личку при наличии любопытства.
WH>>Ох. И как это относится к скаченному из инета коду?
V>Так же точно, как автообновление софта.
Хватит сам с собой разговаривать.
Как относятся закладки в железе к скаченной из инета игрушки?

V>Вот так, шаг за шагом приходится вести тебя к пониманию положения дел. А ведь казалось бы — интернет большой, всё написано.
Какое положение дел?
Всего _два_ драйвера насчитали.

WH>>Сертификацию пары драйверов и ядра все переживут.
WH>>То что предлагаешь ты абсолютно не реально.
V>Да какие пару? Сколько платформ, столько драйверов. А каждый год появляются всё новые и новые платформы и всё новые и новые железки.
Ты говоришь, так как будто платформ много.
Да по сравнению со всем остальным софтом ты их никогда в микроскоп не увидишь.
Да даже на фоне периферии не заметишь.

V>Дык, игнор вопросов по-существу я принимаю за согласие. Если нет — велкам ответить по-существу хотя бы насчет комбинированного интерфейса HDMI.
Я ответил. Но ты не понял.

V>Бутылка — это вообще мини-ОС, считай, что интересно там только ядро АОС бла-бла-бла
Ты тут пытаешься утверждать, что в бутылке с безопасностью не хуже чем в сингулярити.

V>Ну да, таких дыр в самой популярной операционке изчезающе мало, в основном из легаси-кода. Вряд ли есть в новом коде, т.к. в компиляторе от MS стоят все эти проверки по опасному АПИ CRT.
Есть еще куча прикладного софта.

V>Боюсь, сегодня у тебя не получится привести ссылку на работающий пример под Win7.
Я за этим не слежу. Но уверен мыщъх много покажет.

V>Еще раз, драйверов всего мильон, а не пару. Пару критичных только на конкретной железке, а самих железок тонна. Атаковать надо через ср-ва загрузки и запуска программ.
Миллион реализаций IOMMU?
Ты точно ничего не путаешь?

V>Ты еще попроси через JS атаковать. И да, обычное приложение может являться частью инфраструктуры. И вообще, любая атака — это комплексное мероприятие.
Тот же мыщъх показывал и атаки через JS с переполнением буфера интерпретатора.
И через JVM.
А все по тому что нехрен такие вещи на С писать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
Не помню. Но модель сингулярити как раз на такой сценарий и заточена.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Это не ко мне, это в ответ на подобного рода неоднократные заявления: http://www.rsdn.ru/forum/philosophy/4823144.1.aspx
V>Абсолютно тоже самое в OCaml.
V>Правда в ИДЕ под Оберон этот SYSTEM хоть специально подсвечивается, а где такое же для модуля Obj в OCaml или unchecked (или как его там) в Haskell?
Ты опять сам с собой разговаривашь.

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

V>Докажи обратное. Сценарии, где он предпочтительнее всех, я уже давал неоднократно, но ты не соизволил их проанализировать. К тому же, парсер оперативный, без откатов, поэтому на своих сценариях
Не давал.
Ни одного.
Только с умным видом говорил, что они есть.

V>он крайне популярен. В комфортных для себя сценариях работает со скоростью лексера, только даже еще быстрее в несколько раз (в переводе на мегабайты исходного текста). Почему так — предлагаю догадаться самому.
В комфортных это на LR(0) грамматике?

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

V>Я видеотехнике и обработке изображений посвятил достаточно лет, мне эти темы преобазований/калибровки цветовых пространств интересны.
Не заметно.

V>Это не тоже самое, ес-но. Это местами эффективней, местами нет. Как раз по работе довожу эффективность различных способов передачи данных/сигналов м/у потоками. В каких-то сценариях рулят lock-free буфера (аналоги твоих каналов), а в каких-то всех заруливает обыкновенный shared доступ с короткими блокировками. Думать, что есть единое лекарство на все случаи — это ммм... как минимум непрофессионально, если не сказать покрепче.
Ты опять сам с собой разговариваешь.
Ты тут толкал мысль о том, что сингулярити и бутылка одинаковые.

V>И да, показательно, что как только я попытался тебя сосредоточить на том, что как создаются сами каналы (не из глобальной ли кучи?), ты продемонстрировал игнор. Собсно, как и всегда, когда доходим до конкретики — тебя сразу нет.
Не из глобальной.
Дальше что придумывать будешь?

WH>>И еще много чего что я так сразу не вспомню.
V>Дык, меньше бы линял, меньше бы надо было запоминать незакрытых тем.
Я не линял. Просто надоедало говорить с человеком, который говорит сам с собой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
WH>Не помню. Но модель сингулярити как раз на такой сценарий и заточена.

Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?

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

WH>Как относятся закладки в железе к скаченной из инета игрушки?

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

V>>Вот так, шаг за шагом приходится вести тебя к пониманию положения дел. А ведь казалось бы — интернет большой, всё написано.
WH>Какое положение дел?
WH>Всего _два_ драйвера насчитали.

Угу, всего два двайвера на каждый чипсет.

V>>Да какие пару? Сколько платформ, столько драйверов. А каждый год появляются всё новые и новые платформы и всё новые и новые железки.
WH>Ты говоришь, так как будто платформ много.

В год десятки новых чипсетов для разнообразных архитектур.

WH>Да по сравнению со всем остальным софтом ты их никогда в микроскоп не увидишь.

Это здесь причем?

V>>Дык, игнор вопросов по-существу я принимаю за согласие. Если нет — велкам ответить по-существу хотя бы насчет комбинированного интерфейса HDMI.
WH>Я ответил. Но ты не понял.

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

V>>Бутылка — это вообще мини-ОС, считай, что интересно там только ядро АОС бла-бла-бла
WH>Ты тут пытаешься утверждать, что в бутылке с безопасностью не хуже чем в сингулярити.

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

V>>Ну да, таких дыр в самой популярной операционке изчезающе мало, в основном из легаси-кода. Вряд ли есть в новом коде, т.к. в компиляторе от MS стоят все эти проверки по опасному АПИ CRT.
WH>Есть еще куча прикладного софта.

Ну так этот код в юзверском пространстве работает. Не сиди под админом и всё.

V>>Боюсь, сегодня у тебя не получится привести ссылку на работающий пример под Win7.
WH>Я за этим не слежу. Но уверен мыщъх много покажет.

Не покажет. Времена WinXP давно прошли.

V>>Еще раз, драйверов всего мильон, а не пару. Пару критичных только на конкретной железке, а самих железок тонна. Атаковать надо через ср-ва загрузки и запуска программ.
WH>Миллион реализаций IOMMU?
WH>Ты точно ничего не путаешь?

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

V>>Ты еще попроси через JS атаковать. И да, обычное приложение может являться частью инфраструктуры. И вообще, любая атака — это комплексное мероприятие.
WH>Тот же мыщъх показывал и атаки через JS с переполнением буфера интерпретатора.

Не сиди под админом.

WH>И через JVM.
WH>А все по тому что нехрен такие вещи на С писать.

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

> Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?

Имхо этот вопрос еще рано задавать. Может быть и проблема пока надумана. Сейчас ведь даже не выбраны существующие пути решения — хотя бы выбрать правильный уровень и разрез изоляции.
Имхо 95% всех вопросов или даже больше решить можно организационно, на верхнем уровне изоляции. Схема: совместно используемое оборудование (почти) без состояний. Полностью изолированные разделы:
— игры (опасный)
— хрень (опасный)
— работа (безопасный)
— пароли, явки (безопасный)
— еще какая-нибудь хрень (безопасный)
где вообще половина может быть сертифицированными наборами софта, а по вопросам безопасности болит голова у производителей.
---
Хотя если я неправильно понял и вам просто хочется пообщаться на тему безопасности ос, то сорри

Posted via RSDN NNTP Server 2.1 beta

M>>Стоп-стоп-стоп. А какой, по-твоему, Оберон в BlueBottle? Напомню: ты утверждаешь, что GC, синхронизация объектов и прочие плюшки реализуются не языком, а средой:

V>Да.

M>>То есть Bluebottle банально является VM для некоего языка Оберон.

V>Нет, это десктоп над AOS. А сама AOS — среда исполнения программ на АО. Соответственно просто ОберонОС — это среда исполнения ропграмм на просто Обероне. BlackBox — это среда исполнения программ на Компонентном Паскале, который есть тоже Оберон на самом деле.

То есть это — банальная VM.

V>Который есть развитие Модулы, которая есть развитие первоначального Паскаля. Вот такой винигрет. Запутаться можно, согласен, но это же не повод для поливания г-ном, не?

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

M>>Ты тут начинаешь рассказывать сказки про компилируемость этого языка,
V>Это не сказки, это так и есть.

Ну-ну. И во что компилируется Оберон в Bluebottle?

M>>Одно или оба из этих двух утверждений являются ложью.

V>Ничего не является ложью. Компиллируемость в байт-код НЕ является чем-то обязательным. Есть Обероны с байт-кодом (для изоляции от аппаратной платформы), а есть без промежуточного байт-кода. Ничего принципиально не меняется. Модули в любом случае хранят одну и ту же метаинформацию, которая для Оберона крайне компактна и быстро парсится, в отличие от метаинформации дотнета. Да, где используется байт-код, там работает JIT-загрузка этого байт-кода. Причем, эта загрузка работает по-требованию, причем, это работает с 80-х годов. Второй раз один-в-один мы увидели всё тоже самое в дотнете от второго после Вирта всемирно известного турбо-дельфи-паскалиста. Но дотнет у тебя, судя по другим постам, таких возражений не вызывает.

Сколько слов только ради того, чтобы попытаться выкрутиться.

Два простых вопроса:
— Берем Оберон, компилируем его в нативный код. В нем будет GC, динамическая загрузка и асинхронность, или не будут?
— Берем Оберон, запускаем его в BlueBottle. В нем будет GC, динамическая загрузка и асинхронность, или не будут?

M>>Если Оберон компилируемый, то в нем не будет ни GC, ни активных объектов — ни-че-го, потому что ты утверждаешь, что эти фишки — прерогатива VM.

V>Среда исполнения — это не обязательно VM. Это метаинформация + механизм по ее обслуживанию. А будет ли эта метаинформация о виртуальном байт-коде или реальном для конкретной железки — не принципиально. Похоже, в этом месте у тебя сидит глобальное непонимание работы того же дотнета. У него унутре сосуществуют две метаинформации: одна исходная из объектного файла, вторая — реальное расположение данных и кода после JIT.

Ты утверждаешь, что для GC, асинхронности и т.п. Оберону обязательно нужна ОСь, которая все это будет предоставлять. Если она ему нужна, то эта ОСь — VM для Оберона, и без этой VM он — ничто.

M>>Если эти фишки — прерогатива VM, то Оберон не компилируемый, ну или компилируемый в некоторое внутреннее представление этой самой VM (что и происходит — модули хранятся в некоем внутреннем двоичном представлении). Но для получения плюшек такой VM (GC, асинхронные сообщения и т.п.) Оберон и не нужен, что прекрасно видно на примере Erlang'а.

V>Нет никакой VM даже в байт-кодном Обероне.

А сама AOS — среда исполнения программ на АО. Соответственно просто ОберонОС — это среда исполнения ропграмм на просто Обероне.

Да ты что, никакой VM, ты что. Есть только «среда исполнения ропграмм на просто Обероне».

V>Есть загрузчик, который работает со скоростью обычного загрузчика ОС (!!!), переводя виртуальные байт-коды в реальные железные. Нет никакой рантайм-интерпретации, нет никакой динамики. Только статика.

Ну да, ну да. Для Оберона типа сделали JIT. И? Без VM в этом хваленом Обероне не будет ничего из этого:

GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

ARK>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

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

V>>Нет, это десктоп над AOS. А сама AOS — среда исполнения программ на АО. Соответственно просто ОберонОС — это среда исполнения ропграмм на просто Обероне. BlackBox — это среда исполнения программ на Компонентном Паскале, который есть тоже Оберон на самом деле.

M>То есть это — банальная VM.

То есть ты НЕ понимаешь определение "среда исполнения". Это не VM, увы.

V>>Который есть развитие Модулы, которая есть развитие первоначального Паскаля. Вот такой винигрет. Запутаться можно, согласен, но это же не повод для поливания г-ном, не?

M>Ну, ты сам прикладываешь все усилия к тому, чтобы всю эту кашу поливали говном.

Глупости. Я вижу реакцию только конкретно на слово Оберон. Ни Паскаль ни Модула такой реакции почему-то не вызывают.

Это курьез сам по себе. Ну и не настолько уж это и каша, если речь идет о 30-тилетнем сроке смены языков. Всего-лишь две серьезные ревизии. C# меняется быстрее гораздо, оставляя одно и то же название. Вот это и есть путаница.

M>>>Ты тут начинаешь рассказывать сказки про компилируемость этого языка,
V>>Это не сказки, это так и есть.
M>Ну-ну. И во что компилируется Оберон в Bluebottle?

В бинарные модули.

M>>>Одно или оба из этих двух утверждений являются ложью.

V>>Ничего не является ложью. Компиллируемость в байт-код НЕ является чем-то обязательным. Есть Обероны с байт-кодом (для изоляции от аппаратной платформы), а есть без промежуточного байт-кода. Ничего принципиально не меняется. Модули в любом случае хранят одну и ту же метаинформацию, которая для Оберона крайне компактна и быстро парсится, в отличие от метаинформации дотнета. Да, где используется байт-код, там работает JIT-загрузка этого байт-кода. Причем, эта загрузка работает по-требованию, причем, это работает с 80-х годов. Второй раз один-в-один мы увидели всё тоже самое в дотнете от второго после Вирта всемирно известного турбо-дельфи-паскалиста. Но дотнет у тебя, судя по другим постам, таких возражений не вызывает.

M>Сколько слов только ради того, чтобы попытаться выкрутиться.

Т.е. любая информация проходит сквозь тебя не задерживаясь? В этом посте ответ на все твои вопросы относительно якобы VM. Или я сложно объясняю?

M>Два простых вопроса:
M>- Берем Оберон, компилируем его в нативный код. В нем будет GC, динамическая загрузка и асинхронность, или не будут?

Да, кроме встроенной асинхронности, она такая же как и везде, как в С++, например или в дотнете.

M>- Берем Оберон, запускаем его в BlueBottle. В нем будет GC, динамическая загрузка и асинхронность, или не будут?

Да, если компилить компилятором AO и пользовать активные расширения языка. Дополниетльно там доступно вроде бы и обычным Обероном компилить (если не ошибаюсь), получая первый твой вариант.

V>>Среда исполнения — это не обязательно VM. Это метаинформация + механизм по ее обслуживанию. А будет ли эта метаинформация о виртуальном байт-коде или реальном для конкретной железки — не принципиально. Похоже, в этом месте у тебя сидит глобальное непонимание работы того же дотнета. У него унутре сосуществуют две метаинформации: одна исходная из объектного файла, вторая — реальное расположение данных и кода после JIT.

M>Ты утверждаешь, что для GC, асинхронности и т.п. Оберону обязательно нужна ОСь, которая все это будет предоставлять. Если она ему нужна, то эта ОСь — VM для Оберона, и без этой VM он — ничто.

Ага, так ты неверно понимаешь термин VM. И о чем тогда спор? Давай сначала определимся в терминологии. Да, есть Обероны с VM, но есть и без VM и они ничем не отличаются, потому VM не является фокусом, фокус на среде исполнения. VM — это абстрактная машина, а конкретные коды — они конкретные. Поясни, плиз, в чем такая катастрофическая разница для тебя VM vs просто M?

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

M>Да ты что, никакой VM, ты что. Есть только «среда исполнения ропграмм на просто Обероне».

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

V>>Есть загрузчик, который работает со скоростью обычного загрузчика ОС (!!!), переводя виртуальные байт-коды в реальные железные. Нет никакой рантайм-интерпретации, нет никакой динамики. Только статика.

M>Ну да, ну да. Для Оберона типа сделали JIT. И? Без VM в этом хваленом Обероне не будет ничего из этого:
M>

M>GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

Было, есть и будет без специфичной VM. Ты разве не в курсе, как выгружать нейтивные модули? Кстати, VM дотнета этого не умеет, зато умеет нейтивный COM. Аналогично функциональные типы. Тебя же не смущает, что многие функциональные языки компиляются в нейтив? Функциональный тип в нейтиве во время выполнения представлен парой указателей { функция, замкнутый_контекст }. Делегаты Оберона устроены точно так же. Одноименные делегаты дотнета аналогично (кто бы сомневался

M>>>>Ты тут начинаешь рассказывать сказки про компилируемость этого языка,
V>>>Это не сказки, это так и есть.
M>>Ну-ну. И во что компилируется Оберон в Bluebottle?

V>В бинарные модули.

Ну то есть не в нативный x86 код, например, а внекий промежуточный код, так?

M>>Два простых вопроса:
M>>- Берем Оберон, компилируем его в нативный код. В нем будет GC, динамическая загрузка и асинхронность, или не будут?

V>Да,

Будут или не будут? — Да.

Шикарный ответ

V>кроме встроенной асинхронности, она такая же как и везде, как в С++, например или в дотнете.

Ты утверждал, что GC, динамическая загрузка и асинхронность — это прерогатива ОСи.

M>>- Берем Оберон, запускаем его в BlueBottle. В нем будет GC, динамическая загрузка и асинхронность, или не будут?

V>Да, если компилить компилятором AO и пользовать активные расширения языка. Дополниетльно там доступно вроде бы и обычным Обероном компилить (если не ошибаюсь), получая первый твой вариант.

V>>>Среда исполнения — это не обязательно VM. Это метаинформация + механизм по ее обслуживанию. А будет ли эта метаинформация о виртуальном байт-коде или реальном для конкретной железки — не принципиально. Похоже, в этом месте у тебя сидит глобальное непонимание работы того же дотнета. У него унутре сосуществуют две метаинформации: одна исходная из объектного файла, вторая — реальное расположение данных и кода после JIT.

M>>Ты утверждаешь, что для GC, асинхронности и т.п. Оберону обязательно нужна ОСь, которая все это будет предоставлять. Если она ему нужна, то эта ОСь — VM для Оберона, и без этой VM он — ничто.

V>Ага, так ты неверно понимаешь термин VM.

Я его хорошо понимаю. Это ты тут рассказываешь сказки.

V>И о чем тогда спор? Давай сначала определимся в терминологии. Да, есть Обероны с VM, но есть и без VM и они ничем не отличаются, потому VM не является фокусом, фокус на среде исполнения. VM — это абстрактная машина, а конкретные коды — они конкретные. Поясни, плиз, в чем такая катастрофическая разница для тебя VM vs просто M?

В чем, по твоему, состоит разница между VM и «средой исполнения»?

V>В отличие от дотнета, байт-код которого неприспособлен для непосредственного исполнения на процессорах, для Оберона существуют железные процессоры, исполняющие его байт-код.

Дадада, Оберон, компилирующийся в байт-код — это супер-мега компилирующийся язык с оптимизирующим!!!одинодинодин компилятором
А Erlang, компилирующийся в в байт-код — это голимый интерпретатор ©

Логика, как всегда, на высоте.

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

От того, что семантика близка к процессору, не делает эту VM не-VM

M>>Да ты что, никакой VM, ты что. Есть только «среда исполнения ропграмм на просто Обероне».

V>Да. Потому что VM — это абстракция от конкретного железа. А среда исполнения — это набор функциональности и соглашений, реализованных в АПИ. Безо-всякой надобности в какой-либо виртуальности. А твой любимый дотнет — это совокупность VM и среды исполнения на ее основе.

Если код выпоняется внутри среды исполнения, то чем является среда исполнения для этого кода? Банальной VM. Особенно, если учесть, что без этой среды в Обероне ничего не будет.

V>>>Есть загрузчик, который работает со скоростью обычного загрузчика ОС (!!!), переводя виртуальные байт-коды в реальные железные. Нет никакой рантайм-интерпретации, нет никакой динамики. Только статика.

M>>Ну да, ну да. Для Оберона типа сделали JIT. И? Без VM в этом хваленом Обероне не будет ничего из этого:
M>>

M>>GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.

V>Было, есть и будет без специфичной VM.

Ты утверждал, что все процитированное — «это ОС естественно» © Опять меняешь показания?

V>Ты разве не в курсе, как выгружать нейтивные модули? Кстати, VM дотнета этого не умеет, зато умеет нейтивный COM. Аналогично функциональные типы. Тебя же не смущает, что многие функциональные языки компиляются в нейтив? Функциональный тип в нейтиве во время выполнения представлен парой указателей { функция, замкнутый_контекст }. Делегаты Оберона устроены точно так же. Одноименные делегаты дотнета аналогично (кто бы сомневался

).

Что насчет GC и «асинхронности изкоробки»?

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

V>>кроме встроенной асинхронности, она такая же как и везде, как в С++, например или в дотнете.

M>Ты утверждал, что GC, динамическая загрузка и асинхронность — это прерогатива ОСи.

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

V>>Ага, так ты неверно понимаешь термин VM.
M>Я его хорошо понимаю.

Ты его не понимаешь вообще никак.

M>В чем, по твоему, состоит разница между VM и «средой исполнения»?

Я давал определение в том же посте ниже.

M>Дадада, Оберон, компилирующийся в байт-код — это супер-мега компилирующийся язык с оптимизирующим!!!одинодинодин компилятором

Да.

M>А Erlang, компилирующийся в в байт-код — это голимый интерпретатор ©

Да. Потому что динамическия языки, в отличие от статически-тпизированных, трудно оптимизировать. Фактически только через суперкомпиляцию, а этот раздел IT находится пока мест в зачаточном состоянии. Поэтому в Эрланге выполняется постоянный eval любой динамической переменной. Помимо динамики, интерпретация байт-кода, это не тоже самое, что исполнений нейтивного кода. Поэтому на Обероне числдробилки работают на уровне С++, а на Эрланге — в 100 раз медленне. А почему для Эрланг техногия JIT является некоторой проблемой, в сравнении с JIT для дотнета или джавы — рекомендую помедитировать самостоятельно. В любом случае, в условиях динамики даже JIT не помогает, как показали лучшие компиляторы Схемы — затраты на распаковку динамических значений всё-равно существенные.

M>Логика, как всегда, на высоте.

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

V>>Потому что он имеет вполне нормальное кодирование, близкое по семантике к современным процессорам. Поэтому, мне сложно согласиться с буквой V.
M>От того, что семантика близка к процессору, не делает эту VM не-VM

При наличии железного исполнения — делает. Открой хотя бы вики.

M>Если код выпоняется внутри среды исполнения, то чем является среда исполнения для этого кода? Банальной VM.

Нет, она является АПИ, реализующей некие соглашения. GDI/USER в Windows — это тоже среда исполнения.

M>Особенно, если учесть, что без этой среды в Обероне ничего не будет.

OMG. Масло-маслянное. Без донета не будет дотнета. Вот такой уровень аргументов.

V>>Ты разве не в курсе, как выгружать нейтивные модули? Кстати, VM дотнета этого не умеет, зато умеет нейтивный COM. Аналогично функциональные типы. Тебя же не смущает, что многие функциональные языки компиляются в нейтив? Функциональный тип в нейтиве во время выполнения представлен парой указателей { функция, замкнутый_контекст }. Делегаты Оберона устроены точно так же. Одноименные делегаты дотнета аналогично (кто бы сомневался

).

M>Что насчет GC и «асинхронности изкоробки»?

А что с ними не так? Тебе бла-бла-бла надо услышать или технические детали? Если второе — переформулируй вопрос.

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

V>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?
Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.
Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.
Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

Блин. Ну никакой фантазии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Блин, закладки могут быть во всем, а чаще всего — сразу во многих местах. И тем более в скачанной игрушке. Если для тебя этот сценарий кажется маловероятным, то ты просто не в теме.
Закладки в скачанной игрушке ни кого не волнуют.
Волнуют только закладки в ядре ОС и нескольких критичных драйверах.
Которые по пальцам одной руки пересчитать можно.

V>Угу, всего два двайвера на каждый чипсет.
Ты говоришь так как будто количество чипсетов можно заметить в микроскоп по сравнению с остальным софтом.

V>В год десятки новых чипсетов для разнообразных архитектур.
Сертифицировать сотню драйверов в год. Какой ужОс.

WH>>Да по сравнению со всем остальным софтом ты их никогда в микроскоп не увидишь.
V>Это здесь причем?
При том, что закладки волнуют только в паре драйверов.
Во всем остальном софте закладки не волнуют.

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

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

V>Утверждалась о сходной модели построения ОС.
Общего у них только безопасность на уровне языка.
Но это всё равно, что утверждать, что все ОС, которые используют аппаратную защиту одинаковые.

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

При том, что в бутылке защиты нет совсем.

V>IOMMU можно сказать что и нет. А как будет в полный рост — то это замена DMA. А что у нас происходит в DMA — мы знаем. У каждого производителя за несколько лет накопится целая серия спецификаций, по одной на каждую генерацию чипсета.
Только все они будут сводиться к тому разрешить ли доступ конкретной железке к конкретной страницы памяти.
Те SetAccess(device, page, access) : bool.
Вот и весь интерфейс IOMMU драйвера.

V>Потому что в Windows не сложилась культура обслуживания привилегий, хотя бы на уровне Линукс. При том, что если брать не культуру, а функциональность системы, отвечающей за привилегии, то она в виндах многократно покруче будет.
Бла-бла-бла.
Ибо узел ботнета может встать и под юзером. Ему много не надо.
Да и для кражи данных юзера админ не нужен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

V>Да. Потому что динамическия языки, в отличие от статически-тпизированных, трудно оптимизировать. Фактически только через суперкомпиляцию, а этот раздел IT находится пока мест в зачаточном состоянии. Поэтому в Эрланге выполняется постоянный eval любой динамической переменной. Помимо динамики, интерпретация байт-кода, это не тоже самое, что исполнений нейтивного кода.

Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?

M>>Особенно, если учесть, что без этой среды в Обероне ничего не будет.

V>А что с ними не так? Тебе бла-бла-бла надо услышать или технические детали? Если второе — переформулируй вопрос.

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

1. Берем Оберон—язык.

Что есть в языке из перечисленного (на уровне спецификаций, описаний и т.п.):
— ООП
— функциональные типы
— динамическая загрузка модулей
— активные объекты из коробки
— GC

2. Берем программу на Обероне и компилируем ее в нативный код. То есть, например, в x86-нативный код, готовый выполняться, скажем, в винде без оберток типа BlackBox'а, BlueBottle или чего-то там еще

Что там будет из перечисленного:
— ООП
— функциональные типы
— динамическая загрузка модулей
— активные объекты из коробки
— GC

3. Берем среду/VM BlackBox и пишем в ней программу на Обероне

Что там будет из перечисленного:
— ООП
— функциональные типы
— динамическая загрузка модулей
— активные объекты из коробки
— JIT (то есть докомпиляция не до внутреннего представления BlackBox, а до именно нативного кода)

4. Берем ОСь BlueBottle и пишем в ней программу на Обероне

— ООП
— функциональные типы
— динамическая загрузка модулей
— активные объекты из коробки
— JIT (то есть докомпиляция не в байткод, а до именно нативного кода — как бы он там ни был представлен)

5. Берем Оберон, пишем программу для микроконтроллера, компилируем... Ну для того же PIC, или пофиг для чего.

Что там будет из перечисленного:
— ООП
— функциональные типы
— динамическая загрузка модулей
— активные объекты из коробки
— JIT

V>>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?
WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.
WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.
WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

WH>Блин. Ну никакой фантазии.

Самое смешное, что MS SQL Server уже давно так и работает, по сути. Вплоть до того, что из Enterprise Studio хрен откроешь файлы на restore/backup, если у пользователя нет доступа к этим файлам

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

V>>Да. Потому что динамическия языки, в отличие от статически-тпизированных, трудно оптимизировать. Фактически только через суперкомпиляцию, а этот раздел IT находится пока мест в зачаточном состоянии. Поэтому в Эрланге выполняется постоянный eval любой динамической переменной. Помимо динамики, интерпретация байт-кода, это не тоже самое, что исполнений нейтивного кода.

M>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?

Мде...
Ес-но.

M>1. Берем Оберон—язык.

M>Что есть в языке из перечисленного (на уровне спецификаций, описаний и т.п.):
M>- ООП
M>- функциональные типы

В языке.

M>- динамическая загрузка модулей
M>- активные объекты из коробки
в версии АО
M>- GC

А эти пункты обеспечивается аналогом CRT, назовем его ORT, хотя его наывают просто Оберон.
Если написал хоть одну программу на дотнете, то должен понимать о чем речь. "Чисто язык" C# вообще не имеет смысла без GC, библиотечных модулей, RTTI и т.д. и т.п. Все эти вещи выходят за рамки языка, но программы на языке пишут из расчета, что все эти вещи есть. В Обероне аналогично. Вернее — наоборот, разарботчики Явы и Дотнета переняли философию Оберона. Не зря Java-язык и Java-среда исполнения названы одним словом, как и Оберон. Первое не имеет смысла без второго.

M>2. Берем программу на Обероне и компилируем ее в нативный код. То есть, например, в x86-нативный код, готовый выполняться, скажем, в винде без оберток типа BlackBox'а, BlueBottle или чего-то там еще

XDS oberon compiler

А чем не устраивает среда исполнения BlackBox?

M>Что там будет из перечисленного:
M>- ООП
M>- функциональные типы
M>- динамическая загрузка модулей
M>- активные объекты из коробки
M>- GC

Кроме активных объектов — всё (если не ошибаюсь, мой гугл не лучше твоего). ИМХО, активные объекты вообще мало смысла имеют без специальной ОСи. Я это объяснял в предыдущем посте. Хотя, пощуать вживую их можно на WinAosMini.

M>4. Берем ОСь BlueBottle и пишем в ней программу на Обероне

M>- ООП
M>- функциональные типы
M>- динамическая загрузка модулей
M>- активные объекты из коробки
M>- JIT (то есть докомпиляция не в байткод, а до именно нативного кода — как бы он там ни был представлен)

Всё будет.

M>5. Берем Оберон, пишем программу для микроконтроллера, компилируем... Ну для того же PIC, или пофиг для чего.

M>Что там будет из перечисленного:
M>- ООП
M>- функциональные типы
M>- динамическая загрузка модулей
M>- активные объекты из коробки
M>- JIT

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

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

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

Замечательно!

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

WH>>Ну так оно и будет происходить через OpenFileDialog.
WH>>OpenFileDialog будет возвращать не строку как сейчас, а файл.
V>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
Это уже используется в реальном мире более 20 лет. Ты бы посмотрел что-нибудь окромя виртовских куч дерьма?

Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.

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

V>>>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
WH>>Не помню. Но модель сингулярити как раз на такой сценарий и заточена.
V>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?
Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android).

V>Первые два пункта. Т.е. то, что относится сугубо к языку. Среда исполнения контроллеру не нужна. Потому что не нужно динамическое управление ресурсами. Это важный аспект, предлагаю помедитировать — а нахрена вообще нужны какие-то там среды исполнения? Какую именно задачу они берут на себя?

Суммируем:

Сам язык:
— ООП
— Функциональные типы

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

Более того, как язык Оберон не привнес абсолютно ничего нового. Хуже того, в себя ничего нового он не вобрал. Что ООП, что «функциональные типы» (хак для того, чтобы иметь ФВП в языке) давно были, и применялись промышленно задолго до Оберона-языка.

Компиляция в нативный код:
— не известно, будет ли динамическая подгрузка модулей
— не известно, будет ли GC
— активных объектов не будет
потому что «гугл тоже не уверен».

VM/среда выпонения
— GC
— активные объекты (весьма примитивные, на основе мьютексов, локов и т.п)
— динамическая загрузка модулей

— GC не является чем-то новым. В частности, тот же Lisp широко использовался в промышленных масштабах еще в 80-е и — внезапно — у него был GC. Не говоря об изобретении GC в 1959-м. APL тоже не может пожаловаться на отсутсвие промышленного применения, и тоже обладал GC.
— Активные объекты не являются чем-то новым: к тому моменту, как появился Active Oberon, Erlang уже вовсю использовался в промышленности, причем с моделью намного более умной. И не надо рассказывать сказки про «ах, сравнивать компилируемый язык с интерпретатором». Как ты сам сказал, при нативной компиляции активные объекты внезапно куда-то исчезают. О чем, собственно, честно сказано у самих оберонщиков. То есть, как и что выполняется в Active Oberon для поддержки этих объектов, вопрос открытый. Ну и как я уже говорил, работа над Erlang'ом основывалась на еще более ранних параллельных языках, активно используемых тогда в промышленности.
— динамическая загрузка модулей так же не является чем-то новым. До Оберона в промышленных масштабах использовалась от того же Лиспа, как я понимаю, до того же Erlang'а.

Ну да, ну да, к началу 2000-ных маленькая часть всей этой Паскале-подобной куча-малы имела все вышеперечисленное, но существовало оно только в виде Bluebottle (или AOS?) + ActiveOberon. Ну да, собрали кучу идей и воплотили их в чем-то одном. И? Ну так не они первые собрали все в кучу, и не они последние. Ключевое: не они первые.

И чем так гордятся оберонщики? Тем, что он первым был в чем-то там? Так не был он первым. Тем, что на нем ОСь написана? Так не на нем одном и не на нем первом. Тем, что у него строгая статическая типизация, не позволяющая произвольно мнеять объекты в памяти? Так не у него одного, не у него первая (при том, что таки позволяет менять и System входит в описание языка). Тем, что у него к 1999-му году появились «активные объекты»? Ну так в реализации «mutex-lock-sync-wait» далеко не у него одного, и не у него первого. А в боле грамотной реализации точно не у него. То, что у него есть «функциональные типы»? Так не у него одного и точно не у него первого.

В чем гордость, брат? ©

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

M>Суммируем:

M>Сам язык:
M>- ООП
M>- Функциональные типы
— простой
— детерминированный
— типобезопасный
— надежный

M>То есть сам язык из себя ничего не предоставляет, как тут и говорилось уже много раз.

Угу, как и разработанный на 20 лет позже C# ничего из себя не представляет. А Джава вообще стократ убогее смотрелась. Только на библиотеках и выехала.

M>Все эти вопли про «супероптимизирующие компиляторы» и прочий бред можно спокойно выкидывать, потому что в этом примитиве и оптимизировать, по сути, нечего.

Оптимизировать всегда есть чего. Никаких воплей не было, это твоя проблема восприятия. Речь шла о хорошей на тот момент оптимизации. Собственно, более-менее хороший код генерили только компиляторы паскалеподобных языков и Фортрана. Компиляторы С++ их существенно обогнали уже ближе к концу 90-х, начала 2000-х.

M>Более того, как язык Оберон не привнес абсолютно ничего нового.

Ну да, это продолжение того самого Паскаля и Модулы от того же самого автора. По сравнению с этими языками, собственного же производства, Вирт не привнес ничего нового, кроме более приятного синтаксиса (эти парные begin/end в Паскале когда-то нехило раздражали), + GC, плюс шлифанул сам язык, + добавил среду исполнения, получился Оберон. Для 80-х годов очень неплохо. Это считай та же Джава, только более продвинутая и на 10-15 лет раньше вышедшая.

M>Хуже того, в себя ничего нового он не вобрал.

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

M>Что ООП, что «функциональные типы» (хак для того, чтобы иметь ФВП в языке) давно были, и применялись промышленно задолго до Оберона-языка.

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

M>Компиляция в нативный код:
M>- не известно, будет ли динамическая подгрузка модулей

Известно, будет.

M>- не известно, будет ли GC

Известно, будет.

M>- активных объектов не будет

В каких-то версиях будет, в каких-то не будет.

M>потому что «гугл тоже не уверен».

Потому что зря ты учавствуешь в форуме, если не трудишься включать внимательность. Речь шла о конкретном BlackBox.

M>VM/среда выпонения
M>- GC
M>- активные объекты (весьма примитивные, на основе мьютексов, локов и т.п)
M>- динамическая загрузка модулей

M>- GC не является чем-то новым.

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

M>В частности, тот же Lisp широко использовался в промышленных масштабах еще в 80-е и — внезапно — у него был GC.

Ты видел этот лисповый GC? Самое время посмотреть и устыдиться. Две процедуры по 10-15 строк. Кароч, пытаться сравнивать синхронный и асинхронный GC — это даже не смешно.

M>Не говоря об изобретении GC в 1959-м. APL тоже не может пожаловаться на отсутсвие промышленного применения, и тоже обладал GC.

Угу, как и Матлаб, и которые все, упсс, интерпретаторы с синхронным GC.

M>- Активные объекты не являются чем-то новым: к тому моменту, как появился Active Oberon, Erlang уже вовсю использовался в промышленности, причем с моделью намного более умной.

Модель Эрланга намного более глупая, отсюда непреодолимые проблемы ввода-вывода. Чтобы Эрланг поумнел, ему нужна среда-операционка навроде AOS или Сингулярити. А так это полная профанация хорошей идеи. Если в AOS и Сингулярити ввод-вывод намного эффективнее, чем в обычных операционках, то на таком же точно активном Эрланге ввод-вывод тормозит ВСЮ программу из всех сотент и тысяч активностей. Это же полный П. Даже взять тот же нашумевший проект про роутер на Эрланге, приводилась статистика: объем кода на Эрланге в общей доле всего кода был менее 20%, в основном идет код на С/С++. Более того, эрланговский код обслуживал самую ненапряжную вещь — установку соединений, доля требуемых вычислительных ресурсов под которую — менее сотой доли одного % от всех задач. Очередной полный П.

M>И не надо рассказывать сказки про «ах, сравнивать компилируемый язык с интерпретатором».

Надо. Надо все эти тупые интерпретирующие поделки выжигать каленым железом. Если под язык существует только интерпретатор — это недоделанный язык. Интерпретатор хорош только для REPL и других малюсеньких задач, где критично время запуска после внесенного исправления. Идеальный вариант — шелл, написали строчку кода, тут же запустили. Если же программа отлажена, то нафига ей интерпретатор-то? Фактически, на любой компиллируемый сегодня язык можно написать интерпретатор, был бы смысл. Например, для Хаскеля так и сделали — идет компилятор + интерпретатор (сугубо для REPL). Но когда берут кастрат-интерпретатор для более-менее серьезных по объемам задач.... брр... Вот уж точно, "каждая домохозяйка должна уметь программировать" (С).

M>Как ты сам сказал, при нативной компиляции активные объекты внезапно куда-то исчезают.

Это ты уже совсем бредишь.

M>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?
Ес-но.

BlueBottle построена на AOS. Работает полностью нейтивный код, ленивая загрузка образов с грануляцией уровня модуля, GC и все остальные плюшки.

M>О чем, собственно, честно сказано у самих оберонщиков. То есть, как и что выполняется в Active Oberon для поддержки этих объектов, вопрос открытый.

Где ты там увидел, что активные объекты исчезают? Живут и здравствуют. Какая поддержка — тоже сказано.

M>Ну и как я уже говорил, работа над Erlang'ом основывалась на еще более ранних параллельных языках, активно используемых тогда в промышленности.

А вышло, что вышло. Предмет потешательства и издевательств над вычислительной эффективностью языка.

M>- динамическая загрузка модулей так же не является чем-то новым. До Оберона в промышленных масштабах использовалась от того же Лиспа, как я понимаю, до того же Erlang'а.

Очередной незачет. Ну ты в курсе...

M>Ну да, ну да, к началу 2000-ных маленькая часть всей этой Паскале-подобной куча-малы имела все вышеперечисленное, но существовало оно только в виде Bluebottle (или AOS?) + ActiveOberon. Ну да, собрали кучу идей и воплотили их в чем-то одном. И?

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

M>Ну так не они первые собрали все в кучу, и не они последние. Ключевое: не они первые.

Дык, молодец, что размахиваешь своими ключевыми комплексами. Мне-то до фени. Тем более, что в споре было ключевое не это. Зацеплись за другое — что в промышленном масштабе этому всему (реализованному в Обероне и AOS) только еще предстоит набирать обороты, поэтому объявлять идеи, обкатанные вокруг Оберона устаревшими, было как минимум глупо. Сейчас даже на дотнете толком продуктов на рынке коробочного ПО не видно, куда уж там до активных объектов... До них еще десяток лет, если не больше. Это всё ОСи следующего поколения. Не зря MS ковыряется в своей Сингулярити и её потомках...

Единственно в чем можно обвинить Оберон — это в низкой готовности к обще-коммерческому применению. Т.е. даже взять тот же Дельфи или Джаву — степень готовности была высокая. Но это всё требует денег и ничего кроме денег, на то она и коммерция. Посмотри на тот же Nemerle, уже сколько лет его пилят, а кач-во поставки такое, что на реальный проект его не возьмешь, при всей его интересности. Посмотрим на результаты через несколько лет развития при финансовой поддержке.

M>И чем так гордятся оберонщики? Тем, что он первым был в чем-то там?

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

M>Так не был он первым.

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

M>А в боле грамотной реализации точно не у него.

Гы, а какая реализация асинхронности грамотная? Как у Сингулярити? Пффф.. В Сингулярити ограничение и связь по рукам и ногам. Сверх-простые вещи ты должен делать сверх-дорого. ИМХО, самая грамотная реализация это та, которая позволяет не платить за лишнее, если это лишнее не нужно. Или же позволяет создать любые необходимые навороты, типа тех же самых каналов в Сингулярити. В ней каналы — это просто реализация межпотоковой очереди, которая идет изкаробки, и которую без проблем можно сделать в библиотечном виде.

M>В чем гордость, брат? ©

Таки батхёрт? Ну это не ко мне.

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

Для баз данных эти файлы создаются:
1. удаленно;
2. при этом зачастую автоматически клиентским удаленным приложением.

WH>Блин. Ну никакой фантазии.

Воображение и фантазии — разные вещи. Фантазии — это результат неумения подчинять воображение законам мира, то бишь путь к сфероконям и прочим феям.
Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз.

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

M>Самое смешное, что MS SQL Server уже давно так и работает, по сути. Вплоть до того, что из Enterprise Studio хрен откроешь файлы на restore/backup, если у пользователя нет доступа к этим файлам

Ты всерьез открываешь бэкапы только из Enterprise Studio? Ручками? И создаешь бэкапы тоже ручками? Действительно, очень смешно. DMO/SMO/RMO пользовать не пробовал?

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

WH>>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
V>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.

V>Воображение и фантазии — разные вещи. Фантазии — это результат неумения подчинять воображение законам мира, то бишь путь к сфероконям и прочим феям.
V>Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз.
Да-да. Ты придумал совершенно левый довод, и с апломбом считаешь, что все вокруг идиоты.

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

WH>>>Ну так оно и будет происходить через OpenFileDialog.
WH>>>OpenFileDialog будет возвращать не строку как сейчас, а файл.
V>>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
C>Это уже используется в реальном мире более 20 лет.

Брехня. В реальном мире на десктопе винда, а на серваках линукса. И там и там такой функциональности НЕТ.
Все остальное на уровне Оберона по распространенности или еще многократно ниже.

C>Ты бы посмотрел что-нибудь окромя виртовских куч дерьма?

Ты бы до ветру сходил.

C>Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.

Это уже операционка? И это точно человек на том конце интернета, а не бот?

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

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

C>Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android).

Дык, куда смотреть? На сфероконей или реальную Сингулярити? Или ты совсем потерялся?

1. Твой говноандроид вообще вскрывается на раз;
2. По безопасности кода ему до Оберона как до пекина раком;
3. По эффективности работы ему до Оберона как до Пекина раком туда и обратно;

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

Ладно бы ты еще привел в пример bada или MeGoo, но Андроид — это сразу в сад к нубам не задерживаясь. Но даже bada и MeGoo так же сидят на устаревшей архитектуре операционки.

И да, конфиги практически всегда надо шарить м/у приложениями. А пример сервиса конфигов мы давно видели — реестр виндов. Со всеми такими же проблемами и граблями как и с независимыми файлами, в случае надобности шарить эти конфиги м/у независимыми программами. Т.е. сама фраза "а вот тут сервис конфигов" выдает невладение предметом.

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

V>>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
C>Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.

Прямо-таки на весь носитель??? Шарик, да ты... ну ты понял... Это не ложится на предложенную модель безопасности вообще никак. С т.з. этой модели и носителей-то никаких для юзверя нет, тома в лучшем случае.

V>>Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз.
C>Да-да. Ты придумал совершенно левый довод, и с апломбом считаешь, что все вокруг идиоты.

Ты или отвечай по делу, или не отнимай мои кванты внимания.
А чтобы тебе легче было сосредоточиться, верну-ка я скипнутый тобой неудобный момент:

Угу, особенно это будет хорошо смотреться, если у меня только консоль к базе данных с удалённой клиентской машины.

Для баз данных эти файлы создаются:
1. удаленно;
2. при этом зачастую автоматически клиентским удаленным приложением.

И для избежания разночтений, заранее поясню, что консоль к базе — это не RDP-сессия, в которой запросто можно показать диалог от имени другого юзверя (ситемной записи, типа как выскакивают диалоги в Win7), это просто соединение по TCP + аутентификация всего одним юзвером, + функциональность на основе библиотек, аналогичных SQLDMO/SQLSMO/SQLRMO.

Смогешь разрулить, как считаешь?

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

C>>Это уже используется в реальном мире более 20 лет.
V>Брехня. В реальном мире на десктопе винда, а на серваках линукса. И там и там такой функциональности НЕТ.
Я же говорю — хватит показывать своё незнание.

Изоляция процессов с помощью разграничения доступа к ресурсам путём использования неподделываемых handle'ов называется http://en.wikipedia.org/wiki/Capability-based_security . В Юниксах она частично может быть реализована с помощью запрета для процессов открывать файлы, кроме тех, дескрипторы которых получаются от доверенных процессов. Это используется на практике в юниксах уже 20 лет, для этого есть специальный механизм передачи файлов через локальные сокеты ( http://archives.neohapsis.com/archives/postfix/2000-09/1476.html ).

C>>Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.
V>Это уже операционка? И это точно человек на том конце интернета, а не бот?
В принципе, уже да (см. http://www.google.com/intl/en/chrome/devices/ )

V>Как GoogleChrome относится к Сингулярити? А к Оберону? Мало того, что пример своей нерелевантностью характеризует отсутствие логического мышления, дык еще у тебя хватает наглости эту нерелевантность пытаться натягивать сугубо на одну сторону спора. Хорошо себя чувствуешь? Нерелевантные аргументы априори можно натягивать с одинаковым успехом в обе стороны.
Ага, "слаботипизированный OCaml".

Тебе посчитать количество твоих увиливаний в сторону и переходов на непонятно что? Ну типа, перехода с ФВП на контроллеры с ОЗУ в 512 байт.

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

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

Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.

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

Я утверждал изначально о безопасности кода, порождаемого языком. Это ровно та безопасность, которая позволяет отказаться от защищенной памяти и получать целый ворох плюшек в награду. Если же рассуждать о безопасности к вирусам/атакам, то язык тут вообще не при чем. Согласен? Байткод, кстати, в бутылке тоже присутствует и тоже ровно с той же целью — для переносимости. Обсуждаемые в этой подветке вещи (типа верификации байткода) можно надстроить НАД готовой операционкой. Как пример — популярные сейчас "песочницы". Потребовала хоть одна "песочница" переделки ядра ОС? Нет, есно. Это просто специальная версия загрузчика.

V>>Утверждалась о сходной модели построения ОС.
WH>Общего у них только безопасность на уровне языка.

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

WH>Но это всё равно, что утверждать, что все ОС, которые используют аппаратную защиту одинаковые.

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

WH>Ты нашол только ДВА драйвера в которых закладки опасны.
WH>По сравнению с миллионами программ защиту, от которых можно переложить на механизмы ОС это просто ничто.

И в чем аргумент? С чего ты взял, что точно так же невозможно этой защитой наградить ту же AOS? В Сингулярити это выполняется не ядром операционки, а специальным приложением — инсталлятором. Кто мешает написать аналогичный инсталлятор для AOS? Я думаю, что этого не сделали от того, что такие ОСи используют не как ОСи общего назначения, а как специализированные, встаиваемые. Т.е. сам вопрос еще не стоял. Это не начит, что вопрос неразрешим, если вдруг встанет. Просто MS производит ОСи общего назначения, поэтому им эта тема была важна.

WH>При том, что в бутылке защиты нет совсем.

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

V>>IOMMU можно сказать что и нет. А как будет в полный рост — то это замена DMA. А что у нас происходит в DMA — мы знаем. У каждого производителя за несколько лет накопится целая серия спецификаций, по одной на каждую генерацию чипсета.
WH>Только все они будут сводиться к тому разрешить ли доступ конкретной железке к конкретной страницы памяти.
WH>Те SetAccess(device, page, access) : bool.
WH>Вот и весь интерфейс IOMMU драйвера.

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

V>>Потому что в Windows не сложилась культура обслуживания привилегий, хотя бы на уровне Линукс. При том, что если брать не культуру, а функциональность системы, отвечающей за привилегии, то она в виндах многократно покруче будет.
WH>Бла-бла-бла.
WH>Ибо узел ботнета может встать и под юзером. Ему много не надо.

Прописать себя для автостарта не сможет, если правильно зону безопасности для интернета задать под виндами.

WH>Да и для кражи данных юзера админ не нужен.

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

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

C>>Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android).
V>Дык, куда смотреть? На сфероконей или реальную Сингулярити? Или ты совсем потерялся?
Оберон — это один сплошной сфероконь. Точнее, сферическая какашка коня.

В Сингулярити, кстати, сервис логов есть.

V>1. Твой говноандроид вообще вскрывается на раз;
Программой без привиллегий? Неа, не вскрывается.

V>2. По безопасности кода ему до Оберона как до пекина раком;
Ты вообще понял о чём говоришь? В Обероне безопасности НЕТ ВООБЩЕ.

Её не то что не надо взламывать, а её НЕТ ВООБЩЕ И ПОЛНОСТЬЮ. Любой модуль может что угодно делать с системой. Показать как БлювотнуюБутылку сломать простой программой?

V>3. По эффективности работы ему до Оберона как до Пекина раком туда и обратно;
Ну раз сказал — давай бенчмарки. На ARM-устройстве.

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

V>>>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
C>>Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.
V>Прямо-таки на весь носитель??? Шарик, да ты... ну ты понял... Это не ложится на предложенную модель безопасности вообще никак. С т.з. этой модели и носителей-то никаких для юзверя нет, тома в лучшем случае.
Ну да. Подумать дальше одного шага — неее, невозможно.

Понятное дело, что можно и на часть носителя. Возможно, реализованную в виде виртуального раздела или отдельного файла/каталога. Это совершенные мелочи реализации.

V>И для избежания разночтений, заранее поясню, что консоль к базе — это не RDP-сессия, в которой запросто можно показать диалог от имени другого юзверя (ситемной записи, типа как выскакивают диалоги в Win7), это просто соединение по TCP + аутентификация всего одним юзвером, + функциональность на основе библиотек, аналогичных SQLDMO/SQLSMO/SQLRMO.
V>Смогешь разрулить, как считаешь?

1) Ты сполз с обычных приложений на какие-то непонятнораспределённые системы. Далее:

- А как это делается НА ОБЕРОНЕ?
— Очень просто, так как на Обероне нет баз данных. Checkmate. Муахахаха.

2) Никаких проблем с надёжной передачей идентичности пользователя через TCP нет. Этим занимается, для примера, Kerberos и задача сводится к: "открываю на удалённом хосте консольку под местным администратором и говорю 'на носителе XX разрешить создавать базу данным пользователям группы ПОЛЬЗОВАТЕЛЬ_БД' ".

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

Причём подобные системы уже существуют и активно используются: http://docs.oracle.com/cd/E19082-01/819-7309/txnet-2/index.html

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

C>И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует.

Тебе не пофиг ли, что именно признает некий vdimas из интернета? Тебя объективная реальность интересует или чтобы тебе было в споре комфортно? Ссылки на реальные проекты уже приводил.

Интереса ради обрати внимание на поддержку реалтайма, встроенного в язык:
http://www.embeddedcomputingconference.ch/pdf_sec_2009/4A2-Glavitsch.pdf

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

C>>И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует.
V>Тебе не пофиг ли, что именно признает некий vdimas из интернета? Тебя объективная реальность интересует или чтобы тебе было в споре комфортно? Ссылки на реальные проекты уже приводил.
Где они? Где их можно скачать и посмотреть?

Я пока ничерта не вижу, кроме убогой БлевотнойБутылки.

V>Интереса ради обрати внимание на поддержку реалтайма, встроенного в язык:
V>http://www.embeddedcomputingconference.ch/pdf_sec_2009/4A2-Glavitsch.pdf
А причём здесь realtime?

И прямо оттуда:

Real-time tasks
 Real-time tasks have highest priority
 Can interrupt garbage collector
 Garbage collector runs as separate thread (так как там древний как говно мамонта трёхцветный GC)
 Are not allowed to modify object graph ещё бы, так как может столкнуться с GC
 Are not allowed to allocate memory
 Are not allowed to use thread synchronization constructs such as
EXCLUSIVE and AWAIT
 May only call procedures/methods that itself do not allocate memory
 Enforced by compiler directive

Вау, такая поддержка, ну ТАКАЯ поддержка.

Ты бы не позорился.

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

V>>Правда в ИДЕ под Оберон этот SYSTEM хоть специально подсвечивается, а где такое же для модуля Obj в OCaml или unchecked (или как его там) в Haskell?
WH>Ты опять сам с собой разговаривашь.
WH>

WH>На паскалеподобных языках меньше делают ошибок на каждый чих, в сравнении с недотипизированными OCaml или Си.

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

V>>Докажи обратное. Сценарии, где он предпочтительнее всех, я уже давал неоднократно, но ты не соизволил их проанализировать. К тому же, парсер оперативный, без откатов, поэтому на своих сценариях
WH>Не давал.
WH>Ни одного.
WH>Только с умным видом говорил, что они есть.

Давал раз 10.

1. Парсинг потока из сети. Область деятельности — EDI. Размеры документов — мегабайты. Неоднозначность низкая, но не позволяет обходиться регулярными грамматиками. Любые парсеры с откатами в таких сценариях выглядят убого.

2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.

Вырезка:

C and C++ both allow the following statement:

x * y ;

It has two different parses:
It can be the declaration of y, as pointer to type x
It can be a multiply of x and y, throwing away the answer.

...

And if you cheat enough, you can make LR parsers work for C and C++. The GCC guys did for awhile, but gave it up for hand-coded parsing, I think because they wanted better error diagnostics.

There's another approach, though, which is nice and clean and parses C and C++ just fine without any symbol table hackery: GLR parsers. These are full context free parsers (having effectively infinite lookahead). GLR parsers simply accept both parses, producing a "tree" (actually a directed acyclic graph that is mostly tree like) that represents the ambiguous parse. A post-parsing pass can resolve the ambiguities.

We use this technique in the C and C++ front ends for the DMS Software Reengineering Tookit. They have been used to process millions of lines of large C and C++ systems, as well as dozens of other languages.

V>>он крайне популярен. В комфортных для себя сценариях работает со скоростью лексера, только даже еще быстрее в несколько раз (в переводе на мегабайты исходного текста). Почему так — предлагаю догадаться самому.
WH>В комфортных это на LR(0) грамматике?

Дык, чтобы ему сравнять по скорости хотя бы с лексером, надо до десятка одновременных веток протягивать до конца. А по опыту реального использования — в среднем болтаются 2-4 ветки на тех коротких участках, где этих веток больше одной. В приведенном примере в точке ';' опять наступает однозначность. А все неумершие варианты хранятся очень эффективно, переиспользуя общие части дерева разбора.

V>>Если есть что по-существу — ответь там и кинь мне ссылку.
WH>Я тебя отправил читать про альфабленд.
WH>Вот и почитай.
WH>И подумай, как это относится масштабированию.
WH>И фильтр на тех картинка был строго один и тот же.

Назови просто имя алгоритма фильтрации и/или ресэмплинга. Я гуглом пользоваться умею. Либо опиши словами (можно на псевдокоде) алгоритм, я тебе скажу как он называется. Самому не любопытно разве узнать, какой именно велосипед ты самостоятельно изобрел?

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

V>>Я видеотехнике и обработке изображений посвятил достаточно лет, мне эти темы преобазований/калибровки цветовых пространств интересны.
WH>Не заметно.

Пока до технических моментов не дойдем, заметно не будет.

V>>Это не тоже самое, ес-но. Это местами эффективней, местами нет. Как раз по работе довожу эффективность различных способов передачи данных/сигналов м/у потоками. В каких-то сценариях рулят lock-free буфера (аналоги твоих каналов), а в каких-то всех заруливает обыкновенный shared доступ с короткими блокировками. Думать, что есть единое лекарство на все случаи — это ммм... как минимум непрофессионально, если не сказать покрепче.
WH>Ты опять сам с собой разговариваешь.
WH>Ты тут толкал мысль о том, что сингулярити и бутылка одинаковые.

Ну дык, Сингулярити ограниченее, понятно. Ограничь бутылку, например, попроси у меня качественную реализацию межпотоковой очереди с элегантно решенной ABBA-проблемой и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити. Про инсталлятор с верификатором говорил уже. Это же не ядро ОС, это просто запускаемое приложение. Это инфраструктура.

V>>И да, показательно, что как только я попытался тебя сосредоточить на том, что как создаются сами каналы (не из глобальной ли кучи?), ты продемонстрировал игнор. Собсно, как и всегда, когда доходим до конкретики — тебя сразу нет.
WH>Не из глобальной.

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

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

C>>>И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует.
V>>Тебе не пофиг ли, что именно признает некий vdimas из интернета? Тебя объективная реальность интересует или чтобы тебе было в споре комфортно? Ссылки на реальные проекты уже приводил.
C>Где они? Где их можно скачать и посмотреть?

C>Я пока ничерта не вижу, кроме убогой БлевотнойБутылки.

Т.е. по ссылке не ходил?

V>>Интереса ради обрати внимание на поддержку реалтайма, встроенного в язык:
V>>http://www.embeddedcomputingconference.ch/pdf_sec_2009/4A2-Glavitsch.pdf
C>А причём здесь realtime?

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

C>И прямо оттуда:
C>

C>Real-time tasks
C> Real-time tasks have highest priority
C> Can interrupt garbage collector
C> Garbage collector runs as separate thread (так как там древний как говно мамонта трёхцветный GC)
C> Are not allowed to modify object graph ещё бы, так как может столкнуться с GC
C> Are not allowed to allocate memory
C> Are not allowed to use thread synchronization constructs such as
C>EXCLUSIVE and AWAIT
C> May only call procedures/methods that itself do not allocate memory
C> Enforced by compiler directive

C>Вау, такая поддержка, ну ТАКАЯ поддержка.

C>Ты бы не позорился.

Понятно, и здесь ты тоже не в теме. Да что же за фигня... Ты чем по работе хоть занимаешься?

Короче, цимус в том, что:
1. контроллируется компилятором. А точно такое же для VoIP я бегал по всему коду глазками и зачищал за всех ручками;
2. выполняется обычно в контексте прерывания прямо от железа;

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

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

V>>>>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
C>>>Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.
V>>Прямо-таки на весь носитель??? Шарик, да ты... ну ты понял... Это не ложится на предложенную модель безопасности вообще никак. С т.з. этой модели и носителей-то никаких для юзверя нет, тома в лучшем случае.
C>Ну да. Подумать дальше одного шага — неее, невозможно.

C>Понятное дело, что можно и на часть носителя. Возможно, реализованную в виде виртуального раздела или отдельного файла/каталога. Это совершенные мелочи реализации.

ЧТД. Куда ни копни — в той же Сингулярити чего надо тоже нет. И приходится на лету лихорадочно изобретать.
Спасибо, мне отлично удалось заставить тебя спорить с самим с собой, достаточно было подменить вывеску. В следующий раз я буду тупо копипастить твои аргументы, приведенные в защиту Сингулярити.

V>>И для избежания разночтений, заранее поясню, что консоль к базе — это не RDP-сессия, в которой запросто можно показать диалог от имени другого юзверя (ситемной записи, типа как выскакивают диалоги в Win7), это просто соединение по TCP + аутентификация всего одним юзвером, + функциональность на основе библиотек, аналогичных SQLDMO/SQLSMO/SQLRMO.
V>>Смогешь разрулить, как считаешь?

C>1) Ты сполз с обычных приложений на какие-то непонятнораспределённые системы. Далее:

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

C>

C>- А как это делается НА ОБЕРОНЕ?
C>- Очень просто, так как на Обероне нет баз данных. Checkmate. Муахахаха.

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

C>2) Никаких проблем с надёжной передачей идентичности пользователя через TCP нет. Этим занимается, для примера, Kerberos и задача сводится к: "открываю на удалённом хосте консольку под местным администратором и говорю 'на носителе XX разрешить создавать базу данным пользователям группы ПОЛЬЗОВАТЕЛЬ_БД' ".

Дудки, это должно быть автоматически. Ты просто кнопку должен нажать в GUI удаленного приложения. А изначально, напомню, предлагалось, чтобы некий FileOpenDialog возвращал не имя файла, а открытый файл. Вот давай, возвращай открытый файл через удаленную не RDP-консоль.

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

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

C>Причём подобные системы уже существуют и активно используются: http://docs.oracle.com/cd/E19082-01/819-7309/txnet-2/index.html

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

На сегодня адью.

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

C>В Сингулярити, кстати, сервис логов есть.

Сервис логов — это просто приложение. Напиши этот сервис логов хоть даже на самописную операционку.

V>>1. Твой говноандроид вообще вскрывается на раз;
C>Программой без привиллегий? Неа, не вскрывается.

V>>2. По безопасности кода ему до Оберона как до пекина раком;
C>Ты вообще понял о чём говоришь? В Обероне безопасности НЕТ ВООБЩЕ.

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

C>Её не то что не надо взламывать, а её НЕТ ВООБЩЕ И ПОЛНОСТЬЮ. Любой модуль может что угодно делать с системой. Показать как БлювотнуюБутылку сломать простой программой?

Давай. Без модуля SYSTEM. Считаем, что у нас программа без привилегий и (согласно выданной рядом ссылке) я могу ограничить возможность приложения зависеть от SYSTEM. Ломай.

V>>3. По эффективности работы ему до Оберона как до Пекина раком туда и обратно;
C>Ну раз сказал — давай бенчмарки. На ARM-устройстве.

Нахрена тебе такие сложности? Бери Android-x86. Будем перемножать матрицу 1000x1000.

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

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

C>Изоляция процессов с помощью разграничения доступа к ресурсам путём использования неподделываемых handle'ов называется http://en.wikipedia.org/wiki/Capability-based_security . В Юниксах она частично может быть реализована с помощью запрета для процессов открывать файлы, кроме тех, дескрипторы которых получаются от доверенных процессов. Это используется на практике в юниксах уже 20 лет, для этого есть специальный механизм передачи файлов через локальные сокеты ( http://archives.neohapsis.com/archives/postfix/2000-09/1476.html ).

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

OpenFileDialog возвращает не строку как сейчас, а файл.

Покажи мне, где это уже 20 как есть в реальном мире. Ответь хотя бы раз за свои слова.

C>>>Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.
V>>Это уже операционка? И это точно человек на том конце интернета, а не бот?
C>В принципе, уже да (см. http://www.google.com/intl/en/chrome/devices/ )

V>>Как GoogleChrome относится к Сингулярити? А к Оберону? Мало того, что пример своей нерелевантностью характеризует отсутствие логического мышления, дык еще у тебя хватает наглости эту нерелевантность пытаться натягивать сугубо на одну сторону спора. Хорошо себя чувствуешь? Нерелевантные аргументы априори можно натягивать с одинаковым успехом в обе стороны.
C>Ага, "слаботипизированный OCaml".

Угу, и давай вилять. Потому что как обычно — сказать нечего. А когда есть чего — вечно невпопад. См. начало этого поста.
Даю еще одну попытку. Как GoogleChrome относится к Сингулярити? Почему не к Оберону?

C>Тебе посчитать количество твоих увиливаний в сторону и переходов на непонятно что? Ну типа, перехода с ФВП на контроллеры с ОЗУ в 512 байт.

Считай. Мне и считать не надо — у тебя все сообщения нерелевантны. Даже в этом посте дважды.

V>Байткод, кстати, в бутылке тоже присутствует и тоже ровно с той же целью — для переносимости.

M>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?

Мде...
Ес-но.

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

V>Ну дык я видел не раз в реальных программах и библиотеках на OCaml опасные конструкции.
Те в обероне модуля SYSTEM не существует?

V>1. Парсинг потока из сети. Область деятельности — EDI. Размеры документов — мегабайты. Неоднозначность низкая, но не позволяет обходиться регулярными грамматиками. Любые парсеры с откатами в таких сценариях выглядят убого.
Бла-бла-бла.
Грамматику давай.

V>2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.
БРЕД! Полнейший.
С++ невозможно адекватно разобрать контекстно-свободным парсером.
А GLR строго контекстно-свободный.

V>Вырезка:
Читай её сам.
GLR не справляется.
Нужен постпроцессинг.

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

V>Назови просто имя алгоритма фильтрации и/или ресэмплинга. Я гуглом пользоваться умею. Либо опиши словами (можно на псевдокоде) алгоритм, я тебе скажу как он называется. Самому не любопытно разве узнать, какой именно велосипед ты самостоятельно изобрел?

V>Лично для меня всегда фан узнавать, что я самостоятельно изобретал, скажем прямо, нетривиальные вещи. В до-интернетныен времена такое происходило регулярно.
Любой фильтр. Любой ресамплинг.
Если неправильно работать с альфой будет этот артефакт.
Почему так и откуда он берется, попробуй догадаться сам.
Ключевое слова альфабленд. Посмотри на формулу бленда пикселей с альфой. Она тебя очень сильно удивит.

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

V>Ну дык, Сингулярити ограниченее, понятно. Ограничь бутылку, например, попроси у меня качественную реализацию межпотоковой очереди с элегантно решенной ABBA-проблемой
Чего? Это название гуглиться не может.

V>и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити.
Это полный звездец.
Ты действительно не понимаешь, что на бутылке сингулярити не сделать?
Ты действительно не понимаешь, сколько возможностей для той же оптимизации дают изолированные процессы?
Ты действительно не понимаешь, что на мониторах lockfree не получится?

V>Про инсталлятор с верификатором говорил уже. Это же не ядро ОС, это просто запускаемое приложение. Это инфраструктура.
Которой в бутылке нет. И сделать нельзя.
Ибо изоляции всё равно нет.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>ЧТД. Куда ни копни — в той же Сингулярити чего надо тоже нет. И приходится на лету лихорадочно изобретать.
Есть.
А даже если чего то нет в конкретной реализации то модель сингулярити такова что все о чем тут говорим, делается за день не напрягаясь.

V>Спасибо, мне отлично удалось заставить тебя спорить с самим с собой, достаточно было подменить вывеску. В следующий раз я буду тупо копипастить твои аргументы, приведенные в защиту Сингулярити.

В твоем воображении.

V>Я сполз на заурядное, но достаточно полноценное клиентское приложение, которое умеет бэкап и восстановление своих данных (при наличии нужных разрешений приладному пользователю). Это банально, в общем-то, т.к. все либы для любых баз для этого дела есть.
Осталось понять, что пользователь может спокойно дать приложению нужные права.
Ты пойми. Нет разницы между тем, чтобы дать права приложению и пользователю.

V>Дудки, это должно быть автоматически. Ты просто кнопку должен нажать в GUI удаленного приложения. А изначально, напомню, предлагалось, чтобы некий FileOpenDialog возвращал не имя файла, а открытый файл. Вот давай, возвращай открытый файл через удаленную не RDP-консоль.
Ты говоришь, так как будто это единственный механизм дать права приложению.
Воображение отсутствует.
Совсем.

V>Спасибо, класных лулзов посшибал. Если ты еще не воткнул где именно — Вольфхаунд тебе растолкует. Ты его терию только что уничтожил, ну просто под асфальт закатал.
Опять сам с собой говоришь.
Что из того что написано по ссылке противоречит тому что я говорю?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.
Бред.

V>Я утверждал изначально о безопасности кода, порождаемого языком. Это ровно та безопасность, которая позволяет отказаться от защищенной памяти и получать целый ворох плюшек в награду.
Опять бред. Оберон не защищает от гонок.
Гонки могут привести к расстрелу памяти.

V>Если же рассуждать о безопасности к вирусам/атакам, то язык тут вообще не при чем. Согласен?
Нет.

V>Именно, это базис. И основные плюшки удивительно перекликаются. А остальные навороты — фактически прикладная функциональность.
Что там пересекается?
Там все разное.

V>И в чем аргумент? С чего ты взял, что точно так же невозможно этой защитой наградить ту же AOS?
С того что там нет изоляции.
Вообще нет.

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

V>Кто мешает написать аналогичный инсталлятор для AOS?
Модель исполнения которая использована в бутылке.

V>Я думаю, что этого не сделали от того, что такие ОСи используют не как ОСи общего назначения, а как специализированные, встаиваемые. Т.е. сам вопрос еще не стоял. Это не начит, что вопрос неразрешим, если вдруг встанет. Просто MS производит ОСи общего назначения, поэтому им эта тема была важна.
Для бутылки неразрешим.
Разве что дотошно сертифицировать каждое приложение.
Но это не реально.
И пользователи, и разработчики хором пошлют тебя с таким предложением.

V>Пофиг, защита не в ядре операционки находится, а на прикладном уровне. Это принципиально. А на этом уровне можно навертеть что угодно при наличии ресурсов..
Защита находится ни там и ни там.
Она находится на уровне модели исполнения, которой подчиняется и ядро, и прикладные программы.

V>Ты потерял нить.
Ты ее даже не находил.

V>Даже драйвер DMA тоже имеет простой интерфейс,
Проблема сингулярити не в драйверах ДМА, а в том, что интерфейс железок для работы с ДМА не имеет ничего общего между собой.
Поэтому они не смогли верифицировать работу конкретной железки с ДМА.
Если бы было IOMMU то им не пришлось бы.
Достаточно было бы заставить драйвер декларировать какую страницу памяти он собрался читать/писать. Статический контроль для этого сделать тривиально.
После чего становится совершенно наплевать на интерфейс железки. Ибо если она полезет не туда, то просто получится отлуп от IOMMU.

V>речь была о том, что рано или поздно самих этих драйверов IOMMU будет много.
Много это сколько?
100?
По сравнению с миллионами программ каждая из которых на порядки сложнее всех этих драйверов вместе взятых?

А ведь в бутылке придется сертифицировать буквально все.

При этом в сингулярити мы насчитали целые две группы драйверов.
Драйверы винта и драйверы IOMMU.

V>Прописать себя для автостарта не сможет, если правильно зону безопасности для интернета задать под виндами.
Еще что-нибудь переполнит и пропишется.

WH>>Да и для кражи данных юзера админ не нужен.
V>Нужен для доступа к данным остальных юзеров.
Не нужен. На персоналках обычно один юзер.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.
WH>Бред.

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

V>>Я утверждал изначально о безопасности кода, порождаемого языком. Это ровно та безопасность, которая позволяет отказаться от защищенной памяти и получать целый ворох плюшек в награду.
WH>Опять бред. Оберон не защищает от гонок.
WH>Гонки могут привести к расстрелу памяти.

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

Даже для сложного С++ Valgrind находит такие вещи на раз, а уж для простейшего байткода сам бог велел.

V>>И в чем аргумент? С чего ты взял, что точно так же невозможно этой защитой наградить ту же AOS?
WH>С того что там нет изоляции.
WH>Вообще нет.

Я тебя уже поправлял: единица изоляции там — это приватная память объекта. Активный Объект — это и есть процесс. И ты никак не можешь эту изоляцию нарушить через голову публичного АПИ объекта.
Если тебя лично напрягают глобальные переменные в модулях — это твои предрассудки. Модуль — это всего-лишь синглтон, это полный аналог обычного объекта, который заведомо будет существовать в единственном экземпляре в любой операционке, даже в Сингулярити. Как пример — список сетевых интерфейсов. И какая фиг разница, явно передавать ссылку на такой синглтон каждый раз, или обойтись одним уровнем косвенности меньше, воспользовавшись услугами загрузчика по ресолвингу имен?

V>>В Сингулярити это выполняется не ядром операционки, а специальным приложением — инсталлятором.
WH>В сингулярити изоляция обеспечивается моделью исполнения.

Тут не про изоляцию, а про безопасный для исполнения код.

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

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

V>>Кто мешает написать аналогичный инсталлятор для AOS?
WH>Модель исполнения которая использована в бутылке.

Ладно, пошли механические ответы, уже не интересно. Спасибо за участие.

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

V>>Байткод, кстати, в бутылке тоже присутствует и тоже ровно с той же целью — для переносимости.

M>

M>>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?

M>Мде...
M>Ес-но.

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

Но я не доктор.

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

V>>ЧТД. Куда ни копни — в той же Сингулярити чего надо тоже нет. И приходится на лету лихорадочно изобретать.
WH>Есть.
WH>А даже если чего то нет в конкретной реализации то модель сингулярити такова что все о чем тут говорим, делается за день не напрягаясь.

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

V>>Спасибо, мне отлично удалось заставить тебя спорить с самим с собой, достаточно было подменить вывеску. В следующий раз я буду тупо копипастить твои аргументы, приведенные в защиту Сингулярити.
WH>В твоем воображении.

Это я не тебе, ты тут ответил за другого. И да, посмотри, что там предлагается вначале.

V>>Я сполз на заурядное, но достаточно полноценное клиентское приложение, которое умеет бэкап и восстановление своих данных (при наличии нужных разрешений приладному пользователю). Это банально, в общем-то, т.к. все либы для любых баз для этого дела есть.
WH>Осталось понять, что пользователь может спокойно дать приложению нужные права.
WH>Ты пойми. Нет разницы между тем, чтобы дать права приложению и пользователю.

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

V>>Дудки, это должно быть автоматически. Ты просто кнопку должен нажать в GUI удаленного приложения. А изначально, напомню, предлагалось, чтобы некий FileOpenDialog возвращал не имя файла, а открытый файл. Вот давай, возвращай открытый файл через удаленную не RDP-консоль.
WH>Ты говоришь, так как будто это единственный механизм дать права приложению.

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

WH>Воображение отсутствует.

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

WH>Что из того что написано по ссылке противоречит тому что я говорю?

Вот это:

C>Понятно, что для обеспечения общих инвариантов безопасности будет требоваться, чтобы клиентские системы тоже были безопасными. Тогда общение через сеть будет просто частным случаем посылки сообщений.
C>Причём подобные системы уже существуют и активно используются: http://docs.oracle.com/cd/E19082-01/819-7309/txnet-2/index.html

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

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

V>Дык, если в эту степь рассуждать, что и в Оберон-ОС можно много чего прикрутить. Собственно, она таки позиционируется — это инструмент для разработки эффективных и надежных исполнительных сред.
Нельзя.
Модель исполнения не позволяет.
При этом в сингулярити http://en.wikipedia.org/wiki/Capability-based_security вшита прямо в модель исполнения.

V>Это от вида распространения привилегий в приложении зависит. Я говорю как раз о таком сценарии, где было бы неплохо, чтобы приложение работало под правами конкретного пользователя. Это просто обязательно при любом подключении на сервер с некоей точки удаленного доступа неважно по какому протоколу.
Это можно сделать.
Но не нужно.
Ни одному приложению не нужны все права пользователя.
Максимум что нужно БД это права на чтение/записаь в некоторые папки.

WH>>Ты говоришь, так как будто это единственный механизм дать права приложению.
V>Нет, это ты многократно сделал на этом упор, а я лишь показал тебе случай, где это не работает.
Не выдумывай. Я никогда не говорил что это единственный способ.
Я говорил про то, что это абсолютно безгеморройный способ с одной стороны железно ограничить приложение и с другой дать пользователю возможность открывать любые файлы.

V>Придумаешь еще что-то покажу и там. В общем, я здесь скурпулёзно и последовательно перебираю аргументы технического плана,

При этом, не понимая, что тебе говорят.

V>В этом подходе предлагается доверять сетевым ендпоинтам, наделяя соединения с ними теми же возможнстями/правами, как и локальные программы. Т.е. уже даже не надо патчить никакой код на атакуемой машине. Чтобы было понятно о чем речь: компьютерные сетевые картейки вообще никак не видят прозрачные ethernet-свичи.
Ты опять с собой разговариваешь.
Никто не мешает установить защищённое соединение с защитой от MiM. И таких протоколов тьма.
Это в любом случае нужно, если ты собираешься обеспечить безопасность.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>В этом подходе предлагается доверять сетевым ендпоинтам, наделяя соединения с ними теми же возможнстями/правами, как и локальные программы. Т.е. уже даже не надо патчить никакой код на атакуемой машине. Чтобы было понятно о чем речь: компьютерные сетевые картейки вообще никак не видят прозрачные ethernet-свичи.
Про шифрование и надёжные протоколы установления подлинности — ты как-то забыл.

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

V>>Дык, если в эту степь рассуждать, что и в Оберон-ОС можно много чего прикрутить. Собственно, она таки позиционируется — это инструмент для разработки эффективных и надежных исполнительных сред.
WH>Нельзя.
WH>Модель исполнения не позволяет.
WH>При этом в сингулярити http://en.wikipedia.org/wiki/Capability-based_security вшита прямо в модель исполнения.
Шото как-то мне надоело с ним флеймить. В третий раз по кругу пошло обсуждение.

PS: можно ли в Немерле организовать что-то типа typeset'ов из Rust'а?

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

V>>>Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.
WH>>Бред.
V>Предлагаю не отмахиваться от этого вопроса, он интересен.
Абсолютно не интересен, любому у кого есть хоть капля воображения.

V>Согласно репорту Сингулярити, при инсталяции драйвера создается его некий манифест, который указывает ресурсы, к которым можно обращаться этому драйверу. Если целевой драйвер работает с другим драйвером-посредником, то вот ситуация — эти ресурсы (например, для окна DMA) он должен получать динамически. Но верификатор Сингулярити такой код не пропустит, т.е. не подзволит читать/писать произвольную память. Остается передавать непосредственно данные посреднику, чтобы тот их закачивал в DMA. А это не взлетит для видео однозначно. Или есть еще третий вариант?
Что такое закачать в ДМА?
Правильно.
Записать данные в страницу памяти.
И сказать ДМА, где их брать.

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

Мы эти страницы даже в пользовательском коде заполнить можем.
И все будет точно так же.

Кстати IOMMU на данную модель натягивается почти автоматически.

V>А могут и нет, если поле атомарного типа (машинное слово). Что мешает выяснять эти моменты верификатором, например, если некий объект забыли пометить как синхронизируемый, но к нему могут идти вызовы более чем от одного активного или несинхронизируемого объекта (в т.ч. в произвольных сочетаниях)?

Не работает. Теоритически. Ибо можно новые модули загружать.

V>Даже для сложного С++ Valgrind находит такие вещи на раз, а уж для простейшего байткода сам бог велел.

Статически? В условиях загрузки новых модулей?

А динамически никому не нужно.
Ибо будет решето как в современных ОС.

V>Я тебя уже поправлял: единица изоляции там — это приватная память объекта. Активный Объект — это и есть процесс. И ты никак не можешь эту изоляцию нарушить через голову публичного АПИ объекта.
БРЕД!
Ибо ссылки на внутренние объекты могут быть беспрепятственно сохранены, где попало.

V>Если тебя лично напрягают глобальные переменные в модулях — это твои предрассудки. Модуль — это всего-лишь синглтон, это полный аналог обычного объекта, который заведомо будет существовать в единственном экземпляре в любой операционке, даже в Сингулярити.
Бред.
В бутылке модуль глобален на всю ОС.
В сингулярити на процесс.
Хотя я бы их вообще отменил.
Не нужны они.

V>Как пример — список сетевых интерфейсов. И какая фиг разница, явно передавать ссылку на такой синглтон каждый раз, или обойтись одним уровнем косвенности меньше, воспользовавшись услугами загрузчика по ресолвингу имен?
Какой феерический бред.
Ты про безопасность системы вообще не думаешь.
Так делать нельзя.
Никогда.

V>>>В Сингулярити это выполняется не ядром операционки, а специальным приложением — инсталлятором.
WH>>В сингулярити изоляция обеспечивается моделью исполнения.
V>Тут не про изоляцию, а про безопасный для исполнения код.
Без изоляции это невозможно.

V>А насчет модели исполнения — экземпляры объектов полностью изолированы.
Бред.

V>Эта такая же модель исполнения, вид в профиль.
Способности к анализу отсутствуют.

V>ИМХО, тебя сбивает с толку термин "процесс", ты забываешь, что процесс — это объект операционной системы.
Ты опять говоришь с собой.

V>А в Обероне это объект языка.
Ох.
Ты что действительно не понимаешь, что в сингулярити для каждого процесса есть свое объектное пространство?
Что не могут существовать ссылки из одного процесса в другой?
И что оберон никак от этого не защищает?

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

Модель сингулярити не мешает ввести и другие примитивы общения без нарушения изоляции процессов.

V>Я бы предпочел, чтобы были доступны оба варианта, а за безопасностью следил верификатор.
Бред.
Не бывает таких верификаторов.
Особенно в условиях динамической загрузки кода.

V>Кстати, для встроенной реализации каналов даже язык толком расширять не придется. Если помнишь, в Паскале файл — это не файл на диске, это порт последовательного доступа к типизированным кортежам. А за ним может быть что угодно.
Бред.
Необходимы поддержка уникальных ссылок и проверка протоколов.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

C>PS: можно ли в Немерле организовать что-то типа typeset'ов из Rust'а?
Если интересует, задай вопрос в тематическом форуме.
И ссылку не забудь. Ибо что-то с наскоку не гуглится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

V>>Ну дык я видел не раз в реальных программах и библиотеках на OCaml опасные конструкции.
WH>Те в обероне модуля SYSTEM не существует?

Давай мы сначала разберемся с OCaml. А то вы меня забодали тыкать одной и той же, вполне справедливой фразой. В отличие от Оберона, у тебя и возможности-то не будет узнать про зависимость от модуля Obj в конечном образе. А в Обероне можно явно запретить загрузку модуля с такой зависимостью.

V>>1. Парсинг потока из сети. Область деятельности — EDI. Размеры документов — мегабайты. Неоднозначность низкая, но не позволяет обходиться регулярными грамматиками. Любые парсеры с откатами в таких сценариях выглядят убого.
WH>Бла-бла-бла.
WH>Грамматику давай.

Да бери любые транзакции из EDIFACT X12.

V>>2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.
WH>БРЕД! Полнейший.
WH>С++ невозможно адекватно разобрать контекстно-свободным парсером.
WH>А GLR строго контекстно-свободный.

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

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

V>>Вырезка:
WH>Читай её сам.
WH>GLR не справляется.
WH>Нужен постпроцессинг.

GLR даст все возможные корректные ветки разбора. Ес-но, приведенный отрезок не парсится ни одним контекстно-свободным парсером, даже TDOP. Но TDOP будет безбожно врать на этом примере, т.к. он разбирает первую попавшуюся ветку, как и ПЕГ, а GLR честно предоставит все варианты. А потом эти варианты уже ресолвятся решателем на основе программирования в ограничениях.

WH>А если в мой парсер добавить таблицу имен он это без всякого построцессинга разберет.

Любой разберет с таблицей, твой парсер тут не при чем. Я же эту технику и показывал для С++, как неоднозначности сводятся к однозначностям. Но это такой язык, где необязательно объявление идет впереди использования, а если нет, то TDOP парсер для таких сценариев вообще самый худший вариант.

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

V>>Назови просто имя алгоритма фильтрации и/или ресэмплинга. Я гуглом пользоваться умею. Либо опиши словами (можно на псевдокоде) алгоритм, я тебе скажу как он называется. Самому не любопытно разве узнать, какой именно велосипед ты самостоятельно изобрел?

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

Гы, я просто пока не в курсе, что ты вкладываешь в слово "неправильно работать с альфой".

WH>Почему так и откуда он берется, попробуй догадаться сам.

Ды ты бы вола бы за хвост не тянул и закрыли тему еще несколько месяцев назад.

WH>Ключевое слова альфабленд.

Гы, я думал интересно будет насчет преобразований м/у цветовыми пространставами, бо там много тонкостей. А ресэмплинг внутри одного пространства, в какой-нить ARGB — это детсад.

WH>Посмотри на формулу бленда пикселей с альфой. Она тебя очень сильно удивит.

Формула эта — простая линейная пропорция. Поэтому, чтобы сохранить статистику исходного изображения при ресэмплинге:
1. Изображение необходимо привести к линейной шкале, то бишь к гамме=1, а после преобразования вернуть гамму обратно.
2. Сам алгоритм ресэмплинга должен сохранять исходную статистику изображения.

Собственно ВСЁ.

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

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

)))
Ты еще дулю мне скрути и язык покажи. Еще больше полегчает.

V>>Ну дык, Сингулярити ограниченее, понятно. Ограничь бутылку, например, попроси у меня качественную реализацию межпотоковой очереди с элегантно решенной ABBA-проблемой
WH>Чего? Это название гуглиться не может.

ABA-problem не гуглится? А сейчас?

Судя по проблемам с преодолением описки, ты даже и не слышал о такой? Ох уж эти мне "на элементарщине сыпающиеся" (С).

V>>и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити.
WH>Это полный звездец.
WH>Ты действительно не понимаешь, что на бутылке сингулярити не сделать?

Делать надо

WH>Ты действительно не понимаешь, сколько возможностей для той же оптимизации дают изолированные процессы?

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

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

WH>Ты действительно не понимаешь, что на мониторах lockfree не получится?

Пока что видно, что это ты lock-free не понимаешь.

А по-делу — на мониторах нет, ес-но, а на interlocked-операциях из известного модуля — да.

V>>Про инсталлятор с верификатором говорил уже. Это же не ядро ОС, это просто запускаемое приложение. Это инфраструктура.
WH>Которой в бутылке нет. И сделать нельзя.
WH>Ибо изоляции всё равно нет.

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

V>>Разочарую, сами каналы создаются из глобальной кучи и регистрируются в глобальных же списках.
WH>Бред.
WH>Никакой глобальной кучи каналам не нужно.

И точно бред. Ес-но для самого канала — нужно. Для сообщений внутри канала можно обойтись уже локальным пулом.

WH>И уж точно ни в каких списках их регистрировать не нужно.

?????

WH>Откуда ты вообще эти списки придумал?

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

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

V>>Это от вида распространения привилегий в приложении зависит. Я говорю как раз о таком сценарии, где было бы неплохо, чтобы приложение работало под правами конкретного пользователя. Это просто обязательно при любом подключении на сервер с некоей точки удаленного доступа неважно по какому протоколу.
WH>Это можно сделать.
WH>Но не нужно.
WH>Ни одному приложению не нужны все права пользователя.
WH>Максимум что нужно БД это права на чтение/записаь в некоторые папки.

Файл архивации еще можно по всяким ресурсам отправлять, а у тех тоже свои права и политики. В общем, размахивать своим невежеством не стоило. Как это делается сейчас — я знаю. Что при этом происходит при определении конкретного набора разрешений — тоже. Но ты предложил вариант, который НЕ работает нигде, кроме в GUI локального пользователя. Ладно бы сболтнул случайно и успокоился, дык многократно настаивал. Это залет.

Это не максимум, это минимум Не БД, а пользователям.

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

А это уже юления после залета. А казалось бы, всего-то предложили пару сценариев использования.

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

Спорно АБСОЛЮТНО каждое словос т.з. современной безопасности. В реальности всегда требуется суперпозиция прав приложения и пользователя. Вот эти вот попытки упрощать закончились задолго до появления Юниксов.

V>>Придумаешь еще что-то покажу и там. В общем, я здесь скурпулёзно и последовательно перебираю аргументы технического плана,
WH>

При этом, не понимая, что тебе говорят.

Ну сейчас-то уже убедился, кто и чего не понимает? Всего-то 5-6 итераций мне понадобилось чтобы до тебя дошли все побочные эффекты предложенного сценария... какие мелочи, право.

V>>В этом подходе предлагается доверять сетевым ендпоинтам, наделяя соединения с ними теми же возможнстями/правами, как и локальные программы. Т.е. уже даже не надо патчить никакой код на атакуемой машине. Чтобы было понятно о чем речь: компьютерные сетевые картейки вообще никак не видят прозрачные ethernet-свичи.
WH>Ты опять с собой разговариваешь.

Не льсти себе.

WH>Никто не мешает установить защищённое соединение с защитой от MiM. И таких протоколов тьма.

Ты всьерьез решил попросить очередного лулза? А потом утверждать "я никогда не говорил что это единственный способ." (С).
Предлагаю вместо 5-6 итераций один раз тебе помедитировать над исходными условиями.

WH>Это в любом случае нужно, если ты собираешься обеспечить безопасность.

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

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

Я же говорю, вы, ребятки, кормите лулзами похлеще иных домохозяек.

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

V>>>>Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.
WH>>>Бред.
V>>Предлагаю не отмахиваться от этого вопроса, он интересен.
WH>Абсолютно не интересен, любому у кого есть хоть капля воображения.

V>>Согласно репорту Сингулярити, при инсталяции драйвера создается его некий манифест, который указывает ресурсы, к которым можно обращаться этому драйверу. Если целевой драйвер работает с другим драйвером-посредником, то вот ситуация — эти ресурсы (например, для окна DMA) он должен получать динамически. Но верификатор Сингулярити такой код не пропустит, т.е. не подзволит читать/писать произвольную память. Остается передавать непосредственно данные посреднику, чтобы тот их закачивал в DMA. А это не взлетит для видео однозначно. Или есть еще третий вариант?
WH>Что такое закачать в ДМА?
WH>Правильно.
WH>Записать данные в страницу памяти.
WH>И сказать ДМА, где их брать.

WH>Что мы и делаем.
WH>После чего отдаем эти страницы кому надо.
WH>И он без единого копирования говорит, кому надо, где брать данные.

WH>Мы эти страницы даже в пользовательском коде заполнить можем.
WH>И все будет точно так же.

Мде... зато с каким апломбом....
1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.

WH>Кстати IOMMU на данную модель натягивается почти автоматически.

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

V>>А могут и нет, если поле атомарного типа (машинное слово). Что мешает выяснять эти моменты верификатором, например, если некий объект забыли пометить как синхронизируемый, но к нему могут идти вызовы более чем от одного активного или несинхронизируемого объекта (в т.ч. в произвольных сочетаниях)?
WH>

Не работает. Теоритически. Ибо можно новые модули загружать.

Все зависимости статические.

V>>Даже для сложного С++ Valgrind находит такие вещи на раз, а уж для простейшего байткода сам бог велел.
WH>

Статически? В условиях загрузки новых модулей?

Да.

V>>Я тебя уже поправлял: единица изоляции там — это приватная память объекта. Активный Объект — это и есть процесс. И ты никак не можешь эту изоляцию нарушить через голову публичного АПИ объекта.
WH>БРЕД!
WH>Ибо ссылки на внутренние объекты могут быть беспрепятственно сохранены, где попало.

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

V>>Если тебя лично напрягают глобальные переменные в модулях — это твои предрассудки. Модуль — это всего-лишь синглтон, это полный аналог обычного объекта, который заведомо будет существовать в единственном экземпляре в любой операционке, даже в Сингулярити.
WH>Бред.
WH>В бутылке модуль глобален на всю ОС.

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

V>>Как пример — список сетевых интерфейсов. И какая фиг разница, явно передавать ссылку на такой синглтон каждый раз, или обойтись одним уровнем косвенности меньше, воспользовавшись услугами загрузчика по ресолвингу имен?
WH>Какой феерический бред.
WH>Ты про безопасность системы вообще не думаешь.
WH>Так делать нельзя.
WH>Никогда.

Ну так с тем же успехом можно подменять модули в GAC. Насколько это реально?
И твоё "нельзя" — это на типонебезопасных языках нельзя, а если происходящее детерминировано, то можно.

WH>>>В сингулярити изоляция обеспечивается моделью исполнения.
V>>Тут не про изоляцию, а про безопасный для исполнения код.
WH>Без изоляции это невозможно.

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

V>>А насчет модели исполнения — экземпляры объектов полностью изолированы.
WH>Бред.

-1

WH>Ты что действительно не понимаешь, что в сингулярити для каждого процесса есть свое объектное пространство?

Я не вижу в этом особых преимуществ, если мы договорились, кто код безопасен сам по себе. Все-равно все объекты в одной плоской памяти, а пространство объектов — сугубо логическое. И еще. Для твоей изоляции требуется специальный дорогой инструмент обслуживания этой изоляции.. И оп-па — на сцену выходят каналы. Это же компромисс получился, если посмотреть на всю композицию в целом. Если бы ты хоть немного поработал с lock-free, понял бы, почему я на твои каналы смотрю без энтузиазма. Существуют механизмы передачи информации/сигналов многократно дешевле, в десятки и больше раз.

WH>Что не могут существовать ссылки из одного процесса в другой?
WH>И что оберон никак от этого не защищает?

Ссылки возможны только при явных зависимостях. Никаких ссылок, типа как на безтиповый Object в дотнете быть не может.

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

WH>Модель сингулярити не мешает ввести и другие примитивы общения без нарушения изоляции процессов.

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

V>>Я бы предпочел, чтобы были доступны оба варианта, а за безопасностью следил верификатор.
WH>Бред.
WH>Не бывает таких верификаторов.

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

WH>Особенно в условиях динамической загрузки кода.

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

V>>Кстати, для встроенной реализации каналов даже язык толком расширять не придется. Если помнишь, в Паскале файл — это не файл на диске, это порт последовательного доступа к типизированным кортежам. А за ним может быть что угодно.
WH>Бред.
WH>Необходимы поддержка уникальных ссылок и проверка протоколов.

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

V>>Ладно, пошли механические ответы, уже не интересно. Спасибо за участие.
WH>Если бы ты еще мог понять, что они означают.

Если бы ты еще не вредничал в каждом предложении, как старая жена, было бы вообще идеально.

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

V>Мде... зато с каким апломбом....
Мде... зато с каким апломбом....

V>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
Можно пример?

А то в Линуксе, идиоты такие, смогли как-то сделать общую систему поддержки DMA с поддержкой IOMMU для x86 и ARM (с его странными требованиями когерентности). Никакой зависимости от "драйверов конкретных чипсетов" нет и в помине.

V>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
Мимо.

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

>> Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?

G>Имхо 95% всех вопросов или даже больше решить можно организационно, на верхнем уровне изоляции. Схема: совместно используемое оборудование (почти) без состояний. Полностью изолированные разделы:
G> — игры (опасный)
G> — хрень (опасный)
G> — работа (безопасный)
G> — пароли, явки (безопасный)
G> — еще какая-нибудь хрень (безопасный)

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

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

ARK>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

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

V>>Давай мы сначала разберемся с OCaml. А то вы меня забодали тыкать одной и той же, вполне справедливой фразой. В отличие от Оберона, у тебя и возможности-то не будет узнать про зависимость от модуля Obj в конечном образе. А в Обероне можно явно запретить загрузку модуля с такой зависимостью.
C>Нельзя. Я могу в бинарном коде написать "cli; hlt" без всяких зависимостей от SYSTEM. И всё, стоп-система.

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

C>Так как бинарный код в Обероне никоим образом не проверяется.

Байткод загружается через JIT и что-то там проверяется. Насчет глубины проверки утверждать не буду, в 80-90-х годах акценты/задачи по-другому формулировались.

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

ARK>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению.

Заметь, для этого не потребовалось переписать всю ОС. Нужен просто специальный загрузчик, который при связывании создает "умные переходники" к системным ф-ям. Подобными хуками под винду я тоже когда-то баловался. Не знаю как в iOS, а сверху виндов написать такую систему можно даже самому.

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

V>>Первые два пункта. Т.е. то, что относится сугубо к языку. Среда исполнения контроллеру не нужна. Потому что не нужно динамическое управление ресурсами. Это важный аспект, предлагаю помедитировать — а нахрена вообще нужны какие-то там среды исполнения? Какую именно задачу они берут на себя?

M>Суммируем:

M>В чем гордость, брат? ©

Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

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

C>>Нельзя. Я могу в бинарном коде написать "cli; hlt" без всяких зависимостей от SYSTEM. И всё, стоп-система.
V>В обесуждаемой AOS не можешь. Там байткод у всех модулей, причем, байткод этот детерминированный и безопасный. А модуль SYSTEM — это псевдо-модуль, его нет. Это на самом деле не классический модуль, а низкоуровневое АПИ ОС, доступ к которому дается через такой же интерфейс модулей.
Таки AOS — это галимый тормозной байт-код, значит? Через 40 лет после появления P-Code? Ну и где инновации?

C>>Так как бинарный код в Обероне никоим образом не проверяется
V>Байткод загружается через JIT и что-то там проверяется. Насчет глубины проверки утверждать не буду, в 80-90-х годах акценты/задачи по-другому формулировались.
Так, а где новизна и промышленность и всё такое?

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

V>А это уже юления после залета. А казалось бы, всего-то предложили пару сценариев использования.
Нет. Это ты пытаешься убедить себя что что-то понимаешь.

V>Спорно АБСОЛЮТНО каждое словос т.з. современной безопасности. В реальности всегда требуется суперпозиция прав приложения и пользователя. Вот эти вот попытки упрощать закончились задолго до появления Юниксов.
Опять бредишь.
Разговор начинался с офиса и фотошопа.
Им OpenFileDialog за глаза.
Игрушкам даже он не нужен.

Что у нас еще остается на десктопе?
Да ничего.

А на серверах ясен хрен нужен другой подход к раздачи привилегий.

V>Ну сейчас-то уже убедился, кто и чего не понимает? Всего-то 5-6 итераций мне понадобилось чтобы до тебя дошли все побочные эффекты предложенного сценария... какие мелочи, право.
Ты конечно.

WH>>Никто не мешает установить защищённое соединение с защитой от MiM. И таких протоколов тьма.
V>Ты всьерьез решил попросить очередного лулза? А потом утверждать "я никогда не говорил что это единственный способ." (С).
V>Предлагаю вместо 5-6 итераций один раз тебе помедитировать над исходными условиями.
А что над ними медитировать то?
Если у нас защищенное соединение с защитой от MiM то мы можем верить этому соединению как тому пользователю от имени, которого оно установлено.

V>Это уже совсем другой уровень безопасности. Если ты до этого всячески настаивал на безопасности и закрыточти машины от прониктовения — то это ровно противоположная идеология: машины открыты для проникновения (это банально удобно для работы), но защита пытается выстроиться на уровне сети. Ты вообще понимаешь, насколько это далекий от обсуждаемого подход? В этом случае характеристики конкретных операционок на ендпоинтах вообще не играют рояли. Я же тебе скзаал — Кайберакс подложил тебе свинью, закатав всю твою теорию под асфальт.
Что-то чем дальше, тем бредовее.
И никогда ничего про закрытость машины не говорил.
Наоборот.
Я говорил про то что на машину можно ставить что попало.
Лишь бы этому чему попало лишних привилегий не давать.

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

V>И да, на самом деле это то, о чемя говорил с самого начала — что если речь о злонамерениях, то ключевая инфраструктура. Ты спрорил до соплей, а теперь, ради согласшения с одним из участников, который на твоей стороне конкретно здесь и сейчас, подписался под каждым моим словом, оспоренным тобой раньше.
Ты опять бредишь. И пытаешься съехать с темы.
Изначально разговор был про приложения.
И про то, что согласно твоей вере нужно сертифицировать 100% приложений.
Иначе все развалится.

Но ты нашёл аж ДВА драйвера и ядро ОС, которые нужно сертифицировать.
Весь остальной софт будет прекрасно жить без этого.

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

V>Да еще с таким присущим тебе последние нескоолько лет твоей недолгой жизни апломбом.
Чья бы корова...

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

ARK>Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

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

ARK>>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

ARK>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

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

V>Давай мы сначала разберемся с OCaml. А то вы меня забодали тыкать одной и той же, вполне справедливой фразой. В отличие от Оберона, у тебя и возможности-то не будет узнать про зависимость от модуля Obj в конечном образе. А в Обероне можно явно запретить загрузку модуля с такой зависимостью.
Те вся разница в том чтобы научить, компилятор OCaml'а выставлять в бинарнике флаг, что там опасный модуль используется?
После чего OCaml сразу становится супертипизированным?

V>Да бери любые транзакции из EDIFACT X12.
Нет, ты конкретную грамматику давай.

V>GLR хоть и разбирает любую контекстно-свободную грамматику, но для более сложных, т.е. неоднозначных в рамках контектсно-свободных, он в конце разбора выдает ВСЕ варианты. Причем, эти варианты хранятся компактно, без избыточности.
И что толку?
Если мне всё равно их потом нужно руками анализировать?

Это я еще про восстановление после ошибок говорить не начинал.

V>Отличие от нисходящих парсеров с откатами в том, что парсеры с откатами в случае неоднозначностей грамматики имеют склонность вечно зацикливаться.
Бред.

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

V>GLR даст все возможные корректные ветки разбора. Ес-но, приведенный отрезок не парсится ни одним контекстно-свободным парсером, даже TDOP. Но TDOP будет безбожно врать на этом примере, т.к. он разбирает первую попавшуюся ветку, как и ПЕГ, а GLR честно предоставит все варианты. А потом эти варианты уже ресолвятся решателем на основе программирования в ограничениях.
Другими словами ГЛР тоже ничего не разберет.
А заставит ручками разбираться что произошло.
При это нисходящим парсерам можно спокойно добавить таблицу имен, и они волшебным образом начинают разбирать такой код.

V>Любой разберет с таблицей, твой парсер тут не при чем. Я же эту технику и показывал для С++, как неоднозначности сводятся к однозначностям. Но это такой язык, где необязательно объявление идет впереди использования, а если нет, то TDOP парсер для таких сценариев вообще самый худший вариант.
Что за бред?
С++ так не умеет.

V>Я когда-то пытался донести до вас мысль, что TDOP — это всего лишь один из алгоритмов парсинга. Ну чтобы вы поднялись чуть над темой и не считали никакой конкретный реализованный алгоритм за панацею. Потому что панацеи нет.
То-то ты GLR во все щели толкаешь.

V>Ды ты бы вола бы за хвост не тянул и закрыли тему еще несколько месяцев назад.
Я тебе просто показываю, как ты общаешься.

V>Гы, я думал интересно будет насчет преобразований м/у цветовыми пространставами, бо там много тонкостей. А ресэмплинг внутри одного пространства, в какой-нить ARGB — это детсад.
Но ты не знаешь, как он работает.
Иначе ты бы сразу понял, что не так с той картинкой.

V>Формула эта — простая линейная пропорция.
Не правильно.

V>Поэтому, чтобы сохранить статистику исходного изображения при ресэмплинге:
V>1. Изображение необходимо привести к линейной шкале, то бишь к гамме=1, а после преобразования вернуть гамму обратно.
V>2. Сам алгоритм ресэмплинга должен сохранять исходную статистику изображения.
Это правильно.

V>Собственно ВСЁ.
Нет не все.
Почему попробуй догадаться сам.

V>ABA-problem не гуглится? А сейчас?

V>Судя по проблемам с преодолением описки, ты даже и не слышал о такой? Ох уж эти мне "на элементарщине сыпающиеся" (С).
1)Знаю я про это. Просто названия плохо запоминаю.
2)В каналах сингулярити такой проблемы нет благодоря дизайну этих самых каналов.
И кто тут сыпется на элементарщине?

V>>>и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити.
WH>>Это полный звездец.
WH>>Ты действительно не понимаешь, что на бутылке сингулярити не сделать?
V>Делать надо
Ну да.
Выкинуть все. И написать с нуля. Правильно.
А нет, так как написано.

WH>>Ты действительно не понимаешь, сколько возможностей для той же оптимизации дают изолированные процессы?
V>Я уже одергивал тебя от таких обобщений. Связь через каналы — дорогое удовольствие само по себе, не самый лучший вариант для многих сценариев.
Так можно и без каналов. Не нарушая изоляции процессов.

V>И уже где-то пощупать эти гипотетические оптимизации можно?
В сингулярити.

V>Есть такое, в реальном мире я оптимизирую через локальные вычисления, то бишь загружаю из памяти в локальные переменные, числодроблю и выгружаю обратно.
Это опять не в тему.

WH>>Ты действительно не понимаешь, что на мониторах lockfree не получится?
V>Пока что видно, что это ты lock-free не понимаешь.
Реализация локфрии на локах. Интересно.

V>Яуже начинаю тебя подозревать в том, что ты вызов метода объекта пытаешься отличать от посылки ему сообщения. И вся твоя изоляция держиться только на это разнице. Это надуманно. Политику синхронизации определяет вызваемый ресурс. Если он помечен, как синхронизируемый, никакой внешний код не вызовет его в несинхронизируемом виде.
Ну что за бред ты несешь. Переставай за меня думать. У тебя не получается.
Запомни: я всегда очень буквален. И когда я говорю, кури альфабленд. Ты должен курить альфабленд. Ибо ты его не понимаешь.
Короче до тех пор, пока ты мне не покажешь, как в сингулярити передать ссылку на объект из одного процесса в другой записываю тебя в безответственные бредогенераторы.

В обероне это делается на раз.
После чего по этому объекту начинаются гонки.
Да и не на всех архитектурах запись/чтение указателя атомарны.

V>Оттуда же, откуда списки процессов и остальных ресурсов. Каналы закрываются "сами", даже если процесс прибит насильно. Потому что он принадлежт операционной системе и она имеет на него ссылку. Исходники Сингулярити есть? Я в них не смотрел, но могу на этот момент поспорить.
Бред.
Каналы абсолютно пассивны и полностью автономны.
И убивают их процессы во время собственной смерти.
Таким образом, глобального списка каналов не существует.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

WH>Разговор начинался с офиса и фотошопа.
WH>Им OpenFileDialog за глаза.
WH>Игрушкам даже он не нужен.

WH>Что у нас еще остается на десктопе?
WH>Да ничего.

WH>А на серверах ясен хрен нужен другой подход к раздачи привилегий.

Да даже там, по большому счету, этот подход мало отличается от OpenFileDialog, если так подумать

Может, только более гранулярно, но и то.

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

V>>Если тебя лично напрягают глобальные переменные в модулях — это твои предрассудки. Модуль — это всего-лишь синглтон, это полный аналог обычного объекта, который заведомо будет существовать в единственном экземпляре в любой операционке, даже в Сингулярити.
WH>Бред.
WH>В бутылке модуль глобален на всю ОС.
WH>В сингулярити на процесс.
WH>Хотя я бы их вообще отменил.
WH>Не нужны они.

Э... Модули не нужны? А как без них, код где будет лежать? К примеру, по сути в дотнете assembly — это модуль.

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

ARK>>Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

M>Это не мы прицепились, это защитники Оберона его преподносят то как панацею, то как первый в мире, то как самый супер-пупер-лучший язык, с которого все и вся все слизали и т.п. Что, естественно, вызывает отторжение, так как действительности соответсвует мало.

Ну прям не супер-пупер, конечно. Но и не так плох, как некоторые его тут малюют.

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

А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...

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

ARK>>>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>>>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

ARK>>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

M>Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

Если на Обероне, то точно без модуля System.

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

ARK>>>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

M>>Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

ARK>Если на Обероне, то точно без модуля System.

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

А что сама песочница? Как показывают примеры Chrome и той же iOS, песочница вполне себе может писаться на C/C++

Взломов что одной, что другой песочницы предельно мало.

M>>Это не мы прицепились, это защитники Оберона его преподносят то как панацею, то как первый в мире, то как самый супер-пупер-лучший язык, с которого все и вся все слизали и т.п. Что, естественно, вызывает отторжение, так как действительности соответсвует мало.

ARK>Ну прям не супер-пупер, конечно. Но и не так плох, как некоторые его тут малюют.

Сам Оберон, как язык, достаточно примитивен, и интереса из себя не представляет — кроме как для использования там, где нужны достаточно примитивные языки со строгой статической типизацией. ОСи/среды на нем/для него написанные, интереса все так же не представляют. Может, на конец 90-х они могли быть хоть сколько-нибудь интересны, но сейчас они неинтересны совсем.

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

А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...

Ага

Ну, РСДН этому способствует.

Кстати. Обнаружил на вики гениальное:

http://en.wikipedia.org/wiki/Modula-2

The [Modula-2] language design was also influenced by the Mesa programming language

http://en.wikipedia.org/wiki/Mesa_programming_language

Mesa was an innovative programming language developed in the late 1970s... Mesa is an ALGOL-like language with strong support for modular programming. To use a library, a program or higher-level library must "import" the definitions. The Mesa compiler type-checks all uses of imported entities; this combination of separate compilation with type-checking was unusual at the time.

Mesa introduced several other innovations in language design and implementation, notably in the handling of software exceptions, thread synchronization, incremental compilation, and more.

Mesa had a major influence on the design of other important languages, such as Modula-2 and Java

Но, как мы знаем, все это неправда, и впервые появилось только и исключительно в Обероне

И на Java повлиял только и исключительно Оберон, другие языки на нее не влияли

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

V>Мде...
ЧТо конкретно?

V>зато с каким апломбом....
У тебя учусь.

V>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
Пример в студию.

V>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
Ну да. Без IOMMU все печально.
С IOMMU все хорошо.

WH>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
Что за бред?
Какие еще адреса страниц в манифесте?

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

V>И код не подлежит верификации и сравнения с манифестами, т.к. код получает неизветсные на этапе компиляции цифры и настраивает ими контроллер DMA. Мне казалось, что такое нарушение очевидно. Ан нет... )))
Это очередной твой бред.

V>>>Я тебя уже поправлял: единица изоляции там — это приватная память объекта. Активный Объект — это и есть процесс. И ты никак не можешь эту изоляцию нарушить через голову публичного АПИ объекта.
WH>>БРЕД!
WH>>Ибо ссылки на внутренние объекты могут быть беспрепятственно сохранены, где попало.
V>Если на внутренние — то только внутри и могут,
И что же мне помешает передать ее в другой объект?
Оберон этому никак не препятствует.

V>Ну так с тем же успехом можно подменять модули в GAC. Насколько это реально?
Перестань говорить сам с собой.
ГАК тут вообще не причем.

V>И твоё "нельзя" — это на типонебезопасных языках нельзя, а если происходящее детерминировано, то можно.
Ни на каких нельзя.

V>ХЗ. Я под безопасностью имел ввиду какие-нить переполнения, выходы индексов за пределы массива и т.д. Без изоляции можно писать очень эффективные системы. Нафига, например, корабельной навигационной системе изоляция процессов. Поясни.
Ох. Ты даже не понимаешь, про какую изоляцию я говорю.
А говорю не про аппаратную защиту памяти. А про логическую изоляцию процессов на уровне системы типов.

V>>>А насчет модели исполнения — экземпляры объектов полностью изолированы.
WH>>Бред.
V>-1
Оберон не знаешь.

WH>>Ты что действительно не понимаешь, что в сингулярити для каждого процесса есть свое объектное пространство?
V>Я не вижу в этом особых преимуществ, если мы договорились, кто код безопасен сам по себе.
Ну да. Возможность грохнуть зажравшийся процесс, а не всю ОС фигня.
Гарантии того что нет гонок фигня.
Все фигня. Один vdimas умный.

V>Все-равно все объекты в одной плоской памяти, а пространство объектов — сугубо логическое. И еще. Для твоей изоляции требуется специальный дорогой инструмент обслуживания этой изоляции.. И оп-па — на сцену выходят каналы. Это же компромисс получился, если посмотреть на всю композицию в целом. Если бы ты хоть немного поработал с lock-free, понял бы, почему я на твои каналы смотрю без энтузиазма. Существуют механизмы передачи информации/сигналов многократно дешевле, в десятки и больше раз.
Которые можно реализовать, не нарушая изоляцию процессов.

WH>>Что не могут существовать ссылки из одного процесса в другой?
WH>>И что оберон никак от этого не защищает?
V>Ссылки возможны только при явных зависимостях.
Но они могут быть.
И гонки могут быть.
И вот такой код может быть. http://www.rsdn.ru/forum/philosophy/1004226.1.aspx

V>Никаких ссылок, типа как на безтиповый Object в дотнете быть не может.
Это вообще к делу не относится.

V>Без нарушения изоляции не обойтись
Еще как.

V>без посредников, то бишь без копий нужной инфрмации.
Это снова бред.

V>И здесь дорого всё: создание копий, помещение в очередь,
И снова...

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

V>Valgrind. Погоняй на досуге, очень рекомендую. А казалось бы — для опасных языков предназначен. Юоюсь предоложить во сколко раз будет проще для безопасных.
Гонял. Мышей кроме самых примитивных не ловит.
А мне нужны гарантии, что всё хорошо.
Понимаешь? ГАРАНТИИ!

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

V>Проверка протоколов — это уже высокоуровневые плюшки.
Это плюшка, которая необходима для работы.

V>А поддержка уникальных ссылок в паскалях всегда была изкаробки.
Что за бред.
Паскаль ты не знаешь.
Не было там никогда уникальных типов.

V>Он сам разбирается в процессе анализа при компиляции, где ему создать копию, а где переиспользовать имеющиеся данные. И да, CONST там все-таки ввели, это одна из гарантий для вызываемого метода.
Это все вообще не о том.

V>Если бы ты еще не вредничал в каждом предложении, как старая жена, было бы вообще идеально.
Нехрен на зеркало пенять.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ARK>Э... Модули не нужны? А как без них, код где будет лежать? К примеру, по сути в дотнете assembly — это модуль.
В бутылке к модулю прибиты статические переменные.
И они глобальные на всю ОСь.
Одни и те же переменные для всех юзеров, гостей и админов.
Прикинь.
Безопасности нет.
Хотя куда там. Два пользователя одновременно работать и то не могут.
Да даже один пользователь две копии одной программы запустить не может.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...

M>Ага

Ну, РСДН этому способствует.
Это я пофиксил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>А что сама песочница? Как показывают примеры Chrome и той же iOS, песочница вполне себе может писаться на C/C++

Взломов что одной, что другой песочницы предельно мало.

Может-то может... но дыры там есть, они просто ждут своего часа.

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

M>Сам Оберон, как язык, достаточно примитивен, и интереса из себя не представляет — кроме как для использования там, где нужны достаточно примитивные языки со строгой статической типизацией. ОСи/среды на нем/для него написанные, интереса все так же не представляют. Может, на конец 90-х они могли быть хоть сколько-нибудь интересны, но сейчас они неинтересны совсем.

Ну, тогда С еще более примитивен. Да и Java тоже... того... не особо продвинута.

А интерес для народа, боюсь, обычно представляет то, куда вкладывается бабло.

M>Кстати. Обнаружил на вики гениальное:
M>

M>http://en.wikipedia.org/wiki/Modula-2

M>The [Modula-2] language design was also influenced by the Mesa programming language

M>http://en.wikipedia.org/wiki/Mesa_programming_language

M>Mesa was an innovative programming language developed in the late 1970s... Mesa is an ALGOL-like language with strong support for modular programming. To use a library, a program or higher-level library must "import" the definitions. The Mesa compiler type-checks all uses of imported entities; this combination of separate compilation with type-checking was unusual at the time.

M>Mesa introduced several other innovations in language design and implementation, notably in the handling of software exceptions, thread synchronization, incremental compilation, and more.

M>Mesa had a major influence on the design of other important languages, such as Modula-2 and Java

M>Но, как мы знаем, все это неправда, и впервые появилось только и исключительно в Обероне

И на Java повлиял только и исключительно Оберон, другие языки на нее не влияли

Ну да, про систему MESA известно, что она сильно повлияла на Модулу. Вирт тогда ездил в какую-то академическую командировку в США и работал в институте, где сделали MESA. Правда, я смотрел MESA language report, язык показался каким-то корявым. Неудивительно, что он остался чисто академическим проектом, Modula-Oberon гораздо доступнее.

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

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

ARK>>Э... Модули не нужны? А как без них, код где будет лежать? К примеру, по сути в дотнете assembly — это модуль.
WH>В бутылке к модулю прибиты статические переменные.
WH>И они глобальные на всю ОСь.
WH>Одни и те же переменные для всех юзеров, гостей и админов.

А, ну т.е. модули без глобальных переменных не отменяются? Тогда нормально.

WH>Хотя куда там. Два пользователя одновременно работать и то не могут.
WH>Да даже один пользователь две копии одной программы запустить не может.

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

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

ARK>А, ну т.е. модули без глобальных переменных не отменяются? Тогда нормально.

Только только от них нет ни какого.

ARK>Ну это издержки проекта. Его вроде писали 2 с половиной человека, причем не полный рабочий день. Для таких ресурсов результат довольно впечатляющий. Конечно, ежели по уму делать, глобальные переменные надо делать на один процесс, а лучше вообще убрать.
Ты не понял.
Это не по тому, что они не смогли сделать иначе.
Это по тому, что они считают это правильным.
Это их идеология.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

C>В Обероне нет:
C>1) Алгебраических типов и Pattern Matching
C>3) Макросистемы
C>4) Зависимых типов
C>5) Typeset'ов
C>...
C>Это унылое дерьмо мамонта из 80-х годов.

а оно надо?

я из всего перечисленного использую только
C>2) Generic'ов — реально необходимая вещь

а про остальное даже не знаю )

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

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

ARK>>А, ну т.е. модули без глобальных переменных не отменяются? Тогда нормально.

WH>Только только от них нет ни какого.

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

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

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

C>>В Обероне нет:
C>>1) Алгебраических типов и Pattern Matching
C>>3) Макросистемы
C>>4) Зависимых типов
C>>5) Typeset'ов
C>>...
C>>Это унылое дерьмо мамонта из 80-х годов.

Ф>а оно надо?

Ф>я из всего перечисленного использую только
C>>2) Generic'ов — реально необходимая вещь

Ф>а про остальное даже не знаю )

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

А пункты 3, 4, 5 вообще есть мало где.

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

ARK>Тогда я не понимаю — предлагается убрать модули совсем? А что вместо них, какие-то структурные единицы должны быть для хранения того же байт-кода?
Вся идеология оберона построена на том, что у модуля есть состояние.
Которое лежит в переменных модуля.
Расширяется система путем загрузки новых модулей со своим состоянием.
Те модули без состояние в инфраструктуре оберона практически бесполезны.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ARK>>Тогда я не понимаю — предлагается убрать модули совсем? А что вместо них, какие-то структурные единицы должны быть для хранения того же байт-кода?
WH>Вся идеология оберона построена на том, что у модуля есть состояние.
WH>Которое лежит в переменных модуля.
WH>Расширяется система путем загрузки новых модулей со своим состоянием.
WH>Те модули без состояние в инфраструктуре оберона практически бесполезны.

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

M>>Сам Оберон, как язык, достаточно примитивен, и интереса из себя не представляет — кроме как для использования там, где нужны достаточно примитивные языки со строгой статической типизацией. ОСи/среды на нем/для него написанные, интереса все так же не представляют. Может, на конец 90-х они могли быть хоть сколько-нибудь интересны, но сейчас они неинтересны совсем.

ARK>Ну, тогда С еще более примитивен. Да и Java тоже... того... не особо продвинута.

ARK>А интерес для народа, боюсь, обычно представляет то, куда вкладывается бабло.

Неверно. Расскажи, какое бабло было вложено в Ruby, Python и PHP, например?

M>>Но, как мы знаем, все это неправда, и впервые появилось только и исключительно в Обероне

И на Java повлиял только и исключительно Оберон, другие языки на нее не влияли

ARK>Ну да, про систему MESA известно, что она сильно повлияла на Модулу.
ARK>Вирт тогда ездил в какую-то академическую командировку в США и работал в институте, где сделали MESA. Правда, я смотрел MESA language report, язык показался каким-то корявым. Неудивительно, что он остался чисто академическим проектом, Modula-Oberon гораздо доступнее.

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

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

M>>>Сам Оберон, как язык, достаточно примитивен, и интереса из себя не представляет — кроме как для использования там, где нужны достаточно примитивные языки со строгой статической типизацией. ОСи/среды на нем/для него написанные, интереса все так же не представляют. Может, на конец 90-х они могли быть хоть сколько-нибудь интересны, но сейчас они неинтересны совсем.

ARK>>Ну, тогда С еще более примитивен. Да и Java тоже... того... не особо продвинута.

ARK>>А интерес для народа, боюсь, обычно представляет то, куда вкладывается бабло.

M>Неверно. Расскажи, какое бабло было вложено в Ruby, Python и PHP, например?

Я написал "обычно". Да и тут вопрос спорный. Питон, по-моему, никто толком и не знал, пока его гугль не взял под крыло.

M>>>Но, как мы знаем, все это неправда, и впервые появилось только и исключительно в Обероне

И на Java повлиял только и исключительно Оберон, другие языки на нее не влияли

ARK>>Ну да, про систему MESA известно, что она сильно повлияла на Модулу.
ARK>>Вирт тогда ездил в какую-то академическую командировку в США и работал в институте, где сделали MESA. Правда, я смотрел MESA language report, язык показался каким-то корявым. Неудивительно, что он остался чисто академическим проектом, Modula-Oberon гораздо доступнее.

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

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

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

Что характерно — ни на один из заданных вопросов ты так и не ответил. Зато навалил кучу бессвязного и слабо относящегося по теме флейма. Шеридан №2.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

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

C>>>Нельзя. Я могу в бинарном коде написать "cli; hlt" без всяких зависимостей от SYSTEM. И всё, стоп-система.
V>>В обесуждаемой AOS не можешь. Там байткод у всех модулей, причем, байткод этот детерминированный и безопасный. А модуль SYSTEM — это псевдо-модуль, его нет. Это на самом деле не классический модуль, а низкоуровневое АПИ ОС, доступ к которому дается через такой же интерфейс модулей.
C>Таки AOS — это галимый тормозной байт-код, значит? Через 40 лет после появления P-Code? Ну и где инновации?

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

Модули при загрузке переводятся в рельный код конкретной архитектуры, сейчас это называется JIT. Помимо этого есть нейтивные Обероны. У них своя ниша. Я почему и напираю на то, что всё это не так просто, как вы тут пытались изобразить. Потому что уже в 80-х годах работал асинхронный GC по нейтивному коду. Этот момент до сих пор еще предмет активного исследования. Даже тупой до безобразия код, порождаемый сегодня JIT дотнета, имеет своей тупизной природу асинхронного GC, чтобы тот банально умел ставить во взаимное соответствие значения регистров железного процессора и состояние стека вычислений исходной VM.

Ну и малыми силами была разработана надежная операционка. Сравнивать по степени надежности другие популярные операционки того времени, типа Юниксов или 2-х Виндов — это было даже не смешно.

C>>>Так как бинарный код в Обероне никоим образом не проверяется
V>>Байткод загружается через JIT и что-то там проверяется. Насчет глубины проверки утверждать не буду, в 80-90-х годах акценты/задачи по-другому формулировались.
C>Так, а где новизна и промышленность и всё такое?

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

ЧТД.

Я вообще вижу по другим топикам, что сверхубогий язык и одна из самых тупыейших в природе сред исполнения Java у тебя нареканий не вызывают, скорее наборот. А ОС для домохозяек от программирования — Андроид, где все эти эффекты гипертрофированы до безобразия, тем более... Брр... Сорри, но по мне это натуральный подход леммингов: где больше халявных библиотек, там им и комфортно.

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

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

WH>Те вся разница в том чтобы научить, компилятор OCaml'а выставлять в бинарнике флаг, что там опасный модуль используется?
WH>После чего OCaml сразу становится супертипизированным?

Если еще все либы без этого модуля перепишешь. В общем, это ты на полвопроса ответил. Вопрос звучал так: Оберону надо садиться на аппаратаное прерывания и прочие DMA, потому что операционка, а вот зачем такой модуль в OCaml — непонятно.

V>>Да бери любые транзакции из EDIFACT X12.
WH>Нет, ты конкретную грамматику давай.

Ну ок, вот интересная транзакция, X12 271.
Небольшая, но показывающая всю убогость парсеров с откатами для определенных сценариев.

V>>GLR хоть и разбирает любую контекстно-свободную грамматику, но для более сложных, т.е. неоднозначных в рамках контектсно-свободных, он в конце разбора выдает ВСЕ варианты. Причем, эти варианты хранятся компактно, без избыточности.
WH>И что толку?
WH>Если мне всё равно их потом нужно руками анализировать?

Зачем руками. Программирование в ограничениях. Вывод типов как, по твоему работает? Это точно такая же задача — найти решение при наличии фактов и правил.

WH>Это я еще про восстановление после ошибок говорить не начинал.

А ты начни. GLR может порекомендовать правильные конструкции в месте ошибки, в отличии от LL(k), который тоже может порекомендовать, ес-но, правда на порядок большее их мн-во. ))

V>>Отличие от нисходящих парсеров с откатами в том, что парсеры с откатами в случае неоднозначностей грамматики имеют склонность вечно зацикливаться.
WH>Бред.

Это медицинский факт для нисходящего разбора в случае некоторых неоднозначностей, приводящих к левой рекурсии. Именно исходная неоднозначность грамматики может не дать её полностью факторизовать. Поэтому-то я не люблю LL(k) для неоднозначных грамматик, что в таких случаях в LL(K) надо описывать не целевую грамматику, а некую промежуточную. А потом действительно, ручками и только ручками переводить промежуточную в целевую.

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

Но не в координатах КС-разбора.

V>>GLR даст все возможные корректные ветки разбора. Ес-но, приведенный отрезок не парсится ни одним контекстно-свободным парсером, даже TDOP. Но TDOP будет безбожно врать на этом примере, т.к. он разбирает первую попавшуюся ветку, как и ПЕГ, а GLR честно предоставит все варианты. А потом эти варианты уже ресолвятся решателем на основе программирования в ограничениях.
WH>Другими словами ГЛР тоже ничего не разберет.
WH>А заставит ручками разбираться что произошло.
WH>При это нисходящим парсерам можно спокойно добавить таблицу имен, и они волшебным образом начинают разбирать такой код.

Не начнут. Про С/С++ уже обсуждали. У него идет предварительное объявление типов именно чтобы "спокойно добавить таблицу имен". Блин, но это же 70-е года, мало памяти и однопроходность парсера... Сейчас-то всё тоже самое можно на GLR без предварительного объявления типов. Просто каждый встреченный символ будет отбрасывать ранее сохраненные неоднозначности. И что характерно — опять же оперативным образом, то бишь не накапливая ненужную информацию.

V>>Любой разберет с таблицей, твой парсер тут не при чем. Я же эту технику и показывал для С++, как неоднозначности сводятся к однозначностям. Но это такой язык, где необязательно объявление идет впереди использования, а если нет, то TDOP парсер для таких сценариев вообще самый худший вариант.
WH>Что за бред?
WH>С++ так не умеет.

Конкретно С++ нет. Но можно нарисовать язык с таким же точно синтаксисом, но без требования предварительного объявления типов, то бишь без #include, с моделью компиляции навроде C#. Как раз отличный вариант, чтобы показать затык для парсеров с откатами.

V>>Я когда-то пытался донести до вас мысль, что TDOP — это всего лишь один из алгоритмов парсинга. Ну чтобы вы поднялись чуть над темой и не считали никакой конкретный реализованный алгоритм за панацею. Потому что панацеи нет.
WH>То-то ты GLR во все щели толкаешь.

Та блин, GLR — это просто самый общий вариант для восходящего разбора (и дословный перевод такой же), отец семейства, кароч. Есть же LALR, всевозможные модификации SLR и т.д. Ты только копни в эту область. Прямо сейчас эта область исследуется активнее всего, (случайно, что ле?). ИМХО, потому что оперативность — это отличное качество для современных скоростей обмена информацией, т.е. она хорошо смотрится при конвейерной организации обработки этой информации.

И да, конкретно против TDOP я ничего не имею, а LL(1) вообще считаю НАИЛУЧШИМ вариантом для тех случаев, где исходная грамматика приводима к LL(1) без необходимости ее подмены на промежуточную (нецелевую) грамматику. Поэтому пользовал LL(1) неоднократно. Моя мысль банально в том, что не существует одного решения на все случаи жизни. А вы как-то умудрились целый пласт восходящего разбора проигнорировать. Это слишком дохрена игнорировать надо. Помнишь то обсуждение, чтобы при преобразовании частей правил в ДКА для вашего ПЕГ сохранялись исходные нетерминалы? Это же натуральная вотчина для восходящего разбора — генерить именно такие ДКА (для регулярной грамматики вроде бы достаточен LR(0) ). Такая же скорость разбора, ровно один шаг алгоритма на каждый символ, и достоверно восстановленное синтаксическое дерево произвольной глубины. Я ХЗ почему ты не обратил внимание на этот момент еще тогда. LR(0) вообще можно юзать вместо ДКА для случаев, когда грамматика явно приводима к регулярной, но нужны не только сами разобранные строки (нетерминал верхнего уровня), но и обязательно ход разбора, то бишь дерево.

==========
на остальное потом.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Вы с дубу рухнули, поднять такой эпический срач? Это же тема номер 2 за Вынь вс. Линь!

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

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

Не только Оберон. Паскаль и Модула из того же семейства. Обрати внимание, сколько было ООП-языков раньше, но в современном мейнстриме выжил такой технический принцип построения полиморфизма, который впервые появился в Паскале (по крайней мере в мейнстриме). Это я про С++/Java/C#.

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

AVK>Что характерно — ни на один из заданных вопросов ты так и не ответил. Зато навалил кучу бессвязного и слабо относящегося по теме флейма. Шеридан №2.

Какие вопросы, такие ответы. Спрашивайте по существу.

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

C>>>В Обероне нет:
C>>>1) Алгебраических типов и Pattern Matching
C>>>3) Макросистемы
C>>>4) Зависимых типов
C>>>5) Typeset'ов
C>>>...
C>>>Это унылое дерьмо мамонта из 80-х годов.

Ф>>а оно надо?

Ф>>я из всего перечисленного использую только
C>>>2) Generic'ов — реально необходимая вещь

Ф>>а про остальное даже не знаю )

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

А пункты 3, 4, 5 вообще есть мало где.

Особую остроту придает тот факт, что перечисленные пункты не новость, а старше того же Оберона многократно, но так и не взлетели. И не взлетят, бо противоречат инкапсуляции ООП/КОП. И внимание современной разработки уж точно не на этом перечисленном формалине образца 40-50-х годов сосредоточено.

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

V>>А это уже юления после залета. А казалось бы, всего-то предложили пару сценариев использования.
WH>Нет. Это ты пытаешься убедить себя что что-то понимаешь.

Это ты который раз попался и вертишься. Расслабься, всё уже свершилось.

V>>Спорно АБСОЛЮТНО каждое словос т.з. современной безопасности. В реальности всегда требуется суперпозиция прав приложения и пользователя. Вот эти вот попытки упрощать закончились задолго до появления Юниксов.
WH>Опять бредишь.
WH>Разговор начинался с офиса и фотошопа.
WH>Им OpenFileDialog за глаза.
WH>Игрушкам даже он не нужен.

WH>Что у нас еще остается на десктопе?
WH>Да ничего.

WH>А на серверах ясен хрен нужен другой подход к раздачи привилегий.

А еще где-то третий. Охрененный аргумент... сразу свободен, кароч. ОС одна и та же. И ОС не отличет игрушку от БД. И не должна.

V>>Ну сейчас-то уже убедился, кто и чего не понимает? Всего-то 5-6 итераций мне понадобилось чтобы до тебя дошли все побочные эффекты предложенного сценария... какие мелочи, право.
WH>Ты конечно.

)))

WH>>>Никто не мешает установить защищённое соединение с защитой от MiM. И таких протоколов тьма.
V>>Ты всьерьез решил попросить очередного лулза? А потом утверждать "я никогда не говорил что это единственный способ." (С).
V>>Предлагаю вместо 5-6 итераций один раз тебе помедитировать над исходными условиями.
WH>А что над ними медитировать то?
WH>Если у нас защищенное соединение с защитой от MiM то мы можем верить этому соединению как тому пользователю от имени, которого оно установлено.

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

V>>Это уже совсем другой уровень безопасности. Если ты до этого всячески настаивал на безопасности и закрыточти машины от прониктовения — то это ровно противоположная идеология: машины открыты для проникновения (это банально удобно для работы), но защита пытается выстроиться на уровне сети. Ты вообще понимаешь, насколько это далекий от обсуждаемого подход? В этом случае характеристики конкретных операционок на ендпоинтах вообще не играют рояли. Я же тебе скзаал — Кайберакс подложил тебе свинью, закатав всю твою теорию под асфальт.
WH>Что-то чем дальше, тем бредовее.
WH>И никогда ничего про закрытость машины не говорил.
WH>Наоборот.
WH>Я говорил про то что на машину можно ставить что попало.
WH>Лишь бы этому чему попало лишних привилегий не давать.

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

WH>И я совершенно не понимаю, какая разница между пользователем, который подключен локально и пользователем, который подключен удаленно.

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

V>>И да, на самом деле это то, о чемя говорил с самого начала — что если речь о злонамерениях, то ключевая инфраструктура. Ты спрорил до соплей, а теперь, ради согласшения с одним из участников, который на твоей стороне конкретно здесь и сейчас, подписался под каждым моим словом, оспоренным тобой раньше.
WH>Ты опять бредишь. И пытаешься съехать с темы.
WH>Изначально разговор был про приложения.
WH>И про то, что согласно твоей вере нужно сертифицировать 100% приложений.
WH>Иначе все развалится.

Не всех, а имеющих определенные права доступа к информации. Про 100% — это твой только что придуманный бред, чтобы оправдать своё непонимание ситуации. Мне достаточен ровно такой процент, чтобы он вышел за рамки тщательно сертифицированного ПО. Конкретно в Сингулярити они вышли за этот % изкаробки. В реальной жизни выход будет еще больше.

WH>Но ты нашёл аж ДВА драйвера и ядро ОС, которые нужно сертифицировать.
WH>Весь остальной софт будет прекрасно жить без этого.

Я еще искать не начинал. И не 2 драйвера, а многие сотни независимых, ес-но, я тебя уже одергивал. И еще, ты так и не обрисовал, как ты себе представляешь тестирование ПО на злонамеренность. И как ты себе вообще верификацию ПО представляешь? много раз сертификацию проходил, поделись? Или как обычно последние годы — облака, белокрылые лошадки.. сплошь сферические? Ладно там верификация на опасный с т.з. типобезопасности код — это хоть как-то автоматизируется, но обсуждаемые вещи будут абсолютно типобезопасны, а глазками в сотне тыщ строк ты хрен чего поймаешь. Это такая ситуация прямо на сегодня. А ты этого никак не понимаешь, бо по-твоему, типобезопасность и изолированность что-то значат. А на самом деле через DMA прямо сейчас можно загнать любой участок памяти Сингулярити в буфер жесткого диска и прочитать обратно. Вот и нет твоей изолированности процессов. В общем, не с того конца ты подходишь к безопасности изначально. А всё потому, что пороха не нюхал и рассуждаешь угубо умозрительно.

WH>Теперь пытаешься приписать мне бред, который ты придумал и теперь опровергаешь.

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

V>>Да еще с таким присущим тебе последние нескоолько лет твоей недолгой жизни апломбом.
WH>Чья бы корова...

V>>Я же говорю, вы, ребятки, кормите лулзами похлеще иных домохозяек.
WH>Ты даже не представляешь, сколько лулзов ты поставляешь.

Да мне пох, вообще-то. Я уже говорил не раз, на Обероне я не написал не строчки, но мне не помешало поинтересоваться, что и как там. И там понимать нечего, если голова соображает. Да и на Паскале пришлось пошпилить когда-то давно, т.е. комплексов по поводу языка нет. Но здесь приходится бодаться и просвещать даже по таким вопросам, которые можно прочесть в первых строчках Вики. Вот уровень обсуждения. Стыдуха.

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

WH>>А на серверах ясен хрен нужен другой подход к раздачи привилегий.

M>Да даже там, по большому счету, этот подход мало отличается от OpenFileDialog, если так подумать

Может, только более гранулярно, но и то.

Блин, Мамут, давай лучше о политике, там хоть более предметно выходит. Подход настолько отличается, что натянуть одно на другое вообще никак. В нормальных защищенных соединениях у тебя будет просто поток байт по ровно одному TCP-соединению и по какому-то хрен его знает высокоуровнемому протоколу сверху TCP, о котором операционка ни слухом ни духом. Передать удаленно хендл открытого файла (как предложил Wolfhound) — вообще никак, чтобы контроллировать процесс передачи и последующее использование операционкой. Я уже молчу о такой предложенной вещи как "личное" кликанье юзверя с нужными правами мышью по кнопке ОК этого диалога... фиг с ним, считаем, что где-то придумали альтернативу и как-то "кликнули", но просто если передашь хендл, и дашь некое АПИ работы по такому хендлу (а ведь такое АПИ будет нейтрально к протоколу, ес-но, ведь протоколов мильон), это невообразимая дыра со всех сторон, даже со стороны уже зараженного сервака, где бедный сетевой бот никак не мог открыть файл из-за недостатка привилегий. А тут уже за него открыли и даже хендл сообщили — вот это халява так халява. Цепляйся вообще любым самым простым соединением и юзай уже открытый хендл на своё усмотрение. Т.е. ситуация на сегодня, когда действие выполняет серверное ПО-посредник по имени файла (скажем, MS SQL Server), но выполняет достоверно команды лишь от конкретного достоверного соединения — эта ситуация и то на многие порядки более безопасная, чем предложенный натуральный беспредел. А всё потому, что торопыжки бросаются на клавиатуру не подумав.

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

V>>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
C>Можно пример?

Легко. Популярная 24-битная адресация у PCI-устройств. Т.е. мапить можно только конкретные ФИЗИЧЕСКИЕ диапазоны адресов. Напомню, что юзверские виртуальные адреса после свопа меняют свои физические адреса. Конечно, это всё разруливается несложным алгоритмом через mmap (чтобы привязать некий юзверский диапазон к физическому mmap-IO), но сам этот вызов из юзверского кода — вообще приговор всему, что мы тут обсуждали. Нет его в Сингулярити для юзверского кода и никогда не будет.

C>А то в Линуксе, идиоты такие, смогли как-то сделать общую систему поддержки DMA с поддержкой IOMMU для x86 и ARM (с его странными требованиями когерентности). Никакой зависимости от "драйверов конкретных чипсетов" нет и в помине.

Ты хоть понимаешь термин "когерентность" относительно ДМА?

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

И никакой "общей" системы там нет. Там есть банальная абстракция на вызовы ядра того же Linux (типа virt_to_bus), но сами коды драйвера устройства — опаснее некуда с т.з. обсуждаемого, т.к. по-прежнему оперируют произвольными адресами физической памяти (в плоской модели памяти кольца ядра).

V>>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
C>Мимо.

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

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

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

AVK>Что характерно — ни на один из заданных вопросов ты так и не ответил. Зато навалил кучу бессвязного и слабо относящегося по теме флейма. Шеридан №2.

Не совсем справедливое сравнение. Шеридан разбирается в материале и "фанатеет" востребованной технологией. vdimas скорее похож на создателя суперкомпактного языка, который скакал тут пол года назад (PC101 кажется?).

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

V>>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
WH>Пример в студию.

Кайбераксу рядом привел.

V>>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
WH>Ну да. Без IOMMU все печально.
WH>С IOMMU все хорошо.

Давай в отдельной теме рассмотрим IOMMU. А то сдается мне, кто-то чего-то недопонимает насчет этой технологии. Там не отсутсвует DMA, там ровно наоборот, работа с любыми аппаратными ресурсами идет теперь примерно так же, как раньше только для DMA. В общем, в этой однородности суть (см. спецификации HyperTransport).

WH>>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
WH>Что за бред?
WH>Какие еще адреса страниц в манифесте?

ОМГ.

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

Т.е. операционка должна сканить, что ты там по каналам передаешь? Т.е. не просто проверять типобезопасность на этапе инсталляции ПО, а вообще сканить сами передаваемые байты? )))
Не стыдно?

V>>И код не подлежит верификации и сравнения с манифестами, т.к. код получает неизветсные на этапе компиляции цифры и настраивает ими контроллер DMA. Мне казалось, что такое нарушение очевидно. Ан нет... )))
WH>Это очередной твой бред.

Это та поверхностность, от которой ты не можешь отучиться. Я же выше сказал, вопрос не так прост, как кажется. Давай вот распишем от участвующих 2-х драйверов вплоть до записываемых в устройство байт, а то при помощи одних только междометий толку всё-равно не будет.

WH>>>Ибо ссылки на внутренние объекты могут быть беспрепятственно сохранены, где попало.
V>>Если на внутренние — то только внутри и могут,
WH>И что же мне помешает передать ее в другой объект?
WH>Оберон этому никак не препятствует.

Да ничего. Но ты передашь ссылку на объект СВОЕГО модуля или доступную только из СВОЕГО модуля. Опять нихферштейн? Т.е. не в рассматриваемом месте передачи находится слабое звено. Если какой-то важной информацией/объектом уже завладел, то до фени, каким образом эту информацию куда-то передавать. А ты пытаешься меня сфокусировать на способе передачи уже хакнутой информации. Сие мне вовсе неинтересно.

V>>Ну так с тем же успехом можно подменять модули в GAC. Насколько это реально?
WH>Перестань говорить сам с собой.
WH>ГАК тут вообще не причем.

Понятно, контекст утерян. Фиг с ним..

V>>И твоё "нельзя" — это на типонебезопасных языках нельзя, а если происходящее детерминировано, то можно.
WH>Ни на каких нельзя.

V>>ХЗ. Я под безопасностью имел ввиду какие-нить переполнения, выходы индексов за пределы массива и т.д. Без изоляции можно писать очень эффективные системы. Нафига, например, корабельной навигационной системе изоляция процессов. Поясни.
WH>Ох. Ты даже не понимаешь, про какую изоляцию я говорю.
WH>А говорю не про аппаратную защиту памяти. А про логическую изоляцию процессов на уровне системы типов.

И я всё еще про неё же. Просто ты передвинул изоляцию всего на один шажок, а я утверждаю, что в случае абсолютной безопасности кода эту изоляцию можно целиком и полностью перенести в ср-ва инкапсуляции самого языка. Сингулярити что сделало? Она 1-в-1 сэмулировала аппаратную защиту памяти процессов своими программными ср-вами. Ты это хоть понимаешь? А вопрос изначально стоит так — зачем вообще появилась эта аппаратная защита памяти процессов? Достаточно составирть список причин и пройтись по нему в условиях абсолютной типобезопасности и верифицируемости байт-кода. ИМХО, в этом случае украсть что-то у объекта можно будет только тогда, когда программа специально будет так написана, чтобы у нее можно было что-то украсть. ИМХО, такую способность (пусть даже вложенную по ошибке) тоже вполне можно будет отловить каким-нить анализатором, если код полностью детерминирован.

V>>>>А насчет модели исполнения — экземпляры объектов полностью изолированы.
WH>>>Бред.
V>>-1
WH>Оберон не знаешь.

Давай по существу. Вот ты имеешь экземпляр объекта. Попробуй преодолеть его инкапсуляцию. Ты даже адрес его получить не сможешь в языке. А факты нецелевого оперирования адресом объекта в байткоде, ИМХО, тоже можно отлавливать автоматом.

WH>>>Ты что действительно не понимаешь, что в сингулярити для каждого процесса есть свое объектное пространство?
V>>Я не вижу в этом особых преимуществ, если мы договорились, кто код безопасен сам по себе.
WH>Ну да. Возможность грохнуть зажравшийся процесс, а не всю ОС фигня.

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

WH>Гарантии того что нет гонок фигня.

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

WH>Все фигня. Один vdimas умный.

Может и ошибаюсь, и что с того? У меня на этот счет никаких комплеков. Но мне интересны только верифицируемые рассуждения, которые я смог бы повторить самостоятельно не торопясь с нужной мне подробностью... а не вот этот обмен междометиями. А пока что, стоило самостоятельно добавить к аргументам оппонентов 1-2 уровней подробностей, и всё рассыпается.

V>>Все-равно все объекты в одной плоской памяти, а пространство объектов — сугубо логическое. И еще. Для твоей изоляции требуется специальный дорогой инструмент обслуживания этой изоляции.. И оп-па — на сцену выходят каналы. Это же компромисс получился, если посмотреть на всю композицию в целом. Если бы ты хоть немного поработал с lock-free, понял бы, почему я на твои каналы смотрю без энтузиазма. Существуют механизмы передачи информации/сигналов многократно дешевле, в десятки и больше раз.
WH>Которые можно реализовать, не нарушая изоляцию процессов.

Не можно, ес-но. Изоляцию в смысле Сингулярити придется нарушить. Но сам вопрос изоляции процессов в силе (см чуть выше в этом же посте). Чтобы было проще я уже предложил сценарий: скажем, некая корабельная навигационная система? Или возьмем военного робота, управляющего ракетным комплексом. У нас стоит задача выжать максимум вычислительной эффективности от железки. Ес-но, современные ОС, типа Windows или Linux никакого максимума не дадут и близко. Твои предложения?

WH>>>Что не могут существовать ссылки из одного процесса в другой?
WH>>>И что оберон никак от этого не защищает?
V>>Ссылки возможны только при явных зависимостях.
WH>Но они могут быть.
WH>И гонки могут быть.
WH>И вот такой код может быть. http://www.rsdn.ru/forum/philosophy/1004226.1.aspx

Я его видел давно, только не понял, что именно ты хотел там сказать? Это нормальная регистрация объектов в статических данных. Например, remoting в дотнете работает точно так же как ты там написал — через статические списки. Только поэтому локальный прокси может жить до тех пор, пока жив удаленный стаб, хотя на него никто локально не ссылается.

И да, тот пример можно было упростить до 5 строчек... Спишем ненужную многословность на твою молодость на год публикации.

V>>Никаких ссылок, типа как на безтиповый Object в дотнете быть не может.
WH>Это вообще к делу не относится.

Относится. Ты не сможешь в такой список пихать все подряд объекты, получаемые невесть откуда. Ты получать невесть откуда объекты-то не сможешь. Жесткая статическая типизация — это совершенно другой подход к программированию. В рамках Сингулярити и C#, скажем так, это недостижимо. Там любой мало-мальский код срывается в динамическое приведение типов. Се ля ви, человеческая слабость. Поэтому там изолированность процессов скорее всего требуется. Ведь динамическое приведение типов нарушает ссылочную прозрачность, и автоматически уже можно мало чего проверить... Ну вот разве что типобезопасность каналов, которые обязательны для изоляции недетерминированных программ друг от друга.

V>>без посредников, то бишь без копий нужной инфрмации.
WH>Это снова бред.

Это не бред. Это определение роли сообщений — быть посредниками информации.

V>>И здесь дорого всё: создание копий, помещение в очередь,
WH>И снова...

Ты уже нашел ABA-problem в гугле? В уме прикинул затраты на решение?
MS давало свой алгоритм решения ABA в списках хендлов в виндах и я где-то в MSDN его видел. Не фонтан с т.ч. быстродействия, прямо скажем.

V>> сигналы шедуллеру, чтобы он дал кванты принимающей стороне, чтение этих копий на той стороне. Всё вместе много и дорого.
WH>Всё это придется проделать и оберону.

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

V>>Valgrind. Погоняй на досуге, очень рекомендую. А казалось бы — для опасных языков предназначен. Юоюсь предоложить во сколко раз будет проще для безопасных.
WH>Гонял. Мышей кроме самых примитивных не ловит.
WH>А мне нужны гарантии, что всё хорошо.
WH>Понимаешь? ГАРАНТИИ!

Всё ясно, не гонял ты нифига. Может и по остальным пунтам так же не моргая врешь? )))

Мы же там о гонках говорили. А Valgrind ловит ВСЕ гонки. Т.е. вообще все, даже которые в коде просто есть, но согласно хитросплетениям алгоритмов никогда не будут вызваны. Но они есть и могут буть вызваны... ну скажем в случае дотнета через рефлексию. Поэтому, гарантии ловли гонок 100%. Уникальный тул, таки крайне рекомендую к изучению.

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

Вообще, мыслить надо объектами, а не модулями, в этом идеология. Зачем объекту знать, кто его использует? Он дает АПИ и честно его реализует, вот и всё.

V>>Проверка протоколов — это уже высокоуровневые плюшки.
WH>Это плюшка, которая необходима для работы.

V>>А поддержка уникальных ссылок в паскалях всегда была изкаробки.
WH>Что за бред.
WH>Паскаль ты не знаешь.
WH>Не было там никогда уникальных типов.

Да вроде доходчиво пояснил, что происходит.

V>>Он сам разбирается в процессе анализа при компиляции, где ему создать копию, а где переиспользовать имеющиеся данные. И да, CONST там все-таки ввели, это одна из гарантий для вызываемого метода.
WH>Это все вообще не о том.

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

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

AVK>>Что характерно — ни на один из заданных вопросов ты так и не ответил. Зато навалил кучу бессвязного и слабо относящегося по теме флейма. Шеридан №2.

N>Не совсем справедливое сравнение. Шеридан разбирается в материале и "фанатеет" востребованной технологией. vdimas скорее похож на создателя суперкомпактного языка, который скакал тут пол года назад (PC101 кажется?).

Судя по твоим комментам, ты просто ничего не понимаешь в обсуждении. Т.е. вообще ничего. Заметь, тот пример с Хаскелем привел ты, и вроде даже как что-то на Хасклее можешь. Но мне, не знающему толком ни Хаскеля ни тем более Конкурентного Хаскеля, понадобилось ~5 мин чтения документации, чтобы показать тебе полное невладение предметом относительно твоего же собственного примера. Вот уж Facepalm как он есть.
http://www.rsdn.ru/forum/philosophy/4814422.1.aspx и ниже.

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

V>>Любой разберет с таблицей, твой парсер тут не при чем. Я же эту технику и показывал для С++, как неоднозначности сводятся к однозначностям. Но это такой язык, где необязательно объявление идет впереди использования, а если нет, то TDOP парсер для таких сценариев вообще самый худший вариант.
WH>Что за бред?
WH>С++ так не умеет.

Описка, ес-но, читать: ...где Обязательно объявление идет впереди использования...
Вроде из контекста должно было быть понятно.

V>>Ды ты бы вола бы за хвост не тянул и закрыли тему еще несколько месяцев назад.
WH>Я тебе просто показываю, как ты общаешься.

Мде? Меня наоборот ругают за излишние подробности. Ты полная противоположность.

V>>Гы, я думал интересно будет насчет преобразований м/у цветовыми пространставами, бо там много тонкостей. А ресэмплинг внутри одного пространства, в какой-нить ARGB — это детсад.
WH>Но ты не знаешь, как он работает.
WH>Иначе ты бы сразу понял, что не так с той картинкой.

Да я ХЗ, если честно, т.к. всегда получал только правильную картинку и совершенно не в курсе, как ты получил неправильную.

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

Кароч, тему закрыли, это переходит все границы. Тебе можно было сказать в чем дело еще тогда и сразу. Я ХЗ что за чудеса скромности ты решил продемонстрировать.

V>>Формула эта — простая линейная пропорция.
WH>Не правильно.

)))

V>>Собственно ВСЁ.
WH>Нет не все.
WH>Почему попробуй догадаться сам.

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

V>>ABA-problem не гуглится? А сейчас?

V>>Судя по проблемам с преодолением описки, ты даже и не слышал о такой? Ох уж эти мне "на элементарщине сыпающиеся" (С).
WH>1)Знаю я про это. Просто названия плохо запоминаю.
WH>2)В каналах сингулярити такой проблемы нет благодоря дизайну этих самых каналов.
WH>И кто тут сыпется на элементарщине?

Дизайн каналов в ABA вовсе не при чем. Ты таки не в теме. ABA-болезнь можно относительно дешево решить (всего одна лишняя операция записи указателя) только для такого сценария, когда из межпотоковой очереди выгребает один и только один поток. Все остальные сценарии не имеют абсолютно-надежного решения кроме случая генерации заведомо уникальных токенов на каждое сообщение. А это дорого. Да именно, сценарий Сингулярити, подходит под то самое "элегантное" решение. Именно поэтому (см в пред.постах) я тебе сказал, что могу дать реализацию такой очереди без ABA-болезни для Оберона, что там у активного объекта тоже один поток. Иначе бы не стал и хвастать.

V>>Я уже одергивал тебя от таких обобщений. Связь через каналы — дорогое удовольствие само по себе, не самый лучший вариант для многих сценариев.
WH>Так можно и без каналов. Не нарушая изоляции процессов.

А как?

V>>И уже где-то пощупать эти гипотетические оптимизации можно?
WH>В сингулярити.

Не дашь ссылку или пример кода, где бы видна была работа такого оптимизатора? Или это "потенциальное преимущество"?

V>>Есть такое, в реальном мире я оптимизирую через локальные вычисления, то бишь загружаю из памяти в локальные переменные, числодроблю и выгружаю обратно.
WH>Это опять не в тему.

Как раз в тему. Компилятор С++ считает стек (и вообще локальные переменные) приватной памятью потока и проводит агрессивную оптимизацию. Поэтому после загрузки данных в локальную память, числодробление и выгрузки я получал от 3-х до 12 раз ускорение. Я так подумал, что ты намекал на аналогичное в процессах Сингулярити.

V>>Яуже начинаю тебя подозревать в том, что ты вызов метода объекта пытаешься отличать от посылки ему сообщения. И вся твоя изоляция держиться только на это разнице. Это надуманно. Политику синхронизации определяет вызваемый ресурс. Если он помечен, как синхронизируемый, никакой внешний код не вызовет его в несинхронизируемом виде.
WH>Ну что за бред ты несешь. Переставай за меня думать. У тебя не получается.
WH>Запомни: я всегда очень буквален. И когда я говорю, кури альфабленд. Ты должен курить альфабленд. Ибо ты его не понимаешь.

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

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

Не покажу ес-но.

WH>В обероне это делается на раз.
WH>После чего по этому объекту начинаются гонки.

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

WH>Да и не на всех архитектурах запись/чтение указателя атомарны.

Это к делу не относится. Вопрос стоял так: почему бы не использовать на порядок более дешевые ср-ва, если они есть?

V>>Оттуда же, откуда списки процессов и остальных ресурсов. Каналы закрываются "сами", даже если процесс прибит насильно. Потому что он принадлежт операционной системе и она имеет на него ссылку. Исходники Сингулярити есть? Я в них не смотрел, но могу на этот момент поспорить.
WH>Бред.
WH>Каналы абсолютно пассивны и полностью автономны.
WH>И убивают их процессы во время собственной смерти.
WH>Таким образом, глобального списка каналов не существует.

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

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

V>Кароч, тему закрыли, это переходит все границы. Тебе можно было сказать в чем дело еще тогда и сразу.

Хотя не, мелькнула одна догадка (учитывая твои манеры).

Неужели ты всерьез намекал на физический смысл значения "альфа" в той модели представления маски прозрачности, которая дается через квадратный пиксел?
Если ты из-за этого столько морочил голову... Прокляну. )))

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

V> о мне, не знающему толком ни Хаскеля ни тем более Конкурентного Хаскеля, понадобилось ~5 мин чтения документации, чтобы показать тебе полное невладение предметом относительно твоего же собственного примера.

Как показывает эта ветка, ты вообще мало что знаешь толком. Очень жалею, что потратил время и вежливость. Надо было отключаться сразу, как только ты понес в своей обычной хамской манере пургу про мутабельность, вместо того чтобы прислушаться и понять, что МVar == AWAIT, а forkIO == "активные обьекты Oberona".

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

V>Описка, ес-но, читать: ...где Обязательно объявление идет впереди использования...
V>Вроде из контекста должно было быть понятно.
А в прошлом сообщении ты начал крутиться в другую сторону.

V>Мде? Меня наоборот ругают за излишние подробности. Ты полная противоположность.
Так ты не подробности рассказываешь.
Ты кучу букв, не относящихся к делу пишешь.

V>Кароч, тему закрыли, это переходит все границы.
Слив засчитан.

V>Тебе можно было сказать в чем дело еще тогда и сразу. Я ХЗ что за чудеса скромности ты решил продемонстрировать.
Так я сразу сказал.
Проблемы с альфой. К гамме и фильтрам отношения не имеют.

V>>>Формула эта — простая линейная пропорция.
WH>>Не правильно.
V>)))
Я же говорю. Ты не понимаешь что такое альфабленд.
И как он работает, если пиксели содержат альфу.

V>Не могу догадаться, я не получал картинок с искаженной статистикой, а у тебя по неправильной картинке идет искажение, видимое невооруженным глазом. А не пробовал гистограмму строить?
Еще раз. Ты даже не понимаешь, что ты видишь.
Проблемы с альфой и только с альфой.

WH>>Так можно и без каналов. Не нарушая изоляции процессов.
V>А как?
Да как угодно.
Главное чтобы указатели через границу процесса не просачивались.

V>Не дашь ссылку или пример кода, где бы видна была работа такого оптимизатора? Или это "потенциальное преимущество"?
Читай отчет по сингулярити.
Там английским по белому написано.

V>Это твои фантазии. Курить надо статистику изображения при ресэмплинге. И да, бывает далеко не только альфабленд, но и другие операции с масками прозрачности. Но оп-па, они все покрываются описанным мною алгоримом при ресэмплинге.
Опять бредишь.

WH>>Короче до тех пор, пока ты мне не покажешь, как в сингулярити передать ссылку на объект из одного процесса в другой записываю тебя в безответственные бредогенераторы.
V>Не покажу ес-но.
Ну, значит, туда я тебя и записываю.

WH>>В обероне это делается на раз.
WH>>После чего по этому объекту начинаются гонки.
V>Valgrind. )))
V>Но это перебор, есно. Там же полная детерминированность, можно разработать инструмент гораздо проще, чем Valgrind, т.к. вместо гонок можно ловить прямо в верификаторе описанную ситуацию шаринга мутабельных несинхронизированных объектов.
Осталось только понять что система типов сингулярити и есть такой верификатор.
Причем работает в 100% случаев.
А в обероне его нет и не предвидится.
В случае даже если ты это сделаешь для оберона ничто не заставит людей запускать твой верификатор.
В случае с сингулирити у нах просто нет выбора.

WH>>Да и не на всех архитектурах запись/чтение указателя атомарны.
V>Это к делу не относится. Вопрос стоял так: почему бы не использовать на порядок более дешевые ср-ва, если они есть?
Опять сам с собой разговариваешь.
Разговор про то, что оберон небезопасный язык.

WH>>Каналы абсолютно пассивны и полностью автономны.
WH>>И убивают их процессы во время собственной смерти.
WH>>Таким образом, глобального списка каналов не существует.
V>А единого списка процессов тоже нет?
Не нужен.

V>А выражение "ссылка прямая либо косвенно" из синглтона ты не сообразил?
Это просто набор слов.

V>И таки память под конкретный канал берется не из общей кучи? )))
Ну, только если под общей кучей подразумевать общее адресное пространство.
Но если не подразумевать, то нет.

V>Аууу, давай-ка ближе к телу.
С таким собеседником без шансов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>В нормальных защищенных соединениях у тебя будет просто поток байт по ровно одному TCP-соединению и по какому-то хрен его знает высокоуровнемому протоколу сверху TCP, о котором операционка ни слухом ни духом. Передать удаленно хендл открытого файла (как предложил Wolfhound) — вообще никак, чтобы контроллировать процесс передачи и последующее использование операционкой.
Бред.

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

V>фиг с ним, считаем, что где-то придумали альтернативу и как-то "кликнули", но просто если передашь хендл, и дашь некое АПИ работы по такому хендлу (а ведь такое АПИ будет нейтрально к протоколу, ес-но, ведь протоколов мильон), это невообразимая дыра со всех сторон, даже со стороны уже зараженного сервака, где бедный сетевой бот никак не мог открыть файл из-за недостатка привилегий. А тут уже за него открыли и даже хендл сообщили — вот это халява так халява. Цепляйся вообще любым самым простым соединением и юзай уже открытый хендл на своё усмотрение. Т.е. ситуация на сегодня, когда действие выполняет серверное ПО-посредник по имени файла (скажем, MS SQL Server), но выполняет достоверно команды лишь от конкретного достоверного соединения — эта ситуация и то на многие порядки более безопасная, чем предложенный натуральный беспредел. А всё потому, что торопыжки бросаются на клавиатуру не подумав.
Всё мимо. А всё по тому, что ты не в состоянии понять, о чем вообще разговор.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Это ты который раз попался и вертишься. Расслабься, всё уже свершилось.
Вертишься тут только ты.

WH>>А на серверах ясен хрен нужен другой подход к раздачи привилегий.
V>А еще где-то третий.
Ну, попробуй, найди третий.

V>Охрененный аргумент... сразу свободен, кароч. ОС одна и та же. И ОС не отличет игрушку от БД. И не должна.
Так она и не отличает.
Оба способа доступны и для БД и для игрушки.
Просто БД нужен один, а игрушки не нужно ни того ни другого.

V>Святая простота. Снимая полный трафик рано или поздно в этот трафик можно вклиниться. Хотя бы потому, что открытые ключи передают открыто и ими можно расшифровать зашифрованное сообщение. Курить современное популярное шифрование.

Лолшто?
Открытые ключи они на то и открытые чтобы ими ничего расшифровать было нельзя.
Или ты собрался сломать ассиметричный шифр? Удачи.

V>Ну тогда Киберакс нуб, а не ты. ))
V>Мне то пофиг, кто из вас нуб, модели-то заведомо противоречащие. Он привел ссылку, где технология такова, что удаленный пользователь может иметь права локального. В той технологии это единственный ключевой момент, остальное — детали реализации.
И к чему эта гора букв?
К модели безопасности сингулярити это вообще никак не относится.

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

V>Не всех, а имеющих определенные права доступа к информации. Про 100% — это твой только что придуманный бред, чтобы оправдать своё непонимание ситуации.
Это не бред. Это то, что будет твориться в бутылке. Иначе все развалиться.

V>Мне достаточен ровно такой процент, чтобы он вышел за рамки тщательно сертифицированного ПО. Конкретно в Сингулярити они вышли за этот % изкаробки. В реальной жизни выход будет еще больше.
Опять бессвязный набор букв.

V>Я еще искать не начинал.
И что ты уже не один десяток сообщений делаешь?

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

V>И еще, ты так и не обрисовал, как ты себе представляешь тестирование ПО на злонамеренность. И как ты себе вообще верификацию ПО представляешь? много раз сертификацию проходил, поделись? Или как обычно последние годы — облака, белокрылые лошадки.. сплошь сферические? Ладно там верификация на опасный с т.з. типобезопасности код — это хоть как-то автоматизируется, но обсуждаемые вещи будут абсолютно типобезопасны, а глазками в сотне тыщ строк ты хрен чего поймаешь. Это такая ситуация прямо на сегодня. А ты этого никак не понимаешь, бо по-твоему, типобезопасность и изолированность что-то значат. А на самом деле через DMA прямо сейчас можно загнать любой участок памяти Сингулярити в буфер жесткого диска и прочитать обратно. Вот и нет твоей изолированности процессов. В общем, не с того конца ты подходишь к безопасности изначально. А всё потому, что пороха не нюхал и рассуждаешь угубо умозрительно.
Еще раз.
Это лечится при помощи IOMMU раз и навсегда.

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

V>Да мне пох, вообще-то. Я уже говорил не раз, на Обероне я не написал не строчки, но мне не помешало поинтересоваться, что и как там.
Но помешало понять.

V>И там понимать нечего, если голова соображает.
Если.

V>Да и на Паскале пришлось пошпилить когда-то давно, т.е. комплексов по поводу языка нет. Но здесь приходится бодаться и просвещать даже по таким вопросам, которые можно прочесть в первых строчках Вики. Вот уровень обсуждения. Стыдуха.
Это нам тебя просвещать приходится.
Но ты даже то, что тебе разжёвывают, проглотить не можешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Легко. Популярная 24-битная адресация у PCI-устройств. Т.е. мапить можно только конкретные ФИЗИЧЕСКИЕ диапазоны адресов.
И что помешает мне выделить память в этом диапазоне?

V>Напомню, что юзверские виртуальные адреса после свопа меняют свои физические адреса.
К делу не относится.

V>Конечно, это всё разруливается несложным алгоритмом через mmap (чтобы привязать некий юзверский диапазон к физическому mmap-IO), но сам этот вызов из юзверского кода — вообще приговор всему, что мы тут обсуждали. Нет его в Сингулярити для юзверского кода и никогда не будет.
И почему же это приговор?
Можешь сказать?
Особенно если пользовательский код скажет: Дай мне кусок памяти подходящий для DMA.
После чего просто отправит его в драйвер.

Единственная опасность это DoS атака. Когда процесс начнет жрать эту память и не отдавать.
Но такие процессы можно прибивать автоматом. И освобождать все что они нахапали.

V>На этом сайте лежит русскоязычный перевод технического репорта по Сингулярити. Очень рекомендую освежить, прежде чем вернуться к теме.
Очень кривой перевод надо сказать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Давай в отдельной теме рассмотрим IOMMU. А то сдается мне, кто-то чего-то недопонимает насчет этой технологии. Там не отсутсвует DMA, там ровно наоборот, работа с любыми аппаратными ресурсами идет теперь примерно так же, как раньше только для DMA. В общем, в этой однородности суть (см. спецификации HyperTransport).
Главное там то, что можно сказать какие страницы памяти может трогать данная железка.
Все остальное к делу не относится.

WH>>>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>>>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
WH>>Что за бред?
WH>>Какие еще адреса страниц в манифесте?
V>ОМГ.
Ты давай по существу.
Или не в состоянии.
Ибо для IOMMU не нужно ничего прописывать ни в каком манифесте.
Ибо страницы выделяются динамически.
И динамически прописываются в IOMMU для данной железки.

V>Т.е. операционка должна сканить, что ты там по каналам передаешь? Т.е. не просто проверять типобезопасность на этапе инсталляции ПО, а вообще сканить сами передаваемые байты? )))
V>Не стыдно?
Тебе должно быть стыдно.
Ибо это делается именно что проверками типов на этапе инсталляции.

V>Это та поверхностность, от которой ты не можешь отучиться. Я же выше сказал, вопрос не так прост, как кажется. Давай вот распишем от участвующих 2-х драйверов вплоть до записываемых в устройство байт, а то при помощи одних только междометий толку всё-равно не будет.
Давай. Расписывай.

V>Да ничего. Но ты передашь ссылку на объект СВОЕГО модуля или доступную только из СВОЕГО модуля. Опять нихферштейн?
И ничего не меняет.
Мы можем внутри одного модуля создать два потока. И привет.

V>Т.е. не в рассматриваемом месте передачи находится слабое звено. Если какой-то важной информацией/объектом уже завладел, то до фени, каким образом эту информацию куда-то передавать. А ты пытаешься меня сфокусировать на способе передачи уже хакнутой информации. Сие мне вовсе неинтересно.
Я вообще не про хаки.
Я про то что оберон не обеспечивает гарантии того что объекты не будут доступны из разных потоков без синхронизации

V>>>Ну так с тем же успехом можно подменять модули в GAC. Насколько это реально?
WH>>Перестань говорить сам с собой.
WH>>ГАК тут вообще не причем.
V>Понятно, контекст утерян. Фиг с ним..
Ты его и не находил. Ни разу.

V>И я всё еще про неё же. Просто ты передвинул изоляцию всего на один шажок, а я утверждаю, что в случае абсолютной безопасности кода эту изоляцию можно целиком и полностью перенести в ср-ва инкапсуляции самого языка. Сингулярити что сделало? Она 1-в-1 сэмулировала аппаратную защиту памяти процессов своими программными ср-вами. Ты это хоть понимаешь?
Я понимаю, что ты ничего не понимаешь.

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

V>ИМХО, в этом случае украсть что-то у объекта можно будет только тогда, когда программа специально будет так написана, чтобы у нее можно было что-то украсть. ИМХО, такую способность (пусть даже вложенную по ошибке) тоже вполне можно будет отловить каким-нить анализатором, если код полностью детерминирован.
Если ты сделаешь этот анализатор (причем так чтобы его нельзя было отключить) то ты получишь сингулярити 1 в 1.
Но в обероне этого нет.

V>Давай по существу. Вот ты имеешь экземпляр объекта. Попробуй преодолеть его инкапсуляцию. Ты даже адрес его получить не сможешь в языке. А факты нецелевого оперирования адресом объекта в байткоде, ИМХО, тоже можно отлавливать автоматом.
Перестань разговаривать сам с собой.
Разговор идет про то, что можно один объект использовать из разных потоков без синхронизации.

V>Скачай WinAosMini, напиши зажравшийся активный объект и грохай его наздоровье. И я тебе на это уже отвечал, кстате.
Ага. Цепляем за статическую переменную и привет.
Вся память остается навечно.

WH>>Гарантии того что нет гонок фигня.
V>В условиях отсутствия какой-либо динамики все гонки можно обнаружить до запуска программ.
Вот только она в обероне присутствует.

V>Может и ошибаюсь, и что с того? У меня на этот счет никаких комплеков. Но мне интересны только верифицируемые рассуждения, которые я смог бы повторить самостоятельно не торопясь с нужной мне подробностью... а не вот этот обмен междометиями. А пока что, стоило самостоятельно добавить к аргументам оппонентов 1-2 уровней подробностей, и всё рассыпается.

1-2 уровня бессвязных букв.

V>Не можно, ес-но. Изоляцию в смысле Сингулярити придется нарушить.
Не придется.

V>Но сам вопрос изоляции процессов в силе (см чуть выше в этом же посте). Чтобы было проще я уже предложил сценарий: скажем, некая корабельная навигационная система? Или возьмем военного робота, управляющего ракетным комплексом. У нас стоит задача выжать максимум вычислительной эффективности от железки. Ес-но, современные ОС, типа Windows или Linux никакого максимума не дадут и близко. Твои предложения?
Написать ДСЛ для управления этим роботом и скомпилировать его.
Это будет заведомо более эффективно чем оберон.

V>Я его видел давно, только не понял, что именно ты хотел там сказать? Это нормальная регистрация объектов в статических данных.
Оно и видно.
Это я к тому, что никто не мешает сожрать всю память.

V>Например, remoting в дотнете работает точно так же как ты там написал — через статические списки. Только поэтому локальный прокси может жить до тех пор, пока жив удаленный стаб, хотя на него никто локально не ссылается.
К делу не относится.

V>Относится. Ты не сможешь в такой список пихать все подряд объекты, получаемые невесть откуда. Ты получать невесть откуда объекты-то не сможешь.
Это не важно.
Важно то, что я могу сожрать всю память.
И никто ее отобрать обратно не сможет.

V>Жесткая статическая типизация — это совершенно другой подход к программированию. В рамках Сингулярити и C#, скажем так, это недостижимо. Там любой мало-мальский код срывается в динамическое приведение типов. Се ля ви, человеческая слабость.
Ну что за бред ты ту опять несешь?

V>Поэтому там изолированность процессов скорее всего требуется. Ведь динамическое приведение типов нарушает ссылочную прозрачность, и автоматически уже можно мало чего проверить...
Феерия продолжается.
Ссылочная прозрачность это про неизменяемость.
К слову в хаскеле динамические привидения типов тоже есть.

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

V>>>без посредников, то бишь без копий нужной инфрмации.
WH>>Это снова бред.
V>Это не бред. Это определение роли сообщений — быть посредниками информации.
А не приходило в голову, что сообщение может быть адресом?
А не полной копией данных.

V>Нет. Пассивное распространение информации отличается от активной. Можно просто через короткую блокировку выставить некий флаг, а будет ли он когда-нибудь проверен — зависит от состояния того объекта и прикладной логики. А из канала выгребать надо в любом случае.

1)Это можно сделать и в модели сингулярити. Просто добавляем шаренный флаг и все.
2)Это не имеет смысла. Ибо если объект висит и ждет, когда этот флаг будет установлен, то он так и не проснется.
Ну и ABA тут будет отжигать в полный рост.

V>>>Динамическая загрузка статических зависимостей, заметь. Модуль загружается при первом обращении к нему. То бишь зависимость торчит статически, но если модуль не вызвается, он не загружен.
WH>>Но ты никогда не знаешь, какой еще модуль использует данный.
WH>>И сколько их.
WH>>И когда они появятся.
V>Вообще, мыслить надо объектами, а не модулями, в этом идеология. Зачем объекту знать, кто его использует? Он дает АПИ и честно его реализует, вот и всё.
Ох. Модуль в обероне тоже объект.
Причем такой, который удалить нельзя.

V>>>А поддержка уникальных ссылок в паскалях всегда была изкаробки.
WH>>Что за бред.
WH>>Паскаль ты не знаешь.
WH>>Не было там никогда уникальных типов.
V>Да вроде доходчиво пояснил, что происходит.
Ага. Объяснил то, что ты представления не имеешь о том, что такое уникальный тип.

V>Это ровно о том, нахрена вообще нужны уникальные типы. Они нужны для тупых компиляторов. Это перенос сложности с компилятора на человека. Ты так и не понял, в каких случах и для чего автоматичеески создается копия значения, а когда нет?

Лолшто?
Уникальные типы проверяют уникальность ссылки на объект, который по логике должен иметь ровно одну ссылку.
Особенно это актуально когда объект по ходу дела тип меняет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.

К твоему сведению. У С++ вообще нет неоднозначеностей в грамматке. Просто она КЗ. Там надо иметь таблицу символов в процессе парсинга.

V>Вырезка:
V>

V>C and C++ both allow the following statement:

V>x * y ;

V>It has two different parses:
V> It can be the declaration of y, as pointer to type x
V> It can be a multiply of x and y, throwing away the answer.

V>...

V>And if you cheat enough, you can make LR parsers work for C and C++. The GCC guys did for awhile, but gave it up for hand-coded parsing, I think because they wanted better error diagnostics.

V>There's another approach, though, which is nice and clean and parses C and C++ just fine without any symbol table hackery: GLR parsers. These are full context free parsers (having effectively infinite lookahead). GLR parsers simply accept both parses, producing a "tree" (actually a directed acyclic graph that is mostly tree like) that represents the ambiguous parse. A post-parsing pass can resolve the ambiguities.

V>We use this technique in the C and C++ front ends for the DMS Software Reengineering Tookit. They have been used to process millions of lines of large C and C++ systems, as well as dozens of other languages.

И что ты тут вычитал? Это неоднозначность для КС-парсеро. Добавление таблицы символов и проверки идентификаторов по ней делает грамматику однозначной КЗ грамматикой.

Ты сейчас дискредитируешь себя в глазах окружающих.

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

О! Смешно один и тем же лицам.

Это, конечно, ничего, что самая популярная ОСь вот только-только переходит с процедурного системного АПИ на АПИ в виде ООП/КОП. То бишь, определяется такой вид подачи АПИ как минимум на ближайшие лет 20-30. И это ничего что самая популярная платформа для Embedded (наиболее активно развивающего направления IT) имеет АПИ, определенное в Java-стиле, то бишь тоже сугубо на ООП/КОП... Главное, делать как можно более загадочное лицо и улыбаться. )))

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

V>>Описка, ес-но, читать: ...где Обязательно объявление идет впереди использования...
V>>Вроде из контекста должно было быть понятно.
WH>А в прошлом сообщении ты начал крутиться в другую сторону.

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

V>>Мде? Меня наоборот ругают за излишние подробности. Ты полная противоположность.
WH>Так ты не подробности рассказываешь.
WH>Ты кучу букв, не относящихся к делу пишешь.

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

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

V>>Кароч, тему закрыли, это переходит все границы.
WH>Слив засчитан.

Дык, ты и слил, НИ РАЗУ не ответив на прямо поставленный один и тот же вопрос в уже 4-х независимых темах. Это залет.

V>>Тебе можно было сказать в чем дело еще тогда и сразу. Я ХЗ что за чудеса скромности ты решил продемонстрировать.
WH>Так я сразу сказал.
WH>Проблемы с альфой.

А в Киеве дядька. А сформлировать ответ ты боишься по понятным причинам. Чтобы не усугублять свой epic fail.

V>>>>Формула эта — простая линейная пропорция.
WH>>>Не правильно.
V>>)))
WH>Я же говорю. Ты не понимаешь что такое альфабленд.
WH>И как он работает, если пиксели содержат альфу.

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

V>>Не могу догадаться, я не получал картинок с искаженной статистикой, а у тебя по неправильной картинке идет искажение, видимое невооруженным глазом. А не пробовал гистограмму строить?
WH>Еще раз. Ты даже не понимаешь, что ты видишь.
WH>Проблемы с альфой и только с альфой.

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

2. Зачем нужна гистограмма и как ее получить для изображения с альфа-каналом, мы тоже не знаем? ))) ЧТД.

Даю направление по 2-му: построй, одновременно для белого, черного и серого заднего фона для правильной и неправильной картинки. Ответы на все свои "открытия" увидишь прямо в гистограммах. Построй и устыдись. Просто вот эта твоя манера считать собеседников за идиотов растет исключительно из-за собственного непонимания слов собеседника, а это, в свою очередь, из-за вопиющей поверхностности по любой затронутой теме. И ведь, я козыри, в отличие от, в рукаве не держу. Все входы и выходы даю с самого начала. Но ведь лень сильнее тебя, не правда ли?

WH>>>Так можно и без каналов. Не нарушая изоляции процессов.
V>>А как?
WH>Да как угодно.
WH>Главное чтобы указатели через границу процесса не просачивались.

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

Понимаешь, написать в будущем можно что угодно.. давай уж тогда сменим вывеску темы на "как бы это могло быть?". Но даже в этом случае в Обероне гораздо проще на сегодня запретить передачу несинхронизированных мутабельных объектов прямо или косвенно м/у активными объектами (с учетом атомарности операций, например, над машинным словом), чем в Сингулярити. Бо в Сингулярити вообще нет возможности передать в другой процесс ссылку на некий расшареный объект, который нужен, чтобы представлять из себя расшаренный кусок памяти, где бы процессы обменивались несрочными флагами в самой дешевой манере.

WH>>>Короче до тех пор, пока ты мне не покажешь, как в сингулярити передать ссылку на объект из одного процесса в другой записываю тебя в безответственные бредогенераторы.
V>>Не покажу ес-но.
WH>Ну, значит, туда я тебя и записываю.

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

V>>Не дашь ссылку или пример кода, где бы видна была работа такого оптимизатора? Или это "потенциальное преимущество"?
WH>Читай отчет по сингулярити.
WH>Там английским по белому написано.

Ясно. Т.е. не дашь.

V>>Это твои фантазии. Курить надо статистику изображения при ресэмплинге. И да, бывает далеко не только альфабленд, но и другие операции с масками прозрачности. Но оп-па, они все покрываются описанным мною алгоримом при ресэмплинге.
WH>Опять бредишь.

Т.е. над масками прозрачности ты умеешь только альфа-бленд? ЧТД.

WH>Осталось только понять что система типов сингулярити и есть такой верификатор.
WH>Причем работает в 100% случаев.

Ясно. Т.е. чем отличается верификация при наличии или отсутствии динамических приведений типов, мы тоже не понимаем. ЧТД.

WH>А в обероне его нет и не предвидится.

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

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

1. Верификатор можно вставить в загрузчик.
2. В инсталлятор.
Выбирай.

WH>В случае с сингулирити у нах просто нет выбора.

Нет выбора до тех пор, пока не написать такой драйвер жесткого диска, что выбор появится. )))
Речь-то об инсталляторе+загрузчике. Какие проблемы написать альтернативный и то и тот?

WH>>>Да и не на всех архитектурах запись/чтение указателя атомарны.
V>>Это к делу не относится. Вопрос стоял так: почему бы не использовать на порядок более дешевые ср-ва, если они есть?
WH>Опять сам с собой разговариваешь.
WH>Разговор про то, что оберон небезопасный язык.

Т.е. на прямо поставленный вопрос мы опять не можем дать прямой ответ и срочно переводим тему? ЧТД.

WH>>>Каналы абсолютно пассивны и полностью автономны.
WH>>>И убивают их процессы во время собственной смерти.
WH>>>Таким образом, глобального списка каналов не существует.
V>>А единого списка процессов тоже нет?
WH>Не нужен.

А как будешь прибивать "зажравшийся процесс" (С)? Где его искать?

V>>А выражение "ссылка прямая либо косвенно" из синглтона ты не сообразил?
WH>Это просто набор слов.

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

V>>И таки память под конкретный канал берется не из общей кучи? )))
WH>Ну, только если под общей кучей подразумевать общее адресное пространство.
WH>Но если не подразумевать, то нет.

Ну всё с тобой ясно. Посмотри со стороны на свои посты... Почетный приз Болотного Ужа присуждается Wolfhound.

V>>Аууу, давай-ка ближе к телу.
WH>С таким собеседником без шансов.

Дык, еще бы. Я тебе уползти не дам. Тебе придется кажое свое юление повторить более одного раза, для надежности. Чтобы я точно убедился, что тебе не просто было лень/некогда отвечать в конкретном посте, а ты принципиально отказываешься/не можешь этого сделать. Дык, твой выбор, каждый сам кузнец своего счастья.

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

V>>Скорее, ровно наоборот. Идеи Оберона просты, мощны, но на первый взгляд их мощь неочевидна. Это развитие ООП ровно в ту сторону, которая стала неожиданно популярной буквально недавно: GC, функциональные типы, динамическая загрузка и выгрузка модулей, акторы и прочая "новомодная" асинхронность (AWAIT в Active Oberon) изкаробки.
C>Да ну? Бредить переставай.

C>В Обероне нет:
C>1) Алгебраических типов и Pattern Matching
C>2) Generic'ов — нельзя даже сделать банальный типобезопасный map.
C>3) Макросистемы
C>4) Зависимых типов
C>5) Typeset'ов
C>...
C>Это унылое дерьмо мамонта из 80-х годов.

В плане истории важно не то что в нем нет, а то что в нем появилось. К сожалению, я не могу вспомнить ничего.

C>Чувак, я участвовал в эпичном треде о "синтаксическом оверхеде". Это ты ничерта не знаешь об Обероне.

Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.

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

V>>Легко. Популярная 24-битная адресация у PCI-устройств. Т.е. мапить можно только конкретные ФИЗИЧЕСКИЕ диапазоны адресов.
V>>Конечно, это всё разруливается несложным алгоритмом через mmap (чтобы привязать некий юзверский диапазон к физическому mmap-IO), но сам этот вызов из юзверского кода — вообще приговор всему, что мы тут обсуждали. Нет его в Сингулярити для юзверского кода и никогда не будет.
WH>И что помешает мне выделить память в этом диапазоне?
WH>И почему же это приговор?
WH>Можешь сказать?

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

WH>Особенно если пользовательский код скажет: Дай мне кусок памяти подходящий для DMA.
WH>После чего просто отправит его в драйвер.

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

WH>Единственная опасность это DoS атака. Когда процесс начнет жрать эту память и не отдавать.
WH>Но такие процессы можно прибивать автоматом. И освобождать все что они нахапали.

Это не тот уровень опасности, это уровень устойчивости к стресс-сценариям, он не несет опасность в плане обсуждаемого несанкционированного доступа к произвольным данным. Мне пока хочется понять трюк с записью в ПРОИЗВОЛЬНУЮ память на уровне пользовательского кода. Я так-то со многими доводами относительно Сингулярити соглашался из-за того, что считал, что это невозможно. Если же это возможно, хотелось бы увидеть — как?

V>>На этом сайте лежит русскоязычный перевод технического репорта по Сингулярити. Очень рекомендую освежить, прежде чем вернуться к теме.
WH>Очень кривой перевод надо сказать.

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

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

V>>>Описка, ес-но, читать: ...где Обязательно объявление идет впереди использования...
V>>>Вроде из контекста должно было быть понятно.
WH>>А в прошлом сообщении ты начал крутиться в другую сторону.
V>В какую еще другую, если я предложил представить язык с синтаксисом С++, но с отсутствующими требованиями относительно предварительных объявлений. Ты уже успел забыть С++, что ле? Всё равно не поверю.
Вот я и говорю что в другую.
Ты сам себя то почитай.

V>Гы, если не понимаешь, то для тебя многие вещи пустой звук, ес-но... как для троешников на уроках в школе. Ну и плюс приходится тратить силы на борьбу с тобой, бо ведешь спор очень скользско (хотя бы насчет альфы пример).

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

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

V>Дык, ты и слил, НИ РАЗУ не ответив на прямо поставленный один и тот же вопрос в уже 4-х независимых темах. Это залет.
Я каждый раз отвечал прямо.
Но ты не можешь понять, что тебе говорят.

V>А в Киеве дядька. А сформлировать ответ ты боишься по понятным причинам. Чтобы не усугублять свой epic fail.
Так это твой epic fail.
Открой википедию наконец.

V>Я же говорю, тебе нечего ответить по существу, поэтому будешь юлить бесконечно. Ну юли дальше.
Открой википедию наконец.

V>1. Вопрос на засыпку — а зачем вообще нужна линейная шкала отсчетов при ресэмплинге? С чего ты решил гамму-то проигнорировать? Не хочешь нарисовать искажения хотя бы для самой простой интерполяции при ресэмплинге — линейной, при гамме, отличной от 1?
Я гамму не игнорировал.
Это ты в своем больном воображении придумал.

V>Даю направление по 2-му: построй, одновременно для белого, черного и серого заднего фона для правильной и неправильной картинки. Ответы на все свои "открытия" увидишь прямо в гистограммах. Построй и устыдись. Просто вот эта твоя манера считать собеседников за идиотов растет исключительно из-за собственного непонимания слов собеседника, а это, в свою очередь, из-за вопиющей поверхностности по любой затронутой теме. И ведь, я козыри, в отличие от, в рукаве не держу. Все входы и выходы даю с самого начала. Но ведь лень сильнее тебя, не правда ли?

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

V>Дык, это уже есть в Сингулярити, или очередная "маленькая потенциальная доработка"? И как мне с тобой что-то обсуждать, если на каждый технический аргумент у тебя одно и то же: "а вот можно подшаманить, а здесь подкрутить" и т.д. до бесконечности?
В сингулярити главное это изолированные процессы.
Способов общаться между изолированными процессами без нарушения изоляции миллион.

В обероне изоляции нет.
Никакой.
Ваще.

V>Понимаешь, написать в будущем можно что угодно.. давай уж тогда сменим вывеску темы на "как бы это могло быть?". Но даже в этом случае в Обероне гораздо проще на сегодня запретить передачу несинхронизированных мутабельных объектов прямо или косвенно м/у активными объектами (с учетом атомарности операций, например, над машинным словом), чем в Сингулярити. Бо в Сингулярити вообще нет возможности передать в другой процесс ссылку на некий расшареный объект, который нужен, чтобы представлять из себя расшаренный кусок памяти, где бы процессы обменивались несрочными флагами в самой дешевой манере.
Так в сингулярити невозможно запретить передачу или невозможно передать.
Ты уж определись.

V>>Про инсталлятор с верификатором говорил уже. Это же не ядро ОС, это просто запускаемое приложение. Это инфраструктура.
WH>Которой в бутылке нет. И сделать нельзя.
WH>Ибо изоляции всё равно нет.

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

WH>>>>Короче до тех пор, пока ты мне не покажешь, как в сингулярити передать ссылку на объект из одного процесса в другой записываю тебя в безответственные бредогенераторы.
V>>>Не покажу ес-но.
WH>>Ну, значит, туда я тебя и записываю.

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

Ты тут втирал, что оберон такой же безопасный как сингулирити.
Я тебе показал, что это не так.

Теперь ты пытаешься обвинить меня, черт знает в чем.
Как типично.

WH>>Осталось только понять что система типов сингулярити и есть такой верификатор.
WH>>Причем работает в 100% случаев.
V>Ясно. Т.е. чем отличается верификация при наличии или отсутствии динамических приведений типов, мы тоже не понимаем. ЧТД.
Ничем. Совсем ничем.
Но ты можешь показать класс. И в очередной раз отжечь.

WH>>А в обероне его нет и не предвидится.
V>Для Оберона такой верификатор будет на порядок проще, бо в языке соблюдается ссылочная прозрачность.
Ну что за бред ты опять несешь?
Ссылочная прозрачность это про неизменяемость. Понимаешь? НЕИЗМЕНЯЕМОСТЬ!
А не про динамические привидения типов.

Ты даже не знаешь, что означают термины, которыми ты пользуешься.

V>1. Верификатор можно вставить в загрузчик.
V>2. В инсталлятор.
V>Выбирай.
И получить сингулярити.

WH>>В случае с сингулирити у нах просто нет выбора.
V>Нет выбора до тех пор, пока не написать такой драйвер жесткого диска, что выбор появится. )))
V>Речь-то об инсталляторе+загрузчике. Какие проблемы написать альтернативный и то и тот?
Ну да. Нашёл всего два вектора атаки на сингулирити (которые легко закрыть) и теперь пытаешься оправдать ими бредовость бутылки.

WH>>>>Да и не на всех архитектурах запись/чтение указателя атомарны.
V>>>Это к делу не относится. Вопрос стоял так: почему бы не использовать на порядок более дешевые ср-ва, если они есть?
WH>>Опять сам с собой разговариваешь.
WH>>Разговор про то, что оберон небезопасный язык.
V>Т.е. на прямо поставленный вопрос мы опять не можем дать прямой ответ и срочно переводим тему? ЧТД.
Это ты переводишь тему.
Разговор шёл про безопасность.
Ты начал юлить на тему эффективности.
Которой в обероне еще меньше чем в бутылке.
Ибо мониторы требуют больше работы, чем посылка сообщения.

V>>>А единого списка процессов тоже нет?
WH>>Не нужен.
V>А как будешь прибивать "зажравшийся процесс" (С)? Где его искать?
В списке дочерних процессов пользователя.
Просто для каждого пользователя создаём процесс и все.
И каждый процесс может создать дочерний процесс.
Получаем дерево процессов.
И если один из них зажрался, просто прибиваем всё поддерево разом.

V>>>А выражение "ссылка прямая либо косвенно" из синглтона ты не сообразил?
WH>>Это просто набор слов.
V>Нет,
Нет. Это именно не согласованный набор слов.

V>это рядом обсуждали что есть статические мемберы и причем тут синглтоны.
И то и другое должно умереть.

V>Я предположил, что список процесов в операционке мог бы быть таким синглтоном.
Только не нужно это.

V>Облом было повторяться об одном и том же снова и снова подробно... не ожидал, что ты быстро забудешь что было пару дней назад.
Это бессвязный набор слов. Что они означают понять невозможно.

V>>>И таки память под конкретный канал берется не из общей кучи? )))
WH>>Ну, только если под общей кучей подразумевать общее адресное пространство.
WH>>Но если не подразумевать, то нет.
V>Ну всё с тобой ясно. Посмотри со стороны на свои посты... Почетный приз Болотного Ужа присуждается Wolfhound.
А что конкретно тебе не нравится?
Или ты хочешь сказать, что единое адресное пространство это обязательно одна куча?

V>Дык, еще бы. Я тебе уползти не дам. Тебе придется кажое свое юление повторить более одного раза, для надежности. Чтобы я точно убедился, что тебе не просто было лень/некогда отвечать в конкретном посте, а ты принципиально отказываешься/не можешь этого сделать. Дык, твой выбор, каждый сам кузнец своего счастья.
Э нет. Это я тебе уползти не дам.
И чем дальше, тем больше я убеждаюсь, что разговор с тобой не имеет смысла.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.

Этот топик тоже сильно. Только место Губанова vdimas занял.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Давай в отдельной теме рассмотрим IOMMU. А то сдается мне, кто-то чего-то недопонимает насчет этой технологии. Там не отсутсвует DMA, там ровно наоборот, работа с любыми аппаратными ресурсами идет теперь примерно так же, как раньше только для DMA. В общем, в этой однородности суть (см. спецификации HyperTransport).
WH>Главное там то, что можно сказать какие страницы памяти может трогать данная железка.
WH>Все остальное к делу не относится.

Неверно. Страницы памяти можно назначить любые. Полная функциональность DMA сохраняется. Я же сказал — любое обращение к аппаратуре выполняется в стиле DMA — посылкой пачки байт. Только теперь эта пачка называется "сообщением" и идёт обмен сообщениями вместо записи в многие регистры ввода/вывода (о семантике которых операцинка ни слухом ни духом) и слушания многих прерываний (аналогично). Т.е. теперь идет унифицированный обмен как целевыми данными, так и настройками для этих данных. Речь относительно IOMMU о том, чтобы некий верификатор "понимал" семантику этих сообщений и енфорснул бы типобезопасность операций DMA.

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

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

WH>>>>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>>>>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
WH>>>Что за бред?
WH>>>Какие еще адреса страниц в манифесте?
V>>ОМГ.
WH>Ты давай по существу.
WH>Или не в состоянии.
WH>Ибо для IOMMU не нужно ничего прописывать ни в каком манифесте.
WH>Ибо страницы выделяются динамически.
WH>И динамически прописываются в IOMMU для данной железки.

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

==========
на остальное потом

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

V>Потому что у нас плоская модель памяти, которая, как мне представлялось, возможна только при неких гарантиях. А тут требуется кусок предвыделенной т.н. "low memory" описать парой адресов в одном процессе-драйвере и передать в другой процесс пользовательского уровня для модификации.
И в чем проблема то?

WH>>Особенно если пользовательский код скажет: Дай мне кусок памяти подходящий для DMA.
WH>>После чего просто отправит его в драйвер.
V>Покажи плиз, как оформить этот небезопасный код, чтобы его пропустил верификатор?
Да запросто.
AllocateDmaMamory(size : int) : option[DmaBuffer]
DmaBuffer это уникальный указатель на память доступную для ДМА.
Если процесс его потеряет то система сразу об этом узнает.
И благодаря уникальности процесс может спокойно передать его в другой процесс.

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

V>Мне пока хочется понять трюк с записью в ПРОИЗВОЛЬНУЮ память на уровне пользовательского кода. Я так-то со многими доводами относительно Сингулярити соглашался из-за того, что считал, что это невозможно. Если же это возможно, хотелось бы увидеть — как?
Откуда ты взял слово ПРОИЗВОЛЬНУЮ я так и не понял.

Но что самое интересное IOMMU полностью снимает эту проблему. А без IOMMU ОС с программной защитой не живут.
Бутылка тоже не жилец.
Так что тут даже отдельного API не понадобится.
Просто выделяем уникальный буфер и все.

V>Это я не тебе. А перевод не такой уж кривой. Автор перевода присылал мне его на коррекцию когда-то, но после нескольких первых откорректированных и возвращенных исправленых абзацев я увидел, что мои уточнения, скажем так, задевают автора перевода... Просто мои уточнения шли в плане тонкостей речевых оборотов (репорт написан довольно свободным языком), и эти исправления спровоцировали спор в стиле "а какая разница???". В общем, я самоустранился от сего неприятного времяпрепровождения, хотя успел сверить перевод с оригиналом. Если не обращать внимание на тонкости речевых оборотов, всё более-менее верно.
Да я бы не сказал. За давностью уже не помню, какие там косяки. Но их там хватает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>Я уже молчу о такой предложенной вещи как "личное" кликанье юзверя с нужными правами мышью по кнопке ОК этого диалога...
WH>Еще можно сделать так чтобы юзер один раз написал в консоли, что данное приложение имеет доступ к данной папке.

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

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

V>Неверно. Страницы памяти можно назначить любые. Полная функциональность DMA сохраняется. Я же сказал — любое обращение к аппаратуре выполняется в стиле DMA — посылкой пачки байт. Только теперь эта пачка называется "сообщением" и идёт обмен сообщениями вместо записи в многие регистры ввода/вывода (о семантике которых операцинка ни слухом ни духом) и слушания многих прерываний (аналогично). Т.е. теперь идет унифицированный обмен как целевыми данными, так и настройками для этих данных. Речь относительно IOMMU о том, чтобы некий верификатор "понимал" семантику этих сообщений и енфорснул бы типобезопасность операций DMA.
Так это будет обеспечивать драйвер IOMMU.
Ему мы верим.
Он сертифицированный.

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

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

При этом интерфейс IOMMU можно очень легко абстрагировать от всех подробностей.

V>В манифесте указываются ресурсы, к которым обращается драйвер. Насколько я понял, еще до загрузки операционки известно, какой драйвер какие физические адреса памяти получит, если они ему нужны в кач-ве ресурсов (как пример — область адресов для "окон" памяти видеокарты). Если верификатор будет знать сообщения IOMMU "в лицо", он сможет проверить, что в этих сообщениях фигурирует только диапазоны памяти (для операций IOMMU->DMA), указанные в манифесте.
Ох.
Одна функция.
BufferLock(buffer : Buffer) : LockedBuffer
Эта функция отмапит данный буфер в адресное пространство железки.
После чего железка сможет работать с ним и только с ним.
У LockedBuffer можно позвать метод Adress который вернет адрес буфера. Этот адрес можно скормить железке.
Ну и BufferUnlock для симметрии.
Либо просто теряем уникальный LockedBuffer и память освобождается. И IOMMU узнает, что нужно эту память забрать у железки.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>И что ты тут вычитал? Это неоднозначность для КС-парсеро. Добавление таблицы символов и проверки идентификаторов по ней делает грамматику однозначной КЗ грамматикой.

Таблица для описанного варианта помогает только для случая, когда типы объявляются перед использованием. А внутри классов некоторые компиляторы С++ это умеют уже ДО того, как встретили объявление типа:

//////////////////////////////////////////////////////////////////
struct S1 {
  void m() { 
    if(MyInt * tmp = getTmp()) {
      // тут компилятор считает MyInt * tmp объявлением переменной
    }
  }

  typedef int MyInt;

  MyInt * getTmp() { return NULL; }

  MyInt * tmp;
};

//////////////////////////////////////////////////////////////////
struct S2 {
  void m() { 
    if(MyInt * tmp = getTmp()) {
      // тут компилятор считает MyInt * tmp умножением 
    }
  }

  int getTmp() { return 42; }

  static struct S3 {
    int & operator*(int) { return tmp; }
  } MyInt;

  static int tmp;
};

В этом примере TDOP загнется. GLR проглотит, не заметив.

VD>Ты сейчас дискредитируешь себя в глазах окружающих.

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

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

V>Дык, я-то понял, что ты от собственной затеи уже отказался. А Mamut еще продолжает по инерции катиться в ту же сторону. Не хочешь прокомментировать его пост, справедливости ради?
Ни от чего я не отказался.
Это тебе в очередной раз твои галлюцинации нашептали.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>>2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.
WH>БРЕД! Полнейший.
WH>С++ невозможно адекватно разобрать контекстно-свободным парсером.
WH>А GLR строго контекстно-свободный.

Вообще-то можно. Просто в случаях полной неоднозначности GLR выдаст столько деревьев сколько удалось разобрать.

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

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

Но, думаю, что мы это тоже сможем сделать.

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

VD>В плане истории важно не то что в нем нет, а то что в нем появилось. К сожалению, я не могу вспомнить ничего.

В нем появилась среда исполнения для нейтивного кода, такая, что эта среда демонстрировала характеристики в плане подгрузки модулей, ГЦ и т.д., ранее присущие лишь интерпретаторам байткода или динамическим языкам. Второй раз на более-менее нормальном уровне это было повторено только в дотнете с их JIT-компилятором.

C>>Чувак, я участвовал в эпичном треде о "синтаксическом оверхеде". Это ты ничерта не знаешь об Обероне.
VD>Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.

Вот то-то и оно. Он участвовал в "синтаксическом оверхеде" и все знания, походу, подчерпнул оттуда. А здесь засыпал вопросами, ответы на которые содержатся на первых страницах Вики... Действительно, эпично вышло. "Не читал, но осуждаю".

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

VD>>Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.

WH>Этот топик тоже сильно. Только место Губанова vdimas занял.

Боюсь, его занял ты, со своим плаванием в обсуждаемом и постоянными загадочными недоговоренностями. Губанов №2 и есть. "Вы ничего не понимаете" (С).

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

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

FR>Я компиляторы писать не собирался и не собираюсь, но судя по размеру описания языка и рантайма, компилятор оберона
FR>гораздо проще чем интерпретатор питона, тем более сейчас когда есть такие штуки как llvm.

Написать компилятор строго типизированного языка при готовом бекенде проще, чем интерпретатор, если за скобками оставить типизацию и кое какие хитрозадые вещи в некоторых языках (в Обероне таких нет). Проверено лично мной на практике.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

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

V>В нем появилась среда исполнения для нейтивного кода, такая, что эта среда демонстрировала характеристики в плане подгрузки модулей, ГЦ

Которые были в ML появившемся в 1973 (Оберон появился в 1986). Так что этот не более чем твоя выдумка.

V>и т.д.,

О "т.д." по подробнее, плиз. А то пока информация не подтверждается.

V>ранее присущие лишь интерпретаторам байткода или динамическим языкам.

Ага. Таким как ML. Пойду за попкорном, продолжай.

V>Второй раз на более-менее нормальном уровне это было повторено только в дотнете с их JIT-компилятором.

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

V>Вот то-то и оно. Он участвовал в "синтаксическом оверхеде" и все знания, походу, подчерпнул оттуда. А здесь засыпал вопросами, ответы на которые содержатся на первых страницах Вики... Действительно, эпично вышло. "Не читал, но осуждаю".

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

Лично моего мнения об Обероне ты не изменил. Язык тупиковый. Единственная его идея — минимализм. Может оно не плохо для обучения, но не для практического использования.

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

V>Если еще все либы без этого модуля перепишешь. В общем, это ты на полвопроса ответил. Вопрос звучал так: Оберону надо садиться на аппаратаное прерывания и прочие DMA, потому что операционка, а вот зачем такой модуль в OCaml — непонятно.

А Обероны для Виндовс таких модулей не имеют? Если имеют, то хочу услышать ответ на данный вопрос для них.

V>Ну ок, вот интересная транзакция, X12 271.
V>Небольшая, но показывающая всю убогость парсеров с откатами для определенных сценариев.

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

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

Оберон ушел в историю. Почтим память старка и пойдем дальше.

V>Зачем руками. Программирование в ограничениях. Вывод типов как, по твоему работает? Это точно такая же задача — найти решение при наличии фактов и правил.

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

WH>>Это я еще про восстановление после ошибок говорить не начинал.

V>А ты начни. GLR может порекомендовать правильные конструкции в месте ошибки, в отличии от LL(k), который тоже может порекомендовать, ес-но, правда на порядок большее их мн-во. ))

Опять же. Не надо громких слов. Заявил, что GLR есть какие-то преимущества — обоснуй.

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

Что тут может дать GLR и где можно посмотреть реализации (чтобы попробовать их)?

V>>>Отличие от нисходящих парсеров с откатами в том, что парсеры с откатами в случае неоднозначностей грамматики имеют склонность вечно зацикливаться.
WH>>Бред.

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

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

V> Именно исходная неоднозначность грамматики может не дать её полностью факторизовать.

Факторизация решает другую проблему парсеров с бэктрекингом — исключение экспоненциального случая. В парсере Н2 используется частичная мемоизация которая исключает экспоненту в большинстве случаев в автоматическом режиме. Так что ему факторизация не нужна.

Скажу больше Н2-шный парсер даже провоцирует на отказ от факторизации, так как это упрощает получаемое АСТ.

V>Поэтому-то я не люблю LL(k) для неоднозначных грамматик,

LL то тут причем? В нем нет бэктрекинга, а значит LL-грамматики не могут разбирать неоднозначные грамматики.

V>что в таких случаях в LL(K) надо описывать не целевую грамматику, а некую промежуточную. А потом действительно, ручками и только ручками переводить промежуточную в целевую.

Что-то ты совсем не в ту степь пошел. LL(k) обсуждать бессмысленно.

Что касается алгоритма N2, то вот фрагмент грамматики самого N2. Как не сложно убедиться никакой левой факторизации нет. И это не приводит к каким-то проблемам, так как парсинг подправил мемоизируется.

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

Можно расшифровать понятия "мощность представления неодозначного результата" и "оперативный парсер"?

Да и вообще хотелось бы объяснений. Голословные заявления как-то напрягают.

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

WH>>Языки программирования однозначны.

V>Но не в координатах КС-разбора.

Вообще-то из современных ЯП только С++ и Немерл не может быть отпарсен КС-парсером. И их зависимость от контекста довольно простая.

V>Не начнут. Про С/С++ уже обсуждали. У него идет предварительное объявление типов именно чтобы "спокойно добавить таблицу имен". Блин, но это же 70-е года, мало памяти и однопроходность парсера... Сейчас-то всё тоже самое можно на GLR без предварительного объявления типов. Просто каждый встреченный символ будет отбрасывать ранее сохраненные неоднозначности. И что характерно — опять же оперативным образом, то бишь не накапливая ненужную информацию.

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

Где-нибудь есть информация о производительности GLR-парсеров?

V>Та блин, GLR — это просто самый общий вариант для восходящего разбора (и дословный перевод такой же), отец семейства, кароч. Есть же LALR, всевозможные модификации SLR и т.д. Ты только копни в эту область. Прямо сейчас эта область исследуется активнее всего, (случайно, что ле?). ИМХО, потому что оперативность — это отличное качество для современных скоростей обмена информацией, т.е. она хорошо смотрится при конвейерной организации обработки этой информации.

У любых LR-парсеров есть проблемы с динамической расширяемостью. Плюс восходящий анализ сильно отличается от того как код читается человеком. Отсюда проблемы с диагностикой ошибок. А описывать в грамматике все возможные случаи опечаток как-то очень не просто.

V>И да, конкретно против TDOP я ничего не имею,

Ты еще за одно осознай, что алгоритм используемый в N2 не эквивалентен TDOP. Это совмещение TDOP, PEG и пидуманных Вольфхаундом улучшений. По сему нельзя рассуждать о нем как о TDOP или как о LL(k).

V>а LL(1) вообще считаю НАИЛУЧШИМ вариантом для тех случаев, где исходная грамматика приводима к LL(1) без необходимости ее подмены на промежуточную (нецелевую) грамматику. Поэтому пользовал LL(1) неоднократно. Моя мысль банально в том, что не существует одного решения на все случаи жизни. А вы как-то умудрились целый пласт восходящего разбора проигнорировать.

Ну, почему же? По факту TDOP фактически восходящий алгоритм (хотя выглядит как нисходящий). Мы не разделяем твоих симпатий к LR. Причем даже не потому что он восходящий, а потому что он автоматный. Нам нужен динамически расширяемый парсер. Тут ни LL ни LR особо не годятся, так как подразумевают автоматную реализацию.

У TDOP и рекурсивного спуска с откатами есть одно неоспоримое преимущество — эти алгоритмы позволяют динамически комбинировать парсеры.

Можно в середине разбора взять и изменить GLR-парсер (грамматику)?

V>Это слишком дохрена игнорировать надо. Помнишь то обсуждение, чтобы при преобразовании частей правил в ДКА для вашего ПЕГ сохранялись исходные нетерминалы? Это же натуральная вотчина для восходящего разбора — генерить именно такие ДКА (для регулярной грамматики вроде бы достаточен LR(0) ).

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

V>Такая же скорость разбора, ровно один шаг алгоритма на каждый символ, и достоверно восстановленное синтаксическое дерево произвольной глубины. Я ХЗ почему ты не обратил внимание на этот момент еще тогда. LR(0) вообще можно юзать вместо ДКА для случаев, когда грамматика явно приводима к регулярной, но нужны не только сами разобранные строки (нетерминал верхнего уровня), но и обязательно ход разбора, то бишь дерево.

Для разбора дерева рекурсивный спуск подходит точно так же как

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>В этом обсуждении, в частности, упомянут и ДРАКОН:

С какого боку тут Дрокон? Нельзя же совать его во все дыры?

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

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

C>>Ты думаешь я зря спросил у vdimas'а какую версию Оберона взять?
C>>Я всё жду пока он попытется найти работающий компилятор на их сайте. Муахахахаха.

V>Тебя тоже в гугл больше не пускают как и Мамута? Вот уже точно муа... ))
V>http://www.ethoberon.ethz.ch/download.html

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

Integrates Oberon with Windows, Netscape and ActiveX

Бред выдающий тот факт, что со времен Вынь 95 никому не было дела до этой поделки.

V>http://bluebottle.ethz.ch/download.html

За фиг кому-то нужны какие-то левые ОС? Всем нужны компиляторы под виндовс или линукс. Причем желательно с поддержкой IDE.

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

V>Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop,

Ты шутишь? Как можно сравнивать вордпэд пристствующий в Блэкбоксе со средой разработки? Где (хотя бы) автодополение при вводе и подсветка синтаксиса?

Потом сам Блэкбокс не является Обероном по сути и использует крайне примтивный GC который не применим в более-менее нагруженных по памяти проектах.

Это игрушка для институтов. Может на ней и можно учить программировать, но программировать на ней в 21 веке нельзя.

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

VD>Бред выдающий тот факт, что со времен Вынь 95 никому не было дела до этой поделки.

Им и самим нет дела до компилятора под винду. Сам язык без своей среды исполнения полезен не более, чем комплятор C# без дотнета.

VD>За фиг кому-то нужны какие-то левые ОС? Всем нужны компиляторы под виндовс или линукс. Причем желательно с поддержкой IDE.

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

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

V>Боюсь, его занял ты, со своим плаванием в обсуждаемом и постоянными загадочными недоговоренностями. Губанов №2 и есть. "Вы ничего не понимаете" (С).
Хватит говорить о себе во множественном числе.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения. А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

Ждём мобилу с оберон-осью

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

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

V>>Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop,
VD>Ты шутишь? Как можно сравнивать вордпэд пристствующий в Блэкбоксе со средой разработки? Где (хотя бы) автодополение при вводе и подсветка синтаксиса?

Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).
Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.

VD>Потом сам Блэкбокс не является Обероном по сути и использует крайне примтивный GC который не применим в более-менее нагруженных по памяти проектах.

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

VD>Это игрушка для институтов. Может на ней и можно учить программировать, но программировать на ней в 21 веке нельзя.

Почему нет? Какие-нить расчетные утилиты, вспомогательные программы? Я гогда-то даже на VB for DOS писал много всякого такого, т.к. однажды прикинул статистику, и выходило, что в расчетных утилитках поверх TurboVision непростительно большую долю кода в исходниках отнимает обслуживание самого TurboVision, а он же не целевой ни разу...

Ну и в плане адекватности под учебный процесс... Во многих ВУЗах до сих пор лабораторки по программированию на TP пишут... Вот уж

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

ВП>>В этом обсуждении, в частности, упомянут и ДРАКОН:
VD>С какого боку тут Дрокон? Нельзя же совать его во все дыры?

А эта ветка иначально в обсуждении ДРАКОНА жила, пока ее не выделили.

А насчет Blocky полностью согласен. Они так умудрились сделать графический дизайн уонструкция языка, что многие правиа ДРАКОНА по формированию графического представления алгоритмов выполняются автоматически.

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

AVK>Написать компилятор строго типизированного языка при готовом бекенде проще, чем интерпретатор, если за скобками оставить типизацию и кое какие хитрозадые вещи в некоторых языках (в Обероне таких нет). Проверено лично мной на практике.

А какой интерпретатор вышел сложнее какого компилятора?

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

V>>В нем появилась среда исполнения для нейтивного кода, такая, что эта среда демонстрировала характеристики в плане подгрузки модулей, ГЦ
VD>Которые были в ML появившемся в 1973 (Оберон появился в 1986). Так что этот не более чем твоя выдумка.

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

V>>ранее присущие лишь интерпретаторам байткода или динамическим языкам.
VD>Ага. Таким как ML. Пойду за попкорном, продолжай.

V>>Второй раз на более-менее нормальном уровне это было повторено только в дотнете с их JIT-компилятором.
VD>Яву мы опускаем за некошерностью?

А разве это был не интерпретатор в до-дотнетные времена? Выходит, опускаем... И чем ниже, тем справделивее.. ))

VD>В прочем, нормального уровня в Обероне не было никогда. Можно посмотреть реализацию Оберона для Виндовс с приличным GC?

Выделенное — оксюморон сам по себе, вообще-то. Ты обсуждение вообще читал? Т.е. оно такое даже есть, согласен, тот же BlackBox, но это уже частные поделки.

VD>А то все что пробовали в прошлом эпическом сраче про синтаксический оверхэд обделалалось на примитивных тестах замусоривших кучу.

Это ты про BlackBox, надо полагать. ЧТД.

А не пробовал хотя бы WinAosMini? А сам полноценный Оберон, не? А то ведь с тем же успехом можно было судить о дотнете по ранним бетам Mono — тот был бы epic fail.

VD>Лично моего мнения об Обероне ты не изменил. Язык тупиковый. Единственная его идея — минимализм. Может оно не плохо для обучения, но не для практического использования.

А я сам язык и не обсуждал, если заметил. Лишь выдал одно маленькое замечание — он чуть почище, чем изветсный мне Турбо-Паскаль. Это всё. Но блин, мне даже на C# первого дотнета пришлось пару лет поработать, и ничего, не умер до сих пор... Хотя такое брр еще поискать...

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

V>А какой интерпретатор вышел сложнее какого компилятора?

Некий внутренний DSL. Сперва был написан интрпретатор, потом переделан в компилятор под CLR с сильным сокращением объема исходников.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

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

V>Есть и так и как угодно.

Нет, удобного синтаксиса для работы с диапазонами в Си нет.

V>Спасибо, поржал. Без иронии, просто прикольный ход мыслей.

Ну, это и была шутка для оживления разговора.

V>никто не знает как лучше.

Никто не знает как лучше для всех. Но многие знают как лучше для n человек. так вот это n в случае Вирта пренебрежимо мало. И для краткости можно записать: "Вирт не знает как лучше".

V>Тем не менее, общие принципы в современных императивных языках шлифовались не без заимствований... и у Вирта в т.ч.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Либо "родной" стек вообще не используется. В SML/NJ и GHC — именно так.

V>Разница лишь в том, какой вид многозадачности доступен в такой системе — кооперативный, или полноценный с вытеснениями. ИМХО, для обсуждаемой задачи, когда агенты должны постоянно сидеть в ожидании сигналов ввода-вывода каналов (прямо по условию) разница м/у видами многозадачности не столь принципиальна.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>А мне показалось — чистота и ленивость.

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

V>А побочные эффекты надо заворачивать в монаду-последовательность и эта монада появилась не сразу, так?

Да, это один из результатов экспериментов по изоляции и т.д.

V>Функциональный подход хорош при вычислении данных и плох, когда эти вычисленные данные надо куда-то девать.

Ничего не понял. Это можно как-то раскрыть?

V>ИМХО, наличие мутабельных механизмов диктует соображение практичной применимости языка.

Ну да, все правильно. Чистые ФЯ и не запрещают мутабельность — они дают инструментарий для разделения кода на чистый и остальной.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Гарантирует не хуже Хаскеля. Такой уровень гарантий тебя устроит? Или в природе существуют гарантии еще выше?

Справедливости ради нужно отметить, что хуже. К примеру, аналоги обероновского SYSTEM в хаскеле все-таки отключаются.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>Им и самим нет дела до компилятора под винду. Сам язык без своей среды исполнения полезен не более, чем комплятор C# без дотнета.

Так и запишем. Под виндой Оберона нет, так как он никому не нужен.

V>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения.

Круг ембедщиков очень узок. Обсуждать это тут бессмысленно.

V> А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

Эту хрень ты рассказывай детям.

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

ARK>Минутку. Стало быть, в API будет такой сервис, который предоставляет возможность слать поток байт в сеть.
ARK>Наш вредоносный редактор документов открывает файл через OpenFileDialog (точнее пользователь открывает для работы) и шлет все его байты в сеть. Ну, дали мы редактору при установке такое право, он попросил. Такой сценарий возможен?
1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?
2. Если редактор попросил доступ в сеть, то вы можете дать ему доступ в конкретное место. Скажем, в облачный сторадж — https://documentcloud.com/. Вы знаете, что это за сайт, и доверяете ему свои документы. Втихушку открыть канал на левый сервер приложение не сможет — ровно потому же, что не сможет и открыть произвольный файл. Ему этот сокет отдаёт внешнее доверенное приложение, работающее через ручное подтверждение в гуе.
3. Браузер при установке запросит у вас разрешение ходить на любые адреса, и вы ему это позволите — ровно потому, что у него зато нет доступа к произвольным файлам.

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

V>>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения. А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

S>Ждём мобилу с оберон-осью

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

Не так. Ждем спутников на Андроиде. А вот как захватит рынок спутников, тогда поубавится смысл обсуждать тормозные среды исполнения.

=========
Ну и дело не в кач-вах среды ни разу, ес-но. Там с одной стороны толкает MS, с другой Google. Всего-навсего две самые мощные IT-компании... Какие мелочи, право.

Здравствуйте, vdimas, Вы писали:

V>Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).

Ау! Ты часом не заблудился? Ты пришел на форум современных разработчиков, а не к срперам из дома престарелых программистов.

Тут "вроде как где-то" не катит. А подсветка "через синтаксис" вызовет только смех.

Давай называть вещи своими именами. Оберона на ПК практически нет. Есть ублюдочный БлэкБокс застрявший в совем развитии в 80-ых годах.

Есть ли он еще где-то тоже большой вопрос. Потому как почитав список успешных проектов, который ты давал, и не найдя ни одного тому подтверждения по указанным ссылкам, верить уже не хочется.

V>Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась.

Конечно. Языку вообще ничего не нужно. Он же не живой. Нужно людям. Возможно ты не в их числе. Но я вот точно не буду использовать язык без нормальной поддержки IDE.

V> Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи.

Ага. В 80-ых и начале 90-ых. Сейчас — нет. И Дельфи тому отличное подтверждение.

V>Ну и еще, там же не текстовый документ, а гипертекстовый.

Это никого не трогает. Да и не нужно это никому за пределами универов.

V>Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.

Ой. Ну, не надо гнать. Видели мы эту полноценную документацию. Поверхностный самопал мало дающий на практике.

VD>>Потом сам Блэкбокс не является Обероном по сути и использует крайне примтивный GC который не применим в более-менее нагруженных по памяти проектах.

V>Дык, это же среда, работающая поверх обычной операционки. Ей в таком сценарии некомфортно.

Плохому танцору яйца мешают. ББ — это унылое говно потому что делают его безрукие неудачники.

V>Я и не собрался обсуждать характеристики BackBox, просто разговор шел не только о характеристиках Оберона, но и доступности инструментария. В этой среде можно удобно поотлаживаться, без всяких виртуалок.

Просто ненужность инструмента приводит к тому, что интересуются им только бездарности не снмогшие уйти от паскалей которые они освоили на заре своей карьеры. Вот и пытаются они найти спасательный круг в Оберонах. А наличие такого безрукого комьюнити приводит к столь плачевному состоянию средства разработки.

Итого язык не нужен одаренным людям и потому не развиваются средства разработки под него. Что тут еще можно обсуждать?

VD>>Это игрушка для институтов. Может на ней и можно учить программировать, но программировать на ней в 21 веке нельзя.

V>Почему нет?

Потому что унылое говно. И потому что есть масса реально интересных языков с намного более качественными инструментами под них.

V>Какие-нить расчетные утилиты, вспомогательные программы?

А зачем же их писать на унылом говне то?

Я еще понимаю почему Оберон может быть интересен ембедщикам. Язык простой. Компилятор для него тоже должен быть не сложный. Переносить на новое железо проще. Плюс язык безопасный. Если все равно портировать на новое железо, а задачи простые, то моно о нем и задуматься. Особенно это актуально, если зарплаты низкие и работают у тебя в основном неудачники.

Ну, для обучения, там еще туда-сюда. Но для реальной разработки?

У этого говна — ББ нет даже возможности версии отслеживать. А от ОЛЕ-объектов в коде нет никакого толку на практике.

V>Ну и в плане адекватности под учебный процесс... Во многих ВУЗах до сих пор лабораторки по программированию на TP пишут... Вот уж

Это ни разу не оправдывать унылость и бессмысленность Оберона.

Здравствуйте, vdimas, Вы писали:
V>Блин, Мамут, давай лучше о политике, там хоть более предметно выходит. Подход настолько отличается, что натянуть одно на другое вообще никак. В нормальных защищенных соединениях у тебя будет просто поток байт по ровно одному TCP-соединению и по какому-то хрен его знает высокоуровнемому протоколу сверху TCP, о котором операционка ни слухом ни духом. Передать удаленно хендл открытого файла (как предложил Wolfhound) — вообще никак, чтобы контроллировать процесс передачи и последующее использование операционкой.
Как всегда — много умных слов, ни тени понимания.
Система работает примитивно просто (это изобрели ещё в доисторические времена): каждое приложение получает доступ только к тому, что ему дали. Обходных путей не существует.
В десктопе упрощённая цепочка выглядит так:
1. Есть приложение Explorer, которому мы сильно доверяем. Ему в начале времён дали доступ ко всем дискам, и к АПИ типа CreateFile().
2. Есть произвольное другое приложение, которое по умолчанию ничего не видит и не имеет. Вызвать CreateFile оно не может. Всё, что оно может сделать — вызвать OpenFileDialog(), который возвращает сразу хэндлы файлов, которые указал пользователь.

Ключевой момент: Explorer здесь не является частью модели безопасности. Это всего лишь одна из надстроек, построенных поверх низкоуровневых механизмов, которых в оберонах нету.

Если мне удобно, то я могу дать SQL Server всеобъемлющие права на все диски — и проблема будет решена: он будет открывать всё подряд.
Если я не доверяю SQL Server (потому что он у меня исполняет скрипты, присланные непонятно кем), то я заставлю его работать с внешним приложением-конфигуратором, которое будет ему давать доступ к файлам, которые лично я ему подтвердил — хотя бы через конфиг-файл, права на доступ к которому я получаю тем же способом через OpenFileDialog на своём администраторском ноутбуке.

Поэтому все рассуждения про байты, TCP-соединения, передачи хендлов, тут совершенно не про то. Речь только про то, как исполняющая среда решает, какие методы каких объектов кому разрешено вызывать, и какие значения параметров позволены быть у этих методов.
Если такая система есть — значит, можно построить надёжную конструкцию взаимного доверия. Если, конечно, продумать вопросы социальной инженерии — но против неё вообще ничего не помогает.
Если такой системы нет — то рассуждения про безопасность можно смело сливать в канализационный прибор, так как всегда будет возможность под видом калькулятора подсунуть программу, которая делает что угодно с привилегиями текущего пользователя. Изоляция одного лишь модуля SYSTEM — детский сад. В нормальной среде все компоненты параноидальны по-максимуму друг к другу.

Здравствуйте, vdimas, Вы писали:

V>А эта ветка иначально в обсуждении ДРАКОНА жила, пока ее не выделили.

Раз выделили, значит она к Дракону отношение не имеет.

Здравствуйте, WolfHound, Вы писали:
WH>

Лолшто?
WH>Открытые ключи они на то и открытые чтобы ими ничего расшифровать было нельзя.
WH>Или ты собрался сломать ассиметричный шифр? Удачи.
+1. Всегда радуюсь, когда люди мне рассказывают, что SSL не может работать. Особенно, когда это сопровождается вееробразными движениями пальцев и отеческим тоном.

Здравствуйте, VladD2, Вы писали:

V>>Им и самим нет дела до компилятора под винду. Сам язык без своей среды исполнения полезен не более, чем комплятор C# без дотнета.
VD>Так и запишем. Под виндой Оберона нет, так как он никому не нужен.

Так и есть. Винда Оберону не нужна.

V>>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения.
VD>Круг ембедщиков очень узок. Обсуждать это тут бессмысленно.

Зато круг php-шников очень широк. )))
Ну ивсе относительно насчет embedded, просто ты страшно далек от народа. Кол-во embedded-устройств уже прямо сейчас превышает кол-во компов общего назначения на порядки и будет чем дальше, тем больше. Даже в полноценном компе от 2-х до 5-ти тех самых утсройств, разарботка которых ведется именно как embedded.

V>> А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

VD>Эту хрень ты рассказывай детям.

Я с этой хренью ежедневно борюсь. И уже давно уперлись в пределы быстродейтсвия самих операционок. За то время пока операционка всего лишь пару раз переключит контекст исполнения, + наложится штраф на эффективность последующего кода сразу после переключения, можно распарсить несколько сложных сообщений и обойти несколько сотен узлов алгоритма юзверской логики. Не на дотнете, понятно.

Детям расскажу про эту хрень обязательно, не переживай. Хотя, может им повезет и они будут сидеть под совсем другими операционками.

Здравствуйте, vdimas, Вы писали:

VD>>В прочем, нормального уровня в Обероне не было никогда. Можно посмотреть реализацию Оберона для Виндовс с приличным GC?

V>Выделенное — оксюморон сам по себе, вообще-то. Ты обсуждение вообще читал? Т.е. оно такое даже есть, согласен, тот же BlackBox, но это уже частные поделки.

Слушай кончай троллить. Я тебя кормить не намерен. Ты уже договорился до полнешего бреда. Виндвос, видите ли, мешает вам. Яве и дотнету не мешает, а Оберону мешает.

Намеренный бред с целью провокации флэйма.

Здравствуйте, VladD2, Вы писали:

VD>В этом плане GLR довольно удобен, так как позволяет отложить разрешение контекстных неоднозначностей на момент после окончания основного парсинга.
VD>Но, думаю, что мы это тоже сможем сделать.

Для нисходящих парсеров это неудобно. См. что вышло в алгоритме Эрли.

Здравствуйте, vdimas, Вы писали:

V>А не пробовал хотя бы WinAosMini? А сам полноценный Оберон, не? А то ведь с тем же успехом можно было судить о дотнете по ранним бетам Mono — тот был бы epic fail.

Тебя тут уже сто раз просили дать ссылку на реализацию Оберона которую можно использовать на практике. Но такой нет, вот ты и изворачиваешься как уж на сковородке.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Ждём мобилу с оберон-осью

Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

V>Не так. Ждем спутников на Андроиде. А вот как захватит рынок спутников, тогда поубавится смысл обсуждать тормозные среды исполнения.

Спутинки на андройде в природе имеются (гугл в помощь)
http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/

V>=========
V>Ну и дело не в кач-вах среды ни разу, ес-но. Там с одной стороны толкает MS, с другой Google. Всего-навсего две самые мощные IT-компании... Какие мелочи, право.

Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?

Здравствуйте, vdimas, Вы писали:

V>Откроет файл с магическим именем, через который получит образ винта, и сольет этот образ куда-нить в сеть. Делов-то...
У калькулятора не будет доступа к "открытию файла с магическим именем". Ему придётся вызвать специальную программу, в которой пользователь через GUI должен будет указать файл, который надо открыть. Перед тем, как слить образ куда-то в сеть, нужно получить доступ к сетевому каналу — тоже через специальную программу, которая спросит у пользователя, точно ли он хочет дать этому приложению доступ до сайта для слива.
Напрямую к драйверу сети приложение доступ всё равно не получит — не нужен он ему.
А если нужен — скажем, это "приложение" что-то типа VPN или ещё специфичнее — то кто ж ему даст доступ к файлам?

Здравствуйте, WolfHound, Вы писали:

WH>Ты конкретную ссылку дай.

Кстати, рядом привел: http://www.rsdn.ru/forum/philosophy/4827038.1.aspx

(До этого, думая что ты помнишь С++, пересказывал тебе похожий сценарий словами насчет гипотетического языка, который как С++, только без предварительного объевления.)

V>>Это медицинский факт для нисходящего разбора в случае некоторых неоднозначностей, приводящих к левой рекурсии.
WH>Вот только мой парсер жрет левую рекурсию не напрягаясь.

Да ничего он не жрет, у него просто детерминированный алгоритм разбора, поэтому он не сможет разобрать аналогичную неоднозначную грамматику, о которой речь, принципиально.

V>>Именно исходная неоднозначность грамматики может не дать её полностью факторизовать.
WH>Языки программирования неоднозначны.

Ты хотел сказать однозначны, надеюсь. Грамматика для КС-парсера всё-равно будет неоднозначной. Мы это раз в пол-года снова и снова будем обсуждать?

И да, я помню абсолютно все твои доводы (ты уже на 10й круг пошел минимум за последний год) и внимательно посмотрел на сам алгоритм работы TDOP. Он приципиально сможет разобрать только простые, однозначные на уровне синтаксиса конструкции.

V>>Поэтому-то я не люблю LL(k) для неоднозначных грамматик, что в таких случаях в LL(K) надо описывать не целевую грамматику, а некую промежуточную. А потом действительно, ручками и только ручками переводить промежуточную в целевую.
WH>Те, по-твоему, нисходящие парсеры это только LL(K)?

LL(1) по эффективности не уступает LR(0) и даже просто лексеру на ДКА. Поэтому, ес-но, лично у меня он заслуживает внимания и всегда первый претендент, если грамматика позволяет.

WH>>>Языки программирования однозначны.
V>>Но не в координатах КС-разбора.
WH>Меня КС разбор не волнует.

Не говори гоп.

V>>Та блин, GLR — это просто самый общий вариант для восходящего разбора (и дословный перевод такой же), отец семейства, кароч. Есть же LALR, всевозможные модификации SLR и т.д. Ты только копни в эту область. Прямо сейчас эта область исследуется активнее всего, (случайно, что ле?).
WH>Вся драконщина это одна большая случайность.

Какая прелесть. Ниасиливший тему студент пытается организовать движение против невыученных им уроков.

V>>И да, конкретно против TDOP я ничего не имею,
WH>Только ты не понимаешь что это. И как он работает.

Если в том смысле, что "не проникся", ну т.е. как собутыльник "ты ведь меня понимаешь, да?"... то нет, ес-но, не проникся. Понимать-то там нечего, ограничения подхода TDOP видны невооруженным взглядом. Но вот ты этого в упор не видишь, бо тебе не с чем сравнить. Ну тогда поизобретай велисипеды. Ссылку уже дал, развлекайся.

WH>Иначе бы не вещал глупости на тему того что нужно его грамматику факторизовать.

Очередная твоя брехня.
1. Речь была о факторизации исходной неоднозначной грамматики;
2. Грамматика TDOP однозначна.
3. Грамматикой это назвать можно лишь с большой натяжкой — это алгоритм разбора, как и ПЕГ. По мне — никакой грамматикой там и не пахнет. То бишь описание правил для парсера не есть описание грамматики в терминах редукций, например, а есть описание работы некоего императивного алгоритма.
4. Любой императивный алгоритм по своей природе ограничивает исходный класс разбираемых грамматик только теми, св-ва которых ложатся на этот алгоритм. В этом плане TDOP недалеко ушел от других, вполне конкретных императивных алгоритмов разбора, которые ВСЕГДА определяют лишь некий подкласс разбираемых грамматик (LL(k), LALR, SRL и т.д.). Это всего-лишь алгоритмы, ограниченные неким подклассом грамматик, и для них тоже подается описание грамматики в некоем понятном им виде. (вовсе не в таком, как эта грамматика представлена в терминах редукций).

Здравствуйте, WolfHound, Вы писали:

V>>Гы, если не понимаешь, то для тебя многие вещи пустой звук, ес-но... как для троешников на уроках в школе. Ну и плюс приходится тратить силы на борьбу с тобой, бо ведешь спор очень скользско (хотя бы насчет альфы пример).

WH>И альфой я абсолютно буквален. И сразу сказал куда смотреть.
WH>Но ты не можешь даже википедию открыть.

Да вменяем ли ты? Тебе было сказано, как работает альфа — понятно. Поделись, где ты увидел проблему.

WH>И посмотреть на размер формулы, которая смешивает два пикселя с альфой.

Так она тебя вгоняет в ступор или в чем у тебя дело-то? Или на полном серьезе считаешь, что у меня интернет не той системы? Или в моем справочнике по студийной видеотехнике думаешь другие формулы для т.н. "ключевого канала" (он же альфа-канал) приведены? То, что ты решил повалять дурака было понятно сразу, только валять дурака принято малость скромнее.

WH>И чем дальше, тем больше я убеждаюсь, что разговор с тобой не имеет смысла.

В такой манере — ес-но не имеет. Ты же за слова не отвечаешь, а я дотошный. Вот тебе и некомфотно. Тебе же нужна аудитория, в рот заглядывающая..

Здравствуйте, vdimas, Вы писали:

V>Да вменяем ли ты?
Ты точно нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, VladD2, Вы писали:

VD>Тут вряд ли найдутся знатоки формата. Ты привел бы, действительно, грамматику и пояснил в чем косяк.

Грамматику в удобном вам виде я не нашел, везде дается в том же виде как и уменя в PDF в доке одного из проектов. Т.е. вы сможете найти ее легко на первых страницах гугла в таком же как у меня виде.
Грамматика там несложная, а косяк в EDI торчит в самом сценарии электронного документооборота.

Немного терминологии. В EDI есть сегменты — это именованные записи. С т.ч. парсера документа — это терминалы, ему на вход идут коды сегментов. И есть циклы. Цикл — это повторение некоего шаблона из сегментов и циклов от 0 до нескольких раз. Сегменты тоже могут повторяться от 0 до нескольких раз, но специальный цикл-нетерминал под них не заводят, это просто отображение поля-массива в сообщении. Рекурсии в циклах нет. То бишь, проверить входящее сообщение на принадлежность грамматике можно даже с помощью регулярной грамматики, если имена циклов (нетерминалы) считать нецелевыми, т.е. отбросить их в процессе приведения НКА в ДКА. Но отбросить их нельзя требуется именно восстановить дерево разбора. (Перекликается с той вашей задачей в ПЕГ, если помнишь, когда терялись нетерминалы при минимизации ДКА).

Неоднозначность берется от опциональности циклов и сегментов. Даже один и тот же сегмент в одном цикле может быть массивом, в другом — единичным элементом. А по факту придет только один элемент, вот тебе и неоднозначность, это массив с кол-вом элементов 1, или другой цикл, где этот элемент не является массивом.

Но сами документы EDI всегда однозначны. Т.е. даже с учетом опциональных сегментов сам документ будет построен так, что рано или поздно в конце останется только один вариант разбора. Вот этот момент и есть мега-косяк, когда сервер зачитывает приличный трафик из этих документов и обрабатывает их по конвейерной схеме. В моих экспериментах с нисходящим парсингом я получал сотни откатов на средние по размерам документы. Это был приплызд. Имено в этом месте я попробовал Эрли (допиливал ваш вариант с сайта), изучал варианты с мемоизацией, но умножал это дело на предельные размеры документов (мегабайты, и это "одно выражение" если проводить аналогию с языками программирования), то у меня выходило, что не хватит всей памяти компьютера.

Потом попробовал обкатанный ранее GLR — и всё сразу стало на свои места. В среднем идут себе 2-4 ветки вдоль всего разбора. Какие-то появляются, какие-то исчезают... В максимальных точках доходило до 3-х десятков веток, но эти места редки и коротки, быстро проскакиваются и дальше опять идет малое число вариантов. Работа парсера: по сути есть одна таблица автомата разбора на каждую транзакцию (транзацкция = электронный документ), по ней (таблице) протягиваются те самые 2-4 курсора. Согласись, смешные затраты на обеспечение параллельности. Хранить исходную последовательность для целей отката не надо. В каких-то местах у нас все варианты "схлопываются" до 1-го, вот до этой точки уже можно отдавать высокоуровневые циклы (узлы дерева документа) на прикладную валидацию и расшифровку значений. Причем, сценариев "схлопывания" несколько: это когда вообще остается один вариант из всех, либо когда всё множество неоднозначных вариантов распознает данный цикл как один и тот же (бывает и такое). Т.е. выходит прикольно: документ еще не разобран целиком, а уже полным ходом идет его обработка. Такое возможно потому, что алгоримт указывает на "достоверно-разобранные" куски входного потока. Далее. Все неоднозначные варианты шарят м/у собой одинаковые части до момента возникновения неоднозначности в каждой ветке дерева. Момент работы с памятью тоже характерно приятен: "отваливающиеся" узлы погибших неверных веток разбора переиспользуются на каждом шаге для новых. Даже в дотнете это дало приличных буст для скорости разбора.

VD>Это называется спекулятивная типизация. Я что-то пока не слышал о парсерах предоставляющих услуги типизации да еще и в для произвольной системы типов. Если тебе такие известны, то дай ссылку, плиз.

Ес-но это этап после парсинга. Просто этому этапу согласно его природы абсоютно до фени — один там вариант, или несколько. Например, в процессе вывода типов всё-равно перебираются мн-во вариантов, но остаются только такие, где всё однозначно стыкуется. Я лишь заметил, что в таких условиях неоднозначный выхлоп GLR не должен привести с серьезным переделкам остального, даже если речь идет о выводе типов (то бишь "модных" языках).

V>>А ты начни. GLR может порекомендовать правильные конструкции в месте ошибки, в отличии от LL(k), который тоже может порекомендовать, ес-но, правда на порядок большее их мн-во. ))
VD>Опять же. Не надо громких слов. Заявил, что GLR есть какие-то преимущества — обоснуй.

Под GLR сидит LR(0), а у него всегда в месте конфликта есть список "удачных" продолжений. Более-менее вменяемый аналогичный этот список только у LL(1), а там где k>1, там список может быть невменяемый по размеру.

VD>Потом порекомендовать — это детский сад. Правильный парсер должен в автомате выявить минимально-возможный ошибочный код, восстановить состояние парсера и продолжить разбор. При этом нужно еще дать качественную диагностику и постараться разобрать то правило на котором произошел облом, так чтобы потом в IDE можно было информацию по правильно разобранным частям получить.

1. Восходящие парсеры можно вернуть в произвольную точку разбора, но для ЯВУ вообще достаточноскипнуть текущее выражение и найти следующее.
2. Для ЯВУ вопрос отката вообще как бы несложен. Парсер ЯВУ можно условно составить из нескольких вложенных парсеров: парсеров общей структуры программы, парсеров выражений языка и т.д. Интересный момент в том, что на нисходящих парсерах (типа ПЕГ), такое описание структуры программы через вложенные парсеры происходит естественным образом. Но самый интересный момент в том, что на уровне выражений языка более удобные восходящие парсеры. Помню когда-то подобные рассуждения порвали тебе мозг и ты меня попытался высмеять... хотя техника ПЕГ — это разновидность комбинаторного парсинга, то бишь лично у меня бы не было никаких комплексов по поводу того, что на самом низком "тупиковом" уровне комбинации парсеров сидел бы восходящий разбор. ДКА-то лексера всё-равно по восходящему принципу работает и ничего.

Как раз удачный уже привел рядом:
http://www.rsdn.ru/forum/philosophy/4827038.1.aspx

============
на остальное потом.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vdimas, Вы писали:
V>>Блин, Мамут, давай лучше о политике, там хоть более предметно выходит. Подход настолько отличается, что натянуть одно на другое вообще никак. В нормальных защищенных соединениях у тебя будет просто поток байт по ровно одному TCP-соединению и по какому-то хрен его знает высокоуровнемому протоколу сверху TCP, о котором операционка ни слухом ни духом. Передать удаленно хендл открытого файла (как предложил Wolfhound) — вообще никак, чтобы контроллировать процесс передачи и последующее использование операционкой.
S>Как всегда — много умных слов, ни тени понимания.
S>Система работает примитивно просто (это изобрели ещё в доисторические времена): каждое приложение получает доступ только к тому, что ему дали. Обходных путей не существует.

Осталось определиться с понятием "приложение". Для того же MS SQL — это десятки запускаемых экзешников. Давай, покажи процесс раздачи прав каждому из них.

S>В десктопе упрощённая цепочка выглядит так:
S>1. Есть приложение Explorer, которому мы сильно доверяем. Ему в начале времён дали доступ ко всем дискам, и к АПИ типа CreateFile().
S>2. Есть произвольное другое приложение, которое по умолчанию ничего не видит и не имеет. Вызвать CreateFile оно не может. Всё, что оно может сделать — вызвать OpenFileDialog(), который возвращает сразу хэндлы файлов, которые указал пользователь.

S>Ключевой момент: Explorer здесь не является частью модели безопасности. Это всего лишь одна из надстроек, построенных поверх низкоуровневых механизмов, которых в оберонах нету.

Упс... Ну и у кого тут не тени понимания?
1. Эксплорер — это обычное GUI приложение, а не надстройка.
2. Как и обычному GUI приложению, Эксплореру НЕ нужно АПИ CreateFile() для своей работы, бо OpenFileDialog можно вызывать с мильонами флагов, в т.ч. для создания файлов.

S>Если мне удобно, то я могу дать SQL Server всеобъемлющие права на все диски — и проблема будет решена: он будет открывать всё подряд.

Проблема будет создана, а не решена.

S>Если я не доверяю SQL Server (потому что он у меня исполняет скрипты, присланные непонятно кем), то я заставлю его работать с внешним приложением-конфигуратором, которое будет ему давать доступ к файлам, которые лично я ему подтвердил — хотя бы через конфиг-файл, права на доступ к которому я получаю тем же способом через OpenFileDialog на своём администраторском ноутбуке.

Сорри, неважнецки с воображением. Не взлетит такой подход.
1. Не заставишь ты работать MS SQL с "внешним приложением-конфигратором".
2. Не работает для бэкапа в сетку.

S>Поэтому все рассуждения про байты, TCP-соединения, передачи хендлов, тут совершенно не про то. Речь только про то, как исполняющая среда решает, какие методы каких объектов кому разрешено вызывать, и какие значения параметров позволены быть у этих методов.

Эта модель НЕ работает вообще нигде и не будет впредь. То, что ты недопонял мои аргументы — было видно с первой строчки твоего ответа, т.к. я исхожу из того, что в реальности работает суперпозиция прав приложения и пользвателя, а ты решил ограничиться только приложением. Но такой подход для реальной работы неудобен, т.к. по умолчанию всё будет запрещено, кроме локаьных хранилищ, а в случае попыток улучшить удобсво как ты описал (начать раздавать права только приложению), твой подход превращается в точно такую же дыру в безопасности.

S>Если такая система есть — значит, можно построить надёжную конструкцию взаимного доверия.

А смысл, если как раз из этой конструкции и можно украть данные? Ты же пользователя проигнорировал, вернее, переложил головную боль о пользователе на конкретное приложение.

S>Если такой системы нет — то рассуждения про безопасность можно смело сливать в канализационный прибор, так как всегда будет возможность под видом калькулятора подсунуть программу, которая делает что угодно с привилегиями текущего пользователя.

Не можно. Ты допускаешь невнимательность, пытаясь рассматривать две крайности: система прав от пользователя vs система прав от приложения. Это у тебя спор сам с собой получается, т.к. по мне единственный реально работающий вариант совместный и никак иначе. А юниксы я тут, похоже, сам для себя в пример приводил. Просто у юниксов сама шкала прав, скажем прямо, примитивная, но общий подход верен. У современных виндов наоборот, шкала прав всеобъемлющая, но общий подход заведомо ненадежный. Да, поэтому под видом калькулятора в виндах можно делать что угодно. Только это не аргумент ни разу в ЭТОМ споре.

S>Изоляция одного лишь модуля SYSTEM — детский сад. В нормальной среде все компоненты параноидальны по-максимуму друг к другу.

Ты не понял про SYSTEM. )))
Этот модуль для хаков, при том, что кольцо исполнения общее на всех. Все остальные модули не позволят перепрыгнуть встроенные механизмы защиты, какие бы они не были.

Да и вообще, опять же с воображением не ахти. Никакой взаимной параноидальности на уровне модулей в рантайм быть не может и не надо, если загрузчик уже пропустил/загрузил модуль — этот модуль должен адекватно и эффективно работать. Это же нейтивная истема. А любая безопасность с т.з. кода обеспечивается артефактами безопасности и никак иначе — некими описательными структурами. Например: некий модуль предоставляет функциональность художественного логгирования. Дык, этот модуль не должен корчить из себя операционную систему и считать, какому вызывающему модулю что можно, а что нет. Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.

Здравствуйте, samius, Вы писали:

V>>Не так. Ждем спутников на Андроиде. А вот как захватит рынок спутников, тогда поубавится смысл обсуждать тормозные среды исполнения.

S>Спутинки на андройде в природе имеются (гугл в помощь)
S>http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/

Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С)
А запустили уже или как? А рынок захватили?

V>>=========
V>>Ну и дело не в кач-вах среды ни разу, ес-но. Там с одной стороны толкает MS, с другой Google. Всего-навсего две самые мощные IT-компании... Какие мелочи, право.

S>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?

ХЗ, мобильникам ОС понадобилась буквально лет 5-6 лет назад, а до этого, всё, что называлось "mobile OC" на самом деле никакой ОС не являлось.
А поменять тему обсуждения тебе вряд ли удасться. Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.

Здравствуйте, VladD2, Вы писали:

V>>Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).
VD>Ау! Ты часом не заблудился? Ты пришел на форум современных разработчиков, а не к срперам из дома престарелых программистов.

Покажи мне современных разработчиков. Кокретно на этом сайте по большей части разработчики под дотнет. Разработчики не самой этой среды, заметь, то бишь не производители технологий, а сугубо потребители современных технологий. Домохозяйки тоже с современными технологиями обращаются на ура на кухне...

Ты решил предложить мне сравнить домохозяку, орудующую самым современным кухонным комбайном, с разаработчиком кухонного комбайна? Пусть даже предыдущего поколения? А что ты сравнивать собрался?

VD>Тут "вроде как где-то" не катит. А подсветка "через синтаксис" вызовет только смех.

Ок, берешь код на Обероне, предлагаешь помимо ключевых слов выделить еще что-то, выражаешь свои намерения хотя бы в RTF или HTML. Смотрим, сравниваем. Своё ИМХО я уже сказал, для Паскалевкого синтаксиса подсветка помимо ключевых слов не принципиальна. Как и для похожего на него VB.

Там же нечего подсвечивать.

VD>Давай называть вещи своими именами. Оберона на ПК практически нет. Есть ублюдочный БлэкБокс застрявший в совем развитии в 80-ых годах.

Оберона на ПК всяко больше Немерле, застрявшего в своем развитии в 2005-м.

VD>Есть ли он еще где-то тоже большой вопрос. Потому как почитав список успешных проектов, который ты давал, и не найдя ни одного тому подтверждения по указанным ссылкам, верить уже не хочется.

Т.е. ты всерьез собрался утверждать, что в той ссылке тебе наврали?

Ох и трололо...

V>>Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась.
VD>Конечно. Языку вообще ничего не нужно. Он же не живой. Нужно людям. Возможно ты не в их числе. Но я вот точно не буду использовать язык без нормальной поддержки IDE.

А как же ты до 2003-го года программировал, бедный?
Не забыл еще, что мы обсуждали систему, разработка которой остановилась еще до дотнета.

V>>Ну и еще, там же не текстовый документ, а гипертекстовый.
VD>Это никого не трогает. Да и не нужно это никому за пределами универов.

Узнаю старого доброго Влада2. Если аргумент оппонента неудобен — тем хуже аргументу.
Ладно, в таком ключе смысла сорить в форуме нет. Сорри, дальше даже не читал.

Здравствуйте, Sinclair, Вы писали:

ARK>>Минутку. Стало быть, в API будет такой сервис, который предоставляет возможность слать поток байт в сеть.
ARK>>Наш вредоносный редактор документов открывает файл через OpenFileDialog (точнее пользователь открывает для работы) и шлет все его байты в сеть. Ну, дали мы редактору при установке такое право, он попросил. Такой сценарий возможен?
S>1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?

Затем. Поставь изкаробки WinServer2008. Ничего сам не настраивай. Вроде бы обычная винда (так и есть, кстате). Посади на эту операцинку свою девушку или любого другого продвинутого пользователя, но не прожженого админа. Пользоваться этой виндой он/она не сможет. Даже приличная часть программистов не сразу сможет ей пользоваться как десктопом... хотя, нефик делать, если разобраться — это обычная винда... Просто изкаробки всё запрещено. Т.е. даже в условиях относительно примитивной модели безопасности Windows (сравнить с юниксовой), система абсолютна неюзабельна для пользователя.

Здравствуйте, Klapaucius, Вы писали:

V>>Гарантирует не хуже Хаскеля. Такой уровень гарантий тебя устроит? Или в природе существуют гарантии еще выше?
K>Справедливости ради нужно отметить, что хуже. К примеру, аналоги обероновского SYSTEM в хаскеле все-таки отключаются.

Зависимости от SYSTEM тоже запрещаются.

(и вообще, не надоело вокруг SYSTEM спекулировать?)

Здравствуйте, Klapaucius, Вы писали:

K>Можно огласить список заимствований у Вирта? А то я вот ни одного заимствования у Вирта вспомнить не могу.

Легко: VB, VB.Net, Java, C++, C# — близнецы-братья паскалю с объектными расширениями.

Другие приводимые языки, типа Лиспа, SmallTalk, Симулы и т.д. настолько из другой оперы, что авторы указанных языков себе явно льстят, когда ссылаются на них. А реально в приведенной группе языков в точности одинаковый механизм рантайм-полиморфизма над императивным исполнением и отсюда одинаковый подод к решению задач. Взять те же паттерны из GOF — они ровно для этой группы языков. Ни Лиспу ни SmallTalk эти паттерны и даром не сдались, у тех свои паттерны.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Не так. Ждем спутников на Андроиде. А вот как захватит рынок спутников, тогда поубавится смысл обсуждать тормозные среды исполнения.

S>>Спутинки на андройде в природе имеются (гугл в помощь)
S>>http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/

V>Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С)
Я почитал прежде чем кинуть ссылку.

V>А запустили уже или как? А рынок захватили?
эк ты тему на изнанку вывернул

S>>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?

V>ХЗ, мобильникам ОС понадобилась буквально лет 5-6 лет назад, а до этого, всё, что называлось "mobile OC" на самом деле никакой ОС не являлось.
V>А поменять тему обсуждения тебе вряд ли удасться. Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.

По поводу смены темы обсуждения:
http://www.rsdn.ru/forum/philosophy/4827511.1.aspx

Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

на что я ответил
http://www.rsdn.ru/forum/philosophy/4827528.1.aspx

Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.

Здравствуйте, AndrewVK, Вы писали:

V>>А какой интерпретатор вышел сложнее какого компилятора?
AVK>Некий внутренний DSL. Сперва был написан интрпретатор, потом переделан в компилятор под CLR с сильным сокращением объема исходников.

А техника интерпретации какая была: p-код или работающее AST?

Здравствуйте, samius, Вы писали:

S>>>Спутинки на андройде в природе имеются (гугл в помощь)
S>>>http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/

V>>Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С)
S>Я почитал прежде чем кинуть ссылку.

Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.

V>>А запустили уже или как? А рынок захватили?
S>эк ты тему на изнанку вывернул

Это тоже я писал?

Ждём мобилу с оберон-осью Как выйдет и захватит рынок,

S>>>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?

S>По поводу смены темы обсуждения:
S>http://www.rsdn.ru/forum/philosophy/4827511.1.aspx
S>

S>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

S>на что я ответил
S>http://www.rsdn.ru/forum/philosophy/4827528.1.aspx
S>

S>Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

А, т.е. ты типа задал тему. Ну дык я по ней полностью ответил. Твой аргумент всё-равно нерелевантен в ключе обзора технологий.

А вот то, что ты проигнорировал это:

Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.

Показательно. Ты сам старательно уходишь от исходной темы. И проявляешь недовольство что я неохотно ухожу вслед за тобой. Это забавно само по себе. ))

S>Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.

1. Это ты не понял мой ответ тебе.
2. Ты хотел сказать Не будет смысл? Ошибаешься, ес-но. Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Я почитал прежде чем кинуть ссылку.

V>Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.
Это ты для других написал?

V>>>А запустили уже или как? А рынок захватили?
S>>эк ты тему на изнанку вывернул

V>Это тоже я писал?
V>

V>Ждём мобилу с оберон-осью Как выйдет и захватит рынок,

Так это я писал про захват мобильного рынка обероном, а не о захвате андройдом спутников.

S>>По поводу смены темы обсуждения:
S>>http://www.rsdn.ru/forum/philosophy/4827511.1.aspx
S>>

S>>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

(*)

V>А, т.е. ты типа задал тему. Ну дык я по ней полностью ответил. Твой аргумент всё-равно нерелевантен в ключе обзора технологий.
(**)

V>А вот то, что ты проигнорировал это:

V>

V>Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.

V>Показательно. Ты сам старательно уходишь от исходной темы. И проявляешь недовольство что я неохотно ухожу вслед за тобой. Это забавно само по себе. ))
Я это проигнорировал лишь потому что запуск оберона на ARM-платформе не является значимым событием на рынке мобильных разработок. Как и не является причиной не обсуждать тормозные среды исполнения.

S>>Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.

V>1. Это ты не понял мой ответ тебе.
V>2. Ты хотел сказать Не будет смысл? Ошибаешься, ес-но. Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.
А теперь посмотри на (*) (**) и пойми что ты уже споришь сам с собой.

Здравствуйте, VladD2, Вы писали:

V>>Выделенное — оксюморон сам по себе, вообще-то. Ты обсуждение вообще читал? Т.е. оно такое даже есть, согласен, тот же BlackBox, но это уже частные поделки.
VD>Ты уже договорился до полнешего бреда. Виндвос, видите ли, мешает вам. Яве и дотнету не мешает, а Оберону мешает.

Да мешает. Ты бы эта... Не погружался сразу в ветки... Переведи представление топика из дерева в хронологический порядок... Почитай, пройдись по ссылкам, а потом велкам... если желание останется.

В общем, точно так же, "Виндвос" (С) мешает небезызвестному Бартоку/Сингулярити, он мешает Оберону. Оберон был разработан не с целью yet another language, эта была взята Модула (развитие Паскаля) и доработана до нужд разработки безопасной операционки. Вот что такое Оберон. Это язык, ОС и среда исполнения на нем. Ну просто одно слово было взято для всего, в отличии от двух слов для аналогичного Bartok-Singularity.

VD>Слушай кончай троллить.
VD>Я тебя кормить не намерен.
VD>Намеренный бред с целью провокации флэйма.

И вам не болеть.

Здравствуйте, vdimas, Вы писали:

V>Ты решил предложить мне сравнить домохозяку, орудующую самым современным кухонным комбайном, с разаработчиком кухонного комбайна? Пусть даже предыдущего поколения? А что ты сравнивать собрался?

Кабздец. Это уже все пределы перешло. Тема полшла во флэйм.

Здравствуйте, novitk, Вы писали:

V>> о мне, не знающему толком ни Хаскеля ни тем более Конкурентного Хаскеля, понадобилось ~5 мин чтения документации, чтобы показать тебе полное невладение предметом относительно твоего же собственного примера.

N>Как показывает эта ветка, ты вообще мало что знаешь толком. Очень жалею, что потратил время и вежливость. Надо было отключаться сразу, как только ты понес в своей обычной хамской манере пургу про мутабельность, вместо того чтобы прислушаться и понять, что МVar == AWAIT, а forkIO == "активные обьекты Oberona".

Я не могу прислушиваться к нубству, сорри. Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом. А что такое await — курить Conditional variables. Затем, когда подкрепишься знаниями, обрати внимание, что никакие конкурентные банковские транзакции из примера не проверяют никаких условий, они тупо получают синхронизированный доступ к мутабельной переменной.

Но и это не принципиально. Прикол в том, что именно ты прокоментировал на какую именно мысль. Всю тяжесть выбитого лулза, боюсь, у тебя не получилось осознать до сих пор... Ты ведь прокоментировал мысль о том, что чистому функциональному языку нужен механизм продолжений для реализации агентской среды, так? Но ты предложил такой язык, который уже никак не является чистым функциональным... Так и не поняв, насколько глубоко уселся в лужу, затем спросил (и сейчас опять спрашиваешь) "и где разница?". Вопрос-то хороший.

Особенно если помнить, что в хорошем вопросе содержится часть ответа. А нету никакой разницы. Где ты видел принципиальную раницу м/у императивными языками?

Здравствуйте, Klapaucius, Вы писали:

V>>А побочные эффекты надо заворачивать в монаду-последовательность и эта монада появилась не сразу, так?
K>Да, это один из результатов экспериментов по изоляции и т.д.

Это промежуточный результат эксперимента. Автор Хаскеля разразился статьей о том, что коль нам приходится эмулировать императивность в функциональном языке и в этой императивности повторимы в точности все побочные эффекты, то никакого смысла делать так на самом деле нет, а к безопасности языка надо подходить с другой стороны.

Вот тебе результаты всех экспериментов — возвращение на круги своя. Потому что моделиировать модель над моделью оказалось излишним. Ссылочная прозрачность на основе типобезопасности дает точно такой же эффект контроллируемой мутабельности.

K>

V>>Функциональный подход хорош при вычислении данных и плох, когда эти вычисленные данные надо куда-то девать.

K>Ничего не понял. Это можно как-то раскрыть?

А что непонятного? Процесс математических вычислений легко ложится на функциональную чистоту, OK, но последующее полезное использование этих вычисленных данных должно сопровождаться побочными эффектами. Например, с целью сохранить результат вычислений. См. выделенное.

Здравствуйте, vdimas, Вы писали:
V>Осталось определиться с понятием "приложение". Для того же MS SQL — это десятки запускаемых экзешников. Давай, покажи процесс раздачи прав каждому из них.
"Приложение" в такой системе — единица раздачи привилегий. Тот же MS SQL — это вовсе не "десятки запускаемых екзешников", но в обсуждаемой системе будет состоять из достаточно большого количества компонент. Большинству из них не нужны никакие особенные права. А вот тем, кто хочет работать с чем-то особенным (например, собственно backup engine, которому нужен tape access), будут получать доступ через подтверждение.

V>Упс... Ну и у кого тут не тени понимания?
Судя по ответам — у вас.
V>1. Эксплорер — это обычное GUI приложение, а не надстройка.
V>2. Как и обычному GUI приложению, Эксплореру НЕ нужно АПИ CreateFile() для своей работы, бо OpenFileDialog можно вызывать с мильонами флагов, в т.ч. для создания файлов.
Вы продолжаете не понимать. Кто, по-вашему, реализует OpenFileDialog?
Он не является частью ядра.

V>Сорри, неважнецки с воображением. Не взлетит такой подход.
Ничего, потренируете воображение — и всё получится.
V>1. Не заставишь ты работать MS SQL с "внешним приложением-конфигратором".
V>2. Не работает для бэкапа в сетку.
Всё прекрасно работает. Один процесс имеет доступ к кэшу DB Engine, другой — к сетке. Благодаря отсутствию аппаратной изоляции, передача данных между ними ничего не стоит.

V>Не можно. Ты допускаешь невнимательность, пытаясь рассматривать две крайности: система прав от пользователя vs система прав от приложения.
Нет. Само собой разумеется, что права пользователя тоже играют роль. Однако, без изоляции процессов это никак не спасает, т.к. у пользователя всегда слишком много прав.

V>Этот модуль для хаков, при том, что кольцо исполнения общее на всех. Все остальные модули не позволят перепрыгнуть встроенные механизмы защиты, какие бы они не были.
Откуда там возьмутся механизимы защиты, если их нет?

V>Да и вообще, опять же с воображением не ахти. Никакой взаимной параноидальности на уровне модулей в рантайм быть не может и не надо, если загрузчик уже пропустил/загрузил модуль — этот модуль должен адекватно и эффективно работать.
Вы тренируйте, тренируйте воображение. В вашей модели загрузчик пропускает запуск калькулятора, который хочет доступ к временным файлам, и калькулятор сразу получает доступ ко всему тому, на что имеет доступ пользователь.

Это же нейтивная истема. А любая безопасность с т.з. кода обеспечивается артефактами безопасности и никак иначе — некими описательными структурами. Например: некий модуль предоставляет функциональность художественного логгирования. Дык, этот модуль не должен корчить из себя операционную систему и считать, какому вызывающему модулю что можно, а что нет. Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.

Ваше воображение работает не в ту сторону. Модулю не нужно узнавать о том, как его вызывают. Почитайте что-нибудь про CAS.

Здравствуйте, vdimas, Вы писали:
S>>1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?

V>Затем. Поставь изкаробки WinServer2008. Ничего сам не настраивай. Вроде бы обычная винда (так и есть, кстате). Посади на эту операцинку свою девушку или любого другого продвинутого пользователя, но не прожженого админа. Пользоваться этой виндой он/она не сможет. Даже приличная часть программистов не сразу сможет ей пользоваться как десктопом... хотя, нефик делать, если разобраться — это обычная винда... Просто изкаробки всё запрещено. Т.е. даже в условиях относительно примитивной модели безопасности Windows (сравнить с юниксовой), система абсолютна неюзабельна для пользователя.
Не понял смысл вашего мысленного эксперимента. Ешё раз спрошу: зачем вы дали редактору право ходить в любое место в интернете?

Если вы хотите поговорить о социальной инженерии — давайте поговорим. Но не стоит смешивать её с техническими вопросами.

Здравствуйте, Klapaucius, Вы писали:

V>>Фактически одно и то же когда продолжения делаются не в языке-интерпретаторе, а в компиллируемом в нейтивный код. В этом случае продолжения делаются именно через полное дублирование контекста исполнения (и "родного" стека машины в т.ч.).

K>Либо "родной" стек вообще не используется. В SML/NJ и GHC — именно так.

Вопросы:
1. Какой стек используется в GHC?
2. Даже если используется некий эмулируемый стек (или 2 стека, как в классике), то разве это отменяет необходимость копирования хотя бы части стека для продолжений?

Выделил потому, что некоторые нейтивные компиляторы Схемы копируют не весь нейтивный стек, а некую его часть, достаточную для работы продолжения.

V>>Разница лишь в том, какой вид многозадачности доступен в такой системе — кооперативный, или полноценный с вытеснениями. ИМХО, для обсуждаемой задачи, когда агенты должны постоянно сидеть в ожидании сигналов ввода-вывода каналов (прямо по условию) разница м/у видами многозадачности не столь принципиальна.

K>На практике "легкие потоки" для программиста это обычные потоки, вся асинхронная машинерия от него абстракцией отгорожена. А эмуляция легких потоков на продолжениях — это или (в лучшем случае) развесистые монады как в lwt или вообще колбек-лапша.

Я понятия не имею, что ты там себе нарисовал. Ты работал с фиберами? Делал прокси на ввод-вывод для целей шедуллинга фиберов? Покажи мне, какая проблема запустить продолжение в отдельном фибере и организовать "всю асинхронную машинерию" (С) на кооперативной многозадачности? Мне преставляется простая модель: куча "однопоточных" продложений сидят на ожидании ввода-вывода и получают кванты на исполнение ровно тогда, когда для них этот ввод-вывод готов. В разработанной мною когда-то на C# агентской среде происходило аналогичное, только ручками и местами "код наоборот", то бишь реакция на события в автоматном стиле (событийный подход). Только на относительно несложных задачах я мог "выпрямлять" алгоритмы на yield-return, где источников событий мало, а лучше вообще один. Мне продолжения кажутся хорошей механикой для аналогичного "выпрямления" автоматных алгоритмов.

Здравствуйте, samius, Вы писали:

S>>>Я почитал прежде чем кинуть ссылку.
V>>Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.
S>Это ты для других написал?

Нет, я в форуме для себя пишу. Эдакая онлайновая записная книжка.
====================
Моя аннотация тебя задевает?

S>Так это я писал про захват мобильного рынка обероном, а не о захвате андройдом спутников.

Вот. Вопрос: а зачем ты пытался перевести тему исходного обсуждения?

S>А теперь посмотри на (*) (**) и пойми что ты уже споришь сам с собой.

Э нет, если кому-то что-то повторяю, это не значит спор с самим собой, это значит, что жду ответа по существу от начинающего бегать собеседника. Захотелось пообщаться на эти темы? Ну давай общаться.

1.

Твой аргумент всё-равно нерелевантен в ключе обзора технологий.

Не согласен — обоснуй.

Ну ок, даже считаем что выдали твоему аргументу некий кредит доверия даже до обоснования его релевантности в этом топике. Далее возражаем по твоему аргументу:
2.

Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.

Опять не согласен — опять обоснуй.

Здравствуйте, vdimas, Вы писали:

V>Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.
Ценность ручного раскрашивания кода близка к нулю. Причем с отрицательной стороны. То, что современная IDE обязана делать сама, предлагается делать вручную.
Раскраска кода должна быть семантической, чтобы улучшить восприятие. Семантика кода — штука объективная, заставлять человека вручную вводить информацию, которая в коде уже есть — каменный век. К тому же эту семантику нужно ещё и поддерживать в актуальном состоянии.

Выбор цветовой схемы — ровно наоборот, штука абсолютно субъективная. Она должна быть строго ортогональна семантике. Кому-то комфортнее с фиолетовым текстом на чёрном фоне, кому-то — с синим на белом. Авторы Оберона этого не понимают — их представления о usability безнадёжно застряли в 80х годах.

Кроме всего — раскраска в современных IDE — динамическая. То есть, я встал курсором на идентификатор — все его вхождения подсветились. Встал на другой — подсветились другие. Встал на скобку — подсветилась парная. Как это реализовать на убогом "гипертексте" Оберона?
Правильно — никак. Это ровно потому, что его проектировали люди, не понимающие что такое код, что с ним делают люди, зачем они это делают. Он весь — сплошное сборище ошибок.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.
S>>Это ты для других написал?

V>Нет, я в форуме для себя пишу. Эдакая онлайновая записная книжка.
V>====================
V>Моя аннотация тебя задевает?
Мне не ясно, кому она адресована

S>>Так это я писал про захват мобильного рынка обероном, а не о захвате андройдом спутников.

V>Вот. Вопрос: а зачем ты пытался перевести тему исходного обсуждения?
Напоминаю: тема, в рамках которой я влез — твои сомнения в смысле обсуждать тормозные среды исполнения. А ты все время пытаешься обсудить со мной какие-то другие темы, в том числе запуск оберона на арм-е и мои переводы темы.

S>>А теперь посмотри на (*) (**) и пойми что ты уже споришь сам с собой.

V>Э нет, если кому-то что-то повторяю, это не значит спор с самим собой, это значит, что жду ответа по существу от начинающего бегать собеседника. Захотелось пообщаться на эти темы? Ну давай общаться.
Ты не повторяешь. Ты высказываешь противоположный своему тезису.

V>1.
V>

V>Твой аргумент всё-равно нерелевантен в ключе обзора технологий.

V>Не согласен — обоснуй.
Знаешь что, я не собирался технологии обозревать. Я критикую твои сомнения относительно смысла обсуждения.

V>Ну ок, даже считаем что выдали твоему аргументу некий кредит доверия даже до обоснования его релевантности в этом топике. Далее возражаем по твоему аргументу:
V>2.
V>

V>Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.

V>Опять не согласен — опять обоснуй.
Это возражение твоему исходному сомнению, а не моему аргументу.
Давай-ка я помещу твое сомнение и аргумент против него рядом, что бы ты понял наконец, о чем речь:

Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать.

Или ты считаешь оберон популярнее андройда?

Здравствуйте, VladD2, Вы писали:

V>>Ты решил предложить мне сравнить домохозяку, орудующую самым современным кухонным комбайном, с разаработчиком кухонного комбайна? Пусть даже предыдущего поколения? А что ты сравнивать собрался?
VD>Кабздец. Это уже все пределы перешло. Тема полшла во флэйм.

Увы, ты первый решил попытаться называть вещи своими именами. А оно всегда нелицеприятно.

Здравствуйте, VladD2, Вы писали:

VD>Слушай кончай троллить. Я тебя кормить не намерен. Ты уже договорился до полнешего бреда. Виндвос, видите ли, мешает вам. Яве и дотнету не мешает, а Оберону мешает.
Не, он — всем мешает. Конкретно мешает аппаратная изоляция. В принципе, можно запустить всю среду внутри одного вин-процесса, и внутри неё "лёгкие процессы" смогут очень эффективно коммуницировать. Но это годится только для диссертаций, т.к. в реальных приложениях всё упрётся во ввод-вывод. Его влияние, в принципе, можно минимизировать для некоторых узкоспецифических классов приложений, вроде баз данных, но в общем случае получить наблюдаемые преимущества перед нативом не выйдет.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vdimas, Вы писали:

V>>Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.
S>Ценность ручного раскрашивания кода близка к нулю. Причем с отрицательной стороны.

Ценность такого замечания близка к 0-лю до возражения на неоднократно в теме высказанное:

для Паскалевкого синтаксиса подсветка помимо ключевых слов не принципиальна.

S>То, что современная IDE обязана делать сама, предлагается делать вручную.

Интерактивную методичку для студентов IDE не может делать сама.

S>Раскраска кода должна быть семантической, чтобы улучшить восприятие.

Коллега, меньше слов, больше дела.

Ок, берешь код на Обероне, предлагаешь помимо ключевых слов выделить еще что-то, выражаешь свои намерения хотя бы в RTF или HTML. Смотрим, сравниваем.

S>Семантика кода — штука объективная, заставлять человека вручную вводить информацию, которая в коде уже есть — каменный век.

Коллега, тебе же тоже врде Паскаль должен быть знаком, хотя бы из-за времени, в котором ты получал образование. Покажи мне, как поделить синтаксис Оберона на семантики, требующие раскраски?

Сдается мне, прямо здесь и сейчас ты пытаешься натягивать опыт одних языков на другие. Смысла выделять идентификаторы от типов в паскалевском синтаксисе нет вообще, они и так отделены синтаксисом, не спутаешь... В отличие от синтаксиса неоднозначных языков:
C#/Java:
some_type.static_method()
some_variable.exemplar_method()

Вот здесь без цветового выделения жопа, согласен.

S>К тому же эту семантику нужно ещё и поддерживать в актуальном состоянии.

Документацию так и так надо поддерживать в актуальном состоянии.

S>Выбор цветовой схемы — ровно наоборот, штука абсолютно субъективная. Она должна быть строго ортогональна семантике.

Я уже сказал своё ИМХО — достаточно выделения только ключевых слов.

S>Авторы Оберона этого не понимают — их представления о usability безнадёжно застряли в 80х годах.

Влад, ты?
Какое отношение имеет, например, проект Bartok/Сингулярити, к подсветке синтаксиса в какой-то IDE? Да еще если сам Вирт к этой IDE никакого отношения не имеет? И кто тут решил пофлеймить?

S>Кроме всего — раскраска в современных IDE — динамическая. То есть, я встал курсором на идентификатор — все его вхождения подсветились. Встал на другой — подсветились другие. Встал на скобку — подсветилась парная. Как это реализовать на убогом "гипертексте" Оберона?

Предположу, что так же, как и везде. А у тебя были другие предположения?

S>Правильно — никак.

Это домохозяйке починить кухонный комбайн никак... были бы руки. Подсветка синтаксиса не rocket science, а скорее ровно наоборот. Надо — сделай, исходники BlackBox открыты.

Почему подсветка синтксиса стала такая динамичная буквально не так давно? Правильно — не понимаешь. Не понимаешь, что для этого нужен парсинг исходников в фоне и достаточные вычислительные ресурсы, которые появились повсеместно уже после 2000-го.

S>Это ровно потому, что его проектировали люди, не понимающие что такое код, что с ним делают люди, зачем они это делают. Он весь — сплошное сборище ошибок.

Нет, это просто от того, что комменты пишут люди, не имеющие представления о процессах разработки ПО. Не умеющие банально приложить требования (в т.ч. нефункциональные) к реализации и сравнить одно с другим на релевантность. Ты минимум дважды в одном посте нимало не смущаясь запряг карету впереди лошади. Не стыдно?

Здравствуйте, vdimas, Вы писали:

V>Я не могу прислушиваться к нубству, сорри. Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом. А что такое await — курить Conditional variables. Затем, когда подкрепишься знаниями, обрати внимание, что никакие конкурентные банковские транзакции из примера не проверяют никаких условий, они тупо получают синхронизированный доступ к мутабельной переменной.

"Смотрю в книгу, вижу фигу."
Там ведь всего три предложения. У тебя с английским тоже проблемы? Я подчеркну, возьми словарь и переведи три раза.

An MVar t is mutable location that is either empty or contains a value of type t. It has two fundamental operations: putMVar which fills an MVar if it is empty and blocks otherwise, and takeMVar which empties an MVar if it is full and blocks otherwise. They can be used in multiple different ways:
1. As synchronized mutable variables, 2. As channels, with takeMVar and putMVar as receive and send, and 3. As a binary semaphore MVar (), with takeMVar and putMVar as wait and signal.

Вот например AWAIT из твоего любимого Оберона:

await :: MVar a->(a->Bool)->IO a
await mv f = do v <- takeMVar mv
                if f v then return v else await mv f

V>Но и это не принципиально. Прикол в том, что именно ты прокоментировал на какую именно мысль. Всю тяжесть выбитого лулза, боюсь, у тебя не получилось осознать до сих пор... Ты ведь прокоментировал мысль о том, что чистому функциональному языку нужен механизм продолжений для реализации агентской среды, так?

Только в твоей фантазии, клоун. Я всего лишь весьма вежливо указал на твою неосведомленность о наличие в Хаскелле активных обьекты в 95-м году. Ты, вместо того чтобы признать свое незнание, ни к селу ни к городу закричал "MVar — это мутабельное говно". После этого я сделал две попытки выяснить, чем это отличается от реализации AWAIT в обероне, но ты накрылся демагогией и я понял бессмысленность продолжения.

Здравствуйте, Sinclair, Вы писали:

S>Ваше воображение работает не в ту сторону. Модулю не нужно узнавать о том, как его вызывают. Почитайте что-нибудь про CAS.
CAS та еще бяка. CBS намного лучше.
При этом в сингулярити капабилитями являются сами каналы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Sinclair, Вы писали:

S>Не, он — всем мешает. Конкретно мешает аппаратная изоляция. В принципе, можно запустить всю среду внутри одного вин-процесса, и внутри неё "лёгкие процессы" смогут очень эффективно коммуницировать. Но это годится только для диссертаций, т.к. в реальных приложениях всё упрётся во ввод-вывод. Его влияние, в принципе, можно минимизировать для некоторых узкоспецифических классов приложений, вроде баз данных, но в общем случае получить наблюдаемые преимущества перед нативом не выйдет.
Разговор идет про сборку мусора, а не про IO.
И тут аппаратная защита вообще не релевантна.
Ибо, например в той же сингулярити сборщики мусора живут каждый в своем процессе.

А так согласен. Аппаратная защита должна умереть.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Ценность такого замечания близка к 0-лю до возражения на неоднократно в теме высказанное:
V>

V>для Паскалевкого синтаксиса подсветка помимо ключевых слов не принципиальна.

Утверждения без аргументов идут в канализационный прибор.

V>Интерактивную методичку для студентов IDE не может делать сама.
Совершенно верно. Но в промышленном программировании задачи делать интерактивные методички для студентов не стоит. Ценность Виртовских идей для обучения концепциям программирования никто и не оспаривал.

V>Коллега, меньше слов, больше дела.
V>

V>Ок, берешь код на Обероне, предлагаешь помимо ключевых слов выделить еще что-то, выражаешь свои намерения хотя бы в RTF или HTML. Смотрим, сравниваем.

Не понимаю пассаж.

S>>Семантика кода — штука объективная, заставлять человека вручную вводить информацию, которая в коде уже есть — каменный век.

V>Коллега, тебе же тоже врде Паскаль должен быть знаком, хотя бы из-за времени, в котором ты получал образование. Покажи мне, как поделить синтаксис Оберона на семантики, требующие раскраски?
Начнём с простого — будем подсвечивать комментарии и литералы. Чтобы лучше отличать a = l0 от а = 10.
Перейдём к сложному — покажем разницу между локальными переменными и мемберами, чтобы видеть, где тут кто:

PROCEDURE Fail(obj: MyObject; var Title: String)
BEGIN
 WITH obj DO 
   Title := 'Hello 1';
 Title := 'Hello 2';
END;

Двинемся к тому, чтобы подсвечивать по-разному идентификаторы из текущего модуля и импортированные из других. Подсвечиваем красным то, что пришло из System.

V>Сдается мне, прямо здесь и сейчас ты пытаешься натягивать опыт одних языков на другие. Смысла выделять идентификаторы от типов в паскалевском синтаксисе нет вообще, они и так отделены синтаксисом, не спутаешь...
Я, коллега, опираюсь на опыт разных языков. Я на Delphi написал больше кода, чем вы читали.

V>Документацию так и так надо поддерживать в актуальном состоянии.
Ага. При
S>>Выбор цветовой схемы — ровно наоборот, штука абсолютно субъективная. Она должна быть строго ортогональна семантике.

V>Я уже сказал своё ИМХО — достаточно выделения только ключевых слов.
Смешно.
V>Предположу, что так же, как и везде. А у тебя были другие предположения?
У меня были предположения, что предлагаемое решение — красить текст вручную.

V>Это домохозяйке починить кухонный комбайн никак... были бы руки. Подсветка синтаксиса не rocket science, а скорее ровно наоборот. Надо — сделай, исходники BlackBox открыты.
Мне? Нет, не надо. У меня уже есть IDE и язык, которые умеют это из коробки.

V>Почему подсветка синтксиса стала такая динамичная буквально не так давно? Правильно — не понимаешь.

Забавно, как вы собственную некомпетентность приписываете собеседникам.
V>Не понимаешь, что для этого нужен парсинг исходников в фоне и достаточные вычислительные ресурсы, которые появились повсеместно уже после 2000-го.
Детский лепет. Всё упирается в скорость компиляции. Парсить исходники в паскалевском синтаксисе всегда было очень легко — язык специально заточен на это. А вся динамика — исключительно заслуга редактора и команды, которая ставит перед собой такую задачу.

V>Нет, это просто от того, что комменты пишут люди, не имеющие представления о процессах разработки ПО. Не умеющие банально приложить требования (в т.ч. нефункциональные) к реализации и сравнить одно с другим на релевантность. Ты минимум дважды в одном посте нимало не смущаясь запряг карету впереди лошади. Не стыдно?
Мне — нет. Я просто разбираюсь в том, о чём пишу. И о процессах разработки ПО, и о его внутреннем устройстве.

Здравствуйте, vdimas, Вы писали:

V>А техника интерпретации какая была: p-код или работающее AST?

Второе.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

V>>Коллега, меньше слов, больше дела.
V>>

V>>Ок, берешь код на Обероне, предлагаешь помимо ключевых слов выделить еще что-то, выражаешь свои намерения хотя бы в RTF или HTML. Смотрим, сравниваем.

S>Не понимаю пассаж.

Пассаж был в том, чтобы самому раскрасить кусок какого-нить реального кода и показать для примера.

S>Перейдём к сложному — покажем разницу между локальными переменными и мемберами, чтобы видеть, где тут кто:
S>

S>PROCEDURE Fail(obj: MyObject; var Title: String)
S>BEGIN
S> WITH obj DO 
S>   Title := 'Hello 1';
S> Title := 'Hello 2';
S>END;
S>

Неудачный пример, не поможет, если оба Title являются чьими-то мемберами. Например, второй Title — мембер объекта, с процедурой Fail.

S>Двинемся к тому, чтобы подсвечивать по-разному идентификаторы из текущего модуля и импортированные из других. Подсвечиваем красным то, что пришло из System.

Выделеное именно так и подсвечивается. Тут ты угадал. Сам модуль в списке импорта тоже подсвечивается красным как в заголовке импорта, так и в древовидном навигаторе по модели кода.

V>>Сдается мне, прямо здесь и сейчас ты пытаешься натягивать опыт одних языков на другие. Смысла выделять идентификаторы от типов в паскалевском синтаксисе нет вообще, они и так отделены синтаксисом, не спутаешь...
S>Я, коллега, опираюсь на опыт разных языков. Я на Delphi написал больше кода, чем вы читали.

В первых Дельфи, на которых я тоже успел пописать, пока нормальные компиляторы плюсов под винды не появились, раскраска была не сильно круче. Вот как раз только ключевые слова, литералы/числа и комментарии. Не помню там разный цвет под мемберы и локальные переменные.

V>>Я уже сказал своё ИМХО — достаточно выделения только ключевых слов.
S>Смешно.

Да ради бога.

V>>Предположу, что так же, как и везде. А у тебя были другие предположения?
S>У меня были предположения, что предлагаемое решение — красить текст вручную.

Не надо ля-ля, ты утверждал, что сделать это принципиально невозможно, потому что

его проектировали люди, не понимающие что такое код, что с ним делают люди, зачем они это делают. Он весь — сплошное сборище ошибок.

Вот такие вот рефлексии. )))

V>>Это домохозяйке починить кухонный комбайн никак... были бы руки. Подсветка синтаксиса не rocket science, а скорее ровно наоборот. Надо — сделай, исходники BlackBox открыты.
S>Мне? Нет, не надо. У меня уже есть IDE и язык, которые умеют это из коробки.

Гы, язык не умеет себя раскрашивать. Спасибо за фан.

V>>Почему подсветка синтксиса стала такая динамичная буквально не так давно? Правильно — не понимаешь.
S>

Забавно, как вы собственную некомпетентность приписываете собеседникам.
V>>Не понимаешь, что для этого нужен парсинг исходников в фоне и достаточные вычислительные ресурсы, которые появились повсеместно уже после 2000-го.
S>Детский лепет. Всё упирается в скорость компиляции. Парсить исходники в паскалевском синтаксисе всегда было очень легко — язык специально заточен на это. А вся динамика — исключительно заслуга редактора и команды, которая ставит перед собой такую задачу.

Легко не легко — это спекуляции. Действительно нормальную раскраску кода в IDE я увидел уже в конце 90-х начала 2000-х, когда Оберон уже перестали разрабатывать. А до это все были тупые или как? Или просто графические IDE на тех процессорах тормозили сами по себе даже без сложной раскраски?

S>Мне — нет. Я просто разбираюсь в том, о чём пишу. И о процессах разработки ПО, и о его внутреннем устройстве.

Я привел твой отрывок. Вот твоё разбирательство. Это низкопробные рефлексии, а не разбирательства.

===========================
Собственно, вся эта ветка была порождена аналогичной рефлексией, см. первый пост после выделения ветки в отдельную тему. Я-то отношусь к Оберону абсолютно нейтрально, по-другому никак, ибо конкретно на Обероне не писал ничего серьезного, только пару раз в разное время играл с различными его реализациями. Конечно, всё понятно и так: нет стольких вложенных людских (то бишь денежных) ресурсов, нет стольких халявных либ, как привыкли на примере джавы и дотнета и т.д. Но с минимальными ресурсами был достигнут отличный результат и его использование в критических областях говорит само за себя.

Но самый фан здесь в том, что моя абсолютно нейтральная позиция на фоне всех этих низкопробных рефлексий выглядит как позиция защиты Оберона. Это само по себе уже забавно. Тут как раз глашатаи из всех сект подтянулись, и мне общение с ними доставляет определенный фан... Слышится недовольство и уже не знают что придумать... А то как же... Это же все догмы идут лесом... Все уже привыкли к установленному порядку, все уже договорились, разметили территорию: что вот мол, безопасный язык у нас либо декларативный (функциональный), а если императивный, то непременно через байткод, и лучше всего через байткод джавы или дотнета. А тут выскочка Оберон, да еще старше их всех, утверждлает тоже самое насчет чистого нейтивного языка. Вот уж неплохая красная тряпочка получилась... Что 8 лет назад, что сейчас... Ну, побегайте за красной тряпочкой, мне помахать несложно. ))) Видители, язык в IDE не покрасили, поэтому типобезопасная операционка полное г-но... Какая прелесть! Можно подумать, что целью разарботки операционки является раскрашенное IDE для Синклера. А товарищь Торвальдс-то и не знал... Вся жисть на свалку... В общем, сорри, но фан как он есть. Домохозяйкам комбайн не так покрашенный дали, поэтому суп они приготовить не в состоянии.

В общем, в твоей рефлексии для меня новости нет. Это ты и именно ты больше всех был глашатаем дотнета на заре этого сайта. Это именно твои определенные навыки, и, я бы даже сказал твой талант, в области бла-бла-бла языком, прямо на этом сайте создавали дотнету определенную репутацию... что даже я когда-то верил. Ведь лично ты разводил тут такую отборную Ньювасюковщину, таким соловьем заливался, что вот мол, вы сейчас можете писать на дотнете, а потом эта среда станет супер-пупер и ваши инвестиции только окрепнут. А по факту: мастшабируемость никакая, эффективность так и осталась на уровне десятилетней давности, и даже в будущих проектах ничего на этот счет не говорят. Вот это упс так упс вышел... Нехорошо получилось, правда? Ты мне должен за зря потраченное время в человекогодах. Да что тут говорить... WinForms недалеко укатился от MFC, многообещающий WPF с треском провалился из-за своей монстроидальной нерабтоспособности... В будущих Виндах таки сделали обещаный когда-то АПИ под кодовым названием "Авалон"... да только в нейтиве. Как тут говорил Кайберакс — Муахахаха.

Вообще, я сейчас вспоминаю те давние обсуждения и вижу, блин, насколько правы были те, кто говорил, что дотнет и прочие секты — это dogfood для окружающих. Что сама MS выпускает качественные рыночные продукты, ядро которых нейтив и только нейтив. А дотнет они сами пользуют чисто в утилитных целях. Ведь даже среда разработки, по сути, утилитный продукт для выпуски других продуктов. А не самоцель, за которую ты только что судорожно уцепился. Наше вам пффф с кисточкой...

S>Начнём с простого — будем подсвечивать комментарии и литералы. Чтобы лучше отличать a = l0 от а = 10.
S>Перейдём к сложному — покажем разницу между локальными переменными и мемберами, чтобы видеть, где тут кто:
S>

S>PROCEDURE Fail(obj: MyObject; var Title: String)
S>BEGIN
S> WITH obj DO 
S>   Title := 'Hello 1';
S> Title := 'Hello 2';
S>END;
S>

S>Двинемся к тому, чтобы подсвечивать по-разному идентификаторы из текущего модуля и импортированные из других. Подсвечиваем красным то, что пришло из System.

Зачем все так сложно. Можно начать с примитивного:

Out.Ln; Out.String("str"); Out.Ln;

Нет. Out.Ln — это не переменная/тип из модуля Out. Это — функция. Но ведь в неоднозначном©™ синтаксисе Оберона это понятно с первого взгляда!

Здравствуйте, vdimas, Вы писали:

V>Покажи мне современных разработчиков. Кокретно на этом сайте по большей части разработчики под дотнет. Разработчики не самой этой среды, заметь, то бишь не производители технологий, а сугубо потребители современных технологий. Домохозяйки тоже с современными технологиями обращаются на ура на кухне...

В следующий раз за подобные аналогии будет бан.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, Mamut, Вы писали:

M>Зачем все так сложно. Можно начать с примитивного:
M>

M>Out.Ln; Out.String("str"); Out.Ln;
M>

M>Нет. Out.Ln — это не переменная/тип из модуля Out. Это — функция. Но ведь в неоднозначном©™ синтаксисе Оберона это понятно с первого взгляда!

Если бы это была публичная переменная модуля, то выражение Out.Ln; было бы некомпиллируемым.

А если бы ты даже догадался как избежать очередного epic fail и написал бы чуть каверзнее, например так:
MyFunc Out.Ln;
Где Ln — переменная модуля, то я бы тебе ответил, что эти переменные экспортируются вовне как св-ва, только поэтому при экспорте у них можно указать вид доступа извне: R/W или RO. А потом бы я отправил тебя на новый круг искать разницу м/у get-свойвом и вызовом ф-ии.

================
В общем, дьявол в деталях. Я не набрался смелости утверждать, что Паскалям раскраска не нужна вовсе, просто считаю, что в ограничениях Оберона она непринципиальна. Более того, мне есть с чем сравнить, хотя бы с плюсами, где я без подержки среды буду кодить минимум вдвое медленнее при тех объемах проектов, между которыми приходится скакать по работе. Более того, я высказал сугубо своё личное мнение, а спорить в такой манере против сугубо моего личного мнения — заведомо неблагодарное занятие. Это я тебе заранее обещаю. )) С личным мнением вообще не спорят. Максимум вместо этого делятся своим мением. Если бы оно еще будет интересным.. Но пока что, увы.

Здравствуйте, vdimas, Вы писали:

V>Особую остроту придает тот факт, что перечисленные пункты не новость, а старше того же Оберона многократно, но так и не взлетели. И не взлетят, бо противоречат инкапсуляции ООП/КОП.

Ужас то какой. Ну расскажи тогда, как в православном ООП 21 века следует разруливать такие ситуации: есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>О! Смешно один и тем же лицам.

Я бы на твоем месте сильно задумался, почему столько людей, придерживающихся совершенно разных взглядов на языки программирования, тем не менее категорически с тобой не согласны.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vdimas, Вы писали:
V>>Осталось определиться с понятием "приложение". Для того же MS SQL — это десятки запускаемых экзешников. Давай, покажи процесс раздачи прав каждому из них.
S>"Приложение" в такой системе — единица раздачи привилегий. Тот же MS SQL — это вовсе не "десятки запускаемых екзешников", но в обсуждаемой системе будет состоять из достаточно большого количества компонент. Большинству из них не нужны никакие особенные права.

С какой стати не нужны?

S>А вот тем, кто хочет работать с чем-то особенным (например, собственно backup engine, которому нужен tape access), будут получать доступ через подтверждение.

Это унылое Г. Раздача прав в "ленивой" манере, то бишь по-требованию, адекватна только для десктопного юзверя. Никакой админ с тобой не согласится.

V>>Упс... Ну и у кого тут не тени понимания?
S>Судя по ответам — у вас.
V>>1. Эксплорер — это обычное GUI приложение, а не надстройка.
V>>2. Как и обычному GUI приложению, Эксплореру НЕ нужно АПИ CreateFile() для своей работы, бо OpenFileDialog можно вызывать с мильонами флагов, в т.ч. для создания файлов.
S>Вы продолжаете не понимать. Кто, по-вашему, реализует OpenFileDialog?

Гы-гы, общедоступная либа CommonCtrl.dll, которая ничего не знает о каком-то там Explorer. Напиши свой шелл, какие проблемы?

S>Он не является частью ядра.

Дык, в обсуждаемых операционках (Сингулярити/Оберон) НИЧЕГО не является частю ядра, кроме аппаратных абстракций и шедуллера. В Сингулярити еще каналы и разделяемый хип под данные в каналах.

S>Всё прекрасно работает. Один процесс имеет доступ к кэшу DB Engine, другой — к сетке. Благодаря отсутствию аппаратной изоляции, передача данных между ними ничего не стоит.

Еще раз, вот это удаленно не работает:

я заставлю его работать с внешним приложением-конфигуратором, которое будет ему давать доступ к файлам, которые лично я ему подтвердил — хотя бы через конфиг-файл, права на доступ к которому я получаю тем же способом через OpenFileDialog на своём администраторском ноутбуке.

из-за предложенной "ленивой" манеры раздачи прав.

V>>Не можно. Ты допускаешь невнимательность, пытаясь рассматривать две крайности: система прав от пользователя vs система прав от приложения.
S>Нет. Само собой разумеется, что права пользователя тоже играют роль. Однако, без изоляции процессов это никак не спасает, т.к. у пользователя всегда слишком много прав.

Что ты понимаешь под изоляцией процессов? И почему у удаленного пользователя должно быть много прав?

V>>Этот модуль для хаков, при том, что кольцо исполнения общее на всех. Все остальные модули не позволят перепрыгнуть встроенные механизмы защиты, какие бы они не были.
S>Откуда там возьмутся механизимы защиты, если их нет?

Механизмы защиты через типобезопасность. Модуль-то SYSTEM можно запретить импортировать. Ес-но, как и в Сингулярити потребуется создать некий "пояс доверия", т.е. небольшую часть кода, которую заведомо можно считать безопасной, а остальным будет доступно только то, что доступно через честное АПИ.

V>>Да и вообще, опять же с воображением не ахти. Никакой взаимной параноидальности на уровне модулей в рантайм быть не может и не надо, если загрузчик уже пропустил/загрузил модуль — этот модуль должен адекватно и эффективно работать.
S>Вы тренируйте, тренируйте воображение. В вашей модели загрузчик пропускает запуск калькулятора, который хочет доступ к временным файлам, и калькулятор сразу получает доступ ко всему тому, на что имеет доступ пользователь.

Я же говорю, ты споришь сам с собой, сравнивая исключительно два крайних сценария. Если бы я предложил тебе аналогичный сценарий для серверного "доверенного" приложения, которое пускает всех подряд юзверов (ну, забыли один if в коде, с кем не бывает), то ты бы быстро вспомнил о совместной о суперпозиции прав, так? Я ответил на твой вопрос?

S>Это же нейтивная истема. А любая безопасность с т.з. кода обеспечивается артефактами безопасности и никак иначе — некими описательными структурами. Например: некий модуль предоставляет функциональность художественного логгирования. Дык, этот модуль не должен корчить из себя операционную систему и считать, какому вызывающему модулю что можно, а что нет. Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.

S>Ваше воображение работает не в ту сторону. Модулю не нужно узнавать о том, как его вызывают. Почитайте что-нибудь про CAS.

Что именно? Я такой CAS делал. Это просто спцифический загрузчик, который вешает хуки на системные вызовы и умничает во время этих вызовов. Ну и сам CAS тоже, знаешь ли, вовсе не приложение уровня ядра. А требуется именно изкаробки.

Здравствуйте, WolfHound, Вы писали:

S>>Ваше воображение работает не в ту сторону. Модулю не нужно узнавать о том, как его вызывают. Почитайте что-нибудь про CAS.
WH>CAS та еще бяка.

Именно что. Ровно один уровень прав для всех приложений в помойке.

Здравствуйте, vdimas, Вы писали:

V>Пассаж был в том, чтобы самому раскрасить кусок какого-нить реального кода и показать для примера.
А-а. Ну я привёл вам примеры того, что можно делать, а что нельзя.

V>Неудачный пример, не поможет, если оба Title являются чьими-то мемберами. Например, второй Title — мембер объекта, с процедурой Fail.
Я восхищаюсь вашей способсностью спорить за обе стороны. Сначала вы мне рассказываете, что достаточно выделять ключевые слова, а теперь вам недостаточно предложенной мной раскраски.
Ну, спасибо за аргумент — я не против выделять своих и чужих мемберов по-разному, хотя обычно нужды в этом нет.

V>Выделеное именно так и подсвечивается. Тут ты угадал. Сам модуль в списке импорта тоже подсвечивается красным как в заголовке импорта, так и в древовидном навигаторе по модели кода.
А остальное где?

V>В первых Дельфи, на которых я тоже успел пописать, пока нормальные компиляторы плюсов под винды не появились, раскраска была не сильно круче. Вот как раз только ключевые слова, литералы/числа и комментарии. Не помню там разный цвет под мемберы и локальные переменные.
Ну, а в Турбо Паскале 6.0 вообще не было никакой подсветки. Это что, доказывает её избыточность?
А в Delphi, скажем, 5, уже была довольно-таки богатая подсветка. Ознакомьтесь.

V>Легко не легко — это спекуляции. Действительно нормальную раскраску кода в IDE я увидел уже в конце 90-х начала 2000-х, когда Оберон уже перестали разрабатывать. А до это все были тупые или как?
Сравните производительность редакторов Turbo Pascal 5.0 и Borland Pascal 7.0 на одной и той же 286 машине.

V>В общем, в твоей рефлексии для меня новости нет. Это ты и именно ты больше всех был глашатаем дотнета на заре этого сайта.
Правда? Жжоте, коллега, жжоте.

V>Это именно твои определенные навыки, и, я бы даже сказал твой талант, в области бла-бла-бла языком, прямо на этом сайте создавали дотнету определенную репутацию... что даже я когда-то верил. Ведь лично ты разводил тут такую отборную Ньювасюковщину, таким соловьем заливался, что вот мол, вы сейчас можете писать на дотнете, а потом эта среда станет супер-пупер и ваши инвестиции только окрепнут. А по факту: мастшабируемость никакая, эффективность так и осталась на уровне десятилетней давности, и даже в будущих проектах ничего на этот счет не говорят. Вот это упс так упс вышел... Нехорошо получилось, правда? Ты мне должен за зря потраченное время в человекогодах.

Здравствуйте, vdimas, Вы писали:

V>С какой стати не нужны?
А зачем они им? Компоненты делают свою работу.

S>>А вот тем, кто хочет работать с чем-то особенным (например, собственно backup engine, которому нужен tape access), будут получать доступ через подтверждение.
V>Это унылое Г. Раздача прав в "ленивой" манере, то бишь по-требованию, адекватна только для десктопного юзверя. Никакой админ с тобой не согласится.
Рад вашей способности делать утверждения от имени широких аудиторий, с которыми вы незнакомы.
Вам знаком термин out-of-the-box security? Он не очень новый. Применительно к SQL Server его начали употреблять примерно в 2004, когда МС стала отключать по умолчанию ненужные компоненты.
Это ровно тот же подход, только реализованный в другой среде.

V>Гы-гы, общедоступная либа CommonCtrl.dll, которая ничего не знает о каком-то там Explorer.
Это в убогой среде с аппаратной изоляцией это "общедоступная либа". А в софтварно-изолированной среде с CBS это отдельное приложение.

V>Еще раз, вот это удаленно не работает:
V>

V>я заставлю его работать с внешним приложением-конфигуратором, которое будет ему давать доступ к файлам, которые лично я ему подтвердил — хотя бы через конфиг-файл, права на доступ к которому я получаю тем же способом через OpenFileDialog на своём администраторском ноутбуке.

V>из-за предложенной "ленивой" манеры раздачи прав.
Всё работает, просто вам лень подумать головой.

V>Что ты понимаешь под изоляцией процессов? И почему у удаленного пользователя должно быть много прав?
Под изоляцией процессов понимается CBS. Прав у пользователя много по служебной необходимости. Например, у вас есть право доступа до вашей адресной книги, до ваших личных документов, и право отправлять почту внешним адресатам. Если у вас забрать эти права, вы не сможете работать. Если дать эти права любому коду, то этот любой код от вашего имени порушит вам нахрен весь бизнес.

V>Механизмы защиты через типобезопасность. Модуль-то SYSTEM можно запретить импортировать. Ес-но, как и в Сингулярити потребуется создать некий "пояс доверия", т.е. небольшую часть кода, которую заведомо можно считать безопасной, а остальным будет доступно только то, что доступно через честное АПИ.

Остаётся вопрос о том, как вы избавитесь от возможности сделать гадость через честное АПИ.

V>Я же говорю, ты споришь сам с собой, сравнивая исключительно два крайних сценария. Если бы я предложил тебе аналогичный сценарий для серверного "доверенного" приложения, которое пускает всех подряд юзверов (ну, забыли один if в коде, с кем не бывает), то ты бы быстро вспомнил о совместной о суперпозиции прав, так? Я ответил на твой вопрос?
Нет, не ответил. Вы опять пишете не в тему, совершенно не понимая сути обсуждаемого предмета.

V>Что именно? Я такой CAS делал. Это просто спцифический загрузчик, который вешает хуки на системные вызовы и умничает во время этих вызовов. Ну и сам CAS тоже, знаешь ли, вовсе не приложение уровня ядра. А требуется именно изкаробки.

Здравствуйте, samius, Вы писали:

V>>Вот. Вопрос: а зачем ты пытался перевести тему исходного обсуждения?
S>Напоминаю: тема, в рамках которой я влез — твои сомнения в смысле обсуждать тормозные среды исполнения.

Ну так они, сомнения, до сих пор есть. Какой смысл их обсуждать в теме о нейтивной технологии?

S>А ты все время пытаешься обсудить со мной какие-то другие темы, в том числе запуск оберона на арм-е и мои переводы темы.

Я не обсуждаю, это факт в ответ на твой факт. А зачем ты привел спутник на основе мобильника, например? Что тобой двигало? А что ты почуствовал после публикации этого факта?
Вот так же примерно ты решил заняться психоанализом меня. ))

V>>Э нет, если кому-то что-то повторяю, это не значит спор с самим собой, это значит, что жду ответа по существу от начинающего бегать собеседника. Захотелось пообщаться на эти темы? Ну давай общаться.
S>Ты не повторяешь. Ты высказываешь противоположный своему тезису.

Какой из них кому противоположен?

S>Знаешь что, я не собирался технологии обозревать. Я критикую твои сомнения относительно смысла обсуждения.

Одно без другого никак на техническом форуме, увы. В лучшем случае можно напроситься на иронию.

V>>Опять не согласен — опять обоснуй.
S>Это возражение твоему исходному сомнению, а не моему аргументу.
S>Давай-ка я помещу твое сомнение и аргумент против него рядом, что бы ты понял наконец, о чем речь:
S>

S>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

Ясно, ты просто влез с середины, утеряв контекст. Имелось ввиду обсуждать прямо здесь, в этой ветке, а не вообще. Мне ведь и Лисп тут в пример приводили... В том контексте аналогично — тыкали, что нет "хорошего" Оберона под Винды. Это ж вообще как надо было потеряться в обсуждении...

Считай, что по 10-му разу я от подобной откровенной хрени уже лениво и далеко не так тщательно отмахиваюсь... есть такое.

S>

S>Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать.

Конкретно ты срефлексировал на тормознутость Андроида или Дотнета (на свой выбор) и я высказался, (коль речь все-равно пошла об этих средах), что имею право упоминать (обсуждать) подробности. В общем, похоже ты не преодолел тот конфуз, что мне эти специфические технические подробности сред ПРИШЛОСЬ упомянуть, чтобы пояснить своё мнение насчет того, почему же нет смысла обсуждать/сравнивать эти среды в этом топике. А в других темах — да ради бога и я сам регулярно обе платформы обсуждаю. Но ты же как контраргумент вообще привел рынок... Не стыдно?

S>Или ты считаешь оберон популярнее андройда?

Гы, разве может кол-во обсуждений Андроида сравниться с колв-ом обсуждений Оберона? Или тебе жалко даже выделить одно вшивое обсуждение раз в 8 лет? Или увидел где-то что я именно так считаю? Или тебя тоже раздражает просто сама тема, как некоторых?

Начал не я... просто вижу резкие необъяснимые рефлексии, как на мозоль наступили... Дык, наш клиент. )))
Кароч, почему случилось обсуждение сказал в последней, но обширной части этого поста: http://www.rsdn.ru/forum/philosophy/4828600.1.aspx
Получил массу удовольствия от общения... жаль, что оно закончилось — все аргументы всех сторон пошли по 2-му и более кругу. Твои аргументы я тоже уже слышал и уже отвечал, можно найти при желании. Так что, Аминь.

Здравствуйте, vdimas, Вы писали:

V>Просто Вирт и Co обогнали время... Просто ты нифига об Обероне не знаешь, судя по этому посту, т.к. твои реплики полностью противоречат реально произошедшему.

V>Ну и такой момент, что за основу языка был взят синтаксис Паскаля, а наиболее популярны сейчас языки с Си-подобным синтаксисом... и, смотрю, некоторые считают возможным причислять "недопаскалистов" к неоспоримым нубам, так ведь? Но синтаксис, ИМХО, дело не то, что десятое, а даже сотое при сравнении возможностей языков.
Сергей Губанов, вы реинкарнировали в vdimas?

Здравствуйте, Sinclair, Вы писали:

V>>Неудачный пример, не поможет, если оба Title являются чьими-то мемберами. Например, второй Title — мембер объекта, с процедурой Fail.
S>Я восхищаюсь вашей способсностью спорить за обе стороны. Сначала вы мне рассказываете, что достаточно выделять ключевые слова, а теперь вам недостаточно предложенной мной раскраски.

МНЕ для ТАКОГО языка достаточно. Бо мне есть с чем сравнить.
Я слово МНЕ и ТАКОГО нормально выделил? )))

S>Ну, спасибо за аргумент — я не против выделять своих и чужих мемберов по-разному, хотя обычно нужды в этом нет.

V>>Выделеное именно так и подсвечивается. Тут ты угадал. Сам модуль в списке импорта тоже подсвечивается красным как в заголовке импорта, так и в древовидном навигаторе по модели кода.
S>А остальное где?

А остальное — только ключевые слова. И да, речь же BlackBox, а есть же среды на Обероне, на которых есть редакторы с полной подсветкой. Т.е. сама мешанина "частный BlackBox"->"Оберон как таковой", позволяет моей совести вести беседу в произвольноv по уровню серьезности стиле...

V>>В первых Дельфи, на которых я тоже успел пописать, пока нормальные компиляторы плюсов под винды не появились, раскраска была не сильно круче. Вот как раз только ключевые слова, литералы/числа и комментарии. Не помню там разный цвет под мемберы и локальные переменные.
S>Ну, а в Турбо Паскале 6.0 вообще не было никакой подсветки. Это что, доказывает её избыточность?

Ну в BorlandPascal 7.0 уже была подсветка тех самых ключевых слов. (и комментариев)

S>А в Delphi, скажем, 5, уже была довольно-таки богатая подсветка. Ознакомьтесь.

Фига себе, 5.0!!! Где бы посмотреть на Оберон 5.0???

Я последний раз программировал на таком Дельфи:

Пока не вышла VS 5.0. ))

V>>Легко не легко — это спекуляции. Действительно нормальную раскраску кода в IDE я увидел уже в конце 90-х начала 2000-х, когда Оберон уже перестали разрабатывать. А до это все были тупые или как?
S>Сравните производительность редакторов Turbo Pascal 5.0 и Borland Pascal 7.0 на одной и той же 286 машине.

Не стыдно скипать ключевое?

Или просто графические IDE на тех процессорах тормозили сами по себе даже без сложной раскраски?

И да, на моей 20MHz двойке оба этих редактора работали мгновенно. В отличие от Notepad на ней же под Win 2.0.

V>>В общем, в твоей рефлексии для меня новости нет. Это ты и именно ты больше всех был глашатаем дотнета на заре этого сайта.
S>Правда? Жжоте, коллега, жжоте.

Увы, правда. Аж зачитывался и считал тебя за технический авторитет. Можно ведь при желании поднять старые-старые темы.

Самому грустно и смешно одновременно. ))

Здравствуйте, vdimas, Вы писали:

V>Вообще, я сейчас вспоминаю те давние обсуждения и вижу, блин, насколько правы были те, кто говорил, что дотнет и прочие секты — это dogfood для окружающих. Что сама MS выпускает качественные рыночные продукты, ядро которых нейтив и только нейтив. А дотнет они сами пользуют чисто в утилитных целях. Ведь даже среда разработки, по сути, утилитный продукт для выпуски других продуктов. А не самоцель, за которую ты только что судорожно уцепился. Наше вам пффф с кисточкой...

MS .net — это клей над native API.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Напоминаю: тема, в рамках которой я влез — твои сомнения в смысле обсуждать тормозные среды исполнения.

V>Ну так они, сомнения, до сих пор есть. Какой смысл их обсуждать в теме о нейтивной технологии?
Это вопрос к тебе же. Ты ведь их упомянул в контексте, в котором их не было. Держи цитату:

VD>За фиг кому-то нужны какие-то левые ОС? Всем нужны компиляторы под виндовс или линукс. Причем желательно с поддержкой IDE.

Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

S>>А ты все время пытаешься обсудить со мной какие-то другие темы, в том числе запуск оберона на арм-е и мои переводы темы.

V>Я не обсуждаю, это факт в ответ на твой факт. А зачем ты привел спутник на основе мобильника, например? Что тобой двигало? А что ты почуствовал после публикации этого факта?
Я привел ссылку в ответ на твой пост

Не так. Ждем спутников на Андроиде.

V>Вот так же примерно ты решил заняться психоанализом меня. ))
Можно цитату с психоанализом?

S>>Ты не повторяешь. Ты высказываешь противоположный своему тезису.

V>Какой из них кому противоположен?
Я уже устал их цитировать

S>>Знаешь что, я не собирался технологии обозревать. Я критикую твои сомнения относительно смысла обсуждения.

V>Одно без другого никак на техническом форуме, увы. В лучшем случае можно напроситься на иронию.

V>>>Опять не согласен — опять обоснуй.
S>>Это возражение твоему исходному сомнению, а не моему аргументу.
S>>Давай-ка я помещу твое сомнение и аргумент против него рядом, что бы ты понял наконец, о чем речь:
S>>

S>>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?

V>Ясно, ты просто влез с середины, утеряв контекст. Имелось ввиду обсуждать прямо здесь, в этой ветке, а не вообще. Мне ведь и Лисп тут в пример приводили... В том контексте аналогично — тыкали, что нет "хорошего" Оберона под Винды. Это ж вообще как надо было потеряться в обсуждении...

Считай, что по 10-му разу я от подобной откровенной хрени уже лениво и далеко не так тщательно отмахиваюсь... есть такое.
Ты сам ввел этот контекст. Цитата наверху этого сообщения.

S>>

S>>Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать.

V>Конкретно ты срефлексировал на тормознутость Андроида или Дотнета (на свой выбор) и я высказался, (коль речь все-равно пошла об этих средах), что имею право упоминать (обсуждать) подробности. В общем, похоже ты не преодолел тот конфуз, что мне эти специфические технические подробности сред ПРИШЛОСЬ упомянуть, чтобы пояснить своё мнение насчет того, почему же нет смысла обсуждать/сравнивать эти среды в этом топике. А в других темах — да ради бога и я сам регулярно обе платформы обсуждаю. Но ты же как контраргумент вообще привел рынок... Не стыдно?
А вот это уже психоанализом пахнет. Если тебе виднее, на что я срефлексировал, то пусть так и останется.

S>>Или ты считаешь оберон популярнее андройда?

V>Гы, разве может кол-во обсуждений Андроида сравниться с колв-ом обсуждений Оберона? Или тебе жалко даже выделить одно вшивое обсуждение раз в 8 лет? Или увидел где-то что я именно так считаю? Или тебя тоже раздражает просто сама тема, как некоторых?
Да я просто подколол. Если бы ты действительно считал оберон популярнее андройда, то противоречия в твоих тезисах не было бы.

V>Начал не я... просто вижу резкие необъяснимые рефлексии, как на мозоль наступили... Дык, наш клиент. )))
А я-то что вижу... но оставлю при себе.

V>Кароч, почему случилось обсуждение сказал в последней, но обширной части этого поста: http://www.rsdn.ru/forum/philosophy/4828600.1.aspx
V>Получил массу удовольствия от общения... жаль, что оно закончилось — все аргументы всех сторон пошли по 2-му и более кругу. Твои аргументы я тоже уже слышал и уже отвечал, можно найти при желании. Так что, Аминь.
Я никаких аргументов не приводил. Я всего лишь написал что будем ждать когда оберон станет настолько популярным и востребованным что можно будет не обсуждать тормоза дотнета и андройда. Ссылка на спутник на андройде не была аргументом, если чо.

До связи

Здравствуйте, Sinclair, Вы писали:

V>>из-за предложенной "ленивой" манеры раздачи прав.
S>Всё работает, просто вам лень подумать головой.

Может и лень, вдруг я придумаю не точно так, как ты имел ввиду. Что мешает привести по пунктам полный сценарий?

V>>Что ты понимаешь под изоляцией процессов? И почему у удаленного пользователя должно быть много прав?
S>Под изоляцией процессов понимается CBS. Прав у пользователя много по служебной необходимости. Например, у вас есть право доступа до вашей адресной книги, до ваших личных документов, и право отправлять почту внешним адресатам. Если у вас забрать эти права, вы не сможете работать. Если дать эти права любому коду, то этот любой код от вашего имени порушит вам нахрен весь бизнес.

Ясно, всё было напрасно...
Этот любой код не порушит, ес-но. См. большинство новых апи виндов с суффиксом EX, там зачастую попадаются такие интересные структуры, как описание текущих аттрибутов безопасности над всякими токенами доступа.

V>>Механизмы защиты через типобезопасность. Модуль-то SYSTEM можно запретить импортировать. Ес-но, как и в Сингулярити потребуется создать некий "пояс доверия", т.е. небольшую часть кода, которую заведомо можно считать безопасной, а остальным будет доступно только то, что доступно через честное АПИ.

S>Остаётся вопрос о том, как вы избавитесь от возможности сделать гадость через честное АПИ.

Дык, много-много постов назад я уже сказал:

Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.

Понимаешь, современные приложения попадают в GAS исключительно потому, что они используют всё еще доступное устаревшее АПИ, в которых НЕ надо подавать SECURITY_ATTRIBUTES, чтобы сделать хоть что-то опасное. Рекомендую посмотреть в MSDN операции над SECURITY_ATTRIBUTES (SECURITY_DESCRIPTOR), а то я как-то в стенку разговариваю, похоже, без содержательного отклика. Надеюсь, объяснять, как происходит суперпозиция сразу нескольких наборов прав в координатах allow/deny не надо?

Т.е. фишка текущей ситуации вокруг CAS в том, что Windows (или любой самописный CAS) не ограничивает в возможности приложений "точечно" не потому, что принципиально не может этого сделать, а потому что НЕ ХОЧЕТ этого делать, чтобы дать возможность приложению на основе устаревшего АПИ хоть как-то загрузиться и хоть как-то работать. Поэтому предоставляет старое небезопасное АПИ через песочницу.

V>>Если бы я предложил тебе аналогичный сценарий для серверного "доверенного" приложения, которое пускает всех подряд юзверов (ну, забыли один if в коде, с кем не бывает), то ты бы быстро вспомнил о совместной о суперпозиции прав, так? Я ответил на твой вопрос?
S>Нет, не ответил. Вы опять пишете не в тему, совершенно не понимая сути обсуждаемого предмета.

Т.е. полностью аналогичный твоему аргумент, но на основе противоположной крайности, ты так и не понял? Неожиданно, прямо скажем... всего-то хотел показать нелепость рассуждений на основе крайностей. Фиг с ним, учту подобную непреодолимость на будущее.

V>>Что именно? Я такой CAS делал. Это просто спцифический загрузчик, который вешает хуки на системные вызовы и умничает во время этих вызовов. Ну и сам CAS тоже, знаешь ли, вовсе не приложение уровня ядра. А требуется именно изкаробки.
S>

Угу, что происходит при загрузке приложения в CAS мы не знаем...

Здравствуйте, samius, Вы писали:

S>Ты сам ввел этот контекст. Цитата наверху этого сообщения.

Для меня вся выделенная ветка — один контекст. Скажем так, чтобы сосредоточиться на какой-то совсем отдельной ветке — это мне надо перечитать конкретную ветку заново. А это нереально, сорри. Поэтому любые новые ответы я даю с учетом уже прозвучавших аргументов со всех сторон.

S>А вот это уже психоанализом пахнет. Если тебе виднее, на что я срефлексировал, то пусть так и останется.

Т.е. это не ты писал?

Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

V>>Начал не я... просто вижу резкие необъяснимые рефлексии, как на мозоль наступили... Дык, наш клиент. )))
S>А я-то что вижу... но оставлю при себе.

Дык поделись, фигли уже...

S>Я никаких аргументов не приводил. Я всего лишь написал что будем ждать когда оберон станет настолько популярным и востребованным что можно будет не обсуждать тормоза дотнета и андройда.

Еще раз крупным по белому, вопрос был в том, какой смысл обсуждать тормозные среды исполнения здесь, в этом топике. Логичнее было бы обсуждать среды, построеные на аналогичном принципе. И да, таких сред гораздо больше, чем две обсужденные шт: Оберон vs Сингулярити. Вот если бы ты привел для обсуждения еще одну подобную или высказался по одной из уже упомянутых — мне это было бы интереснее. Вот и всё что я сказал. Может я и не так подробно высказал своё желание. Ну сорри и так много букв сюда пишу. Но отмахиваться от Лиспа, Эрланга, Виндовса и прочего нерелевантного обсуждению бреда мне категорически надоело. Если перечитаешь тему целиком — поймешь почему.

Здравствуйте, novitk, Вы писали:

N>Там ведь всего три предложения. У тебя с английским тоже проблемы? Я подчеркну, возьми словарь и переведи три раза.
N>

N>An MVar t is mutable location that is either empty or contains a value of type t. It has two fundamental operations: putMVar which fills an MVar if it is empty and blocks otherwise, and takeMVar which empties an MVar if it is full and blocks otherwise.

Хосподя...

Это и есть то самое определение эксклюзивного доступа. Забрали доступ — прочитали переменную, записали переменную — вернули доступ. Что ж так туго-то?
Это полный семантический эквивалент паре операций блокировки. Чтобы меньше тебя путать, им надо было эти ф-ии назвать не takeMVar/putMVar, а более привычно acquire/release.

N>"Смотрю в книгу, вижу фигу."

Ну да.

N>

They can be used in multiple different ways:
N> 1. As synchronized mutable variables,

Именно, это полный семантический эквивалент мутабельной переменной с локом. Думал, я тебе вру? )))

N>

They can be used in multiple different ways:
N> 2. As channels, with takeMVar and putMVar as receive and send

Это уже опциональные фантазии авторов. Что делать с синхронизируемыми данными мы разберемся без сопливых. Сценариев много, здесь справедливо только то, что передачу данных м/у потоками придется делать ручками в обычной манере вокруг синхронизируемых расшаренных данных.

N>

They can be used in multiple different ways:
N> As a binary semaphore MVar (), with takeMVar and putMVar as wait and signal.

Бинарный семафор по определению мьютекс. То бишь, они как бэ намекают, что если игнорить значение, хранимое в MVar, то остаётся только функциональность мьютекса acquire/release, он же семафор со счетчиком 1. Ну на тот случай если мы сами тупые и не догадаемся. )))

N>Вот например AWAIT из твоего любимого Оберона:
N>

N>await :: MVar a->(a->Bool)->IO a
N>await mv f = do v <- takeMVar mv
N>                if f v then return v else await mv f
N>

+1
Возразить нечего. Отличное уточнение.
Как и в любом императивном языке await легко выразим через синхронизируемый доступ + проверки. Заметь, IO обязательно, потому что функциональной чистоты нет, требуется детерминированная последовательность операций в цикле await.

V>>Но и это не принципиально. Прикол в том, что именно ты прокоментировал на какую именно мысль. Всю тяжесть выбитого лулза, боюсь, у тебя не получилось осознать до сих пор... Ты ведь прокоментировал мысль о том, что чистому функциональному языку нужен механизм продолжений для реализации агентской среды, так?

N>Я всего лишь весьма вежливо указал на твою неосведомленность о наличие в Хаскелле активных обьекты в 95-м году.

Их там и сейчас нет. Это расширение языка не входит в официальную поставку самого работоспособного на сегодня компилятора HGC.

N>Ты, вместо того чтобы признать свое незнание, ни к селу ни к городу закричал "MVar — это мутабельное говно".

Незнание неких экзотических фактов — фигня. А вот непонимание фактов — уже натуральный упс. Ты только в этом посте сам докопался что там и как там, а мне, ни разу не хаскелисту, потребовалось ~5мин. И кто тут клоун?

N>После этого я сделал две попытки выяснить, чем это отличается от реализации AWAIT в обероне, но ты накрылся демагогией и я понял бессмысленность продолжения.

Если бы ты, скажем так, подал свои "факты" без характерного наезда, и плюс прокоментировал бы ключевой момент насчет продолжений в случае чистого функционального языка, я бы тебе подсказку в виде "conditional variables" дал бы сразу. Так-то я дружелюбный, если оппонент такой же. )) Ты ведь сугубо упрямства ради до сих пор не признаешь нерелевантности своего примера относительно высказанонй мысли в плане продложений. Т.е. каким бы любопытным не был некий приведенный факт, если его хочется использовать в кач-ве аргумента, он должен быть релевантным. Иначе это просто любопытный факт и не более.

Здравствуйте, Sinclair, Вы писали:

S>>>1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?
V>>Затем. Поставь изкаробки WinServer2008. Ничего сам не настраивай. Вроде бы обычная винда (так и есть, кстате). Посади на эту операцинку свою девушку или любого другого продвинутого пользователя, но не прожженого админа. Пользоваться этой виндой он/она не сможет. Даже приличная часть программистов не сразу сможет ей пользоваться как десктопом... хотя, нефик делать, если разобраться — это обычная винда... Просто изкаробки всё запрещено. Т.е. даже в условиях относительно примитивной модели безопасности Windows (сравнить с юниксовой), система абсолютна неюзабельна для пользователя.
S>Не понял смысл вашего мысленного эксперимента.

Мде...

S>Ешё раз спрошу: зачем вы дали редактору право ходить в любое место в интернете?

Я-то пока ничего никому не давал. Я привел в пример сравнение м/у десктопной Windows, которая изкаробки не запрещает исходящие соединения никаким приложениям и серверную Windows, где по-умолчанию всё запрещено. Зачем я привел такой пример? Потому что оппоненты и ты в т.ч. предлагаете модель, которая близка по духу модели серверной операционки. Т.е. одно дело — умозрительные рассуждения, а другое дело посчупать похожую модель в деле. Я предлагаю всем желающим посчупать прямо сейчас...

S>Если вы хотите поговорить о социальной инженерии — давайте поговорим. Но не стоит смешивать её с техническими вопросами.

Почему не стоит? Любые соглашения так или иначе будут выражены в некоем АПИ.

Изначально я утверждал (из-за чего всё, собственно), что простой полной типобезопасности мне бы хватило для очень многого, т.к. ключевая безопасность ПО обеспечивается совместно с инфраструкторой и никак иначе. И даже нарисовал модель — как именно это происходит во ваимодействии м/у объектами из разных модулей: через security-артефакты, передаваемые в виде аргументов. Почему именно так? А чтобы не надо было реализовать опять же такие предложенные (не мной) технические детали, где бы каждый модуль контролировал, кто же его вызывает. ИМХО, в привычном ООП это банально неудобно.

Здравствуйте, vdimas, Вы писали:

N>>

N>>An MVar t is mutable location that is either empty or contains a value of type t. It has two fundamental operations: putMVar which fills an MVar if it is empty and blocks otherwise, and takeMVar which empties an MVar if it is full and blocks otherwise.

V>Хосподя...

V>Это и есть то самое определение эксклюзивного доступа. Забрали доступ — прочитали переменную, записали переменную — вернули доступ. Что ж так туго-то?
Нет. Это очередное подтверждение того что ты читать не умеешь.

V>Это полный семантический эквивалент паре операций блокировки. Чтобы меньше тебя путать, им надо было эти ф-ии назвать не takeMVar/putMVar, а более привычно acquire/release.
Это полный семантический аналог очереди, в которую помещается ровно одно сообщение.
Чтобы не путать тебя, нужно было назвать эти функции send/receive.

N>>

N>> 1. As synchronized mutable variables,

V>Именно, это полный семантический эквивалент мутабельной переменной с локом. Думал, я тебе вру? )))
Конечно.
Ибо с помощью этого можно эмулировать данную функциональность.

N>>

N>> 2. As channels, with takeMVar and putMVar as receive and send

V>Это уже опциональные фантазии авторов.
Это родная семантика MVar.
Читай описание takeMVar и putMVar до просветления.

V>Что делать с синхронизируемыми данными мы разберемся без сопливых.
Сказал великий гуру не умеющий читать.

N>>Вот например AWAIT из твоего любимого Оберона:
N>>

N>>await :: MVar a->(a->Bool)->IO a
N>>await mv f = do v <- takeMVar mv
N>>                if f v then return v else await mv f
N>>

V>+1
V>Возразить нечего. Отличное уточнение.
А мне есть.
Это нихрена не аналог AWAIT из оберона.

V>Если бы ты, скажем так, подал свои "факты" без характерного наезда, и плюс прокоментировал бы ключевой момент насчет продолжений в случае чистого функционального языка, я бы тебе подсказку в виде "conditional variables" дал бы сразу.
http://en.wikipedia.org/wiki/Monad_%28functional_programming%29#Continuation_monad
Еще не понял насколько твои наезды на монаду IO, и воспевание продолжений выглядят смешно?

V>Т.е. каким бы любопытным не был некий приведенный факт, если его хочется использовать в кач-ве аргумента, он должен быть релевантным. Иначе это просто любопытный факт и не более.
Вот не тебе говорить про релевантность.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

Рад, что ты наконец разобрался. Очередная фантасмагория про кого-то, кто обещал "функциональной чистоту" в конкурентном программировании скипнута.

N>>Я всего лишь весьма вежливо указал на твою неосведомленность о наличие в Хаскелле активных обьекты в 95-м году.
V>Их там и сейчас нет. Это расширение языка не входит в официальную поставку самого работоспособного на сегодня компилятора HGC.

Очередная порция глупостей? Это не расширение языка, а рантайма и оно давно входит в "официальную поставку" GHC. Слово base в названии должны как бы намекать.

Здравствуйте, vdimas, Вы писали:

V>Я-то пока ничего никому не давал. Я привел в пример сравнение м/у десктопной Windows, которая изкаробки не запрещает исходящие соединения никаким приложениям и серверную Windows, где по-умолчанию всё запрещено. Зачем я привел такой пример? Потому что оппоненты и ты в т.ч. предлагаете модель, которая близка по духу модели серверной операционки. Т.е. одно дело — умозрительные рассуждения, а другое дело посчупать похожую модель в деле. Я предлагаю всем желающим посчупать прямо сейчас...
И? Лично я делаю это примерно раз в месяц в среднем (т.е. счупаю свежепоставленную серверную винду). Дальше что?

V>Почему не стоит? Любые соглашения так или иначе будут выражены в некоем АПИ.
Потому что социальная инженерия очень косвенно связана с техническим обеспечением.

V>Изначально я утверждал (из-за чего всё, собственно), что простой полной типобезопасности мне бы хватило для очень многого, т.к. ключевая безопасность ПО обеспечивается совместно с инфраструкторой и никак иначе. И даже нарисовал модель — как именно это происходит во ваимодействии м/у объектами из разных модулей: через security-артефакты, передаваемые в виде аргументов. Почему именно так? А чтобы не надо было реализовать опять же такие предложенные (не мной) технические детали, где бы каждый модуль контролировал, кто же его вызывает. ИМХО, в привычном ООП это банально неудобно.
А кто проверяет эти security — артефакты, передаваемые в виде аргументов?

Здравствуйте, vdimas, Вы писали:
V>МНЕ для ТАКОГО языка достаточно. Бо мне есть с чем сравнить.
V>Я слово МНЕ и ТАКОГО нормально выделил? )))
Нет. В вашем языке выделение будет примерно таким:
Мне ДЛЯ Такого Языка Достаточно. Бо мне ЕСТЬ С чем сравнить.

Потому что капсятся и орут как раз самые неинформативные слова — фактически предлоги, модальные глаголы, и пунктуация.

V>А остальное — только ключевые слова.
Это в унылых средах только ключевые слова.

V>Ну в BorlandPascal 7.0 уже была подсветка тех самых ключевых слов. (и комментариев)
И пунктуации. И литералов.

V>Я последний раз программировал на таком Дельфи:
V>

Уже в этом дельфи (вы точно уверены, что это программировали ещё на 16-разрядном Delphi?) подсветка всё ещё была в разы лучше, чем в BlackBox.
Но вы всё же определитесь — подсветка в Обероне не нужна, или её невозможно было реализовать по соображениям производительности?
Я так понимаю, что ни то, ни другое — просто в Обероне придумали, что программа будет гипертекстом, который пользователь будет раскрашивать руками. А как совмещается автоматическая раскраска с ручной, продумать никто не удосужился.

V>Не стыдно скипать ключевое?
V>

V>Или просто графические IDE на тех процессорах тормозили сами по себе даже без сложной раскраски?

С чего вы взяли, что это — ключевое? Стоимость самой раскраски никак не зависит от того, в текстовом или графическом режиме вы находитесь. От режима зависит только стоимость вывода на экран. А она — совершенно одинакова для разных цветов.
А вы мне сейчас пытаетесь рассказать про то, что Оберону не хватало перформанса для того, что Турбо Паскаль делал мгновенно.

V>И да, на моей 20MHz двойке оба этих редактора работали мгновенно. В отличие от Notepad на ней же под Win 2.0.
Ну вот видите.

V>Увы, правда. Аж зачитывался и считал тебя за технический авторитет. Можно ведь при желании поднять старые-старые темы.

Можно, конечно. Только результат вас разочарует.
Но я не про это, а про то, что вы перепутали RSDN с психологическим форумом. Здесь психоанализ собеседника — оффтоп, и никому не интересен.

Здравствуйте, Sinclair, Вы писали:

S>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?

Легче спросить — откуда они берутся. Проверяет их пусть софт из того самого "пояса безопасности", организующего системное АПИ.

Здравствуйте, WolfHound, Вы писали:

V>>Это и есть то самое определение эксклюзивного доступа. Забрали доступ — прочитали переменную, записали переменную — вернули доступ. Что ж так туго-то?
WH>Нет. Это очередное подтверждение того что ты читать не умеешь.

Кто тут читать не умеет видно невооруженым взглядом. Только что была расписана полная семантика. Давай, попробуй опровергнуть без отсылки к вики и прочим неопределенноличнымикиваниями головы в разные стороны. Попкорном я уже запася.

V>>Это полный семантический эквивалент паре операций блокировки. Чтобы меньше тебя путать, им надо было эти ф-ии назвать не takeMVar/putMVar, а более привычно acquire/release.
WH>Это полный семантический аналог очереди, в которую помещается ровно одно сообщение.

Осталось подумать чуть дальше и увидеть, что эта 1-ка сокращается в обоих частях уравнения и очередь вырождается... очередь вырождается... правильно, в привычный разделяемый ресурс. А то так можно договориться до того, что любая переменная — это массив, в котором кол-во элементов = 1.

Кстати, а Матлабе именно так и есть, любое единичное значение — это матрица [1,1]. Но это мне не мешает считать такое значение скаляром, бо любые операции над матрицей в такой размерности вырождаются... правильно, в скаляр и вырождаются.

И сейчас нихтферштейн?

WH>Чтобы не путать тебя, нужно было назвать эти функции send/receive.

Угу, как и на альфа-бленде простые вещи вызывают сложности и удивление. Тот факт, что сделали ф-ию, в которой ресурс не только блокируется, но сразу и читается (что естественно в ф-ом языке), а при разблокировке наоборот, на твой взгляд наделяют всю систему какими-то магическими свойствами? Сорри, но второй раз твое удивление при ознакомлении с новым материалом меня не заинтересует.

N>>>

N>>> 1. As synchronized mutable variables,

V>>Именно, это полный семантический эквивалент мутабельной переменной с локом. Думал, я тебе вру? )))
WH>Конечно.
WH>Ибо с помощью этого можно эмулировать данную функциональность.

А с помощью важных слов можно эмулировать умственную деятельность.
Это з каробки такая функциональность и есть — переменная с локом. Другое дело, что интерфейс к этой переменной, судя по твоей реакции, не такое как ты привык... Дык, поменьше бы сидел на дотнете, побольше бы смотрел по сторонам, как сейчас делают межпотоковый обмен. Не было бы для тебя ничего нового.

N>>>

N>>> 2. As channels, with takeMVar and putMVar as receive and send

V>>Это уже опциональные фантазии авторов.
WH>Это родная семантика MVar.

Это всего лишь фантазия авторов, как бы они хотели это назвать. Ну, чтобы прикрыть ~~свой срам~~ императивный характер привнесенного расширения. Но нас не проведешь.

WH>Читай описание takeMVar и putMVar до просветления.

Ну ты, я вижу, почитал и просветлился. Поздравляю с новым знанием. День прошел не зря. )))
А я эту кухню был в курсе когда ты еще в школе учился.

V>>Что делать с синхронизируемыми данными мы разберемся без сопливых.
WH>Сказал великий гуру не умеющий читать.

Ну, если формула Альфа бленда вызывает сложности и получаются картинки с видимыми на невооруженный глаз искажениями, как ты показал, то таки да... с чтением простейшего материала у кого-то бааальшие проблемы. Могу спорить на что угодно, что в ВУЗе ты безбожно прогуливал.

N>>>Вот например AWAIT из твоего любимого Оберона:
N>>>

N>>>await :: MVar a->(a->Bool)->IO a
N>>>await mv f = do v <- takeMVar mv
N>>>                if f v then return v else await mv f
N>>>

V>>+1
V>>Возразить нечего. Отличное уточнение.
WH>А мне есть.
WH>Это нихрена не аналог AWAIT из оберона.

Это не возражение, а ругань. Избрази AWAIT из Оберона в тех же координатах.
Здесь расписана семантика conditional variable, которая обыгрывается в 90% видимых мною семантик ключевого слова await из различных языков или их расширений.

V>>Если бы ты, скажем так, подал свои "факты" без характерного наезда, и плюс прокоментировал бы ключевой момент насчет продолжений в случае чистого функционального языка, я бы тебе подсказку в виде "conditional variables" дал бы сразу.
WH>http://en.wikipedia.org/wiki/Monad_%28functional_programming%29#Continuation_monad
WH>Еще не понял насколько твои наезды на монаду IO, и воспевание продолжений выглядят смешно?

Смешно что ты даешь ссылку, которую не понимаешь. Прямо как про обработку изображений.
И да, как именно в функциональном стиле организуется последовательность операций разбирали неоднократно. Ищи на этом сайте, повторяться не буду.
Наездом это не является, эта монада — банальное выпрямление порядка происходящего. Характерно, что в Хаскеле такая монада не просто задает порядок вычислений но и автоматически разрешает побочные эффекты, то бишь вносит императивность над мутабельным сотсоянием. Упссс... а вот этого ты и не заметил.

V>>Т.е. каким бы любопытным не был некий приведенный факт, если его хочется использовать в кач-ве аргумента, он должен быть релевантным. Иначе это просто любопытный факт и не более.
WH>Вот не тебе говорить про релевантность.

Ты еще не расчитался за мороку головы насчет альфа. Там испарился, здесь возник. Давай ты поступишь наоборот, справедливости ради.

Здравствуйте, novitk, Вы писали:

N>Рад, что ты наконец разобрался. Очередная фантасмагория про кого-то, кто обещал "функциональной чистоту" в конкурентном программировании скипнута.

На продолжениях она делается легко и обратное верно — при условии функциональной чистоты конкурентное програмирование доступно только на продолжениях. Просто в Хаскеле нет продложений. Ниасилили.

N>>>Я всего лишь весьма вежливо указал на твою неосведомленность о наличие в Хаскелле активных обьекты в 95-м году.
V>>Их там и сейчас нет. Это расширение языка не входит в официальную поставку самого работоспособного на сегодня компилятора HGC.

N>Очередная порция глупостей? Это не расширение языка, а рантайма и оно давно входит в "официальную поставку" GHC. Слово base в названии должны как бы намекать.

А... ну в таких вопросах свою неправоту я могу признать без проблем... упоминание Хаскеля в кач-ве чистого ф-ного языка было бааальшой ошибкой... Сначала я увидел там STM, а теперь ты еще показал MVar... Там что-нить от функциональной чистоты вообще осталось?

Ну ОК, в исходном тезисе Хаскель не подходит, надо заменить слово "Хаскель" на "Схему". А сам Хаскель предать анафеме. )))

Здравствуйте, Sinclair, Вы писали:

S>Потому что капсятся и орут как раз самые неинформативные слова — фактически предлоги, модальные глаголы, и пунктуация.

ИМХО, ключевые слова не воспринимаются за предлоги/глаголы после некоторой практики на любом языке. Они воспринимаются за некую атомарную единицу информации. За пиктограмму.

S>Но вы всё же определитесь — подсветка в Обероне не нужна, или её невозможно было реализовать по соображениям производительности?

Еще раз, для ЯВУ Оберона есть редакторы с полной подсветкой. Вот только что запустил линуховую виртуалку и открыл в ней среду Kate с нужными настройками:

Это не текстовый терминал "унутре" среды (а там есть и такая возможность), это просто я нашел TTF-версию комфортного мне шрифта и везде ставлю его по-умолчанию.

BlackBox был вообще под рассмотрением только потому, что это среда по винды, то бишь можно скачать и сразу посчупать без установки Оберон (А)ОС на виртуалку.

S>Я так понимаю, что ни то, ни другое — просто в Обероне придумали, что программа будет гипертекстом, который пользователь будет раскрашивать руками. А как совмещается автоматическая раскраска с ручной, продумать никто не удосужился.

Я так думаю, что во времена расцвета Оберона цветные мониторы были бааальшой редкостью... Ну это если уж совсем по справедливости.

V>>Не стыдно скипать ключевое?
V>>

V>>Или просто графические IDE на тех процессорах тормозили сами по себе даже без сложной раскраски?

S>С чего вы взяли, что это — ключевое? Стоимость самой раскраски никак не зависит от того, в текстовом или графическом режиме вы находитесь. От режима зависит только стоимость вывода на экран.

И раскраски, е-сно. Операция SetTextColor над GDI довольно дорогая, внутри инициализируются специальные Pen и Brush для глифов шрифта. Причем (если помнишь) исходный цвет округляется по тем временам до ближайшего цвета из палитры. А палитры тогда были практически всегда индексные, то бишь "округление" цвета на самом деле шло через линейный перебор всех вхождений в палитру и подбор наиболее близкого цвета. А операция нахождения абсоютной цветовой разницы для каждого вхождения из палитры — тоже дорогая. И т.д. и т.п. В общем, я много возился с GDI/MFC даже уже на пнях, так вот, до появления 200MHz компов вывод на экран вылизывался как ничто другое. Почему я кривлюсь до сих пор, когда вижу где-то ресайз, например, и промелькивает в процессе ресайза перерисовка заднего фона. Нубы неистребимы, кароч... )))

S>А вы мне сейчас пытаетесь рассказать про то, что Оберону не хватало перформанса для того, что Турбо Паскаль делал мгновенно.

Турбо-паскаль себя не раскрашивал. Раскрашивать стал Борланд-Паскаль и я его увидел только в начале 93-го.

V>>И да, на моей 20MHz двойке оба этих редактора работали мгновенно. В отличие от Notepad на ней же под Win 2.0.
S>Ну вот видите.

Дык, текстовый же режим, не графика. А в обероне — графика.

V>>Увы, правда. Аж зачитывался и считал тебя за технический авторитет. Можно ведь при желании поднять старые-старые темы.

S>Можно, конечно. Только результат вас разочарует.

Да поднимал не так давно.. случайно натыкаюсь регулярно на одно и то же...

S>Но я не про это, а про то, что вы перепутали RSDN с психологическим форумом. Здесь психоанализ собеседника — оффтоп, и никому не интересен.

Это я свои реакции вообще-то анализировал. Как бэ право имею, да и реакции были на рекламу технических моментов.

Здравствуйте, vdimas, Вы писали:

V>На продолжениях она делается легко и обратное верно — при условии функциональной чистоты конкурентное програмирование доступно только на продолжениях.
Реальную (с вытеснением и МТ) конкурентную среду без синхронизации не сделать. Продолжения это костыль для людей, которые не имеют к ней доступа.

V>Просто в Хаскеле нет продложений. Ниасилили.
"что же это у вас, чего ни хватишься, ничего нет!" (c) M. Булгаков
Давай ты уже перестанешь комментировать язык о котором нифига не знаешь. http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style
Только оно не нужно никому, так как есть Erlang-style примитивы и STM.

V>А... ну в таких вопросах свою неправоту я могу признать без проблем... упоминание Хаскеля в кач-ве чистого ф-ного языка было бааальшой ошибкой... Сначала я увидел там STM, а теперь ты еще показал MVar... Там что-нить от функциональной чистоты вообще осталось?

Какая в жопу чистота при взаимодействии с реальным недетерминированным миром. Хаскель не может изменить мир, он всего лишь позволяет его отделить на уровне системы типов.

V>Ну ОК, в исходном тезисе Хаскель не подходит, надо заменить слово "Хаскель" на "Схему". А сам Хаскель предать анафеме. )))
Опять двадцать пять. Теперь на схему зачем то наехал. http://docs.racket-lang.org/reference/concurrency.html

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Ты сам ввел этот контекст. Цитата наверху этого сообщения.

V>Для меня вся выделенная ветка — один контекст. Скажем так, чтобы сосредоточиться на какой-то совсем отдельной ветке — это мне надо перечитать конкретную ветку заново. А это нереально, сорри. Поэтому любые новые ответы я даю с учетом уже прозвучавших аргументов со всех сторон.
Тогда тем более странно что ты в одном контексте даешь такие "разносторонние" ответы. В том смысле что они по логике должны были бы принадлежать разным сторонам.

S>>А вот это уже психоанализом пахнет. Если тебе виднее, на что я срефлексировал, то пусть так и останется.

V>Т.е. это не ты писал?
V>

V>Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

Это я писал. И не надеялся что это послужит поводом к психоанализу.

V>>>Начал не я... просто вижу резкие необъяснимые рефлексии, как на мозоль наступили... Дык, наш клиент. )))
S>>А я-то что вижу... но оставлю при себе.

V>Дык поделись, фигли уже...
Ничего оригинального, чего бы в этой ветке не было написано в твой адрес.

S>>Я никаких аргументов не приводил. Я всего лишь написал что будем ждать когда оберон станет настолько популярным и востребованным что можно будет не обсуждать тормоза дотнета и андройда.

V>Еще раз крупным по белому, вопрос был в том, какой смысл обсуждать тормозные среды исполнения здесь, в этом топике. Логичнее было бы обсуждать среды, построеные на аналогичном принципе. И да, таких сред гораздо больше, чем две обсужденные шт: Оберон vs Сингулярити. Вот если бы ты привел для обсуждения еще одну подобную или высказался по одной из уже упомянутых — мне это было бы интереснее. Вот и всё что я сказал. Может я и не так подробно высказал своё желание. Ну сорри и так много букв сюда пишу. Но отмахиваться от Лиспа, Эрланга, Виндовса и прочего нерелевантного обсуждению бреда мне категорически надоело. Если перечитаешь тему целиком — поймешь почему.
А твоим оппонентам надоело отмахиваться от оберона. Тут не надо даже тему перечитывать что бы понять причину.
Давай лучше вместь приведения еще одной среды я подкину мысль что ось-среда/JM(или CLR) вероятно имела бы больший успех, чем оберон-ось. До кучи еще одна мысль, что если бы оно реально надо было кому-то, то оно бы уже было.

Здравствуйте, AndrewVK, Вы писали:

AVK>Я бы на твоем месте сильно задумался, почему столько людей, придерживающихся совершенно разных взглядов на языки программирования, тем не менее категорически с тобой не согласны.

А если я и так знаю? Да и ты и так знаешь, что я итак знаю и к чему тогда спрашивать? ))) Так надо. Кто-то несогласен "категорически", а кто по-существу. Будучи немного внимательным ты увидишь оставленное пространство для маневра практически в каждом посте по этой теме, даже в самых провокационных.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ужас то какой. Ну расскажи тогда, как в православном ООП 21 века следует разруливать такие ситуации: есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?

Это ты всерьез спросил или как все? ))

При наличии инструмента инкапсуляции ей можно не пользоваться. А когда инкапсуляции нет, то попользоваться ей при нужде не выйдет. Это ответ на то, что ты хотел спросить?

А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать. Визитор — это же развитие ф-сти объекта вне объекта. Может там будет подходящий сценарий упрятать ф-сть в самом объекте? А этот вариант ты мне на выбор не предоставил. А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных? Зачастую многократно и удобнейи эффективней, чем упаковывать значние конкретного типа в абстрактное и распаковывать затем на паттерн-матчинге или визиторе. Вариантов даже больше 4-х, кароч, а никак не 2.

Здравствуйте, vdimas, Вы писали:

V>Это ты всерьез спросил или как все? ))

Ты хами хами. Совсем чуть чуть осталось.

V>При наличии инструмента инкапсуляции ей можно не пользоваться. А когда инкапсуляции нет, то попользоваться ей при нужде не выйдет. Это ответ на то, что ты хотел спросить?

Нет. Вопрос был вполне конкретный. Просьба продемонстрировать тру ООП решение 21 века. Show me your code.

V>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.

Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.

V>Может там будет подходящий сценарий упрятать ф-сть в самом объекте?

Нет, не подходящий. Объект это AST, согласно SRP нагружать лишним функционалом не надо.

V>Вариантов даже больше 4-х, кароч, а никак не 2.

Да хоть 10. Код покажи.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, novitk, Вы писали:

V>>На продолжениях она делается легко и обратное верно — при условии функциональной чистоты конкурентное програмирование доступно только на продолжениях.
N>Реальную (с вытеснением и МТ) конкурентную среду без синхронизации не сделать. Продолжения это костыль для людей, которые не имеют к ней доступа.

А ты и не имеешь доступа из юзверского кода к вытесняющей многозадачности. А любые попытки таки сделать вытесняющую из юзверского кода (напр. управление фиберами по таймеру), превратят всю затею в профанацию. Да и вообще, это обсуждение выросло из обсуждения рядом агентской среды (акторов), а в ней акторы сидят в ожидании и получают кванты на обработку преимущественно тогда, когда им есть что делать, то бишь готов ввод-вывод. И я уже писал тут более одного раза, что в этих самых условиях, когда агенты сидят постоянно на вводе/выводе особой разницы м/у кооперативной многозадачностью и вытесняющей нет. Разница есть только тогда, когда процессы всё-время что-то делают, а не сидят по большей части в ожидании сигналов.

V>>Просто в Хаскеле нет продложений. Ниасилили.
N>"что же это у вас, чего ни хватишься, ничего нет!" (c) M. Булгаков
N>Давай ты уже перестанешь комментировать язык о котором нифига не знаешь. http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style

Это малость не то, что настоящие продолжения. Вместо текущего контекста вычисления захватывается только явно поданные вычисления/монады. Ну ок, а коротины на этом сделать можно, чтобы явно диспетчеризировать этому продолжению поступающие данные?

Т.е. в чем суть. (Напомню, рчь об асинхронности, то бишь не факт, что даже нужны примитивы синхроизации на прикладном уровне, скорее даже вредны)

Вот есть входные события. Можно нарисовать обработчики событий по простой событийной схеме, то бишь совершая работу над мутабельным состоянием в ответ на каждое событие через конкретную ф-ию-обработчик. А можно иначе — иметь некий контекст вычислений, который читает из некоего пайпа (абстракция) и каждый вызов зачитки данных из пайпа с т.з. потока исполнения этого контекста вычислений как бы блокирующий. А извне всё наоборот — вызов на ожидание "изнутри" такой коротины на основе продолжения будет означать взврат из процедуры записи в пайп для внешнего кода, то бишь конец цикла диспетчеризации события. Т.е. это не две независимые нити общаются и не два фибера, а просто вывернутая наизнанку логика из того же самого потока (который из пула), примерно как в async/await в C#.

V>>Ну ОК, в исходном тезисе Хаскель не подходит, надо заменить слово "Хаскель" на "Схему". А сам Хаскель предать анафеме. )))
N>Опять двадцать пять. Теперь на схему зачем то наехал. http://docs.racket-lang.org/reference/concurrency.html

Странно, call/cc и коротины на нем в стандарте Схемы вижу, а то, что по ссылке — не вижу.

Здравствуйте, VladD2, Вы писали:

C>>Это унылое дерьмо мамонта из 80-х годов.
VD>В плане истории важно не то что в нем нет, а то что в нем появилось. К сожалению, я не могу вспомнить ничего.
А в нём ничего и не появилось нового, абсолютно.

Здравствуйте, AndrewVK, Вы писали:

V>>Это ты всерьез спросил или как все? ))
AVK>Ты хами хами. Совсем чуть чуть осталось.
Ну, т.е. это у тебя случайно вырвалось?

Ужас то какой. Ну расскажи тогда, как в православном ООП 21 ...

Тебе ничего там не жмет? Кто-то чего-то недопонимает, похоже... В общем, прогибаться под такой стиль общения все-равно никто не станет. Раз уж на RSDN сложились такие нормы общения, значит будем исходить из того, что есть. А попытки угрожать модерством в топике, в котором что-то пытаешься спорить по существу... это ж почти аргумет в споре.

V>>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.
AVK>Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.

V>>Может там будет подходящий сценарий упрятать ф-сть в самом объекте?
AVK>Нет, не подходящий. Объект это AST, согласно SRP нагружать лишним функционалом не надо.

Это мне, как автору решения решать, сорри за тафтологию.

Зачем ты скипнул это?

А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных?

В ней суть, т.к. принципиально варианты разделяются вокруг идеологии poll/push, тут даже ООП не при чем, а SRP тем более ортогональная характеристика решения. Предложенные тобой варанты визитора vs АлгТД это же одно и тоже фактически. С некоторой долей вероятности эти два решения, будучи приведенным компилятором в машинный код, могут даже выглядеть одинаково. В общем, это рантайм-полиморфизм, которым ты заведомо наградил один и тот же элемент дизайна... т.е. обсуждать техники этого полиморфизма на фоне принципиального решения в дизайне — это палочкой ковыряться...

ИМХО, тут всё очевидно. Если у тебя интерфейс в стиле poll, то ты вынужден делать возвращаемое значение абстрактным, если функциональность "Дай" может вернуть значения более чем одного конкретного типа:
SomeAbstractValue Дай(Context context);

Причем, SomeAbstractValue приходится делать абcтрактным в рантайм. Я тебе уже не раз говорил, что такой подход называется так: сначала сливаем в бутылочное горлышко, потом обратно разливаем.

Можно сделать интерфейс в стиле push:
void На(Context context, Listener listener);

В этом случае уже доступен выбор compile-time или runtime полиморфизма для Listener. Но гвоздь в том, что значения конкретных типов, которые получаются в конкретном месте, не надо заворачивать в абстрактные. Техника немного близка к визитору, но лишь ровно на половину, к тому же зачастую позволяет избегать дорогих вирутальных вызовов в Listener.

V>>Вариантов даже больше 4-х, кароч, а никак не 2.
AVK>Да хоть 10. Код покажи.

Основные отличия показал.
Писать сюда визитор, или реализацию Listener ес-но не буду, всё и так тебе понятно, я уверен. Единственный интерес в таком дизайне (я его называю — эффективным, оперативным) сидит в том, где у нас будут идти переходы poll<=>push. Таких переходов в дизайне может быть намного больше одного. И вот тут уже, сорри, надо чуть больше данных для принятия решений. Само решение принимается фактически механически и зависит напрямую от твоей задачи (от колв-а и дороговизны операций над бутылкой). Самих техник перехода poll<=> push больше одного, один из них я привел как цитирование себя в этом же посте. Другие способы — чередование обработки данных с построением графа конечного результата, в т.ч. через отправку данных для второй операции в другой поток.

Здравствуйте, Kernan, Вы писали:

V>>Ну и такой момент, что за основу языка был взят синтаксис Паскаля, а наиболее популярны сейчас языки с Си-подобным синтаксисом... и, смотрю, некоторые считают возможным причислять "недопаскалистов" к неоспоримым нубам, так ведь? Но синтаксис, ИМХО, дело не то, что десятое, а даже сотое при сравнении возможностей языков.
K>Сергей Губанов, вы реинкарнировали в vdimas?

Окстись, я его похоже старше и еще не умер, чтобы в мой ник реаинкарнировать. )))

Здравствуйте, Kernan, Вы писали:

K>Сергей Губанов, вы реинкарнировали в vdimas?

И да, ты произнес ключевое слово, теперь ты вне игры. Следующий.

))

Здравствуйте, samius, Вы писали:

S>А твоим оппонентам надоело отмахиваться от оберона. Тут не надо даже тему перечитывать что бы понять причину.
S>Давай лучше вместь приведения еще одной среды я подкину мысль что ось-среда/JM(или CLR) вероятно имела бы больший успех, чем оберон-ось. До кучи еще одна мысль, что если бы оно реально надо было кому-то, то оно бы уже было.

Дык, а ты еще не понял? Мне надо. Не обязательно Оберон, но сам подход и все что связано. CLR/JM не подходят и близко. Скажем так, разница почти на порядок в эффективности по моим задачам. Я вообще расчитывал больше узнать, чем рассказать... бо сразу признался, что не изучал его настолько глубоко, как некоторые знаменитые здесь личности... Просто времена когда можно спросить и получить ответ на этом сайте давно прошли... оппонент "отрывает пятую точку" только когда с ним споришь.

Ну а что тут некоторые в мой адрес писали — вообще до фени. Это одни и те же личности, взаимные диспозиции с которыми определились еще до 2004-го. Ничего нового. Да и у меня тут много постов было за все годы, весьма разных. Каждый выбирает что ему нравится.

Здравствуйте, vdimas, Вы писали:

V>А попытки угрожать модерством в топике, в котором что-то пытаешься спорить по существу... это ж почти аргумет в споре.

Ты если еще не понял, это намек что ты в этом топике ведешь себя на грани допустимого. Сбавь обороты. К разговору со мной это отношения не имеет. И, коль ты уже личные нападки от безличных не отличаешь, дальнейшее обсуждение этого вопроса только на moderator@rsdn.ru

V>Зачем ты скипнул это?

Затем, что к вопросу отношения не имеет, обычное растекание мыслью по древу, из-за которого с тобой невозможно спорить.
Дальнейшее растекание тоже поскипано.

V>SomeAbstractValue Дай(Context context);

Что такое SomeAbstractValue?

V>Можно сделать интерфейс в стиле push:
V>void На(Context context, Listener listener);

Опять ничего не понятно.

V>>>Вариантов даже больше 4-х, кароч, а никак не 2.
AVK>>Да хоть 10. Код покажи.

V>Основные отличия показал.

А код — не показал. Одна пустая болтовня, уж извини. Причем много.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>И, коль ты уже личные нападки от безличных не отличаешь, дальнейшее обсуждение этого вопроса только на moderator@rsdn.ru

Жаловаться в мыло все-равно не буду. А на обороты некоторые личности растолкали, это да... Впрочем, все сообщения на месте, всё видно...

Здравствуйте, vdimas, Вы писали:

V>Еще раз, для ЯВУ Оберона есть редакторы с полной подсветкой. Вот только что запустил линуховую виртуалку и открыл в ней среду Kate с нужными настройками:
Это обычная подсветка синтаксиса. Детский сад, короче говоря.

Вот ТАК выглядит реальная подсветка в современных редакторах:

Здравствуйте, AndrewVK, Вы писали:

V>>SomeAbstractValue Дай(Context context);

AVK>Что такое SomeAbstractValue?

Это тот самый абстрактный тип, который ты задал по условию. Это либо алгТД, либо ОО-интерфейс посещаемой стороны в визиторе. По тому факту, какой именно элемент ты наградил абстрактностью, я понял о каком общем виде дизайна идет речь.

(И можно я таки не буду писать сюда классического визитора или эмуляцию размеченного объединения и никто мне за это не скажет, что я с этим не справился?)

V>>Можно сделать интерфейс в стиле push:
V>>void На(Context context, Listener listener);

AVK>Опять ничего не понятно.

Полезная работа выполняется в процедуре/ф-ии/методе На, на вход которой поданы необходимые данные + некий callback. Внутри в конкретных ветках алоритма, там, где ты ранее создавал значения конкретных типов и упаковывал их в абстрактные типы, теперь ты вызываешь типизированные перегрузки методов listener.

Например:

// algorithm node 1
string s = MakeString(chars, offset, length);
listener.process(s);
..
// algorithm node 2
SomeObject o = MakeObject(data);
listener.process(o);
...

class Listener {
  public void process(string s);
  public void process(SomeObject o);
...
}

AVK>Одна пустая болтовня, уж извини. Причем много.

С учетом этого:

AVK>Опять ничего не понятно.

Даже мало, походу. Никакой болтовни. Наложи уточение на прошлый пост. Я просто понятия не имею с какого уровня подробностей надо что-то объяснять. Начал из предположения, что все понятно. Нет — ок, буду уточнять по мере выяснения, что именно непонятно.

Еще я упоминал момент про замкнутый контекст, который переводит push опять в poll. Это примерно вот такая замена:

// algorithm node 2
SomeObject o = MakeObject(data);
astNodes.add((o)=>listener.process(o));

Это подходит для работы с конкретным Listener, когда над astNodes надо совершать всего одну операцию.

Если больше одной, то:

interface Listener {
...
}

class ListenerProxy : Listener {
  public void process(string s) { _proxee.process(s); }
...
  Listener _proxee;
}

Заметь, все эти poll-варианты являются вариациями, близкими к визитору по сути происходящего, но вдвое более скромными в плане поддержки, т.к. не требуют объявления и разработки интерфейса посещаемой стороны в визиторе, нужен только сам посетитель.

Здравствуйте, AndrewVK, Вы писали:

V>>А техника интерпретации какая была: p-код или работающее AST?

AVK>Второе.

Ну тогда предположу специфику — огромное кол-во типов узлов AST.
В обычном интерпретирующем языке кол-во типов узлов минимально, плюс обычно всего 2-4 базовых типа, и ф-сть самого интрепретатора меньше по объему, чем парсера.

Здравствуйте, Cyberax, Вы писали:

C>Вот ТАК выглядит реальная подсветка в современных редакторах:

Бррр... чуть глаза не сломал ))))
В современных редакторах это выглядит намного лучше:

Здравствуйте, vdimas, Вы писали:

C>>Вот ТАК выглядит реальная подсветка в современных редакторах:
V>Бррр... чуть глаза не сломал ))))
Вопрос конкретных цветов и шрифтов — это исключительно вопрос вкуса и личных предпочтений. Только сейчас заметил, что на картинке не учтено, что у меня высокий DPI — на обычных мониторах текст будет выглядеть слишком большим.

А вот вопрос функциональности — это уже не вопрос вкуса. Современные IDE понимают семантику языка и делают соответствующую подсветку.

V>В современных редакторах это выглядит намного лучше:
Точно. А для Оберона — ниасилили.

Здравствуйте, Cyberax, Вы писали:

V>>В современных редакторах это выглядит намного лучше:
C>Точно. А для Оберона — ниасилили.

И не осилят...

У них компоненты миниатюрного размера. А подсветка рулит для разбора завалов исходников. В общем, наличие проблемы надо сначала осознать. Не осознают, увы, это же не Джава. ))

Здравствуйте, vdimas, Вы писали:

V>Это я свои реакции вообще-то анализировал. Как бэ право имею, да и реакции были на рекламу технических моментов.
Ваша психология тоже здесь никого не интересует. Как и то, почему вы воспринимаете технические обсуждения за рекламу.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

S>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?

V>Легче спросить — откуда они берутся. Проверяет их пусть софт из того самого "пояса безопасности", организующего системное АПИ.
Ок, заодно расскажите, откуда они берутся. А то я, похоже, чего-то фундаментального не понимаю. Также, как и того, каким волшебным образом софт из "пояса безопасности" вдруг получит возможность что-то там проверить. Вот у меня "модуль" А вызывает метод объекта из "модуля" B. Допустим, это метод WebRequest.Send(). Как будет осуществляться проверка того, что модулю А можно разрешить эту операцию?

V>Это не текстовый терминал "унутре" среды (а там есть и такая возможность), это просто я нашел TTF-версию комфортного мне шрифта и везде ставлю его по-умолчанию.
Я правильно понимаю, что в этом варианте никакого "гипертекста" и ручной раскраски уже нет?
То есть мой тезис про ценность ручного раскрашивания кода таки подтвердился. Спасибо.

Здравствуйте, Sinclair, Вы писали:

S>>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?

V>>Легче спросить — откуда они берутся. Проверяет их пусть софт из того самого "пояса безопасности", организующего системное АПИ.
S>Ок, заодно расскажите, откуда они берутся. А то я, похоже, чего-то фундаментального не понимаю.

А как это организованно в виндах, понимаешь? Ну, чтобы я лишнего не писал.

S>Также, как и того, каким волшебным образом софт из "пояса безопасности" вдруг получит возможность что-то там проверить.

Он должен содержать код проверки, ес-но. Сама по себе из воздуха безопасность не возьмется.

S>Вот у меня "модуль" А вызывает метод объекта из "модуля" B. Допустим, это метод WebRequest.Send(). Как будет осуществляться проверка того, что модулю А можно разрешить эту операцию?

Есть т.н. "политика безопасности". Эта политика — список из десятков/сотен пунктов, по кажому из которых что-то прописано ("можно", "нельзя", "можно только локальному пользователю" и т.д.). См настройку политики в тех же виндах. Любая функциональность, попавшая в пункты из политики, хочешь или нет, должна войти в пояс безопасности.

Конкретно насчет WebRequest.Send(), артефакты безопасности будут переданы при вызове ниже и где-то будет просто уровень TCP-стека, к которому относятся несколько пунктов из политики и которые (эти пункты) будут проверяться в соотв, вызовах TCP. Т.е. модули, отвечающие за сетевой уровень, должны будут попасть внутрь пояса безопасности.

В общем, какая-то часть системного кода должна быть доверенной всё-равно. Должна быть некая точка опоры, от которой мы отталкиваемся. Так вот, остальное меня интересует только с т.з. хакнуть эту систему. Слабые места в ней тоже есть. Причем, слабость этих мест (оп-па!!!) не зависит от того, будет ли злонамеренный модуль изолированным процессом или модулем в общем объектном пространстве. Т.е. вот почему мне эта изолированность не принципиальна, — алгоритмы взлома одни и те же. Факт изолированности имеет значение только в том смысле как говорил Вольфхаунд, например из-за возможности гонок и порчи памяти из-за них. Но, ИМХО, гонки можно выявлять еще на этапе компиляции. А потом еще раз (для надежности) на этапе загрузки байт-кода.

Здравствуйте, Sinclair, Вы писали:

V>>Это я свои реакции вообще-то анализировал. Как бэ право имею, да и реакции были на рекламу технических моментов.
S>Ваша психология тоже здесь никого не интересует. Как и то, почему вы воспринимаете технические обсуждения за рекламу.

Э нет, коллега, есть такое дело, как объективная реальность. Если ты убедительно говорил о том, что будет, и при этом позже шли отчеты о поездках на семинары и общение с инсайдерами и ключевыми разработчиками, то изрекаемое тобой воспринималось как информация о продукте, в т.ч. когда речь шла о будущем направлении развития продукта. Подаваемая исключительно в положительном ключе информация о характеристиках продукта является рекламой по-определению, нравится тебе оно или нет. Так вот, упс в том, что всё это подаваемое на самом деле информацией не являлось, а являлось результатом деятельности твоего мыслительного аппарата, то бишь было сугубо твоим ИМХО. Просто ты регулярно забывал и забываешь упоминать эту важную особенность подачи т.н. "информации" в твоих постах. Вот и всё кино.

Здравствуйте, Sinclair, Вы писали:

S>Я правильно понимаю, что в этом варианте никакого "гипертекста" и ручной раскраски уже нет?
S>То есть мой тезис про ценность ручного раскрашивания кода таки подтвердился. Спасибо.

Дык это и не полноценная IDE для Оберона. Это просто редактор с раскраской под мильон языков и возможностью настроить запуск внешнего toolchain на сборку или отладку. Поддержка автокомплита у этой среды идет через внешний тул CTags, а там список языков поскромнее (порядка 40-ка языков). Модула-2 и Оберон в него не входит, т.е. для этих языков есть только поддержка раскраски в IDE.

Здравствуйте, Cyberax, Вы писали:

C>Только сейчас заметил, что на картинке не учтено, что у меня высокий DPI — на обычных мониторах текст будет выглядеть слишком большим.

Дело не в DPI, сам рендеринг шрифта кривой. Несимметричные исходно симметричные буквы, неравномерное расстояние м/у буквами, съезжающий со знакоместа курсив. В общем, как рендеринг шрифтов там еще настраивать и настраивать, так и сам шрифт стоит подобрать тщательнее... Глаза — это важный рабочий инструмент нашего брата. ))

Здравствуйте, vdimas, Вы писали:

Очепятка

V>

V>// algorithm node 2
V>SomeObject o = MakeObject(data);
V>astNodes.add((/*o*/)=>listener.process(o));
V>

Здравствуйте, vdimas, Вы писали:

V>Кто тут читать не умеет видно невооруженым взглядом.
Я думаю тут это уже всем видно.

V>Только что была расписана полная семантика. Давай, попробуй опровергнуть без отсылки к вики и прочим неопределенноличнымикиваниями головы в разные стороны. Попкорном я уже запася.
Попробуй написать атомарный
readMVar :: MVar a -> IO a
Если это изменяемая переменная с синхронизацией код будет простым.

Если бы все было, так как ты говоришь, то там была бы одна базовая операция.
modifyMVar :: MVar a -> (a -> IO (a, b)) -> IO b

V>И сейчас нихтферштейн?
Ты точно не понимаешь семантику этого дела.
И почему это крайне сложно привести к разделяемому ресурсу.

V>Угу, как и на альфа-бленде простые вещи вызывают сложности и удивление.
Ты так и не понял что такое альфа бленд.
И почему при бленде остальных каналов нужно использовать не только альфу, с которой происходит смешивание, но и альфу обоих пикселей?

V>Тот факт, что сделали ф-ию, в которой ресурс не только блокируется, но сразу и читается (что естественно в ф-ом языке), а при разблокировке наоборот, на твой взгляд наделяют всю систему какими-то магическими свойствами? Сорри, но второй раз твое удивление при ознакомлении с новым материалом меня не заинтересует.
В том то и дело что тут у нас совершенно иная семантика.
Но ты в очередной раз показываешь, что не в состоянии выделить модель.

V>А с помощью важных слов можно эмулировать умственную деятельность.
Ты тут этим и занимаешься.

V>Это з каробки такая функциональность и есть — переменная с локом. Другое дело, что интерфейс к этой переменной, судя по твоей реакции, не такое как ты привык... Дык, поменьше бы сидел на дотнете, побольше бы смотрел по сторонам, как сейчас делают межпотоковый обмен. Не было бы для тебя ничего нового.

Напиши readMVar :: MVar a -> IO a
А я посмеюсь.

V>Это всего лишь фантазия авторов, как бы они хотели это назвать. Ну, чтобы прикрыть ~~свой срам~~ императивный характер привнесенного расширения. Но нас не проведешь.
Ты постоянно говоришь о себе во множественном числе.
Это, похоже, уже диагноз.

V>Ну ты, я вижу, почитал и просветлился. Поздравляю с новым знанием. День прошел не зря. )))
V>А я эту кухню был в курсе когда ты еще в школе учился.
Ты не смог проанализировать одну строку документации.
Все твои выводы мусор.

V>Ну, если формула Альфа бленда вызывает сложности и получаются картинки с видимыми на невооруженный глаз искажениями, как ты показал, то таки да... с чтением простейшего материала у кого-то бааальшие проблемы. Могу спорить на что угодно, что в ВУЗе ты безбожно прогуливал.
Это у тебя большие проблемы.
Ибо я сразу сказал что картинка с искажениями получена при использовании формулы которая считает альфаканал равноправным. И смешивает все каналы независимо друг от друга.
Картинка без искажений получена при использовании правильной формулы. Которая при смешивании цветовых каналов использует альфу обоих пикселей.

V>Это не возражение, а ругань. Избрази AWAIT из Оберона в тех же координатах.
Сам изобрази.
Я гору кода писать не хочу.

V>Здесь расписана семантика conditional variable, которая обыгрывается в 90% видимых мною семантик ключевого слова await из различных языков или их расширений.

Твоя не способность понять что происходит в двух строках кода просто поражает.

V>Смешно что ты даешь ссылку, которую не понимаешь. Прямо как про обработку изображений.
Не суди по себе о других.

V>И да, как именно в функциональном стиле организуется последовательность операций разбирали неоднократно. Ищи на этом сайте, повторяться не буду.
Обычно монадами.
Просто заводят эстафетную палочку, которую передают ее от операции операции. В ней накапливаются все побочные эффекты. А всякие там MVar с точки зрения программы неизменяемые значения.
Но на физическом уровне (уже после всех оптимизаций проводимых над чистой программой) происходит магия.
Это позволяет с одной стороны языку оставаться чистым, а с другой стороны иметь строгий порядок выполнения операций там, где оно надо.

V>Наездом это не является, эта монада — банальное выпрямление порядка происходящего. Характерно, что в Хаскеле такая монада не просто задает порядок вычислений но и автоматически разрешает побочные эффекты, то бишь вносит императивность над мутабельным сотсоянием. Упссс... а вот этого ты и не заметил.
Это ты не заметил, что эта монада и есть твои континюэйшены о которых ты говоришь, что они все из себя функциональные.
И то, что использование этой монады будет выглядеть точно так же как использование монады IO.
Ну, просто буква в букву. Только IO будет заменено на Cont.
Монада IO, кстати, тоже вполне себе функциональна.

V>Ты еще не расчитался за мороку головы насчет альфа. Там испарился, здесь возник. Давай ты поступишь наоборот, справедливости ради.
Я просто уже устал повторять, что там нет проблем с гаммой. Там проблемы с тем, что каналы смешивались независимо.
Но ты не в состоянии это понять.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Легко: VB, VB.Net, Java, C++, C# — близнецы-братья паскалю с объектными расширениями.

То, что они "близнецы" — это серьезное преувеличение. Но в любом случае это не ответ на мой вопрос. Потому, что паскаль сам состоит из заимстований — ничего придуманного Виртом в нем нет. Объектные расширения тоже не Вирт придумал.

V>Другие приводимые языки, типа Лиспа, SmallTalk, Симулы и т.д. настолько из другой оперы, что авторы указанных языков себе явно льстят, когда ссылаются на них.

Ну да, Симула теперь "из другой оперы", хотя это, фактически, Алгол 60 + "мейнстримный" ООП. Под катом пример кода для людей без доступа к википедии:

Скрытый текст

Begin
   Class Glyph;
      Virtual: Procedure print Is Procedure print;;
   Begin
   End;

   Glyph Class Char (c);
      Character c;
   Begin
      Procedure print;
        OutChar(c);
   End;

   Glyph Class Line (elements);
      Ref (Glyph) Array elements;
   Begin
      Procedure print;
      Begin
         Integer i;
         For i:= 1 Step 1 Until UpperBound (elements, 1) Do
            elements (i).print;
         OutImage;
      End;
   End;

   Ref (Glyph) rg;
   Ref (Glyph) Array rgs (1 : 4);

   ! Main program;
   rgs (1):- New Char ('A');
   rgs (2):- New Char ('b');
   rgs (3):- New Char ('b');
   rgs (4):- New Char ('a');
   rg:- New Line (rgs);
   rg.print;
End;

V>Взять те же паттерны из GOF — они ровно для этой группы языков. Ни Лиспу ни SmallTalk эти паттерны и даром не сдались, у тех свои паттерны.

Наверное поэтому в книжке GOF есть примеры на некоем марсианском языке:

createMaze: aFactory 
        | room1 room2 aDoor | 
        room1 := (aFactory make: #room) number: 1. 
        room2 := (aFactory make: #room) number: 2. 
        aDoor := (aFactory make: #door) from: room1 to: room2. 
        room1 atSide: #north put: (aFactory make: #wall). 
        ...

Вот это он и есть — Смолток.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Автор Хаскеля

Который из 256?

V>разразился статьей

Тут, по идее, должна была быть ссылка на статью.

V>о том, что коль нам приходится эмулировать императивность в функциональном языке

Ее там не нужно "эмулировать". Там есть самые настоящие изменяемые ссылки и массивы — без всякой эмуляции.

V>и в этой императивности повторимы в точности все побочные эффекты, то никакого смысла делать так на самом деле нет

На самом деле, конечно, смысл есть. Во-первых, код разделяется на чистый и остальной. Во-вторых, сайд эффекты тоже подразделены на категории. К примеру, сортировка массива на месте это одно, а запись в файл — совсем другое.

V>Вот тебе результаты всех экспериментов — возвращение на круги своя.

Что и куда вернулось?

V>Потому что моделиировать модель над моделью оказалось излишним.

У моделирования модели над моделью тоже своя ниша есть, но не хотите — не моделируйте. никто не заставляет.

V>Ссылочная прозрачность на основе типобезопасности дает точно такой же эффект контроллируемой мутабельности.

А мы о чем сейчас говорили?

V>А что непонятного? Процесс математических вычислений легко ложится на функциональную чистоту, OK, но последующее полезное использование этих вычисленных данных должно сопровождаться побочными эффектами. Например, с целью сохранить результат вычислений. См. выделенное.

Ну так это же и хорошо. Потому, что ФП существует в том числе и для решения проблем с сайд-эффектами.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, WolfHound, Вы писали:

WH>Если бы все было, так как ты говоришь, то там была бы одна базовая операция.
WH>modifyMVar :: MVar a -> (a -> IO (a, b)) -> IO b

Вот это и есть тдодумывание за оппонента. Я просто хотел, чтобы ты самолично об этом сказал, без юлений и намеков. Спасибо, это более деловой подход. Я теперь хоть смогу возразить по-существу.

Я тоже за тебя додумал, есть такое... но я-то оказался прав, считая, что переменую с локом ты обслуживаешь как-то так (C#):

lock(mutext) {
  resource = value;
 // return resource;
}

А всю твою реакцию здесь можно назвать удивлением, что это может быть не так, как ты привык.

Всё проще. Помнишь я тебе говорил когда-то, какой примитив синхронизации является базовым? Предположи, сколько этих базовых примитивов синхронизации обслуживают логику MVar. Почему именно так?

V>>И сейчас нихтферштейн?
WH>Ты точно не понимаешь семантику этого дела.
WH>И почему это крайне сложно привести к разделяемому ресурсу.

Ей-богу, ты натурально запарил своей мантрой "ты точно не понимаешь". Давай прямо здесь и сейчас с ней покончим.

Я могу что-то понимать не так как ты, ес-но. Но постоянно забавным выходит то, что я прекрасно понимаю, что именно понимаешь ты, а вот что понимаю я — для тебя темный лес. Первый абзац этого поста был честен с твоей стороны и хорошо показал, что ты НЕ понимаешь, что имено я понимаю. Не утомил еще? ))) В общем, пока ты действительно не воткнешь мою т.з., обвинять меня в непонимании как минимум преждевременно.

Итак, я уже дал все подсказки. Могу повторить:
1. Что такое разделяемый ресурс? Для чего он вообще нужен.
2. Что такое передача данных м/у потоками через разделяемый ресурс?

Для ответа на этот вопрос можно взять любой самый простой язык программирования (C#, например, чтобы все стороны могли легко верифицировать решение), и я прошу тебя нарисовать п.2 через п.1. Если правильно нарисуешь, увидишь кое-какую важную вещь, которая объясняет вообще всё. И тут же поймешь, что именно понимаю я. И почему, когда речь о разделяемом ресурсе, твое предыдущее представление о переменных с локом НЕ работают. Вернее, работают, ес-но, но очень и очень неэффективно. Кстати, если нарисуешь полноценный п.2. через lock(mutex) {}, то увидишь причину неэффективности.

Кароч, морочить тебе голову, как ты мне, я не буду. Как только ты покажешь свое решения п.2. я либо говорю правильно, либо привожу одно из правильных решений (минимум 2 варианта... правда после приведения к базису на основе того самого примитива синхронизации все варианты схлопываются в один).

Ну а потом как приз могу изобразить аналогичное в lock-free манере, если будет любопытно. (Тут полу-lock-free, точнее, но будет всяко эффективней классическкого варианта)

Здравствуйте, vdimas, Вы писали:

V>Ну тогда предположу специфику — огромное кол-во типов узлов AST.

Не было там никакого огромного количества. Десятка два может. Проблема не в типах узлов, а в том что в CLR уже есть готовая система примитивных типов и полиморфных операций над ними, а в интерпретаторе это все нужно было сочинять самостоятельно. Сейчас с DLR, наверное, будет уже попроще.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

AVK>>Что такое SomeAbstractValue?

V>Это тот самый абстрактный тип, который ты задал по условию.

Я тип — не задавал. Я привел только входные требования к нему.

V> Это либо алгТД

Круто. То есть в качестве примера замены ФлгТД на тру ООП решение ты приводишь код с использованием АлгТД.

V>, либо ОО-интерфейс посещаемой стороны в визиторе

Т.е. таки визитор. Объем писанины в случае АлгТД и визитора сравнивать будем?

V>. По тому факту, какой именно элемент ты наградил абстрактностью, я понял о каком общем виде дизайна идет речь.

Я никакого дизайна не приводил. Я попросил тебя привести дизайн.

V> Внутри в конкретных ветках алоритма, там, где ты ранее создавал значения конкретных типов и упаковывал их в абстрактные типы

Я ничего такого не делал и не писал об этом.

V>Например:
V>

V>// algorithm node 1
V>string s = MakeString(chars, offset, length);
V>listener.process(s);
V>..
V>// algorithm node 2
V>SomeObject o = MakeObject(data);
V>listener.process(o);
V>...
V>

V>class Listener {
V>  public void process(string s);
V>  public void process(SomeObject o);
V>...
V>}
V>

Ну наконец то. Теперь сравни с АлгТД.

V>С учетом этого:
V>

AVK>>Опять ничего не понятно.

V>Даже мало, походу.

Нет, много и не по делу.

V>Я просто понятия не имею с какого уровня подробностей надо что-то объяснять.

Пинцет. Show me your code!!!

V>Заметь, все эти poll-варианты являются вариациями, близкими к визитору по сути происходящего

Хуже то, что они являются его аналогами по объему писанины. И если у тебя хотя бы 5-6 типов значений, то это более менее оправдано, а вот если их 2-3, то это стрельба из пушки по воробьям. При этом АлгТД практически идеальное решение подобных задач.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>>>В современных редакторах это выглядит намного лучше:
C>>Точно. А для Оберона — ниасилили.
V>И не осилят...

V>У них компоненты миниатюрного размера.
Обычно этот размер тождественно равен нулю. Так как код на Обероне не пишут.

Здравствуйте, vdimas, Вы писали:

V>Всё проще. Помнишь я тебе говорил когда-то, какой примитив синхронизации является базовым? Предположи, сколько этих базовых примитивов синхронизации обслуживают логику MVar. Почему именно так?
Его нет.
Также как нет базовой вычислительной модели.
Все выражается друг через друга.

Но что характерно ты так и не предоставил мне решение одной простой задачки.
Короче напиши readMVar или засчитываю слив.
Авторам библиотеки удалось лишь с такой оговоркой.

This function is atomic only if there are no other producers (i.e. threads calling putMVar) for this MVar.

Попробуй понять почему.

Плюс тебе еще задачка сделать await. На данных примитивах будет просто гора кода.
И я даже не уверен, что его можно сделать с одной MVar.

Всю свою демагогию про продолжения ты тоже, что характерно слил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

S>>>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?
V>А как это организованно в виндах, понимаешь? Ну, чтобы я лишнего не писал.
Нет. Можно ссылку на MSDN?

V>Конкретно насчет WebRequest.Send(), артефакты безопасности будут переданы при вызове ниже и где-то будет просто уровень TCP-стека, к которому относятся несколько пунктов из политики и которые (эти пункты) будут проверяться в соотв, вызовах TCP. Т.е. модули, отвечающие за сетевой уровень, должны будут попасть внутрь пояса безопасности.
Что такое "внутрь"? Я правильно понимаю, что для вызова WebRequest.Send() мой прикладной модуль должен будет иметь у себя в "артефактах безопасности" пункты, разрешающие TCP/IP?
Если да — то это, простите, дыра.

V>В общем, какая-то часть системного кода должна быть доверенной всё-равно. Должна быть некая точка опоры, от которой мы отталкиваемся.
Вопрос — какая именно часть кода у вас доверенная. Вот, скажем, драйвер GSM-модема от 3rd-party — он доверенный или нет?

Здравствуйте, vdimas, Вы писали:

V>Э нет, коллега, есть такое дело, как объективная реальность. Если ты убедительно говорил о том, что будет, и при этом позже шли отчеты о поездках на семинары и общение с инсайдерами и ключевыми разработчиками, то изрекаемое тобой воспринималось как информация о продукте, в т.ч. когда речь шла о будущем направлении развития продукта. Подаваемая исключительно в положительном ключе информация о характеристиках продукта является рекламой по-определению, нравится тебе оно или нет. Так вот, упс в том, что всё это подаваемое на самом деле информацией не являлось, а являлось результатом деятельности твоего мыслительного аппарата, то бишь было сугубо твоим ИМХО. Просто ты регулярно забывал и забываешь упоминать эту важную особенность подачи т.н. "информации" в твоих постах. Вот и всё кино.
Коллега, способы действия вашего и моего мыслительного аппаратов я обсуждать здесь не намерен. Я достаточно понятно пишу слово "оффтоп", или оно должно быть капсом?

Здравствуйте, vdimas, Вы писали:

V>Дык это и не полноценная IDE для Оберона. Это просто редактор с раскраской под мильон языков и возможностью настроить запуск внешнего toolchain на сборку или отладку. Поддержка автокомплита у этой среды идет через внешний тул CTags, а там список языков поскромнее (порядка 40-ка языков). Модула-2 и Оберон в него не входит, т.е. для этих языков есть только поддержка раскраски в IDE.
Ну вот и славненько: нет ни того, ни другого. То есть ни гипертекста, ни полноценной IDE.
Это — прямой результат решений, принятых командой разработчиков. Спасибо, что находите подтверждения моим предположениям.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Что такое SomeAbstractValue?
V>>Это тот самый абстрактный тип, который ты задал по условию.

AVK>Я тип — не задавал. Я привел только входные требования к нему.

Ты потребовал его абстрактность, а это нефункциональные требования, то бишь это просто диктуется неким твоим де-факто дизайном операций вокруг AST. Если настаиваешь, чтобы я окружающий дизайн не трогал, то твой вопрос превращается в бессмысленный.

V>> Это либо алгТД
AVK>Круто. То есть в качестве примера замены ФлгТД на тру ООП решение ты приводишь код с использованием АлгТД.

Мне вообще всё равно, на каком механизме run-time полиморфизма ты решил сделать свой абстрактный тип данных. Принципиальной разницы у тебя НЕТ. А у меня есть.

V>>, либо ОО-интерфейс посещаемой стороны в визиторе
AVK>Т.е. таки визитор. Объем писанины в случае АлгТД и визитора сравнивать будем?

Нет, это я перечислил пункты твоего условия. Мне не надо сравнивать визитор и АлгТД, я и так знаю. Давай сравнивать их оба с моим вариантом.

V>>. По тому факту, какой именно элемент ты наградил абстрактностью, я понял о каком общем виде дизайна идет речь.
AVK>Я никакого дизайна не приводил. Я попросил тебя привести дизайн.

OMG.

есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?

Ты мне предложил выбрать один из двух вариантов, оба которых означают, что само значение ты собрался завернуть в абстрактный тип.

Я же тебе показываю как недорого убежать от такого дизайна. Получаемые плюшки:
— эффективнее чем алгТД в рантайм;
— короче в коде, чем визитор + обслуживающий код не надо распылять по всем затронутым визитором классам в иерархии;
— меньше потенциальных багов, т.к. мы всегда работаем в системе конкретных типов, без превращения их в абстрактные и обратно.

V>> Внутри в конкретных ветках алоритма, там, где ты ранее создавал значения конкретных типов и упаковывал их в абстрактные типы
AVK>Я ничего такого не делал и не писал об этом.

Я уже процитировал ключевое в твоем вопросе. Обе предложенные техники подразумевают некий промежуточный абстрактный тип, хранимый в узлах AST. Я же предложил:
— не хранить AST вообще, то бишь организовать т.н. "оперативную" обработку (push). Если вы отказались от интерпретатора на работающем AST, то само AST как промежуточный результат под большим вопросом.
— если таки надо хранить AST, то в нем надо хранить простой thunk (poll=>push) на функторе. И да. с т.з. ООП функтор тоже имеет право на жизнь.

AVK>Ну наконец то. Теперь сравни с АлгТД.

Ес-но АлгТД ничуть не лучше:

// дополнительно придется описать абстрактный тип (псевдокод)
enum class AstNode {
  | TextNode { string Text; }
  | ObjNode { SomeObj Obj; }
}
...

// algorithm node 1
string s = MakeString(chars, offset, length);
astNodes.add(new TextNode(s));
..
// algorithm node 2
SomeObject o = MakeObject(data);
astNodes.add(new ObjectNode(o));
...
class AstProcessor {
  public void process(AstNode node) {
    // псевдокод
    match(node) {
      | TextNode textNode => process(textNode.Text);
      | ObjectNode objNode => process(objNode.Obj);
    }
  }

  public void process(string s);
  public void process(SomeObject o);
...
}

По кол-ву строк не сильно лучше, и еще потеря эффективности на ровном месте. Ну и плюс безобидный до этого код неожиданно стал потенциально баговым, если полноту матча не проверять компилятором.

AVK>Пинцет. Show me your code!!!

Лучше бы ты мне дал свой код и попросил допилить до моего варианта, если тебе не достаточно описания идеи.

V>>Заметь, все эти poll-варианты являются вариациями, близкими к визитору по сути происходящего
AVK>Хуже то, что они являются его аналогами по объему писанины.

Нет, не являются. Не надо всю эту писанину вокруг визитора размазывать по всем файлам и участвующим типам. Кстате, АлгТД тоже этим полезным кач-вом обладает.

AVK>И если у тебя хотя бы 5-6 типов значений, то это более менее оправдано,

Указанный подход вообще всегда оправдан вместо визитора, т.к. позволяет:
1. не описывать абстрактный посещаемый класс;
2. не нужно в наследниках писать visitor.visit(me);
3. зачастую п.2. забывают (потому что это распыление функциональности по классам и файлам), как результат в некоей иерархии классов опять же появляется баг на совершенно ровном месте.

AVK>а вот если их 2-3, то это стрельба из пушки по воробьям.

Та где? Посмотри на мой код в пред. посте внимательней, это ВЕСЬ необходимый код. Остальное будет прикладная логика, одинаковая для всех вариантов. Сравнение с АлгТД я уже привел.

AVK>При этом АлгТД практически идеальное решение подобных задач.

Т.к. ты очень размазано сформулировал критерий идеальности, попробую я. Оно "идеальное" не столько для 2-3-х вариантов типов, оно может быть лучшим решением даже для 20-30 вариантов типов при условии, что сложность обработки каждого варианта умещается в одну-две строчки, т.е. логика не требует оформления в некую единицу языка. То бишь оно идеально там, где в моём матче вместо вызва process(textNode.Text) уместно было бы сразу писать целевой код — тело метода process(string s). Но фактор "однострочности" полезной логики — стремный критерий для принятия решений в дизайне, как по мне, бо имеет обыкновение с течением времени меняться... А уже всё завязано и хрен развяжешь. А в моем варианте, заметь, никакой искуственно введеной дополнительной связанности и прочих зависимостей. О конкретных типах знают только места в алгоритме, которые эти конкретные типы формируют, и обработчик этих конкретных типов. Т.е. от производителя к потребителю значениях всевозможных типов попадают не отсвечивая нигде по пути.

Здравствуйте, vdimas, Вы писали:

AVK>>Я тип — не задавал. Я привел только входные требования к нему.

V>Ты потребовал его абстрактность, а это нефункциональные требования, то бишь это просто диктуется неким твоим де-факто дизайном операций вокруг AST.

Нет такого. Есть вполне конкретная задача — хранить и использовать значение, которое может быть трех видов.

V>Мне вообще всё равно, на каком механизме run-time полиморфизма ты решил сделать свой абстрактный тип данных. Принципиальной разницы у тебя НЕТ. А у меня есть.

Вот вся суть твоих сообщений. Ты нахватался обрывочных знаний, но как дело доходит до конкретики и применения, то начинаются сплошные разводы на воде. Я тебя с Шериданом не просто так сравнил.
Вобщем, в очередной раз заканчиваю общение с тобой из-за физической невозможности вчитываться в десятки килобайт расплывчатого текста в каждом сообщении.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>Ну вот и славненько: нет ни того, ни другого. То есть ни гипертекста, ни полноценной IDE.
S>Это — прямой результат решений, принятых командой разработчиков. Спасибо, что находите подтверждения моим предположениям.

Т.е. мы всё это время таки сравнивали язык и среду исполнения с IDE?
Жесть. )))

Здравствуйте, Klapaucius, Вы писали:

V>>Ссылочная прозрачность на основе типобезопасности дает точно такой же эффект контроллируемой мутабельности.

K>А мы о чем сейчас говорили?

О том, что для этого не нужна никакая специальная монада, а достаточно обычной статической типобезопасности в обычном императивном языке. Без вот этого динамического приведения типов как в популярных средах исполнения.

K>Ну так это же и хорошо. Потому, что ФП существует в том числе и для решения проблем с сайд-эффектами.

И каким образом ФП решает эти проблемы?

Здравствуйте, vdimas, Вы писали:

V>О том, что для этого не нужна никакая специальная монада, а достаточно обычной статической типобезопасности в обычном императивном языке.

1) Монада, действительно не нужна, а точнее не обязательна. Это только один из интерфейсов IO, из коробки есть еще аппликативный функтор (менее мощный) и стрелки (той же мощности). Можно добавлять и другие интерфейсы, если это нужно.
2) В инстансе класса Monad для IO нет ничего специального. Обычный библиотечный код.
3) Ссылочная прозрачность и обеспечивается "обычной статической типобезовасностью". IO — это абстрактный тип, конструктор которого из модуля, где он определен, не экспортируется. Зато экспортируется набор операций, которые позволяют работать с IO безопасным образом. Скомбинировать их (штатным образом) так, чтоб нарушилась ссылочная прозрачность нельзя — в этом и весь фокус. Разумеется, имея лазейку для приведения любых типов к любым можно пробить дыру в абстрактности IO и реализовать опасные операции, нарушающие ссылочную прозрачность.

V>Без вот этого динамического приведения типов как в популярных средах исполнения.

Какое еще динамическое приведение?

V>И каким образом ФП решает эти проблемы?

Предоставлением альтернативных решений, там где они возможны, средствами изоляции и классификации эффектов (на уровне системы типов в том числе), инструментарием декомпозиции общего назначения, который можно и для улучшения императивного кода использовать, помимо прочего.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Kernan, Вы писали:

K>>Сергей Губанов, вы реинкарнировали в vdimas?

V>И да, ты произнес ключевое слово, теперь ты вне игры. Следующий.

V>))

Да я и так вне игры после наблюдения за психоделической веткой "синтаксический оверхед".

Здравствуйте, Klapaucius, Вы писали:

V>>И каким образом ФП решает эти проблемы?

K>Предоставлением альтернативных решений, там где они возможны, средствами изоляции и классификации эффектов (на уровне системы типов в том числе), инструментарием декомпозиции общего назначения, который можно и для улучшения императивного кода использовать, помимо прочего.

А что мешает в императивном языке использовать тот же const?

В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется... Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?

Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?

Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vdimas, Вы писали:

V>>Особую остроту придает тот факт, что перечисленные пункты не новость, а старше того же Оберона многократно, но так и не взлетели. И не взлетят, бо противоречат инкапсуляции ООП/КОП.

AVK>Ужас то какой. Ну расскажи тогда, как в православном ООП 21 века следует разруливать такие ситуации: есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?

Православное ООП 21 века — это Java/C#?

Да, там других вариантов похоже нет.

А вообще это насколько частая/нормальная ситуация? Чтобы значение было настолько разнородным. Лично мне такое, кажется, вообще не встречалось, правда я компиляторы не пишу.

Здравствуйте, AndrewVK, Вы писали:

V>>Ты потребовал его абстрактность, а это нефункциональные требования, то бишь это просто диктуется неким твоим де-факто дизайном операций вокруг AST.
AVK>Нет такого. Есть вполне конкретная задача — хранить и использовать значение, которое может быть трех видов.

Она полностью решена. Но не в том виде, как ты от меня требовал. Тебя это задело.

Я тебе уже сказал что надо делать — дать сюда отрывок кода целиком на любом из твоих вариантов, и я верну его переделанным в мой вариант. Это было так сложно?

V>>Мне вообще всё равно, на каком механизме run-time полиморфизма ты решил сделать свой абстрактный тип данных. Принципиальной разницы у тебя НЕТ. А у меня есть.
AVK>Вот вся суть твоих сообщений.

Суть была ниже и она никуда не делась, то сообщение на месте.

AVK>Ты нахватался обрывочных знаний, но как дело доходит до конкретики и применения, то начинаются сплошные разводы на воде.

Ну попроси кого-нить из коллег объяснить, делов-то... Того же Вольфхаунда. Он хоть и вредный, но соображающий.

AVK>Вобщем, в очередной раз заканчиваю общение с тобой из-за физической невозможности вчитываться в десятки килобайт расплывчатого текста в каждом сообщении.

Ай молодца. Сначала потребовал предоставить код и пояснить о чем речь, но стоило предоставить и то и другое, как решил испариться.

================
Короче, я не удивлен. К чему ты клонил, было понятно сразу. Но я честно предупредил, что вариантов больше 2-х. Так что будем считать, что ты обиделся на то, что твой пример относительно "ООП 21" (С) был неудачным.

Здравствуйте, AndrewVK, Вы писали:

V>>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.

AVK>Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.

Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.

Здравствуйте, AndrewVK, Вы писали:

Поднялся на начало подветки... это жесть!!!

Специально для любителей коротких постов... Тадам!
В первом же коротком посте была упомянута суть приведенного впоследствии решения:

А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных? Зачастую многократно и удобнейи эффективней, чем упаковывать значние конкретного типа в абстрактное и распаковывать затем на паттерн-матчинге или визиторе.

Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация". На плюсах таким же точно трюком для избавления от визитора пользуюсь уже давно. Оч удобно, всем рекомендую.

====================
Ну и характерно, что ты процитированное предложение сразу скипнул при ответе. И затем всячески делал вид, что такого способа не существует, пытаясь перевести обсуждение в сравнение исключительно алгТД vs визитор. Несерезно.

Здравствуйте, vdimas, Вы писали:

V>Ну попроси кого-нить из коллег объяснить, делов-то... Того же Вольфхаунда. Он хоть и вредный, но соображающий.

Он то как раз понимает, что в мейнстриме адекватной замены АлгТД+ПМ нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexRK, Вы писали:

ARK>Православное ООП 21 века — это Java/C#?

Это ты vdimas спроси. Он тут нам рассказывает, что АлгТД с ООП несовместимы.

ARK>А вообще это насколько частая/нормальная ситуация?

В некоторых задачах — очень частая. Мои пример — из DSL для импорта данных. Там значение полей может быть указано так:

<where v:Code="SomeCode"> <!-- Просто строка в атрибуте -->
  <v:Quantity>25.5</v:Quantity> <!-- А здесь надо ее к decimal преобразовать -->
  <v:Ref>SomeClass.RefID</v:Ref> <!-- Здесь ссылка, которую надо отресолвить и достать по ней данные -->
  <v:Ref2>USD</v:Ref2> <!-- А здесь ссылка по значению, значение которой получается запросом к тому, на что ссылаются со сравнением уникального поля, которое, собственно, и указано в теле тега -->
  <v:Description file="Description1.txt"/> <!-- Здесь значение хранится в другом файле. При этом загружать файл в память весь нельзя, нужно перелить через буфер фиксированного размера в другой поток. -->
</where>

Вот все эти значения должны обрабатываться по единым правилам до тех пор, пока непосредственно не нужно будет что то читать в БД или загружать туда. А вот когда понадобится, то надо выполнить операцию формирования запроса уникальным для каждого типа значения способом.
Так вот, АлгТД позволяют решать такие задачи практически идеальным способом, ничуть не выбиваясь из ООП (и в F# и в Немерле они все равно сводятся к обычным классам с дискриминантами). И я бы еще понял, если бы речь зашла о том, что, в принципе, задачи, решаемые ими, можно решить статически, без участия рантайм полиморфизма, но при чем тут инкапсуляция — мне вообще непонятно, так как АлгТД выставляют наружу вполне себе классический контракт из набора свойств и дискриминанта, никак не афишируя внутреннюю структуру хранения и реализации.

ARK>Лично мне такое, кажется, вообще не встречалось, правда я компиляторы не пишу.

Тут такое дело — если ты не знаешь что это и для чего, то ты можешь просто не видеть те места, где они дают существенный выигрышь. К примеру, даже сейчас товарищи некоторые считают, что все нововведения C# 3 бесполезны и им некуда их применить.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация".

Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется.

V>Ну и характерно, что ты процитированное предложение сразу скипнул при ответе.

Открою тебе страшную тайну — я твои простыни целиком не читаю, мне времени жалко.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexRK, Вы писали:

ARK>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.

Не понял. Напиши псевдокод.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

V>>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация".
AVK>Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется.
У него просто идея фикс вместо парсер -> AST -> работа с АСТ совмещать парсер с работой в одной куче кода. Про то, что это не только говнокод, но еще и не всегда возможно он слушать не хочет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Вот все эти значения должны обрабатываться по единым правилам до тех пор, пока непосредственно не нужно будет что то читать в БД или загружать туда. А вот когда понадобится, то надо выполнить операцию формирования запроса уникальным для каждого типа значения способом.

А иерархия классов тут не более предпочтительное решение?

AVK>Так вот, АлгТД позволяют решать такие задачи практически идеальным способом, ничуть не выбиваясь из ООП (и в F# и в Немерле они все равно сводятся к обычным классам с дискриминантами). И я бы еще понял, если бы речь зашла о том, что, в принципе, задачи, решаемые ими, можно решить статически, без участия рантайм полиморфизма, но при чем тут инкапсуляция — мне вообще непонятно, так как АлгТД выставляют наружу вполне себе классический контракт из набора свойств и дискриминанта, никак не афишируя внутреннюю структуру хранения и реализации.

Вероятно, инкапсуляция при том, что дает возможность сделать псевдо-АТД. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами. Таким образом, сделать некорректный АТД не выйдет. Хотя может быть имелось в виду что-то иное.

AVK>Тут такое дело — если ты не знаешь что это и для чего, то ты можешь просто не видеть те места, где они дают существенный выигрышь. К примеру, даже сейчас товарищи некоторые считают, что все нововведения C# 3 бесполезны и им некуда их применить.

Да, тут согласен.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexRK, Вы писали:

ARK>>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.

AVK>Не понял. Напиши псевдокод.

  class Consumer
  {
    public void Consume(Foo foo) { ... }
  }

  static class Utils
  {
    public static Foo StreamToFoo(Stream stream) { ... }

    public static Foo StringToFoo(Stream stream) { ... }
  }

Что-то в этом роде.

Хотя если надо наше значение везде "таскать" по коду (правда зачем?), а конвертить в последний момент — такой вариант не подойдет.

Здравствуйте, AlexRK, Вы писали:

ARK>>>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.
AVK>>Не понял. Напиши псевдокод.

ARK>

ARK>  class Consumer
ARK>  {
ARK>    public void Consume(Foo foo) { ... }
ARK>  }

ARK>  static class Utils
ARK>  {
ARK>    public static Foo StreamToFoo(Stream stream) { ... }

ARK>    public static Foo StringToFoo(Stream stream) { ... }
ARK>  }
ARK>

ARK>Что-то в этом роде.

Это некорректный код и я мысли все равно не понял.

ARK>Хотя если надо наше значение везде "таскать" по коду (правда зачем?)

Затем, что они сперва обрабатываются по общим правилам. К примеру, исходный код иерархический, а интерпретатору скармливаются плоские данные, последовательный набор операций, в которых все иерархии свернуты определенным образом. И используются такие значения далеко не в одном месте.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexRK, Вы писали:

ARK>А иерархия классов тут не более предпочтительное решение?

А что с ней делать? Виртуальный метод — не вариант, потому что алгоритмов, использующих эти данные не один, и эти алгоритмы не требуют логической связи от AST к ним. Визитор? Или еще какой вариант?

ARK>Вероятно, инкапсуляция при том, что дает возможность сделать псевдо-АТД

Непонятно.

ARK>. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами.

Это и есть АлгТД. Только без поддержки языка (не фатально) и без контроля гарантированного учета всех возможных вариантов, который обеспечивает ПМ или правильно реализованный визитор (а вот это уже фатально).

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Это некорректный код и я мысли все равно не понял.

Я ошибся, во втором статическом методе надо вместо "Stream stream" поставить "String str".

Мысль такая, что в этом "алгебраическом типе" три значения не являются полностью гетерогенными, а по сути — одним и тем же в разных представлениях. Плюс основная операция обработки одна. Поэтому я предложил превратить сразу потоки и строки в объект и дальше везде работать с ним.

ARK>>Хотя если надо наше значение везде "таскать" по коду (правда зачем?)

AVK>Затем, что они сперва обрабатываются по общим правилам. К примеру, исходный код иерархический, а интерпретатору скармливаются плоские данные, последовательный набор операций, в которых все иерархии свернуты определенным образом. И используются такие значения далеко не в одном месте.

Если значение "в трех ипостасях" будет использоваться не в одном месте, то в этих нескольких местах перед использованием будет преобразование из Stream или String в объект? Или каким образом этот АлгТД еще будет использоваться? Или я чего-то не понял.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexRK, Вы писали:

ARK>>А иерархия классов тут не более предпочтительное решение?

AVK>А что с ней делать? Виртуальный метод — не вариант, потому что алгоритмов, использующих эти данные не один, и эти алгоритмы не требуют логической связи от AST к ним. Визитор? Или еще какой вариант?

Я имел в виду именно виртуальный метод "операция формирования запроса". Если алгоритмов несколько — выносим их в общий интерфейс. Или по каким-то причинам обработка должна обязательно быть где-то извне?

ARK>>. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами.

AVK>Это и есть АлгТД. Только без поддержки языка (не фатально) и без контроля гарантированного учета всех возможных вариантов, который обеспечивает ПМ или правильно реализованный визитор (а вот это уже фатально).

+1. Да, все верно. Для реализации этого всего необходима инкапсуляция. Такое вот у меня возникло (возможно очевидное и примитивное) предположение на вопрос "причем тут инкапсуляция".

Здравствуйте, WolfHound, Вы писали:

V>>>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация".
AVK>>Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется.
WH>У него просто идея фикс вместо парсер -> AST -> работа с АСТ совмещать парсер с работой в одной куче кода.

Конкретно для AWK были даны два варианта, для оперативной обработки и привычной ему поэтапной. http://www.rsdn.ru/forum/philosophy/4829347.1.aspx

WH>Про то, что это не только говнокод,

Это от радиуса кривизны рук зависит.

WH>но еще и не всегда возможно он слушать не хочет.

Для танкистов: для тех случаев, где невозможно сразу, тоже был дан вариант.

Здравствуйте, AndrewVK, Вы писали:

V>>Ну попроси кого-нить из коллег объяснить, делов-то... Того же Вольфхаунда. Он хоть и вредный, но соображающий.

AVK>Он то как раз понимает, что в мейнстриме адекватной замены АлгТД+ПМ нет.

Речь не о том, что он понимает прямо сейчас, а том, что он почитает и поймет про CPS-трансформацию, затем покажет, каким именно образом исчезает АлгТД при CPS-трансформации.

Здравствуйте, AlexRK, Вы писали:

ARK>Я ошибся, во втором статическом методе надо вместо "Stream stream" поставить "String str".

Тогда непонятно самое интересное, как выбирается нужный метод при вызове.

ARK> Плюс основная операция обработки одна. Поэтому я предложил превратить сразу потоки и строки в объект и дальше везде работать с ним.

Что значит превратить потоки и строки в объект? Каким образом?

ARK>Если значение "в трех ипостасях" будет использоваться не в одном месте, то в этих нескольких местах перед использованием будет преобразование из Stream или String в объект?

Нет. Будет ответный алгоритм, зависящий от типа значения. Т.е. нужна все та же динамическая диспетчеризация. И вот как ее обеспечивать в ситуации, когда список значений дискриминанта фиксирован на стадии компиляции, как раз и есть самое интересное. АлгТД интересны не сами по себе, а в комплекте с ПМ.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>Речь не о том, что он понимает прямо сейчас, а том, что он почитает и поймет про CPS-трансформацию, затем покажет, каким именно образом исчезает АлгТД при CPS-трансформации.

Если ты про замену виртуальных методов на ФВП, то это не CPS-трансформация, это просто замена ООПного полиморфизма на функциональный. Мы же вроде как про ООП тут беседуем.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexRK, Вы писали:

ARK>Я имел в виду именно виртуальный метод "операция формирования запроса".

Не годится. Вызывающе чрезмерная связность. На каждого консьюмера в AST методов не надобавляешься.

ARK> Если алгоритмов несколько — выносим их в общий интерфейс.

Ага. Т.е. в итоге получаем классический визитор. Браво! В чем проблема такого подхода пояснять?

ARK>+1. Да, все верно. Для реализации этого всего необходима инкапсуляция. Такое вот у меня возникло (возможно очевидное и примитивное) предположение на вопрос "причем тут инкапсуляция".

Не, vdimas утверждает, что АлгТД нарушает компиляцию. В этом, собственно, и был единственный вопрос всей ветки с моим участием.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Что значит превратить потоки и строки в объект? Каким образом?
AVK>Нет. Будет ответный алгоритм, зависящий от типа значения. Т.е. нужна все та же динамическая диспетчеризация. И вот как ее обеспечивать в ситуации, когда список значений дискриминанта фиксирован на стадии компиляции, как раз и есть самое интересное. АлгТД интересны не сами по себе, а в комплекте с ПМ.

Понятно. Я неверно истолковал ваше высказывание "Строка парсится, стрим выкачивается в память, объект используется как есть" как означающее, что строка и стрим соответствующими алгоритмами приводятся к объекту, который используется, как есть. Получается, что все эти значения потребляются совершенно разными алгоритмами. Поэтому мое изначальное предположение о ненужности АТД неверно.

Здравствуйте, vdimas, Вы писали:

V>Просто в Хаскеле нет продложений. Ниасилили.

В Хаскеле нет continuation monad? Жжешь.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexRK, Вы писали:

ARK>Получается, что все эти значения потребляются совершенно разными алгоритмами.

Не совсем так. Алгоритм один, но отличающийся немного для значений разных типов. Т.е. в каком то месте нужно сделать ветвление по дискриминанту, а потом продолжить дальше обобщенную обработку.

... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>

> Вот вся суть твоих сообщений. Ты нахватался обрывочных знаний, но как дело доходит до конкретики и применения, то начинаются сплошные разводы на воде. Я тебя с Шериданом не просто так сравнил.

Всегда возникают трудности, когда нужно перейти от обсуждения коня в вакууме к конкретному коню. Конкретных много разных, какого выбрать? Задача была поставлена несколько размыто. Так же можно было бы уточнить стоимость приведения типов, стоимость выполнения операций, сценарии. Может быть действительно тут вариант с предварительным или ленивым приведением типов подошел бы. Ан нет, все нечетко, но код вынь да полож, а мы будем посмеяться зная то что не знает другая сторона.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:
V>Т.е. мы всё это время таки сравнивали язык и среду исполнения с IDE?
V>Жесть. )))

Ну, я не знаю, что и с чем сравнивали вы. Это же ваш был аргумент :
Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).
Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.

А потом в результате разговора внезапно оказалось, что раскраски синтаксиса там нету потому, что

Операция SetTextColor над GDI довольно дорогая, внутри инициализируются специальные Pen и Brush для глифов шрифта. Причем (если помнишь) исходный цвет округляется по тем временам до ближайшего цвета из палитры. А палитры тогда были практически всегда индексные, то бишь "округление" цвета на самом деле шло через линейный перебор всех вхождений в палитру и подбор наиболее близкого цвета. А операция нахождения абсоютной цветовой разницы для каждого вхождения из палитры — тоже дорогая. И т.д. и т.п. В общем, я много возился с GDI/MFC даже уже на пнях, так вот, до появления 200MHz компов вывод на экран вылизывался как ничто другое.

Ну разве это не здорово? То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало. Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.

Здравствуйте, AndrewVK, Вы писали:

AVK>Если ты про замену виртуальных методов на ФВП, то это не CPS-трансформация,

1. Это CPS-трансформация прямо по определению.
2. Идентично заменяются оба варианта, что на визиторе, что на АлгТД, то бишь конкретно виртуальные методы не при чем.
3. Фокус не на самой CPS-трансформации, а в пост-эффекте. Конкретно здесь не надо будет вводить дополнительный абстрактный тип для представления узла AST, т.к. теперь в узле хранится замыкание, контекст которого унутре оперирует конкретным типом.

AVK>это просто замена ООПного полиморфизма на функциональный.

Так же как замена функционального полиморфизма на основе АлгТД на функциональный же полиморфизм на основе функционального типа (который тоже всегда абстрактный). Т.е. вся разница в том, что пользовательский тип надо объявлять и обслуживать, а абстрактные функциональные типы даны изкаробки. (Камешек в сторону связанности)

Помнишь за что пеняют делегаты в дотнете? Что они нифига не являются абстрактными функциональными типамм, в отличие от функциональных типов ФП-языков. Поэтому-то были введены все эти Func<>, Action<> и т.д., чтобы как то организовать некое обобщение сигнатур функциональных типов, которое присутствовало бы в случае их абстрактности изкаробки

AVK>Мы же вроде как про ООП тут беседуем.

Дык, boost::lambda, которые я использую для точно такого же в С++, называются как функциональщина, выглядят как функциональщина, а откроешь — унутрях сплошное ООП. Аналогично анонимные делегаты в дотнете.

ИМХО, это банально удобно, когда в языке есть возможность заменять интерфейсы с одним методом на парадигму "функтор". В С++ особенно хорошо видно, что это всё-таки обычный объект, т.к., в отличие от донета, он требует такого же внимания как и другие объекты, из-за особенностей размещения (стек/куча) и контроля времени его жизни.

Здравствуйте, AndrewVK, Вы писали:

AVK>Это ты vdimas спроси. Он тут нам рассказывает, что АлгТД с ООП несовместимы.

Я еще ничего не рассказывал. Тебе вообще рассказывать смысла нет, ты сам пишешь посты в 3 строчки и у других далее 3-х строк не читаешь... Превратили, блин, форум в бесконечный IRC чат.

И не надо меня перевирать, я сказал (дословно) что оно не взлетело и не взлетит в ближайшее время. И подразумевалось (см исходный пост) два утверждения, а не одно:
1. В мейнстриме в ближайшие много лет будет таки ООП.
2. Зависимые типы, АлгТД и т.д. (смотри приведенный оппонентом список) в мейстриме в ближайшие годы тоже не взлетят.

Конкретно почему не взлетит АлгТД и паттерн-матчинг в ООП-мейнстриме? Потому что паттерн матчинг умеет намного больше, чем ты хотел добиться от меня в примере. Стоит открыть этот "ящик Пандоры" и оттуда полезет... полезут всякие св-ва и флаги, искуственные сигнатуры конструкторов и т.д. и т.п. — все это полезет в публичные интерфейсы только ради попользовать их в конструкции паттерн-матчинга. И дизайн будет тяготеть всё больше и больше к хаскелевскому типу, когда все кишки объектов наружу. Вот почему моё ИМХО вспомнило об инкапсуляции.

Еще момент. Посмотри на АлгТД в Немерле. Это инвалид, а не АлгТД. Потому что у него ограничение на реализацию в виде ref-типов. А такая техника реализации — это тормоза на ровном месте для самых популярных сценариев, хотя бы возьми Nullable. Стал бы производитель CLR всерьез думать о том, чтобы Nullable делать ref-типом? Да не в жисть... Модные разговоры о модном ФП на форумах это одно, а св-ва платформы — малость другое, нужен трезвый подход.

Далее. Представим возможность реализации АлгТД в виде value-типов. Такую реализацию можно посмотреть прямо сейчас, скормив IIOP.Net описание какого-нить размеченного объединения в CORBA IDL. Будет хорошо видно что там, где фП-языки используют типобезопасность и нивелируют лишние проверки в паттерн-матчинге, там безопасный (с т.з. ООП) интерфейс размеченного объединения должен будет при каждом доступе к вариантам проверять дискриминатор, даже если мы уже находимся в правильной ветке паттерн-матчинга. Т.е. опять получилась профанация и тормоза. Ну и до кучи сюда стоит помнить о совместимости разных языков на CLR.

Ес-но можно будет сделать полноценные АлгТД прямо в дотнете в каком-нить функциональном языке, но эффективно это будет только на неинкапсулированном представлении, открытом как internal внутри модуля. То бишь вопрос интероперабельности с остальными языками под вопросом. И даже вопрос интероперабельности языка с самим собой при попытке сделать модульнуй, как принято в CLR, его дизайн.

AVK>В некоторых задачах — очень частая. Мои пример — из DSL для импорта данных.

Для твоей задачи никакой паттерн-матчинг не нужен, достаточно некоего синтаксического сахарка, о котором уже давно говорят, что-то типа такого:

switch(node.GetType()) {
  case typeof(TextNode): ...
  case typeof(ObjectNode): ...
}

Здравствуйте, AndrewVK, Вы писали:

V>>Просто в Хаскеле нет продложений. Ниасилили.
AVK>В Хаскеле нет continuation monad? Жжешь.

В исходной семантике — call/cc, вызываемой из произвольного места в коде? Нет, конечно.

Это малость не то, что настоящие продолжения. Вместо текущего контекста вычисления захватывается только явно поданные вычисления/монады.

В исходной семантике можно сделать полный форк текущего контекста вычислений внутри любых сколь угодно вложенных вызовов... и в каждом контексте будет свой, грубо говоря, return, корректно выполняющийся по своей копии стека вычислений. Поэтому речь и идет о том, что при нейтивном исполнение (не на интерпретаторе) полноценные продолжения требуют форкать так же состояние нейтивного стека.

Здравствуйте, Sinclair, Вы писали:

S>Ну разве это не здорово?

Нет, терять контекст всегда нездорово.

S>То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало.

Дык, ты опять путаешь Оберон и некий BlackBox. Причем, нимало не смущаясь, покритиковав в одном предложении BlackBox, даже не закончив еще этого предложения, тут же делаешь выводы насчет Оберона как такового. Жаль, что я не могу здесь написать, что я думаю о такой мммм... "манере" ведения беседы.

От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.

S>Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.

Это не противоречие, а результат твоей искуственной мешанины Оберона как такового и BlackBox-а в частности. И даже в пределах одной подветки, прикинь, могут упоминаться сразу несколько вещей.

Здравствуйте, vdimas, Вы писали:

S>>То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало.
V>Дык, ты опять путаешь Оберон и некий BlackBox.
Ну, распутайте. В чём тут секрет?

V>От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.
Ок, мы вернулись к тому, с чего начали.
Гипертекстовость как способ раскраски кода — сосёт.
Семантическая раскраска — рулит.
Отсутствие необходимости семантической раскраски паскалеподобных языков, я надеюсь, мы развеяли к этому моменту? Или вы опять начнёте юлить и уводить разговор в сторону?

Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:
1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
2. Джава с его javadoc
3. С# c его XML Documentation Comments.
В третьем случае документация официально становится частью языка. Это пример того, как надо дизайнить язык. И пример того, как язык влияет на возможности IDE.

S>>Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.
V>Это не противоречие, а результат твоей искуственной мешанины Оберона как такового и BlackBox-а в частности.
Ну, давайте уберём мешанину.

Здравствуйте, vdimas, Вы писали:

V>А что мешает в императивном языке использовать тот же const?

V>В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется...
модификатор const в языке C++ — фикция.
Он не даёт нам никаких гарантий, т.к. всегда можно привести int к const int. То, что я не могу изменить этот инт, не означает, что никто не может.

Здравствуйте, Sinclair, Вы писали:

V>>От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.
S>Ок, мы вернулись к тому, с чего начали.
S>Гипертекстовость как способ раскраски кода — сосёт.
S>Семантическая раскраска — рулит.

S>Отсутствие необходимости семантической раскраски паскалеподобных языков, я надеюсь, мы развеяли к этому моменту?

Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.

S>Или вы опять начнёте юлить и уводить разговор в сторону?

Мне-то ачем юлить? Я лишь отвергаю попытки приписать мне лишнее. Твоё мнение, насчет необходимости раскраски я услышал. Но не считаю, что из этого следует, что сама среда Оберон г-но из-за того, что в некоей BlackBox недостаточно покрасили текст. Я тебе уже раз 10 напоминал о некоректности такой "лоики". ИМХО, это ты пытаешься перевести разговор каждый раз, когда заслуживаешь подобные замечания.

S>Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:
S>1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
S>2. Джава с его javadoc

Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.

S>3. С# c его XML Documentation Comments.
S>В третьем случае документация официально становится частью языка.

Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.

S>Это пример того, как надо дизайнить язык. И пример того, как язык влияет на возможности IDE.

В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону. Пример Doxygen/С++ показывает это во всей красе.

Здравствуйте, vdimas, Вы писали:

V>Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.
С неаргументированным ИМХО — запросто. Ваши аргументы про ненужность сводились к намёкам на семантическую однозначность Оберона по сравнению с "другими языками". Оказалось, что
а) в Обероне полно конструкций, в которых семантику из чистого синтаксиса извлечь затруднительно
б) в остальных Паскалеподобных языках раскраска синтаксиса применяется примерно с 1990 года.

S>>Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:
S>>1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
S>>2. Джава с его javadoc

V>Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.
С точки зрения языка, это решение эквивалентно Джавовскому.

V>Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.
Я бы не сказал, что этого мало. Генерилки заботятся об оформлении. Это как раз правильное разделение обязанностей — программист описывает семантику, а стили и представление предоставляет внешний тул. Нет никакой ручной раскраски.

V>В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону.
Я бы не сказал про все языки. К некоторым языкам (в т.ч. фортрану и С++) прикрутили внешние инструменты типа doxygen. В некоторых (Java, C#, VB.Net) есть общепринятые стандарты, заданные разработчиками. Для некоторых — ничего нет.
И только Обероновцы придумали бред с гипертекстом.

V>Пример Doxygen/С++ показывает это во всей красе.
Пример Doxygen показывает, что
1. Для документации в языке гипертекст нафиг не упал
2. Пример Java вдохновил команду QT на разработку своего аналога. Пример Оберона не смог никого вдохновить.

Здравствуйте, Sinclair, Вы писали:

V>>Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.
S>С неаргументированным ИМХО — запросто.

Гм, ну ок, ниже приведу попунктно, почему так.

S>Ваши аргументы про ненужность сводились к намёкам на семантическую однозначность Оберона по сравнению с "другими языками". Оказалось, что
S>а) в Обероне полно конструкций, в которых семантику из чистого синтаксиса извлечь затруднительно

Возможно... Но справедливости ради, пример с WITH — это спекуляции чистой воды. Случай 2-х вложенных WITH ничем не отличается по-сути от случая когда один WITH в методе объекта. И там и там 2 уровня вложенности контекстов объектов. Но для второго случая ты предлагаешь красить мемберы объекта разными цветами, а что же делать в случае 2-х вложенных WITH? Или еще пример, в этих языках есть возможность определять локальные процедуры, которые могут оперировать контекстом вышестоящей процедуры. Как там различать самые локальные переменные от несамых локальных? )))

По опыту С++, мне комфортно, когда выделены цветом:
— ключевые слова
— макроопределения
— enum
— типы
— ф-ии/методы
— строки.

Т.е. даже всего того, что было предложено еще оппонентами для раскраски, типа локальных/нелокальных переменных, статических/нестатических методов и т.п. мне не надо, потому что: засоряет вид, локальность/мемберность переменных разруливается в обязательном порядке через name conventions, а вызов статического мембера с вызовом экземплярного в С++ перепутать сложно.

А теперь берем паскалеподобные языки:
— макроопределений нет
— enum нет
— в языке сложно спутать идентификаторы типов с идентификаторами процедур.

Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
Теперь аргументировано?

S>б) в остальных Паскалеподобных языках раскраска синтаксиса применяется примерно с 1990 года.

Исходный Оберон — разработка 80-х, начала 90-х годов.

V>>Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.
S>С точки зрения языка, это решение эквивалентно Джавовскому.

Ну вот оно и откровенное юление. Ты же прекрасно понял о чем я, разве нет? С точки зрения стандарта языка Doxygen не существует. Только это и принципиально. Вместо того, чтобы прибивать гвоздями на заседаниях комитета всякую хрень к языку, этот момент был отдан на откуп третьесторонним разработчикам. Было очень много вариантов генерации доки для С++ во все времена (я за 20 лет их видел десятки), но вот устаканился Doxygen и буквально единицы коммерческих, которые мало кто пользует.

Но ты посмотри, колгда это всё устаканилось — уже в 2000-х годах.

V>>Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.
S>Я бы не сказал, что этого мало. Генерилки заботятся об оформлении. Это как раз правильное разделение обязанностей — программист описывает семантику, а стили и представление предоставляет внешний тул. Нет никакой ручной раскраски.

Я не о раскрасках, а о тагах в дотнетном XML-doc. Третьестороннии генерилки расширяют исходный набор тагов чуть ли не вдвое. Вот тебе кривизна попыток устаканить этот набор через стандарт во всей красе. Достаточно было дать референсный независимый тул, как поступили в Java.

V>>В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону.
S>Я бы не сказал про все языки. К некоторым языкам (в т.ч. фортрану и С++) прикрутили внешние инструменты типа doxygen. В некоторых (Java, C#, VB.Net) есть общепринятые стандарты, заданные разработчиками. Для некоторых — ничего нет.

Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок. В общем, предлагаю этот момент "убогости Оберона" тоже считать закрытым... Уж очень с натяжкой выходит...

S>И только Обероновцы придумали бред с гипертекстом.

А мне гипертекстовые ссылки прямо из кода нравятся.

По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.

V>>Пример Doxygen/С++ показывает это во всей красе.
S>Пример Doxygen показывает, что
S>1. Для документации в языке гипертекст нафиг не упал
S>2. Пример Java вдохновил команду QT на разработку своего аналога. Пример Оберона не смог никого вдохновить.

Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.

Здравствуйте, Sinclair, Вы писали:
V>>В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется...
S>модификатор const в языке C++ — фикция.
S>Он не даёт нам никаких гарантий, т.к. всегда можно привести int к const int.

Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.

S>То, что я не могу изменить этот инт, не означает, что никто не может.

Дык, твой аргумнет известный, я же его и привел:

Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?

Именно этот момент меня в С++ и раздражает, бо реально const_cast и приведение в стиле С для того же самого — это косяк в дизайне, спокойно лечится выпрямлением кода. Т.е. запросто можно убрать эти конструкции из языка и он ни капли не пострадает.

И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.

Тогда останется всего один момент в плане типобезопасности, требующий решения — это нулевые ссылки (указатели). В функциональных языках безопасность этого момента решается через некий АлгТД навроде Maybe и обязательно ветвление по нему на ПМ. Для императивных языков требуется придумать нечто аналогичное, встроенное в семантику языка.

Здравствуйте, vdimas, Вы писали:

V>По опыту С++, мне комфортно, когда выделены цветом:
V>- ключевые слова
V>- макроопределения
V>- enum
V>- типы
V>- ф-ии/методы
V>- строки.

V>Т.е. даже всего того, что было предложено еще оппонентами для раскраски, типа локальных/нелокальных переменных, статических/нестатических методов и т.п. мне не надо, потому что: засоряет вид, локальность/мемберность переменных разруливается в обязательном порядке через name conventions, а вызов статического мембера с вызовом экземплярного в С++ перепутать сложно.
Я, простите, не буду доверять вашему опыту в том, чего вам "не надо", пока вы не поработаете в среде, где всё это есть. Человек, так уж он устроен, быстро привыкает к хорошему.
В Турбопаскале 5 не было вообще никакой раскраски. В 6.0 добавили двухцветную раскраску уровня "ключевые слова vs всё остальное". В 7.0 сделали полноценную раскраску практически всего синтаксиса. Это мы говорим о промежутке буквально в несколько лет.
И, да, заметим — у ТурбоПаскаля и Борланд Паскаля была масса фанатов. Его делали Хейльсберг и Канн — парни, которые знают, чего требовать от компилятора и IDE.
А ваши тщания разрулить неопределённости синтаксиса через naming conventions и code style помогут ой как не везде. Раскраска синтаксиса помогает читать код, и её преимущество — в том, что она помогает читать любой код. А не только написанный по тем гайдлайнам, которые установили для себя лично вы.

V>А теперь берем паскалеподобные языки:
V>- макроопределений нет
V>- enum нет
Как это? Куда дели enum?
RTFM:
http://www.modula2.org/reference/enumerations.php
http://www.delphibasics.co.uk/Article.asp?Name=Sets
То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.
V>- в языке сложно спутать идентификаторы типов с идентификаторами процедур.

V>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
V>Теперь аргументировано?
Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".
V>Исходный Оберон — разработка 80-х, начала 90-х годов.
Ну, так в исходном Паскале тоже ничего не было. Однако в 80х, начале 90х для него таки сделали IDE.

V>Ну вот оно и откровенное юление. Ты же прекрасно понял о чем я, разве нет? С точки зрения стандарта языка Doxygen не существует.
Как и javadoc.

V>Только это и принципиально. Вместо того, чтобы прибивать гвоздями на заседаниях комитета всякую хрень к языку, этот момент был отдан на откуп третьесторонним разработчикам. Было очень много вариантов генерации доки для С++ во все времена (я за 20 лет их видел десятки), но вот устаканился Doxygen и буквально единицы коммерческих, которые мало кто пользует.
А вот Java и C# стандартизовали один стандарт. Благодаря этому, разработчикам не надо метаться в выборе движка.

V>Но ты посмотри, колгда это всё устаканилось — уже в 2000-х годах.
Конечно. А если бы формат комментов включили в ранние стандарты, или хотя бы в референс реализацию, то устаканилось бы это уже в 90х.

V>Я не о раскрасках, а о тагах в дотнетном XML-doc. Третьестороннии генерилки расширяют исходный набор тагов чуть ли не вдвое. Вот тебе кривизна попыток устаканить этот набор через стандарт во всей красе. Достаточно было дать референсный независимый тул, как поступили в Java.
Откуда кривизна? Стандарт намеренно сделан расширяемым. Показать место, где это обеспечено, или сами найдёте?
При этом основные семантические теги приняты без разногласий. А оформительские особенности (все эти <threadsafety>, <note>, etc.) — up to 3rd party.

V>Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок.
Конечно же есть. Разница — ровно такая же, как между поддержкой строк в языке и "возможностью наплодить свои классы строк". Стандарт даёт возможность разработчикам пользоваться языком и интероперировать, а в бесстандартных языках типа С++ имеется зоопарк плохо совместимых между собой "платформ" — Qt, MFC, и так далее.

В общем, предлагаю этот момент "убогости Оберона" тоже считать закрытым... Уж очень с натяжкой выходит...
Да без проблем.

V>А мне гипертекстовые ссылки прямо из кода нравятся.

Гипертекстовые ссылки из кода бывают двух типов:
1. В коде, Go to definition — поддерживаются вменяемыми IDE безо всякой ручной раскраски. В Delphi — Ctrl+Click, в VS, емнип, клавиатурная комбинация.
2. Произвольные, из комментариев — поддерживаются вменяемыми IDE безо всякой ручной раскраски.

V>По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.
Оберон бы вас точно так же не спас. Если авторы доки не воспользовались средствами, встроенными в PDF (вы же знали, что в нём прекрасно работают ссылки — ещё с тех времён, когда Adobe хотела заменить им HTML для вёрстки в вебе?), то средствами, встроенными в Оберон они бы тоже пренебрегли.

V>Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.
Это они в контексте гипертекстовых исходников ссылаются, или вы опять пытаетесь контекст подменить?

Здравствуйте, vdimas, Вы писали:

V>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.
Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.
RTFM-мьте до просветления.

S>>То, что я не могу изменить этот инт, не означает, что никто не может.

V>Дык, твой аргумнет известный, я же его и привел:
V>

V>Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?

Нет, вы привели совершенно другой аргумент. Это аргумент про то, что функция, в которую уехала ссылка на константу (callee), может её взломать через const_cast, обманув ожидания caller-а.
А я говорю про то, что даже убрав из языка C-style cast и const_cast, мы оставляем возможность caller-у обмануть ожидания callee по константности переданной ссылки. Если callee хочет работать с переданным ему по ссылке значением, он обязан сделать копию руками. Если вам это непонятно, то дизайном языков заниматься пока рано — спрашивайте, будем разьяснять.

V>И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.
Я не знаю семантики "предложенного модификатора clean".

Здравствуйте, Sinclair, Вы писали:

V>>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.
S>Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.

Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит. Когда речь идет о гарантиях, то нас интересует ровно обратный сценарий, когда мы вводим модификатор const для некоей ссылки/указателя, и эта гарантия полностью соблюдается. Только при соблюдении гарантий речь может идти о ссылочной прозрачности, даже если мы эту ссылку в процессе вычислений куда-то передаём (я думал и так понятно, где находится тот самый момент нарушения ссылочной прозрачности в императивных языках). Болезнь современного С++ в том, что через эти гарантии легко перешагнуть прямо ср-вами языка. Лично меня это раздражает, бо эти перешагивания мне не нужны (да и другим тоже). Но безопасность кода всегда потенциально под угрозой.

S>RTFM-мьте до просветления.

Пользуясь случаем, я бы предложил прогуляться в сад. ))

S>>>То, что я не могу изменить этот инт, не означает, что никто не может.

V>>Дык, твой аргумнет известный, я же его и привел:
V>>

V>>Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?

S>Нет, вы привели совершенно другой аргумент. Это аргумент про то, что функция, в которую уехала ссылка на константу (callee), может её взломать через const_cast, обманув ожидания caller-а.

S>А я говорю про то, что даже убрав из языка C-style cast и const_cast, мы оставляем возможность caller-у обмануть ожидания callee по константности переданной ссылки.

Обмана никакого нет, если ты неконстантное значение захочешь привести к константе, ведь ты не нарушишь ни одного контракта.

S>Если callee хочет работать с переданным ему по ссылке значением, он обязан сделать копию руками.

Никто никому ничего не обязан. Для императива вся его декомпозиция заключается в декомпозиции кода по обработке данных. А если эта обработка многостадийная, то вот и получи ссылку на неконстантное значение. Зачем это всё? Да пустяки, всего лишь примерно на порядок-полтора эффективнее в нагрузочных сценариях, чем аналогичное, выполненное в функциональной чистоте.

См. с чего пошла речь изначально. Никто не собирался запрещать мутабельность как таковую (на современных архитектурах рассуждения в эту область отдают либо академичностью, либо непревзойденным нубством), речь лишь о том, чтобы отделять мух от котлет, то бишь, если мы ввели иммутабельность в некий контракт, то этот контракт должен быть соблюдён. Точка.

S>Если вам это непонятно, то дизайном языков заниматься пока рано — спрашивайте, будем разьяснять.

А не пробовал лечить по фотографии? ))

Если бы ты хоть примерно представлял, какие проблемы возникают при дизайне языков... Константность — это вообще дело десятое, если не сотое. При всей моей желчи в адрес текущего положения дел в С++ я-то прекрасно отдаю себе отчет, что язык не был разработан с 0-ля в прошлые выходные. Що маэмо те маэмо, включая гирю на ногах из почти 40 лет жизни исходного языка Си.

V>>И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.

S>Я не знаю семантики "предложенного модификатора clean".

Это блуждающе обсуждалось многократно. Суть предложения в том, чтобы награждать контракт ф-ии/метода неким модификатором (например, "clean"), который требовал бы функциональной чистоты от самих вычислений в теле ф-ии и во всех вложенных вызовах. Этот модификатор, будучи введенным, был бы тесно связан с const... почему именно так — объяснять не намерен. Будем считать этот вопрос планкой вхождения в тему.

И зря ты скипнул тему насчет Maybe... Для императивных языков требуется, я бы сказал, "креативное решение" проблемы нулевых ссылок. ))) На эту тему стоит помозговать. Контракты Spec# относительно этого — это даже не детсад, а ясельная группа.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

V>>>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.
S>>Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.

V>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.

Хм, не вредит??

    int x = 10;
    int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
    x = 12;
    std::cout << "y = " << y << std::endl; // а вот получите болт.

Здравствуйте, vdimas, Вы писали:

V>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
Дальнейшая чушь поскипана. Контрпример вам привели. Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте. Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.

Здравствуйте, Sinclair, Вы писали:

V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
S>Дальнейшая чушь поскипана. Контрпример вам привели.

Нет. Попробуешь ты привести контример?

S>Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте.

Да мне и так понятно, что тебе непонятно. Читай мой пост еще раз. Медленно. Потом думай, где контракт, а где его соблюдение.

S>Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.

Обсуждать бесполезно, пока ты не поймешь, что именно я написал насчет гарантий. Пока что у тебя какое-то своё кино.

Здравствуйте, Jack128, Вы писали:

V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.

J>Хм, не вредит??
J>

J>    int x = 10;
J>    int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
J>    x = 12;
J>    std::cout << "y = " << y << std::endl; // а вот получите болт.
J>

Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд... Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь?

Что значит "// мне казалось, что y — не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)"??? Тебе до фени, т.к. тебе с этим константным значением ничего нельзя сделать. Теперь см. на свою константность с т.з. вызывающего кода. Когда ты объявляешь себя const для окружающих — это ТЫ гарантируешь, что ТЫ не будешь это значение изменять.

Т.е. ты не можешь как-то требовать константности от вызывающего, но ты можешь гарантировать нечто важное тем, кто тебя вызывает. Далее, согласно правилам распростанения const теперь требуешь константности от вызываемых ТОБОЙ ф-ий для обработки этих же данных. И эта константность будет гарантироваться низлежащими ф-ия для ТЕБЯ. Обратил внимание, в какую сторону распространяется требование константности? А в какую сторону распространяется "чистый" код по факту применения этой константности? Ровно в противоположную. Теперь полегчало?

Если нет, см простой пример:

int m1(const int &) {...}

void m2() {
  int x = 10;

  // мутабельная часть метода
  x = 20;

  // абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()
  int y = m1(x);

  // опять мутабельная часть кода
  x = 30;
}

Описанное верно для случая видимости данных из одного потока.

В общем, изначально речь шла о том, что:

Чистые ФЯ и не запрещают мутабельность — они дают инструментарий для разделения кода на чистый и остальной.

Такое разделение я показал в методе m2. Чтобы оно работало со всеми присущими ФП обещанными плюшками в "чистых" участках кода, гарантии константности должны соблюдаться, то бишь из языка надо убрать дыры, позволяющие её обходить.

Здравствуйте, vdimas, Вы писали:

V>Если нет, см простой пример:

V>int m1(const int &) {...}
V>void m2() {
V>  int x = 10;
V>  // мутабельная часть метода
V>  x = 20;

//Что за идиотский бред!
//А я вот так сделаю
start_thread(&x);

V>  // абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()
V>  int y = m1(x);
V>  // опять мутабельная часть кода
V>  x = 30;
V>}

void mutator(void *data)
{
   int *x=(int*) data;
   while(true)
   {
       *x=rand(); //Happy debugging!
   }
}
void start_thread(int *x)
{
   beginthread(&mutator, x);
}

Нету в С/С++ никаких таких гарантий. И сделать их нельзя. Const/volatile — это механизм создания контекстов кода, он ничуть не гарантирует целостности данных банально из-за того, что данные передаваемые в константный контекст могут одновременно использоваться в другом потоке из неконстантного.

Здравствуйте, vdimas, Вы писали:

V>Нет. Попробуешь ты привести контример?
Зачем? Вы все ещё не понимаете того, который вам уже привели.
V>Обсуждать бесполезно, пока ты не поймешь, что именно я написал насчет гарантий. Пока что у тебя какое-то своё кино.
Я-то как раз всё понимаю. Вы уже почти разобрались — роете в правильную сторону. Попробуйте предоставить гарантии константности для callee, оставаясь в рамках С++.

Здравствуйте, vdimas, Вы писали:

J>>Хм, не вредит??
J>>

J>>    int x = 10;
J>>    int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
J>>    x = 12;
J>>    std::cout << "y = " << y << std::endl; // а вот получите болт.
J>>

V>Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд...

И даже облажавшись, продолжаем обвинять всех остальных в том, что они идут не в ногу?
V>Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь?

Конечно же callee определяет контракт для caller.

V>Что значит "// мне казалось, что y — не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)"??? Тебе до фени, т.к. тебе с этим константным значением ничего нельзя сделать. Теперь см. на свою константность с т.з. вызывающего кода. Когда ты объявляешь себя const для окружающих — это ТЫ гарантируешь, что ТЫ не будешь это значение изменять.
О! Правильная мысль.
V>Т.е. ты не можешь как-то требовать константности от вызывающего, но ты можешь гарантировать нечто важное тем, кто тебя вызывает.
Вот ещё одна правильная мысль. Именно про это я и писал — что если хочется "потребовать константности от вызывающего", то надо сразу при вызове делать полную копию. Иначе полагаться ни на что нельзя — а это запрет оптимизаций, а также возможные нарушения в логике работы.

V>Далее, согласно правилам распростанения const теперь требуешь константности от вызываемых ТОБОЙ ф-ий для обработки этих же данных. И эта константность будет гарантироваться низлежащими ф-ия для ТЕБЯ. Обратил внимание, в какую сторону распространяется требование константности? А в какую сторону распространяется "чистый" код по факту применения этой константности? Ровно в противоположную. Теперь полегчало?
Ну конечно же не полегчало. Потому что вы продолжаете непонимать ограниченность модели, несмотря на то, что оно у вас перед глазами.

V>Если нет, см простой пример:
V>

V>int m1(const int &) {...}

V>void m2() {
V>  int x = 10;

V>  // мутабельная часть метода
V>  x = 20;

V>  // абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()
V>  int y = m1(x);

V>  // опять мутабельная часть кода
V>  x = 30;
V>}
V>

V>Описанное верно для случая видимости данных из одного потока.
Ну, в данном конкретном случае x видим только из одного потока. Более того — из одного контекста. Так что риска нет.
Но m1 об этом ничего не знает, она не может полагаться на ваше честное слово в том, что её будут вызывать исключительно с константами либо со ссылками на локальную переменную.
Первый способ нарушить эти ожидания — использовать аргумент в нескольких потоках.
Второй способ — вызывать из m1() код, который может иметь другой способ доступа к аргументу.
Например, callback-метод, определённый в объекте-владельце аргумента. Безо всяких потоков нарушаем ожидания m1().

V>Такое разделение я показал в методе m2. Чтобы оно работало со всеми присущими ФП обещанными плюшками в "чистых" участках кода, гарантии константности должны соблюдаться, то бишь из языка надо убрать дыры, позволяющие её обходить.
Чтобы оно работало со всеми присущими плюшками, придётся изменить семантику const. Потому что в нынешнем виде этот const ничего не гарантирует вызываемому. Вы не можете в рамках С++ выразить сигнатуру "дайте мне ссылку на объект, который точно не изменится, хотя бы в пределах времени моего исполнения".
А в ФП — можете.

Здравствуйте, vdimas, Вы писали:

V>А что мешает в императивном языке использовать тот же const?

Это тут уже подробно обсудили.

V>Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?

Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода? Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.

В языках, где это реально работает, чистота функций гарантируется по построению. Начинается все с базовой иммутабельности — const-ов для этого не достаточно. Однако, изменяемые ссылки нужны и мы добавляем в чистый язык соотвествующие функции:

readMutVar :: MutVar a -> a

writeMutVar :: MutVar a -> a -> ()

Так делается в SML и в этот момент эта "чистота по построению" теряется. Т.е. в случае "в основном иммутабельного" языка вроде ML это решение уровня библиотеки (по большому счету, некоторая модификация языка нужна — неявный runIO для main).
Мы же сейчас строим чистый язык, так что этот вариант для нас не подходит — нам нужна другая библиотека.
Делаем функции работы с изменяемыми ссылками чистыми:

readMutVar :: MutVar a -> State -> (State, a)

writeMutVar :: MutVar a -> a -> State -> State

Все, теперь сайд-эффект обозначен как "изменение" некоторого фиктивного параметра State — т.е. сайд-эффектом он быть перестал, ссылочная прозрачность не нарушается.
Но у нас все еще есть проблема: из таких функций можно собрать функцию, которая чистой не является, ссылочную прозрачность нарушает.
Как же быть? Если в языке есть уникальные типы — мы просто делаем State уникальным:

readMutVar :: MutVar a -> *State -> (*State, a)

writeMutVar :: MutVar a -> a -> *State -> *State

Все, теперь "нечистая" комбинация таких функций просто не пройдет тайпчек.
Ну а что делать, если у нас уникальных типов нет?
Нам поможет другой аспект типобезопасности — обычная инкапсуляция.

readMutVar :: MutVar a -> State -> (State, a)
-- слегка поправим сигнатуру:
writeMutVar :: MutVar a -> a -> State -> (State,())
-- теперь сходство становится очевидным:
newtype IO a = IO (State -> (State, a))

readMutVar :: MutVar a -> IO a
writeMutVar :: MutVar a -> a -> IO ()

Теперь реализуем комбинаторы для этих функций, которые сохраняют уникальность State, и экспортируем их, а конструктор IO не экспортируем.
Вот теперь любая функция у нас чистая по построению (пока мы не нарушим инкапсуляцию IO).

Как видите, мы обошлись без монад, поэтому я и говорил, что они не нужны. Но желательны. Для чего? Для уменьшения писанины.
Выше я упоминал "безопасные комбинаторы". Для удобства их нужно много, а минимальный их набор — две штуки. Так вот, набор удобных комбинаторов, выражаемых в терминах этих базовых двух — одинаков для всех монад. А описываемое выше протаскивание параметра-состояния — это монада state. Поэтому вместо отдельной инфраструктуры построения безопасных (с точки зрения ссылочной прозрачности) мутирующих функций нам нужно просто реализовать инстанс класса Monad для IO (две функции). Плюс к тому, для монад делается синтаксический сахар, который маскирует всю эту "обвязку" из комбинаторов.
Класс Monad — это только одно из доступных решений. В хаскеле сейчас "из коробки" есть две иерархии таких интерфейсов для комбинации вычислений Functor/Applicative/Monad и (менее популярные) стрелки.

V>Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.

Этот "синтаксический оверхэд" (зло)намеренный. В стандартной библиотеке хаскеля для таких функций любят придумывать имена вроде пожалуйстаПрочитайЗначениеПоЭтойСтрашнойСтрашнойИзменяемойСсылке и написаниеЭтогоЧудовищноДлинногоИмениФункцииЯвляетсяНаказаниемЗаИзменениеПеременной. Ну, как написание ключевых слов Оберона является наказанием за то, что программист решил написать код на Обероне. Все это, с моей точки зрения, идиотизм. Но в случае хаскеля это можно исправить, сильно улучшить краткость и удобство работы с мутабельными ссылками/массивами, просто описав удобные функции в библиотеке.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Cyberax, Вы писали:

C>Нету в С/С++ никаких таких гарантий. И сделать их нельзя.

Может тебе стоило перечитать хоть немного из ветки, прежде чем бросаться с шашкой на танк?
Да и нехорошо скипать кючевое:

Описанное верно для случая видимости данных из одного потока.

А то ты сам с собой споришь.

C>Const/volatile — это механизм создания контекстов кода, он ничуть не гарантирует целостности данных банально из-за того, что данные передаваемые в константный контекст могут одновременно использоваться в другом потоке из неконстантного.

— const гарантирует даже из другого потока (если не пользовать дыры приведения типов), просто ты не подал переменнуюв другой поток как const.
— Зачем мне рядом с const нужен был еще один модификатор clean для ф-ий, который, оп-па, в некоторых сценариях уже прямо сейчас покрывается const? Наверно потому, что есть сценарии, где не покрывается?

Вот всяко более простой пример, чем ты привел:

void m3(int & a, const int & b) {
  a++;
}

void m2() {
  int x = 10;

  // участок уже нечистый, т.к. мы вызываем нечистый метод
  int y = m3(x, x);
}

Вот здесь особенно хорошо видно, зачем мне модификатор clean для кода.

Здравствуйте, Sinclair, Вы писали:

V>>Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд...
S>

И даже облажавшись, продолжаем обвинять всех остальных в том, что они идут не в ногу?

Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... поэтому я как раз-то хотел его обсудить — некий clean. Т.е., до этого поста ты даже не понимал, зачем я вообще рассуждаю относительно еще одного модификатора? Круто! ))

V>>Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь?

S>Конечно же callee определяет контракт для caller.

ЧТД. Поэтому я прямо сейчас остановлюсь и даю тебе еще одну попытку. Ты НЕ знаешь, как работает const в С++. Ты НЕ понимаешь, как можно выстроить полезные гарантии на основе const, то бишь для тебя, будь ты программистом С++, этот модификатор был бы более чем бесполезен...

В общем, спасибо за честность, но я уже 4 поста назад сказал, что ты неправильно понимаешь, зачем этот const вообще нужен. Будем считать, что я понятия не имею, что именно ты пытаешься обсуждать... Мне даже лень, если честно, фантазировать в сторону той семантики const, которую ты себе надумал и затем вдребезги "разбил". Может, как-нить потом на эту тему. Могу лишь дать ключевую затравку: модификатор const относится исключительно к данным (даже если стоит при экземплярном методе, то он стоит перед this), а надуманный мной модификатор clean стоял бы исключительно как модификатор сигнатуры ф-ий/методов. В общем, даже одна эта деталь должна была заставить тебя помедитировать — почему именно так? Еще не поздно, кстате.

Здравствуйте, Sinclair, Вы писали:

S>Я-то как раз всё понимаю. Вы уже почти разобрались — роете в правильную сторону. Попробуйте предоставить гарантии константности для callee, оставаясь в рамках С++.

)))

Читать до просветления.

Здравствуйте, Klapaucius, Вы писали:

V>>А что мешает в императивном языке использовать тот же const?
K>Это тут уже подробно обсудили.

Еще нет. Всё самое интересное только начинается. Рекомендую последить за темой. ))

V>>Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?

K>Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода?

Прямо компилятором и будет, не нужно никакое чудо. Если сигнатура ф-ии помечена как clean, то в теле ф-ии не может быть не-clean операций.

K>Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.

Это спекуляции, положа руку на. Мне даже от одного const очень много пользы удается извлечь, т.к. в первую очередь я использую этот модификатор для себя, то бишь сам себе бью линейкой по рукам. При наличии clean эта линейка была бы заметно увестистей. Банально хочется заствить компилятор делать больше работы по проверке кода.

K>В языках, где это реально работает, чистота функций гарантируется по построению. Начинается все с базовой иммутабельности — const-ов для этого не достаточно.

Потому что рассуждаете в сторону const=иммутабельность. Но это нерелевантное сопоставление. Распространение константности ровно противоположно направлению распространению иммутабельности. Это же по природе вещей и так должно было быть понятно: гарантии от себя противоположны требованиям от других.

Так вот, я утверждаю, что не смотря на противоположное направление распространения константности, таки можно добиться гарантий иммутабельности в некоей конкретной точке.

K>Теперь реализуем комбинаторы для этих функций, которые сохраняют уникальность State, и экспортируем их, а конструктор IO не экспортируем.
K>Вот теперь любая функция у нас чистая по построению (пока мы не нарушим инкапсуляцию IO).

Спасибо за расшифровку IO, но ее читал уже давно. Напомню мой недавний тезис:

Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.

Почему так? Потому что Хаскель предлагает комбинировать ф-ии программисту и проверяя их чистоту. Предложенный модификатор clean затсавлял бы аналогично программистов так комбинировать ф-ии, чтобы не нарушать этот модификатор.

K>Как видите, мы обошлись без монад, поэтому я и говорил, что они не нужны. Но желательны. Для чего? Для уменьшения писанины.

Разве только для этого. Вроде бы через модификатор IO компилятор позволяет опасные конструкции, типа чтения памяти (например, для связи с легаси-АПИ).

K>Выше я упоминал "безопасные комбинаторы". Для удобства их нужно много, а минимальный их набор — две штуки. Так вот, набор удобных комбинаторов, выражаемых в терминах этих базовых двух — одинаков для всех монад. А описываемое выше протаскивание параметра-состояния — это монада state. Поэтому вместо отдельной инфраструктуры построения безопасных (с точки зрения ссылочной прозрачности) мутирующих функций нам нужно просто реализовать инстанс класса Monad для IO (две функции). Плюс к тому, для монад делается синтаксический сахар, который маскирует всю эту "обвязку" из комбинаторов.
K>Класс Monad — это только одно из доступных решений. В хаскеле сейчас "из коробки" есть две иерархии таких интерфейсов для комбинации вычислений Functor/Applicative/Monad и (менее популярные) стрелки.

V>>Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.

K>Этот "синтаксический оверхэд" (зло)намеренный. В стандартной библиотеке хаскеля для таких функций любят придумывать имена вроде пожалуйстаПрочитайЗначениеПоЭтойСтрашнойСтрашнойИзменяемойСсылке и написаниеЭтогоЧудовищноДлинногоИмениФункцииЯвляетсяНаказаниемЗаИзменениеПеременной.

Длинное имя абсолютно непринципиально для того, что хочу я — заставить компилятор больше мне помогать. Ему длина идентификаторов до фени.

K>Ну, как написание ключевых слов Оберона является наказанием за то, что программист решил написать код на Обероне. Все это, с моей точки зрения, идиотизм.

ХЗ, в том же С++ я вынужден разметкой комментов выделять отдельные ф-ии, чтобы они не сливались с окружающим "фоном". На паскалевских языках такое выделение идет изкаробки через ключевые слова.

K>Но в случае хаскеля это можно исправить, сильно улучшить краткость и удобство работы с мутабельными ссылками/массивами, просто описав удобные функции в библиотеке.

И с помощью этих ф-ий можно будет так?

x = 20;
x = x + 10;

Здравствуйте, vdimas, Вы писали:
V>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ...
Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий". Это вас интересовало "что мешает в императивном языке использовать тот же const". Отлично — потребовалось всего пять дней и восемь постов чтобы понять, что же именно мешает.

А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const. И постарайтесь избегать умозаключений на тему того, кто тут насколько знает С++ — они мало кому интересны. Я вам про это уже говорил. Если у вас цель — довыступаться до бана, то так и напишите на модераторский адрес.

Здравствуйте, Sinclair, Вы писали:

V>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ...
S>Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий".

Фи, какие грязные инсинуации. В общем, ЧТД.

Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.

==========================
Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.

Здравствуйте, FR, Вы писали:

V>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... поэтому я как раз-то хотел его обсудить — некий clean. Т.е., до этого поста ты даже не понимал, зачем я вообще рассуждаю относительно еще одного модификатора? Круто! ))

FR>В C++ никаких гарантий нет.

Дык, были бы гарантии, не было бы обсуждений, что бы мне хотелось в С++ доработать.

Здравствуйте, Klapaucius, Вы писали:

K>Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода? Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.

По мне тоже система типов лучше, но модификаторы типа const тоже вполне нормально для императивных языков, но
в C++ const это во многом чистая косметика (хотя даже это дает возможность писать более надежный код), вот в D
все уже серьезно.
Польза очень даже извлекается, во первых оптимизация кода и перенос вычислений в compile time второе
многопоточность.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

V>>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ...
S>>Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий".

V>Фи, какие грязные инсинуации. В общем, ЧТД.

V>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.

V>==========================
V>Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.

Здравствуйте, vdimas, Вы писали:

V>Если сигнатура ф-ии помечена как clean, то в теле ф-ии не может быть не-clean операций.

И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?
Просто я не раз уже видел такие рассуждения "давайте сделаем аннотации чистоты" а когда начинаются вопросы отвечают как в анекдоте: "я вам дал идею, а детали вы сами продумывайте".

V>Это спекуляции, положа руку на. Мне даже от одного const очень много пользы удается извлечь, т.к. в первую очередь я использую этот модификатор для себя, то бишь сам себе бью линейкой по рукам. При наличии clean эта линейка была бы заметно увестистей. Банально хочется заствить компилятор делать больше работы по проверке кода.

Непонятен только механизм работы. И, кроме того, вы не учитываете, что мутабельность по-умолчанию оставляет мало возможностей что-то там проаннотировать. По факту, есть два устойчивых состояния: повсеместная иммутабельность с мутабельностью только там где надо и повсеместная мутабельность с чистым кодом (вроде 2+2) в следовых количествах. Все прочие соотношения "нестабильны" и приводят в перспективе к одному из этих результатов.

V>Потому что рассуждаете в сторону const=иммутабельность. Но это нерелевантное сопоставление. Распространение константности ровно противоположно направлению распространению иммутабельности. Это же по природе вещей и так должно было быть понятно: гарантии от себя противоположны требованиям от других.

Но на практике-то нужны гарантии от других.

V>Почему так? Потому что Хаскель предлагает комбинировать ф-ии программисту и проверяя их чистоту.

Ну так я и объясняю, что чистоту никто не проверяет. Чистота гарантируется по построению.

V>Предложенный модификатор clean затсавлял бы аналогично программистов так комбинировать ф-ии, чтобы не нарушать этот модификатор.

Т.е. нужно будет что-то доказывать и проверять? Ну и как это делать?

V>Разве только для этого. Вроде бы через модификатор IO компилятор позволяет опасные конструкции, типа чтения памяти (например, для связи с легаси-АПИ).

Да для чего угодно. Параметр State-то фиктивный, он ничего не хранит, а просто последовательность задает, которая в неявном виде в чистом языке отсутствует и должа быть явной, когда она нужна. Я и продемонстрировал "чтение памяти". И даже "запись в память".

V>Длинное имя абсолютно непринципиально для того, что хочу я — заставить компилятор больше мне помогать. Ему длина идентификаторов до фени.

С помощью компилятора тоже все в порядке. Но компилятор, а точнее тайпчекер, делает то, что обычно — проверяет типы, а не "вычисляет чистоту" и т.д.

V>И с помощью этих ф-ий можно будет так?
V>

V>x = 20;
V>x = x + 10;
V>

Да, с точностью до именования лексем, = использовать нельзя, это ключевое слово. Можно и короче — с += и прочим. Можно и вышеупомянутый x++ сделать, с той поправкой, что постфиксные операторы в хаскеле должны быть в скобках, т.е. (x++). Можно даже лучше, написать линзы, но не "функциональные", а с изменением по-месту, с помощью ST, а это, фактически, first-class l-values.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
S>Дальнейшая чушь поскипана. Контрпример вам привели. Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте. Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.

Лучше бы ты матом высказался, это, по крайней мере, честно было бы.

Здравствуйте, Klapaucius, Вы писали:

K>Вот это он и есть — Смолток.

И?
А можно посмотреть паттерны фасад, мост, адаптер? А можно посмотреть во что вырождается паттерн State? ))

Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

Здравствуйте, WolfHound, Вы писали:

WH>

Лолшто?

Ага, есть немного. Надо заканчивать в 3 часа писать посты. Ес-но наоборот.

WH>Открытые ключи они на то и открытые чтобы ими ничего расшифровать было нельзя.
WH>Или ты собрался сломать ассиметричный шифр? Удачи.

Гы, я даже не собираюсь рассматривать варианты взлома системы через некие алгоритмы взлома шифрования. Это заведомо бесполезное направление. Речь о взломе через инфраструктуру.

Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...

V>>И еще, ты так и не обрисовал, как ты себе представляешь тестирование ПО на злонамеренность. И как ты себе вообще верификацию ПО представляешь? много раз сертификацию проходил, поделись? Или как обычно последние годы — облака, белокрылые лошадки.. сплошь сферические? Ладно там верификация на опасный с т.з. типобезопасности код — это хоть как-то автоматизируется, но обсуждаемые вещи будут абсолютно типобезопасны, а глазками в сотне тыщ строк ты хрен чего поймаешь. Это такая ситуация прямо на сегодня. А ты этого никак не понимаешь, бо по-твоему, типобезопасность и изолированность что-то значат. А на самом деле через DMA прямо сейчас можно загнать любой участок памяти Сингулярити в буфер жесткого диска и прочитать обратно. Вот и нет твоей изолированности процессов. В общем, не с того конца ты подходишь к безопасности изначально. А всё потому, что пороха не нюхал и рассуждаешь угубо умозрительно.
WH>Еще раз.
WH>Это лечится при помощи IOMMU раз и навсегда.

Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.

Здравствуйте, Sinclair, Вы писали:

S>+1. Всегда радуюсь, когда люди мне рассказывают, что SSL не может работать. Особенно, когда это сопровождается вееробразными движениями пальцев и отеческим тоном.

А как раз рядом показал, что надо делать.

Здравствуйте, Sinclair, Вы писали:

V>>А теперь берем паскалеподобные языки:
V>>- макроопределений нет
V>>- enum нет
S>Как это? Куда дели enum?
S>RTFM:
S>http://www.delphibasics.co.uk/Article.asp?Name=Sets

Терпеть не могу, когда кто-то пытается натянуть сеты на enums. Ты точно писал на Дельфи?

S>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.

Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
1. Эдакие юзверские алиасы для целочисленных типов.
2. Константные значения этих типов.

В Обероне алиасинг доступен для любых типов изкаробки, не только целочисленных.

TYPE
     Flag = BOOLEAN;

Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.

V>>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
V>>Теперь аргументировано?
S>Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".

Пытаться натягивать set на enum — вот это ляп.

V>>Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок.
S>Конечно же есть. Разница — ровно такая же, как между поддержкой строк в языке и "возможностью наплодить свои классы строк".

Дык, еще скажи, что не сталкивался на дотнете с такими сценариями, когда вроде бы задачи по обработке сивольной информации, но встроенные строки прибивают любую эффективность на корню.

S>Стандарт даёт возможность разработчикам пользоваться языком и интероперировать, а в бесстандартных языках типа С++ имеется зоопарк плохо совместимых между собой "платформ" — Qt, MFC, и так далее.

Гы, а язык-то здесь причем?? В языке как раз есть стандарт STL и есть строки (аналоги StringBuilder), а то, что там MS навертели со строками в MFC, дык они минимум дважды полностью меняли внутренний дизайн строки (предпоследний был вообще баговым), и знаешь на чем устаканилось? Правильно, на том же подходе, как в STL. Стоила ли вся эта овчинка выделки, как считаешь?

V>>А мне гипертекстовые ссылки прямо из кода нравятся.

S>Гипертекстовые ссылки из кода бывают двух типов:
S>1. В коде, Go to definition — поддерживаются вменяемыми IDE безо всякой ручной раскраски. В Delphi — Ctrl+Click, в VS, емнип, клавиатурная комбинация.
S>2. Произвольные, из комментариев — поддерживаются вменяемыми IDE безо всякой ручной раскраски.

Если надо прыгнуть куда-то в код в проекте — не поддеживаются. Только по идентификаторам и можно скакать. Но внутрь метода так не заскочешь.

V>>По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.
S>Оберон бы вас точно так же не спас. Если авторы доки не воспользовались средствами, встроенными в PDF (вы же знали, что в нём прекрасно работают ссылки — ещё с тех времён, когда Adobe хотела заменить им HTML для вёрстки в вебе?), то средствами, встроенными в Оберон они бы тоже пренебрегли.

Дык, аргумент был не про PDF, а про то, насколько с гиперссылками удобнее, чем без них. Да, пример был построен на нерадивых технических писателях, но он показал всё что я хотел показать.

V>>Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.
S>Это они в контексте гипертекстовых исходников ссылаются, или вы опять пытаетесь контекст подменить?

Дык, у тебя любой контекст сводится к этому:

Пример Оберона не смог никого вдохновить.

А еще один рядом вообще лично на Вирта наезжает...
Не знаю, не знаю... Как ты думаешь, кто был автором парадигмы p-код? Можешь считать подменой контекста, бо этему раскраски вроде бы договорились считать исчерпанной.

Здравствуйте, vdimas, Вы писали:

K>>Вот это он и есть — Смолток.

V>И?
V>А можно посмотреть паттерны фасад, мост, адаптер? А можно посмотреть во что вырождается паттерн State? ))
Посмотреть нельзя. Но вот пару цитат из книги:
Adapter

Known Uses
Pluggable adapters are common in ObjectWorks\Smalltalk [Par90]. Standard Smalltalk defines a ValueModel class for views that display a single value. ValueModel defines a value, value: interface for accessing the value. These are abstract methods. Application writers access the value with more domain-specific names like width and width:, but they shouldn't have to subclass ValueModel to adapt such application-specific names to the ValueModel interface.

Instead, ObjectWorks\Smalltalk includes a subclass of ValueModel called PluggableAdaptor. A PluggableAdaptor object adapts other objects to the ValueModel interface (value, value: ). It can be parameterized with blocks for getting and setting the desired value. PluggableAdaptor uses these blocks internally to implement the value, value: interface. PluggableAdaptor also lets you pass in the selector names (e.g., width, width directly for syntactic convenience. It converts these selectors into the corresponding blocks automatically.

Another example from ObjectWorks\Smalltalk is the TableAdaptor class. A TableAdaptor can adapt a sequence of objects to a tabular presentation. The table displays one object per row. The client parameterizes TableAdaptor with the set of messages that a table can use to get the column values from an object.

Facade

Known Uses
The compiler example in the Sample Code section was inspired by the ObjectWorks\Smalltalk compiler system [Par90].

[Par90] ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990.

Здравствуйте, vdimas, Вы писали:

V>Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...
Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Известна миллион лет.
Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.
И такой протокол никогда не пройдет через нормального безопасника.

И еще. Не стоит путать прослушивание с проксированием.
Ибо есть протоколы, защищающие от прослушивания, но не проксирования.
А есть протоколы, которые можно атаковать только через слабость алгоритмов шифрования.

V>Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.
Короче очередной слив засчитан.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Терпеть не могу, когда кто-то пытается натянуть сеты на enums.
Мне ваше мнение по этому вопросу глубоко безразлично. Зачем вы меняете тему?
V>Ты точно писал на Дельфи?
Да. Вы же вроде бы писали, что помните мои ранние посты?
Попробуйте для интересу сходить вот сюда.
S>>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

V>Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.
http://compgroups.net/comp.lang.oberon/enumeration-types/1433942
Я надеюсь, само собой понятно, что на нишевом языке никто, кроме фанатов, не пишет?

V>Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
V>1. Эдакие юзверские алиасы для целочисленных типов.
V>2. Константные значения этих типов.
Я не знаю, что именно вы называете мейнстримом. Скажем, енумы в Джаве сделаны сильно по-другому, чем енумы в Object Pascal aka Delphi.
И оба сильно отличаются от сишных "алиасов" — в частности, они не совместимы по присваиванию.
V>Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.
Я улавливаю общий паттерн в вашей манере ведения спора. Вы утверждаете чушь (типа "енум это всего лишь алиас для целочисленного типа"), а потом из неё делаете глубокие выводы.

V>>>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
V>>>Теперь аргументировано?
S>>Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".

V>Пытаться натягивать set на enum — вот это ляп.
Я не понимаю, что значит "натягивать set на enum". Вы что, ещё и путаете Set type с enum type?

V>Дык, еще скажи, что не сталкивался на дотнете с такими сценариями, когда вроде бы задачи по обработке сивольной информации, но встроенные строки прибивают любую эффективность на корню.
Нет, не сталкивался. В тех редких случаях, когда иммутабельные строки неэффективны, рулит StringBuilder.

V>Гы, а язык-то здесь причем?? В языке как раз есть стандарт STL и есть строки (аналоги StringBuilder), а то, что там MS навертели со строками в MFC, дык они минимум дважды полностью меняли внутренний дизайн строки (предпоследний был вообще баговым), и знаешь на чем устаканилось? Правильно, на том же подходе, как в STL. Стоила ли вся эта овчинка выделки, как считаешь?

Считаю, что нет, и вроде бы ясно об этом написал. Вся вот эта галиматья со строками появилась ровно от того, что поддержку строк в язык так и не встроили. std::string — полная чухня. Я бы ещё простил её, если бы у строковых констант тип был не char*, а std::string.

V>Если надо прыгнуть куда-то в код в проекте — не поддеживаются. Только по идентификаторам и можно скакать. Но внутрь метода так не заскочешь.
Зачёт, этот сценарий мне в голову не пришёл.

V>Дык, аргумент был не про PDF, а про то, насколько с гиперссылками удобнее, чем без них. Да, пример был построен на нерадивых технических писателях, но он показал всё что я хотел показать.
Неубедительно. Берём джавадок — видим, что ссылки есть. Гипертекста в джаве — нету. Берём XML Doc Comments, видим: ссылки — есть. Гипертекста — нету.
Резюме: хотение гиперссылок в качестве обоснования необходимости гипертекста не катит.

V>Не знаю, не знаю... Как ты думаешь, кто был автором парадигмы p-код? Можешь считать подменой контекста, бо этему раскраски вроде бы договорились считать исчерпанной.
Автором p-кода был Вирт. Автором парадигмы — хрен его знает. Ричардс разработал INTCODE и O-code практически одновременно с Виртом.

Здравствуйте, Ikemefula, Вы писали:

I>Лучше бы ты матом высказался, это, по крайней мере, честно было бы.
Не хочу уподобляться оппоненту, несмотря на троллинг и провокации с его стороны.

Здравствуйте, vdimas, Вы писали:

V>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
Никаких инсинуаций. Все ходы записаны. Вот вопрос:

А что мешает в императивном языке использовать тот же const?

Я вам написал, что мешает. Вы, вместо того, чтобы читать, что вам пишут, приписали мне (и Klapaucius, Cyberax, и jack128) непонимание семантики слова const. Нет, мы все её как раз прекрасно понимаем. Вместе с её ограничениями.
Это вы почему-то отказываетесь понять, что возможность "наложить ограничения на себя" недостаточна. Поймите, от чистого кода защищаться не нужно — он на то и чистый. Нужно защищать чистый код от модифицирующего кода. А для этого как раз нужен тот механизм гарантий для callee, которого в const нету.

V>==========================
V>Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.
Это та, где вы ссылаетесь на эту? Вот это приём, достойный форумного профи. Как и вырезание вопроса, отвечать на который не хочется.
Я верну его на место:

А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.

Здравствуйте, Sinclair, Вы писали:

V>>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
S>Никаких инсинуаций. Все ходы записаны. Вот вопрос:
S>

S>А что мешает в императивном языке использовать тот же const?

Ну вот на такое выдергивание я и высказал фи, бо в том же самом посте далее наблюдается:

... пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.

S>Я вам написал, что мешает.

Вы все писали исключительно об иммутабельности, не понимая кое-какое важное отличие иммутабельности как от исходных требований, так и от реально происходящего в коде. Современный компилятор С++, если видит жизненный цикл значения, спокойно обходится даже без всяких const при оптимизации, не то, что без мифической иммутабельности. Не нужно! То бишь все плюшки ссылочной прозрачности на самом деле доступны ровно тогда, когда нет скрытых изменений данных.

S>Вы, вместо того, чтобы читать, что вам пишут, приписали мне (и Klapaucius, Cyberax, и jack128) непонимание семантики слова const. Нет, мы все её как раз прекрасно понимаем. Вместе с её ограничениями.

Я уже сказал только что: тогда вы не понимаете другого, в чем я просто не хотел никого обвинять заранее, поэтому пока пытался представить такое понимание как невнимательность и/или недостаточное знание сценариев применимости const (что не страшно, в общем-то для тех, кто не пишет постоянно на плюсах). Ну ОК, будем считать, что это принципиальное непонимание вопроса.

На самом деле там ничего сложного, достаточно было быть внимательным к постам оппонентов. Я сразу напомнил (подразумевая, что обсуждаю этот вопрос не с плюсовиками) о т.н. "распространении константности". В какую сторону константность-то распространяется, господа хорошие? Ну а теперь, второй вопрос — можно ли с помощью этой техники организовать распространение ссылочной прозрачности в след за константностью? Заметь, не "породить ссылочную прозрачность из воздуха" относительно произвольно полученой ссылки (как вы от меня требовали в примерах, ломающих якобы иммутабельность на основе const), а именно распространить, если факт ссылочной прозрачности уже есть в некоей точке алгоритма де-факто?

А откуда ссылочная прозрачность появляется? Вопрос на мильон, а ответ простой — только в месте создания значения. Вот исходная точка. Прямо отсюда можно вернуться к моим постам и, пользуясь новым знанием, посмотреть как на мои примеры, так и на общий ход рассуждений относительно const.

То бишь, в своих постах я изначально исходил из очевидной для меня (но неочевидной для окружающих, как выяснилось) цели: можно ли организовать в некоей точке видимости исходный код так, чтобы вызываемые непрозрачные для компилятора низлежащие процедуры заведомо не нарушали ссылочной прозрачности относительно обложенных const данных? Ответ — можно. Как именно — я уже показал.

Для компилятора было бы достаточно знать жизненный цикл значений и было бы достаточно гарантий от вызываемого кода. Так вот, на сегодня эта техника недостоверна из-за возможности в языке нарушать константность. Но не в том виде, как вы показали (когда ссылочной прозрачности относительно неких данных уже не было на входе процедуры), а из-за встроенных в сам язык конструкций по преодолению этой константности. Вот эти конструкции меня и раздражают.

Ну а второе важное утверждение, которое вы в упор не видите, что const — это модификатор уже существующего, порой очень функционального (не в смысле ФП) и очень полезного типа. В отличие от вашего фетиша — иммутабельности, который был бы ни разу не модификатором типа, а тупо отдельный тип. То бишь нельзя было бы один и тот же полезный тип использовать как мутабльный и как иммутабельный. Мне казалось, что этот важный момент был очевиден всем участникам обсуждения, ан нет?

Итого, исходный постулат о введении контроллируемой мутабельности в случае отдельных иммутабельных типов был бы полной профанацией всей идеи. То бишь вместо разделения алгоритмов на чистые и нечистые относительно одних и тех же данных (которые и есть "состояние" в ООП), было бы тупое разделение кода на две непересекающиеся по типам области. То бишь был бы эффект от двух плохосовместимых языков в одном исходнике, где надо было иметь кучу рукописного кода по копированию данных из одних типов в другие. Это не коснулось бы только простых типов данных и структур на их основе со всеми публично-видимыми полями, на которые компилятор способен распространить иммутабельность самостоятельно... но ведь мы обсуждали ООП.

S>Это вы почему-то отказываетесь понять, что возможность "наложить ограничения на себя" недостаточна.

Курить распространение константности. Всего достаточно.

Мы вообще что и ради чего обсуждаем? Я так предполагаю, что все в курсе, что суперкомпиляция на сегодня недоступна, что современным компиляторам запросто могут быть недоступны кишки вызываемых подпрограмм, поэтому именно от вызываемых подпрограмм требуются гарантии. Не от вызывающих. Что сами эти гарантии относительно вызываемых подпрограмм нужны исключительно для того, чтобы компиляторы могли делать все оптимизации, которые они могли бы делать в случае ссылочной прозрачности.

В общем, насчет понимания... Я как-раз таки прекрасно понимаю, что не то, что const более чем достаточно для обсуждаемой цели. Я понимаю гораздо больше, но стараюсь не писать лишний раз на этот сайт, дабы не дразнить гусей. Я понимаю, что требование иммутабельности в объявлении типа для целей ссылочной прозрачности — это требование сугубо для человека, а не компилятора. Мне просто лень было поднимать опять эти темы, но уже обсуждали подробно когда-то, и я помню реакции коллег, кому это ломает мозг и вообще переполосывает привычно размеченную территорию. Для обеспечения ссылочной прозрачности требуется отсутствие скрытого (от компилятора!) изменения данных. Это ВСЁ. Т.е. де-факто не нужна никакая иммутабельность для обеспечения ссылочной прозрачности. Пример? Пожалуйста: создавай себе локальные мутабельные переменные в процедурах (хотя бы для счетчика цикла), без передачи ссылок на эти переменные куда-то в "черную дыру", никакого нарушения ссылочной прозрачности не будет. Дык, а если та самая "черная дыра" гарантирует const относительно этой ссылки, то опять же, никакого нарушения не будет, при условии, что та дыра не сохранит эту ссылку, а только использует ее в момент вызова без нарушения const... А вот в этом самом месте тебя должно было озарить, нахрена мне вообще был нужен clean. И в чем его принципиальное отличие от const. ))) Ключевое выделил курсивом.

То бишь, опасности в случае const всё еще сохраняются, но они вовсе не в той стороне, как вы показали в примерах. Вы показали заведомую ссылочную непрозрачность и потребовали создать там прозрачность из воздуха. Детсад как он есть. Налицо непонимание происходящего.

S>Поймите, от чистого кода защищаться не нужно — он на то и чистый. Нужно защищать чистый код от модифицирующего кода. А для этого как раз нужен тот механизм гарантий для callee, которого в const нету.

Увы и ах, поэтому-то чистое ФП и не взлетело в мейнстриме до сих пор, что вы всё еще пытаетесь переложить всё на человека, забывая, зачем вообще эта ссылочная прозрачность нужна. Она нужна компилятору сугубо для оптимизаций, чтобы он мог много чего предполагать, считая свои рассуждения относительно переменных по мере трассировки их значений вдоль алгоритма доказанными. Положа руку на, мне был хотелось ограничиться одной этой фразой вместо всех постов, считая коллег достаточно любопытными, чтобы остальное раскрутить самостоятельно... Но не судьба... Ок, далее.

Помимо этого, константность (в отличие от иммутабельности) — это неплохое подспорье для организации сипмпатичного АПИ. Например, мне глубоко несимпатичны решения навроде отдельных интерфейсов ISomeReader + ISomeWriter inherits ISomeReader, где ссылку на второй интерфейс получают динамическим приведением ссылки на первый. Какая гадость, право... И такое в том же дотнете и Java сплошь и рядом. Или того хуже, возьмем иммутабельный вариант реализации объединенного изначально мутабельного интерфейса, который имеет некое св-во IsReadOnly и плюет в нас исключениями при вызове мутабельных методов в случае иммутабельной их реализации. Понятно, что ни система типов, ни компилятор уже ничем такому смертельно раненому пациенту помочь не могут. А в случае const — могут без проблем.

S>Это та, где вы ссылаетесь на эту? Вот это приём, достойный форумного профи. Как и вырезание вопроса, отвечать на который не хочется.
S>Я верну его на место:

S>

S>А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

Дык, я и не мог ответить на таким образом сформулированный вопрос пока видел непонимание работы const. Ведь вопрос связывает одно с другим. Я давал всё больше подсказок — но так и не увидел понимания. ОК, я сел и нахерачил это пост (выбрать на такой пост время тоже не просто). В общем, я не уверен, что и сейчас все участники поняли, как надо заставлять const работать. Но хоть собрал в одном посте все рассуждения и обрисовал ту самую неразрешимую проблему вокруг const, то бишь теперь показал, зачем мне нужен был clean. Он нужен сугубо для:

Потому что с помощью const можно организовать меньше участков кода с соблюдаемой ссылочной прозрачностью, чем бы мне хотелось.

Заведомо зная, что тут надо поднять значительный пласт материала, чтобы показать сей момент, я сразу предупредил:

Этот модификатор, будучи введенным, был бы тесно связан с const... почему именно так — объяснять не намерен. Будем считать этот вопрос планкой вхождения в тему.

Но ты же, блин... Ты же, блин, читаешь форум по диагонали. Ты же сам тут ля-ля одновременно в десятках тем, и считаешь что твои оппоненты делают такое же ля-ля только ради этого самого ля-ля. Я могу себе позволить участвовать обычно в одной теме (очень редко в двух). Поэтому, чтобы общение имело хоть какой-то смысл, было бы неплохо хотя бы иногда перестать бежать отвечать после чтения по диагонали. Посты оппонентов я читаю весьма внимательно, твои в т.ч. Ты — нет. Сорри за оффтоп, но мы дошли аж до сюда по ветке исключительно от твоей невнимательности. Можешь ради любопытства пробежаться теперь по ветке и устыдиться — все входы и выходы были даны сразу, я карт в рукаве не держу и голову людям, как некоторые твои однотимовцы, не морочу.

S>Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.

Ну конечно неправильные. Вы же ставили знак равенства м/у const и иммутабельностью, потом говорили, что это я, оказывается, ставлю, а потом показывали как же я не прав. )))
Это что вообще было, господа хорошие? Сколько мне надо было еще пытаться вас сфокусировать на предмете обсуждения? Ну это просто такое пффф... что теперь стало необходимо проводить ликбез непозволительной для формата форумов глубины в обсуждаемом вопросе, только лишь чтобы доказать, что я не верблюд? Ну, спасибо...

А медитировать я тебя могу отправить лишь над тем вопросом — зачем тебе эта иммутабельность вообще сдалась? Это ключ ко всему. Хотелось бы понимания, что она сама по себе не нужна, что это лишь один из способов для достижения другой полезной цели. Но ни разу не единственный способ.

Здравствуйте, Klapaucius, Вы писали:

K>И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?

Угу.
Если брать D в котором нечто подобное уже реализовано http://dlang.org/function.html#pure-functions то все очень жестко

does not read or write any global or static mutable state
cannot call functions that are not pure
can override an impure function, but an impure function cannot override a pure one
is covariant with an impure function
cannot perform I/O

Различать же просто компилятор просто не компилирует если условия не соблюдаются

K>Просто я не раз уже видел такие рассуждения "давайте сделаем аннотации чистоты" а когда начинаются вопросы отвечают как в анекдоте: "я вам дал идею, а детали вы сами продумывайте".

В D сделали, это потребовало коренной переделки концепции const из C++ и было основной причиной появления D2.
http://dlang.org/const3.html

По сути получилось три уровня

Immutable то что невозможно никак изменить, для сложных объектов действует транзитивно, в общем чисто функциональные типы.
Const это данные только для чтения, близко к C++ const.
И обычные изменяемые данные.

Здравствуйте, vdimas, Вы писали:

V>Ну вот на такое выдергивание я и высказал фи, бо в том же самом посте далее наблюдается:
V>

V>... пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Ну а я отвечу фи на ваш способ выдергивания. Потому что в оригинале было не троеточие, а "или":

Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Что кагбэ подразумевает равноправность решений по убиранию const_cast и введению модификатора clean.

V>Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.
Я не очень понимаю, как вы собираетесь организовывать "участки кода со ссылочной прозрачностью", выходя за пределы одного метода.
Вот мы имеем, скажем,

void foo(const int &x)
{
   cout << x; // 1
   bar();
   cout << x; // 2 
}

Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

V>Вы все писали исключительно об иммутабельности, не понимая кое-какое важное отличие иммутабельности как от исходных требований, так и от реально происходящего в коде. Современный компилятор С++, если видит жизненный цикл значения, спокойно обходится даже без всяких const при оптимизации, не то, что без мифической иммутабельности.
Вы опять делаете необоснованные предположения о том, чего не понимают ваши оппоненты. Ключевое ограничение выделено.
Вопрос только в том, что жизненный цикл значения длиной в одно тело метода малоинтересен на практике. Интересна возможность собирать из мелких кубиков целостные решения, и выводить свойства целого из свойств частей.

V>На самом деле там ничего сложного, достаточно было быть внимательным к постам оппонентов.
V>То бишь, в своих постах я изначально исходил из очевидной для меня (но неочевидной для окружающих, как выяснилось) цели: можно ли организовать в некоей точке видимости исходный код так, чтобы вызываемые непрозрачные для компилятора низлежащие процедуры заведомо не нарушали ссылочной прозрачности относительно обложенных const данных? Ответ — можно. Как именно — я уже показал.
Ну вам же привели на ваше "можно" контрпримеры.

V>Для компилятора было бы достаточно знать жизненный цикл значений и было бы достаточно гарантий от вызываемого кода.
В том-то и проблема, что такой подход требует глобального анализа для "жизненного цикла значений".

Но не в том виде, как вы показали (когда ссылочной прозрачности относительно неких данных уже не было на входе процедуры), а из-за встроенных в сам язык конструкций по преодолению этой константности. Вот эти конструкции меня и раздражают.

V>Мы вообще что и ради чего обсуждаем? Я так предполагаю, что все в курсе, что суперкомпиляция на сегодня недоступна, что современным компиляторам запросто могут быть недоступны кишки вызываемых подпрограмм, поэтому именно от вызываемых подпрограмм требуются гарантии. Не от вызывающих. Что сами эти гарантии относительно вызываемых подпрограмм нужны исключительно для того, чтобы компиляторы могли делать все оптимизации, которые они могли бы делать в случае ссылочной прозрачности.
Ну покажите же мне, какие оптимизации может делать компилятор при компиляции foo(const int& x) по сравнению с компиляцией foo(int& x).

S>>Я верну его на место:

S>>

S>>А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

V>Дык, я и не мог ответить на таким образом сформулированный вопрос пока видел непонимание работы const.
Нет никакого непонимания работы const.

V>Ведь вопрос связывает одно с другим. Я давал всё больше подсказок — но так и не увидел понимания. ОК, я сел и нахерачил это пост (выбрать на такой пост время тоже не просто).
То есть как обычно — у вас хватило времени налить воды, но кода с примером применения clean мы так и не увидели. ЧиТД.

S>>Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.
V>Ну конечно неправильные. Вы же ставили знак равенства м/у const и иммутабельностью, потом говорили, что это я, оказывается, ставлю, а потом показывали как же я не прав. )))
Никто не ставил знаков равенства. Говорили, что для изоляции чистого кода от мутабельного const не работает. И вы мне тут капсом пишете что нет, он для этого не работает. Зато, предположительно, будет работать clean. Но пока непонятно как. Давайте код в студию, а то без него разговор смысла не имеет.

Здравствуйте, Sinclair, Вы писали:

S>Как это? Куда дели enum?
S>RTFM:
S>http://www.modula2.org/reference/enumerations.php
S>http://www.delphibasics.co.uk/Article.asp?Name=Sets
S>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП. Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов. Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...

Здравствуйте, FR, Вы писали:

FR>В D сделали, это потребовало коренной переделки концепции const из C++ и было основной причиной появления D2.
FR>http://dlang.org/const3.html

FR>По сути получилось три уровня

FR>Immutable то что невозможно никак изменить, для сложных объектов действует транзитивно, в общем чисто функциональные типы.
FR>Const это данные только для чтения, близко к C++ const.
FR>И обычные изменяемые данные.

Во, это все круто. Мне нравится. Правильно сделано.

Есть еще мысль — надо убрать из языка все ссылки вообще.

Передача параметров только копированием значения (семантически, а так компилятор может провести анализ и заменить значение ссылкой). От совсем опасных указателей избавились, теперь пока ссылки выкинуть.

ИМХО, сразу уберется куча потенциальных ошибок и код будет более организованным. Циклические структуры данных и рекурсия в пролете.

Здравствуйте, AlexRK, Вы писали:

ARK>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП.
С точки зрения ООП — да.
А ООП с точки зрения енумов — мутная концепция. Непонятно, зачем нужен тип данных, у которого может быть произвольное количество попарно различных экземпляров

ARK>Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов.
Ну, традиционные енумы как-то очень-очень ограничены. В том плане, что их взаимозаимозаменяемость в известных мне языках уж очень упрощена: либо всё совместимо со всем, либо ничего ни с чем.
А тем временем можно представить себе всякие интересные сценарии — типа сужения/расширения набора легальных значений — которые бы позволяли тайп чекеру отлавливать больше багов, чем можно сейчас.

ARK>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...
Ну, это у всего так. Невозможно эмулировать А на Б с сохранением того же удобства.
Хотя всё зависит от того, как енумы определены. Скажем, если бы енумов не было в джаве, можно было бы их эмулировать на основе класса с приватным конструктором и набором константных статик полей.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AlexRK, Вы писали:

ARK>>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП.
S>С точки зрения ООП — да.
S>А ООП с точки зрения енумов — мутная концепция. Непонятно, зачем нужен тип данных, у которого может быть произвольное количество попарно различных экземпляров

Ну вот когда появятся енум-ориентированные ЯП, тогда можно будет и это обсудить.

А в рамках ООП не зря многие "идеологи" пытаются выкинуть енум, это не на пустом месте. Но полностью адекватной замены лично я пока не вижу.

ARK>>Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов.
S>Ну, традиционные енумы как-то очень-очень ограничены. В том плане, что их взаимозаимозаменяемость в известных мне языках уж очень упрощена: либо всё совместимо со всем, либо ничего ни с чем.
S>А тем временем можно представить себе всякие интересные сценарии — типа сужения/расширения набора легальных значений — которые бы позволяли тайп чекеру отлавливать больше багов, чем можно сейчас.

Имеется в виду "наследование енумов"?

ARK>>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...
S>Ну, это у всего так. Невозможно эмулировать А на Б с сохранением того же удобства.
S>Хотя всё зависит от того, как енумы определены. Скажем, если бы енумов не было в джаве, можно было бы их эмулировать на основе класса с приватным конструктором и набором константных статик полей.

Да, но это уже неудобно, бойлерплейт.

Здравствуйте, WolfHound, Вы писали:

WH>Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
WH>Известна миллион лет.
WH>Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.

Увы, для защиты от этой атаки нужна дополнительная линия связи реалтайм, по которой пойдет дополнительный секрет. В сценарии общения по одному проводу, да еще в полуавтоматизированном режиме, защиты от нее нет, бо для обоих сторон удаленный подставной ендпоинт неотличим от оригинального. То бишь даже вариант заранее присланного по почте пароля не канает, ведь тот идет тоже через прокси. В общем не забываем, что в сценариях взлома всегда предполагается, что все алгоритмы известны.

WH>И такой протокол никогда не пройдет через нормального безопасника.

Татышо! Простой пример: ты входишь в SSH и тебя программа спрашивает, импортировать ли тот ключ с того IP, твои действия? А действия безопасника?
Не изобретай, кароч.

WH>И еще. Не стоит путать прослушивание с проксированием.

Стоит, стоит. Любой твой IP-трафик проходит десяток и больше ендпоинтов, прежде, чем попадет к цели.

WH>Ибо есть протоколы, защищающие от прослушивания, но не проксирования.

Относительно исходной темы об инфраструктуре — это слабые спекуляции.

WH>А есть протоколы, которые можно атаковать только через слабость алгоритмов шифрования.

Дык, сейчас уже сильных алгоритмов в опен-сорсе столько, что... Смотри хотя бы Crypto++ обертку... Да еще бывают для надежности накручивают шифрование многократно, возводя требуемое время для вскрытия в степень. Я в эту тему даже не хочу копать, нереал.

V>>Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.
WH>Короче очередной слив засчитан.

Короче, не компосируй мой процессор. Рядом уже подробно всё обсудили, сколько можно повторяться об одном и том же? Твои доводы, что "IOMMU будет мало" — очередные спекуляции чистой воды...

Здравствуйте, vdimas, Вы писали:

WH>>Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
WH>>Известна миллион лет.
WH>>Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.

V>Увы, для защиты от этой атаки нужна дополнительная линия связи реалтайм, по которой пойдет дополнительный секрет. В сценарии общения по одному проводу, да еще в полуавтоматизированном режиме, защиты от нее нет, бо для обоих сторон удаленный подставной ендпоинт неотличим от оригинального. То бишь даже вариант заранее присланного по почте пароля не канает, ведь тот идет тоже через прокси. В общем не забываем, что в сценариях взлома всегда предполагается, что все алгоритмы известны.

http://en.wikipedia.org/wiki/Public_key_infrastructure

Здравствуйте, vdimas, Вы писали:

V>Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

Мы, вроде бы, не про ФП и паттерны тут говорим, а обсуждаем явно не соотвествующее действительности утверждение "SmallTalk эти паттерны и даром не сдались, у тех свои паттерны". Подавляющее большинство паттернов GOF и прочих, вроде MVC, были придуманы смолтокерами и для Смолтока.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, FR, Вы писали:

FR>Польза очень даже извлекается, во первых оптимизация кода и перенос вычислений в compile time второе
FR>многопоточность.

Я не собираюсь утверждать, что пользы нет вообще, но от утверждения о том, что "польза извлекается сложно" не снимаю.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Иван Дубров, Вы писали:

ИД>http://en.wikipedia.org/wiki/Public_key_infrastructure

Увы и ах, военные не могут позволить себе полагаться на мифические независимые "достоверные центры", определяющие истинность сертификатов. Поэтому, система генерит аналоги сертификатов сама при регистрации конкретных "девайсов" (включая мобильные). Просто, если для проводных устройств можно хотя бы для регистрации подключать их в изолированную локальную сеть, то GSM траффик перехватывается таким же точно образом вообще на раз.

Ну и по твоей ссылке любопытно:

On July 10, 2011, a wildcard certificate was issued by DigiNotar's systems for Google by an attacker with access to their systems. This certificate was subsequently used by unknown persons in Iran to conduct a man-in-the-middle attack against Google services.[12][13] On August 28, 2011, certificate problems were observed on multiple Internet service providers in Iran.[14] The fraudulent certificate was posted on pastebin.[15] According to a subsequent news release by VASCO, DigiNotar had detected an intrusion into its certificate authority infrastructure on July 19, 2011.[16] DigiNotar did not publicly reveal the security breach at the time.

After this certificate was found, DigiNotar belatedly admitted dozens of fraudulent certificates had been created, including certificates for the domains of Yahoo!, Mozilla, WordPress and The Tor Project.[17] DigiNotar could not guarantee all such certificates had been revoked.[18] Google blacklisted 247 certificates in Chromium,[19] but the final known total of misissued certificates is at least 531.[20] Investigation by F-Secure also revealed that DigiNotar's website had been defaced by Turkish and Iranian hackers in 2009.[21]

Здравствуйте, Sinclair, Вы писали:

S>Что кагбэ подразумевает равноправность решений по убиранию const_cast и введению модификатора clean.

ХЗ, "пойти еще дальше" — никакая не равноправность. По крайней мере мне так казалось, когда я пользовался русским языком для написания поста.

V>>Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.
S>Я не очень понимаю, как вы собираетесь организовывать "участки кода со ссылочной прозрачностью", выходя за пределы одного метода.
S>Вот мы имеем, скажем,

S>

S>void foo(const int &x)
S>{
S>   cout << x; // 1
S>   bar();
S>   cout << x; // 2 
S>}
S>

S>Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

Нет.
Слушай, как ты вообще умудряешься такое предполагать? Для меня ход твоих мыслей по поводу const полнейшая загадка до сих пор, ей-богу... Мне даже уже надоело делать вид, как же я недоумеваю. ))

Кароч, давай медленно разбирать, что есть const, какова его семантика, и как правильно получать плюшки от этой семантики.

Вернемся к сааамому началу. Напомню, речь шла о передаче аргументов в паскале и оберонах и о введении ключевого слова CONST в обероны для экономии затрат на передачу аргументов.

Давай придумаем пример некоей ф-ии на мейнстримовом синтаксисе:

static int sum(int a, int b, int c, int d) {
  a += b;
  a += c;
  a += d;
  return a;
}

Несмотря на мутабельный императивный алгоритм, ф-ия sum чиста, как слеза ребенка, ведь переменная a — копия исходного аргумента. К тому же, любой компилятор в состоянии так протрассировать ход вычислений, что ему не нужен будет никакой фрейм локальных переменных и адрес переменной "a" из этого фрейма, он может тупо подставить одну инструкцию векторного модуля процессора и вернуть на выход результат эквивалентного выражения: a+b+c+d.

Теперь представь, что нам надо складывать не int, а многомерные вектора, получая, скажем, итоговый вектор сил в многомерном пространстве. Тогда передавать аргументы ПО ЗНАЧЕНИЮ окажется накладным, скорее всего (из-за объема копируемых данных), и будет смысл передавать исходные данные по ссылке. Скажем, для C# примерно так:

struct Vec { 
/* many projections */ 

static Vec operator+(...) {}.
};

static int sum(ref Vec a, ref Vec b, ref Vec c, ref Vec d) {
  a += b;
  a += c;
  a += d;
  return a;
}

Упс... стоило передать не копии значений, а их ссылки, и ф-ия перестала быть чистой. Давай попробуем допилить C# до вменяемого состояния, добавим еще один модификатор in, то бишь пусть вместо модификаторов ref и out будут модификаторы ref in и ref out.

static int sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
  a += b;
  a += c;
  a += d;
  return a;
}

А вот этот код уже не скомпилится, потому что нарушает гарантии ref in. Поэтому код придется переписать так, чтобы гарантии не нарушались. Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).

Итого, мы обогатили синтаксис C# полезным ключевым словом, который предоставляет кое-какие гарантии вызывающему коду, за счет этого мы можем смело сэкономить на копировании аргументов, передавая их по ссылке. Идем далее. У структур могут быть методы/св-ва. Эти методы могут изменять значения полей структуры, а могут и нет. Мне бы хотелось некоторого контроля за тем, какие именно методы поданного по ссылке объекта с модификатором in я могу дергать, а какие нет. Кому как, а мне модификатор in для методов не нравится, кривовато:

struct Vec { 
  public int Dimentions { in get; set; }
};

Что если так:

struct Vec { 
  public int Dimentions { const get; set; }
};

Чуть лучше.

Делее — чистота.
Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
— нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
— аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:

clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}

Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.

Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".

Напомню так же, что я попытался этим clean развить понравившуюся мне мысль о "контроллируемой мутабельности". Т.е. мутабельность мне нужна, ес-но, но я хочу убежать от скрытой мутабельности, от непонятных сюрпрайзов во время работы программы.

=============
На остальное потом.

Дважды описка, читать так:

V>

V>static Vec sum(ref Vec a, ref Vec b, ref Vec c, ref Vec d) {
V>  ...
V>}
V>

Здравствуйте, Sinclair, Вы писали:

"Остальное осмотрел". Ключевые моменты ты все-равно скипнул, отвечать больше не на что.

S>Ну покажите же мне, какие оптимизации может делать компилятор при компиляции foo(const int& x) по сравнению с компиляцией foo(int& x).

Устал поправлять, речь всегда о гарантиях для вызывающего кода:

int x = 42;
foo(x);
std::cout << x;

Для разных вариантов foo будет сгенерен разный код. Для первого варианта будет такое:

foo(42);
std::cout << 42;

Для второго — исходный.

ИМХО, невооруженным взглядом видно, где тут работает ссылочная прозрачность.

Здравствуйте, Klapaucius, Вы писали:

K>И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?

Вот тут обрисовал как я использую const и для чего хотел бы иметь clean:
http://www.rsdn.ru/forum/philosophy/4838600.1.aspx

K>Да, с точностью до именования лексем, = использовать нельзя, это ключевое слово. Можно и короче — с += и прочим. Можно и вышеупомянутый x++ сделать, с той поправкой, что постфиксные операторы в хаскеле должны быть в скобках, т.е. (x++). Можно даже лучше, написать линзы, но не "функциональные", а с изменением по-месту, с помощью ST, а это, фактически, first-class l-values.

Ну... круто, если так. ))

Здравствуйте, FR, Вы писали:

FR>Если брать D в котором нечто подобное уже реализовано http://dlang.org/function.html#pure-functions то все очень жестко
FR>

FR>does not read or write any global or static mutable state
FR>cannot call functions that are not pure
FR>can override an impure function, but an impure function cannot override a pure one
FR>is covariant with an impure function
FR>cannot perform I/O

Именно оно!!!

Тааак... походу зря D обходят вниманием... по крайней мере я зря обхожу... ))
А каковы прогнозы насчет готовности D2?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Иван Дубров, Вы писали:

ИД>>http://en.wikipedia.org/wiki/Public_key_infrastructure

V>Увы и ах, военные не могут позволить себе полагаться на мифические независимые "достоверные центры", определяющие истинность сертификатов.

В смысле -- не могут? Почему они не могут завести свои CA и подписывать своими ключами ключи своих устройств?

При этом даже если полагаться на сторонние CA (например, для установления первоначального защищённого соединения по которому уже будет передана информация о своём CA), это всё равно будет безопаснее, чем просто передавать публичный ключ устройства.

V>Поэтому, система генерит аналоги сертификатов сама при регистрации конкретных "девайсов" (включая мобильные). Просто, если для проводных устройств можно хотя бы для регистрации подключать их в изолированную локальную сеть, то GSM траффик перехватывается таким же точно образом вообще на раз.

Я уверен, можно придумать множество вариантов, более защищённых чем то, что ты описал (просто обменяться публичными ключами). Если это потребуется.

V>Ну и по твоей ссылке любопытно:
V>

V>On July 10, 2011, a wildcard certificate was issued by DigiNotar's systems for Google by an attacker with access to their systems. This certificate was subsequently used by unknown persons in Iran to conduct a man-in-the-middle attack against Google services.[12][13] On August 28, 2011, certificate problems were observed on multiple Internet service providers in Iran.[14] The fraudulent certificate was posted on pastebin.[15] According to a subsequent news release by VASCO, DigiNotar had detected an intrusion into its certificate authority infrastructure on July 19, 2011.[16] DigiNotar did not publicly reveal the security breach at the time.

V>After this certificate was found, DigiNotar belatedly admitted dozens of fraudulent certificates had been created, including certificates for the domains of Yahoo!, Mozilla, WordPress and The Tor Project.[17] DigiNotar could not guarantee all such certificates had been revoked.[18] Google blacklisted 247 certificates in Chromium,[19] but the final known total of misissued certificates is at least 531.[20] Investigation by F-Secure also revealed that DigiNotar's website had been defaced by Turkish and Iranian hackers in 2009.[21]

А что тут любопытного? Слишком много CA, которым устройства доверяют "по умолчанию" (прописаны во всех браузерах, например), и которые могут быть скомпроментированы. В случае если нужно построить прям совсем защищённую сеть, можно развернуть свою PKI. При этом, в любом случае, man-in-the-middle атака существенно проще, чем украсть ключ одного из CA.

> I>Лучше бы ты матом высказался, это, по крайней мере, честно было бы.
> Не хочу уподобляться оппоненту, несмотря на троллинг и провокации с его стороны.

Стоит заметить, что вы с vdimas почти полное подобие. Забавно наблюдать, что у вас даже получается некоторое общение

Posted via RSDN NNTP Server 2.1 beta

> Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...

Сказочки в стиле Мышъх-а.
Читай несимметричное шифрование. Ты не можешь имитировать другую сторону или подменять пакеты не зная что в передаваемых пакетах и не можешь расшифровать пакеты, проксирование тебе в этом никак не поможет, ибо. Тебе правильно ссылку на википедию дали

Не бывает такого в военных системах, не надо ля-ля.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>ХЗ, "пойти еще дальше" — никакая не равноправность. По крайней мере мне так казалось, когда я пользовался русским языком для написания поста.
Ладно, я отвечу. Но это — в последний раз.

S>>

S>>void foo(const int &x)
S>>{
S>>   cout << x; // 1
S>>   bar();
S>>   cout << x; // 2 
S>>}
S>>

S>>Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

V>Нет.
V>Слушай, как ты вообще умудряешься такое предполагать?
Ну это же вы утверждали, что const нам поможет для ссылочной прозрачности. Вот я пытаюсь применить её определение.

V>Кароч, давай медленно разбирать, что есть const, какова его семантика, и как правильно получать плюшки от этой семантики.

V>Теперь представь, что нам надо складывать не int, а многомерные вектора, получая, скажем, итоговый вектор сил в многомерном пространстве. Тогда передавать аргументы ПО ЗНАЧЕНИЮ окажется накладным, скорее всего (из-за объема копируемых данных), и будет смысл передавать исходные данные по ссылке. Скажем, для C# примерно так:

V>Упс... стоило передать не копии значений, а их ссылки, и ф-ия перестала быть чистой. Давай попробуем допилить C# до вменяемого состояния, добавим еще один модификатор in, то бишь пусть вместо модификаторов ref и out будут модификаторы ref in и ref out.
V>

V>static int sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
V>  a += b;
V>  a += c;
V>  a += d;
V>  return a;
V>}
V>

V>А вот этот код уже не скомпилится, потому что нарушает гарантии ref in. Поэтому код придется переписать так, чтобы гарантии не нарушались. Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).
Не очень понятно.

V>Итого, мы обогатили синтаксис C# полезным ключевым словом, который предоставляет кое-какие гарантии вызывающему коду, за счет этого мы можем смело сэкономить на копировании аргументов, передавая их по ссылке. Идем далее.
Не, далее мы не пойдём. Будем разбирать этот пример. Какие именно гарантии предоставляет ключевое слово in?
Вот, допустим, у меня такие методы:

private Vec _dong;
public fail()
{
   _dong = new Vec(...)
   var ding = _dong.DeepCopy();
   var oops = same(ref _dong);
   Debug.Assert(ding == _dong);
}
public same(ref in Vec a)
{
  _dong.Wipe();
  return a;
}

Как видим, ref in не помешало мне сломать гарантии компилятору.

V>Делее — чистота.
V>Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

V>Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
V>- нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
V>- аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

V>Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:
V>

V>clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}
V>

V>Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.
Конечно знаем — ни в каких нельзя.

V>Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".
Отлично, я так и думал. Именно поэтому я не хотел выкладывать сюда результаты моих медитаций — вы бы начали юлить и обвинять меня в том, что я за вас неправильно придумал ограничения на clean.

Давайте модифицируем пример вот так:

clean void fail(ref in Vec a, ref out Vec result, clean Action callback)
{
  result = a;
  callback();
}

Очевидно, что модификатор clean можно также распространять и на делегаты. По вашему определению, с fail всё в порядке — он вызывает только clean метод, с ref in аргументом ничего не делает, мутабельные статические поля не трогает.

Теперь вызовем его вот так:

var Vec test = new Vec(...);
var Vec test2;
fail(ref test, ref test2, ()=>{test.Wipe();} )
Debug.Assert(test == test2);

Наше замыкание — тоже вполне себе clean. Оно вызывает только один метод на test, который тоже clean — он меняет только this, а ведь он ничем не хуже, чем ref out result.
Таким образом, мы видим, что из clean компилятор тоже не может сделать ничего полезного.
Попробуйте изменить ограничения на clean метод — возможно, вы всё же получите какую-нибудь пользу

Здравствуйте, Sinclair, Вы писали:

V>>Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).
S>Не очень понятно.

Имелось ввиду такое:

static Vec sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
  Vec tmp = a;
  tmp += b;
  tmp += c;
  tmp += d;
  return tmp;
}

Теперь sum опять чиста, несмотря на всю мутабельность, если эта мутабельность не выходит за пределы ф-ии.

S>Не, далее мы не пойдём. Будем разбирать этот пример. Какие именно гарантии предоставляет ключевое слово in?

Такие, что конкретно эту переменную-аргумент вызываемый метод менять не может. Больше никаких. То бишь не вообще ссылаемое значение изменяться не может, а конкретно через эту ссылку.

S>Вот, допустим, у меня такие методы:
S>

S>private Vec _dong;
S>public fail()
S>{
S>   _dong = new Vec(...)
S>   var ding = _dong.DeepCopy();
S>   var oops = same(ref _dong);
S>   Debug.Assert(ding == _dong);
S>}
S>public same(ref in Vec a)
S>{
S>  _dong.Wipe();
S>  return a;
S>}
S>

S>Как видим, ref in не помешало мне сломать гарантии компилятору.

Да приводили уже аналогичный пример на Си и я показывал уже ошибку рассуждений. Еще до момента вызова same(ref _doing) была нарушена ссылочная прозрачность _doing. Тут нет исходной ссылочной прозрачности и ее некуда распространять. То бишь я, как программист (а заодно и компилятор) никаких выводов относительно значений _dong после вызова same() делать не будет.

А откуда ссылочная прозрачность появляется? Вопрос на мильон, а ответ простой — только в месте создания значения.

Надо было не присваивать new Vec куда-то во внешний мир (в д.с. поле по адресу this), и тогда цикл жизни этого созданного значения можно было бы трекать. После присвоения мемберу объекта и вызова неконстантных методов объекта — уже нельзя. Это же закон для const.

Надо было вызвать const-методы, но в нем ты бы не смог вызвать не-const метод переменной _dong, бо константность распространилась бы и на нее. Для замыканий все работает аналогично с распространением константности, boost::bind в пример.

V>>Делее — чистота.
V>>Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

V>>Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
V>>- нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
V>>- аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

V>>Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:
V>>

V>>clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}
V>>

V>>Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.
S>Конечно знаем — ни в каких нельзя.

В приведенном примере таки знаем достоверно.

V>>Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".
S>Отлично, я так и думал. Именно поэтому я не хотел выкладывать сюда результаты моих медитаций — вы бы начали юлить и обвинять меня в том, что я за вас неправильно придумал ограничения на clean.

S>Давайте модифицируем пример вот так:
S>

S>clean void fail(ref in Vec a, ref out Vec result, clean Action callback)
S>{
S>  result = a;
S>  callback();
S>}
S>

S>Очевидно, что модификатор clean можно также распространять и на делегаты. По вашему определению, с fail всё в порядке — он вызывает только clean метод, с ref in аргументом ничего не делает, мутабельные статические поля не трогает.

Да. Только, боюсь, вместо clean Action будет некий CleanAction с другой сигнатурой определения делегата — с модификатором clean.

S>Теперь вызовем его вот так:
S>

S>var Vec test = new Vec(...);
S>var Vec test2;
S>fail(ref test, ref test2, ()=>{test.Wipe();} )
S>Debug.Assert(test == test2);
S>

S>Наше замыкание — тоже вполне себе clean. Оно вызывает только один метод на test, который тоже clean — он меняет только this, а ведь он ничем не хуже, чем ref out result.

Абсолютно правильные рассуждения. Просто нужна толика внимательности: замыкание является clean, но не является const. Итого, мы опять передаем неконстантную ссылку на переменную test "куда-то", и после этого не можем гарантировать её константности. Как разработчику, так и компилятору это прекрасно известно. То бишь на плюсах я отлично отслеживаю подобные моменты, даже когда использую boost::bind для аналогичных сценариев. Просто в отсутствии clean их трекать приходится сугубо умозрительно, "вручную" соблюдая необходимые мне clean-гарантии.

S>Таким образом, мы видим, что из clean компилятор тоже не может сделать ничего полезного.

Может. Просто пользу надо уметь извлекать. Как именно — я показал в своих примерах в предыдущем посте. То бишь, если мне нужны гарантии, я делаю код таким, чтобы эти гарантии могли быть соблюдены. Коль речь об ООП, то модификатор const так же применяется к методам, в этом случае он означает const this внутри методов и распространяеся на значения всех полей и составных тоже рекурсивно.

S>Попробуйте изменить ограничения на clean метод — возможно, вы всё же получите какую-нибудь пользу

Не хочу! ))
См сюда: http://www.rsdn.ru/forum/philosophy/4836755.1.aspx

Бока ограничений на обязательную иммутабельность я уже описал:

исходный постулат о введении контроллируемой мутабельности в случае отдельных иммутабельных типов был бы полной профанацией всей идеи. То бишь вместо разделения алгоритмов на чистые и нечистые относительно одних и тех же данных (которые и есть "состояние" в ООП), было бы тупое разделение кода на две непересекающиеся по типам области. То бишь был бы эффект от двух плохосовместимых языков в одном исходнике, где надо было иметь кучу рукописного кода по копированию данных из одних типов в другие. Это не коснулось бы только простых типов данных и структур на их основе со всеми публично-видимыми полями, на которые компилятор способен распространить иммутабельность самостоятельно... но ведь мы обсуждали ООП.

То бишь мой вывод такой, что при введении гарантированной иммутабельности в том смысле как ты настаиваешь, когда модификатор приписывается не к переменной, а к типу как таковому, чтобы эти гарантии распространялись в любую сторону, а не только по направлению in вызываемых методов... в общем, в случае такой гарантированной иммутабельности оставаться в рамках парадигмы ООП будет банально неудобно. Вот и всё кино.

Здравствуйте, Klapaucius, Вы писали:

V>>Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

K>Мы, вроде бы, не про ФП и паттерны тут говорим, а обсуждаем явно не соотвествующее действительности утверждение "SmallTalk эти паттерны и даром не сдались, у тех свои паттерны". Подавляющее большинство паттернов GOF и прочих, вроде MVC, были придуманы смолтокерами и для Смолтока.

Ну дык, я постоянно в коде коллег вижу применение паттернов, основанных на парадигме адаптора (служить переходником м/у несовместимыми интерфейсами) и вижу, что в 99% случаев при наличии утиной типизации конкретные места в коде могут обходиться без этого адаптера. Но в случае статически-типизированной номативной типизации — не могут.

Здравствуйте, Sinclair, Вы писали:

S>>>>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?
V>>А как это организованно в виндах, понимаешь? Ну, чтобы я лишнего не писал.
S>Нет. Можно ссылку на MSDN?

msdn security descriptor overview

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379571%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379557%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374876%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379204%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379198%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374807%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379195%28v=vs.85%29.aspx

V>>Конкретно насчет WebRequest.Send(), артефакты безопасности будут переданы при вызове ниже и где-то будет просто уровень TCP-стека, к которому относятся несколько пунктов из политики и которые (эти пункты) будут проверяться в соотв, вызовах TCP. Т.е. модули, отвечающие за сетевой уровень, должны будут попасть внутрь пояса безопасности.
S>Что такое "внутрь"? Я правильно понимаю, что для вызова WebRequest.Send() мой прикладной модуль должен будет иметь у себя в "артефактах безопасности" пункты, разрешающие TCP/IP?
S>Если да — то это, простите, дыра.

)))
нет, прикладной модуль должен иметь внутри себя свой аналог дотнетным WindowsIdentity/WindowsPrincipal, а настройки для юзверов и групп хранятся и проверяются системой. Мне лишь надо расширить исходную модель Windows так, чтобы я мог подавать несколько principal, а перед выполнением охраняемой функциональности работала суперпозиция разрешений/запрещений всех поданных principal.

То бишь, скажем, некоторому юзверю кое-что не разрешено, но при работе конкретно через это приложение ему будет доступна некая функциональность, которую разрешит администратор. Если же будут вхождения deny для некоего приложения, то даже админ не сможет их преодолеть, зашедши иначально с аккаунтом с полным доступом ко всему и запустив это приложение, будь то удаленно или локально.

V>>В общем, какая-то часть системного кода должна быть доверенной всё-равно. Должна быть некая точка опоры, от которой мы отталкиваемся.
S>Вопрос — какая именно часть кода у вас доверенная. Вот, скажем, драйвер GSM-модема от 3rd-party — он доверенный или нет?

Вполне может быть нет, тогда обращения к этому драйверу пойдут через проксирование системой безопасности. Благо, все драйверы имеют один и тот же интерфейс, то бишь создать на-лету прокси будет несложно.

Здравствуйте, Иван Дубров, Вы писали:

V>>Увы и ах, военные не могут позволить себе полагаться на мифические независимые "достоверные центры", определяющие истинность сертификатов.

ИД>В смысле -- не могут? Почему они не могут завести свои CA и подписывать своими ключами ключи своих устройств?

Могут, но это надо делать централизовано. А система изначально предназначена для создания своей защищенной сети в интернет по миру. Ты же не может сгенерить пару ключей и послать пару по сети, правильно?))

Для отладки мне просто дали логин-пароль к ближайшему ноду регистрации, программа сгенерила все ключи, оставила закрытый себе и зарегистрировала "виртуальный девайс".

ИД>При этом даже если полагаться на сторонние CA (например, для установления первоначального защищённого соединения по которому уже будет передана информация о своём CA), это всё равно будет безопаснее, чем просто передавать публичный ключ устройства.

Вряд ли в таких делах будут полагаться на сторонние CA. ИМХО, когда речь о политике, то все эти вещи не работают. Они работают до тех пор, пока ты им доверяешь. А так ведь сторонний центр может быть частью сценария атаки.

V>>Поэтому, система генерит аналоги сертификатов сама при регистрации конкретных "девайсов" (включая мобильные). Просто, если для проводных устройств можно хотя бы для регистрации подключать их в изолированную локальную сеть, то GSM траффик перехватывается таким же точно образом вообще на раз.

ИД>Я уверен, можно придумать множество вариантов, более защищённых чем то, что ты описал (просто обменяться публичными ключами). Если это потребуется.

Все твои варианты сводятся к тому, чтобы обменяться публичными ключами по альтернативному, более доверенному каналу, и подписать ими свои ключи, а в момент обмена запрашивать те центры на достоверность подписи (они же не дадут нам закрытые ключи). Там вся возможная разница лишь в глубине рекурсии этой одной и той же операции.

ИД>А что тут любопытного? Слишком много CA, которым устройства доверяют "по умолчанию" (прописаны во всех браузерах, например), и которые могут быть скомпроментированы.

А вариант заведомо за несколько лет до взлома создания "правдоподобной" CA ты не учитываешь? Все эти CA — сплошной субъективизм.

ИД>В случае если нужно построить прям совсем защищённую сеть, можно развернуть свою PKI.

Можно, но если доступ к ней будет по тому же самому проводу, то man-in-the-middle можно применять на любой стадии. См. замечание насчет де-факто рекурсивности процесса.

Здравствуйте, grosborn, Вы писали:

G>Читай несимметричное шифрование. Ты не можешь имитировать другую сторону или подменять пакеты не зная что в передаваемых пакетах и не можешь расшифровать пакеты, проксирование тебе в этом никак не поможет, ибо. Тебе правильно ссылку на википедию дали

Не бывает такого в военных системах, не надо ля-ля.

Еще один "доктор по фотографии"...
Курить процедуру обмена ключами.

Здравствуйте, Sinclair, Вы писали:

V>>Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.
S>http://compgroups.net/comp.lang.oberon/enumeration-types/1433942
S>Я надеюсь, само собой понятно, что на нишевом языке никто, кроме фанатов, не пишет?

Не надейся. Это могут быть случайно залетевшие студенты, решившие поумничать. Фанаты не стали бы нести откровенной чуши, т.к. ее можно нести только не поняв уже имеющихся в языке ср-в.

V>>Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
V>>1. Эдакие юзверские алиасы для целочисленных типов.
V>>2. Константные значения этих типов.
S>Я не знаю, что именно вы называете мейнстримом.

Известный тебе дотнет пойдет? "Всё-таки я люблю шарп" (С)
Ну я еще упоминал С/С++ и считаю, что они тоже самый что ни на есть мейнстрим.

S>Скажем, енумы в Джаве сделаны сильно по-другому, чем енумы в Object Pascal aka Delphi.

Т.е., когда я говорил о раскраске enums в С++, я должен был иметь ввиду enums из Джавы? ))
И да, в Джаве можно объявлять обычные целочисленные enums практически c такой же семантикой, как в плюсах.

V>>Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.
S>Я улавливаю общий паттерн в вашей манере ведения спора. Вы утверждаете чушь (типа "енум это всего лишь алиас для целочисленного типа"), а потом из неё делаете глубокие выводы.

Я думаю, ты полностью потерял нить беседы:

V>- enum нет
Как это? Куда дели enum?
...
То, что в Обероне их нет — это, мягко говоря, не от большого ума.

Я тебе объясняю, что функциональность enum из мейнстрима в обероне доступна изкаробки. В джаве enums я бы не сказал, что так уж в мейнстриме, они появились недавно, когда основная масса кода популярных джавовских фреймворков уже написана.

V>>Пытаться натягивать set на enum — вот это ляп.
S>Я не понимаю, что значит "натягивать set на enum". Вы что, ещё и путаете Set type с enum type?

Я путаю?

Как это? Куда дели enum?
RTFM:
http://www.delphibasics.co.uk/Article.asp?Name=Sets

Это залет.

Здравствуйте, AlexRK, Вы писали:

ARK>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП. Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно,

Выглядит полезно из-за привносимой дополнительной типобезопасности вокруг интегральных значений.

ARK>однако фиг знает — может быть существует что-то получше енумов.

Существует — алиасинг типов.

ARK>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...

В плюсах можно эмулировать алиасинг без затрат в рантайм. Но муторно в исходнике: статические константы юзверских типов надо сначала объявить внутри класса, а потом проинициализировать вне класса. Такое дублирование раздражает.

> Еще один "доктор по фотографии"...
> Курить процедуру обмена ключами.

Очередной слив в вопросах безопасности засчитан.

Posted via RSDN NNTP Server 2.1 beta

> G>Читай несимметричное шифрование. Ты не можешь имитировать другую сторону или подменять пакеты не зная что в передаваемых пакетах и не можешь расшифровать пакеты, проксирование тебе в этом никак не поможет, ибо. Тебе правильно ссылку на википедию дали

Не бывает такого в военных системах, не надо ля-ля.
>
> Еще один "доктор по фотографии"...
> Курить процедуру обмена ключами.

Ты вообще-то прочитал бы википедию повнимательнее. Там в общем-то достаточно написано для понимания, что зная публичные ключи ты не можешь взломать систему проксированием.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

ИД>>В смысле -- не могут? Почему они не могут завести свои CA и подписывать своими ключами ключи своих устройств?

V>Могут, но это надо делать централизовано. А система изначально предназначена для создания своей защищенной сети в интернет по миру. Ты же не может сгенерить пару ключей и послать пару по сети, правильно?))

V>Для отладки мне просто дали логин-пароль к ближайшему ноду регистрации, программа сгенерила все ключи, оставила закрытый себе и зарегистрировала "виртуальный девайс".

У тебя и ноды регистрации был общий секрет, это уже позволяет организовать безопасный обмен ключами.

ИД>>Я уверен, можно придумать множество вариантов, более защищённых чем то, что ты описал (просто обменяться публичными ключами). Если это потребуется.

V>Все твои варианты сводятся к тому, чтобы обменяться публичными ключами по альтернативному, более доверенному каналу, и подписать ими свои ключи, а в момент обмена запрашивать те центры на достоверность подписи (они же не дадут нам закрытые ключи). Там вся возможная разница лишь в глубине рекурсии этой одной и той же операции.

ИД>>В случае если нужно построить прям совсем защищённую сеть, можно развернуть свою PKI.

V>Можно, но если доступ к ней будет по тому же самому проводу, то man-in-the-middle можно применять на любой стадии. См. замечание насчет де-факто рекурсивности процесса.

Ничего не понял.

Не надо ничего запрашивать. Никакие ключи никто никуда не отдаёт.

Пара ключей генерируется устройством один раз и подписывается CA. В этот момент будет нужен защищённый канал, который можно организовать разными способами (для передачи публичного ключа). Например, на основе знания общего секрета или поместив устройство физически рядом с CA. В первом варианте у злоумышленника не будет секрета и он не сможет упросить CA сгенерировать ему сертификат. Во втором случае, злоумышленник физически не сможет получить сертификат.

После этого, устройство может обмениваться с другими такими устройствами без участия CA и при этом оно будет уверенно в их подлинности (так как у них будут сертификаты), атака man-in-the-middle уже не пройдёт.

Здравствуйте, vdimas, Вы писали:

V>Увы, для защиты от этой атаки нужна дополнительная линия связи реалтайм, по которой пойдет дополнительный секрет. В сценарии общения по одному проводу, да еще в полуавтоматизированном режиме, защиты от нее нет, бо для обоих сторон удаленный подставной ендпоинт неотличим от оригинального. То бишь даже вариант заранее присланного по почте пароля не канает, ведь тот идет тоже через прокси. В общем не забываем, что в сценариях взлома всегда предполагается, что все алгоритмы известны.
Ох. Для защиты от этого достаточно один раз передать секрет по надежному каналу.
Те если действительно нужно, то можно просто передать флешку или записку с курьером.

V>Татышо! Простой пример: ты входишь в SSH и тебя программа спрашивает, импортировать ли тот ключ с того IP, твои действия? А действия безопасника?
Он еще фингерпринты ключа говорит.
А этого уже достаточно для того чтобы проверить подлинность ключа.
И дальше, сколько не проксируй ничего ты сделать не сможешь.

V>Не изобретай, кароч.
Да я не изобретаю.
Просто ты ничего не знаешь.

WH>>Ибо есть протоколы, защищающие от прослушивания, но не проксирования.
V>Относительно исходной темы об инфраструктуре — это слабые спекуляции.
Это не спекуляции. Это факты. И о них знает любой, кто хоть немного криптографией интересовался.

WH>>А есть протоколы, которые можно атаковать только через слабость алгоритмов шифрования.
V>Дык, сейчас уже сильных алгоритмов в опен-сорсе столько, что... Смотри хотя бы Crypto++ обертку... Да еще бывают для надежности накручивают шифрование многократно, возводя требуемое время для вскрытия в степень. Я в эту тему даже не хочу копать, нереал.
Всё это в мою пользу.
Ибо я и о том и говорю, что хрен сломаешь.

V>Короче, не компосируй мой процессор. Рядом уже подробно всё обсудили, сколько можно повторяться об одном и том же? Твои доводы, что "IOMMU будет мало" — очередные спекуляции чистой воды...
"IOMMU будет мало" это ТВОИ доводы. Причем они ничем не подкреплены.
Мои доводы, что IOMMU будет достаточно, чтобы защититься от всех драйверов кроме драйвера винта.
Итого нужно сертифицировать всего два типа драйверов.
А не абсолютно весь софт как в бутылке.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Могут, но это надо делать централизовано.
И?

V>А система изначально предназначена для создания своей защищенной сети в интернет по миру. Ты же не может сгенерить пару ключей и послать пару по сети, правильно?))
Если у меня есть логин, пароль и публичный ключ (или его фингерпринты) CA не никаких проблем зарегистрировать у него свой публичный ключ.

V>Для отладки мне просто дали логин-пароль к ближайшему ноду регистрации, программа сгенерила все ключи, оставила закрытый себе и зарегистрировала "виртуальный девайс".
А в программе случайно не был зашит публичный ключ CA?
Ибо если был и программа им правильно пользовалась то все твои спекуляции летя в мусор.

V>А вариант заведомо за несколько лет до взлома создания "правдоподобной" CA ты не учитываешь? Все эти CA — сплошной субъективизм.
Если CA свой. И его PK зашит в программу. То нет никаких проблем.
А в случае с военными наверняка так оно и есть.

V>Можно, но если доступ к ней будет по тому же самому проводу, то man-in-the-middle можно применять на любой стадии. См. замечание насчет де-факто рекурсивности процесса.
Очередная демонстрация непонимания предмета.
Не надоело позориться?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

V>>Увы, для защиты от этой атаки нужна дополнительная линия связи реалтайм, по которой пойдет дополнительный секрет. В сценарии общения по одному проводу, да еще в полуавтоматизированном режиме, защиты от нее нет, бо для обоих сторон удаленный подставной ендпоинт неотличим от оригинального. То бишь даже вариант заранее присланного по почте пароля не канает, ведь тот идет тоже через прокси. В общем не забываем, что в сценариях взлома всегда предполагается, что все алгоритмы известны.
WH>Ох. Для защиты от этого достаточно один раз передать секрет по надежному каналу.
WH>Те если действительно нужно, то можно просто передать флешку или записку с курьером.

Дык, о чем и речь. Я сразу об этом и сказал — нереальный сценарий. Передать-то надо на другой конец земного шара.

V>>Татышо! Простой пример: ты входишь в SSH и тебя программа спрашивает, импортировать ли тот ключ с того IP, твои действия? А действия безопасника?
WH>Он еще фингерпринты ключа говорит.
WH>А этого уже достаточно для того чтобы проверить подлинность ключа.

Какую в опу подлинность, если мне прямо здесь и сейчас кто-то открыл SSH на совершенно новую машинку? Ну вот надо по работе?
Там просто генерят пару ключей перед первым запуском sshd и на этом вся настройка заканчивается. Мало кто (да фактически никто) не выписывает себе сертификаты.

V>>Не изобретай, кароч.
WH>Да я не изобретаю.
WH>Просто ты ничего не знаешь.

Просто ты живешь в виртуальном мире.

Здравствуйте, WolfHound, Вы писали:

V>>Могут, но это надо делать централизовано.
WH>И?

И доступно только по проводу.

V>>А система изначально предназначена для создания своей защищенной сети в интернет по миру. Ты же не может сгенерить пару ключей и послать пару по сети, правильно?))
WH>Если у меня есть логин, пароль и публичный ключ (или его фингерпринты) CA не никаких проблем зарегистрировать у него свой публичный ключ.

Публичный ключ СА содержится в инсталляхе программки, которую скачиваешь по сети. Программа для мобилы. Подменили ему ключ СА, он регистрирует свои ключи у нас, а мы дальше сквозняком шлем хеши от секретов в первоначальный СА. Твои действия?

V>>Для отладки мне просто дали логин-пароль к ближайшему ноду регистрации, программа сгенерила все ключи, оставила закрытый себе и зарегистрировала "виртуальный девайс".
WH>А в программе случайно не был зашит публичный ключ CA?

Дык, ес-но был.

WH>Ибо если был и программа им правильно пользовалась то все твои спекуляции летя в мусор.

Да пусть пользуется. Только не факт что тем ключем.

V>>А вариант заведомо за несколько лет до взлома создания "правдоподобной" CA ты не учитываешь? Все эти CA — сплошной субъективизм.
WH>Если CA свой. И его PK зашит в программу. То нет никаких проблем.
WH>А в случае с военными наверняка так оно и есть.

Это я отвечал чтобы отмести варианты сторонних центров сразу. Любой нод-прокси и есть CA в этой инфраструктуре. В программу жестко вшит список нодов и их аттрибутов. Только вот сама программа ползет так же по сети. А помня свою юность, для вскрытия программ даже исходники не нужны... Тем более для линуховых программ, где все линкуемые символы на виду.

V>>Можно, но если доступ к ней будет по тому же самому проводу, то man-in-the-middle можно применять на любой стадии. См. замечание насчет де-факто рекурсивности процесса.
WH>Очередная демонстрация непонимания предмета.
WH>Не надоело позориться?

Похоже ты не понял насчет "любой стадии".

Здравствуйте, grosborn, Вы писали:

G>Ты вообще-то прочитал бы википедию повнимательнее. Там в общем-то достаточно написано для понимания, что зная публичные ключи ты не можешь взломать систему проксированием.

Ну... ты уже близок к понимаю проблематики..
Что по-твоему означает "знать публичные ключи"? На память, что ле? )))
Ты их получаешь по точно такому же проводу, как отдаешь свои. Это было сказано изначально.

Здравствуйте, vdimas, Вы писали:

V>Публичный ключ СА содержится в инсталляхе программки, которую скачиваешь по сети. Программа для мобилы. Подменили ему ключ СА, он регистрирует свои ключи у нас, а мы дальше сквозняком шлем хеши от секретов в первоначальный СА. Твои действия?

Как подменили? В коде программы? Ну так и всю программу можно подменить. Если ты не можешь гарантировать доставку программу, то ты вообще ничего не можешь гарантировать, дальше уже можно и не вспоминать про криптографию.

Если же для скачивания всё-таки используются публичные CA, зашитые в устройство, то подменить программу будет достаточно сложно. И если её таки НЕ подменят, дальнейшее взаимодействие можно организовать защищённым образом, а не просто отправлять публичный ключ в надежде, что его не перехватят и не передадут другой.

> G>Ты вообще-то прочитал бы википедию повнимательнее. Там в общем-то достаточно написано для понимания, что зная публичные ключи ты не можешь взломать систему проксированием.
>
> Ну... ты уже близок к понимаю проблематики..
> Что по-твоему означает "знать публичные ключи"? На память, что ле? )))
> Ты их получаешь по точно такому же проводу, как отдаешь свои. Это было сказано изначально.

И тут ты (внезапно!) начинаешь понимать, что система организационно предусматривает гарантированную доставку открытых ключей

Это написано в википедии. Это везде написано. Это обязательное условие всех таких систем, даже не военных. Это знает даже двоешник безопасник, но не знает vdimas.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Иван Дубров, Вы писали:

ИД>Как подменили? В коде программы? Ну так и всю программу можно подменить. Если ты не можешь гарантировать доставку программу, то ты вообще ничего не можешь гарантировать, дальше уже можно и не вспоминать про криптографию.
+1

ИД>Если же для скачивания всё-таки используются публичные CA, зашитые в устройство, то подменить программу будет достаточно сложно. И если её таки НЕ подменят, дальнейшее взаимодействие можно организовать защищённым образом, а не просто отправлять публичный ключ в надежде, что его не перехватят и не передадут другой.
Или же еще проще. Программу закачивают не по сети, а админы перед выдачей устройства.
Ну, или не программу, а ключ единственного доверенного CA. После чего программу можно спокойно скачивать через любую сеть.

Короче это всё настолько просто, что даже скучно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

WH>>Ох. Для защиты от этого достаточно один раз передать секрет по надежному каналу.
WH>>Те если действительно нужно, то можно просто передать флешку или записку с курьером.
V>Дык, о чем и речь. Я сразу об этом и сказал — нереальный сценарий. Передать-то надо на другой конец земного шара.
Реальный. Особенно в случае с военными. Было бы желание.

V>Какую в опу подлинность, если мне прямо здесь и сейчас кто-то открыл SSH на совершенно новую машинку? Ну вот надо по работе?
V>Там просто генерят пару ключей перед первым запуском sshd и на этом вся настройка заканчивается. Мало кто (да фактически никто) не выписывает себе сертификаты.

The authenticity of host 'rsdn.ru (95.31.13.136)' can't be established.
RSA key fingerprint is cf:9d:39:35:20:3c:bf:7b:33:d3:3c:21:32:33:c2:0e.
Are you sure you want to continue connecting (yes/no)?

Выделенное видишь?
Это фингерпринт. Для того чтобы убедится в подлинности сервера нужно его сверить.

При этом ни какие CA не нужны.

V>Просто ты живешь в виртуальном мире.
Это ты не понимаешь, что такое ssh и как им пользоваться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

V>Известный тебе дотнет пойдет? "Всё-таки я люблю шарп" (С)
V>Ну я еще упоминал С/С++ и считаю, что они тоже самый что ни на есть мейнстрим.
Тогда и пишите "в С и С++", а не в мейнстриме.
V>Т.е., когда я говорил о раскраске enums в С++, я должен был иметь ввиду enums из Джавы? ))
Вы должны были говорить о раскраске enums в С++. Потому что джава — самый что ни на есть мейнстрим. И на Дельфи тоже наколбашено довольно много кода — на его фоне обероном, скажем, можно пренебречь.
V>И да, в Джаве можно объявлять обычные целочисленные enums практически c такой же семантикой, как в плюсах.
В Джава есть ровно один способ объявлять енумы, и их семантика другая, чем в плюсах. Прекратите нести чушь.

V>Я тебе объясняю, что функциональность enum из мейнстрима в обероне доступна изкаробки. В джаве enums я бы не сказал, что так уж в мейнстриме, они появились недавно, когда основная масса кода популярных джавовских фреймворков уже написана.
Они там были всю жизнь, просто их в своё время несколько расширили для большего удобства. Они никогда не были синонимами целых типов.

V>>>Пытаться натягивать set на enum — вот это ляп.
S>>Я не понимаю, что значит "натягивать set на enum". Вы что, ещё и путаете Set type с enum type?

V>Я путаю?
V>

V>Как это? Куда дели enum?
V>RTFM:
V>http://www.delphibasics.co.uk/Article.asp?Name=Sets

V>Это залет.
Цитирую самый первый параграф по указанной ссылке:

Enumerations
The provision of enumerations is a big plus for Delphi. They make for readable and reliable code. An enumeration is simply a fixed range of named values. For example, the Boolean data type is itself an enumeration, with two possible values : True and False. If you try to assign a different value to a boolean variable, the code will not compile.

Что я могу сказать? Это залёт. Заодно это мой последний пост вам в ответ — не вижу смысла спорить с человеком, неспособным на клик мышкой.

Здравствуйте, WolfHound, Вы писали:

WH>Выделенное видишь?
WH>Это фингерпринт. Для того чтобы убедится в подлинности сервера нужно его сверить.

Татышо )))
А ты хоть раз в жизни его сверял?

Кароч, мистер всезнайка:
1. Это выдается только в одном из сценариев настройки, когда StrictHostKeyChecking=ask;
2. В другом сценарии, когда StrictHostKeyChecking=no идет просто обмен ключами и ключ сервера у тебя молча оседает;
3. А когда действительно надо защититься, то вообще никакого получения ключа сервера НЕТ. StrictHostKeyChecking=yes

Тебе сделают на машине другие чуть другие настройки и ты не вспомнишь, первый раз ты на хост заходишь или уже заходил, уже сверял отпечаток, уже соглашался и ключ сервера осел у тебя в базе.

WH>При этом ни какие CA не нужны.

V>>Просто ты живешь в виртуальном мире.
WH>Это ты не понимаешь, что такое ssh и как им пользоваться.

Я тебе показываю как оно есть на самом деле, бо пользуюсь SSH по работе почти ежедневно. Иногда приходится делать 2 проброса портов через 3 SSH-ноды, и комбинаторных сценариев настроек там бывает прилично... А не как ты в Вики что-то такое прочел и теперь блещешь своей наивностью относительно запроса отпечатка...

Здравствуйте, grosborn, Вы писали:

>> Что по-твоему означает "знать публичные ключи"? На память, что ле? )))
>> Ты их получаешь по точно такому же проводу, как отдаешь свои. Это было сказано изначально.

G>И тут ты (внезапно!) начинаешь понимать, что система организационно предусматривает гарантированную доставку открытых ключей

Это написано в википедии. Это везде написано. Это обязательное условие всех таких систем, даже не военных. Это знает даже двоешник безопасник, но не знает vdimas.

Дык, я на том спервого поста и фокусирую, что от инфраструктуры зависит, а ты прямо сейчас юлить как уж на сковородке изволишь. Я же вижу, как от поста к посту растет твоя эрудиция. В принципе это неплохо само по себе, но ты же, негодник, прямо сейчас пытаешься поймать меня не на том, на чем хотел изначально. Наблюдать за этим забавно. ))

И да, пример реально происходящего вокруг SSH я рядом приводил. Ознакамливайся, корми свою эрудицию.

Здравствуйте, Sinclair, Вы писали:

S>Что я могу сказать? Это залёт. Заодно это мой последний пост вам в ответ — не вижу смысла спорить с человеком, неспособным на клик мышкой.

Коль не умеешь оформлять ссылки, кто доктор? Давать ссылки без аннотаций вообще моветон сам по себе... Мы же не слепые, на ссылке было написано: ...Article.asp?Name=Sets

Правильная ссылка выглядит так:
Enumerations, SubRanges and Sets

Здравствуйте, vdimas, Вы писали:

V>А ты хоть раз в жизни его сверял?
Сверял.

V>Кароч, мистер всезнайка:
V>1. Это выдается только в одном из сценариев настройки, когда StrictHostKeyChecking=ask;
И что же мне мешает, помешает иметь эту настройку?

V>Тебе сделают на машине другие чуть другие настройки и ты не вспомнишь, первый раз ты на хост заходишь или уже заходил, уже сверял отпечаток, уже соглашался и ключ сервера осел у тебя в базе.
И кто же мне сделает другие настройки?

Плюс ты еще не забыл, что мы говорим про защищенное соединение вообще, а не про SSH конкретно?

Короче ты в очередной раз начал всех учить и слил.
Теперь крутишься.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

> G>И тут ты (внезапно!) начинаешь понимать, что система организационно предусматривает гарантированную доставку открытых ключей

Это написано в википедии. Это везде написано. Это обязательное условие всех таких систем, даже не военных. Это знает даже двоешник безопасник, но не знает vdimas.
>
> Дык, я на том спервого поста и фокусирую, что от инфраструктуры зависит, а ты прямо сейчас юлить как уж на сковородке изволишь.

Чего-чего? Ну давай я тебя прямо спрошу, если ты в этой ситуации не можешь двух слов связать. В той описываемой тобой военной системе, предусмотрен ли организационно или технически безопасный обмен ключами или хотя бы их гарантированная доставка? Возможные варианты ответов:

1. Да
2. Нет
3. Не знаю
4. Не могу точно сказать, у меня нет таких данных

И что бы у тебя не было возможности ответить полуправдой, "система", это вся система, а не только тот код который ты смотрел. Включая инструкции пользователям или документация как у них там. Ответ 2. принимается, если ты точно знаешь, что они пересылают ключи "через пол земного шара по интернету" или там по каким-то проводам. Готов поверить на слово, но хочется услышать это от тебя. И опять же что бы не было полуправды и иносказаний, ответ 2. Нет — должны быть известные тебе примеры реального использования (не тестового) именно в таком режиме.
Тебе осталось только выбрать циферку, это тебя не затруднит?

(Я думаю ты уже и сам давно понял, что написал ерунду, но признавать это не хочешь. и скорее всего не признаешь.)

> Я же вижу, как от поста к посту растет твоя эрудиция.

Как она может расти, если я уже последнее время ничего не читаю, некоторые перспективные вещи забросил, отстаю от жизни, тупею и деградирую.

> В принципе это неплохо само по себе, но ты же, негодник, прямо сейчас пытаешься поймать меня не на том, на чем хотел изначально. Наблюдать за этим забавно. ))

Перечитай посты еще раз медленно. Я тебе сразу сказал, что ты написал сказочку в стиле Мышъха по лом системы. И я тебя ни на чем не ловлю, мы уточняем кто был неправ, ты или та система сделана безграмотно. Но поверить что военную систему создавали с нарушением базовых (! даже я это понимаю) принципов, это как-то трудно. Значительно проще предположить что это ты тут прогнал.

> И да, пример реально происходящего вокруг SSH я рядом приводил. Ознакамливайся, корми свою эрудицию.

Ты о чем конкретно? Ты вроде бы про SSH ничего не писал. И какое отношение это имеет к твоим сказочкам про лом военной системы? Сдается мне ты опять пытаешься увести в сторону. Давай меньше слов плиз? мне реально трудно читать все что ты пишешь, без обид. Готов признать, что как писатель ты невероятно продуктивен.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Выглядит полезно из-за привносимой дополнительной типобезопасности вокруг интегральных значений.

Да, именно так.

V>Существует — алиасинг типов.

Поясните, пожалуйста, о чем речь. В моем представлении алиасинг — это просто назначение типу другого имени.

V>Но муторно в исходнике

Да вот о чем и речь.

C>>Оберонкоре — это собрание неграмотных фриков, у половины из которых идеология: "да я 40 лет крутил этот болт ключом на 15!" Ещё там есть несколько невинных жертв этих фриков, которые пытаются что-то делать с использованием технологий, которые им навязали.

C>>О современном состоянии в разработке ПО там и близко не знают.

Кстати, форум оберонкоре не статичен и, если можно так сказать, развивается. В частности там постепенно стала главенствовать идеалогия а не технология. Модераторы начали резать всех кто говорит что-то против в идеалогическом плане. В результате люди, которые хоть сколь-нибудь грамотные и думающие, оттуда ушли и создали свой форум: http://oberspace.dyndns.org/ Естественно обсуждение Оберона плавно начало перетекать на новый форум, даже не смутьяны начали регистрироваться на новом форуме, ибо интересно же. C этим надо было что-то делать...

В результате на оберонкоре были приняты новые, более жесткие правила форума. В числе них замечательное правило 1.2:
> 2. На конференции запрещено размещение ссылок или прочей информации справочного/рекламного характера на
> идеологически несовместимые ресурсы (глобально) и ресурсы, содержимое которых не имеет ничего общего
> с тематикой (в соответствующем разделе конференции).

с помощью этого пункта правил модераторы вырезают любые ссылки и упоминания оберспейса (видимо чтобы народ не утекал).

Такое ощущение, что на оберонкоре оный Оберон это уже не столько язык, сколько религия

PS. На текущий момент на оберонкоре обсуждения вопросов связанных с Обероном практически не ведется, в основном там тусуются драконопоклонники, дракон обсуждают. Так что можно смело оберонкоре переименовывать в драконкоре, или логово Дракона.

Здравствуйте, grosborn, Вы писали:

G>Перечитай посты еще раз медленно. Я тебе сразу сказал, что ты написал сказочку в стиле Мышъха по лом системы. И я тебя ни на чем не ловлю, мы уточняем кто был неправ, ты или та система сделана безграмотно. Но поверить что военную систему создавали с нарушением базовых (! даже я это понимаю) принципов, это как-то трудно. Значительно проще предположить что это ты тут прогнал.

Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. Уже было сказано, что ключи вшиты в прогу жестко. Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю. В отличие от.

По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... опять и снова показав, что дыра всегда в инфраструктуре.

Кароч, хоть ты сейчас и пытаешься делать вид, что что-то знал и понимал с самого начала — поздно, все ходы записаны. Каждый твой пост как буд-то не имеет связи с предыдущим, а весь смысл можно заменить на "Баба Яга против!". Дык, ради бога, я во всей этой теме как раз таких пациентов и собрал для беседы... мне нужно было от них, чтобы они шевелили процессором и делились результатами. Но от тебя, увы, толку нет. Ты больше спрашиваешь, чем делишься инфой. Бесполезен, сорри. Что я хотел показать этим примером — я уже показал. Но не тебе, ес-но. Будь ты хоть чуть внимательней, то увидел бы, что посты оппонентов лишь подтверждают мой исходный тезис насчет инфраструктуры.

G>Ты о чем конкретно? Ты вроде бы про SSH ничего не писал.

Рядом в этой же ветке писал насчет реальных происходящих сценариев в SSH. Читай.

G>И какое отношение это имеет к твоим сказочкам про лом военной системы?

Нет никаких сказок, это жизнь. Реально я не ломал и не собираюсь. Но если регистрация устройств будет проходить по тому же сценарию, как прошел я — то сломать вполне реально. Другое дело — зачем? Скажем так, некоторые знакомые "ломатели" до сих пор живут непонятно где и не отсвечивают. Оно мне надо?

G>Сдается мне ты опять пытаешься увести в сторону. Давай меньше слов плиз? мне реально трудно читать все что ты пишешь, без обид. Готов признать, что как писатель ты невероятно продуктивен.

Сдается мне, что ты здесь вообще непонятно что делаешь в кач-ве писателя. Лучше читай и запоминай.

> Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться.

Как некрасиво ты себя ведешь. Не побоюсь сказать уже все давно поняли твой залет, а ты все изображаешь разбирающегося в теме.

> Уже было сказано, что ключи вшиты в прогу жестко.

Напомню тебе твои же слова: "При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи". Это противоречит "вшиты в прогу жестко", если ты не понял.

Кароч, может ты все-таки почитаешь про шифрование, безопасность? Ключи генерируются парами — открытый и закрытый, если что. я тебе в первых строках упомянул несимметричное шифрование. RTFM в общем.

Но даже предположим ключиты вшиты, ты думаешь это дает тебе возможность взломать систему? Прослушать — да, управлять — нет.

Пока вместо ответов какие-то финты, балеринка ты наша.

> Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю.

Мне ты это зачем писал? Мне все-равно на это. У меня было маленькое замечание, ты мог просто признать свою ошибку и получать фан дальше, но ты предпочитаешь продолжать лажаться в теме.

> По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... опять и снова показав, что дыра всегда в инфраструктуре.

Ну... ты вообще способен на теме диалога сосредоточиться? Ну зачем опять это вранье и хвастовство?

<...болтовня какая-то скипнута...>

> Сдается мне, что ты здесь вообще непонятно что делаешь в кач-ве писателя. Лучше читай и запоминай.

Что запоминать, твои сказочки? Нафиг?
Извини, но ты болтлив не по сути вопроса и постоянно уводишь диалог куда-то в сторону и не отвечаешь на вопросы. Я понимаю, это форум и люди приходят пообщаться, но все-равно должны быть какие-то рамки. Твой стиль нереально напрягает.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Sinclair, Вы писали:

Кстати, до меня только сейчас дошло, почему я не могу воткнуть в ход твоих мыслей, а ты в ход моих.

В своих примерах ты пытаешься защищать иммутабельность. А я так даже вопрос ставить для себя не могу, поэтому не мог понять, что тебе непонятно. Фигли иммутабельность защищать-то? Прямо при создании/объявлении значения присвой ему const и оно будет заведомо защищено (если не придираться к хакам в современном С++). Или так разработай интерфейс объекта в ОО-программе, чтобы после создания объект был иммутабельным до конца своей жизни (это возможно даже на C# без const). То бишь, в плане иммутабельности никакой проблемы, ес-но, НЕТ. Защищать надо всегда мутабельное состояние, а не иммутабельное. "Контроллируемая мутабельность" именно это и означает, что я (и компилятор) смогут трекать происходящее с мутабельными данными в программе и быть уверенными в происходящем. В этом смысле const поможет проконторллировать, что конкретно по этой ссылке значение не изменят, а clean даст гарантии для неконстантных ссылок, что их не запомнят в каком-нить ненаблюдаемом, с т.з. вызывающего, контексте, и не будут дергать затем запомненное по ссылке значение одновременно с целевым императивным алгоритмом... который в этом случае перестаёт быть "контроллируемым".

Здравствуйте, vdimas, Вы писали:

V>В своих примерах ты пытаешься защищать иммутабельность. А я так даже вопрос ставить для себя не могу, поэтому не мог понять, что тебе непонятно. Фигли иммутабельность защищать-то?
Наивность, граничащая с некомпетентностью.
Я ещё раз поясняю: компилятор с раздельной компиляцией, не выполняя global flow analysis, не в состоянии извлечь из этой вашей "иммутабельности" ничего полезного. Именно из-за того, что ему неизвестно, ссылается ли переданная в данный фрагмент ссылка на const реально ссылкой на const или ссылкой на mutable.
А при выполнении global flow analysis компилятору совершенно наплевать на ваши ручные аннотации — он и так увидит, где имеет место ссылочная прозрачность, а где — нет.
Что тут непонятно?

Здравствуйте, Sinclair, Вы писали:

Ладно, я ошибся. Проблема была не в этом...

Выходит, тот момент, где есть возникновение, а где распространение ссылочной прозрачности, оказался тебе не по зубам даже после разжевать и в рот положить... Казалось бы, показал как правильно пользоваться обсуждаемым инструментарием... ан нет... Смотришь в код и плаваешь в 3-х строчках, даже в собственных примерах...

Т.е. принятые в языке D концепции тебе, понятное дело, всё еще непонятны и бесполезны, с твоих же слов... ))
Ну ок, не смею больше беспокоить.

Здравствуйте, AlexRK, Вы писали:

V>>Существует — алиасинг типов.
ARK>Поясните, пожалуйста, о чем речь. В моем представлении алиасинг — это просто назначение типу другого имени.

Я имею ввиду получение нового типа вместе с новым идентификатором. Ес-но typedef из C++ или using Identifier1 = Identifier2 из C# этим св-вом не обладают.

Здравствуйте, grosborn, Вы писали:

>> Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться.
G>Как некрасиво ты себя ведешь. Не побоюсь сказать уже все давно поняли твой залет, а ты все изображаешь разбирающегося в теме.

Я не знаю, кто там и что понял на уровне вики. Всё что было понято — они уже написали и я уже отвечал. Или у оппонентов есть еще какие-то тайные знания?

>> Уже было сказано, что ключи вшиты в прогу жестко.

G>Напомню тебе твои же слова: "При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи". Это противоречит "вшиты в прогу жестко", если ты не понял.

Не противоречит. Есть режим запуска для регистрации с параметрами. Как вскрываются оба сценария — я уже говорил. Ну и исходник, опять же...

G>Кароч, может ты все-таки почитаешь про шифрование, безопасность? Ключи генерируются парами — открытый и закрытый, если что.

OMG. ))

G>я тебе в первых строках упомянул несимметричное шифрование. RTFM в общем.

Наивный.

G>Но даже предположим ключиты вшиты, ты думаешь это дает тебе возможность взломать систему? Прослушать — да, управлять — нет.

Ну не позорился бы уже.
1. Что вообще хотят добиться при взломе, не интересовался?
2. Как ты себе вообще представляешь в случае проксирования возможность слушать, но невозможность управлять? Что мне мешает полностью подменять трафик клиента?

Это просто пять баллов!!

G>Пока вместо ответов какие-то финты, балеринка ты наша.

Если ответ неудобен — твои проблемы.

G>Мне ты это зачем писал? Мне все-равно на это. У меня было маленькое замечание, ты мог просто признать свою ошибку и получать фан дальше, но ты предпочитаешь продолжать лажаться в теме.

Я не увидел от тебя ни полезной инфы, не замечаний по теме помимо тех, на которые уже отвечал. Прямо сейчас, например, ты упомянул о генерации ключей парами. Я расчитывал, что ты кормишь свою эрудицию гораздо оперативнее.

>> По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... опять и снова показав, что дыра всегда в инфраструктуре.

G>Ну... ты вообще способен на теме диалога сосредоточиться? Ну зачем опять это вранье и хвастовство?

Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики.

G>Что запоминать, твои сказочки? Нафиг?

Ну, извини, подробностей дать не могу. Но любопытные моменты — не жалко.

G>Извини, но ты болтлив не по сути вопроса и постоянно уводишь диалог куда-то в сторону и не отвечаешь на вопросы.

Я не могу отвечать 10 раз на одни и те же вопросы. Ты отставал по теме и дублировал остальных участников, поэтому можешь просто посмотреть все ответы рядом.

К тому же, будь любопытным, ты бы читал все за и контра и видел бы, где именно располагаются слабые моменты. Собсно, я сразу открестился от перебора/взлома ключей/паролей (не обратил внимание?) и обсуждаю сугубо инфраструктуру. Ты этого не понял, увы. Чтобы понять, почему именно инфраструктуру — поднимись чуть выше по ветке, восстанови контекст беседы целиком.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, AlexRK, Вы писали:

V>>>Существует — алиасинг типов.
ARK>>Поясните, пожалуйста, о чем речь. В моем представлении алиасинг — это просто назначение типу другого имени.

V>Я имею ввиду получение нового типа вместе с новым идентификатором. Ес-но typedef из C++ или using Identifier1 = Identifier2 из C# этим св-вом не обладают.

Замечу, что в Oberon'e этого также нет. И, по моему, этого нет и в паскале. Но это есть в Аде.

В плюсах это (подобный механизм), как я понимаю, можно реализовать библиотечно (через шаблоны).

Здравствуйте, vdimas, Вы писали:

V>Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики.

О какой многоуровневой системе идёт речь, когда ты в одном из первых сообщений описал наивный обмен публичными ключами? Я тебе пытался показать, что а) Так делать не надо б) Есть способы сделать лучше. Опять же -- есть разделяемый секрет, пароль, этого уже вполне достаточно чтобы установить надёжное соединение. Можно даже ни с какими CA не заморачиваться. в) Если нет способа гарантировать доставку неизменённой программы, то о безопасности можно и не вспоминать.

Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

V>Ладно, я ошибся. Проблема была не в этом...

V>Выходит, тот момент, где есть возникновение, а где распространение ссылочной прозрачности, оказался тебе не по зубам даже после разжевать и в рот положить... Казалось бы, показал как правильно пользоваться обсуждаемым инструментарием... ан нет... Смотришь в код и плаваешь в 3-х строчках, даже в собственных примерах...

V>Т.е. принятые в языке D концепции тебе, понятное дело, всё еще непонятны и бесполезны, с твоих же слов... ))
V>Ну ок, не смею больше беспокоить.

Дарю : "Ладно, я слился. Но на всё есть много точек зрения и, следовательно, я не слился."

> V>Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики.
>
> О какой многоуровневой системе идёт речь, когда ты в одном из первых сообщений описал наивный обмен публичными ключами? Я тебе пытался показать, что а) Так делать не надо б) Есть способы сделать лучше. Опять же -- есть разделяемый секрет, пароль, этого уже вполне достаточно чтобы установить надёжное соединение. Можно даже ни с какими CA не заморачиваться. в) Если нет способа гарантировать доставку неизменённой программы, то о безопасности можно и не вспоминать.
>
> Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.

Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе.

На простейшие вопросы (и мои в том числе http://www.rsdn.ru/Forum/?uid=34906) ответить не может. Объяснения не читает. О безопасности не имеет никакого понятия, рассматривает не систему в целом, а отдельные элементы. Считает, что взлом небезопасного (с вшитыми ключами) транспортного уровня ломает всю систему (провайдеры могут воровать у банков?

О технических и организационных мерах безопасности не имеет представления. Более того, не имеет представления о таких бытовых вещах, как системы электронных платежей по интернету с подтверждением платежей по SMS (как простейший пример безопасности основанной на третьей стороне).

Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам.

Это либо клиника либо самозабвенный троллинг.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. Уже было сказано, что ключи вшиты в прогу жестко. Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю. В отличие от.
Сам с собой тут споришь исключительно ты.
Всё что я говорил это то что затраты на инфраструктуру бутылки будут на несколько порядков больше чем на инфраструктуру сингулярити.
И достигается это за счет правильного дизайна сингулярити.

V>По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH...
Всё больше и больше фактов.
Теперь оказывается не только, в программу вшиты ключи, но её еще и через https качают.
Единственное слабое место тут это CA.
Но если CA свой. И в браузере есть только корневой сертификат этого CA, то данная схема не ломается.
А на служебных девайсах так оно и будет.

V>опять и снова показав, что дыра всегда в инфраструктуре.
Ничего кроме своего невежества ты в очередной раз не показал.

V>Кароч, хоть ты сейчас и пытаешься делать вид, что что-то знал и понимал с самого начала — поздно, все ходы записаны. Каждый твой пост как буд-то не имеет связи с предыдущим, а весь смысл можно заменить на "Баба Яга против!".
Это ты про себя?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Дарю : "Ладно, я слился. Но на всё есть много точек зрения и, следовательно, я не слился."

Ну, ок, ты слился. ))

Нет никаких "много точек зрения" в природе. Определение ссылочной прозрачности простое и однозначное. Просто, любые рассуждения, что ссылочная прозрачность достижима без набившей оскомину имммутабельности, скажем так, не соответствуют "генеральной линии партии" на этом сайте... А кое-кому откровенно взрывает моск. ))

Здравствуйте, FR, Вы писали:

FR>Но я тебе вроде уже показывал в D гарантии есть http://dlang.org/const3.html но и ограничения гораздо жестче.

И всё-равно хаки встроены в язык:

char[] s = ...; 
immutable(char)[] p = cast(immutable)s;      // undefined behavior 
immutable(char)[] p = cast(immutable)s.dup;  // ok, unique reference

Кстати, вторая строчка хорошо показывает, что иммутабельность — это таки св-во типа, а не переменной, в отличие от const.

Здравствуйте, Иван Дубров, Вы писали:

ИД>Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.

Я ХЗ почему это кривой пример, это наиболее популярный сценарий шифрования на сегодня. То, как оно обстоит на самом деле, это малость не то, как оно должно быть в идеальном мире. Просто тут некоторые тоже заведомо считали SHH вершиной безопасности, а я показываю свою практически ежедневную практику и эффект от того, что все прописанные процедуры поддержки инфраструктуры на самом деле сугубо вербальные соглашения, которые никто никогда не соблюдает. Пример насчет отпечатка — характерный. Насчет импорта неизвестных сертификатов — тем более.

Здравствуйте, grosborn, Вы писали:

G>Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе.

Почему пехотинцы-то? Что пехотинцы делают по всему миру?

G>Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам.
G>Это либо клиника либо самозабвенный троллинг.

Дык, подрбности я даже в личке далеко не всем выдам. А насчет многоуровневости и где там надо считать уровни "прохождения" при ломке — показательно, что ты не понял ни слова.

Зато опять отметился в форуме. Ну, молоток.

Здравствуйте, WolfHound, Вы писали:

V>>Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. Уже было сказано, что ключи вшиты в прогу жестко. Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю. В отличие от.
WH>Сам с собой тут споришь исключительно ты.

Заметно. ))

WH>Всё что я говорил это то что затраты на инфраструктуру бутылки будут на несколько порядков больше чем на инфраструктуру сингулярити.

Описанный пример показывает, насколько это далеко от истины. Рассмотренной инфраструктуре вообще пофиг какая операционка.

WH>И достигается это за счет правильного дизайна сингулярити.

Идентичная внешняя безопасность достигается это за счет идентичной инфраструктуры. А насчет безопасности — см. мои посты об артефактах безопасности. Атрибуты в исходном коде в Сингулярити в сравнении с этим — детсад. Не пригодно для реальной работы.

V>>По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH...
WH>Всё больше и больше фактов.
WH>Теперь оказывается не только, в программу вшиты ключи, но её еще и через https качают.

А есть принципиальная разница через https или SSH/SCP? А ты пользуешься только IE, который изкаробки, или ты шаришься по и-нету де-факто со стороннего браузера? ))
Спасибо за очередной фан.. впрочем, как всегда. Надеюсь, ты понял насчет неразвитой мысли о стороннем браузере. Для того, кому я отвечал предыдущим постом развивать нет смысла, ес-но.

WH>Единственное слабое место тут это CA.
WH>Но если CA свой. И в браузере есть только корневой сертификат этого CA, то данная схема не ломается.
WH>А на служебных девайсах так оно и будет.

Тебя забыли спросить, как оно будет. А по факту не так. Программа портирована на многие мобильные платформы, покупаешь девайс, качаешь ПО, регистрируешь ноду. Всё. Преднаначена для связи по всему миру, ес-но. Хочешь игнорить реальные сценарии — твои проблемы. Как можно добавить защиты — заведомо известно. Но я тебе уже приводил аналогию использования серверной ОС в кач-ве десктопной в ответ на твои предложения "всё запретить из коробки" для десктопных осей. Похоже, ты ниче не понял насчет неюзабельности.и как следствия нереальности таких сценариев.

V>>опять и снова показав, что дыра всегда в инфраструктуре.
WH>Ничего кроме своего невежества ты в очередной раз не показал.

Толсто и как всегда умозрительно.

V>>Кароч, хоть ты сейчас и пытаешься делать вид, что что-то знал и понимал с самого начала — поздно, все ходы записаны. Каждый твой пост как буд-то не имеет связи с предыдущим, а весь смысл можно заменить на "Баба Яга против!".
WH>Это ты про себя?

Это про любителей черпать знания из вики и размахивать затем ими.

Здравствуйте, Sinclair, Вы писали:

S>А при выполнении global flow analysis компилятору совершенно наплевать на ваши ручные аннотации — он и так увидит, где имеет место ссылочная прозрачность, а где — нет.
S>Что тут непонятно?

Непонятна твоя т.з. до сих пор, более ничего. Ес-но меня global flow analisis не интересует, лично мне, как программисту, он не поможет никак. Пример с возможностью создать безопасный иммутабельный тип даже на C# без встроенной поддержки иммутабельных типов разве ни о чем тебе не говорит? (если не брать во внимание хаки через рефлексию)

Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ. Причем, мне эта безопасность требуется для мутабельного варианта в т.ч. Для мутабельных сценариев требуются гарантии видимости (то бишь локальности) происходящего и ничего более. Требовать иммутабельности для мутабельных сценариев — это какой-то заведомо цирк.

Как описывать это безопасное АПИ — я показал более одного раза. Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак. Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал. Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince? Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность? Аналогично насчет моих const и clean.

Только мне легче гораздо, бо компилятор много чего контроллирует.

Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const:

Именно из-за того, что ему неизвестно, ссылается ли переданная в данный фрагмент ссылка на const реально ссылкой на const или ссылкой на mutable.

Жесть как она есть. ))
Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx?

Здравствуйте, vdimas, Вы писали:

V>Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ.
Инструмент для этого подходит любой. Безопасные АПИ можно клепать хоть на K&R С. Вот только доказать это не удастся.

V>Как описывать это безопасное АПИ — я показал более одного раза.

V>Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак.
Я показал, и неоднократно, как ваше "безопасное" АПИ ломается на раз-два.

V>Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал.
Да никак их не вылечить.

V>Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince?
Нет никакой rocket science. Есть упорное непонимание в лице одного субъекта того, как работает компилятор.

V>Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность?

"Визуально"... Визуально я и в С могу найти. А могу — не найти. Нету в шарпе (и вообще в дотнете) средств статически проверить иммутабельность. Система типов не та.

V>Аналогично насчет моих const и clean.

Только мне легче гораздо, бо компилятор много чего контроллирует.
Я же показал вам пример с вашим const и clean, который показывает, что никаких гарантий такой clean не даёт.

V>Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const:
Ещё раз объясню: я прекрасно понимаю семантику const. Это вы не понимаете, почему она бесполезна.
Вы показали ровно один изолированный пример, где время жизни идентификатора полностью контролируется компилятором.
Шаг вправо-влево — и всё, никаких бенефитов.
V>Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx?
Читал. Отлично. То есть вся ссылочная прозрачность действует ровно в пределах одного метода, на локальную переменную, и только до тех пор, пока мы не произвели вызов, где ссылка на неё фигурирует в качестве не-конст параметра.
Это и есть ваше "константность прекрасно распространяется"?

В вашем примере компилятор не может оптимизировать код foo — по причине, которую я вам уже семь раз изложил, а вы полагаете эту причину "непониманием семантики const". Ну так код foo и надо в первую очередь оптимизировать! В случае нормальной архитектуры вы строите код из отдельных модульных кусочков. Вся реальная работа происходит где-то внутри функций, а не в клее, которым вы их соединяете. И как раз там нет никакой пользы от константности.

> G>Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе.
>
> Почему пехотинцы-то? Что пехотинцы делают по всему миру?

А кто, военные разведчики что ле? И сливают военные секреты в штаб по мобилам? И эту систему починить тебя просил какой-то штирлиц из соседнего подъезда, приехавший в отпуск на выходные? Ну типа "братан, помоги, когда отправляю разведданные в центр мобила пишет что-то не по нашенски".
Или может быть ракетные войска? Так-то обычно они по гугл-мапс наводятся, что наши что американы, но вот помня что американы все-время лажались из за того что мапс не обновлялась вовремя (то госпиталь разбомбят, то гостиницу с журналистами), наши решили отправлять наводчиков с мобилами на место перед бомбежкой, для надежности.

> G>Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам.
> G>Это либо клиника либо самозабвенный троллинг.
>
> Дык, подрбности я даже в личке далеко не всем выдам. А насчет многоуровневости и где там надо считать уровни "прохождения" при ломке — показательно, что ты не понял ни слова.

> Зато опять отметился в форуме. Ну, молоток.

Главный молоток тут ты. Насочинялся до взлома восьмиуровневых систем, когда не умеешь пользоваться даже одноуровневой.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Sinclair, Вы писали:

V>>Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ.
S>Инструмент для этого подходит любой. Безопасные АПИ можно клепать хоть на K&R С. Вот только доказать это не удастся.

Из-за ссылочной непрозрачности, так ведь? На С++ сегодня аналогично — невозможно. Медицинский факт. Нужен некий предложенный мною clean (он же pure в D2). Нужно убрать хаки константности. Нужно распространять константность на значения, располагаемые по адресу из ссылочных типов.

V>>Как описывать это безопасное АПИ — я показал более одного раза.
S>

V>>Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак.
S>Я показал, и неоднократно, как ваше "безопасное" АПИ ломается на раз-два.

Оно никак не ломается даже в твоих примерах. Дай ссылку или скопируй сюда самый каверзный из приведенных — я разберу его пошагово. А так же покажу как допилить до безопасного варианта, если требуется. Безопасность определяется в ТЗ, ес-но, и более ничем.

Столкновение происходит сугубо в твоём понимании семантики const. Я специально заменил его на "ref in" на шарпоподобном языке, чтобы семантика более соответствовала названию модификатора переменной-аргумента. Другой семантики у const НЕТ, и ты ругаешь за то, что ееё нет.

Но это обсуждение в никуда. Я вызвался расписать безопасный сценарий именно в этой семантике. Почему мне не нужна явная иммутабельность — уже говорил. Потому, что это прибитые гвоздями ограничения к типам, а мне надо над одними и теми же данными разрабатывать чистые и нечистые алгоритмы. Выделенное ключевое. Помнишь, я тебе обрисовывал сценарий устойчивого к исключениям кода? ИМХО, в пространстве иммутабельности это заведомо невоможно без лишних приседаний/копирований. Может я и ошибаюсь — тогда покажи как это возможно.

V>>Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал.
S>Да никак их не вылечить.

Ты давай ТЗ, а я дам решение. А то пока что были сниппеты кода, от которых ты безосновательно много чего хотел.

V>>Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince?
S>Нет никакой rocket science. Есть упорное непонимание в лице одного субъекта того, как работает компилятор.

Он работает, как ему скажешь. Если ты ему дал кривой код, он честно его скомпилит и выполнит.

V>>Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность?
S>

"Визуально"... Визуально я и в С могу найти. А могу — не найти. Нету в шарпе (и вообще в дотнете) средств статически проверить иммутабельность. Система типов не та.

Воот, а в С++ есть. ))
Даже замечание насчет кривизны распространения константности на ссылочные переменные-мемберы разруливается устоявшимся способом:

template<typename T>
class SmartPtr {
  T * target_;
  ...
  T * get() { return target_; }
  const T * get() const { return target_; }
}

Просто мне бы хотелось автоматического распространения... И, хотя для указателей это было бы проблематично из-за семантики адреса как значения, то уж для ссылок могло быть автоматом.

V>>Аналогично насчет моих const и clean.

Только мне легче гораздо, бо компилятор много чего контроллирует.
S>Я же показал вам пример с вашим const и clean, который показывает, что никаких гарантий такой clean не даёт.

Дает. Просто ты настаиваешь на гарантиях для вызываемого кода. Похоже, ты забыл какое отношение у вызываемого и вызывающего кода, оно многие к одному со стороны вызывающего кода. В тех случаях, где ссылочная прозрачность УЖЕ нарушена, там искать ее распространения наивно. Но в других сценариях, где ссылочная прозрачность некоего локального значения не нарушена, там вызов той же самой ф-ииеё НЕ нарушит. Только это мне и важно. Просто const и clean позволят не контроллировать сколь угодно глубоко зависимости визуально, накладывая транзитивно распространяемые ограничения.

V>>Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const:
S>Ещё раз объясню: я прекрасно понимаю семантику const. Это вы не понимаете, почему она бесполезна.
S>Вы показали ровно один изолированный пример, где время жизни идентификатора полностью контролируется компилятором.

Ес-но. И трекается глазами программиста. Это необязательно могла бы быть константа. Это может быть откуда-то полученное значение, сохраненной во временной переменной. По-сути, каждая новая строчка кода может оперировать над данными, у которых ссылочная прозрачность соблюдена, а может нет. Я могу делать такие выводы, трекая в уме алгоритм, протаскивая по коду ссылочную прозрачность, ориентируясь на сигнатуры вызываемых ф-ий/методов. Заметь, operator=() [присвоение] — точно такая же сигнатура некоей ф-ии. Это ключ к пониманию твоих собственных примеров.

При наличии инструмента описания безопасного АПИ всех объектов, начиная с самого нижнего уровня, я просто буду охотиться за гораздо меньшим кол-вом ошибок в нейтивных программах. Ведь с виду в коде всегда всё правильно, но где-то "унутре" возникают самые разнообразные сочетания эффектов. А транзитивная распространяемость модификатора clean поможет мне в случае, если я забыл о нем на некоем низлежащем уровне, то уж вышестоящий мне "напомнит". И не будет никаких эффектов "унутре".

S>Шаг вправо-влево — и всё, никаких бенефитов.
V>>Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx?
S>Читал. Отлично. То есть вся ссылочная прозрачность действует ровно в пределах одного метода, на локальную переменную, и только до тех пор, пока мы не произвели вызов, где ссылка на неё фигурирует в качестве не-конст параметра.
S>Это и есть ваше "константность прекрасно распространяется"?

Да именно, это и есть определение ссылочной прозрачности. Я хочу точно знать, что происходит с КАЖДЫМ локальным значением в КАЖДОЙ ф-ии/методе, когда передаю не копию значения, а ссылку. Весь мой код состоит из ровно таких же ф-ий/методов, так что мне гарантий в пределах одного метода — более чем достаточно.

S>В вашем примере компилятор не может оптимизировать код foo — по причине, которую я вам уже семь раз изложил, а вы полагаете эту причину "непониманием семантики const". Ну так код foo и надо в первую очередь оптимизировать! В случае нормальной архитектуры вы строите код из отдельных модульных кусочков. Вся реальная работа происходит где-то внутри функций, а не в клее, которым вы их соединяете. И как раз там нет никакой пользы от константности.

==============
Почему я, собсно, мусолю эту тему. Низлежащая современная модель вычислений железок, увы, доживет до моей смерти как профессионала. До твоей тоже. Это очередной медицинский факт. То бишь надо исходить из того, что есть. За ситуацией в суперкомпиляции я слежу с периодичностью раз в год примерно... На сегодня эта ситуация еще не преодолела зачаточный уровень и не скоро преодолеет — никаких предпосылок. Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП. Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому. Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков. Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко. На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок. Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. Самые популярные сегодня — это неверное представление о работе собственных многопоточных программ, иногда откровенные гонки. Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, из-за скрытого неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев. Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. В идеале хотелось бы 1 уровень. И мне/нам обсуждаемые языковые ср-ва помогут заметно сэкономить на отладке. А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения. С другой стороны, видя здесь резкую реакцию на "выскочку, идущую против генеральной линии партии", таки есть сомнения — что я еще не увидел? Вдруг есть еще кое-какие моменты?

Просто пока что в меня тыкали примерами, скажем, заведомо нерелевантными обсуждаемому. Все примеры отталкивались от некоего гипотетического требования к семантике const, которого (1) нет и (2) мне, как разработчику на этом языке — не нужно (по приведенным в 3-й раз причинам).
===========

Здравствуйте, vdimas, Вы писали:

V>Ничего не перепутал? Сможешь показать, в каких популярных императивных языках оно есть?

Кстати, насчет того, что в Обероне есть. Вот здесь адепты Оберона обсуждают как бы им на Обероне зафигачить интерфейсы. Язык на прямую их не поддерживает. Объекты есть, а интерфейсов нет. Полиморфизм реализуется ручками, через задницу, со всему причитающимися граблями вроде ручной инициализации объектов и заполнения виртуальных таблиц. А вы, алгебраические типы, алгебраические типы!

Здравствуйте, Kernan, Вы писали:

K>Сергей Губанов, вы реинкарнировали в vdimas?

Вижу меня тут помнят и любят

Я не реинкарнировал в vdimas.

Все эти годы я отсиживался на форумах оберонкоре, потом меня там забанили свои же. Короче, я уже не тот TRUE-оберонщик.

В соседнем посте Алексей описал плачевную ситуацию с оберонкоре: http://rsdn.ru/forum/philosophy/4842898.1.aspx

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Все эти годы я отсиживался на форумах оберонкоре, потом меня там забанили свои же. Короче, я уже не тот TRUE-оберонщик.

А за что забанили, если не секрет?

Здравствуйте, AlexRK, Вы писали:

ARK>А за что забанили, если не секрет?

За "дать в морду Ткачёву" (который info21). Ткачёв троллил все обсуждения, которые по его мнению могли причинить вред его проекту "Информатика 21". Каждый раз по его вине начинался срач бессмысленный и беспощадный. Потом загаженная Ткачёвым ветка исчезала из свободного доступа (или совсем) под предлогом... загаженности. Ткачёву за это никогда ничего не было. После того как эта схема повторилась несколько раз я инициировал обсуждение как наказать Ткачёва. Ткачёв опять устроил срач. Ему за это опять ничего не сделали, а меня забанили на сутки. Суток мне хватило, я туда больше не вернулся. Я ушёл на oberspace: http://oberspace.dyndns.org/index.php/topic,170.0.html

Здравствуйте, WolfHound, Вы писали:

V>>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?
WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.
WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.
WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

WH>Блин. Ну никакой фантазии.

Не могу удержаться: ))))
Вы изобрели реестр виндоус: WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.

Доступ к БД согласно предоставленным правам: WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.

И антивирус вкупе с файеволом встроенный в ОС:
WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

Вроде ж грамотный человек, но непонятно почему вы пытаетесь представить давно известные общественности вещи
как нечто совершенно новое, полет мысли, панацея, квинтессенция и прочее бла-бла-бла.

Тем самым уподобляясь несчастным апологетам того же несчастного оберона)))) по сути.

Почитатели каких то сферических коней в вакууме, ей-богу.

Не знаю как там в вашей вселенной абстракционистов-теоретиков, у нас у практиков прекрасно работает и Виндоуз и МакОС и Линукс и Андроид с иОСом,
прекрасно пишем на плюсах, жабе, шарпе))
Вы активно защищаете какие то идеи, которые никому массово не нужны. Никаких проблем они не решают, а только добавляют хлопот.
Потому как идеи эти уже давно реализованы и работают и пользу приносят и зарабатывают деньги.

Здравствуйте, SenorProgramador, Вы писали:

SP>Вроде ж грамотный человек, но непонятно почему вы пытаетесь представить давно известные общественности вещи
SP>как нечто совершенно новое, полет мысли, панацея, квинтессенция и прочее бла-бла-бла.
Кто-то разве говорит про "совершенно новое"? Указанные технологии — это вариация на тему "capability based security", которой уже фиг знает сколько лет (30 как минимум точно есть).

Здравствуйте, SenorProgramador, Вы писали:

WH>>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.
SP>Вы изобрели реестр виндоус:
Мимо. Реестр винды это глобальная помойка, в которую кто попало, куда попало может гадить.
И хрен найдешь, кто, что и куда записал.

В данном случае приложение за приделы своей песочницы нагадить не может физически.

Таким образом, приложение полностью автоматически можно удалить без следа. Деинсталятор вшит прямо в ОС.

WH>>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
SP>Доступ к БД согласно предоставленным правам:
Опять мимо. Ибо разговор снова про личную БД приложения за приделы которой оно физически не может сунуться.
При этом от пользователя нужно ровно 0 настройки.

WH>>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.
SP>И антивирус вкупе с файеволом встроенный в ОС:
Опять не попал.
Антивирус это эвристическая программа, которая ловит зловредов с некоторой вероятностью.
В данном случае они физически ничего сделать не могут.

SP>Вроде ж грамотный человек, но непонятно почему вы пытаетесь представить давно известные общественности вещи как нечто совершенно новое, полет мысли, панацея, квинтессенция и прочее бла-бла-бла.
Вещи то старые. Но ты ни разу не угадал.

SP>Не знаю как там в вашей вселенной абстракционистов-теоретиков, у нас у практиков прекрасно работает и Виндоуз и МакОС и Линукс и Андроид с иОСом,
Я вижу, как они работают.
Вирусы. Dllhell. Не работающий софт по причине смены набора команд процессора.

SP>прекрасно пишем на плюсах, жабе, шарпе))
Я вижу, как вы пишете. Жрете память. Ломаете её. Создаете кучу дырок для вирусов. Тормозите на ровном месте. Не можете масштабироваться.

SP>Вы активно защищаете какие то идеи, которые никому массово не нужны. Никаких проблем они не решают, а только добавляют хлопот.
640К хватит всем. (С)
Если ты что-то не понимаешь, это не значит что это не нужно.

SP>Потому как идеи эти уже давно реализованы и работают и пользу приносят и зарабатывают деньги.
В том то и дело что нихрена они не реализованы.
Вернее реализованы, но кусочками, а нужно комплексное решение.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

V>>Всё проще. Помнишь я тебе говорил когда-то, какой примитив синхронизации является базовым? Предположи, сколько этих базовых примитивов синхронизации обслуживают логику MVar. Почему именно так?
WH>Его нет.

Есть. Это атомарный счетчик.

WH>Также как нет базовой вычислительной модели.
WH>Все выражается друг через друга.

Попытка дать док-во по аналогии.

WH>Но что характерно ты так и не предоставил мне решение одной простой задачки.

Какой именно?

WH>Короче напиши readMVar или засчитываю слив.

Или идешь лесом. Я уже более одного раза предлагал тебе подумать над сценарием передачи данных м/у потоками через некое поле, когда речь идет о типе данных, для которого атомарность гарантируется аппаратурой. Например, когда речь об указателе. Фишка в том, что для сигналинга все-равно потребуется некий примитив синхронизации, на котором можно ожидать "готовность" данных.

WH>Авторам библиотеки удалось лишь с такой оговоркой.
WH>

WH>This function is atomic only if there are no other producers (i.e. threads calling putMVar) for this MVar.

WH>Попробуй понять почему.

Что именно понять? Их MVar делается, например, на 2-х семафорах со счетчиком равным 1, или одном семафоре и одном мьютексе. Есть еще вариант — на 1-м мьютексе + sleep() как ожидание. Есть еще вариант на conditional variable, если такая функциональность поддерживается ОС.

Кароч, есть куча полностью атомарных и безопасных реализаций для организации межпоточного обмена. Ограничения могут быть только если пытаться делать блокировки "легковесными", типа как в lock-free алгоритмах.

WH>Плюс тебе еще задачка сделать await. На данных примитивах будет просто гора кода.
WH>И я даже не уверен, что его можно сделать с одной MVar.

Потому что не понимаешь как работает полноценный conditional variable. Классический AWAIT требует PULSE, а последнее требует поддержки очереди ожидающих. Вопрос горы кода зависит от того, есть ли аналог conditional variable в АПИ ОС, или её надо делать самому. В прямом виде для Windows нет, например. Но коссвенно, через completion ports, можно задействовать внутреннюю очередь виндов для аналогичного механизма (см. boost::asio для виндов, где можно диспатчить свои события, а не только системные). Просто этот механизм — именно такой, о котором речь (для асинхронных операций IO, которые реализованы по технологии completion ports в виндах).

WH>Всю свою демагогию про продолжения ты тоже, что характерно слил.

Слил ты про свой мега-TDOP, который не работает на простейшем куске С++ исходника.
Зато сколько было гонору... не? )))

А я ничего не сливал. По ссылке завис мой неотвеченный пост: http://www.rsdn.ru/forum/philosophy/4831188.1.aspx
Если есть чего по нему ответить — велкам.

Здравствуйте, vdimas, Вы писали:

V>>>Всё проще. Помнишь я тебе говорил когда-то, какой примитив синхронизации является базовым? Предположи, сколько этих базовых примитивов синхронизации обслуживают логику MVar. Почему именно так?
WH>>Его нет.
V>Есть. Это атомарный счетчик.

Показать тебе атомарный счетчик, реализованный на любом другом примитиве синхронизации?

WH>>Также как нет базовой вычислительной модели.
WH>>Все выражается друг через друга.
V>Попытка дать док-во по аналогии.
Нет. Просто констатация факта.

WH>>Короче напиши readMVar или засчитываю слив.
V>Или идешь лесом.
Слив засчитан. Тем более что ты несешь просто феерический бред про "базовый примитив синхронизации".
После такого разговаривать с тобой просто нет смысла. Ибо ты полностью безграмотен.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

V>>>>Всё проще. Помнишь я тебе говорил когда-то, какой примитив синхронизации является базовым? Предположи, сколько этих базовых примитивов синхронизации обслуживают логику MVar. Почему именно так?
WH>>>Его нет.
V>>Есть. Это атомарный счетчик.
WH>

Показать тебе атомарный счетчик, реализованный на любом другом примитиве синхронизации?

Ну, покажи, поржем...
Потому как тот "другой" примитив синхронизации будет уже внутри себя содержать счетчик. Не пробовал на досуге посмотреть устройство хотя бы юзер-левельного CRITICAL_SECTION?

WH>>>Также как нет базовой вычислительной модели.
WH>>>Все выражается друг через друга.
V>>Попытка дать док-во по аналогии.
WH>Нет. Просто констатация факта.

Просто хотя бы раз в жизни можно было бы посмотреть на то, как устроены примитивы синронизации внтури ОС, а не изобретать тут. Осей с открытыми исходниками сегодня полно.

WH>>>Короче напиши readMVar или засчитываю слив.
V>>Или идешь лесом.
WH>Слив засчитан.

Гы-гы. Я тебе дал навскидку 3 варианта с ходу, считая их известными. Просто ты их не в курсе, очевидно. Например, покажи механизм сигналинга на первом же варианте из вариантов — двух семафорах со счетчиком 1. А ведь классика жанра, казалось бы.

Про AWAIT мы, походу, испарились. ЧТД.

WH>Тем более что ты несешь просто феерический бред про "базовый примитив синхронизации".
WH>После такого разговаривать с тобой просто нет смысла. Ибо ты полностью безграмотен.

Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.

Но ты оч быстро бегаешь, не вышло. По сути предмета я имею ввиду механизм ожидания на этом счетчике, реализованный через шедуллер ОС. Просто это было бы опасное замечание для того, кто не в курсе, как это всё на самом деле работает. Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными. Но твои предложения выразить одни примитивы через другие говорят о том, что ты мыслишь настолько далекими от устройства этих примитивов понятиями, что действительно, нам с тобой обсуждать сразу нечего. Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.

Здравствуйте, WolfHound, Вы писали:

...много бла-бла-бла...

Вы как будто из лесу вышли с криками: "смотрите, я увидел солнце!" ))
"Это новая звезда и имя ей -- сингулярити!" ))

Про десктопы и десктопные оси в перспективе можете забыть вообще.
Они вымрут как динозавры, ибо уже грянул мобайл. (это насчет вашего неправомерного отсыла в прошлое с 640 Кб)

Посмотрите, хотя бы на андроид -- ну, каждое приложение имеет список пермишнов -- и что?
Почти каждое -- требует целую кучу -- и юзер послушно разрешает.

В иОСе -- премодерация всех легальных приложений -- малвари не пройти, а если и пройти -- то очень недалеко.
Опять же, покупки и настройки и так сохранаяются и переносятся на другое устройство.

И, кстати, и приложения подписываются уникальным ключом разработчика, все это есть уже давно.

Что вы нового пропагандируете и какие проблемы обычного юзера и/или разработчика решаете -- непонятно.

P.S.: я не ради просто поддержания дискуссии, и не с целью каких то словесных нападений, мне кажется, что вы уж слишком рьяно
пытаетесь доказать какие то тезисы, которые уже давно не то, чтобы доказаны, а давно уже работают.

Здравствуйте, WolfHound, Вы писали:

WH>>>Короче напиши readMVar или засчитываю слив.
V>>Или идешь лесом.
WH>Слив засчитан.

Ладно, не ожидал, прямо скажем, такого:

Короче напиши readMVar или засчитываю слив.
Авторам библиотеки удалось лишь с такой оговоркой.
This function is atomic only if there are no other producers (i.e. threads calling putMVar) for this MVar.
Попробуй понять почему.

от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

Простой сигналинг при межпотоковой передаче таков: поток-producer должен получать сигнал, что можно писать, а поток-consumer должен получать сигнал о том, что можно читать. Поэтому, очевидное (и, кстати, самое эффективное в случае большой вероятности захода потоков на ожидание) — это решение "в лоб":

template<typename T>
class MVar
{ 
  Semaphore readSema_, writeSema_;
  T volatile value_;

  MVar() : writeSema_(1) {}

  MVar(const T & value) : value_(value), readSema_(1) {}

  void write(const T & value) {
    writeSema_.acquire(), value_ = value, readSema_.release();
  }

  T read(const T & value) {
    T tmp;
    readSema_.acquire(), tmp = value_, writeSema_.release();
    return tmp;
  }
};

Дарю!
Остальные упомянутые мной способы реализации приводить? ))

В общем, вот элементарная реализация, которая абсолютно безопасна безо-всяких твоих оговорок. А попробовать понять (как ты просил), почему у авторов исходного MVar не получилась реализация без оговорок... предположу, что кривизна рук не того радиуса.

И да, эту реализацию где-то можно рассматривать как очередь с одним элементом... эт даааа... Я всегда привожу пример Матлаба, где скаляры на самом деле матрицы [1,1].

Но там это хоть имеет все основания для такого обобщения без дополнительных приседаний в семантике и реализации, а в случае MVar — увы, нет... потому что если длина очереди будет >1 (если инициализировать семафоры значением макс. длины очереди), то показанная реализация не будет работать. Будет нужен дополнительный примитив синхронизации для разруливания конкурентного доступа к самой очереди. В общем, для межпотоковой очереди подходящи совсем ДРУГИЕ алгоритмы...

Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...

Здравствуйте, vdimas, Вы писали:

V>Просто хотя бы раз в жизни можно было бы посмотреть на то, как устроены примитивы синронизации внтури ОС, а не изобретать тут. Осей с открытыми исходниками сегодня полно.
Твои знания ничтожны. Ибо ты изучаешь даже не деревья, а листья на них.
Но при этом говоришь про лес в целом.

V>Про AWAIT мы, походу, испарились. ЧТД.
Это для тебя слишком сложный разговор. Ты сначала MVar пойми.

V>Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.

Ты не можешь меня поймать. У тебя просто знаний не хватит.

V>Но ты оч быстро бегаешь, не вышло. По сути предмета я имею ввиду механизм ожидания на этом счетчике, реализованный через шедуллер ОС. Просто это было бы опасное замечание для того, кто не в курсе, как это всё на самом деле работает.
Не волнуйся. Я в курсе. Причем намного лучше, чем ты.

V>Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными.
Одна из реализаций hardware transactional memory

RTM adds three new instructions XBEGIN, XEND and XABORT. The XBEGIN and XEND instructions mark the start and the end of a transactional code region; the XABORT instruction explicitly aborts a transaction. Transaction failure redirects the processor to the fallback code path specified by the XBEGIN instruction, with the abort status returned in the EAX register.

Начинай считать счетчики.

V>Но твои предложения выразить одни примитивы через другие говорят о том, что ты мыслишь настолько далекими от устройства этих примитивов понятиями, что действительно, нам с тобой обсуждать сразу нечего.
Я просто понимаю, что с теоритической точки зрения одни примитивы можно выразить через другие. Точно так же как один полный по Тьюрингу язык можно реализовать на другом. Эффективность в данном случае вопрос десятый.
При этом не важно, какие нам даны.
Если нам ничего не дано, то мы не сможем ничего сделать.

V>Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.
Это у тебя не мелькнуло мысли о том, что железо может быть очень разным.
Короче начинай считать счетчики в инструкциях XBEGIN, XEND и XABORT.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, vdimas, Вы писали:

V>от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

Ты даже не представляешь, насколько смешон.

V>Дарю!
V>Остальные упомянутые мной способы реализации приводить? ))
Поздравляю. Ты реализовал getMVar и putMVar.
Теперь используя только getMVar и putMVar реализуй readMVar.
Который читает значение, при этом не забирает его.
Доступа к семафорам у тебя нет. Использовать можно только публичный интерфейс.

V>Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...
Ты понимаешь что, используя одни примитивы можно получить другие.
Это уже прогресс.
Но твоя зацикленность на листьях просто поражает. Вместо анализа модели ты начал анализировать одну из возможных её реализаций. При использовании HTM реализация будет сильно другая. И весь твой анализ сразу отправляется в мусор.
А теперь попробуй представить страшное... MVar реализован процессором. И других примитивов синхронизации в железе нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, SenorProgramador, Вы писали:

SP>Про десктопы и десктопные оси в перспективе можете забыть вообще.
SP>Они вымрут как динозавры, ибо уже грянул мобайл. (это насчет вашего неправомерного отсыла в прошлое с 640 Кб)
1)Никуда десктоп не денется. Мобаил просто не может решать все задачи.
2)У мобайла ровно те же проблемы.
3)640К было не про то о чем ты подумал. А про то, что не нужно говорить о том, что что-то не нужно, если ты не знаешь, зачем это нужно.

SP>Посмотрите, хотя бы на андроид -- ну, каждое приложение имеет список пермишнов -- и что?
SP>Почти каждое -- требует целую кучу -- и юзер послушно разрешает.
1)Гранулярность у них слишком маленькая.
2)Я не разрешаю, если вижу что-то что приложению не нужно.
Например, читалка штрихкодов захотела доступ к моим контактам. Зачем? Была послана.
А если бы я был модератором, то еще бы и забанена.

SP>В иОСе -- премодерация всех легальных приложений -- малвари не пройти, а если и пройти -- то очень недалеко.
Вот тут профессионал и проверит, зачем приложению нужны все те привилегии, что оно запрашивает.
Скорость модерации возрастет на порядки просто по тому, что в большинстве случаев будет достаточно посмотреть, что приложение не просит то, что ему не нужно.

SP>Опять же, покупки и настройки и так сохранаяются и переносятся на другое устройство.
Это вообще отдельный разговор и к безопасности отношения не имеет.

SP>И, кстати, и приложения подписываются уникальным ключом разработчика, все это есть уже давно.
Вот это как раз не обязательно.

SP>Что вы нового пропагандируете и какие проблемы обычного юзера и/или разработчика решаете -- непонятно.
Ессно не понятно. Для этого же нужно много изучить. И это трудно. А просто болтать языком, что все те, кто говорит что-то непонятное идиоты, очень легко.

SP> пытаетесь доказать какие то тезисы, которые уже давно не то, чтобы доказаны, а давно уже работают.
К сожалению не работают. Ибо даже если всё обложить подписями и модераторами, то банальные ошибки переполнения буфера всё испортят.
И это не говоря про такие мелочи как возможность приложению засунуть свои плагины в песочницу. Ибо ничто не мешает плагину вызывать функции ОС с правами приложения.
Например, если я пишу, видело плеер, то я должен быть уверен, что кодек, который я использую, на самом деле не малварь и не лезет куда попало. Что ты будешь делать в классических ОС, чтобы не дать ему запустить свои грязные лапы, куда не следует?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

V>>Просто хотя бы раз в жизни можно было бы посмотреть на то, как устроены примитивы синронизации внтури ОС, а не изобретать тут. Осей с открытыми исходниками сегодня полно.
WH>Твои знания ничтожны. Ибо ты изучаешь даже не деревья, а листья на них.
WH>Но при этом говоришь про лес в целом.

Как всегда, десяток постов сплошного бла-бла-бла... Пока опять не поймали.
Характерно, что ты уцепился за базовый уровень 0 по этой теме, и назвал этот уровень "лесом".

Я с тобой лично не знаком... но уже предлагал как-то поспорить на тот счет, что ты безбожно прогуливал во время учебы в ВУЗе. То, что ты назвал "лесом", дается на 3-4-х лекциях по устройству ОС. Ты на них не был, очевидно. Это банальности, а никакой не лес. Если я их не упоминаю, то лишь от того, что мы на проф-форуме.

V>>Про AWAIT мы, походу, испарились. ЧТД.
WH>Это для тебя слишком сложный разговор. Ты сначала MVar пойми.

Фишка в том, что кол-во необходимых примитивов синхронизации для "честного" сигналинга всё-равно будет таким же, как на самом простом из них... кроме случая отказа от сигналинга ОС и использования вместо него тупого мьютекса (крит.секции) + sleep(). Я по-наивности своей считал, что намеков было более чем достаточно... но всё это действительно для кое-кого оч сложно. В общем, ты много пальцы вейром растопыривал, а сколько нужно примитивов синхронизации для MVar так и не сказал. ЧТД.

V>>Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.

WH>Ты не можешь меня поймать. У тебя просто знаний не хватит.

Угу, с альфой и обделавшимся TDOP тоже не хватило. Натуральный парадокс блабла уже выходит. Только теперь в цикле.

V>>Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными.
WH>Одна из реализаций hardware transactional memory
WH>

WH>RTM adds three new instructions XBEGIN, XEND and XABORT. The XBEGIN and XEND instructions mark the start and the end of a transactional code region; the XABORT instruction explicitly aborts a transaction. Transaction failure redirects the processor to the fallback code path specified by the XBEGIN instruction, with the abort status returned in the EAX register.

WH>Начинай считать счетчики.

Ох, блин, вики открыл? Какая прелесть! А теперь попробуй найтии отличие от обычного CAS, для случая данных шириной в слово.

Это я еще молчу о том, что ни в твоей, ни в моей машинке этой памяти пока нет. Ууупс?

V>>Но твои предложения выразить одни примитивы через другие говорят о том, что ты мыслишь настолько далекими от устройства этих примитивов понятиями, что действительно, нам с тобой обсуждать сразу нечего.
WH>Я просто понимаю, что с теоритической точки зрения одни примитивы можно выразить через другие.

Я рад за тебя... ты прав на все 100%, особенно когда никого не волнует эффективность... Можно даже тупо сидеть в цикле на sleep() и ждать у моря погоды, фигли... Хотя я потрунивал именно над эффективностью этой штуки, когда они показывали нам, в каких сценариях еще можно этот несчастный MVar использовать.

WH>Точно так же как один полный по Тьюрингу язык можно реализовать на другом. Эффективность в данном случае вопрос десятый.

Точно! Речь же о базовом и единственном примитиве синхронизации, доступным из языка... Хотя, это в духе того самого языка, угу. )))

WH>При этом не важно, какие нам даны.
WH>Если нам ничего не дано, то мы не сможем ничего сделать.

Кароч, одни юления и ничего кроме юлений.
В современных SMP-машинках в кольцо ядра спокойно заходят несколько физических потоков. Что значит "ничего не дано"? Этот момент дан свыше и это не переплюнуть. На однопроцессорных машинках просто запрещаются прерывания и выполняется логика конретного примитива синхронизации, но что у нас есть в SMP? — атомарные операции (навроде CAS), к нему spin-wait и самый крайний случай — заморозка текущего потока в шедуллере. Вот твой реальный базис. Действуй. Если бы не было ничего дано, то высокоуровневые примитивы синхронизации в этой среде были бы невозможны.

V>>Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.
WH>Это у тебя не мелькнуло мысли о том, что железо может быть очень разным.
WH>Короче начинай считать счетчики в инструкциях XBEGIN, XEND и XABORT.

Дык, ты всё-равно никоим образом не опровергнул суть вопроса...

Вопрос в силе...
Ну будет более одного счетчика/флага за раз изменяться, и? Я тебе по-секрету скажу, что это же самое происходит внутри виндов прямо сейчас, даже на твоей машинке, путем разбиения машиного слова на поля, и пользуя стандартный цикл обновления на CAS. Если бы ты это знал, не приводил бы сейчас тоже самое с точностью до ширины данных. Так что все твои понты дальше Вики не ходят, увы.

И да, базовый алгоритм я тебе рядом привел. Даже если объединить показанные там семафоры в одно слово, все-равно будут 2 последовательные операции независимо по 2-м полям, отведенным под мьютексы.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, vdimas, Вы писали:

V>>от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

WH>Ты даже не представляешь, насколько смешон.

V>>Дарю!
V>>Остальные упомянутые мной способы реализации приводить? ))
WH>Поздравляю. Ты реализовал getMVar и putMVar.

Дык, реализаций может быть много. Минимум 4 еще я тебе словами описал сразу же. А показал лишь вариант "в лоб", чтобы продемонстрировать те задачи/сигналы, которые возникают при передаче данных м/у потоками. Просто я, по-наивности своей, много постов назад упоминал сии сценарии в словесном описании, думая, что ты владеешь темой... ан нет. А сейчас привел пример исключительно чтобы показать минимально-необходимое кол-во НЕЗАВИСИМЫХ примитивов синхронизации для реализации с стиле "честного" сигналинга ОС, то бишь когда потоки получают управления не для того, чтобы копошиться-проверять готовность (и тратить драгоценные тики ядер на "холостые" переключения контекстов), а когда эта готовность де-факто наличиствует и уже ничего проверятьне надо.

Или ты всерьез предполагал, что с реализацией этой хрени могут быть проблемы? )))
Ты вообще с чем там спорил-то? Ты точно читаешь, что я пишу?

WH>Теперь используя только getMVar и putMVar реализуй readMVar.
WH>Который читает значение, при этом не забирает его.
WH>Доступа к семафорам у тебя нет. Использовать можно только публичный интерфейс.

Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.

Или там есть какой-то "встроенный" прикол? (Всё-таки подобную степень идиотизма предположить с ходу мне сложновато)
Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).

Например, мы в АПИ своих продуктов (low-latency middleware) стараемся избегать таких методов, т.к. это будет профанация, а не АПИ. Межпоточные дела, по-хорошему, должны работать в стиле push, генерируя последовательность событий. Тогда у клиентов библиотек не будет пространства для детских ошибок.

V>>Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...
WH>Ты понимаешь что, используя одни примитивы можно получить другие.
WH>Это уже прогресс.

Сорри, но это уже разочарование в уровне состоявшегося обсуждения...
Мне как-то сложно было сориентироваться, что ты решил по азам пройтись...

WH>Но твоя зацикленность на листьях просто поражает. Вместо анализа модели ты начал анализировать одну из возможных её реализаций.

Да ты читай меня внимательней и будет тебе счастье. Я все карты выложил сразу же:
— стоит задача передачи данных м/у потоками.
— вопрос стоит в минимально-необходимом кол-ве независимых примитивов синхронизации (этот вопрос стоит в любом многопоточном сценарии).
Сей вопрос я тебе задавал многократно, но увы... мы уже способны мыслить только "высокоуровнево".

WH>При использовании HTM реализация будет сильно другая. И весь твой анализ сразу отправляется в мусор.

Не будет, увы. HTM ты можешь проэмулировать прямо сейчас, разбив машинное слово на поля и пользуя цикл обновления CAS. От двух (минимум) независимых примитивов синхронизации не убежишь никак. Рядом уже написал чуть подробнее.

WH>А теперь попробуй представить страшное... MVar реализован процессором. И других примитивов синхронизации в железе нет.

Упс! Наконец-то ты попался. Причем, именно там, где я тебя и поджидал:

По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.
Но ты оч быстро бегаешь, не вышло. По сути предмета я имею ввиду механизм ожидания на этом счетчике, реализованный через шедуллер ОС.

В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))

Здравствуйте, vdimas, Вы писали:

WH>>Поздравляю. Ты реализовал getMVar и putMVar.
V>Дык, реализаций может быть много.
Я тебя не спрашивал про реализации. Я их сам могу придумать больше чем ты.
Я вижу, что ты не понимаешь семантику MVar.
И прошу реализовать простейший механизм, который можно было бы реализовать элементарно, если бы это было правдой.

Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом.

(С)Re[36]: Оберон круче всех!
Но ты не можешь это сделать.

V>Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.
Мы тут обсуждаем твоё заявление, которое я процитировал выше.
Если бы MVar имел ту семантику, о которой ты говоришь, то readMVar реализовывался бы элементарно.
Но ты это сделать не в состоянии.

V>Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).
Есть сценарии когда это осмысленно.

V>Сорри, но это уже разочарование в уровне состоявшегося обсуждения...
V>Мне как-то сложно было сориентироваться, что ты решил по азам пройтись...
Ессно я пошёл по азам. Ты же их не понимаешь.
Ты их зазубрил, но не понял.

V>В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))
Ты просто фантастически безграмотен. Все что нужно это передача управления ОС когда MVar залочился.
Тебя, надеюсь, не удивляет что загрузка страниц памяти из свопа не в процессоре реализовано.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, vdimas, Вы писали:

V>Заодно держи список проектов, обленившийся зануда:
V>http://oberoncore.ru/wiki/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

V>Не знать про ГЛОНАС — это залет, курсант. Хотя я про спутники намекал не раз... И не знать, кто и для чего изначально разработал популярный сейчас для VS2010 шрифт Excelsior это тоже муа... и далее по тексту.

Как человек который там работает говорю нет там никакого Оберона, может на Оберон смотрели, когда был переход с ассемблера, но сейчас его там нет.

А вот Модула-2 есть, правда тоже не в чистом виде, с расширениями — ассемблерные вставки, передача по ссылке как константу (что-то типа const & в C), препроцессор примерно как в C#, кое какие расширения по управлению инициализицией модулей — может еще чего забыд редко используемое.

... << RSDN@Home 1.2.0 alpha 5 rev. 55>>

Здравствуйте, WolfHound, Вы писали:

WH>>>Поздравляю. Ты реализовал getMVar и putMVar.
V>>Дык, реализаций может быть много.
WH>Я тебя не спрашивал про реализации. Я их сам могу придумать больше чем ты.
WH>Я вижу, что ты не понимаешь семантику MVar.

Мде? Давай ревью приведенной реализации, покажи в ней ошибки.

WH>И прошу реализовать простейший механизм, который можно было бы реализовать элементарно, если бы это было правдой.
WH>

WH>Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом.

WH>(С)Re[36]: Оберон круче всех!
WH>Но ты не можешь это сделать.

Я уже показал, как это сделать. А ты дергаешь слова из контекста, как всегда, впрочем. Там было сказано, мною же, про межпоточную передачу данных. Так вот, на одном примитиве синхронизации ты это сделаешь только тогда (опять же было сказано), когда сам доступ к переменной атомарный — например, если хранятся только боксированные типы и чтение/запись на платформе атомарны. Ну и опять же, та фраза была сказана не в контексте разбора работы MVar, а в контексте спора — мутабельная ли эта переменная или нет. Сам характер блокировки там не оговаривался. Я вообще не в курсе, какой был смысл обсуждать механизм MVar, если независимо от логики блокировки у нас остаётся мутабельная переменная?

Ну и, про некий составной тип из двух MVar я тебе уже сказал. На нем в точности можно воспроизвести логику обычной CRITICAL_SECTION (если не придираться к эффективности). То бишь, имеем что имеем — внесение банальных привычных мутабельных переменных, обложенных локами, в священную иммутабельную корову — Хаскель. Вот тебе вся твоя "особенная" многопоточность для Хаскеля. Привычный синхронизируемый императив.

V>>Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.
WH>Мы тут обсуждаем твоё заявление, которое я процитировал выше.
WH>Если бы MVar имел ту семантику, о которой ты говоришь, то readMVar реализовывался бы элементарно.

Это ты сам с собой споришь. Я не приводил на тот момент подробной механики работы MVar, чтобы ты делал хоть какие-то выводы. Зато намекнул на conditional variables, которые легко делаются на MVar. Ты, надеюсь, в курсе, что "честные" ConditionalVariables на одном мьютексте воспроизвести невозможно?

В общем, речь там шла лишь о той самой "философии" работы с многопоточностью. А коль ты упорно зацепился за механику — я тебе её привел: http://www.rsdn.ru/forum/philosophy/4889023.1. Есть желание обсуждать мои слова, а не свои фантазии — обсуждай. Нет — нет.

WH>Но ты это сделать не в состоянии.

Гы-гы. Прекрасный образец причины, которая мешает тебе трезво/критично мыслить последние годы. Молодца.

V>>Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).
WH>Есть сценарии когда это осмысленно.

Нету.

(Если раскрыть тему:
А толку, если гарантий никаких? Т.е. абсолютно никаких. Т.е. зачем тогда Хаскель, если его берут исключительно из-за гарантий, даваемых языком?
Итого: самостоятельных подобных безопасных сценариев в природе нету. Эта операция безопасна лишь будучи управляемой дополнительной блокировкой обязательного объемлющего сценария.)

V>>Сорри, но это уже разочарование в уровне состоявшегося обсуждения...
V>>Мне как-то сложно было сориентироваться, что ты решил по азам пройтись...
WH>Ессно я пошёл по азам. Ты же их не понимаешь.
WH>Ты их зазубрил, но не понял.

Гы-гы. А мне тут кажется нечто другое. Обычная поверхностность и желание уколоть собеседника хоть чем-то. Ты же влез не туда и спорил не о том, о чем был спор. Изначально я утверждал и возможноти многопоточности лишь на продолжениях в среде честной иммутабельности... А как только я, так и быть, пошел у тебя на поводу, т.е. решил таки пообсуждать навязанную тобой тему относительно механики происходящего (а не общий взгляд на происходящие вещи), ты опять убежал. В общем, это уже никакой не фан для меня, т.к. бестолковость твоих манер ведения споров превышает разумные пределы. Слишком быстро скачешь. Лишний раз отвечать тебе банально лень. Напишешь мало — ты будешь гадать за собеседника. Напишешь много — ты будешь бегать исключительно по верхам и придумывать своей беготне оправдания, одно нелепее другого. Утомил уже.

V>>В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))
WH>Ты просто фантастически безграмотен. Все что нужно это передача управления ОС когда MVar залочился.

Вот, второй раз подряд ты попался, именно где тебя ждут.

WH>Тебя, надеюсь, не удивляет что загрузка страниц памяти из свопа не в процессоре реализовано.

А ты пошевели на досуге извилинами, что же это за "передача управления ОС когда MVar залочился". И в чем вообще заключается процесс "залочивания". А то, может, эти механизмы давно есть в твоем проце, только никто их не называет MVar?

(Характерно, что все подсказки я дал буквально здесь же... и ты всё-равно опять вляпался).

	От:	vdimas
	Дата:	04.07.12 16:30
	Оценка:	36 (3) +1

От:	Mamut	http://dmitriid.com
Дата:	04.07.12 21:20
Оценка:

	От:	vdimas
	Дата:	04.07.12 21:44
	Оценка:	+1

	От:	Cyberax
	Дата:	05.07.12 05:26
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	05.07.12 07:07
Оценка:	+1 -1

От:	Владимир Паронджанов	http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата:	05.07.12 16:35
Оценка:

	От:	Klapaucius
	Дата:	09.07.12 10:54
	Оценка:	8 (1) +2

	От:	grosborn
	Дата:	11.07.12 08:26
	Оценка:	1 (1) +1 -1

	От:	WolfHound
	Дата:	20.07.12 14:01
	Оценка:	100 (2)

От:	Философ	http://vk.com/id10256428
Дата:	20.07.12 19:16
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	21.07.12 10:12
Оценка:

От:	VladD2	www.nemerle.org
Дата:	21.07.12 22:12
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	23.07.12 08:39
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.07.12 12:02
Оценка:	+1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	24.07.12 11:34
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.07.12 13:13
Оценка:

	От:	Иван Дубров
	Дата:	01.08.12 00:44
	Оценка:	+2

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	10.09.12 12:05
Оценка:

От:	SenorProgramador	riogamestudio.com
Дата:	11.09.12 01:07
Оценка:	-2

	От:	Дьяченко Александр
	Дата:	25.09.12 18:02
	Оценка: