On Sunday, 15 May 2022 at 06:18:58 UTC, forkit wrote:>
Getting it wrong in software has always had consequences, sometimes really bad consequences. But since software now operates in entirely new spheres that affect all aspects of our life and economy, developers have a wider obligation that just stitching together software so that it works.
Most software is not critical, but in this case you are worse off by hand translating a header file which is more error prone.
The question is if there is enough patience to design and implement macro expansion in a way that works well. That I cannot tell.>
Structured higher-level languages is where we need to be moving towards, not moving backwards to low-level languages like C.
Right, but D will always have raw pointers, so that cannot be D.>
Also, operating systems of the (near) future will require safety guarantees from the software that is intended to run on that operating system. C is not a language that facilitates this.
Not sure what you mean, safety guarantees are on the hardware and OS. Beyond that safety cannot be had as you can implement an interpreter that emulates C.
Also, look at Android that had Java, then put in an effort to allow C.
Same with web browsers.
I was (initially) attracted to D because of how it advanced the problem of writing safe code (particulary @safe). This is what would make D 'popular'.
But ImportC is short-sighted in my opinion, and is a step in the opposite direction.
The focus should instead be on @safe, not C.
You cannot have a reasonable safe language without designing the language for that from the ground. Most languages are safe, so there are many to choose from. There is no shortage on safe languages.
D will never be able to offer more than «safer than» C.