DRAKON.SU

Нормальные архитектуры (вот специально провоцирую, что-то вредный я сегодня ) давно уже непосредственно ориентированы на конструкции ЯВУ (можно считать, на Алгол-семейство).
viewtopic.php?f=26&t=823
http://oberoncore.ru/library/start (книги про Эльбрус)
И Модула-, Оберон- процессоры тоже.

А ещё есть dataflow-архитектуры. В частности, работы покойного В.С. Бурцева.

Много чего есть на свете
Принцип "надо делать по уму" пробивает себе дорогу всегда, постепенно вытесняя "технарство с разводным ключём" (понимаю под этим прикипание к милым сердцу случайным уродствам систем).

Безусловно, не что угодно. Но критерий истинности здесь вне пределов формализации, вне да-нет -ной логики.

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

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

О нет. В классической геометрии, вообще в строгих формальных системах именно в да-нет -ной логике.

Замечательно. Всеми четырьмя конечностями за. Мне вот очень понравился бы FORTH- процессор. Но я не вижу всех этих прекрасных вещей в виде компьютера у меня на столе. И офисах тоже. Ни в одном и ни у кого! И в мировом масштабе тоже! Между тем Интел и проч. почему-то десятки уже лет развивают GOTO-шную архитектуру, добавляя разрядность, новые регистры, кэширование, многоядерность- бог знает что ещё, но GOTO заложено в архитектуре железа и неприкосновенно! Такие там идиоты?

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

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

Истинность, как соответствие знаковых систем реальности, устанавливается не формально. Формально лишь устанавливается эквивалентность знаковых систем друг другу (и тогда уже, транзитивно, реальности). Типа того.

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

Вот-вот. А откуда ему взяться, чёткому техзаданию, если размытость начинается уже на этом уровне? (упомянутые Вами корпоративные стандарты, допустимые затраты.. добавим личные предпочения начальства..) То есть Господь Бог начинает свою "гуманитарную" игру в кости уже здесь, а продолжает в самой разработке (если задача не простейшая). Если "уйти"- то конечно да, но уйти не дано никому: вероятностность, размытость заложена в самой основе мира сего.

Не вижу логики, однако. Если есть go to, то им можно пользоваться. А если нельзя, то go to не нужен. Вон, Дейкстра ругается - мол, go to вносит такие наборы координат для описания процесса, что расхлёбывать намучишься. Поэтому давайте уберём go to отовсюду, кроме простого машинного кода. Да и впрямь - человеку оно зачем? Человеку надо, чтобы программа как можно точнее отображала реально происходящий процесс. Чем нарабатывать культуру использования go to, дешевле будет его выкинуть совсем и не мучать людей почём зря.

Ну, по Дейкстре, структурное программирование как раз и провозглашает отказ от go to, предлагая более человечные средства. Кстати, ссылочки:
http://www.cs.utexas.edu/users/EWD/tran ... WD215.html
и перевод:
http://www.vspu.ac.ru/~chul/dijkstra/goto/goto.htm

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

является удобочитаемым, но явно менее эффективным чем код

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

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

Смысл простой: я тоже за то, чтобы гото использовался как можно меньше. Согласен с кучей обоснований, приведенных выше, в пользу этого соображения. Но если приходится В КАКОЙ_ТО КОНКРЕТНЫЙ МОМЕНТ ломать мозг, чтобы избежать гото и применять нетривиальные и хитровымученные решения - я со спокойной совестью поставлю гото.
..
и меня всегда мучает вопрос: вот и ЯВУ, и ООП, и структурное программирование - чего только не придумали... НО! господа, за время моей сознательной дестельности на ниве программирования (1983 - настоящее) программы менее глючными не стали!!! Меня мучает вопрос - ПОЧЕМУ???

Потому что не смотря на рост числа программистов их квалификация в среднем падает.
А общественность этому способствует ("Освой C# за 21 день").

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

Мир не "там", мир - тут. Мир не сам по себе извращённый, это люди его делают извращённым.

При работе на КП не припомню случая, когда мне пришлось бы "ломать мозг". Итого скажу (делая предположение что Вы работаете на ЯВУ):

То что у Вас не получается пока писать программы без гото не ломая мозг никак не может быть доводом в пользу его необходимости (в ЯВУ).

Я вот выдвигаю возражения против go to не потому, что так сказал Сам Великий Учитель, а потому, что пытаюсь осмыслить суть происходящего со мной в процессе программирования.

Оператор go to - это гипертекстовый скачок, так ведь? Если принять, что программа описывает последовательность действий, то это нас приводит к вектору времени. Читая программу, мы выстраиваем координатную систему процесса и восстанавливаем временную цепь. А скачок go to нарушает последовательность и перебрасывает в другую систему координат.

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

Поэтому я считаю, что говорить об оправданности применения go to при наличии более совершенных средств выражения, не очень этично.

Москва тоже не сразу строилась.