Live data from Hacker News

How an Engineering Company Chose to Migrate to D

dlang.org

31–40 of 170 posts

Re: How an Engineering Company Chose to Migrate to D

#31

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?

Why would you need to? If you unit test the top level function then you're implicitly testing anything it does, e.g., use of the local function.

Re: How an Engineering Company Chose to Migrate to D

#32

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 hole to get themselves out.

Re: How an Engineering Company Chose to Migrate to D

#34
This article seems to ignore two of the most important reasons to choose one language over another. Specifically:

1)Expressiveness in the given problem domain. Some languages are really great in particular niches.

2)Availability of devs. The ability to hire and retain a really great team makes or breaks projects, and while a smart, motivated dev can learn any language, it's definitely a factor in their choice to work or not work with you. If you're in a niche language it will greatly affect the ability of people to use external resources (stackoverflow etc) if they hit blockers and some people will be reluctant to railroad their career into a tech that doesn't appear to be going to the mainstream. On the flipside, if you're lucky you may be able to get really passionate devotees of the language to work for you just to use the language where they might not have done it otherwise.

Re: How an Engineering Company Chose to Migrate to D

#35
I would have ported the application to Free Pascal 15 years ago when their Extended Pascal compiler vendor went out of business. That's a long time to wait! :)

I'm curious what manual translation and rewriting would be necessary when moving to Free Pascal compared to their Pascal2D transpiler and compatibility library.

Re: How an Engineering Company Chose to Migrate to D

#36
post #23

Earlier quoted context omitted.

Go also certainly supports this. Here's a playground example: https://play.golang.org/p/_BLguocGBRn

Does Go take a copy or a reference?

The following example will provide your answer:

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

Re: How an Engineering Company Chose to Migrate to D

#37

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 frame variables). But you asked :)

Re: How an Engineering Company Chose to Migrate to D

#38

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.

Re: How an Engineering Company Chose to Migrate to D

#39

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…

Well Microsoft deemed they are still relevant enough to add them to C# 7.

Re: How an Engineering Company Chose to Migrate to D

#40

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…

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

Now you understand how all of these "How we chose this language" writeups work.

Post reply on HN