Re: Оператор if должен умереть.
От: Владимир Паронджанов Россия http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата: 29.06.12 10:23
Оценка: :)))
Здравствуйте, michael_isu, Вы писали:

MI>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти... Только вот пока не додумал, как от него избавиться совсем. Какие варианты?


Согласен. Оператор if должен умереть. Вместе с ним должны умереть все другие управляющие операторы.
Именно так и сделано в языке ДРАКОН.
http://www.rsdn.ru/forum/philosophy/4749851.aspx?tree=tree
С уважением В. Паронджанов
Re[2]: Оператор if должен умереть.
От: Mamut Швеция http://dmitriid.com
Дата: 29.06.12 10:43
Оценка: 6 (1) +1 :)
ВП>Согласен. Оператор if должен умереть. Вместе с ним должны умереть все другие управляющие операторы.
ВП>Именно так и сделано в языке ДРАКОН.
ВП>http://www.rsdn.ru/forum/philosophy/4749851.aspx?tree=tree

Забаньте его уже кто-нибудь


dmitriid.comGitHubLinkedIn
Re[3]: ДРАКОН!!!
От: Qbit86 Кипр
Дата: 29.06.12 10:45
Оценка:
Здравствуйте, Mamut, Вы писали:

ВП>>Именно так и сделано в языке ДРАКОН.


M>Забаньте его уже кто-нибудь :maniac:


Ящетаю, пора уже форсить ДРАКОН в мемы.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Оператор if должен умереть.
От: BrainSlug Израиль  
Дата: 29.06.12 10:46
Оценка: :)))
Мне кажется он действительно открыл миру новую вещь, — ДГМ (Дракон головного мозга)
.
Re[4]: Оператор if должен умереть.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 29.06.12 11:59
Оценка: +1
Здравствуйте, BrainSlug, Вы писали:

BS>Мне кажется он действительно открыл миру новую вещь, — ДГМ (Дракон головного мозга)


Этот термин уже занят для поклонников Dragon Book, "спасибо" WolfHound'у.
The God is real, unless declared integer.
Re[5]: Оператор if должен умереть.
От: Владимир Паронджанов Россия http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата: 30.06.12 09:35
Оценка: :)))
Здравствуйте, netch80, Вы писали:

N>Этот термин уже занят для поклонников Dragon Book.


Уважаемый Валентин Нечаев!

Вы хорошо знакомы с одномерным (текстовым) структурным программированием.
Похоже, что Вы считаете его единственно возможным.
Но это не так.

Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.

Ниже даны пояснения:

1. Императивная (процедурная) часть языка ДРАКОН опирается на
новый метод – двумерное структурное программирование. Или, что
одно и то же, шампур-метод.

2. Правила двумерного структурного программирования существен-
но отличаются от традиционного одномерного (текстового) струк-
турного программирования.

3. Идеи структурного программирования разрабатывались, когда
компьютерная графика фактически еще не существовала и основ-
ным инструментом алгоритмиста и программиста был одномерный
(линейный или ступенчатый) текст.

4. До появления компьютерной графики методология текстового
структурного программирования была наилучшим решением.

5. С появлением компьютерной графики ситуация изменилась.
Появилась возможность заменить текстовые управляющие струк-
туры на управляющую графику, то есть использовать двумерное
структурное программирование.

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

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

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

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

10. Недопустимо запрещать правильный процесс мышления. Его надо
разрешить. Шампур-метод и язык ДРАКОН устраняют этот недос-
таток.

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


12. При визуальном структурном подходе программист работает толь-
ко с чертежом программы (дракон-схемой), не обращаясь к ее тек-
стовому представлению. Точно так же программист, работающий,
скажем, на Дельфи, не обращается к ассемблеру и машинному
коду – они для него просто не существуют.

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

14. ДРАКОН – это не просто новый язык (новое семейство языков).
Это новый взгляд на процедурное программирование. Если угод-
но – новое мировоззрение.

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

16. Язык ДРАКОН позволил эффективно решить эту задачу.

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

С уважением В. Паронджанов
Re[6]: Оператор if должен умереть.
От: batu Украина  
Дата: 30.06.12 10:02
Оценка: +1
Здравствуйте, Владимир Паронджанов, Вы писали:

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


N>>Этот термин уже занят для поклонников Dragon Book.


ВП>Уважаемый Валентин Нечаев!


ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием.

ВП>Похоже, что Вы считаете его единственно возможным.
ВП>Но это не так.

Вы про UML в курсе? Ваш дракон просто пустое место в смысле содержания. И вообще. Прислушивайтесь хоть чуток к в общем то не глупым людям
Re[6]: Оператор if должен умереть.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 30.06.12 13:15
Оценка: +1
Здравствуйте, Владимир Паронджанов, Вы писали:

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


