www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - So, to print or not to print?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://github.com/dlang/phobos/pull/3971

Walter and I were talking this morning that there should be a high 
barrier of entry for one-liners in Phobos. The "print" function is 
technically a one-liner (i.e. writefln with the appropriate format 
string). On the other hand, it may be convivial enough to warrant 
inclusion, and saves us from embarrassing things such as producing 
meaningless output when numbers are printed together.

There's been a bit of churn in the PR comments regarding the utility of 
"print", and discussion diverged into other functions such as "dump" 
etc. Keeping it on topic: any strong cons and pros regarding the 
function? I want to either merge or close the PR and move on.


Thanks,

Andrei
Apr 25 2016
next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/3971

 Walter and I were talking this morning that there should be a 
 high barrier of entry for one-liners in Phobos. The "print" 
 function is technically a one-liner (i.e. writefln with the 
 appropriate format string). On the other hand, it may be 
 convivial enough to warrant inclusion, and saves us from 
 embarrassing things such as producing meaningless output when 
 numbers are printed together.

 There's been a bit of churn in the PR comments regarding the 
 utility of "print", and discussion diverged into other 
 functions such as "dump" etc. Keeping it on topic: any strong 
 cons and pros regarding the function? I want to either merge or 
 close the PR and move on.


 Thanks,

 Andrei


To be honnest I think it would add more confusion than anything 
for newcommers to have yet another printing function but the name 
is good and it is like python so it's easier for many.

I dislike some points of the API though, I think changing eol is 
more common than changing separator so I would rather have the 
two switched. Maybe even removed, replaced by a single switch 
"eol=true" as contrary to python we have more powerful formating 
functions at hand and I think restricting the domain of each 
function would prove better on the long run in order to keep 
consistency.

Also as the unittest shows it is hard to test a function that can 
only print to stdout which raises an orange flag in my mind: 
please, consider adding a way to supplant stdout. The best would 
be to make the unittest work:   file.print(i, i*i*i);  as it 
clearly comes from an natural expectation.
Apr 25 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/25/2016 04:18 PM, cym13 wrote:

 I dislike some points of the API though, I think changing eol is more
 common than changing separator so I would rather have the two switched.
 Maybe even removed, replaced by a single switch "eol=true" as contrary
 to python we have more powerful formating functions at hand and I think
 restricting the domain of each function would prove better on the long
 run in order to keep consistency.


I'd say it's a coin toss. There'd be as many arguments for one order as 
for the other.


 Also as the unittest shows it is hard to test a function that can only
 print to stdout which raises an orange flag in my mind: please, consider
 adding a way to supplant stdout. The best would be to make the unittest
 work:   file.print(i, i*i*i);  as it clearly comes from an natural
 expectation.


Good point to keep in mind, thanks.


Andrei
Apr 25 2016
prev sibling next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
Something that's been bouncing around in the back of my head for a while.  I
can't decide if it's a 
good idea or a really bad one.  Consider a series of small modules that are
essentially language 
mappers.  Something like:

    std.adapt.ruby
    std.adapt.python
    std.adapt.mumble

Each could contain little functions that map between idioms and names from the
various languages to 
the d native version.   There's no way that we can or should have all those
sorts of little helpers 
in the core library, but that doesn't mean that they shouldn't exist or
wouldn't be useful.

On 4/25/16 12:35 PM, Andrei Alexandrescu via Digitalmars-d wrote:

 https://github.com/dlang/phobos/pull/3971

 Walter and I were talking this morning that there should be a high barrier of
entry for one-liners
 in Phobos. The "print" function is technically a one-liner (i.e. writefln with
the appropriate
 format string). On the other hand, it may be convivial enough to warrant
inclusion, and saves us
 from embarrassing things such as producing meaningless output when numbers are
printed together.

 There's been a bit of churn in the PR comments regarding the utility of
"print", and discussion
 diverged into other functions such as "dump" etc. Keeping it on topic: any
strong cons and pros
 regarding the function? I want to either merge or close the PR and move on.


 Thanks,

 Andrei
Apr 25 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 26/04/2016 8:41 AM, Brad Roberts via Digitalmars-d wrote:

 Something that's been bouncing around in the back of my head for a
 while.  I can't decide if it's a good idea or a really bad one.
 Consider a series of small modules that are essentially language
 mappers.  Something like:

     std.adapt.ruby
     std.adapt.python
     std.adapt.mumble

 Each could contain little functions that map between idioms and names
 from the various languages to the d native version.   There's no way
 that we can or should have all those sorts of little helpers in the core
 library, but that doesn't mean that they shouldn't exist or wouldn't be
 useful.


