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

161–170 of 170 posts

Re: How an Engineering Company Chose to Migrate to D

#161

Post by blub »

coldtea wrote: post #153
acehreli wrote: post #126

Earlier quoted context omitted.

You never said "C" but perhaps you think there is "a reason" why C still exists too. The only reason ineffective tools like C exist is because there are people at the other extreme from those kids: Not take any risk but stick with tried and wrong tools.

Nope, there are tons of other reasons. Huge pool of programmers. Huge pool of libraries. Tons of existing code that should continue to run. Excellent documentation. Very fast compilers. Debuggers and profilers a plenty. Top notch vendor support. Choices of IDEs. Works great in embedded. Predictable. The alternatives being what, e.g. Rust, a 5 year old language with a single implementation that still tries to find its…

Rust, D or Go could be alternatives, but they have limitations in certain domains and types of projects.

C++ doesn't though, and that's why traditional C projects switch. At least in automotive it seems to be the language of choice.

Re: How an Engineering Company Chose to Migrate to D

#162

Post by WalterBright »

JdeBP wrote: post #158
WalterBright wrote: post #103

Earlier quoted context omitted.

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 th…

It's the same way that MetaWare implemented nested functions in its C/C++ compiler in the 1980s and 1990s, too. On top of that, MetaWare built iterators and an iterator-driven for mechanism. The yield() in an iterator was actually a nested function callback from the iterator to the body of the invoking for statement, which was turned into a nested function under the covers. * http://jdebp.info./FGA/metaware-iterator-…

The ENTER and LEAVE instructions only supported dynamic linking (pointer to caller's stack frame) not static linking (pointer to the enclosing function's stack frame).

Re: How an Engineering Company Chose to Migrate to D

#163

Post by _veelo »

scj wrote: post #118
_veelo wrote: post #89

Earlier quoted context omitted.

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 rea…

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?

Re: How an Engineering Company Chose to Migrate to D

#164

Post by creatornator »

earenndil wrote: post #124
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

I wouldn't say go is at all a better c++. It has very different stated goals and a different philosophy. As for d and rust, they improve on c++ in very different ways, just because they're both improvements on c++ doesn't mean they're the same. For example: * D has generally better metaprogramming, however, rust has real macros * D has a garbage collector and defaults to code being memory-unsafe. Rust uses ownership…

I think you've got the wrong idea on "self-hosted". That just means the compiler is written in the language itself. Rustc is written in rust, so it is self-hosted (even if it has an LLVM backend). And likewise, all three D implementations are written in D, despite having either baked-in code generation, a gcc backend, or an llvm backend. You can check the repos on github: all three of DMD, LDC, and GDC are written in D-lang, so they are self-hosted.

Re: How an Engineering Company Chose to Migrate to D

#165

Post by FeepingCreature »

arunc wrote: post #144
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

