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

M>Предлагаю показательно забанить Сергея Губанова о следующим пунктам:

Кстати, обратите внимание: единственный минус этому сообщению поставил С. Губанов

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

AVC>Очень мило.
AVC>Вы предлагаете написать код, но не формулируете ни его смысла, ни условий его эксплуатации.
AVC>Я не знаю происхождения Вашего кода, но сдается мне, что "принципу черного ящика" (интересно, каков он в Вашем понимании?) он определенно не соответствует.

Я не предлагаю написать код. Я его уже написал и предлагаю оттранслировать в эквивалентный на обероне. Ввиду того, что по приведенному куску мы не можем точно, со 100% вероятностью утверждать что делается и, главное, чего не делается в теле той или иной используемой в нем функции (тот самый "черный ящик"), перестраивать алгоритм в соответствии с нашими "догадками" — в принципе неверно. Именно поэтому говорить "ну из очереди наверное ничего не удаляется, поэтому изменим алгоритм так-то и так-то" — некорректно. Так мы можем дойти до предположения, что все вызываемые в коде функции — "пустышки", а все проверяемые значения — ложны, после чего он автоматически выльется в LOOP EXIT END и мы сможем восславить гениальность оберона, позволившего сократить код до одной строчки.

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

AVC>И вызов функции, и ее определение требуют круглых скобок, даже если функция вызывается без параметров.

Стоп-стоп-стоп! Отсюда поподробнее. Значит скобочки рядом с вызовом функции без параметров в обероне таки тоже нужны? В таком случае настоятельно прошу автора топика переписать весь код в этой

Автор: Сергей Губанов
Дата: 09.06.05

мессаге в соответствии с этим [вдруг всплывшим] требованием, пересчитать оверхед по лексемам и перерисовать "звездочные" диаграммы. Что-то сдается мне и оверхед поменьше заявленного будет, да и черелование лексема-идентификатор-лексема-идентификатор куда-то сразу исчезнет.
Для примера один кусок попробую преобразовать сам:

C++

while(a) x();

Лексем — 6
Строк — 1 (или три — с фигурными скобками в K&R-style)
Диаграмма — * * a * x * * *

Оберон:

WHILE a DO x() END

Лексем — 5
Строк — 1 (или три — как запишешь)
Диаграмма — * a * x * * *

Оверхед по лексемам — 20%, по строкам — 0%

Может хватит уже ерундой заниматься?

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

AVC>Даже неловко как-то. Ну ладно.
AVC>Кстати, можно заодно вопрос: а если в самом начале pItem = NIL?

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

Зачем-то и почему-то я в условии цикла написал pItem->Next вместо pItem А это обычная логическая ошибка.

Если писать просто pItem, то дополнительно проверять ничего не нужно. Зачем? Если он нулевой, while не пробежится ни разу.

AVC>Думается, лучше проверить. Получаем:
AVC>

