How an Engineering Company Chose to Migrate to D • Hacker News Board

Re: How an Engineering Company Chose to Migrate to D

#111

Post by atombender » Wed, Jun 20, 2018, 6:41 PM UTC

trishume wrote: post #60

seren wrote: post #5

Maybe I am too timid, but the closing word saying that once the transpiler is ready they could switch overnight seems a bit optimistic. I feel that splitting as much as possible the project into chunks/components and then replacing them one by one sounds more realistic (with the appropriate test harness). Maybe that is the plan but it is not touched in the post. And then maybe an issue that is not that bad, but you a…

There is precedent for this, even within D. The DMD compiler was originally written in C, and someone went to the effort to write a C to D transpiler, worked on it until it was flawless, then ran it overnight and did the transition all at once: https://github.com/dlang/dmd/pull/4923 I think the Go compiler did something similar. It certainly requires iteration of continuously attempting the translation until it works…

The original c2go Go transpiler used to transform the original C compiler to Go wasn't able to produce identically-behaving code, last I heard. It required manual editing. It's no longer maintained, but the fork [1] is much more ambitious, and aims to produce compilable, working programs.

[1] https://github.com/elliotchance/c2go

Re: How an Engineering Company Chose to Migrate to D

#112

Post by xyproto » Wed, Jun 20, 2018, 6:49 PM UTC

> [Go lacks] nested functions with access to variables in their enclosing scope

Surely Go has this?

func main() { a := 1 func() { b := a g := func() { c := b fmt.Println("c is", c) a = 7 } g() }() fmt.Println("a is now", a) }

https://play.golang.org/p/zmWwCNm_PuU

Re: How an Engineering Company Chose to Migrate to D

#113

Post by robocat » Wed, Jun 20, 2018, 6:55 PM UTC

burntsushi wrote: post #38

Xophmeister wrote: post #7

While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation. The need…

