Life is a stream?

[MikeP]

Programmers are enamoured with streams of bytes. Is that abstraction
(i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
alike, so why model it as if it is. What say you (y'all)?

Keywords and key phrases (why is "keyword" a compound word and "key
phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
unit/record/group separator, compromise, designed for all cases but good
for none (nothing),... other.

 

[BGB]

Programmers are enamoured with streams of bytes. Is that abstraction
(i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
alike, so why model it as if it is. What say you (y'all)?

Keywords and key phrases (why is "keyword" a compound word and "key
phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
unit/record/group separator, compromise, designed for all cases but good
for none (nothing),... other.

collections of bytes (globs/streams/arrays/...) are generally the most
generic bottom-level representation for data.

other data representations:
text, XML, arrays, structures, ... although often much more closely
related to the data in question, are nowhere near as general-purpose,
and so are ill suited as a "fundamental representation".

this then is why file-formats are often composed on a number of
"layers", each with various levels of abstraction, various magic
numbers, ...


also, it makes sense, as the world would be far more complex (and not
nearly so functional) if all of the file-systems, network HW, memory
storage, ... each had to deal with a wide range of possible data
representations. since they only see bytes, their job is generally easier.

probably about the only other likely "fundamental" model would be
abstract reference-based high-level data types... however... this model
itself has a notably different problem: it doesn't really map well to
traditional static-typed languages (such as C, C++, Java, ...). even
then, it doesn't matter much, since this other model (more commonly used
in languages like Lisp/Scheme/Erlang/...) still can be mapped fairly
effectively to plain old bytes.

so, seemingly, there is nothing really that doesn't map acceptably well
to bytes.

 

[Michael Doubez]

Programmers are enamoured with streams of bytes.

Yep. that's Ol' man river.

Is that abstraction
(i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
alike, so why model it as if it is. What say you (y'all)?

Are you talking about a model or the support for a model ?

However you interpret your data, it has eventually a beginning and a
end (out-of-bound data are stream in themselves) on a support which is
a represented as an ordered sequence of ones and zeros. The byte being
the smallest addressable unit.

Keywords and key phrases (why is "keyword" a compound word and "key
phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
unit/record/group separator, compromise, designed for all cases but good
for none (nothing),... other.

Those are models with context; you are not at the same level.

Could you elaborate ?

 

[Adam Skutt]

Programmers are enamoured with streams of bytes. Is that abstraction
(i.e., generality) too rigidly modeled?

Given that the only thing you can do with all streams in POSIX is
close them, I would say no. Programmers are enamoured with streams of
bytes as a reflection of the nature of the underlying hardware. When
streams don't work especially well, we don't use them.

I say, all IO (I/O?) is not
alike, so why model it as if it is. What say you (y'all)?

We never have and never will. I don't think you know what you're
talking about, all major operating systems that I can think of
support:
* Memory-mapped I/O (which is the dominant form of hardware I/O in
most modern computers), including shared memory support, like UNIX
mmap.
* Block-based I/O for block-oriented devices, though sometimes only at
the kernel level.
* Stream-based I/O for stream-oriented devices, like UNIX open/read/
write.
* Ancillary I/O for configuration and management of most hardware,
like UNIX ioctl.
* Special purpose I/O for directory and other special filesystem
structures.
* Some form of "reliable" message IPC, such as SysV message queues.

I could keep going, but I think I've made my point.

Keywords and key phrases (why is "keyword" a compound word and "key
phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
unit/record/group separator, compromise, designed for all cases but good
for none (nothing),... other.

It would help if you'd write actual complete sentences. If you don't
have the I/O interface you want, you usually can provide the I/O
interface you want by simply layering on top of the one you have.
This is why we don't have to write block-oriented code to access files
in a filesystem, which is a good thing.

Adam

 

[MikeP]

Yep. that's Ol' man river.


Are you talking about a model or the support for a model ?

Probably, but it is a secret.

However you interpret your data, it has eventually a beginning and a
end (out-of-bound data are stream in themselves) on a support which is
a represented as an ordered sequence of ones and zeros. The byte being
the smallest addressable unit.

Wouldn't I love to find you in "a court of law".

Those are models with context; you are not at the same level.

Could you elaborate ?

I could and have, but I won't.

 

[MikeP]

Having read a few comments and rummaged in the old memory...

Some mainframe systems have record based file systems, where the OS is
responsible for mapping the records onto the disc sectors. There's no
stream of bytes involved - a read will give you a record (which
admittedly is usually made of bytes!) direct from a sector, and there
is no byte-wide stream involved at all. This of course has
advantages if your data is wider than bytes, and the system bus is
too - there's never a need to perform the byte alignment.

It is just data though, Hmm?

 

[MikeP]

Yep. that's Ol' man river.


Are you talking about a model or the support for a model ?

Note that this is a C++ NG. I was alluding to C++ recognizing only
streams of bytes.

However you interpret your data, it has eventually a beginning and a
end (out-of-bound data are stream in themselves) on a support which is
a represented as an ordered sequence of ones and zeros. The byte being
the smallest addressable unit.


Those are models with context; you are not at the same level.

Could you elaborate ?

No, that part was just food for thought.

 

[MikeP]

Given that the only thing you can do with all streams in POSIX is
close them, I would say no. Programmers are enamoured with streams of
bytes as a reflection of the nature of the underlying hardware. When
streams don't work especially well, we don't use them.


We never have and never will. I don't think you know what you're
talking about, all major operating systems that I can think of
support:
* Memory-mapped I/O (which is the dominant form of hardware I/O in
most modern computers), including shared memory support, like UNIX
mmap.
* Block-based I/O for block-oriented devices, though sometimes only at
the kernel level.
* Stream-based I/O for stream-oriented devices, like UNIX open/read/
write.
* Ancillary I/O for configuration and management of most hardware,
like UNIX ioctl.
* Special purpose I/O for directory and other special filesystem
structures.
* Some form of "reliable" message IPC, such as SysV message queues.

I could keep going, but I think I've made my point.

Actually, you've made mine! (I knew someone would).

It would help if you'd write actual complete sentences.

The colon in the above is very key. It is not meant to be sentencial.

 

[MikeP]

Well, depends what you mean.

I'm not sure where I was going with that either.