AVC>WHILE (pItem # NIL) & ~CheckItem(pItem) DO pItem := pItem.Next END;
AVC>

AVC>А почему на Си++ нельзя сделать так же?
AVC>

AVC>while (pItem && !CheckItem(pItem))
AVC>    p = pItem->next;
AVC>

Можно. Однако имеет смысл только для одной проверки. Ну двух. А если точек выхода десяток (по найденному, по обнаруженному битому, срочно по переключению мютекса и т.п.)? И если, как уже приводилось где-то выше по треду, нужно перед выходом по каждому условию выполнить некоторые действия? Запихать это в одну строчку с while нереально, кроме как завести какую-то дополнительную булевскую переменную Work. И что мы получим без break?

Work = 1;

while (pItem && Work)
{
    // Начинается всё неплохо...
    if (IsBadItem(pItem))
    {
        // Что-то делаем...
        LogErrorMessage(something);
        SetErrorState(something);
        Work = 0;    // Напоминаю, без break-а
    }
    
    // А вот здесь уже пойдёт веселье.
    // CheckItem() нельзя вызывать для "плохого" объекта
    if (Work && CheckItem(pItem))
    {
        // Нужно вернуть объект
        // Допустим, для дальнейшего использования сохраняем указатель
        pFounded = pItem;
        Work = 0;
    }
    
    // Вываливаться по внешнему сигналу от другого потока уже как-то нехорошо
    // если уже нашли или была ошибка при проверке
    if (Work && CancelCommand())
    {
        // Ну хоть здесь можно с чистой совестью просто вывалиться из всей функции
        return NULL;    // Что мы там возвращаем и как... NULL...?
    }

    pItem = pItem->Next;
}

И здесь же я сам себе и возражу: ничто не мешает сразу после Work = 0 написать continue — снова перейдём к условию, проверим его, и естественным путём вывалимся из цикла с тем самым ~p. Да. Получается. Теорема доказана (если, конечно, и на continue тоже вето не наложено). Но код тогда лишь немногим лучше данного выше примера... Ставится какая-то переменная и повторяется цикл. Изврат как с точки зрения читающего (ещё подняться к условию цикла и проверить, что мы это делали именно с целью выхода), так и с точки зрения оптимальности (лишний раз проверим условие цикла).

// Стройнее, но немногим лучше
Work = 1;

while (pItem && Work)
{
    if (IsBadItem(pItem))
    {
        // Что-то делаем...
        LogErrorMessage(something);
        SetErrorState(something);
        Work = 0;    continue;
    }
    
    if (CheckItem(pItem))
    {
        pFounded = pItem;
        Work = 0; continue;
    }
    
    if (CancelCommand())
    {
        return NULL;
    }

    pItem = pItem->Next;
}

Далее:

AVC>Бог мой, какая трудная задача!
AVC>

AVC>IF dwCount > 0 THEN i := 0;
AVC>  REPEAT
AVC>    WorkWithObject(pObject[i]);
AVC>    INC(i)
AVC>  UNTIL (i = dwCount) OR (CalculateStat() > SOME_VALUE)
AVC>END;
AVC>

AVC>Может быть, Вам не нравится, что переменная i видна за пределами конструкции?

Нет, я же просил — без уродств с ручной эмуляцией цикла for и лишней предварительной проверкой. Не подходит. Опять же в случае множества условий не получится проверить всё в условии цикла и придётся переносить проверки внутрь. И начинаются загибы со счётчиком i. Допустим, во всё-таки размещённый в условии until CalculateStat() нужно передать значение счётчика. Будете вызывать как CalculateStat(i-1)? Нигде не напутаете? Не будете думать потом, зачем оно нужно? А если i как раз добежала до dwCount? С таким порядком условий CalculateStat() просто не будет вызвана, а ведь нам может быть важен результат её работы. Надо поменять условия местами и молиться, чтобы никто не переписал этот участок с неправильной расстановкой.

Да, и главное: мы везде предполагаем бинарность, т.е. функция возвращает "успех" или "облом", true или false. А если возвращаемых значений больше, и при этом каждое из них важно? Тоже как минимум в условие самого цикла не засунуть...

Читаемость во всех случаях просто никакая. А лишнее доказательство теорем — да не спорю я с давно доказанными теоремами! Вы можете быть своего мнения о моём IQ, но он всё же не настолько низок , равно как и не настолько высок для подобных претензий на открытия. Великая Теория Ненужности break, несомненно, будет ещё раз доказана. Только эффекта — как от доказательства ненужности носков по причине наличия портянок

AVC>

AVC>  PROCEDURE WorkWithObjects;
AVC>    VAR i: INTEGER;
AVC>  BEGIN
AVC>    FOR i := 0 TO dwCount DO
AVC>      WorkWithObject(pObject[i]);
AVC>      IF CalculateStat() > SOME_VALUE THEN RETURN END
AVC>    END
AVC>  END WorkWithObjects;
AVC>...
AVC>WorkWithObjects;
AVC>

А вот это интересный выход Мне нравится, правда. Ручная реализация break

AVC>Да-да, Сергей, не делай так, как Amidlokos!

Тогда уж и как AVC... Код-то практически одинаковый Нет, я правда не понял призыва: не делать КАК? Не использовать break? Кхм, ну что ж... Не писать такого кода в принципе? Так здесь чистый псевдокод, я же не исходник сюда кидаю.

А вообще чего нам вдвоём надо не делать — так это не флеймить. И я-то, каюсь, не удержался... наезда на break не выдержал

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mr. None, Вы писали:

MN>> или на что вы знаете ответ...

СГ>Я действительно отвечаю только на то на что ответить могу. Вообще-то это тавтология, так как нельзя ответить на то на что ответить не можешь.

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

MN>>Четврётого варианта я не вижу.
СГ>Он есть.
Сомневаюсь. См. ниже.

СГ>1) Если компилятор + рантайм Оберона уже написан на чем-то, то переписать его на самом Обероне можно.
А если компилятора + рантайма ещё нет? Всё — дальнейшие рассуждения можно пропустить, потому что проводя "раскрутку" в обратную сторону мы таки приходим к варианту 1 или 2. Ещё раз повторяю — другого не дано! Первый компилятор не компилировался, а набирался сразу в машинных кодах, ибо компилировать было ещё не начем.

