3 ms·

I don't agree. I can think of many languages that obfuscate their idioms that have bounded applicability. Obviously I already mentioned Python, which is obvious

I don't agree. I can think of many languages that obfuscate their idioms that have bounded applicability. Obviously I already mentioned Python, which is obviously bounded to less performant applications (unless you call C code), but another one is SQL. For example, Azure SQL is extremely slow when using sub queries compared to CTEs, but the language does not make this apparent in its design. An example of a language with a smaller domain which makes its idioms obvious through its design is Ruby. An example of a high-performance language that can be used for all those things that makes its idioms obvious through its design is Rust. Another would be, imo, C. > There are not many common idioms that are going to be shared (beyong libstdc++) between a realtime audio processing application and a data visualization backend for the web and an embedded system control app and a payroll processing backend. I also just generally have to disagree with it, but you seem to be using a different definition of idiom to me. From what you said here, you seem to take idiom to be synonymous with "design decision". For me, an idiom is a specific semantic construct, possibly associated with specific syntax, that achieves a specific basic programming task. For example, the idiomatic way to loop with an index in Python is to use enumerate. It's merely the way that most people do the basic things, in a way that is actually good to do. C++ is infamous for a huge number of people using the language dangerously, to the point where there are effectively no idioms outside of specialist communities, and to find them out you need to read books. A significant amount of the basic design of the language needs to be ignored for most purposes.

PaulDavisThe1st 3y ago
One of the main places I see idioms in other languages is in dealing with containers (and there are some very nice ones). Python in particular, but others too. Slicing, splicing, iterating, mutating, map-reduce etc. etc. While I wouldn't say no to having such idioms available in C++ as language constructs, it is important that C++ continues to provide the lowest level that it can for such tasks (e.g. pointers into arrays or other buffers), and probably the level right above that (libstdc++). Similarly for threads (or more generally, parallel and asynchronous programming) - some other languages make available some really nice idioms for expressing these things, but again it is important for performance and control reasons that C++ continues to provide the current lowest level of access for this (basically a wrapper around pthreads). While things like promises, futures and coprocessing are really useful, they are often inappropriate for highly performant code.
- bowsamic 3y ago
  If rust can do it so well, I see no remaining argument about performance and control. It was long believed that C++ had to be bad in this way because such languages must be. Rust was the counter example that ended this myth
  - PaulDavisThe1st 3y ago
    That's not clear to me. The examples I've seen from anywhere that Rust has to deal with hardware suggest that you have to throw out most of the safety guarantees of the language, and this applies also to dealing with OS-provided abstractions of hardware (like MMU-mapped registers and mmap-ed memory regions). I don't have the impression that Rust's container idioms match those of, say, Python, but I may just not know Rust well enough.
    - bowsamic 3y ago
      You’re mistaken then, using unsafe does not mean throwing away the safety guarantees. This is a common misconception though, even among Rust users
      - PaulDavisThe1st 3y ago
        OK, let me put it differently: you cannot reason about safety in those circumstances in the way you can when "unsafe" has not been used. And since reasoning about safety (or perhaps more accurately, not needing to) is one of the raison d'etres for Rust, that's a bit of a hit. Not huge, but for those of us close to metal of some sort, it's a bit of a hit.
        bowsamic 3y ago
        Yes, you can reason about safety in just the same way, as long as a safe API is built around the unsafe usage. That’s why you can have safe OpenGL bindings even though the underlying raw C calls are unsafe E.g. https://github.com/glium/glium https://github.com/glium/glium Rust would be useless if you couldn’t have safety if you had any unsafe at any point. That’s the whole point of rust: you can build safe interfaces to unsafe actions

PaulDavisThe1st 3y ago

One of the main places I see idioms in other languages is in dealing with containers (and there are some very nice ones). Python in particular, but others too. Slicing, splicing, iterating, mutating, map-reduce etc. etc. While I wouldn't say no to having such idioms available in C++ as language constructs, it is important that C++ continues to provide the lowest level that it can for such tasks (e.g. pointers into arrays or other buffers), and probably the level right above that (libstdc++). Similarly for threads (or more generally, parallel and asynchronous programming) - some other languages make available some really nice idioms for expressing these things, but again it is important for performance and control reasons that C++ continues to provide the current lowest level of access for this (basically a wrapper around pthreads). While things like promises, futures and coprocessing are really useful, they are often inappropriate for highly performant code.

bowsamic 3y ago
If rust can do it so well, I see no remaining argument about performance and control. It was long believed that C++ had to be bad in this way because such languages must be. Rust was the counter example that ended this myth
- PaulDavisThe1st 3y ago
  That's not clear to me. The examples I've seen from anywhere that Rust has to deal with hardware suggest that you have to throw out most of the safety guarantees of the language, and this applies also to dealing with OS-provided abstractions of hardware (like MMU-mapped registers and mmap-ed memory regions). I don't have the impression that Rust's container idioms match those of, say, Python, but I may just not know Rust well enough.
  - bowsamic 3y ago
    You’re mistaken then, using unsafe does not mean throwing away the safety guarantees. This is a common misconception though, even among Rust users
    - PaulDavisThe1st 3y ago
      OK, let me put it differently: you cannot reason about safety in those circumstances in the way you can when "unsafe" has not been used. And since reasoning about safety (or perhaps more accurately, not needing to) is one of the raison d'etres for Rust, that's a bit of a hit. Not huge, but for those of us close to metal of some sort, it's a bit of a hit.
      - bowsamic 3y ago
        Yes, you can reason about safety in just the same way, as long as a safe API is built around the unsafe usage. That’s why you can have safe OpenGL bindings even though the underlying raw C calls are unsafe E.g. https://github.com/glium/glium https://github.com/glium/glium Rust would be useless if you couldn’t have safety if you had any unsafe at any point. That’s the whole point of rust: you can build safe interfaces to unsafe actions