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 писал(а): По моему выглядит очень симпатично. Насколько я понимаю, так в учебном компиляторе для Оберона-0 "патчится" код для сложных булевских выражений. Виртовские компиляторы генерят сразу машинный код (скорость компиляции). Уверен, если бы генерировался ассемблерный код, все выглядело бы не так страшно. |
Автор: | AVC [ Четверг, 18 Февраль, 2010 10:31 ] |
Заголовок сообщения: | Re: Почему программа должна быть структурной |
Евгений Темиргалеев писал(а): AVC писал(а): Но и тогда, когда оптимизация обоснована, все равно порой приходится прибегать именно к трюкам -- неочевидным (иногда даже остороумным) приемам, весьма далеким от стандартных оптимизаций компилятора. "неочевидные (остороумные) приемы" и любые другие действия с целью минимизировать потребляемые программой ресурсы разве не есть оптимизация?Конечно, можно назвать это "оптимизацией". Но у меня слово "оптимизация" вызывает две ассоциации: (1) исследование операций и (2) улучшение, "вылизывание" компилятором/программистом уже готового кода. "Трюк"/"хак" же заранее учитывает ограниченность ресурсов, это кардинально отражается на структуре решения (оно просто "другое"). |
Автор: | Axcel [ Четверг, 18 Февраль, 2010 10:34 ] |
Заголовок сообщения: | Re: Почему программа должна быть структурной |
Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. |
Автор: | AVC [ Четверг, 18 Февраль, 2010 10:44 ] |
Заголовок сообщения: | Re: Почему программа должна быть структурной |
Axcel писал(а): Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. Ну, даже не знаю. Здесь весь джентльменский набор: и множественные RETURN, и EXIT, и хранение списка непосредственно в генерируемом машинном коде (кстати, "трюк"). Такое впечатление, что Федор Васильевич срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. |
Автор: | Info21 [ Четверг, 18 Февраль, 2010 11:27 ] |
Заголовок сообщения: | Re: Почему программа должна быть структурной |
AVC писал(а): срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. Что мог, я уже сделал. (И он все разумные а-та-та разумно принял.) |
Автор: | 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: Почему программа должна быть структурной |
Вероятно, наиболее очевидный ответ на это "почему" - потому, что тем самым вполне реализуется сказанное здесь (курсив мой): Info21 в http://www.inr.ac.ru/~info21/events/x-i ... moscow.htm писал(а): ... Здесь прежде всего мы видим, что алгоритмика понимается не как определение одного лишь потока управления процесса, описываемого программно строго, т.е. для исполнителя-"машины". Но как определение процесса решения в целом.Однако речь именно об алгоритмике – о программировании, очищенном от всего случайного. ... Можно навести мосты и с другими мыслями разных авторов... возможно, когда-нибудь удастся... Ну, вот первый мостик... с Лавровым (вторая выдержка здесь: viewtopic.php?p=71221#p71221). Из формулировки алгоритмической разрешимости (на с. 144), в частности, следует, что в бщем случае необходим прогон программы для установления её соответствия тем или иным требованиям.
|
Автор: | Владислав Жаринов [ Суббота, 26 Май, 2012 10:21 ] |
Заголовок сообщения: | Re: Почему программа должна быть структурной |
Да, ещё о дидактике исполнения... В отсутствие учебного редактора, охватывающего сей предмет, можно пользоваться предложениями Лаврова из работы, представленной здесь: viewtopic.php?p=71221#p71221. В пп. 2.3.4 и 2.5.1 он её использует для представления ссылочных структур. Кстати, вторая часть книги вообще любопытна по изложению алгоритмики. В частности, показывается, как некоторые случайности мешают... |
Автор: | Владислав Жаринов [ Воскресенье, 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/ |