Personally/Syntactically I've found that coding in D is much pleasant than C++. Consistent '.' operator for the equivalent '.' '->' '::' in C++, template meta programming for humans, modules, UFCS, etc, etc. But a killer feature that's available in C++, but not available in D is pure RAII idiom. Sure D does scoped destruction (via struct's destructor), but is in no way equal to the contructor+destructor combination i…

You can disable the default constructor on structs with @disable this(); Then the only proper way to initialize the struct is with its parameterized constructor.

Re: How an Engineering Company Chose to Migrate to D

#166

Post by earenndil »

mratsim wrote: post #131
earenndil wrote: post #124

Earlier quoted context omitted.

I wouldn't say go is at all a better c++. It has very different stated goals and a different philosophy. As for d and rust, they improve on c++ in very different ways, just because they're both improvements on c++ doesn't mean they're the same. For example: * D has generally better metaprogramming, however, rust has real macros * D has a garbage collector and defaults to code being memory-unsafe. Rust uses ownership…

I don't understand the "D has generally better metaprogramming, however, rust has real macros" statement. Or do you mean like even though Rust allows you to work on AST, it's too clunky compared to D string mixins?

I don't mean the string mixins, I mean more the template metaprogramming.

Re: How an Engineering Company Chose to Migrate to D

#167

Post by JdeBP »

WalterBright wrote: post #162
JdeBP wrote: post #158

Earlier quoted context omitted.

It's the same way that MetaWare implemented nested functions in its C/C++ compiler in the 1980s and 1990s, too. On top of that, MetaWare built iterators and an iterator-driven for mechanism. The yield() in an iterator was actually a nested function callback from the iterator to the body of the invoking for statement, which was turned into a nested function under the covers. * http://jdebp.info./FGA/metaware-iterator-…

The ENTER and LEAVE instructions only supported dynamic linking (pointer to caller's stack frame) not static linking (pointer to the enclosing function's stack frame).

That is not in fact true.

ENTER copies M words from the caller's stack frame. The pointer passed by MetaWare High C/C++ in the register could equally well have been placed at the relevant position in the caller's stack frame, just as other arguments are, and an ENTER N,1 used as part of the perilogue.

The only consideration here is speed of the ENTER instruction versus having the hidden pointer in a register, not that this sort of nested function implementation is somehow impossible with ENTER. It's just another case of ENTER is slow and other instructions do the same thing better.

* http://jdebp.info./FGA/function-perilogues.html#Standardx86

(Part of that consideration is making non-nested functions usable via full function pointers.)

Re: How an Engineering Company Chose to Migrate to D

#168

Post by scj »

_veelo wrote: post #163
scj wrote: post #118

Earlier quoted context omitted.

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 rea…

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…

I think point one is the concern of most people on this page. The most I've ever transpiled is 40kloc (this was for an R&D project, I'd think twice before doing it in production). ~500kloc is a different matter.

What % of the codebase are you familiar with? What % of the code is known by your team? If you had multiple, conflicting errors pop up at once, how much effort would it take to isolate them (not fix, just identify). What about in a section where no one has worked in a long time (assuming such a thing exists)?

Like any old codebase, I'm sure there are functions that have "just worked" for years (or in this case, decades). With a single action, every piece of code that's been proven solid over time is about to be suspect.

For point two, I think you have a lot more confidence in your ability to detect problems than I would in your shoes.

For point three, I'd much rather manually port necessary code piece by piece over a period of years. Unit testing like crazy while doing so. Thanks to linking, this is an option... One I'd recommend.

Point four is similar to majormajor's comment about the aftermath of the switch. I'm attempting to project beyond the immediate... This port could become a whipping boy... That could bleed into political fallout. No matter what technology you introduce, people will complain. Doubly so if problems arise. Adding a custom transpiler on top of that increases the risk significantly. The easiest transition path to a ${NEW_LANGUAGE} is through linking.

I'm not sure about Python vs. D. My instincts are towards the former, especially if I'm supporting SEM (STEM minus the T) grads as programmers. I also wouldn't easily write off interpreted languages (I'd rather work with them when possible).

I think you have your heart set on this path. But losing the binary safety net in favour of a bespoke transpiler is not a gamble I'd make with large amounts of production code...

Good luck!

Re: How an Engineering Company Chose to Migrate to D

#169

Post by EvenThisAcronym »

arunc wrote: post #143
Const-me wrote: post #120

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 gene…

> I’m surprised to see a lot of criticism in the comments. I'm not surprised to see criticism for D on HN. While reading HN comments on posts related to D, I've always found pro Rust/Go comments.

There's a strictly adhered to rule across Reddit/HN that every D article must consist primarily of people asking why the author did not use Rust/Go instead.

Re: How an Engineering Company Chose to Migrate to D

#170

Post by WalterBright »

JdeBP wrote: post #167
WalterBright wrote: post #162

Earlier quoted context omitted.

The ENTER and LEAVE instructions only supported dynamic linking (pointer to caller's stack frame) not static linking (pointer to the enclosing function's stack frame).

That is not in fact true. ENTER copies M words from the caller's stack frame. The pointer passed by MetaWare High C/C++ in the register could equally well have been placed at the relevant position in the caller's stack frame, just as other arguments are, and an ENTER N,1 used as part of the perilogue. The only consideration here is speed of the ENTER instruction versus having the hidden pointer in a register, not tha…

You're right.
Post reply on HN