Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
On Tuesday, 26 April 2016 at 20:01:34 UTC, Andrei Alexandrescu wrote: Andrei Alexandrescu 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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
On Tuesday, 26 April 2016 at 20:01:34 UTC, Andrei Alexandrescu wrote: 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 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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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).
Re: So, to print or not to print?
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 > I closed the PR as too controversial. -- Andrei
Re: So, to print or not to print?
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"...
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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".
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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...
Re: So, to print or not to print?
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 ;-)
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.)
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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
Re: So, to print or not to print?
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.
So, to print or not to print?
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