Страницы

Пример вреда шаблонного программирования и не только

Попался на глаза пример шаблонного кода на C++

template <typename T>
T tmax(T a, T b) {
    return b < a ? a : b;
}

Я сразу заметил неточность, которая возникнет при использовании дробных чисел

Структурное программирование не про запрет GOTO

Теорема Бёма — Якопини, которую часто называют теоремой про структурное программирование, на самом деле доказывает прямо противоположное тому, что ей приписывается. Она не доказывает достаточности структурного программирования, а наоборот, доказывает, что с помощью структурных операторов управления можно идеально воспроизводить любой неструктурный код, но сохраняя таким образом и все его отрицательные для человека свойства. Более подходящим названием для теоремы было бы «теорема про неструктурное программирование в структурных операторах».

Рассмотрим дикий бессмысленный пример неструктурного кода:

L0: Call0; IF Pred0 GOTO L2;
L1: Call1; IF Pred1 GOTO L3;
L2: Call2; IF Pred2 GOTO L3 ELSE GOTO L0;
L3: Call3; IF Pred3 GOTO L4 ELSE GOTO L1;

Не нужно быть поваром

— Эта жратва никуда не годится. Как можно было так плохо приготовить?

— Почему плохо? Разве ты разбираешься в приготовлении еды?

— Не нужно быть поваром, чтобы понять, что овсянка — это отстой. Вот кукурузные хлопья в сахарной глазури из коробки — это класс! А это — тьфу. Так зачем же мучаться, да ещё и разглагольствовать, будто овсянка полезна и является прорывом в питании? Это очевидно противоречит истине и в высшей степени непрофессионально.

Каменный топор

— Каменный топор — это вершина технической мысли! — сказал мастер, — мы много лет оттачивали умение создавать каменные топоры и работать с ними, и теперь достигли в этом совершенства.

— Но теперь у нас есть и другие, более совершенные инструменты: электродрели, отбойные и пневмо- молотки, станки.

— Хорошо, и что же вам мешает использовать их для создания каменных топоров?

Причины большей популярности внутренне посредственных систем

Почему так часто инженерно менее удачные системы популярнее в разработке, чем более аккуратные и выверенные? Этим вопросом задаются многие разработчики, для которых важен не только результат, преимущественно, в виде личного денежного вознаграждения, но и эффективный путь достижения результата, а также его дополнительные положительные качества с инженереной точки зрения. Вероятно, вы и сами принадлежите к множеству таких людей.

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