СГ>Этот процесс создания компилятора+рантайма Никлаус Вирт назвал словом "раскрутка". Собственно, в результате раскрутки и был создан первый язык Оберон + его компилятор + операционная система Оберон.

То что вы описываетет сводится к варианту 2...

MN>>Варианты ответа 1 и 2 атоматически означают, что сам по себе GC не защищён и может содержать ошибки, следовательно ошибка в GC не будет перехвачена обероном и приложение таки упадёт, будь оно хоть трижды надёжным (не знаю зачем вообще я это объясняю — это должно быть понятно всем и так). Вариант 3 не говорит ни о чём, кроме того, что вы не знаете и всё.

СГ>Вы правы. По этому поводу Никлаус Вирт как раз и ругал все эти дебагеры.
Ну вот опять... Я где-нибудь упоминал дебагеры? Причём тут дебагеры?

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

К>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Этот процесс создания компилятора+рантайма Никлаус Вирт назвал словом "раскрутка". Собственно, в результате раскрутки и был создан первый язык Оберон + его компилятор + операционная система Оберон.

К>Вау! Раскрутку оказывается святой Вирт придумал...

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

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

J>И соответствующее предупреждение компилятора:
J>

J>"ComeauTest.c", line 4: warning: use of "=" where "==" may have been intended
J>     if(i = 1);
J>        ^
J>

J>Скажи честно, тебе самому не надоело еще фигней заниматься?

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

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


AVC>Отсюда беспрерывные "откровения" вроде Вашего (со сравнением переменных) или уж откровенно глупого "оказывается, в Обероне есть BEGIN!!!". О перлах вроде "мне нас**ть на принципы структрного программирования" я уж и не говорю.

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

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

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

П> Если б вы знали, как прикольно мне, ни разу не игравшему это читать.


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

AVC>Отсюда беспрерывные "откровения" вроде Вашего (со сравнением переменных) или уж откровенно глупого "оказывается, в Обероне есть BEGIN!!!". О перлах вроде "мне нас**ть на принципы структрного программирования" я уж и не говорю.

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

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

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

AVC>>И вызов функции, и ее определение требуют круглых скобок, даже если функция вызывается без параметров.

П>Стоп-стоп-стоп! Отсюда поподробнее. Значит скобочки рядом с вызовом функции без параметров в обероне таки тоже нужны? В таком случае настоятельно прошу автора топика переписать весь код в этой

Автор: Сергей Губанов
Дата: 09.06.05

мессаге в соответствии с этим [вдруг всплывшим] требованием, пересчитать оверхед по лексемам и перерисовать "звездочные" диаграммы.

А там нет вызова функции. Там вызов процедуры.

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

Т>А там нет вызова функции. Там вызов процедуры.

То есть у оберона для процедуры с параметрами и без — разный синтаксис? А для функции с параметрами и без — нет? Чудны дела твои, господи...

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

CX>
CX>А ты японскую печатную машинку видел?

http://yuri.shilyaev.com/2005/01/11/234/kitayskaya-pechatnaya-mashinka.html

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Socrat, Вы писали:

S>>А еще типичная ошибка — вместо "==" в условии поставить "="...

СГ>Ну да, точно. Как-то забыл упомянуть. Спасибо что напомнили. За одно только это си-образный синтаксис не имеет права существовать...

Сравни:

while (*a++ = *b++);

и

LOOP 
  a[i] := b[j]; 
  IF b[j] = 0X THEN EXIT END;
  INC(i); 
  INC(j)
END

Язык с таким оверхедом вообще не имеет права существовать.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я для этого что-ли ошибку-то тут засвечивал? Я ее тут засвечивал для того чтобы показать, что в Modula/Oberon-образном синтаксисе ошибки таких сортов невозможны.


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

a [i++] = b;

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

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

А если так?