I like this idea, it would help jump start people too.
Apr 25 2016
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 26 April 2016 at 04:54:33 UTC, rikki cattermole wrote:

 On 26/04/2016 8:41 AM, Brad Roberts via Digitalmars-d wrote:

 Something that's been bouncing around in the back of my head 
 for a while.  I can't decide if it's a good idea or a really 
 bad one. Consider a series of small modules that are 
 essentially language mappers.  Something like:

     std.adapt.ruby
     std.adapt.python
     std.adapt.mumble

 Each could contain little functions that map between idioms 
 and names from the various languages to the d native version.  
  There's no way that we can or should have all those sorts of 
 little helpers in the core library, but that doesn't mean that 
 they shouldn't exist or wouldn't be useful.


 I like this idea, it would help jump start people too.


  Hmmm interesting. I like and hate it at the same time. So maybe 
having a compile time warning that tells you what it's actually 
called and referring to, and recommending they use the proper 
functions. Maybe making them depreciated. Being familiar with 
another language is fine if it jumps you into D, but I don't want 
to start seeing odd Ruby code everywhere that doesn't make sense. 
On the other hand as a learning/easing tool it could be 
invaluable.

  Depreciated or warnings from the compiler wouldn't be bad, and 
even when compiled where warnings are errors, they would have the 
list straight up of a recommended function call and library to 
use instead.

  If they are merely aliased and nothing else, well I can't see 
the harm in that really, as long as they wean out of it 
eventually.
Apr 25 2016
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 26/04/16 07:54, rikki cattermole wrote:

 On 26/04/2016 8:41 AM, Brad Roberts via Digitalmars-d wrote:

 Something that's been bouncing around in the back of my head for a
 while.  I can't decide if it's a good idea or a really bad one.
 Consider a series of small modules that are essentially language
 mappers.  Something like:

     std.adapt.ruby
     std.adapt.python
     std.adapt.mumble

 Each could contain little functions that map between idioms and names
 from the various languages to the d native version.   There's no way
 that we can or should have all those sorts of little helpers in the core
 library, but that doesn't mean that they shouldn't exist or wouldn't be
 useful.


 I like this idea, it would help jump start people too.


I don't like it. It would fragment the language to the point where D 
experts are likely to look at code and not know what it means.

May I remind you that "there is more than one way to do it" is the motto 
for Perl, and we all know how that one turned out in the end.

Shachar
Apr 26 2016
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/3971


I really don't see the utility of the function over writefln 
being great enough to warrant inclusion. I'd vote not to include 
it.
Apr 25 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, April 26, 2016 01:44:07 Jack Stouffer via Digitalmars-d wrote:

 On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu

 wrote:

 https://github.com/dlang/phobos/pull/3971


 I really don't see the utility of the function over writefln
 being great enough to warrant inclusion. I'd vote not to include
 it.


I concur. IMHO, it doesn't add enough value to be worth it, and given that
it adds yet another printing function, it'll increase confusion with
newcomers.

- Jonathan M Davis
Apr 25 2016
parent reply ixid <adamsibson hotmail.com> writes:
On Tuesday, 26 April 2016 at 03:13:22 UTC, Jonathan M Davis wrote:

 On Tuesday, April 26, 2016 01:44:07 Jack Stouffer via 
 Digitalmars-d wrote:

 On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu

 wrote:

 https://github.com/dlang/phobos/pull/3971


 I really don't see the utility of the function over writefln 
 being great enough to warrant inclusion. I'd vote not to 
 include it.


 I concur. IMHO, it doesn't add enough value to be worth it, and 
 given that it adds yet another printing function, it'll 
 increase confusion with newcomers.

 - Jonathan M Davis


Please find an example of a newcomer who would be confused by 
print. This is an objectionable argument because none of the 
people making it are newcomers, you're using an entirely 
theoretical newcomer as your argument, and seem to think 
'print(a, b, c);' is going to confuse people more than 
'writefln("%s %s %s", a, b, c);' which is ridiculous.

Print function names are hardly pristine snow of simplicity that 
'print' is going to muddy. What do you think goes through a 
newcomer's mind when they see 'writefln'? For the vast majority 
it's almost certainly not 'write formatted line', it's 'write 
wagarble' and they'll forget wagarble next time they want to use 
it.

Print is incredibly simple and a low barrier to entry. When 
people need more complexity they can read up on other functions. 
You barely need to read anything to use print and you don't need 
to recheck the documents for using it the second time. Most users 
will find functions like writefln a bit nightmarish when they 
just want the program to do the most basic thing to interact with 
it in the first place. This has been further compounded by some 
of the alternative suggestions where people immediately suggest 
turning it into a template function etc.

Yes, you could sugar up everything and turn the language into an 
unmaintainable mess, it's a question of effort vs reward.

