On Friday, 22 June 2018 at 02:45:06 UTC, Tony wrote:
> On Wednesday, 20 June 2018 at 18:21:01 UTC, Bastiaan Veelo wrote:
>> On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote:
>>> On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote:
>>>> The blog:
>>>> https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/
>>>>
>>>> Reddit:
>>>> https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/
>>>
>>> number 1 on hn
>>> https://news.ycombinator.com/item?id=17355348
>>
>> OMG how am I to respond to all the comments, I cannot see the end of it!
>
> Who produces the Extended Pascal compiler you have been using?

Oops, never mind. Read the article and see it's Prospero Software.

On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote:
> If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward.
>
> The blog:
> https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/

Man, proggit can be savage with the criticism. Every Nim/Rust and the one Ada programmer have come out of the woodwork to make sure you know their language supports nested functions. You've seemingly got to be an expert in every current language to write a comparison article that suggests D may have some advantages.

On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote:
> If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward.
>
> The blog:
> https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/

i hope some of the core people are helping with this transition and making sure this becomes a D success story.

> Man, proggit can be savage with the criticism. Every Nim/Rust and the one Ada programmer have come out of the woodwork to make sure you know their language supports nested functions. You've seemingly got to be an expert in every current language to write a comparison article that suggests D may have some advantages.

I've read the criticisms about the choice of the alternative language on the Reddit page, and I think that most of them are finally quite unfair.

In my programming career, I've already used many strongly-typed languages (C, C++, C#, Java, D, Go, Rust, Nim, Crystal, Julia, Pascal, etc) for at least one professional or personal project, and I'm also convinced that D is a good alternative to EP, especially compared to C++, Go and Rust for instance.

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.

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

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...

On Saturday, 23 June 2018 at 09:41:19 UTC, Ecstatic Coder wrote:
>> Man, proggit can be savage with the criticism. Every Nim/Rust and the one Ada programmer have come out of the woodwork to make sure you know their language supports nested functions. You've seemingly got to be an expert in every current language to write a comparison article that suggests D may have some advantages.
>
> I've read the criticisms about the choice of the alternative language on the Reddit page, and I think that most of them are finally quite unfair.
>
> In my programming career, I've already used many strongly-typed languages (C, C++, C#, Java, D, Go, Rust, Nim, Crystal, Julia, Pascal, etc) for at least one professional or personal project, and I'm also convinced that D is a good alternative to EP, especially compared to C++, Go and Rust for instance.
>
> 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.
>
> IMHO, implementing a EP-to-D source code converter was probably more risky than simply extending an existing Pascal Compiler in that case.
>
> 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...

Yes but their job is to make boats floating (like said Veelo at Dconf 2017, not writing compilers. Pascal lags behind and not a few, in term of expressiveness.
Also transpilation of Pascal to something else is simple because no semantic is needed.

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

On Saturday, 23 June 2018 at 10:00:48 UTC, user1234 wrote:
> On Saturday, 23 June 2018 at 09:41:19 UTC, Ecstatic Coder wrote:
>> 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...
>
> Yes but their job is to make boats floating (like said Veelo at Dconf 2017, not writing compilers. Pascal lags behind and not a few, in term of expressiveness.
> Also transpilation of Pascal to something else is simple because no semantic is needed.

Indeed, my expectation is that I don’t even need to maintain a symbol table. Stefan Koch disagrees with me though, and I’m on a quest to prove him wrong ;-)

>> 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 ;-)
>

Indeed :)

But that doesn't mean I'm completely wrong.

I also enjoy A LOT implementing minimalistic transpilers using the most simplistic code possible, because implementing manual tokenization and a parsing using only "baby code" is really all that's needed for my small DSLs.

My Github account is literally full of them ;)

So yes, implementing transpilers is incredibly fun and easy.

But implementing full blown compilers too actually.

And the advantage of compilers which generate assembly code is that you don't have to fight with the unavoidable limitations of the high-level target language.

For instance I've implemented my first "true" compiler in Basic when I was 13 years old, in order to implement my first 3D renderer and game for my C64 (a simple 3D wireframe tank game using a custom 2x4 pixel charset for rendering), as I quickly found out that it was actually much faster and easier to implement it in a minimalistic basic-like language with integrated fixed point and pointer arithmetic converted into 6502 machine language, than to implement the game directly in 6502 assembler.

So if at one moment you hit a wall with the transpiling approach, you should consider trusting me if I say that implementing an EP compiler which emits IL code could actually be just a matter of months.

Look at the code of this tutorial, which shows how to implement a very limited closure-based language (i.e. with local functions and variable) in C using just Flex and Bison :

https://github.com/senselogic/COMPILER_TUTORIAL

It was implemented in just a few days, and if you check by yourself, you will see that it's 100% baby code...

So if you change your mind and decide to implement your own extended EP compiler (i.e. with additional modern features), you could be astonished by the number of passionate developers who could also be interested in this "modern object Pascal" project...

That's the approach they've had for Crystal, and so far it's worked quite well for them...