OberonCore

Выделено из: viewtopic.php?p=58946#p58946

Настоящий мужик не должен бояться таких трудностей! Императивный стиль в программировании - это рай для домохозяек. За исключением тех случаев, когда он сам по себе создает проблемы, примером чего могут служить Бейсик и Фортран. Глубокое , и самое неочивидное, заблуждение сообщества т.н. "программистов" в том, что язык должен облегчать им процесс создания их шедевров. Отсюда и растут ноги проблемы сложности разработки ПО. Язык, сводящий управление памятью к манипуляциям с типизированными указателями на некоторые унифицированные структуры данных - лучшее средство отучиться думать бошкой. Дейкстра, как неспециалист , не разобравшись в вопросе, поспешил обозвать АПЛ - "ошибкой доведенной до совершенства". То же касается и прочих его заблуждений, касающихся стилистики программных конструкций.

Попытки облегчить жизнь разработчикам, предпринятые Дейкстрой и Виртом, очивидно , провалились. Произошло это потому, что , в данном случае, "проектировщиками" двигало приматическое желание достать банан наиболее простым способом. Как выяснилось, сбивать бананы с помощью универсального бананоуловителя , оказалось еще сложнее, чем без него. Книженки Майерса и Гаммы - тому пример. Вирту же следовало бы поменять местами словосочетания в названии своего классического опуса.

Появление С и Паскаля стало первым шагом к возникновению "узости восприятия" в компьютерном сообществе. Другим, современным, примером такого рода является небезызвестный Хасскел, и рекурсивное программирование в целом, обозванное почему-то "функциональным".

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

Передам.

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

А кстати, тут интересный пунктик.
Что значит тонкое замечание, сразу и мыселька забегала.

Про рекурсивное программирование то ж. Надо подумать.

Речь идет об одном и том же костыле. Только в случае С++ это механизированный костыль с дистанционным управлением для мажоров, а, в случае Оберона, аскетический костыль любителей военизированного мышления.

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

The narrative fallacy.

Все, что появилось после Бейсика и Фортрана, за исключением PL/I( о котором особая песня) - маршировка сужения восприятия. Это приводит к отсутствию творческого подхода, нежеланию рассматривать реализацию структур данных, как творческое действие, соответственно , к сужению взгляда на алгоритмы по обработке этих структур. В комплексе, это ведет к сужению взгляда на все начиная от интерфейсов пользователя и кончая способами организации программ (см. Гамма и проч.) А также, к выделению несовместимых подходов и жесткой дифференциации различных подобластей в программной инженерии. Наблюдается процесс обратного влияния данных схем на творческий процесс проектирования. Когда-то данные методики сами были творческим подходом, но превратившись в элементы синтаксиса языков, оказали отрицательное воздействия на развитие. Бейсик, например, не являлся попыткой борьбы со "структурной сложностью", таковые попытки бессмысленны с использованием будь какого инструментария. Дейкстра, кстати, это осознавал, однако его приматизм, все равно толкал его на поиски решения изначально неверно сформулированной задачи. То же касается и небезызвестного г-на Вирта.

Идите-идите... Мы еще вернемся к этому вопросу...

Это т.н. институализация. Пример абсолютно изоморфный институализации в российской политике г-на Путина сотоварищи, ранее рассматриваемый, как творческое проявление политической индустрии. Дейкстра - Путин в информатике.

Проошу извинения и Ильина, я не имел целью сказать гадость, это студенческий юмор, проклятое демократическое воспитание...

Банду Дейкстры - под суд времени! Давно пор разобрать откуда какие мифы взялись. В историческом контексте.

А может быть, исключение GOTO было сделано наоборот, чтобы подстегнуть креативность, реализуя тот же функционал с помощью указателей и самомодифицирующегося кода?))))) Как говорится, "настоящий программист может написать фортрановскую программу на любом языке".

Про MATLAB vs BlackBox: думаю, что не надо никакого vs, их же можно, как оказалось, прекрасно стыковать и программы на BlackBox в принципе вызываются из MATLABа как свои родные функции. Проблема лишь в отсутствии фирменного SDK.

Существует две параллельных оси развития языков. Первая основана на принципе выделения и институализации наиболее часто повторяющихся программных последовательностей состоящих из елементрных операций, а также на институализации очивидных структур данных, образующихся путем векторизации элементарных однородных элементов данных (что методологически сходно). Вторая базируется на фантастических идеях борьбы с т.н. "структурной сложностью", причины которой, рассматриваются каждой такой "научной школой" с субъективной точки зрения. В первом случае мы имеем естественную последовательность языков , каждый из которых обладает всеми достоинствами предыдущих, и не вносит парадигмальной сумятицы и не ограничивет точки зрения на вещи, это:
Ассемблер,Фортран,Бейсик, АПЛ и т.п.

Во втором случае это:
C, С++, Ада, Паскаль , Оберон, и (ха-ха) -Хаскелл(тут мы имеем поример , как раз резкого отличия в субъективном восприятии причин сложности) и т.п.

Первая ветвь естественна и научно обоснована, вторая неестественна , субъективна, и черпает свое обоснование из себя же самой.

GOTO, это не совсем то, что о нем возомнил Дейкстра.
Это действительно смешно.

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

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

А при чем здесь Дейкстра? Когда есть вполне официальное исследование Кнута по GOTO?
Knuth D.E. Structured Programming with GO TO Statements // ASM Computing Surveys. 1974. 6(4). P.261-301.
А еще раньше он исследовал проги фортрана на предмет количества goto и последствий этого для проги.
Knuth, D. E. «An Empirical Study of FORTRAN Programs», Software -Practice & Experience, vol. 1, pp. 105-133, 1971.

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