> (Also, don't Rust and Go have closures? Surely that would satisfy this requirement.) Indeed they do. It's completely unclear why they don't satisfy the OP's requirement.

From: https://www.reddit.com/r/programming/comments/8si75b/comment...

"In Rust, only lambdas (unnamed functions) can be closures".

The OP's post seems to show they didn't spend much time understanding whether Go closures could serve their need. Although from my own superficial understanding, D is "closer" to Pascal than Go.

Re: How an Engineering Company Chose to Migrate to D

#114

Post by dataking » Wed, Jun 20, 2018, 7:08 PM UTC

jasonszhao wrote: post #96

dataking wrote: post #91

Really cool to see companies willing to migrate to a more modern language. I'm part of a team working on C to Rust migration tools (partly inspired by the Corrode translator). Shameless plug/pre-alpha demo: https://www.c2rust.com Edit: missing word.

Your SSL certificate works in Chrome, but not in my Safari 11.1.1. SSL Shopper (not sure how reliable this is), also shows warnings. https://www.sslshopper.com/ssl-checker.html

Thanks so much for letting me know; should be fixed now.

Edit: reflect resolved status of issue.

Re: How an Engineering Company Chose to Migrate to D

#115

Post by mhh__ » Wed, Jun 20, 2018, 7:18 PM UTC

baybal2 wrote: post #66

All Rust, D and Go pass as "better C++" To me, the evaluation goes solely as ecosystem vs. ecosystem There D is ahead not so much by number of features, than by lack of showstopper flaws

Go's lack of generics make it a strange choice to replace C++, philosophically rather than functionally.

Re: How an Engineering Company Chose to Migrate to D

#116

Post by WalterBright » Wed, Jun 20, 2018, 7:20 PM UTC

lambda wrote: post #77

Xophmeister wrote: post #7

While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation. The need…

Yeah, it looks like the author started playing around with D and writing a Pascal to D compiler for the migration, then did the evaluation with a "requirements" list that seems fairly heavily weighted towards D and their approach to translation by doing a simple recursive walk of the Pascal parse tree and outputting equivalent D, then decided to go with what they had already started working on. Rust does support nest…

D nested functions are defined exactly like regular functions, including all attributes, parameter types, etc. There's nothing new to learn.

My experience as a language designer is that syntax matters, and leveraging the users' existing knowledge is worthwhile.

Re: How an Engineering Company Chose to Migrate to D

#117

Post by 52-6F-62 » Wed, Jun 20, 2018, 7:21 PM UTC

philjohn wrote: post #32

Xophmeister wrote: post #7

While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation. The need…

The biggest problem is they have engineers who have turned their hands to programming, one would expect, without the formal training and so have latched onto various antipatterns without knowing any better because Pascal allowed them to get away with it - painting themselves into a corner. He mentioned an awful lot of code that would have to be refactored, and it could be that they are just too far down the rabbit ho…

To be fair, I work with a large number of formally trained engineers who commit far worse in terms of anti-pattern and data hygiene infractions on the regular and I’ve had the fortune of refactoring their messes.

I don’t think it’s solely dependent on having afforded formal training.

Knowing enough to know that you might not know and just might need to measure or look something up and caring enough to do so is more of the core of it.

Re: How an Engineering Company Chose to Migrate to D

#118

Post by scj » Wed, Jun 20, 2018, 7:21 PM UTC

_veelo wrote: post #89

scj wrote: post #61

Earlier quoted context omitted.

In this case, I'd look into compiling the existing code into .dll/.so files, and just linking between Extended Pascal and ${NEW_LANGUAGE}. Then, convert the code to ${NEW_LANGUAGE} as needed, if needed. That solution is probably the lowest cost / safest course... Assuming the Extended Pascal compiler they have supports it. But I suspect choosing D was a fait accompli.

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.

Hello, I assume by your username that you're the author!

Transpiling is normally a little risky. Transpiling with a custom transpiler over ~500KLOC is downright terrifying.

I'd be concerned that the cure is worse than the disease.

I understand the allure of this solution. Bringing 30ish years of code into the modern era with a single piece of code sounds like a huge win. But you owe it to your employer (who seems really gracious and trusting) to ask:

1. Are there edge cases? Programmers are a clever bunch, and you can never be too sure about what features/bugs they've used/abused!

2. How will success of the transpile be determined? I'd use unit tests, but that'd take a lot of unit tests!

3. What % of that code path is critical? Can you get away with ensuring the functionality of a subset of the codebase? If so, could you just manually port that?

4. "Blaming the compiler" will be a reasonable excuse for any problem over the next year or two after deployment. I guarantee you'll be spending time proving that other peoples' mistakes are not your fault. How much flak are you and your boss going to take for this?

5. Since the code can be linked, might a more popular language (that will be known by a wider community) with a slow porting plan be reasonable?

6. Python is commonly used with scientific computing. Why does this case preclude it? If you are doing mostly numeric processing, that gets directly passed to the hardware anyway!

You have been given a rare chance to pay down technical debt. From what I understand of your solution, I believe the bespoke transpiler and semi-known language will ultimately increase it. And I know you love D, but if I were brought in as a consultant, I'd be recommending the .dll/.so solution with Python. If something is really time sensitive, use Python binding to work with other languages (avoiding premature optimization).

Even if myself or my fellow posters made a point that resonated, it might be too late for such discussions. I can't weigh the political costs for changing strategy now. So I'll wish you good luck, and hope that Extended Python doesn't have too many sharp edges for you to contend with. I hope to see a postmortem a few years from now detailing the outcome of this plan.

Re: How an Engineering Company Chose to Migrate to D

#119

Post by abiox » Wed, Jun 20, 2018, 7:34 PM UTC

oh-kumudo wrote: post #85

How do they plan to solve the hiring problem? I am curious.

if you mean "hiring d programmers", i think it's somewhat of a nonissue. afaik d isn't particularly esoteric, so any new hire should be able to get up to speed quickly.

Re: How an Engineering Company Chose to Migrate to D

#120

Post by Const-me » Wed, Jun 20, 2018, 7:34 PM UTC

I’m surprised to see a lot of criticism in the comments.

Generally, I prefer mainstream languages myself, that’s why I mostly code C++ and C#. But “generally” is the key here. For some projects, or some parts of it, picking a non-mainstream language can be a huge win in terms of productivity.

I never used D in production, but I can remember several occasions where I picked unusual languages, both specialized and general purpose ones. Among others, I’ve used XSLT, sed, awk, VBScript, VB.NET, R, power shell, AutoLISP, MATLAB.

Theoretically all modern programming languages are equivalent because Turing-complete. Practically, for a particular problem, it can be orders of magnitude difference in development time between them. The reasons include availability of specific libraries, integration with other code be it third-party or legacy, or specific runtime features.