On Saturday, 15 April 2017 at 20:45:23 UTC, Jonas Drewsen wrote:
On Saturday, 15 April 2017 at 20:20:49 UTC, Stanislav Blinov wrote:
On Saturday, 15 April 2017 at 20:12:41 UTC, cym13 wrote:
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:

This has been proposed before, and I still don't see the added value compared to:

    auto a=7;
    writeln(a, " times 3 is ", a*3);

besides adding compiler complexity, language complexity and parsing complexity which leaves room for more bugs to be invented. I'm a bit more harsh than I could be, but if this simple question has no clear answer I don't see why it sould make it into the language.

Try a different context:

auto a = 7;

import std.format;
auto str = format("%s times 3 is %s", a, a*3);

//or

import std.conv;
auto str = text(a, " times 3 is ", a*3);

//or

auto str = $"{a} times 3 is {a*3}";

Yes this is a very basic lowering. The value comes from the fact (assumption?) that this pattern of constructing a string from a mix of strings and expressions is very common. The value of a feature could be described as

usage * productivity_improvement = feature_value

So while the productivity_improvement may be modest the usage is high enough to give a high feature_value and justify the addition. A sign of this is the number of other popular languages supporting this feature (not arguing for just copy other languages but it is still an indicator). Unfortunately I have no hard data for these numbers.

There is a very big hole in your equation. It's more like:

feature_value = usage * productivity_improvement - (development_cost + maintainance cost)

also it's worth noting that the productivity improvement is weighed down by the time needed to learn the new way, to understand other people's code that use yet another way to do things, to sift through code to find bugs...

I'm not saying the end value isn't positive, maybe it is. I just don't see how right now.

Just an anecdote: I often do security code reviews, that's my thing. I work with a lot of languages in that context, and I hate having to audit perl or ruby code. It's not because they're bad languages, but there is just so many ways to build strings and so many ways to execute shell code that finding them all in the code to check them is a nightmare. In python on the contrary there is a small set of functions that you can use for subprocessing. Besides they are all functions so even if they're different the structure is alike. This makes it *so* much easier. I want to be able to find bugs easily. I want D to be like python on that part. Not perl. Not ruby.

Reply via email to