On Wednesday, 18 October 2023 at 06:48:59 UTC, monkyyy wrote:
> On Wednesday, 18 October 2023 at 05:05:22 UTC, Imperatorn wrote:
>> Should add D here
>>
>> https://www.codeconvert.ai/
>
> ai start-ups are as dubious as the peak dotcom website without a business plan

I think their business plan is very simple... cashing over a service that translates code. =]

Well, we never know how this will end-up... but everyone is fixed with this 'AI' thing nowadays, but anyway... you know sending your code to a server which you don't know how it will handle your data/code is something that I wouldn't do it for a proprietary code.

Finally from their FAQ: "...Thus, we cannot say that the conversions will always be exactly correct."

I wonder if they compile the translated code before returning the answer, or just returns whatever was converted without any checking.

Matheus.

On Wednesday, 18 October 2023 at 13:55:51 UTC, matheus wrote:
>
> I wonder if they compile the translated code before returning the answer, or just returns whatever was converted without any checking.
>

Tried already, it's ChatGPT type of thing, (I suspect they just call ChatGPT API), the generated code is the same quality as ChatGPT conversion output (you can ask ChatGPT do that too, and without limit), neither syntactic nor semantic error are checked. But it's an convenience than manually convert everything.

On Wednesday, 18 October 2023 at 14:53:31 UTC, mw wrote:

> But it's an convenience than manually convert everything.

On the other hand, there's no reason to manually convert C to D. The only way I'd see something like this to be truly useful is if it understood how to write good code. That could be the fastest code, the easiest to extend, the best API, etc., but AI is not there yet.

On 10/18/2023 11:25 AM, bachmeier wrote:
> On the other hand, there's no reason to manually convert C to D.

I manually converted the D backend from C to D. It didn't take long - mostly because:

1. I'd already removed my oh-so-brilliant C preprocessor metaprogramming

2. A bit of global search/replace handles quite a lot

Of course, the result still looks and acts like C code.

On Wednesday, 18 October 2023 at 23:09:11 UTC, Walter Bright wrote:
> On 10/18/2023 11:25 AM, bachmeier wrote:
>> On the other hand, there's no reason to manually convert C to D.
>
> I manually converted the D backend from C to D. It didn't take long - mostly because:
>
> 1. I'd already removed my oh-so-brilliant C preprocessor metaprogramming
>
> 2. A bit of global search/replace handles quite a lot
>
> Of course, the result still looks and acts like C code.

I just want to say. I'm quite impressed by how easy it was to port C to D manually.

For example a hashmap, I found, took 15 minutes. And another library took about 30 minutes.

The only friction was strings, but it wasn't a show stopper.

Also btw, I'm very curious, about if ImportC could handle dependencies?

If all files are present, could it compile those as well? Sorry for my ignorance

On Wednesday, 18 October 2023 at 23:09:11 UTC, Walter Bright wrote:
> On 10/18/2023 11:25 AM, bachmeier wrote:
>> On the other hand, there's no reason to manually convert C to D.
>
> I manually converted the D backend from C to D. It didn't take long - mostly because:
>
> 1. I'd already removed my oh-so-brilliant C preprocessor metaprogramming
>
> 2. A bit of global search/replace handles quite a lot
>
> Of course, the result still looks and acts like C code.

Oh I can do better than that. I can drop foo.c in the project directory and call all of those functions without doing anything else. Code conversion is usually pointless, because the functions in the .c file work, they're documented, the edge cases have been handled, it's all been tested, and I can update by dropping an updated foo.c in the project directory. If I have the urge to convert, I'm going to do a full rewrite of the code so it's easy to read and easy to work with, like D code is supposed to be.