5 ms·

C++ should be even better in those categories.

siftrics 4y ago
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.
- AlexeyBrin 4y ago
  C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
  - wiseowise 4y ago
    C++ is a sane defaults superset of C.
  - 3836293648 4y ago
    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
  - kazinator 4y ago
    But most of them are new constructs, not found in the venerable C90.
- Koshkin 4y ago
  Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.
  - camel-cdr 4y ago
    How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.
    - Conscat 4y ago
      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.
      - menaerus 4y ago
        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.
        Someone 4y ago
        > 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.
        menaerus 4y ago
        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.
  - tialaramex 4y ago
    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...
colanderman 4y ago
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.
- bakuninsbart 4y ago
  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.
  - sph 4y ago
    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
    - MrLeap 4y ago
      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.
      - sph 4y ago
        It's not a hat, it's a snake that swallowed a Java engineer :)
        tuatoru 4y ago
        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 https://en.wikipedia.org/wiki/Chind%C5%8Dgu
  - 4y ago
Koshkin 4y ago
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.

AlexeyBrin 4y ago
C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
- wiseowise 4y ago
  C++ is a sane defaults superset of C.
- 3836293648 4y ago
  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
- kazinator 4y ago
  But most of them are new constructs, not found in the venerable C90.
Koshkin 4y ago
Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.
- camel-cdr 4y ago
  How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.
  - Conscat 4y ago
    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.
    - menaerus 4y ago
      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.
      - Someone 4y ago
        > 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.
        menaerus 4y ago
        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.
- tialaramex 4y ago
  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...

colanderman 4y ago

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.

bakuninsbart 4y ago
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.
- sph 4y ago
  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
  - MrLeap 4y ago
    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.
    - sph 4y ago
      It's not a hat, it's a snake that swallowed a Java engineer :)
      - tuatoru 4y ago
        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 https://en.wikipedia.org/wiki/Chind%C5%8Dgu
- 4y ago

Koshkin 4y ago

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