_veelo

What's the problem?

Free Pascal was actually on the shortlist of SARC, together with Ada and D [1]. We had different requirements though: GUI was not an issue as we have our own GUI; neither was an IDE. What was very important in our case was D’s compile time reflection capabilities which has enabled us to implement (de)serialisation to/from the binary format that the old Pascal implementation produced. In the maritime industries it is important to be able to build on projects that were developed in the past.

Pascal is not a bad language for engineering, in some aspects it is even better than D. Still, the combined features of D made it a winner over all, in our case.

[1] https://dlang.org/blog/2018/06/20/how-an-engineering-company...

What would these compilers have as advantage over the existing compilers?

Back when there was just one D compiler the common complaint was that this was too few. Now that there are three you sometimes read that there are too many. This is the first time I see someone needing more :)

I work for another company also putting its eggs in the D basket (SARC). We do not consider this risky because of two main reasons:

1) D is not dependent on the funding of one big corporation, so our future is not at the mercy of such corporation.

2) Three highly compatible compilers exist, all of them libre. Inclusion into gcc is probably the best insurance for any language.

The D community may be comparatively small, but for us it is big enough. Changes in and around the language may happen comparatively slowly, but for us they happen fast enough. Tooling may be comparatively limited, but we are actually rather impressed by what is available.

The language itself is of course awesome.

1. Unconsidered edge cases? We'll have to find out... We can always change the _source_ code to eliminate known unhandled edge cases.

2. We ourselves are heavy users of our software, and are likely to be the first to discover "oddities". More serious are subtle numeric differences, and we'll have to create tests against that. One approach to validating the transpiler is instrumenting the code. We could write a Pascal-to-Pascal transpiler that inserts extra code, for example logging the return value of every function. If we do the same for the Pascal-to-D transpiler, and do an identical run, we can compare the logs. And variations of that approach.

3. If a small percentage is unproportionally hard to translate mechanically, we can isolate that and translate manually.

4. I fail to see what you are getting at.

5. Of course we can link code. We think the community is wide enough for us.

6. You mean it gets passed to C.

Thanks for the suggestion. We have a working dual language situation with C++, we don't see that as an attractive option for our other tools. Why would Python be better than D?

To be frank: I have never used Rust nor Go. Nevertheless, I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. The same argument is being discussed at reddit https://www.reddit.com/r/programming/comments/8si75b/how_an_...

Confirmed.

Indeed!

Indeed, it serves encapsulation.

This is the approach I took to modernise Fairway (which is just one component of our suite). It doesn't free us from the limitations of the Extended Pascal compiler. It still works, but we want a way out.