Re: [TUHS] tangential unix question: whatever happened to NeWS?

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Mon, Jan 25, 2021 at 11:05 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote:
> > Osterhout's Tk was beyond amazing.
>
> Still is, really.  So far as I know, nobody has come up with anything
> better.
>

I think one of the innovations that kept it alive was that people took Tk
itself and separated it from Tcl, so one saw bindings from any number of
languages.

The Inferno operating system that was essentially a commercialization of
plan9, implemented Tk with the Limbo programming language (which in many
ways is perhaps the most direct ancestor of Go). That was neat to play
with. Too bad it didn't have a lot of success.

> It had no XDR because it was "reader makes it right" and datatypes
> > were tagged.
>
> That's the first I've heard of that and I really like it.  Most of the
> time, you are on a network of machines that are the same, so why have
> a network byte order, reader makes it right will just work.  Neat.
>

I guess I don't quite understand that. I can get how it works for simple
data types (integers, floating point numbers, perhaps strings) but it seems
like it breaks down pretty quickly for anything with a more complex
representation (structures with multiple members, for instance; how does
one deal with padding, etc?). "Reader makes right" makes some sense for any
pair of sender/receiver architectures, but once you have more than a
handful of machine types with potentially different
ABIs/representations/alignment requirements, etc, then it seems like you're
an n^2 mutual ABI understanding issue. Perhaps I'm being naive in assuming
that multi-data structures are just written out in host format, but if you,
say, write element by element to avoid that, then it seems like you're
already nearly at an architecture independent data representation anyway,
so what does NOT having that buy you? I guess it's potentially faster if
you don't have to swab bytes between similar architectures?

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2611 bytes --]