Barring main, printing something is likely the most commonly used 
function and this covers 90% of what people use it for in the 
simplest and easiest way. People fall into using languages 
because they're elegant, powerful and easy to use. Suddenly all 
the little code examples people will be exposed to are that much 
clearer and more elegant. The benefit is far greater than the 
cost.
Apr 26 2016
next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Tuesday, 26 April 2016 at 08:50:23 UTC, ixid wrote:

 On Tuesday, 26 April 2016 at 03:13:22 UTC, Jonathan M Davis 
 wrote:

 On Tuesday, April 26, 2016 01:44:07 Jack Stouffer via 
 Digitalmars-d wrote:

 On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu

 wrote:

 https://github.com/dlang/phobos/pull/3971


 I really don't see the utility of the function over writefln 
 being great enough to warrant inclusion. I'd vote not to 
 include it.


 I concur. IMHO, it doesn't add enough value to be worth it, 
 and given that it adds yet another printing function, it'll 
 increase confusion with newcomers.

 - Jonathan M Davis


 Please find an example of a newcomer who would be confused by 
 print. This is an objectionable argument because none of the 
 people making it are newcomers, you're using an entirely 
 theoretical newcomer as your argument, and seem to think 
 'print(a, b, c);' is going to confuse people more than 
 'writefln("%s %s %s", a, b, c);' which is ridiculous.

 Print function names are hardly pristine snow of simplicity 
 that 'print' is going to muddy. What do you think goes through 
 a newcomer's mind when they see 'writefln'? For the vast 
 majority it's almost certainly not 'write formatted line', it's 
 'write wagarble' and they'll forget wagarble next time they 
 want to use it.

 Print is incredibly simple and a low barrier to entry. When 
 people need more complexity they can read up on other 
 functions. You barely need to read anything to use print and 
 you don't need to recheck the documents for using it the second 
 time. Most users will find functions like writefln a bit 
 nightmarish when they just want the program to do the most 
 basic thing to interact with it in the first place. This has 
 been further compounded by some of the alternative suggestions 
 where people immediately suggest turning it into a template 
 function etc.

 Yes, you could sugar up everything and turn the language into 
 an unmaintainable mess, it's a question of effort vs reward.

 Barring main, printing something is likely the most commonly 
 used function and this covers 90% of what people use it for in 
 the simplest and easiest way. People fall into using languages 
 because they're elegant, powerful and easy to use. Suddenly all 
 the little code examples people will be exposed to are that 
 much clearer and more elegant. The benefit is far greater than 
 the cost.


It's not print itself that is likely to confuse a newcommer, you 
seem to forget that there is a whole programming language and 
ecosystem around it.

The first questions I expect are "when should I use print and 
when use writeln?" for they share a common role with common 
features.

The second thing is that it will only make it harder for them to 
read other's code: having one way (although not perfect) to do 
things helps maintaining coherence accross any codebase. 
Multiplication of functions to do the same things with only a 
slight change brings only disarray.

Finally it doesn't bring much. One learns writeln, laments a bit 
that it doesn't put spaces itself then just accepts it. I do 
think that easing the path of newcommers is important, I don't 
think print is a good way to do that. I'm all with J.M.D there.
Apr 26 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 26 April 2016 at 08:50:23 UTC, ixid wrote:

 Please find an example of a newcomer who would be confused by 
 print. This is an objectionable argument because none of the 
 people making it are newcomers, you're using an entirely 
 theoretical newcomer as your argument, and seem to think 
 'print(a, b, c);' is going to confuse people more than


I can out myself as a newcomer (since February) and a lot of 
stuff in D is pretty confusing. For example - a bit related - the 
separation between std.stdio and std.file. At least I expected 
that I can use `writeln` on files :/

There are already many other parts that require explanation, so 
please let stdio be a simple module.
Btw to prove the point that two names are bad, let me give you 
`AliasSeq` and `TypeTuple`.

On Tuesday, 26 April 2016 at 12:18:11 UTC, cym13 wrote:

 Finally it doesn't bring much. One learns writeln, laments a 
 bit that it doesn't put spaces itself then just accepts it. I 
 do think that easing the path of newcommers is important, 
 I don't think print is a good way to do that. I'm all with 
 J.M.D there.


I do agree with cym13, J.M.D, Jack Stouffer, rikki, klickverbot 
;-)


 Regardless, even having two printing functions requires that 
 programmers learn what the differences between them are. Each 
 one added to the mix is yet another one whose slight 
 differences has to be distinguished from the others. And we 
 already have 4 of them - write, writef, writeln, and writefln, 
 which is arguably too many. But at least they have a sensible 
 naming scheme that helps distinguish them. print, on the other 
 hand, has nothing in common with them and no indicators in its 
 name how it differs from the others.

 Honestly, I see no value whatsoever in print. writefln already 
 does the same job and in a clearer manner.


