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.