for (Work = 1; pItem && Work; pItem = pItem->Next)
{
    if (IsBadItem(pItem))
    {
        // Что-то делаем...
        LogErrorMessage(something);
        SetErrorState(something);
        Work = 0;    // Напоминаю, без break-а
    }
    
    else if (CheckItem(pItem))
    {
        // Нужно вернуть объект
        // Допустим, для дальнейшего использования сохраняем указатель
        pFounded = pItem;
        Work = 0;
    }
    
    else if (CancelCommand())
    {
        // Ну хоть здесь можно с чистой совестью просто вывалиться из всей функции
        return NULL;    // Что мы там возвращаем и как... NULL...?
    }
}

Здравствуйте, Сергей Губанов, Вы писали:

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

C>>Угу, поэтому все академические разработки весьма успешно загибаются.

СГ>Между прочим, Java и .NET есть коммерческие реализации идей опробованных на оберонах.

Ты про число лексем?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, moudrick, Вы писали:

M>> требования современных виртуальных оберон-машин.

СГ>Каких еще виртуальных? Это у Java есть виртуальная машина, не путайте.

Зря ошибке номер дали. Это не убеждение, не утрерждение. Это просто высказывание.

Я как автор данного высказывания квалифицирую его как стеб.

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

M>>Просьба к коду не придираться

AVC>Да Бог с ним, с кодом; какая разница, ведь Вы просто не знаете языка.
AVC>И в Си++, и в Обероне в данном случае сравниваются переменные.
AVC>И вызов функции, и ее определение требуют круглых скобок, даже если функция вызывается без параметров.

О! Я этого не знал, но! Нигде (ни в постах Сергея, например, ни даже в примерах на ETH) не указано такое требование.

Например

PROCEDURE PrintGadget*;
VAR S: Display.SelectMsg; P: Display.DisplayMsg; obj: Objects.Object;
BEGIN
  Printer.Open("LPT1", "");
  Out.String("Printing gadget"); Out.Ln;
  S.id := Display.get; S.F := NIL; S.obj := NIL; S.time := -1;
  Display.Broadcast(S);
  IF (S.time > 0) & (S.obj # NIL) THEN
    obj := S.obj;
    P.device := Display.printer; P.id := Display.contents; P.F := obj(Display.Frame);
    P.res := -1;
    Display.Broadcast(P);
  END
END PrintGadget;

Только посмотрев в описание модулей можно понять, что Out.Ln — процедура, а Display.get — это переменная

Более того, в EBNF Оберона записано следующее:

...
statement  =  [assignment | ProcedureCall | 
    IfStatement | CaseStatement | WhileStatement | RepeatStatement | 
    LoopStatement | WithStatement | EXIT | RETURN [expression] ].
...
ProcedureCall  =  designator [ActualParameters].

То есть скобки не нужны при вызове

AVC>В Си++, например, напротив, конструктор без параметров не должен иметь скобок, чтобы компилятор не принял его за прототип функции.
AVC>Понимаете, в чем закавыка. Я программирую как на Си++, так и на Обероне. (Оберон мне нравится больше, но для того, что я хочу Вам сказать, это не имеет значения.)
AVC>В то же время ни Вы, ни большинство других "оппонентов" (какими они зачастую себя только воображают) Оберона не знают и на нем не пишут.



AVC>Отсюда беспрерывные "откровения" вроде Вашего (со сравнением переменных) или уж откровенно глупого "оказывается, в Обероне есть BEGIN!!!". О перлах вроде "мне нас**ть на принципы структрного программирования" я уж и не говорю.

Ну, на принципы эти мне не неср*ть в общем случае Дело в том, что слишком часто от того же принциа "одна точка входа — одна точка выхода" необходимо отходить, потому что следование ему приводит к усложнению программы.

На самом деле меня интересовал (в этой подветке) всего один вопрос — почему недопустимо более одной точки выхода из циклов FOR и WHILE в Обероне и почему необходимо было вводить цикл LOOP (он уже нарушает принцип структурного программирования Дейкстры).

AVC>Я отношусь к Вам с уважением и часто с удовольствием читаю Ваши посты.
AVC>Поэтому мне жаль видеть Вас среди людей, которые, зная горячность Сергея (Губанова), нарочно "заводят" его, имитируя непонимание даже очевидных вещей, а затем откровенно издеваются над ним.

Сожалею, если возникло такое ощущение

AVC>Видели бы вы все себя со стороны!
AVC>Попробуйте сами объяснить для себя присутствие столь многих и столь заведомо необъективных и даже откровенно злых людей на этом форуме, если эта тема так им неинтересна, если Оберон — такой уж плохой язык?

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

AVC>Можете рассматривать это как "открытое письмо".