On Sunday, 15 May 2022 at 17:21:18 UTC, Walter Bright wrote:>
In my experience, it is not an option to rewrite working C code into D.
Note that I have successfully converted small and medium C code projects to D.
Don't these two sentences contradict each other? Unless I'm misinterpreting the meaning of words "converted" and "successfully".>
I've done other translations of programs from one language to another.
if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder
converting a program all at once does not work. It must be done incrementally, one function at a time
Can you elaborate on this? One function at a time conversion can be easily done if one language is mostly a superset of another, such as converting from C to C++. But converting from C++ back to C one function at a time would be not so easy anymore (because there are classes, templates and other advanced language features).>
- even so, when faced with a large, complex project, there's just no business case for doing a conversion
Yes, if it ain't broke, don't fix it. Especially if this costs money and introduces unnecessary risks.
C is not very good for implementing new code compared to the other programming languages. But once the job is done, long term maintenance is relatively painless. The language is standardized and newer versions of the compilers are only becoming more strict about certain things.
D is good for rapid development of new code, but isn't great for long term maintenance because of the language evolution and compatibility breakages. My understanding is that many D projects and libraries died off because they could not afford to keep up and can't be even compiled anymore.
I don't think that converting the existing C code into D makes much sense. Because such conversion only turns the strength of one language into the weakness of another.>
Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches. Hand-checking them is error-prone, tedious and very boring work.
Well, everyone is doing this and bindings for popular C libraries are available for most programming languages.>
ImportC makes things so much easier. You can write new D code and hook it up with your existing C code base. You can get reliable, easy, and accurate access to .h files. D will happily work with a project that's a patchwork of C and D code.>
I.e. it dramatically lowers the barrier to adopting D.
Do I understand it right that ImportC is intended for implementing major new features in the existing old C projects using D language?
One of the old C projects is the Linux kernel. I know that some people are working on making it possible to develop some parts of the Linux kernel using Rust language. Would ImportC make it possible to use D for developing some parts of the Linux kernel and how is it different from what Rust people are doing?