[comp.prog.flame] Упрощения в презентациях – повторение пути шаттла Коламбия?

После катастрофы шаттла Коламбия в 2003-м мне попалась на глаза статейка, в которой одной из причин называлось широкое использование Microsoft PowerPoint в NASA. Т.е. виноват, конечно, не сам PowerPoint, а использование презентаций в качестве основной формы докладов подразделений и руководству NASA. Презентации, якобы, не позволяли углубляться в детали, а дают только поверхностную картинку. Т.е. подчиненные подсовывали своему начальству красочные презентации, которые начальство хотело видеть. Что и привело с системным проблемам в обеспечении безопасности полетов шаттлов.

Версия, конечно, бредовая. Но негативная роль презентаций, показывающих только “светлую” сторону, определенно есть. Взять, например, презентацию Дона Сайма “Why is Microsoft investing in Functional Programming?”, а в ней картинку на странице 38:

Действительно ли показанный желтым фрагмент на F# является эквивалентом трех страниц на C#?

Как по мне – так нет. Они не эквиваленты ни по выполняемым операциям, ни по объему комментариев в коде, ни по подробности обработки ошибок.

Зато как убедительно преимущество F# выглядит в презентации! ;)

Еще один пример, на этот раз из обсуждавшейся уже здесь статьи “Элементы функциональных языков”. Фрагмент кода из раздела “10. Сопоставление с образцом”, демонстрирующий работу с POP3 сервером:

sendCommand (POP3C conn _) (RETR msg) =      bsPutCrLf conn (BS.pack ("RETR " ++ show msg))         >> responseML conn    sendCommand (POP3C conn _) (TOP msg n) =      bsPutCrLf conn (BS.pack ("TOP " ++ show msg                               ++ " " ++ show n))         >> responseML conn    sendCommand (POP3C conn _) (AUTH LOGIN user pass) =      do bsPutCrLf conn (BS.pack "AUTH LOGIN")         bsGetLine conn         bsPutCrLf conn (BS.pack userB64)         bsGetLine conn         bsPutCrLf conn (BS.pack passB64)         response conn      where (userB64, passB64) = A.login user pass

Красиво? А вот пример работы с POP3 сервером из библиотеки POCO:

void POP3ClientSession::login(const std::string& username, const std::string& password) {    std::string response;    _socket.receiveMessage(response);    if (!isPositive(response)) throw SMTPException("The POP3 service is unavailable", response);    sendCommand("USER", username, response);    if (!isPositive(response)) throw POP3Exception("Login rejected for user", response);    sendCommand("PASS", password, response);    if (!isPositive(response)) throw POP3Exception("Password rejected for user", response); }

Ведь тоже красиво, не так ли? Просто, лаконично, функционально. Лепота.

Одна проблема с кодом в POCO – нихрена тайм-ауты он не считает. Поэтому, если по какой-то причине соединение с POP3 сервером “залипнет” (т.е. из него ничего не будет читаться, но и сигнала о потере не будет), то приложение на вызове POP3ClientSession::login() уснет навсегда.

А если добавить в приведенные выше фрагменты более суровую (т.е. требующуюся на практике) обработку ошибок и тайм-аутов, куда исчезнет эта красота?

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