🚀 go-pugleaf

In article <BLUME.95Sep18161301@dynastar.cs.princeton.edu>, blume@dynastar.cs.princeton.edu (Matthias Blume) writes:
>
> Aside from that I still disagree with you:  a programming language
> should not specify low-level things like memory layout in its
> definition.  Most of the time you don't need that kind of knowledge,
> it becomes a pain in the neck when switching to modern architectures,
> it prohibits certain kinds of optimizations, and it is generally not
> very useful EXCEPT for the dubious abuse of data types as templates
> for persistent structures in the file system.
>
Agreed, 'a programming language should not specify low-level things like
memory layout in its definition.' But it should be a tool to allow ME
to do that type of thing.

I am one of the users of files whose origin is 'the dubious abuse of
data types as templates for persistant structures in the file system.'
Unfortunately, those abusive data files are now standards, and I've
got to work with them. I have no real choice in the matter. At this
point, the programming language can either facilitate my job of living
with legacy data, or it gets in the way.

There is one point in favor of, let's call them, file persistant data
types. They have little to no overhead for use. Read them into a
structure, maybe fix up some pointers, and you're ready. Perhaps in
a perfect world persistant data would be some parseable file format,
and we would all have either the MIPS or the patience to handle it,
and we wouldn't have to worry about backward compatibility. I'm not
there yet, in all three respects.

Dale Pontius