Or `writeln(chain(a, b, c).join(','))`.
However a compromise could be to allow writeln!`,`(a, b, c, d, 
e), but I guess for most of the cases `dump` is actually the 
function that the user wants to use.


 If it was available today, I would certainly use it for more
 convenient debugging, however the version I proposed [1]
 seems more useful to me.
 Should I make a PR?
 [1]: 
 https://github.com/dlang/phobos/pull/3971#issuecomment-208058229


As mentioned on github I would love to see a proper dump function 
and this would be quite useful for newcomers.
Apr 26 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 08:46 AM, Seb wrote:

 I can out myself as a newcomer (since February) and a lot of stuff in D
 is pretty confusing. For example - a bit related - the separation
 between std.stdio and std.file. At least I expected that I can use
 `writeln` on files :/


Thanks for your insight! Could someone insert an explanation at the top 
of both std.file and std.stdio, built from the following point:

Artifacts in std.stdio treat files as complex data repositories that are 
opened, read from and/or written to, and closed. Artifacts in std.file 
treat a file as a unit, much like shell programs do. With std.file 
read/write operations are done at the level of the entire file at once, 
and details of opening and closing are implicit.


 Honestly, I see no value whatsoever in print. writefln already does
 the same job and in a clearer manner.


 Or `writeln(chain(a, b, c).join(','))`.


That's just a terrible argument, sorry. The whole point here is to not 
necessitate introducing too many language and library artifacts in order 
to print something.


Andrei
Apr 26 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 26 April 2016 at 12:46:48 UTC, Seb wrote:

 the separation between std.stdio and std.file. At least I 
 expected that I can use `writeln` on files :/


You can...

auto file = File("name.txt", "wt");
file.writeln("hey");


 As mentioned on github I would love to see a proper dump 
 function and this would be quite useful for newcomers.


Yeah, dump has serious value, I'd support it.
Apr 26 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 08:18 AM, cym13 wrote:

 The first questions I expect are "when should I use print and when use
 writeln?" for they share a common role with common features.


"When you want spaces between arguments and when you don't".

We've been over this. Nobody asks when they should use writef over 
writeln or readf over readln (which also share a common role with common 
features). What precedent do you have of people getting confused like that?


Andrei
Apr 26 2016
next sibling parent cym13 <cpicard openmailbox.org> writes:
On Tuesday, 26 April 2016 at 12:52:13 UTC, Andrei Alexandrescu 
wrote:

 On 04/26/2016 08:18 AM, cym13 wrote:

 The first questions I expect are "when should I use print and 
 when use
 writeln?" for they share a common role with common features.


 "When you want spaces between arguments and when you don't".

 We've been over this. Nobody asks when they should use writef 
 over writeln or readf over readln (which also share a common 
 role with common features). What precedent do you have of 
 people getting confused like that?


 Andrei


Well, just the post above your own there's a case of someone who 
didn't expect the separation. I think it makes my point.
Apr 26 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 26 April 2016 at 12:52:13 UTC, Andrei Alexandrescu 
wrote:

 "When you want spaces between arguments and when you don't".


As I have said before, other languages have tried this kind of 
thing... and they aren't remembered well for it.

substr vs substring in javascript is the first big example. 
Similar name, subtle difference.
Apr 26 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 09:56 AM, Adam D. Ruppe wrote:

 On Tuesday, 26 April 2016 at 12:52:13 UTC, Andrei Alexandrescu wrote:

 "When you want spaces between arguments and when you don't".


 As I have said before, other languages have tried this kind of thing...
 and they aren't remembered well for it.

 substr vs substring in javascript is the first big example. Similar
 name, subtle difference.


Deja vu all over again. Where's the exchange where that argument got 
destroyed? -- Andrei
Apr 26 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 26 April 2016 at 15:55:54 UTC, Andrei Alexandrescu 
wrote:

 Deja vu all over again. Where's the exchange where that 
 argument got destroyed? -- Andrei


Your attempt at destruction bounced off the thick armor of my 
superior argument!

Here's your comment from the other thread:

https://github.com/dlang/phobos/pull/3971#issuecomment-183368836

"The way I see it is their charters are different, one is not 
better or worse than the other."

You can say exactly the same thing about substr and substring - 
their charters are different, one works by index and one by 
length! The question is: which one is which? Why is it print that 
adds spaces instead of write?

Why is print not to printf what write is to writef?


It is just too similar.

