Thread overview
Expanding tool (written in D) use, want advice
Jun 22, 2018
Jesse Phillips
Jun 24, 2018
Bastiaan Veelo
Jun 24, 2018
aliak
Jun 25, 2018
Vijay Nayar
June 22, 2018
So I have a tool chain developed utilizing D. It is kind of like a Linter for what my company does. I started its development back in 2009 as a POC for why the company should pursue such a concept. That didn't work and I've been utilizing and had a few people pick it up and gain value from it.

Recently there is a vitalized effort to look at how we can test better, so once again I'm advocating for this Lint like concept and of course utilizing my experience with this tool I have used over the years.

But it is written in D and we don't have any D developers, we have C# (and other language) developers. So clearing the tension is that it should be rewritten into C# (if I can convince them that linting is beneficial, which I actually don't think would be a need if it was already in C#).

My argument is going to mainly center around utilizing what exists. Once we have more use and a greater need to make modifications, we can look at a C# migration but we shouldn't start there.

Should I be looking more at the benefits of having D as a tool? It was a good choice for me since I know D so well (and other reasons at the time), but C# is a reasonable language in this space. I'm thinking, like should I go into how learning D wouldn't be too hard for new hire since it has similar syntax to C# and so on.
June 24, 2018
On Friday, 22 June 2018 at 14:45:46 UTC, Jesse Phillips wrote:
> So I have a tool chain developed utilizing D. It is kind of like a Linter for what my company does. I started its development back in 2009 as a POC for why the company should pursue such a concept. That didn't work and I've been utilizing and had a few people pick it up and gain value from it.
>
> Recently there is a vitalized effort to look at how we can test better, so once again I'm advocating for this Lint like concept and of course utilizing my experience with this tool I have used over the years.
>
> But it is written in D and we don't have any D developers, we have C# (and other language) developers. So clearing the tension is that it should be rewritten into C# (if I can convince them that linting is beneficial, which I actually don't think would be a need if it was already in C#).
>
> My argument is going to mainly center around utilizing what exists. Once we have more use and a greater need to make modifications, we can look at a C# migration but we shouldn't start there.
>
> Should I be looking more at the benefits of having D as a tool? It was a good choice for me since I know D so well (and other reasons at the time), but C# is a reasonable language in this space. I'm thinking, like should I go into how learning D wouldn't be too hard for new hire since it has similar syntax to C# and so on.

My $00.02: ideally, your D code should be so easy to read and well documented that any of your C# colleagues can see what’s going on and learn D from it, by example. If you need to convince decision makers, you may want to polish up a subset as a showcase. Make the tools so good that the benefits of using them are obvious.

Good luck!

Bastiaan.

June 24, 2018
On Friday, 22 June 2018 at 14:45:46 UTC, Jesse Phillips wrote:
> So I have a tool chain developed utilizing D. It is kind of like a Linter for what my company does. I started its development back in 2009 as a POC for why the company should pursue such a concept. That didn't work and I've been utilizing and had a few people pick it up and gain value from it.
>
> Recently there is a vitalized effort to look at how we can test better, so once again I'm advocating for this Lint like concept and of course utilizing my experience with this tool I have used over the years.
>
> But it is written in D and we don't have any D developers, we have C# (and other language) developers. So clearing the tension is that it should be rewritten into C# (if I can convince them that linting is beneficial, which I actually don't think would be a need if it was already in C#).
>
> My argument is going to mainly center around utilizing what exists. Once we have more use and a greater need to make modifications, we can look at a C# migration but we shouldn't start there.
>
> Should I be looking more at the benefits of having D as a tool? It was a good choice for me since I know D so well (and other reasons at the time), but C# is a reasonable language in this space. I'm thinking, like should I go into how learning D wouldn't be too hard for new hire since it has similar syntax to C# and so on.

Biggest resistance I usually get is around tooling and library availability - which is not something I can argue for in the face of other languages. So if that comes up, I'd be interested to know how that went.

Also, "may D force be with you" (has no one made a t-shirt from that yet, it's so bad it's good!) :p

Cheers,
- Ali


June 25, 2018
On Friday, 22 June 2018 at 14:45:46 UTC, Jesse Phillips wrote:
> Should I be looking more at the benefits of having D as a tool? It was a good choice for me since I know D so well (and other reasons at the time), but C# is a reasonable language in this space. I'm thinking, like should I go into how learning D wouldn't be too hard for new hire since it has similar syntax to C# and so on.

One strong argument to make is based on performance. Give them numbers about how fast your tool runs and make it efficient. The idea is that because the linting tool will be run for every incremental build a developer makes, slower running times are a barrier to productivity.

But once performance targets are defined, and if the company thinks that C# can also meet those targets, then really it's their call. Ultimately it is their company and their assets.

In such a case, I would generalize your tool for use outside of the specific context of your company, and make it the basis of an open source project.