N>>Этот термин уже занят для поклонников Dragon Book.


ВП>Уважаемый Валентин Нечаев!


ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием.

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

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

Вы ошибаетесь. Что бы это понять, нужно лишь выглянуть за пределы уютного "научного" круга, использующего ДРАКОН, ознакомитсья с другими парадигмами программирования, кроме структурного.
Re[6]: Оператор if должен умереть.
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 30.06.12 15:36
Оценка: :)
Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием.


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

http://www.gamedev.ru/code/forum/?id=19939

void main0()     void main1()
{                {

};               };
Ce n'est que pour vous dire ce que je vous dis.
Re[7]: Оператор if должен умереть.
От: Владимир Паронджанов Россия http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата: 30.06.12 16:14
Оценка: +1 :))
Здравствуйте, samius, Вы писали:

S>Похоже что вы считаете единственно возможным структурное программирование. Но это не так.


Уважаемый Алексей Шинкарев!

Я вовсе не считаю структурное программирование единственно возможным.

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


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


Не понимаю, где здесь ошибка. Да, я противопоставил одномерное и двумерное структурное программирование.
Первое всем известно.
А второе (как показывает обсуждение на форумах RSDN) воспринимается с большим трудом.

Я согласен с Вами, что, говоря о ДРАКОНе, надо обязательно сказать про следующие парадигмы:

1) императивное программирование;
2) процедурное программирование;
3) структурное программирование;
4) параллельное программирование;
5) Automata-based programming;
6) Automatic programming;
7) End-user development;
8) real-time programming
9) Time-driven programming;
10) Concurrent computing;
И др.

Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН?
Если у Вас есть замечания, буду благодарен за критику.
С уважением В. Паронджанов
Re[7]: Оператор if должен умереть.
От: Владимир Паронджанов Россия http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата: 30.06.12 16:40
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Боюсь, что вы немного отстали от жизни. В отечественной практике, в текстовом виде уже семь лет как пишутся далеко не только одномерные программы:


Уважаемый Алексей Бадалов!

Не согласен. В самом деле, я писал:

3. Идеи структурного программирования разрабатывались, когда
компьютерная графика фактически еще не существовала и основ-
ным инструментом алгоритмиста и программиста был одномерный
(линейный или ступенчатый) текст.


Вы не заметили слово "ступенчатый".
Вам не нравится слово "ступенчатый"?

Ладно, пусть будет по-вашему.
Скажем, интендация.

Не нравится "интендация"?
Ладно, я заранее с Вами соглашусь.

Выбирайте любой термин, какой считаете нужным.
Это что-нибудь меняет?

В литературе текст обычно называют линейным или одномерным.
Вам это не по душе?

Ради бога, я с Вами спорить не буду.

Но! Двумерное структурное программирование (используемое в языке ДРАКОН) — это 2D.
Two-dimentional.

Разве не так?
С уважением В. Паронджанов
Re[8]: Оператор if должен умереть.
От: Mamut Швеция http://dmitriid.com
Дата: 30.06.12 18:49
Оценка:
ВП>4) параллельное программирование;
ВП>7) End-user development;
ВП>8) real-time programming
ВП>10) Concurrent computing;
ВП>И др.

ВП>Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН?

ВП>Если у Вас есть замечания, буду благодарен за критику.

Для пунктов 4,7,8,10 Дракон не подходит совершенно.


dmitriid.comGitHubLinkedIn
Re[8]: Оператор if должен умереть.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 30.06.12 19:40
Оценка:
Здравствуйте, Владимир Паронджанов, Вы писали:

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


S>>Похоже что вы считаете единственно возможным структурное программирование. Но это не так.


ВП>Уважаемый Алексей Шинкарев!


ВП>Я вовсе не считаю структурное программирование единственно возможным.

Уже хорошо. А что вам дало повод считать так в отношении netch80?

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


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


ВП>Не понимаю, где здесь ошибка. Да, я противопоставил одномерное и двумерное структурное программирование.

ВП>Первое всем известно.
ВП>А второе (как показывает обсуждение на форумах RSDN) воспринимается с большим трудом.
С трудом понимаю вашу терминологию. Согласно определению, в основе структурного программирования лежит представление программы в виде иерархической структуры блоков. И я не вижу повода размышлять о мерности такого представления. Почему вы традиционное структурное программирование назвали одномерным? Структура блоков может быть достаточно сложна, что бы граф мог не быть планарным. И обычное текстовое представление кода неплохо с этим справляется при наличии развитой IDE. Кстати, текст не менее двумерен, чем картинка-схема.
То что второе (двумерное структурное программирование) воспринимается с трудом — в этом я согласен. Но восприятие — это вопрос многих переменных, в коих значатся автор кода, читатель кода, знакомство того и другого с технологиями и описываемыми процессами, опыт и т.п. Т.е. согласен считать что мои трудности с восприятием ДРАКОНа субъективны.

