How an Engineering Company Chose to Migrate to D

[Bastiaan Veelo]

On Saturday, 23 June 2018 at 09:41:19 UTC, Ecstatic Coder wrote:

> Where I disagree with Bastiaan is on the rejection of the 
> Pascal language itself, as there are other open-source Pascal 
> compilers (GNU Pascal in EP mode) which could have been used 
> and enhanced to match the company requirements, while 
> preserving the company future for the decades to come.

Yes, it's a shame that GNU Pasal (gpc) is in the shape it is. 
Betting on gpc would be like betting on a dead horse. The name 
GNU Pascal is misleading, as gpc was never integrated with gcc. 
There's this thread [1] from 2004 that integration was already 
overdue, and that an initiative to do this in 2000 had failed. In 
2006 it was apparent that gpc was falling out of the mainline [2] 
by failing to port to gcc 4.

Quoting Wikipedia:
> In July 2010 a developer publicly asked opinion [3] (it 
> vanished from the web between July/2014 and June/2015) on the 
> future of GNU Pascal, due to developer shortage and maintenance 
> issues as a GCC port. There was a lively discussion on the 
> maillist [4] where the developers seemed to lean towards 
> reimplementing in C++ with a C code generating backend. The 
> maillist went to sleep again, and as of December 2016 no 
> further releases or announcements about the future course of 
> the project have been made.

As you can see, I was part of that discussion [4] in which I 
suggested to use D instead of C++ for a reimplementation. If only 
they knew then what we know now.

I have tried to use gpc for the SARC code base in 2006, which 
mostly worked except that SARC had started using Prospero 
extensions (without being conscious about it). EP support in gpc 
may also not have been complete yet, I am not sure. This made a 
port too costly, considering that Prospero was still working very 
well. In addition, the string binary compatibility would probably 
also have popped up, as the standard does not define a string 
implementation, so the binary representation of strings depends 
on the compiler implementation. I also was less experienced, 
which is why I didn't want to pick up a corroding project outside 
my field of expertise.

> IMHO, implementing a EP-to-D source code converter was probably 
> more risky than simply extending an existing Pascal Compiler in 
> that case.

Risc is in the eye of the beholder ;-)

> Like everybody here, I hope that Bastiaan efforts will pay in 
> the long term, but I'm not as optimistic as many here that this 
> will end as a success story, as I'm not sure that his teammates 
> will really enjoy working the automatically generated D code as 
> much as on the original source code...

We will have to see. In the meantime, I already completed 
automated translation of our test case of schematic types, a 
difficult one.

I want to thank everyone for all the attention to this article 
and for the project in general. I'll keep you guys posted!

Bastiaan.

[1] https://gcc.gnu.org/ml/gcc/2004-12/msg00782.html
[2] http://www.g-n-u.de/pipermail/gpc/2006-November/013950.html
[3] 
https://web.archive.org/web/20140714170318/http://fjf.gnu.de/gpc-future.html
[4] http://www.g-n-u.de/pipermail/gpc/2010-July/thread.html