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? None of the other big languages, C, C++, Javascript, Java, C#, 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