Comment by tlb | Hacker News Reader

Comment by tlb | Hacker News Reader

Parent Full thread

Aesthetics in C++ is like /* WRITEME: joke * /.

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

there's like 5 things that irritate me about it. So many underscores!

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.

> Aesthetics in C++ is like /\WRITEME: joke\/.

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.

> 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.

Except it needs to interact with C, which significantly limits the extent of this unification.

How so?

The language standard seems to bend over backward to define exceptions for these to that they kinda fit into the system; for example, if you define a variable like this:

  SomeType variable;

The default constructor gets called, except if it's a built-in type nothing actually happens and variable has garbage in it.

The solution is to wrap anything C related in type safe C++ code.

Yes, it's great that C++ enables you to make aesthetic design decisions. What I dislike is the way they interact in complicated ways with architectural decisions.

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.

> 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".

> 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

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.

This is false in my experience (more than 10y). Most teams use a linter and a formatter. The situation is worse in any other language, except maybe golang.

Reply on news.ycombinator.com