6 ms·

What monsters put compile-time programming over concurrency and pattern matching?

by ebg13 7y ago

lgeorget 7y ago
But what if you can do pattern-matching at compile-time?!
- yk 7y ago
  #define stupidHack true
- steveklabnik 7y ago
  'inspect constexpr' is part of the pattern matching paper, IIRC.
majidazimi 7y ago
It means concurrency and pattern matching is not really critical for the community as it is for other language communities. There is no insult, but generally speaking an average C++ developer has deeper knowledge than an average Java developer which essentially means C++ developer is somewhat comfortable with traditional concurrency toolkit like threads.
- asveikau 7y ago
  > C++ developer is somewhat comfortable with traditional concurrency toolkit like threads. As somebody who has used threads a lot and written code in kernel mode etc. something about this scratches me the wrong way. The traditional concurrency toolkit has some issues. Being experienced with them can make you somewhat jaded against them. In particular, the standard way to solve problems in that mode of thinking is to introduce locks, and experienced people know all the problems that locks have, and that the "solution" is harmful in the extreme. So it is acceptable for such a programmer to want more options, standardized. I would even argue that this is more important than introducing std::mutex, std::thread, or std::atomic, because you can say that in the pre-C++11 era nonportable interfaces like pthreads or win32 were already working OK for people that chose to use them.
  - jcelerier 7y ago
    > In particular, the standard way to solve problems in that mode of thinking is to introduce locks nowadays I mostly see lock-free queues and message passing across threads, it's trivial to do with a few nice libraries
stefan_ 7y ago
The C++ committee has been captured by a hostile force that tries to turn every C++ compiler into the slowest imaginable C++ abstract machine emulator.
banachtarski 7y ago
Why would we want concurrency if we already have thread support and coroutines. Concurrency is a nice-to-have abstraction that is not without overhead and design tradeoffs.
alexhutcheson 7y ago
Library authors and maintainers.
ludamad 7y ago
I feel like Herb Sutter has always written favourably about compile time tricks, and it's reflected in his audience
jandrewrogers 7y ago
It actually makes sense to me. Compile-time programming is a very powerful feature of C++ that does not have an equivalent in other systems languages. It is commonly used to effect several types of compile-time verification of code design and safety that would be difficult to do any other way, in addition to its more obvious use case for effecting relatively complex performance optimization algorithmically. The ability to algorithmically generate almost arbitrarily complex types during compilation that are fit to purpose is an extremely useful feature for fast, high-reliability code and used pervasively in modern C++ as the facility has become more expressive. Filling some of the last remaining holes in its expressiveness would be high-value novel capability. Think of it as a hardcore safety feature. You can put me in the camp that adding more support for concurrency in the language beyond a feature like coroutines (in C++20) and the existing primitives is not that useful. It would have the same issue as STL containers, where there simply isn't enough control of the implementation details for them to be used for many applications C++ is used for, so most concurrency infrastructure will be purpose-built anyway. Pattern matching functionality can already be effected in many cases, albeit quite ugly. This would be more syntactic sugar than new capability, so I can understand why it isn't prioritized as much.
- pjmlp 7y ago
  Have you ever used Common Lisp macros, D meta-programming, Nim, Dylan macros, BETA pattern matching, OCaml pptx templates, Template Haskell,...? Yes, C++ compile time capabilities are powerful, but they aren't by all means the only game in town.
  - jandrewrogers 7y ago
    Almost none of those are systems programming languages, which was the domain of comparison.
    - pjmlp 7y ago
      Common Lisp (Lisp Machines), D, Nim, OCaml (MirageOS Unikernel, Docker macOS TCP/IP stack), Haskell (House OS and Galois bare metal deployments).
steveklabnik 7y ago
Another interesting thing about this survey is that the categories don't have equal representation; so for example, "pattern matching" has two papers, one of which is extremely popular, but "compile time programming" has thirteen papers, with a few of them being significantly more popular than the others (one has only one vote, for example, but another is, in my mind, one of the most exciting proposals coming down the line for C++). There's tons of reasons why this could be this way; and it shows why creating these kinds of things is just hard.
paulirwin 7y ago
It also might be a result of the pattern matching proposal having only been introduced this year, and concurrency/coroutines having been a focus in C++20 already. Whereas compile-time programming has been discussed for a while now and is getting more well-baked, but still hasn't made it fully into the language yet and many (myself included) are eager to use it. See the revision history of P0707 for example.

