"In my working life I have had to learn that a done well job is vastly preferable to an excellent or even a perfect job. "

There is a place and time where something like Python is appropriate for this. It's a matter of degree. i.e. when the demands go up to such an extent that performing the task in a language like Python no longer constitutes a "job well done".

Concrete example: Writing a MP4 video driver in Python and foisting it upon the public would probably not make anyone happy due to the atrocious performance that would result.

Another concrete example: In my project I have a stream of cryptographically encoded data on disk that must be transformed and transmitted over the wire at gigabit speeds. A proof of concept was written in Python to demonstrate the concepts, but an advanced implementation harnessing GMP in c++ had to be built to get the performance up, as Python could only move at about 10mbps. Writing bindings for c++ hooks into Python and trying to otherwise manage when and where copies happen Python-side would have been more convoluted and accident prone than doing it in c++ (e.g. is the python type doing a full "deep" copy of a custom type or vector? is it copying a reference? is the difference between the two obvious to the programmer? if we update something we think we copied and it modifies it via reference in several places unexpectedly, how hard will that be to debug?).

So to answer the question directly: When MUST one use something like c/c++? When you hit the limit of what you can realistically and practically get away with using a high level language.

Sent with [Proton Mail](https://proton.me/) secure email.

On Wednesday, August 21st, 2024 at 4:09 PM, o1bigtenor <o1bigtenor@???> wrote:

> On Mon, Aug 19, 2024 at 8:56 PM zeitgeisteater via Dng <dng@???> wrote:
>
>> I haven't read much of any of this, but will respond succinctly to the title.
>>
>> Why c/c++? Control. I can make very powerful type agnostic constructs that optimize very heavily for performance. I can also implement my own memory safety constructs as a matter of regimented course (internal design policy) e.g. to catch common mistakes that might happen at the higher level invocations... effectively building my own safety mechanisms into the language.
>
> This is the original OP here.
> I asked what made c/C++ so wonderful that one MUST use it.
> I think you're perhaps the first person who actually gave a clear answer.
> So you like these 2 languages because the give you control.
>
> Except I just want to get the job done - - - I don't want to learn things which give me perhaps umpteen different way to "blow my own leg off" !!!!!!!!
>
>> Is it more work? Yes. Is it easier to blow my own leg off with the complete freedom? Yes. Am I willing to outsource these elements to a third party? No.
>
> In my working life I have had to learn that a done well job is vastly preferable to an excellent or even a perfect job.
> In point of fact - - - I remember reading an issue of
> Byte magazine where they talked about mathematically proven correct constructs in programming which I believe would be perhaps impossible to do in either c or C++.
> As I would prefer to get the job done - - - I guess that I'm just weird and perhaps not of a typical 'software engineer' type mold although given the plethora of bugs
> in much of the software I run into - - - - well - - - I dunno!
>
>> Am I Luddite? I have embraced certain elements of the newer c++ standards, so I don't believe so. Features I find particularly useful in newer c++ versions are "constant evaluation functions" (a function that runs at compile time to produce a constant) and compiler hints to sort/prevent collisions with operator precedence (e.g. "explicit" keyword).
>
> I would be perhaps labeled as a luddite myself but then I see technology as a tool rather than my master.
> Have found that technology has over the last 15 years become less and less controllable largely due to
> the choices made by others on my behalf.
>
> Regards