BTW ruby and php have print functions. Neither output spaces...
Apr 26 2016
prev sibling parent reply tn <no email.com> writes:
On Tuesday, 26 April 2016 at 12:52:13 UTC, Andrei Alexandrescu 
wrote:

 On 04/26/2016 08:18 AM, cym13 wrote:

 The first questions I expect are "when should I use print and 
 when use
 writeln?" for they share a common role with common features.


 "When you want spaces between arguments and when you don't".

 We've been over this. Nobody asks when they should use writef 
 over writeln or readf over readln (which also share a common 
 role with common features).


Maybe the name of the function should then be "writes" and/or 
"writesln" (instead of "print"), so that it can at least be found 
from the same place in the documentation as other related 
functions. The naming scheme would then also be consistent with 
the rest of the write/writef-family. (Here -s stands for 
"separated/spaced" just as -f stands for "formatted" etc.)
Apr 26 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Tuesday, 26 April 2016 at 14:33:42 UTC, tn wrote:

 On Tuesday, 26 April 2016 at 12:52:13 UTC, Andrei Alexandrescu 
 wrote:

 On 04/26/2016 08:18 AM, cym13 wrote:

 [...]


 "When you want spaces between arguments and when you don't".

 We've been over this. Nobody asks when they should use writef 
 over writeln or readf over readln (which also share a common 
 role with common features).


 Maybe the name of the function should then be "writes" and/or 
 "writesln" (instead of "print"), so that it can at least be 
 found from the same place in the documentation as other related 
 functions. The naming scheme would then also be consistent with 
 the rest of the write/writef-family. (Here -s stands for 
 "separated/spaced" just as -f stands for "formatted" etc.)


I like the `writes` idea!
Could be a good compromise ;-)
Apr 26 2016
prev sibling parent reply TheGag96 <thegag96 gmail.com> writes:
On Tuesday, 26 April 2016 at 14:33:42 UTC, tn wrote:

 Maybe the name of the function should then be "writes" and/or 
 "writesln" (instead of "print"), so that it can at least be 
 found from the same place in the documentation as other related 
 functions. The naming scheme would then also be consistent with 
 the rest of the write/writef-family. (Here -s stands for 
 "separated/spaced" just as -f stands for "formatted" etc.)


I really like this idea. Much better than just "print", and maybe 
even better than "dump".
Apr 26 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 02:29 PM, TheGag96 wrote:

 On Tuesday, 26 April 2016 at 14:33:42 UTC, tn wrote:

 Maybe the name of the function should then be "writes" and/or
 "writesln" (instead of "print"), so that it can at least be found from
 the same place in the documentation as other related functions. The
 naming scheme would then also be consistent with the rest of the
 write/writef-family. (Here -s stands for "separated/spaced" just as -f
 stands for "formatted" etc.)


 I really like this idea. Much better than just "print", and maybe even
 better than "dump".


Can't it be confused with a verb? -- Andrei
Apr 26 2016
next sibling parent TheGag96 <thegag96 gmail.com> writes:
On Tuesday, 26 April 2016 at 18:45:09 UTC, Andrei Alexandrescu 
wrote:

 Can't it be confused with a verb? -- Andrei


Maybe, though really I think most would find it odd to read a 
function name that isn't a name or actual command. If they were 
unfamiliar with it, they'd (hopefully) reparse it in their head 
with s being on its own.

...Then again, I did think "puts" from Ruby was pronounced like 
the word it spells for quite some time when I was younger until I 
realized it was an abbreviation for "put string"...
Apr 26 2016
prev sibling parent tn <no email.com> writes:
On Tuesday, 26 April 2016 at 18:45:09 UTC, Andrei Alexandrescu 
wrote:

 On 04/26/2016 02:29 PM, TheGag96 wrote:

 On Tuesday, 26 April 2016 at 14:33:42 UTC, tn wrote:

 Maybe the name of the function should then be "writes" and/or
 "writesln" (instead of "print"), so that it can at least be 
 found from
 the same place in the documentation as other related 
 functions. The
 naming scheme would then also be consistent with the rest of 
 the
 write/writef-family. (Here -s stands for "separated/spaced" 
 just as -f
 stands for "formatted" etc.)


 I really like this idea. Much better than just "print", and 
 maybe even
 better than "dump".


 Can't it be confused with a verb? -- Andrei


Maybe, but does it matter? I don't see any obvious but different 
meaning for it.

Another option is writed/writedln, where d stands for 
delimited/delimiter.

Of course, naming it after on "separated"/"delimited" kind of 
suggests, that you could give it a separator/delimiter string as 
a compile time or runtime parameter. Obviously, while being 
analogous to writef and more flexible, a runtime parameter would 
make the usage of the function more complicated in simple cases.
Apr 27 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, April 26, 2016 12:18:11 cym13 via Digitalmars-d wrote:

 Finally it doesn't bring much. One learns writeln, laments a bit
 that it doesn't put spaces itself then just accepts it.


