Линус Торвальдс не прав!
Надо б написать программу, в порядке упражнения и демонстрации возможностей ООП, решающую систему линейных уравнений. Пожалуй, можно даже и нелинейных, можно даже и диффренциальных. При правильном дизайне - какая, собственно, разница?

В идеале, система уравнений должна быть контейнером объектов, каждый из которых представляет собой уравнение, инкапсулирующий внутри себя значения коэффициетов (для линейных уравнений) или же вообще математическое выражение общего типа и наследующее некоторый стандартный интерфейс CBaseEquation. Т.е., подробнее, объекты эти сами по себе композитные, включают в себя объекты "левая" и "правая" часть уравнения, хотя для простоты можно считать правую часть уравнения равной нулю. Ну, положим, оставим левую часть, которая представляет из себя дерево операторов и операндов. Оператор может быть, опять же, объектом, имплементриующим некоторый стандартный интерфейс, будь это оператор сложения или, скажем, дифференцирования, ну а операнды - другие операторы, константы и переменные, опять же со своими интерфейсами. Еще, для повышения универсальности, сделаем "равенство" левой и правой части опять же, не встроенным жестко в систему, а некоторым объектом.

Теперь мы, значит, всё это объектно-ориентированно построим, вызовем метод "resolve" и объект "система уравнений" разошлёт подходящие сообщения каждому отдельному уравнению, те в свою очередь своим внутренним компонентам (разумеется, понадобятся call-backs, то есть отдельные уравнения могут запросить объект "система уравнений" данные о работе других уравнений, например. И всё заработает, т.е. система уравнений решится. Осталось только подобрать подходящую имплементацию каждого метода, но это уже частности, главное что мы построили более-менее вменяемый Объектно-ориентированный дизайн, а не свалили всё тупо в кучу, как делают программисты, не владеющие объектно-ориентированным подходом.

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

Т.е. практически только переопределением объектов производного класса мы решаем куда как больший класс задач, чем планировали изначально. Мне даже сложно представить потенциальную расширяемость подобной системы, она практически ничем не ограничена.