Re: So, to print or not to print?

2016-04-27 Thread tn via Digitalmars-d
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?

2016-04-27 Thread Shachar Shemesh via Digitalmars-d

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?

2016-04-26 Thread xenon325 via Digitalmars-d
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?

2016-04-26 Thread Solomon E via Digitalmars-d

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?

2016-04-26 Thread Jon D via Digitalmars-d

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?

2016-04-26 Thread Era Scarecrow via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d
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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread TheGag96 via Digitalmars-d

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?

2016-04-26 Thread Jonathan M Davis via Digitalmars-d
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?

2016-04-26 Thread Adam D. Ruppe via Digitalmars-d
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?

2016-04-26 Thread Seb via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread Meta via Digitalmars-d
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?

2016-04-26 Thread tn via Digitalmars-d
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?

2016-04-26 Thread cym13 via Digitalmars-d
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?

2016-04-26 Thread Adam D. Ruppe via Digitalmars-d
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?

2016-04-26 Thread cym13 via Digitalmars-d
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?

2016-04-26 Thread Adam D. Ruppe via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread Seb via Digitalmars-d

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?

2016-04-26 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-26 Thread Jonathan M Davis via Digitalmars-d
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?

2016-04-26 Thread cym13 via Digitalmars-d

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?

2016-04-26 Thread ixid via Digitalmars-d

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?

2016-04-26 Thread Era Scarecrow via Digitalmars-d

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?

2016-04-26 Thread ZombineDev via Digitalmars-d
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?

2016-04-25 Thread rikki cattermole via Digitalmars-d

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?

2016-04-25 Thread rikki cattermole via Digitalmars-d

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?

2016-04-25 Thread Jonathan M Davis via Digitalmars-d
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?

2016-04-25 Thread Jack Stouffer via Digitalmars-d
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?

2016-04-25 Thread Brad Roberts via Digitalmars-d
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?

2016-04-25 Thread Andrei Alexandrescu via Digitalmars-d

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?

2016-04-25 Thread cym13 via Digitalmars-d
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.