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

Re: How an Engineering Company Chose to Migrate to D

#131

Post by mratsim » Wed, Jun 20, 2018, 9:01 PM UTC

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

Re: How an Engineering Company Chose to Migrate to D

#132

Post by dom96 » Wed, Jun 20, 2018, 9:02 PM UTC

> After this initial pruning, three languages remained on our shortlist: Free Pascal, Ada and D.

I'm really sad to see that the author didn't even consider the Nim programming language. They could have saved themselves a LOT of work, Nim's original compiler was written in Pascal and then translated to Nim using a `pas2nim` tool that is freely available on GitHub[1].

Out of Go, Rust and D, Nim is most similar to Pascal by a long shot. Did the author simply miss Nim completely or did they dismiss it for another reason? It seems to me like it would be absolutely perfect for their project.

1 - https://github.com/nim-lang/pas2nim

Re: How an Engineering Company Chose to Migrate to D

#133

Post by mratsim » Wed, Jun 20, 2018, 9:05 PM UTC

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…

Given the Pascal history and even consideration of Ada, with the focus on expressiveness and ergonomics I'm surprised that Nim didn't make the shortlist. Nim even has an official Pascal-->Nim converter (called pas2nim) as the very early versions of Nim before bootstrapping were in Delphi.

Re: How an Engineering Company Chose to Migrate to D

#134

Post by protocode » Wed, Jun 20, 2018, 9:13 PM UTC

acehreli wrote: post #126

protocode wrote: post #101

Earlier quoted context omitted.

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

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.

C still has it's place. It's not glamorous, but it works. COBOL has no decent replacements. Yet. Some have tried. Almost all have failed. Old does not mean useless. If it works, then it's not wrong.

Re: How an Engineering Company Chose to Migrate to D

#135

Post by blub » Wed, Jun 20, 2018, 9:36 PM UTC

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…

Python has two big issues: performance and dynamic typing.

The solution of using a HLL and dropping down to C for performance strikes me as overly optimistic: the only language where one can legitimately claim that it's pleasant to use C for extra performance is Objective-C. Anything else will be different degrees of painful.

I didn't get the solution of using a dynamic lib and calling/extending that from Python. One would end up with 500kloc of Pascal and a Python one liner. All the work still happens in Pascal.

Re: How an Engineering Company Chose to Migrate to D

#136

Post by Rusky » Wed, Jun 20, 2018, 9:39 PM UTC

WalterBright wrote: post #103

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

That's usually what "capture" means when talking about closures.

Re: How an Engineering Company Chose to Migrate to D

#137

Post by tikue_ » Wed, Jun 20, 2018, 9:49 PM UTC

Rusky wrote: post #136

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…

That's usually what "capture" means when talking about closures.

At least in Rust, capture granularity is per-variable, so I think closures don't contain a stack frame pointer? Though, I'm not sure why this would matter to a user evaluating Rust's closures vs. D's nested fns?

Re: How an Engineering Company Chose to Migrate to D

#138

Post by steveklabnik » Wed, Jun 20, 2018, 9:57 PM UTC

tikue_ wrote: post #137

Rusky wrote: post #136

Earlier quoted context omitted.

That's usually what "capture" means when talking about closures.

At least in Rust, capture granularity is per-variable, so I think closures don't contain a stack frame pointer? Though, I'm not sure why this would matter to a user evaluating Rust's closures vs. D's nested fns?

It’s a pointer to the environment, and a pointer to the function. So yes, not a stack frame pointer.

The environment is a struct containing what is captured; so for example, it would contain an &T if your closure captures a T by reference. You don’t need to walk a set of stack pointers to find it, just follow the reference directly there.

Re: How an Engineering Company Chose to Migrate to D

#139

Post by [deleted] » Wed, Jun 20, 2018, 10:01 PM UTC

acehreli wrote: post #126

protocode wrote: post #101

Earlier quoted context omitted.

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

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.

[deleted]

Re: How an Engineering Company Chose to Migrate to D

#140

Post by AndrewSChapman » Wed, Jun 20, 2018, 10:05 PM UTC

aydwi wrote: post #78

AndrewSChapman wrote: post #48

I would love to be able to use D in my day job. It's a fantastic language that is both powerful and fun to work with. It's great to see companies embracing it.

What is your day job?

I work in a small team building APIs with PHP for the real estate industry. In my last job I did manage to use D for a "sequence mining" algorithm that looked for problematic behavioural patterns in web user behaviour. PHP would have been waaay too slow for the quantity of data that needed to be evaluated. That was honestly one of the most enjoyable things I've ever coded.

My hobby project languages or choice are currently D and Kotlin. I prefer the semantics and flexibility of D, but Kotlin has the backings of the tried and tested Java ecosystem, which is hard to beat when you just want to get down to it. Also web servers in Java are vastly superior at the moment. Vert.x is so very fast.