Ah, yes: weaponizing cybersecurity requirements to trick - I mean “motivate” - higher management to do things “right.”

My thought as well, but those stones were shaped to match each other, reducing the amount of grout needed. It just goes to show the old ways still work, but you have to commit.

This is a dangerous metaphor. Remove the old wall and it turns out the new beautiful wall was leaning against and supported by it.

I get what you mean, it’s just that the metaphor could support both perspectives.

Surely through an intermediate - real - language?

I’ve said this before only to hear “we don’t have time to set that up and agree on a common style” and “that’s team B’s responsibility since we’re contributing to their code base.” Guess what kind of issue we kept wasting time on?

There are a couple of takeaways here. I think the main one is acknowledging that many technical problems are deeply human problems and the existence of a technical solution doesn’t mean we shouldn’t apply the human solution as well.

Like if the variable is then used in a function that only takes one type? Huh.

And bow to the compiler’s whims? I think not!

This shouldn’t compile, because .into needs the type from the left side and let needs the type from the right side.

I came here to laugh, not to cry!

[clicks light switch off and on repeatedly]

Welp, I guess we’re closed for the week.

I’d say I feel seen, but it’s really dark in here.

let a = String::from(“Hello, world!”).into()

I’ll see myself out.

Common criticisms here would be that these endeavors stifle creativity and show the adoption of modern solutions. That said, I find conducting “code archeology” to figure out the idiomatic way of doing something in an old project very rewarding. Because computer programs exist in people’s mind’s, doing that with the support of original developers or subject matter experts is some of the most effective knowledge transfer I’ve ever witnessed.