ВП>Я согласен с Вами, что, говоря о ДРАКОНе, надо обязательно сказать про следующие парадигмы:

Я ничего подобного не утверждал. Я считаю что рост научного знания в области структурного программирования отсутствует. Методология есть, а науки там нет. Во всяком случае с момента публикации теоремы Бёма — Якопини (1966).

ВП>1) императивное программирование;

ВП>2) процедурное программирование;
ВП>3) структурное программирование;
ВП>4) параллельное программирование;
ВП>5) Automata-based programming;
ВП>6) Automatic programming;
ВП>7) End-user development;
ВП>8) real-time programming
ВП>9) Time-driven programming;
ВП>10) Concurrent computing;
ВП>И др.

ВП>Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН?

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

ВП>Если у Вас есть замечания, буду благодарен за критику.

Возможно я вас неправильно понял. Может быть вы говорили о росте научного знания конкретно в области структурного программирования, а не программирования вообще, которое давно уже вышло за рамки структурного.
Re[9]: Оператор if должен умереть.
От: pagid Россия  
Дата: 30.06.12 21:32
Оценка:
Здравствуйте, Mamut, Вы писали:


ВП>>8) real-time programming

M>Для пунктов 4,7,8,10 Дракон не подходит совершенно.

А вот 8 вопрос интересный.
Вроде как объявлено использование, причем реальное использование, именно в real-time системах.

У меня возникло смутное подозрение, что в обсуждаемой отрасли в БЦВМ не используется система прерываний в принципе. Все от чего могли бы они исходить просто опрашивается в цикле.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[9]: Мерность как самостоятельная характеристика
От: VladZharinov  
Дата: 01.07.12 05:39
Оценка:
Здравствуйте, samius, Вы писали:

S>С трудом понимаю вашу терминологию. Согласно определению, в основе структурного программирования лежит представление программы в виде иерархической структуры блоков. И я не вижу повода размышлять о мерности такого представления. Почему вы традиционное структурное программирование назвали одномерным? Структура блоков может быть достаточно сложна, что бы граф мог не быть планарным. И обычное текстовое представление кода неплохо с этим справляется при наличии развитой IDE. Кстати, текст не менее двумерен, чем картинка-схема.

Вы имели в виду что-то типа сказанного здесь?..
Re[10]: Оператор if должен умереть
От: Владимир Паронджанов Россия http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата: 01.07.12 08:56
Оценка: -1
Чтобы снять все вопросы, могу рекомендовать Вам прочитать мою книгу (всего 520 страниц).
Почти триста илллюстраций. У Вас будет полная ясность по языку ДРАКОН.

Книга продается на каждом углу.

Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с. — Иллюстаций 272.


http://www.dmk-press.ru/catalog/computer/programming/978-5-94074-800-7/
http://www.dmk-press.ru/catalog/computer/programming/978-5-94074-800-8_ebook/
http://www.ozon.ru/context/detail/id/17892959/
http://my-shop.ru/shop/books/1233931.html
http://www.labirint.ru/books/344259/
http://shop.armada.ru/books/344259/
С уважением В. Паронджанов
Re[6]: Оператор if должен умереть.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.07.12 09:31
Оценка: +4
Здравствуйте, Владимир Паронджанов, Вы писали:

N>>Этот термин уже занят для поклонников Dragon Book.

ВП>Уважаемый Валентин Нечаев!
ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием.
ВП>Похоже, что Вы считаете его единственно возможным.
ВП>Но это не так.

Уважаемый Владимир Паронджанов!

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

Поэтому я могу пока что квалифицировать Ваш комментарий в мою сторону только одним из двух следующих вариантов: 1) Вы чрезмерно обидчивы и видите какой-то "наезд" на своё детище даже там, где такого не предполагалось и не высказывалось, 2) Вы используете любой повод для высказывания своей позиции, даже там, где его нет.

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


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

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

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

Я чуть больше поясню свой интерес здесь. Моя основная работа сейчас связана с VoIP. Средства управления в VoIP, такие, как SIP — это сложные программные комплексы с нетривиальной логикой, которая собрана в логические уровни. Например, в случае SIP есть уровень приложения, уровень сессии, уровень диалога, уровень транзакций, уровень транспорта. Каждый из них на простом уровне понимания может быть представлен как машина состояний (конечный автомат) с логикой, определяемой внешними и внутренними событиями. Конечно, если я попытаюсь представить логику одного элементарного звена в виде блок-схемы, что-то получится; но это представление будет неэффективно — в том смысле, что неадекватно задаче и из блок-схемы не получится получить ни одного специфического для автомата результата (начиная с тривиальщины вроде нахождения неиспользуемых состояний). Попытка же представить функционал полной программы в виде блок-схемы 1) обречена на получение конструкции, которая влезет разве что на экран в две комнатные стены, 2) ничего не даст для понимания собственно логики. Логичный риторический вопрос — зачем мне тут рисовать блок-схему?