I confess that I was very surprised to find out that writeln worked with
multiple arguments. I fully expected writeln to just print what you give it
followed by a newline, whereas writefln would take a format string and act
like printf except for how %s works with everything, and it adds a newline.
I never would have expected any kind of print function that would print
multiple arguments without a format string.

- Jonathan M Davis
Apr 26 2016
parent Jon D <jond noreply.com> writes:
On Tuesday, 26 April 2016 at 16:30:22 UTC, Jonathan M Davis wrote:

 On Tuesday, April 26, 2016 12:18:11 cym13 via Digitalmars-d 
 wrote:

 Finally it doesn't bring much. One learns writeln, laments a 
 bit that it doesn't put spaces itself then just accepts it.


 I confess that I was very surprised to find out that writeln 
 worked with multiple arguments.


In my initial look at D I would have appreciated print. However, 
at least part of the reason is that it was a while before I knew 
writefln existed. After finding it (and discovering that writeln 
takes multiple arguments), having the functionality of print was 
less an issue.

It's not easy to reconstruct why it took me a while to discover 
writefln, but perhaps finding places to show it off in 
introductory material would help others find it more quickly.

--Jon
Apr 26 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, April 26, 2016 08:50:23 ixid via Digitalmars-d wrote:

 On Tuesday, 26 April 2016 at 03:13:22 UTC, Jonathan M Davis wrote:

 On Tuesday, April 26, 2016 01:44:07 Jack Stouffer via

 Digitalmars-d wrote:

 On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu

 wrote:

 https://github.com/dlang/phobos/pull/3971


 I really don't see the utility of the function over writefln
 being great enough to warrant inclusion. I'd vote not to
 include it.


 I concur. IMHO, it doesn't add enough value to be worth it, and
 given that it adds yet another printing function, it'll
 increase confusion with newcomers.

 - Jonathan M Davis


 Please find an example of a newcomer who would be confused by
 print. This is an objectionable argument because none of the
 people making it are newcomers, you're using an entirely
 theoretical newcomer as your argument, and seem to think
 'print(a, b, c);' is going to confuse people more than
 'writefln("%s %s %s", a, b, c);' which is ridiculous.


Honestly, I think that writefln is way clearer than print. Certainly, if
you're familiar with printf, it's pretty obvious what writefln does with the
possible confusion over whether it prints a newline or not (and the ln in
the name is there to tell you that), whereas it's not at all obvious what
print is going to do without looking at the docs.

Regardless, even having two printing functions requires that programmers
learn what the differences between them are. Each one added to the mix is
yet another one whose slight differences has to be distinguished from the
others. And we already have 4 of them - write, writef, writeln, and
writefln, which is arguably too many. But at least they have a sensible
naming scheme that helps distinguish them. print, on the other hand, has
nothing in common with them and no indicators in its name how it differs
from the others.

Honestly, I see no value whatsoever in print. writefln already does the same
job and in a clearer manner.

- Jonathan M Davis
Apr 26 2016
parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 26 April 2016 at 12:38:06 UTC, Jonathan M Davis wrote:

 On Tuesday, April 26, 2016 08:50:23 ixid via Digitalmars-d 
 wrote:


and seem to think

 'print(a, b, c);' is going to confuse people more than 
 'writefln("%s %s %s", a, b, c);' which is ridiculous.


 Honestly, I think that writefln is way clearer than print. 
 Certainly, if you're familiar with printf, it's pretty obvious 
 what writefln does with the possible confusion over whether it 
 prints a newline or not (and the ln in the name is there to 
 tell you that), whereas it's not at all obvious what print is 
 going to do without looking at the docs.


  We could always use C++ streams! They are perfectly clear what 
they're doing, right?

  stdout << a << " " << b << " " << c << endl;

  Seriously, a formatting line may only be confusing at first, but 
