Rich Hickey brought joy and aesthetics back to software development.
Actually, the fact that C++ has both more and less aesthetically pleasing subsets is a big problem. It means that different people prefer different ways of doing things for purely visual reasons rather than reasons of overall simplicity and maintainability, and that creates needless conflict and churn.
In contrast, Python has very little variation in aesthetic pleasingness. It's all the same Dutch Utilitarian Modernist, perfectly OK if unexciting to look at (@ metaprogramming is an exception.)
And a contrast in the other direction: nobody ever spent a lot of time tweaking their FORTRAN deck for aesthetics.
Just to pick something on my screen at the moment, consider this C++ from mc-stan:
namespace stan {
namespace math {
namespace {
class cos_vari : public op_v_vari {
public:
explicit cos_vari(vari* avi) : op_v_vari(std::cos(avi->val_), avi) {}
void chain() { avi_->adj_ -= adj_ * std::sin(avi_->val_); }
};
} // namespace
But the big problem is that aesthetic choices interact in complicated ways with architectural decisions. For example, using operator << as syntactic sugar over .add() is motivated by aesthetics, but it affects how you do encapsulation.
A good language lets you choose your architecture, and then write an aesthetically pleasing program to match.
On the contrary, C++ treats user-code aesthetics as a first-class design-decision, moreso than many other languages.
In C++ the whole thing is that built-in types aren't special, including ints and operators. This is a deep concept in the design of the language.
The fact that you can express abstract things like matrix multiplication, compile-time unit-conversions, and compile-time range-checking through operator-overloading speaks to how aesthetic the language is.
> It means that different people prefer different ways of doing things for purely visual reasons
I've never seen any sizable project where visual aesthetics of the API aren't relevant. Java's got chained builders and lambdas, Python's got `@property` and various `__foo__` methods, and any sufficiently large Ruby project's syntax is a DSL wrapped in a riddle wrapped in bacon.
User-defined APIs are syntax, so why limit the tokens?
> A good language lets you choose your architecture, and then write an aesthetically pleasing program to match.
C++ does let you do that. You've pointed to an example where there was little or no intentional thought put into the aesthetics of the API. E.g. `avi_` really could own those methods, and the underscores aren't required by the language.
You can argue that C++ gives you too much power or that sometimes it's non-obvoius how to use that power or that you've seen code where the API designers have taken enough rope to hang themselves. But of course it is possible to write "Java" in C++ and avoid any operator-overloading or syntax-sugar if your team decides it wants to do that.
Except it needs to interact with C, which significantly limits the extent of this unification.
SomeType variable;
Libraries like MTL (the matrix template library) are completely architected around providing their nifty syntax. They do insane things like have operators return types representing a symbolic computation, so that template specialization can be used to do a kind of peephole optimization. The end-user experience is aesthetically improved, but do not stare into the abyss of the template definitions.
That is getting better and better with time. C++14 with generic lambda, C++17 with constexpr and C++20 with concepts imrpoved all of that.
It made the writing of template expression switch from "obscure C++ gourou dark magic " to "Kinda readable C++ dude".
Really ? Python would probably be the last language I would quote for "One way to do things" and "little aesthetic pleasingness".
There is around 20 ways to do packaging, unit testing, list iteration, string concatenation, list iterations, network calls, Object Oriented and almost any single action in Python.
The Zen of python (https://www.python.org/dev/peps/pep-0020/) might quote "There should be one-- and preferably only one --obvious way to do it.". That never have been the case in practice.
Rich Hickey did not bring joy and aesthetics to software development, it was already there before he was even born -- https://en.wikipedia.org/wiki/Lisp_(programming_language)
What he did, he made it more popular and more accessible which is at least as important.