Другой пример — организация структуры данных в памяти. Представим себе больничную базу данных. Обнаружено, что каждая запись о посещении врача содержит ФИО пациента вместо ссылки на общую карточку пациента, то есть присутствует бессмысленное и потенциально диверсионное (в случае опечаток, например) дублирование данных. Чтобы хорошо представить себе структуру данных и найти в ней подобные проблемы, нужно нарисовать именно структуру данных. Блок-схема этому никак не поможет, в ней родственные пункты будут разнесены по чрезвычайно далёким местам.

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

Если всё это у вас есть, то я его не нашёл — видимо, слишком хорошо спрятано.

ВП>1. Императивная (процедурная) часть языка ДРАКОН опирается на

ВП>новый метод – двумерное структурное программирование. Или, что
ВП>одно и то же, шампур-метод.

Что скрывается за этим красивым названием и почему шампур?

ВП>3. Идеи структурного программирования разрабатывались, когда

ВП>компьютерная графика фактически еще не существовала и основ-
ВП>ным инструментом алгоритмиста и программиста был одномерный
ВП>(линейный или ступенчатый) текст.

Простите, а разве ничего не значит, что в то же самое время рисовали блок-схемы вручную для разработки и контроля алгоритма? И что советские правила приёма программ просто требовали наличия этих блок-схем даже там, где они были бессмысленны?
Тогда что именно вы привнесли? Графическое средство для автоматизации того, что делалось вручную, пока имело смысл, но дальше потеряло этот смысл?

ВП>4. До появления компьютерной графики методология текстового

ВП>структурного программирования была наилучшим решением.

Не была она наилучшим решением. Она была одна из и далеко не исходной.

ВП>14. ДРАКОН – это не просто новый язык (новое семейство языков).

ВП>Это новый взгляд на процедурное программирование. Если угод-
ВП>но – новое мировоззрение.

Которому лет 50, мне кажется.

ВП>17. Одно временно была решена задача эргономизации блок-схем, то

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

Мне кажется, во всей разработке это единственно ценная часть, как для прикладного программиста. Остальное — а именно, ориентация на блок-схемы — пригодна только для обучения студентов, и то как вспомогательное средство.
The God is real, unless declared integer.
Re[2]: Светофор
От: Qbit86 Кипр
Дата: 01.07.12 09:59
Оценка:
Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Именно так и сделано в языке ДРАКОН.


Здесь на рисунке 88 ошибка. На светофоре жёлтый после красного включается до того, как выключится красный. Т.е. у светофора по ПДД четыре сигнала (кроме ночного режима): зелёный, жёлтый, красный, красно-жёлтый.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Светофор
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.07.12 10:09
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здесь на рисунке 88 ошибка. На светофоре жёлтый после красного включается до того, как выключится красный. Т.е. у светофора по ПДД четыре сигнала (кроме ночного режима): зелёный, жёлтый, красный, красно-жёлтый.


Это совершенно непринципиально, jIMHO, для объяснения метода. Нужно будет — дорисуют.

Тем более что в разных странах разные традиции. Например, у нас принят мигающий зелёный, а в ГДР я видел в той же роли жёлто-зелёный. Или, в Барселоне, похоже, "ночной режим" с мигающим жёлтым не включается принципиально (в 4 утра точно так же переключается, как обычно), но совершенно обычно, что на перекрёстке на выезде с какой-то улицы в одной фазе горит красный, а в другой — мигающий жёлтый (мол, езжайте, но осторожно и всех пропускайте). А над пешеходным светофором там тоже мигающий жёлтый (ну любят они его) для машин, которые подъезжают и должны пропускать пешеходов.

А в Броварах (под Киевом) были светофоры, где ввели мигающий зелёный так, что зелёный по одному направлению и красный по другому это один и тот же сигнал на выходе с блока управления, так что там не было красно-жёлтого, но красный мигал перед переключением.
The God is real, unless declared integer.
Re[4]: Светофор
От: Qbit86 Кипр
Дата: 01.07.12 10:13
Оценка:
Здравствуйте, netch80, Вы писали:

N>Это совершенно непринципиально


Разумеется.

N>Тем более что в разных странах разные традиции.


Но логика одна: читая «промежуточный» сигнал светофора, водитель должен понимать, что за ним последует — разрешающий или запрещающий сигнал.
Глаза у меня добрые, но рубашка — смирительная!