Hacker News Reader

Comment by nikbackm | Hacker News Reader

C++ should be even better in those categories.

Art is often about constraint, and mastery of simple tools.

I identify with @antirez's sentiment. I know both C and C++ very well. I find C definitely more artistic. C++ is utilitarian.

Prolog is the other language I code in "artistically". It too is quite simple and constrained, though it is on the opposite end of the high/low-level spectrum as C.

What is your take on Perl and Ruby? They seem to be the two languages where the communities themselves talk the most about poetry and elegance.

Perl and Ruby are very expressive. Python on the other hand feels like a scripting language designed by a 1990s corporate Java developer.

/unpopular-hot-take

I mostly agree with this. I'll come to python's defense though. Python is a gorgeous language wearing an ugly hat. The hat has __multiple out of place brims__, all of which are about two underscores wide.

It's not a hat, it's a snake that swallowed a Java engineer :)

The name came from the author's love of Monty Python's Flying Circus, so perhaps it's an experiment in low-key absurdist humor or surrealist art. Like chindōgu[1].

1. https://en.wikipedia.org/wiki/Chind%C5%8Dgu

Perl (5) I find quite complex, the opposite of C and Prolog. I suppose the elegance some find comes from packing lots of behavior into very few characters of code. When I want to code as art though, I prefer simpler, less "magical" tools.

I've never used Ruby but from what I've seen I understand it to be similar to Perl in that regard.

I agree that perl can be complex, its feature list is longer than C. Trying to be artistic in it, to me, means trying to make it so my code reads as much like pseudo-code as is reasonably possible. At its best the users are able to read the business logic portions and understand what is going on.

Of course good naming and abstractions are of key importance, and comments and inline documentation are important finishing touches, which so many programmers don't seem to have the time for. It doesn't hurt that Larry Wall, the designer of perl, was a linguist. Perl was meant to be flexible and expressive.

And everyone knows that there's nothing worse to read than obfuscated perl. Perhaps some think that is artistic in a different way, to make the shortest and most unreadable program possible. Not my thing, personally.

True; on the other hand, personally, I think that normally C and C++ shouldn't be even mentioned in the same context. (My C++ code bears virtually no resemblance to my C code.)

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C.

I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.

C++ is a sane defaults superset of C.

C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other

But most of them are new constructs, not found in the venerable C90.

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target.

Note how terrible doing any amount of math is in C.

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

> without operator overloading, it wouldn't be possible to implement lazy evaluation

I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code)

  vector3D a = …
  vector3D b = …
  promise<vector3D> c = addLazily(a,b)
  print c.x

in the end, could do the equivalent of

  print a.x + b.x

I think you could make a modern C++ compiler do that for this simple example.

Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.

Where do you see dynamic memory allocations being needed in that example? I only see locals that a good compiler can fairly easily optimize away.

Also, there’s a simple bijection between expressions with operators and two-argument function calls:

  a + b * c
  +(a, *(b,c))
  plus(a, times(b,c))

Because of that, I don’t understand why operator overloading should give better optimization opportunities than function calls.

Unless you're talking about some theoretical promise, C++ promise implementation imposes dynamic allocation.

Operator overloading is syntax; lazy evaluation is semantics.

That is true but a little bit unfair comment because I expanded with the context in the very next sentence. Or perhaps you're aware of alternative way of how to implement lazy evaluation without expression templates and operator overloading with all of its advantages?

Overloading is miserable. C++ has to provide this as an overload because it still, decades after standardisation and half a lifetime after it was created, doesn't have a way to just extend types.

If you can just extend the types then you can provide operators that way and there's less opportunity for ambiguity. See Rust.

Also so many of the C++ operator overloads are broken instead of just not existing, which tempts you to overload things instead of saying "Nope, that's a bad idea" and just walking away altogether.

Example, boolean short-circuiting AND and OR. If we write

    if (this() || that()) foo();

in C++ then that OR is short-circuiting, so that() won't get called if this() is true.

But if the return type used overloads the boolean OR operator, short-circuiting is disabled, and now both this() and that() are always called...

Reply on news.ycombinator.com