Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How an Engineering Company Chose to Migrate to D

dlang.org

Post reply on HN
Print view View original

101–110 of 170 posts

Re: How an Engineering Company Chose to Migrate to D

#101

Post by protocode »

coldtea wrote: post #75
acehreli wrote: post #53

Earlier quoted context omitted.

Except that "the inclination of an individual towards a new language" is because of "the actual shortcoming of current language."

Actual or imaginary would be a better wording...

I see mostly imaginary. As a back end systems guy for over 20 years, I deal with guys all the time wanting to introduce new tools into the mix that add zero value. There is a reason why *nix tools are still around. There is nothing that Python can do better than awk for grabbing data columns and piping them into some other tool.

There is a reason why COBOL still exists, for example, what with its ability to ensure accuracy out to 38 digits. Nothing else comes close w/o tons of extra crap libraries, questionable code mangling, and TRUST. Banks trust COBOL because it has an almost 60-year history of trust.

When kids get all shiny-eyed over golang or Rust or any other "new" language or tool and think it would be a good fit in the financial arena, I start to get a little nervous.

Re: How an Engineering Company Chose to Migrate to D

#102

Post by pjmlp »

rhacker wrote: post #59
kungtotte wrote: post #49

Earlier quoted context omitted.

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if it's ultimately more expressive.

This is definitely key - one startup I worked for was messing around with live voice capture and processing, voice recognition, etc.. by and large the libraries we had access to that could help do tiny manipulations, cutting, processing of the waveform data was primarily C. We wrote most of our code in C++ because we could directly call C functions and use header files directly. This was 15 years ago, but I honestly…

That is how I migrated from Turbo Pascal to C++, around 1994, only touching C when required to do so.

Could make use of a saner type system, nice frameworks (Turbo Vision, OWL), while being able to painless create safe wrappers around C libraries.

Re: How an Engineering Company Chose to Migrate to D

#103

Post by WalterBright »

galadran wrote: post #10

> Nowadays, whenever D is publicly evaluated, the younger languages Go and Rust are often brought up as alternatives. Here, we need not go into an in-depth comparison of these languages because both Rust and Go lack one feature that we rely on heavily: nested functions with access to variables in their enclosing scope. Maybe I've misunderstood, but aren't Rust's closures [1] exactly what the author is describing? Spe…

D nested functions don't 'capture' variables from their enclosing scope. They can access them just like other code in the enclosing function.

This is achieved by adding a hidden parameter that is a pointer to the enclosing function's stack frame. This forms a threaded list so variables in nested enclosing functions can be accessed by walking that list.

This is the same way Pascal does it.

It also means that taking the address of a nested function produces a pair - a pointer to the function, and this hidden parameter to the enclosing stack frame.

Re: How an Engineering Company Chose to Migrate to D

#104

Post by jerf »

_veelo wrote: post #98
burntsushi wrote: post #38

Earlier quoted context omitted.

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

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

Speaking at least for Go, the "different syntax" between closures and functions is that for closures, you don't give a function name. The only way they could be any more similar is if closures did take a function name, which is generally a bad idea because there's no single behavior I've seen that captures what programmers expect to happen in that case. (In general, for the code

    x = func blah() { ... }
there is a conflict between "x is the only new binding we should have as a result of executing that line" and "the function name 'blah' should do some sort of binding".)

If that's enough to throw your translation process, you've got bigger problems....

(Cards on the table, D is probably a good choice and I'm not advocating for Go here.)

Re: How an Engineering Company Chose to Migrate to D

#105

Post by majormajor »

acehreli wrote: post #53
ssdd wrote: post #50

Earlier quoted context omitted.

Yeah, almost all the time its the inclination of an individual towards a new language that becomes the driving factor of migration rather than the actual shortcoming of current language.

Except that "the inclination of an individual towards a new language" is because of "the actual shortcoming of current language."

It's much easier for the inclination of an [a single] individual to be due to the perception of [just a single] individual, than if the impetus is a team-level inclination.

I've worked on projects where people had gripes about the codebase and/or language, but they often couldn't agree on which language to move to. So a single person taking over based on their own preference is either a bug or a feature: as a bug, it's ignoring everyone else's preferences and disagreements, and possibly moving to something the team is even less happy with. As a feature, it's making a decision instead of endlessly trying to find a perfect decision, and at least ending up somewhere better off than before.

In this case, it sounds like it could be the positive sort of change if only because they were starting from a basically-dead language. It sounds like without that single person's initial effort, they may have not started any effort to migrate to anything.

But this gives me major pause: "My colleagues will continue to develop in Extended Pascal as usual, and once my transpiler is able to translate all or almost all of it, we will make the switch to D overnight." I'd love to fast-forward to see what happens the days after that... and how long that takes to get to, for that matter!

Re: How an Engineering Company Chose to Migrate to D

#106

Post by WalterBright »

junke wrote: post #16
galadran wrote: post #10

> Nowadays, whenever D is publicly evaluated, the younger languages Go and Rust are often brought up as alternatives. Here, we need not go into an in-depth comparison of these languages because both Rust and Go lack one feature that we rely on heavily: nested functions with access to variables in their enclosing scope. Maybe I've misunderstood, but aren't Rust's closures [1] exactly what the author is describing? Spe…

The only difference I see is if you need recursive local functions, which is harder (but not impossible) to do with anonymous closures.

Recursive nested functions in D just work - the hidden parameter to the enclosing frame forms what's called a "static link". A "dynamic link" would be the usual pointer to the previous stack frame (not the enclosing stack frame).

Re: How an Engineering Company Chose to Migrate to D

#107

Post by WalterBright »

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…

Daniel Murphy is the one who wrote the translator.

Re: How an Engineering Company Chose to Migrate to D

#108

Post by [deleted] »

CyberShadow wrote: post #37
blackrock wrote: post #15

D has support for nested functions: I love nested functions. It's good when you need a quick local function, and don't want to expose it to the rest of the code base. But, how do you systematically unit test nested functions?

> But, how do you systematically unit test nested functions? Why, with nested unittests, of course! Just put them in a nested type first: void main() { static int nested(int x) { return x * 2; } struct Test { unittest { assert(nested(2) == 4); } } } Well, OK, that's more of a hack than a feature, and you obviously can't test non-static nested functions (as there'd be no way to give values to the outer function's fram…

[deleted]

Re: How an Engineering Company Chose to Migrate to D

#110

Post by kibwen »

_veelo wrote: post #98
burntsushi wrote: post #38

Earlier quoted context omitted.

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

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

> I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions.

It's unclear where the root of that confidence lies. The translation is just as mechanical in either language as it would be otherwise: see an inner function, replace it with the one thing that can capture variables. Speaking for Rust, it would actually be even easier to do the translation using closures, because Rust closures can have their signatures inferred whereas Rust functions cannot.

Post reply on HN