it's something you need to learn at some point. I don't ever want 
to rely on something as ugly as streams. C had printf; which was 
print, with an f! and that was good enough for everything! (I 
feel like I'm quoting Garfield now)

  Not that long ago when I was getting into D, I used printf more, 
then when I memorized writeln I used it a lot more. It's really 
not that bad. More people should sit down and read the damn 
documentation (mind you I've read about half of it, and I need to 
start over now since it's been so long).
Apr 26 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 04:50 AM, ixid wrote:

 Please find an example of a newcomer who would be confused by print.
 This is an objectionable argument because none of the people making it
 are newcomers, you're using an entirely theoretical newcomer as your
 argument, and seem to think 'print(a, b, c);' is going to confuse people
 more than 'writefln("%s %s %s", a, b, c);' which is ridiculous.


Let me also add that the very request came from a former newcomer. -- Andrei
Apr 26 2016
parent reply cym13 <cpicard openmailbox.org> writes:
On Tuesday, 26 April 2016 at 12:46:09 UTC, Andrei Alexandrescu 
wrote:

 On 04/26/2016 04:50 AM, ixid wrote:

 Please find an example of a newcomer who would be confused by 
 print.
 This is an objectionable argument because none of the people 
 making it
 are newcomers, you're using an entirely theoretical newcomer 
 as your
 argument, and seem to think 'print(a, b, c);' is going to 
 confuse people
 more than 'writefln("%s %s %s", a, b, c);' which is ridiculous.


 Let me also add that the very request came from a former 
 newcomer. -- Andrei


Well except maybe for you and Walter I think we're all former 
newcomers.
Apr 26 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/26/2016 09:50 AM, cym13 wrote:

 On Tuesday, 26 April 2016 at 12:46:09 UTC, Andrei Alexandrescu wrote:

 On 04/26/2016 04:50 AM, ixid wrote:

 Please find an example of a newcomer who would be confused by print.
 This is an objectionable argument because none of the people making it
 are newcomers, you're using an entirely theoretical newcomer as your
 argument, and seem to think 'print(a, b, c);' is going to confuse people
 more than 'writefln("%s %s %s", a, b, c);' which is ridiculous.


 Let me also add that the very request came from a former newcomer. --
 Andrei


 Well except maybe for you and Walter I think we're all former newcomers.


Good point but you know I mean "recently former" :o). -- Andrei
Apr 26 2016
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/04/2016 1:44 PM, Jack Stouffer wrote:

 On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/3971


 I really don't see the utility of the function over writefln being great
 enough to warrant inclusion. I'd vote not to include it.


+1
Apr 25 2016
prev sibling next sibling parent ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/3971

 Walter and I were talking this morning that there should be a 
 high barrier of entry for one-liners in Phobos. The "print" 
 function is technically a one-liner (i.e. writefln with the 
 appropriate format string). On the other hand, it may be 
 convivial enough to warrant inclusion, and saves us from 
 embarrassing things such as producing meaningless output when 
 numbers are printed together.

 There's been a bit of churn in the PR comments regarding the 
 utility of "print", and discussion diverged into other 
 functions such as "dump" etc. Keeping it on topic: any strong 
 cons and pros regarding the function? I want to either merge or 
 close the PR and move on.


 Thanks,

 Andrei


If it was available today, I would certainly use it for more 
convenient debugging, however the version I proposed [1] seems 
more useful to me.
Should I make a PR?

[1]: 
https://github.com/dlang/phobos/pull/3971#issuecomment-208058229
Apr 25 2016
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/3971

 Walter and I were talking this morning that there should be a 
 high barrier of entry for one-liners in Phobos. The "print" 
 function is technically a one-liner (i.e. writefln with the 
 appropriate format string). On the other hand, it may be 
 convivial enough to warrant inclusion, and saves us from 
 embarrassing things such as producing meaningless output when 
 numbers are printed together.

 There's been a bit of churn in the PR comments regarding the 
 utility of "print", and discussion diverged into other 
 functions such as "dump" etc. Keeping it on topic: any strong 
 cons and pros regarding the function? I want to either merge or 
 close the PR and move on.


 Thanks,

 Andrei


Python users are only a subset of new users coming to D, and as 
far as I know it is the only big language where such a `print` 
primitive exists with the semantics of putting spaces between 
each item printed. Ruby also has `print` but it does not put 
spaces between arguments; it adds a newline after each argument. 
So which behaviour should we copy?


Scala, Groovy, et al., have a `print` function that matches the 
semantics of Python's print (nor Ruby's). Why add yet another IO 
function that will only help very inexperienced beginners coming 
from a single (popular, granted) language? I'm all for making the 
D experience easy for beginners, but this is not a low-hanging 
fruit. It's just rotten.
Apr 26 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 https://github.com/dlang/phobos/pull/3971
 
 Walter and I were talking this morning that there should be a high 
 barrier of entry for one-liners in Phobos. The "print" function is 
 technically a one-liner (i.e. writefln with the appropriate format 
 string). On the other hand, it may be convivial enough to warrant 
 inclusion, and saves us from embarrassing things such as producing 
 meaningless output when numbers are printed together.
 
 There's been a bit of churn in the PR comments regarding the utility of 
 "print", and discussion diverged into other functions such as "dump" 
 etc. Keeping it on topic: any strong cons and pros regarding the 
 function? I want to either merge or close the PR and move on.
 
 
 Thanks,
 
 Andrei
 


