локальные переменные в отдельной декларативной части

[ilovb]

Почему же не то? бряк - это goto. Как раз в тему.
А еще там числится

Bohm, Corrado; and Giuseppe Jacopini (May 1966). «Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules

ps Меня несколько настораживает твоя слепота. Только не говори что тоже не видишь разницы между оператором перехода и оператором повторения. В этом случае говорить не о чем.

[valexey_u]

Почему же не то? бряк - это goto. Как раз в тему.
А еще там числится

Bohm, Corrado; and Giuseppe Jacopini (May 1966). «Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules

ps Меня несколько настораживает твоя слепота. Только не говори что тоже не видишь разницы между оператором перехода и оператором повторения. В этом случае говорить не о чем.

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

Но еще раз - никто эксперимента доказывающего что goto (пусть будет даже goto, не break) влияет на качество кода (и влияет отрицательно) не поставил. Даже тот, дикий goto что был лет 40-50 назад. Да доказаны теоремы, разработаны методики как с ним бороться. Но самое важное не изучено никак.

[valexey_u]

Кстати, о КАПСе - читаю я код Вирта читаю, и напарываюсь на вот такое:

Код: [Выделить]

        IF ch = ESC THEN
          N.id := neutralize; Viewers.Broadcast(N); FadeCursor(Pointer); LED(0)
        ELSIF ch = SETSTAR THEN ...

И по инерции думаю - что это за два новых ключевых слова в языке - ESC да SETSTAR, ужель Вирт еще и их в язык добавил?

[Geniepro]

С++ описан все же лучше и полнее чем Оберон в репорте.

Про это лучше у Зуева поспрошать... 

Зуев все же компилятор Оберона писать не пробовал :-)

Но зато он вроде компилятор Зоннона делал на сишарпе...

[ilovb]

То что было при нем - это жесть содомия и угар в чистом виде. И именно с ним он боролся.

Судя по этим словам, ты не до конца понял с чем боролся Дейкстра.
GOTO плох не тем, что с его помощью легко получить макароны. Это лишь следствие.
Плохо когда программист думает goto'ами.

[valexey_u]

То что было при нем - это жесть содомия и угар в чистом виде. И именно с ним он боролся.

Судя по этим словам, ты не до конца понял с чем боролся Дейкстра.
GOTO плох не тем, что с его помощью легко получить макароны. Это лишь следствие.
Плохо когда программист думает goto'ами.

А чем это плохо? Это ж апофигей императивщины! :-)

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

[ilovb]

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

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

ps Почему ты функциональное программирование не ставишь под сомнение? Может нах. эти чистые функции?

[ilovb]

А чем это плохо? Это ж апофигей императивщины! :-)

А мы тут вроде про структурщину, а не про императивщину...

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

Проверяющий что?

[valexey_u]

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

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

Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).

ps Почему ты функциональное программирование не ставишь под сомнение? Может нах. эти чистые функции?

Откуда такие сведения?

[ilovb]

Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).

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

Откуда такие сведения?

Как минимум ты об этом не говоришь.

[valexey_u]

Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).

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

А откуда следует что отсутствие правил лучше их наличия? Еще раз: единственный судья - это эксперимент.

Откуда такие сведения?

Как минимум ты об этом не говоришь.

Говорю. Тем кто настаивает на том, что ФП и ФЯ лучше всего на свете и вообще является единственно верным путем.

Ладно, мне надоело говорить - это не продуктивно. Лучше пойду что-нибудь еще попилю. Не структурно :-)

[albobin]

Зуев все же компилятор Оберона писать не пробовал :-)

https://sites.google.com/site/zouev54/tekusie-proekty/oberon-for-net
Но результат усилий неизвестен

[Kemet]

Между прочим, ReactOS писана на 89 процентов на Си.  А с учетом того, что MSVS не умеет C99, становится очевидно почему же там переменные вначале блока объявляют - другие варианты этот язык просто не поддерживает.

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

[vlad]

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

Где? Обычный С без плюсов: http://svn.reactos.org/svn/reactos/trunk/reactos
Причем такие вещи (избавление от отдельной секции) просто так (just for fun) не переписываются - оно ж и так компилится. Т.е., даже если они переедут на С++, то сначала это будет смена расширения файлов, не более

[vlad]

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

Э... А я так и не понял - почему? Потому что всегда можно ограничить что-то конкретной длиной (например, 32 символа для идентификаторов)? Работать будет не всегда, зато просто?