What monsters put compile-time programming over concurrency and pattern matching?

by ebg13 7y ago

What monsters put compile-time programming over concurrency and pattern matching?

lgeorget 7y ago

But what if you can do pattern-matching at compile-time?!

yk 7y ago
#define stupidHack true
steveklabnik 7y ago
'inspect constexpr' is part of the pattern matching paper, IIRC.

majidazimi 7y ago

It means concurrency and pattern matching is not really critical for the community as it is for other language communities. There is no insult, but generally speaking an average C++ developer has deeper knowledge than an average Java developer which essentially means C++ developer is somewhat comfortable with traditional concurrency toolkit like threads.

asveikau 7y ago
> C++ developer is somewhat comfortable with traditional concurrency toolkit like threads. As somebody who has used threads a lot and written code in kernel mode etc. something about this scratches me the wrong way. The traditional concurrency toolkit has some issues. Being experienced with them can make you somewhat jaded against them. In particular, the standard way to solve problems in that mode of thinking is to introduce locks, and experienced people know all the problems that locks have, and that the "solution" is harmful in the extreme. So it is acceptable for such a programmer to want more options, standardized. I would even argue that this is more important than introducing std::mutex, std::thread, or std::atomic, because you can say that in the pre-C++11 era nonportable interfaces like pthreads or win32 were already working OK for people that chose to use them.
- jcelerier 7y ago
  > In particular, the standard way to solve problems in that mode of thinking is to introduce locks nowadays I mostly see lock-free queues and message passing across threads, it's trivial to do with a few nice libraries

stefan_ 7y ago

The C++ committee has been captured by a hostile force that tries to turn every C++ compiler into the slowest imaginable C++ abstract machine emulator.

banachtarski 7y ago

Why would we want concurrency if we already have thread support and coroutines. Concurrency is a nice-to-have abstraction that is not without overhead and design tradeoffs.

alexhutcheson 7y ago

Library authors and maintainers.

ludamad 7y ago

I feel like Herb Sutter has always written favourably about compile time tricks, and it's reflected in his audience

jandrewrogers 7y ago

It actually makes sense to me. Compile-time programming is a very powerful feature of C++ that does not have an equivalent in other systems languages. It is commonly used to effect several types of compile-time verification of code design and safety that would be difficult to do any other way, in addition to its more obvious use case for effecting relatively complex performance optimization algorithmically. The ability to algorithmically generate almost arbitrarily complex types during compilation that are fit to purpose is an extremely useful feature for fast, high-reliability code and used pervasively in modern C++ as the facility has become more expressive. Filling some of the last remaining holes in its expressiveness would be high-value novel capability. Think of it as a hardcore safety feature. You can put me in the camp that adding more support for concurrency in the language beyond a feature like coroutines (in C++20) and the existing primitives is not that useful. It would have the same issue as STL containers, where there simply isn't enough control of the implementation details for them to be used for many applications C++ is used for, so most concurrency infrastructure will be purpose-built anyway. Pattern matching functionality can already be effected in many cases, albeit quite ugly. This would be more syntactic sugar than new capability, so I can understand why it isn't prioritized as much.

pjmlp 7y ago
Have you ever used Common Lisp macros, D meta-programming, Nim, Dylan macros, BETA pattern matching, OCaml pptx templates, Template Haskell,...? Yes, C++ compile time capabilities are powerful, but they aren't by all means the only game in town.
- jandrewrogers 7y ago
  Almost none of those are systems programming languages, which was the domain of comparison.
  - pjmlp 7y ago
    Common Lisp (Lisp Machines), D, Nim, OCaml (MirageOS Unikernel, Docker macOS TCP/IP stack), Haskell (House OS and Galois bare metal deployments).

steveklabnik 7y ago

Another interesting thing about this survey is that the categories don't have equal representation; so for example, "pattern matching" has two papers, one of which is extremely popular, but "compile time programming" has thirteen papers, with a few of them being significantly more popular than the others (one has only one vote, for example, but another is, in my mind, one of the most exciting proposals coming down the line for C++). There's tons of reasons why this could be this way; and it shows why creating these kinds of things is just hard.

paulirwin 7y ago

It also might be a result of the pattern matching proposal having only been introduced this year, and concurrency/coroutines having been a focus in C++20 already. Whereas compile-time programming has been discussed for a while now and is getting more well-baked, but still hasn't made it fully into the language yet and many (myself included) are eager to use it. See the revision history of P0707 for example.