OberonCore
https://forum.oberoncore.ru/

Почему программа должна быть структурной
https://forum.oberoncore.ru/viewtopic.php?f=82&t=2348
Страница 7 из 8

Автор:  Info21 [ Четверг, 18 Февраль, 2010 07:02 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

AVC писал(а):
Info21 писал(а):
Ну, можно же забыть RETURN. (Или это не по части структурности?)

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

Автор:  Валерий Лаптев [ Четверг, 18 Февраль, 2010 08:22 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Info21 писал(а):
AVC писал(а):
Info21 писал(а):
Ну, можно же забыть RETURN. (Или это не по части структурности?)

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

Проблемы неинициализированных переменных в НОРМАЛЬНОЙ среде быть просто не должно! Отсутствие инициализации переменной должно караться "расстрелом" и квалифицироваться как ГРУБАЯ ошибка. Меня удивляет, почему этого до сих пор не сделали? Это даже не компилятор, это редактор должен следить, БЛИН!!!!!!!!

Последующее обсуждение выделено: viewtopic.php?f=27&t=2372

Автор:  AVC [ Четверг, 18 Февраль, 2010 09:18 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Info21 писал(а):
Но проблема инициализированных переменных есть всегда и так. Зачем к ней добавлять еще одну проблему.

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

Автор:  AVC [ Четверг, 18 Февраль, 2010 09:35 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Info21 писал(а):
В целом я за жесткость и отсутствие мелочной вариативности на низком уровне -- но с конкретной целью: чтобы не отвлекаться от структуры программы.

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

Автор:  Евгений Темиргалеев [ Четверг, 18 Февраль, 2010 09:40 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

AVC писал(а):
Но я все же хочу отметить, что некоторые "трюки" вызваны объективной необходимостью (как правило, ограниченностью ресурсов)
Может стоит называть это обоснованной оптимизацией? А трюками - необоснованную/преждевременную?

Автор:  AVC [ Четверг, 18 Февраль, 2010 09:52 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Евгений Темиргалеев писал(а):
AVC писал(а):
Но я все же хочу отметить, что некоторые "трюки" вызваны объективной необходимостью (как правило, ограниченностью ресурсов)
Может стоит называть это обоснованной оптимизацией? А трюками - необоснованную/преждевременную?

С необходимостью различать обоснованную и необоснованную оптимизацию полностью согласен.
Но и тогда, когда оптимизация обоснована, все равно порой приходится прибегать именно к трюкам -- неочевидным (иногда даже остороумным) приемам, весьма далеким от стандартных оптимизаций компилятора.
(Т.е. для меня слово "трюк" не обязательно связано с негативной оценкой. Но можно попробовать придумать/вспомнить какое-нибудь другое слово: например, "хак", как Валерий Лаптев оценил организацию линейного поиска в двумерном массиве. :) )

Автор:  Axcel [ Четверг, 18 Февраль, 2010 09:57 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Из книжки "Построение компиляторов", стр 184. По моему выглядит очень симпатично.
Код:
PROCEDURE negated (cond: LONGINT): LONGINT
BEGIN
  IF ODD(cond) THEN RETURN cond - 1 ELSE RETURN cond + 1
END negated;

PROCEDURE merged(L), L1: LONGINT): LONGINT
VAR L2, L3: LONGINT;
BEGIN
  IF L0 # 0 THEN
      L2:= L0;
      LOOP
          L3:= code{L2} MOD 40000H;
          IF L3 = 0 THEN EXIT END;
          L2 := L3;
      END;
      code[L2]:=  code[L2] - L3 + L1; RETURN L0
  ELSE RETURN L1
  END;
END merged;

Автор:  Евгений Темиргалеев [ Четверг, 18 Февраль, 2010 10:21 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

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

Автор:  AVC [ Четверг, 18 Февраль, 2010 10:25 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Axcel писал(а):
По моему выглядит очень симпатично.

:mrgreen:
Насколько я понимаю, так в учебном компиляторе для Оберона-0 "патчится" код для сложных булевских выражений.
Виртовские компиляторы генерят сразу машинный код (скорость компиляции). Уверен, если бы генерировался ассемблерный код, все выглядело бы не так страшно. :roll:

Автор:  AVC [ Четверг, 18 Февраль, 2010 10:31 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

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

Конечно, можно назвать это "оптимизацией".
Но у меня слово "оптимизация" вызывает две ассоциации: (1) исследование операций и (2) улучшение, "вылизывание" компилятором/программистом уже готового кода.
"Трюк"/"хак" же заранее учитывает ограниченность ресурсов, это кардинально отражается на структуре решения (оно просто "другое").

Автор:  Axcel [ Четверг, 18 Февраль, 2010 10:34 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. :(

Автор:  AVC [ Четверг, 18 Февраль, 2010 10:44 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Axcel писал(а):
Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. :(

Ну, даже не знаю. :roll:
Здесь весь джентльменский набор: и множественные RETURN, и EXIT, и хранение списка непосредственно в генерируемом машинном коде (кстати, "трюк").
Такое впечатление, что Федор Васильевич срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. :oops:

Автор:  Info21 [ Четверг, 18 Февраль, 2010 11:27 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

AVC писал(а):
срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. :oops:
Что мог, я уже сделал.
(И он все разумные а-та-та разумно принял.)

Автор:  Info21 [ Четверг, 18 Февраль, 2010 11:33 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

AVC писал(а):
Info21 писал(а):
Но проблема инициализированных переменных есть всегда и так. Зачем к ней добавлять еще одну проблему.

По сути, это одна и та же проблема ...
По сути, но не по форме.

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

Автор:  Илья Ермаков [ Четверг, 18 Февраль, 2010 13:20 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Info21 писал(а):
Стоит их поучить, как от всех таких штук начинает колбасить при мысли о том, что и это им надо будет еще втолковывать.


Это точно... Времени дико мало, немыслимо мало. Т.к. в школе - ничего; начинаешь с "таблицы умножения" в алгоритмизации.

Сейчас вот бьюсь над дидактической задачей, как лучше всего научить понимать вообще устройство памяти и структур данных в ней. Нужен исполнитель. Визуальный. Иначе НЕ ВИДЯТ они, как там всё это связывается. Как с указателями работать. То же ООП понять до конца можно, только "руками" почувствовав эти идеи сначала (как оно технически там). Времени ждать, пока дойдёт "инсайтом" в процессе, нет - и неэффективно это; методика нужна.

Автор:  Александр Шостак [ Среда, 24 Март, 2010 21:34 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Евгений Темиргалеев писал(а):
Berserker писал(а):
Лучше больше времени потратить на создание кода, чем отладку или доработку в будущем. Вполне возможно, что если взять за правило структурный стиль , то через какое-то время это войдёт в привычку.
Попробуйте. Если взять соответствующий язык, который не даст расслабляться, то 100% через некоторое время Вы обнаружите, что так и есть.

Переписал весь код текущего проекта ("Система оценки конкурсных предложений", ~3.5тыс. строк) в структурном стиле. Появилась тотальная неприязнь к break/continue/exit (аналог return в ББ).
Как мыслилось раньше:
....ветвения, цикл
....условие выхода - освобождение памяти, очистка мусора
....
....другое условие выхода - освобождение памяти, очистка мусора
Возникали мысли вместо break-ов использовать GOTO на блок с уборкой мусора. Сейчас этого нет. Я знаю на 100%, что код достигнет конца процедуры, и могу расположить там любые действия по финализации работы.
Также стала абсолютно дикой концепция использования исключений для обработки ошибок (в Делфи это сплошь и рядом). Подобные неявные goto рушат основу структурного стиля, заставляя шарахаться от каждого вызова метода или функции. Считаю необходимым применение исключений только там, где это действительно нужно - в математических операциях (TRY a+b EXCEPT MathError END).

Автор:  Владислав Жаринов [ Пятница, 04 Май, 2012 13:37 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Илья Ермаков писал(а):
Сейчас вот бьюсь над дидактической задачей, как лучше всего научить понимать вообще устройство памяти и структур данных в ней. Нужен исполнитель. Визуальный. Иначе НЕ ВИДЯТ они, как там всё это связывается. Как с указателями работать. То же ООП понять до конца можно, только "руками" почувствовав эти идеи сначала (как оно технически там). Времени ждать, пока дойдёт "инсайтом" в процессе, нет - и неэффективно это; методика нужна.
Была идея - использовать схемы типов. Имея в виду, что были уже среды частично визуального исполнения - тот же ПЕКАН: viewtopic.php?p=68848#p68848. Но там как раз до схем связывания типов не дошли...

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

О реализации сего дела. Ясно, что полноценная - это некий редактор. :) Но для дидактики можно просто разобрать по такому принципу одну-две задачи. И составить методу. И даже запрограммировать - но в режиме визуализатора ("перелистывателя страниц", то бишь :))... "Гетерогенная очередь" Свердлова подошла бы. Кстати, думал сам отрисовать - но работа немаленькая... без удобного редактора... ;)

Автор:  Владислав Жаринов [ Среда, 23 Май, 2012 19:10 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Вероятно, наиболее очевидный ответ на это "почему" - потому, что тем самым вполне реализуется сказанное здесь (курсив мой):
...
Однако речь именно об алгоритмике – о программировании, очищенном от всего случайного.
...
Здесь прежде всего мы видим, что алгоритмика понимается не как определение одного лишь потока управления процесса, описываемого программно строго, т.е. для исполнителя-"машины". Но как определение процесса решения в целом.
Можно навести мосты и с другими мыслями разных авторов... возможно, когда-нибудь удастся...

Ну, вот первый мостик... с Лавровым (вторая выдержка здесь: viewtopic.php?p=71221#p71221).
Из формулировки алгоритмической разрешимости (на с. 144), в частности, следует, что в бщем случае необходим прогон программы для установления её соответствия тем или иным требованиям.
    "Итак, отладка в принципе не м.б. исключена?" - радостно воскликнут сторонники "наивного" информоделирования? Тогда и структурность вроде ни к чему?.. А вот тут и вступает в действие сказанное Фёдором Васильевичем... Ибо чем менее мы "очищаем от случайного" язык и описания на нём - тем менее мы м.б. уверены в причинах отклонений от требований. И тем больше нам придётся отлаживать...
Тогда как если мы с самого начала структурировали описание на основе логичности - то и отклонения, как правило, можем выявить путём логического анализа исполнения. Вот как здесь: viewtopic.php?p=72732#p72732 - условие цикла не отвечало требованиям - но товарищ посмотрел и уточнил (возможно, даже и без отладок :wink:). И тем более - изменить работу под новые требования. Пример чему... ну хотя бы здесь, наверное: viewtopic.php?p=72758#p72758 (тоже в рабочем порядке - выявили проблему - локализовали - исправили)...

Автор:  Владислав Жаринов [ Суббота, 26 Май, 2012 10:21 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Да, ещё о дидактике исполнения...
В отсутствие учебного редактора, охватывающего сей предмет, можно пользоваться предложениями Лаврова из работы, представленной здесь: viewtopic.php?p=71221#p71221. В пп. 2.3.4 и 2.5.1 он её использует для представления ссылочных структур.

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

Автор:  Владислав Жаринов [ Воскресенье, 01 Июль, 2012 10:30 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Вот ещё дискуссия: http://www.rsdn.ru/forum/philosophy/4797675.flat.1.aspx.
То, что там ближе к концу возникает о нетекстовых формах записи - в переводе должно означать, что ключевые слова выбора заменяются либо структурными скобками по Прохоренко, либо графикой вершин и линий. А всё, что по семантике и прагматике конструкции выбора - возможно, представляет интерес.. хотя бы для иллюстрации инженерности/неинженерности подходов участников... :)

Страница 7 из 8 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/