On Wednesday, 10 February 2016 at 19:30:26 UTC, Andrei Alexandrescu wrote:
> On 02/10/2016 01:51 PM, w0rp wrote:
>> I wonder if the addition of another function for printing will confuse
>> some new users.
>
> In my experience:
>
> * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++)
>
> * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++)
>
> * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector<bool> vs vector_bool in C++)
>
> * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap").
>
> So I think we're safe.
>
> Andrei

Yeah, that makes sense. Fair enough.

On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
>>> I see no non-trivial cost.
>>
>> I, to, am not getting the cost story. H.S. Teoh, could you please
>> substantiate? -- Andrei
>
> Sorry, I meant technical debt.  My point was that this function needs to
> provide more value than what's effectively just an alias for
> writefln("%s, %s, %s", x, y, z).
>

Having used an equivalent to the proposed "dump" for many years (and an inferior equivalent at that), I can attest that it definitely provides sufficient value over write* functions. With write*, there's always either excess verbosity that just gets in the way of my "flow", or I can opt the succinct route and wind up looking at a dump of numbers finding it difficult to know what number is what variable. Any homemade wrapper/alias only creates even MORE work when trying to use it. Anyone may be skeptical of the reasons, but it doesn't matter because again, this is all direct personal experience, not hypothetical theorizing.

In short: Yes. Yes it does provide sufficient value. And the "technical debt" is still vastly less than the time, effort and bother of having to defend yet another clear improvement on the D perpetual debate forums.

On Thu, Feb 11, 2016 at 09:55:49AM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> >>On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> >>>I see no non-trivial cost.
> >>
> >>I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
> >
> >Sorry, I meant technical debt.  My point was that this function needs to provide more value than what's effectively just an alias for writefln("%s, %s, %s", x, y, z).
> >
> 
> Having used an equivalent to the proposed "dump" for many years (and an inferior equivalent at that), I can attest that it definitely provides sufficient value over write* functions. With write*, there's always either excess verbosity that just gets in the way of my "flow", or I can opt the succinct route and wind up looking at a dump of numbers finding it difficult to know what number is what variable. Any homemade wrapper/alias only creates even MORE work when trying to use it. Anyone may be skeptical of the reasons, but it doesn't matter because again, this is all direct personal experience, not hypothetical theorizing.
> 
> In short: Yes. Yes it does provide sufficient value. And the "technical debt" is still vastly less than the time, effort and bother of having to defend yet another clear improvement on the D perpetual debate forums.

Fair enough.

Personally, though, I find a bunch of comma-separated values very unhelpful. It would be much better if they were labelled, e.g., if:

	int x, y, z;
	dump(x,y,z);

outputs:

	x=1, y=2, z=3

it would be much better than just:

	1, 2, 3

which is unclear which values belongs to which variable. Trivial to figure out in this case, but it's not as obvious when interspersed between other program output & debug messages. But maybe that's just a matter of habit, and difference in personal debugging style.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
> Personally, though, I find a bunch of comma-separated values very
> unhelpful. It would be much better if they were labelled

So wasn't this dump() as opposed to print()? Two different functions doing different things. -- Andrei

On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
>
> Fair enough.
>
> Personally, though, I find a bunch of comma-separated values very
> unhelpful. It would be much better if they were labelled, e.g., if:
>
> 	int x, y, z;
> 	dump(x,y,z);
>
> outputs:
>
> 	x=1, y=2, z=3
>
> it would be much better than just:
>
> 	1, 2, 3
>
> which is unclear which values belongs to which variable. Trivial to
> figure out in this case, but it's not as obvious when interspersed
> between other program output & debug messages. But maybe that's just a
> matter of habit, and difference in personal debugging style.
>

My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?

On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
> >
> >Fair enough.
> >
> >Personally, though, I find a bunch of comma-separated values very unhelpful. It would be much better if they were labelled, e.g., if:
> >
> >	int x, y, z;
> >	dump(x,y,z);
> >
> >outputs:
> >
> >	x=1, y=2, z=3
> >
> >it would be much better than just:
> >
> >	1, 2, 3
> >
> >which is unclear which values belongs to which variable. Trivial to figure out in this case, but it's not as obvious when interspersed between other program output & debug messages. But maybe that's just a matter of habit, and difference in personal debugging style.
> >
> 
> My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?

IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.)


T

-- 
In order to understand recursion you must first understand recursion.

On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote:
> On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d wrote:
>> On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
>> >[...]
>> 
>> My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
>
> IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.)
>
>
> T

yeah, dump is really useful, print is a bit marginal.

On 02/11/2016 04:44 PM, John Colvin wrote:
> On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote:
>> On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via
>> Digitalmars-d wrote:
>>> On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
>>> >[...]
>>>
>>> My understanding is that's the whole point of the "dump" function
>>> being discussed. Unless I misunderstood?
>>
>> IMO `dump` is worthwhile but `print` seems little more than an alias
>> for `writefln`. I can't find enough justification to warrant `print`.
>> (Next thing you know, newbies will be asking why there's both `print`
>> and `write` that do the same thing except different.)
>>
>>
>> T
>
> yeah, dump is really useful, print is a bit marginal.

Ahh, I missed the "print" stuff. I do agree it's not as useful as "dump", plus the name seems to suggest a connection with printf, which strikes me as confusing.

I do think the "print" function discussed (ie, like writeln, but auto-inserts spaces between the args) is occasionally nice for script-like programs. In fact, I think I have a function like that in Scriptlike specifically because of that...unless it's back in my older utility library instead...

I'd be perfectly happy to have it, particularly if it had a less confusing name, but can definitely see it being debatable whether it really is Phobos-worthy.

On Friday, 12 February 2016 at 03:18:47 UTC, Nick Sabalausky wrote:
> I'd be perfectly happy to have it, particularly if it had a less confusing name, but can definitely see it being debatable whether it really is Phobos-worthy.

Andrei has previously expressed a desire for a big standard library and it is a very good introduction to the language for newbies to be able to use print. It's simple and does what they expect, writefln("%s %s %s %s", a, b, c, d) is anything but simple and contains multiple pitfalls for a new user. This is likely the second most commonly used function (or thing someone wants a function to do) after main.

Why is the resistance to convenience functions so high in this community? If you want people to use D it will need to be both powerful and feel light and easy to use. It would seem to be better for D to allow convenience functions in Phobos more broadly where the use case is common.

There are already many print and write functions, it's not a thing that has only one way to do it that will be greatly muddied by the addition of another function, can you cite threads from other languages where people are confused by a function called print that prints?

On 2/11/16 4:38 PM, H. S. Teoh via Digitalmars-d wrote:
> (Next
> thing you know, newbies will be asking why there's both `print` and
> `write` that do the same thing except different.)

That sounds unlikely to me. What would be a few examples/precedents? -- Andrei