[OT] Programming language WATs

[Jonathan M Davis]

On Monday, February 06, 2012 23:01:06 H. S. Teoh wrote:
> On Mon, Feb 06, 2012 at 10:02:15PM -0800, Jonathan M Davis wrote:
> > On Monday, February 06, 2012 21:49:23 H. S. Teoh wrote:
> [...]
> 
> > In my experience, most C++ programmers ignore streams for basic I/O,
> > if not in general. They're nice for some basic stuff and for object
> > oriented stuff, but as soon as you need formatting, they're a pain.
> > So, for the most part, printf gets used. I think that about the only
> > place that I see streams used much is binary streams which take
> > advantage of an object knowing how to write and read itself to and and
> > from a stream. But even that's rare in my experience. I'm sure that it
> > depends on the programmers though.
> 
> I don't see what's the discrepancy between formatting and streams. As
> far as I'm concerned, writeln() is essentially taking a bunch of
> objects, converting them to string representations, and writing said
> strings sequentially to some output channel (i.e., output stream).

In C++, you end up with stuff like

cout << "point: [" << x << ", " << y "]" << endl;

That's already much uglier than

printf("point: [%f, %f]\n", x, y);

But what if you want to do something like %02f? With printf, that's easy:

printf("point: [%02f, %02f]\n", x, y);

With streams, it's hideous. I'd have to go look it up to give you an example. 
It involves setting flags in the stream and the like, and it's horrible. In my 
experience, no one uses it.

> [...]
> 
> > You end up with pretty much the same thing in C# and Java. println and
> > its friends are what's used most frequently (though it works better in
> > D, C#, and Java than it does in C++, thanks to toString), though
> > streams do get used for some stuff - usually not text though. It
> > probably varies a bit from programmer to programmer though.
> 
> And println/writeln is essentially writing to an output stream. It can
> be a file, a socket, a pipe, whatever. The functionality of a stream is
> all that's needed to implement it.
> 
> > Regardless, I wouldn't really consider a file to be specific to either
> > the stdio approach or streams. If anything, I find it bizarre that
> > std.stream uses the term File for a stream. That seems to me to be
> > like making a container into a range or an iterator, which really
> > doesn't make sense. You have a range _over_ a container, not a
> > container which is a range. One of the reasons that dealing with
> > dynamic arrays in D can be so confusing is that they're ranges and
> > people think that they're containers (though they really aren't, since
> > they don't own their memory). Mixing the concept of file and stream
> > seems like a bad idea. But it's probably just a case of a poorly named
> > type.
>
> [snip]

The long term plan is to create a std.stream which then provides a range-based 
interface for streams. Then you can do with it whatever you can do with any 
input stream - though there's still a lot that you would lose out on, since it 
can't be a forward range. Exactly how that will interact with std.stdio, I 
don't know. That will depend on the API that's finally decided up.

Regardless, my point was that while it might make sense to have a stream over 
a file, it doesn't make sense for a stream to _be_ a file, any more than it 
makes sense for a container to _be_ a range. You have a range over the 
container. The container itself isn't a range. So, std.stream's File type is 
poorly named IMHO. But it's going away in the long run, so it ultimately 
doesn't really matter what it was named.

> > In any case, std.stream is rather old and outdated and will be
> > replaced at some point with a range-based API. And its replacement may
> > interact with std.stdio better.
> 
> [...]
> 
> Yikes! So I should just avoid using it altogether then? How come it's
> not marked deprecated?

Because it doesn't have a replacement yet. The replacement has been discussed 
on some level, but no one has fleshed it out and implemented it yet. Steven 
Schveighoffer's rewrite of std.stdio may start that ball rolling. I don't know. 
What it really needs is a champion to take on the effort of leading the 
discussion, implementing it, and pushing it through the review process. No one 
has really stepped up to do that yet.

It's like std.xml. You can use it, but it's not going to be around in the long 
term, and we don't have a replacement for it yet. We're just certain that the 
current version is unacceptable and needs to be replaced. It would probably be 
a good idea to put a warning of some kind in the documentation, but for the 
moment, it's not going away.

- Jonathan M Davis