Если это даже правда, это утверждение о программистах на C и C ++, а не утверждение о языках.
Может случиться так, что программисты на С ++ с большей вероятностью будут думать о своих программах как о наборах небольших, повторно используемых компонентов. Затем они будут стремиться к дизайну снизу вверх.
Возможно, программисты на Си более склонны думать о своих программах как об одной монументальной задаче, которую они подразделяют на более мелкие и более простые задачи. Затем они будут стремиться к дизайну сверху вниз.
Или такой тенденции может не быть. Ни один язык не мешает ни одному из подходов. Например, предположим, я хочу написать код, который анализирует некоторые данные и печатает отчет. Вот нисходящий подход в C:
# first version of the code (doesn't compile)
raw_data = read_the_data();
processed_data = perform_the_analysis(raw_data);
report = prepare_report(processed_data);
puts(report);
Для восходящего подхода C я мог бы сначала написать какой-то очень общий, многократно используемый код, который анализирует сохраненный формат данных, потому что я знаю, что хочу загружать данные. Аналогично, я бы написал некоторый код, который обрабатывает анализируемую форму данных различными способами, которые обычно полезны, учитывая природу данных. Затем я напишу код, который использует эти инструменты для анализа данных, как требуется в моем конкретном приложении, напишу код, который создаст нужный мне отчет, а затем соберу все это вместе.
В C ++ я бы делал почти одно и то же в обоих случаях, за исключением того, что я не буду проектировать структуры данных и функции, которые на них работают, я буду разрабатывать классы, которые инкапсулируют данные вместе с соответствующими существенными операциями над этим данные, а затем функции, не являющиеся членами, которые работают с классами.
В любом случае вы можете получить довольно похожий код. Одной из областей, в которой это имеет большое значение, является тестирование - если вы создаете восходящую версию, то, как только вы написали какой-либо код, вы написали что-то, что работает, что вы можете с пользой протестировать. Можно протестировать нисходящий фреймворк без каких-либо реализованных компонентов, с подходящими поддельными компонентами, но я часто не уверен, насколько реалистичным является этот тест.
Я не знаю, что программисты на C ++ более или менее озабочены, чем программисты на C, иметь что-то конкретное как можно скорее. Компромисс, который вы делаете, заключается в том, чтобы думать о общей картине, а не о том, что вы можете реализовать прямо сейчас, за разумный кусок работы, и о том, как заставить их встретиться. Также думать о решении проблемы, которую вы имеете под рукой, а не думать о том, как, в общем, решать проблемы, связанные с вещами, которые включает в себя ваша проблема. Это не совсем языковые проблемы.