Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>1)Сложность восприятия и сложность обучения — практичеки одно и тоже, только взгляд с разных сторон.

IT>Сложность само по себе одно и тоже — затраченные усилия, и её виды — это как раз и есть взгляд с разных сторон. Разделение на виды само по себе вещь достаточно условная и интересно прежде всего для выявления, лучшего понимания и устранения проблемных мест. Возьмём, например, код, который плохо читаем, т.к. страдает отсутствием форматирования, соглашений, запутан и многословен. Что нужно сделать, чтобы он стал прощё? Его можно отформатировать, отрефакторить, распутать и убрать лишнее. В результате он станет проще за счёт уменьшения сложности восприятия.
Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.

IT>Теперь возьмём код, который легко читается, но базируется на технологии, которая изучающему этот код пока не известна. Пусть это будет WPF — как раз та вещь, которая обладает довольно высоким порогом вхождения. Поможет ли нам форматирование кода, его рефакторинг и распутывание лучше понять такой код? Ответ очевиден — не поможет, рефакторить можно хоть до посинения. Нужно брать в руки книжки и изучать технологию.
Понимание что делает код не появится без понимания абстракций, которыми он оперирует.

Так что для "восприятия" нужно "обучение".

G>>2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами, тогда как алгоритмическая сложность и сложность сложность изменения преслдуют постоянно.

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

IT>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела.
Это еще более редкое явление.

Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.

G>>3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные.
IT>Какие?
В случае парсера — нетривиальные алгоритмы — неочевидное преобразование входных данных в выходные, которое вряд ли получится декомпозировать на более протые части. В случае бухгалтерской системы все можно до элементарных вещей декопозировать, но возникает пролема распределения обязанностей между программными модулями и обеспечение их взаимодействия.