По результатам общего знакомства с
"Искусством..." впечатление следующее.
...
Недавно стал читать
"Решение сложных задач".
Весьма интересна вводная часть:
Вложение:
Комментарий к файлу: Позиция автора о поиске решений задач и подготовке в сфере программирования.
Потопахин-РешСложЗадач-извл(ВД+Огл+Введ+Гл1,2).djvu [121.26 КБ]
Скачиваний: 491
Простым языком и кратко изложен ряд базовых вещей. Общие вопросы, обсуждённые для "Искусства...", имеют смысл и здесь - но глубина материала рождает и новые темы.
Так, это:
В.В. Потопахин на с. 1 писал(а):
Основной метод, действие которого проявляется на каждом шагу - это метод борьбы с неопределённостями.
- удачно ориентирует, что задачу можно поставить неопределённостно, стохастично и детерминированно. И каждая постановка отражает понимание смысла задачи, предметной области со своей стороны.
В то же время и детерминистская постановка должна учитывать вариативность значений тех или иных величин, когда они представляют реальные параметры. Т.к. она может влиять на решение уже при математической формализации. Можно видеть это у Одинцова (где для вычисления фиксированных и приближённых значений выводятся разные формулы) - а что получается, если игнорировать это, показано Петровым.
Творческий труд неалгоритмизуем - что в то же время не значит, что он не систематичен и не требует организации. То же ранее говорил и Грабин - см. с 80-81 в третьей выдержке из
этого поста - оно и неудивительно.
Справедливо критикуется метод "проб и ошибок" в выборе способа решения - по крайней мере, с позиций современной ТРИЗ. Тем более, что содержательную классификацию всех возможных задач и логически сомнительно построить. В то же время, скажем, у
М.А. Орлова можно видеть и критику ряда методов организации творчества (хотя объектами выступают материальные системы). Можно предположить, что наряду с физическими противоречиями существуют и логические - относительно идеальных систем. И их выделение наряду с логическими эффектами даст возможность эффективнее организовать решение задач "на идеальное" - в частности, программистских. Хотя это не "предписания, как надо мыслить" - скорее возможное направление мышления
для придания решению задач более инженерного характера.
Интересно обсуждение декомпозиции и формализации. В то же время формализация м.б. понята более широко - как не отдельный этап, но процесс получения любого знания, отчуждаемого (по
Фридланду - Гл. 6; см. также на
этой странице) или "отслаиваемого" (по
Леонтьеву) как совокупность данных, документированных и/или сообщённых непосредственно.
Также это:
В.В. Потопахин на с. 11 писал(а):
Можно без всякого преувеличения сказать, что запись алгоритма — это отдельная наука, требующая специальных навыков, средств и подходов.
— перекликается с идеями Паронджанова. А наука о записи (не только алгоритмической части знания о задаче) - это ИП и когнитивная эргономика как её часть.
Идея о записи на прогязыке (изначально детерминированном), но с допущением ЕЯ-формулировок (фиксирующих недетерминированную часть понимания решения) - одна из тех, что положены в основу графит метода. На примере это показано прежде всего для этой
задачи оформления визуалов, - особенно при деклар-моделировании (см.
этот рисунок в графчасти и о деклар-модели в
текстовой части)
И желательно владение изоморфными средствами записи именно для развития творческого мышления. Это и потому, что «разнорукость» в этом деле не мешает — и потому, что тип мышления в отношении базовых представлений для восприятия/оперирования/отчуждения у разных людей разный. Хотя большинство занимающихся сейчас информоделированием (и у Вас программированием, в частности), видимо, представляют тип «литераторов» - но это м.б. и следствием как раз «барьера вхождения» для «живописцев» при доминировании в литературе текстовой записи. Кроме того, предметники и аналитики тоже не все «литераторы» - м.б. скорее и наоборот. А программисту работать в команде (триаде) с ними — и надо бы уметь специфицировать задачи не только текстом.
В своё время В. Лаптев приводил в
этом посте пример, как визуализация задач помогла и при обучении программированию — и
п. Непрофессиональная визуализация этого примера показывает то же самое.
Кстати, если вернуться к творчеству, представлению знаний и противоречиям. Пожалуй, кое-что можно видеть в данной выдержке. Прежде всего - сказанное на с. 9 о разнице между реальными объектами и структурами данных, их представляющими. Между необходимой в информатике конечностью структур данных и бесконечностью (в т.ч. и в силу непрерывности изменения) реальных величин. Противоречие, видимо, проявляется и в «утечках» памяти при работе с произвольными (указательными) структурами.
Есть и разница в выразительных возможностях разных форм записи; так, в
этой книге на с. 11-12 приводится пример возможности конечного графового описания ЛИСП-структуры данных - и невозможности конечно описать такую структуру скобочными выражениями.
Сказанное о точности вычислений тоже, видимо, можно поставить в этот ряд. Возможно, целесообразными именно при инженерном программировании будут решения, основанные на отказе от вещественных чисел в пользу целых (конечно, необходимой разрядности). Это даст устойчивость к накоплению ошибок, как говорилось в
этом посте (для чего Штернберг предлагал специальные алгоритмы — но, видимо, только для вещественных вычислений). Тем более, что на это указывалось и в критике Оберона в
этом посте, и при рассмотрении формальной верификации в
этой работе.
О творчестве в формализации много говорят - но и тут позиции не всегда плодотворные - что видно на той же Компьютерре. Произвольно рассуждая о "художественности" программирования (что особенно удобно применительно к прогязыкам с неформальным синтаксисом и undefined behaviour ) - отдельные граждане кое о чём забывают. Тут говорилось (Фёдором Васильевичем, кажется), что программер зачастую мало что другое знает и не всегда хочет знать - и искусства это также касается. Потому что людей искусства образуют не витанием в облаках, а по методу. И методы эти принципиально таковы же, как методологии формализации знаний в других профессиях - и зафиксированы чаще всего усилиями личностей-формализаторов, подчас великих. Во всём мире признаны методы наших сотечественников: в театральном деле - Константина Станиславского (и альтернативный - Михаила Чехова), в балете - Агриппины Вагановой. В архитектуре (материальной ) также сложились методы отчуждения и передачи знаний, начиная с Витрувия. Менее известно, что и в живописи выработаны методы формализации, и в прикладном искусстве (на основании которых образуют мастеров и в Палехе, и во Мстёре, и в Вологде)... Видели мы это и для литературы - хотя бы у Каверина.
И специфика художественной формализации в сравнении с технической - прежде всего в том, что: А) многое нужно передавать через личность наставника, состоявшегося в деле; Б) объём "базовых техник", подлежащих передаче, в разных делах м.б. существенно различен (в той же литературе это прежде всего грамотность и первичное владение языком, которое всё-таки прерогатива общего образования).
Почему я тут об этом? Потому, что у многих "художественность" в информатике - это отрицание и возможности целенаправленной подготовки по информоделированию, и необходимости качества ИТ-работы. Тогда как у Виталия Валерьевича неформальность творчества не отрицает ни методичности подготовки к нему, ни требований к качеству его результата. А сказанное здесь: В.В. Потопахин на с. 2 писал(а):
Обратите внимание на правила, выведенные в процессе анализа хода решения. Этих правил немного, и они не представляют системы. ...подобная система скорее всего привела бы не только к повышению эффективности мыслительного процесса, но и к ограничению Ваших творческих возможностей. Поэтому сформулированных правил немного и они не носят характер предписаний, как надо мыслить, это скорее небольшие советы, корректирующие направление мышления.
- обнаруживает сходство с методом актёрской игры. Имеются в виду игровые "приспособления" - которые при формальном использовании могут стать "штампами". Хотя есть и различие - преодоление "заштампованности" игры происходит в т.ч. и через расширение круга "приспособлений" (часто они берутся из жизненных наблюдений - и здесь прямая аналогия с выводом правил на конкретных задачах). А гениальные лицедеи обычно ничем вроде бы не пользуются - и создают реальный характер (вспомним Смоктуновского или Леонова). Но как и у них результат "проходит контроль качества" зрительским восприятием - так и у гениальных программистов (как и у остальных ) должно получаться то, что выдерживает контроль на соответствие требованиям к изделию - в т.ч. и к определённости поведения.
Конечно, в отличие от искусства, требования эти сегодня уже формальные - на сегодня хотя бы метод проверки моделей или
автоматное программирование. И думаю, Виталию Валерьевичу будет под силу в работе по инженерии показать, как это делать на КП и в ББ. Некая попытка показать "проверяемую модель" в графит-форме предпринята в
этом примере - но это всё же эскиз "предметника", требующий развития (как и сама форма записи)...
В общем, этот материал, думаю, также должен занять своё место в новых книгах автора.