I closed the PR as too controversial. -- Andrei
Apr 26 2016
next sibling parent reply Solomon E <default avatar.org> writes:
On Tuesday, 26 April 2016 at 20:01:34 UTC, Andrei Alexandrescu 
wrote:

 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 https://github.com/dlang/phobos/pull/3971
 
 Walter and I were talking this morning that there should be a 
 high barrier of entry for one-liners in Phobos. The "print" 
 function is technically a one-liner (i.e. writefln with the 
 appropriate format string). On the other hand, it may be 
 convivial enough to warrant inclusion, and saves us from 
 embarrassing things such as producing meaningless output when 
 numbers are printed together.
 
 There's been a bit of churn in the PR comments regarding the 
 utility of "print", and discussion diverged into other 
 functions such as "dump" etc. Keeping it on topic: any strong 
 cons and pros regarding the function? I want to either merge 
 or close the PR and move on.
 
 
 Thanks,
 
 Andrei
 


 I closed the PR as too controversial. -- Andrei


I thought maybe std.adapt.Python.print would be a neat compromise 
(if there are Pythonistas who want to maintain that library 
module.) When I use Python, I often define my own output 
function, now with some influence from D on the behavior and 
naming it write. I've also defined convenience output functions 
named "print" in D, while I'm learning it. That's an argument 
against having Python style "print" except in a special 
adapt.Python module.

Then I was overwhelmed by how good the suggestion from tn was to 
have "writes" and "writesln" in D's set of "write" functions.

writesln(a, b); // I would expect does the same as
writefln("%s %s", a, b);

alias print = writesln!(separator="\t");
print(a, b); // now with tab separation

Comma for tab separation was a syntax built-in of 1964 BASIC, 
which was the most limited practical student programming language 
possible. I've implemented an interpreter of it in Python. It 
would be cool if it were easy for D beginners to write anything 
that could be written in 1964 BASIC.

As for "writes" looking like it might be a present tense verb or 
a plural noun: That's part of the beauty of it. It looks 
ambiguous and casual, like "puts" in Ruby, which helped and in no 
way hurt Ruby adoption, because superficially looking casual 
while actually having precise definitions behind the keywords is 
part of what makes scripting language style writing fun, and easy 
to write with imagination for many uses (rather than the language 
seeming to impose on the subject of the program.)

About one-liners in Phobos: If those one-liners help rewrite 
other features as one-liners, until everything is one-liners, 
bring on the monogram apocalypse.
Apr 26 2016
parent Solomon E <default avatar.org> writes:
On Tuesday, 26 April 2016 at 21:11:22 UTC, Solomon E wrote:

 ...
 writesln(a, b); // I would expect does the same as
 writefln("%s %s", a, b);

 alias print = writesln!(separator="\t");
 print(a, b); // now with tab separation

 ...


Sorry about using a named template argument when that isn't a 
thing apparently.

writesln!"\t"("A", "B"); // tab separation

void print(string separator = "\t", string eol = "\n", S...)(auto 
ref S args)
{
     writesln!(separator, eol, S)(args);
}
print("A", "B"); // now with tab separation

Those lines successfully run, and I don't know how to define a 
custom "print" shorter yet.
Apr 26 2016
prev sibling parent reply xenon325 <anm programmer.net> writes:
On Tuesday, 26 April 2016 at 20:01:34 UTC, Andrei Alexandrescu 
wrote:

 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 https://github.com/dlang/phobos/pull/3971


 I closed the PR as too controversial. -- Andrei


I guess it's too late, but from what I gathered from the 
comments, main controversy is about the name but not the utility 
(e.g. Adam's `substr` vs `substring` argument).

`printDelimited` and/or `printDelimitedLn`. Done.

Maybe I'm too spoiled by IDEs, but I really think we should not 
optimize for short names in std library. My (PHP and Java) IDE 
would suggest `printDelimited` after typing "prd" or even "pd".

I write such helper in every project and having it in phobos 
would be nice.

(P.S. these naming and other bikeshedding debates are pretty 
depressing in this otherwise great community)

-Alexander
Apr 26 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 27 April 2016 at 04:48:30 UTC, xenon325 wrote:

 I guess it's too late, but from what I gathered from the 
 comments, main controversy is about the name but not the 
 utility (e.g. Adam's `substr` vs `substring` argument).


I don't think it has enough utility to be added at all, if it is 
defined as printing with spaces.

If it is defined as printing to be human readable, then I'd take 
it, even if the first iteration uses spaces. Then we can expand 
it to do stuff like pretty-print objects.
Apr 27 2016