[OT] Programming language WATs

[H. S. Teoh]

On Mon, Feb 06, 2012 at 05:18:14PM -0800, Jonathan M Davis wrote:
> On Monday, February 06, 2012 17:13:28 H. S. Teoh wrote:
> > OK, so this thread was supposed to be about WATs in D. Today I found
> > one.
> > 
> > 	std.stdio.File != std.stream.File
> > 
> > which means you can't assign stdin to InputStream.
> > 
> > Yes I know, you need to import cstream and use cstream.din instead,
> > but this is very counterintuitive to a newcomer. It certainly
> > elicited a WAT from me today when I first ran into this
> > schizophrenic split between std.stdio (which is pretty much used in
> > every D code example I've seen, which gives the impression that it's
> > the "native" and "default" thing to use) and std.stream (which one
> > would expect should naturally extend the functionality of std.stdio,
> > but it doesn't).
> 
> I guess that it depends on how you think or what you're used to. I
> wouldn't necessarily expect std.stream to be related to std.stdio at
> all. Certainly. in C++, stream-based and non-stream-based I/O isn't
> related at all (or if it is, it's an implementation detail). So, my
> general expectation is that they're completely separate, though I
> suppose that they don't _have_ to be designed that way.

The thing is, coming from a Linux background, I've become accustomed to
the "everything is a file" concept, which entails "file == stream". So I
found it very strange to discover that this is not true in D, at least
as far as std.stdio is concerned.


> Given that std.stream has its own File type, that would make it pretty
> obvious that the File from std.stdio would not work with std.stream.
> But I guess that you could see a function taking File in std.stream
> without having read enough of std.stream's documentation to realize
> that it had its own File type.
[...]

I certainly did not realize this, since the docs refer to "File" rather
than "std.stream.File" or "std.stdio.File" explicitly.

But even after I realized there were two different File types, it took
me yet another while to figure out how to bridge them with std.cstream.
This is one of those things that *really* needs good docs for newbies,
because it's a point of confusion to the uninitiated that needs to be
explained.

On another note, I find this divide between std.stream and std.stdio
quite jarring. The C++ model is to use <iostream> by default, and
optionally provide <cstdio> to those who prefer it. This, I find, makes
sense, because streams are a much more powerful concept that subsumes
the concept of a file, and having it as default makes sense. Having
<cstdio> as an option is merely a concession for C programmers who
migrated to C++ (and I'm one of them who still hold on to cstdio over
iostream) -- so it's understandable that the two cannot be freely
intermixed.

In D, however, I did not expect this stream/stdio divide to exist,
though I suppose the name "std.stdio" is a kind of giveaway. In any
case, std.stdio is used all over the place in D docs and tutorials,
besides write/writeln() being a pet example motivating variadic
templates, so it seems to hold the equivalent place to <iostream> in
C++. As such, I found it strange that this divide between streams and
stdio files still persists in D. I would have thought that D should have
integrated the two seamlessly into a single subsystem (or otherwise
redesigned it in a more logical fashion), rather than perpetuating the
schizophrenic divide inherited from C/C++.


T

-- 
Маленькие детки - маленькие бедки.