[TUHS] Tech Sq elevator (Was: screen editors)

[TUHS] Tech Sq elevator (Was: screen editors)

[Noel Chiappa]

    > From: Clem Cole

    > when she found out the elevators were hacked and controlled by the
    > student's different computers, she stopped using them and would take
    > the stairs 

It wasn't quite as major as this makes it sound! A couple of inconspicuous
wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
the Knight displays) into the elevator controller, and run onto the terminals
where the wires from the 'down' call buttons on the 8th and 9th floors went.

So it wasn't anything major, and there was really no need for her to take the
stair (especially 8 flights up :-).

The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
Knight TV keyboards; typing 'ESC E' called the elevator to the floor
that keyboard was on (there's a table, 'ELETAB', which gives the physical
floor for each keyboard).

The machine could also open the locked 9th floor door to the machine room
(with an 'ESC D'), and there some other less major things, e.g. print screen
hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
out of the 'keyboard multiplexor'); it may have been something the AI Lab
built from scratch.

      Noel

Re: [TUHS] Tech Sq elevator

[Lars Brinkhoff]

Noel Chiappa writes:
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think)
> from Knight TV keyboards

(This isn't TUHS material, but I can't resist.  CC to COFF.)

There is also a Chaosnet service to call for the elevator or open the
door, so it can be used remotely.  The ITS program ESCE uses this
service.  I suppose there must have been something for the Lisp machines
too, maybe even a Super-Hyper-Cokebottle keyboard command.

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Angelo Papenhoff]

On 10/01/20, Noel Chiappa wrote:
>     > From: Clem Cole
> 
>     > when she found out the elevators were hacked and controlled by the
>     > student's different computers, she stopped using them and would take
>     > the stairs 
> 
> It wasn't quite as major as this makes it sound! A couple of inconspicuous
> wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
> the Knight displays) into the elevator controller, and run onto the terminals
> where the wires from the 'down' call buttons on the 8th and 9th floors went.
> 
> So it wasn't anything major, and there was really no need for her to take the
> stair (especially 8 flights up :-).
> 
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
> Knight TV keyboards; typing 'ESC E' called the elevator to the floor
> that keyboard was on (there's a table, 'ELETAB', which gives the physical
> floor for each keyboard).
> 
> The machine could also open the locked 9th floor door to the machine room
> (with an 'ESC D'), and there some other less major things, e.g. print screen
> hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
> out of the 'keyboard multiplexor'); it may have been something the AI Lab
> built from scratch.

For those not aware: we have the TV-11 running again under emulation and
it is once again the preferred way to use ITS.
Unfortunately I'm not quite sure how to emulate all the elevator
behaviour...any ideas? :D


aap

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Kevin Bowling]

On Sun, Jan 12, 2020 at 3:26 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>
> >> After scrolling through the command list, I wondered how
> >> long it was and asked to have it counted. Easy, I thought,
> >> just pass it to a wc-like program. But "just pass it" and
> >> "wc-like" were not givens as they are in Unix culture.
> >> It took several minutes for the gurus to do it--without
> >> leaving emacs, if I remember right.
>
> > This is kind of illustrative of the '60s acid trip that
> > perpetuates in programming "Everything's a string maaaaan".
> > The output is seen as truth because the representation is
> > for some reason too hard to get at or too hard to cascade
> > through the system.
>
> How did strings get into the discussion? Warner showed how
> emacs could be expected to do the job--and more efficiently
> than the Unix way, at that: (list-length (command-list-fn)).
> The surprise was that this wasn't readily available.

Bakul provided an explanation for the pipeline, the funny cue to me
that I interpreted from Warner's message is just that emacs had the
ability to do it in a coherent way but did not and ISTM that the way
you make a mess of that is by losing the intent of the representation.
I am regularly surprised by how surprising type systems are to
computing professionals.  The language and environment may help or
dissuade you from doing that, wasn't really relevant to my original
point.

Larry tells me the message is somehow inflammatory, it wasn't intended
that way I was just trying to make light of the situation and provide
people a launch pad to think for themselves about some fundamentals
because it's worthwhile to do so occasionally.

> Back then, in fact, you couldn't ask sh for its command
> list. help|wc couldn't be done because help wasn't there.
>
> Emacs had a different problem. It had a universal internal
> interface--lists rather than strings--yet did not have
> a way to cause this particular list to "cascade through
> the system". (print(command-list-fn)) was provided, while
> (command-list-fn) was hidden.

The only response I can come up with to these two points eventually
boils down to a philosophical riddle:  does the work matter or does
how the work is done matter?  Both, the situation dictates.  I execute
innumerable shell pipelines per day and perhaps craft a dozen
ephemerals ones.

Regards,
Kevin

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Doug McIlroy]

>> After scrolling through the command list, I wondered how
>> long it was and asked to have it counted. Easy, I thought,
>> just pass it to a wc-like program. But "just pass it" and
>> "wc-like" were not givens as they are in Unix culture.
>> It took several minutes for the gurus to do it--without
>> leaving emacs, if I remember right.

> This is kind of illustrative of the '60s acid trip that
> perpetuates in programming "Everything's a string maaaaan".
> The output is seen as truth because the representation is
> for some reason too hard to get at or too hard to cascade
> through the system.

How did strings get into the discussion? Warner showed how
emacs could be expected to do the job--and more efficiently
than the Unix way, at that: (list-length (command-list-fn)).
The surprise was that this wasn't readily available.

Back then, in fact, you couldn't ask sh for its command
list. help|wc couldn't be done because help wasn't there.

Emacs had a different problem. It had a universal internal
interface--lists rather than strings--yet did not have
a way to cause this particular list to "cascade through
the system". (print(command-list-fn)) was provided, while
(command-list-fn) was hidden.

Doug

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Jon Steinhart]

Bakul Shah writes:
> On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > I wasn't being snarky.  You said
> >
> >   "The output is seen as truth because the representation is for some
> >   reason too hard to get at or too hard to cascade through the system."
> >
> > I honestly have no idea what that means.
> >
> > Likewise, 
> >
> >   "There's a total comedy of work going on in the unix way of
> >   a wc pipeline versus calling a length function on a list."
> >
> > I just don't know what you mean.
>
> May be this is not what Kevin meant but the way I interpreted
> his message: smushing everything down to strings for output as
> in unix pipelines loses any underlying structure which then
> may have to be rediscovered by the next program in the
> pipeline by parsing. This is slower, indirect and errorprone.
> If one can communicate a structured representation of data between
> components that would be better.

Ah.  So lines IS the structure that a lot of people want.  As I just
said in a post, the JSON tools are a good example of communicating
structured data although I would have done them differently.

Jon

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Bakul Shah]

On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon@fourwinds.com> wrote:
>
> I wasn't being snarky.  You said
>
>   "The output is seen as truth because the representation is for some
>   reason too hard to get at or too hard to cascade through the system."
>
> I honestly have no idea what that means.
>
> Likewise, 
>
>   "There's a total comedy of work going on in the unix way of
>   a wc pipeline versus calling a length function on a list."
>
> I just don't know what you mean.

May be this is not what Kevin meant but the way I interpreted
his message: smushing everything down to strings for output as
in unix pipelines loses any underlying structure which then
may have to be rediscovered by the next program in the
pipeline by parsing. This is slower, indirect and errorprone.
If one can communicate a structured representation of data between
components that would be better.

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Kevin Bowling]

On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Kevin Bowling writes:
> > I honestly can't tell if this is genius level snark :) in case you're
> > sincere we generally go to great lengths to build up data types and
> > structures (in C lingo) when programming only to tear those useful
> > attributes off often at inopportune times.  Basically type
> > systems/type safety have been too expensive or too difficult to use
> > through history.
> >
> > Think of sitting at an SQL prompt as a counterpoint.  You can pretty
> > easily get at the underlying representation and relationships of the
> > data and the output is just a side effect.  Not saying SQL is the
> > ultimate answer, just that most people have a bit of experience with
> > it and UNIX so can mentally compare the two for themselves and see the
> > pros and cons to preserving the underlying representations.
> >
> > Regards,
> > Kevin
> >
> > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote:
> > >
> > > Kevin Bowling writes:
> > > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > > programming "Everything's a string maaaaan".  The output is seen as
> > > > truth because the representation is for some reason too hard to get at
> > > > or too hard to cascade through the system.
> > > >
> > > > There's a total comedy of work going on in the unix way of a wc
> > > > pipeline versus calling a length function on a list.  Nonetheless, the
> > > > unix pipeline was and is often magnitude easier for a single user to
> > > > get at.  This kind of thing is amusing and endearing to me about our
> > > > profession in modern day.
> > > >
> > > > Regards,
> > > > Kevin
> > >
> > > Can you please elaborate?  I read your post, and while I can see that it
> > > contains English words I can't make any sense out of what you said.
> > >
> > > Thanks,
> > >         Jon
>
> I wasn't being snarky.  You said
>
>   "The output is seen as truth because the representation is for some
>   reason too hard to get at or too hard to cascade through the system."
>
> I honestly have no idea what that means.

If the SQL prompt example did not clarify you are welcome to go one on
one if this is something you think is curious to you, I think I've
explained the point I was making adequately for a general audience.

>
> Likewise,
>
>   "There's a total comedy of work going on in the unix way of
>   a wc pipeline versus calling a length function on a list."
>
> I just don't know what you mean.
>

Reason through what happens in a shell pipeline, the more detail the
better.  A quick nudge is fork/exec, what happens in the kernel, what
happens in page tables, what happens at the buffered output, tty layer
etc.  Very few people actually understand all these steps even at a
general level in modern systems.

If you had a grocery list on a piece of paper would you
a) count the lines or read it directly off the last line number on the
paper if it is numbered

b) copy each character letter by letter to a new piece of equipment
(say, a word processor), until you encounter a special character that
happens to be represented as a space on the screen, increment a
counter, repeat until you reach another special character, output the
result and then destroy and throw away both the list and the word
processor equipment.

This kind of thing doesn't really matter in the small or at all for
performance because computers are fast.  But most programming bugs in
the large eventually boil down to some kind of misunderstanding where
the representation was lost and recast in a way that does not make
sense.

Regards,
Kevin

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Jon Steinhart]

Kevin Bowling writes:
> I honestly can't tell if this is genius level snark :) in case you're
> sincere we generally go to great lengths to build up data types and
> structures (in C lingo) when programming only to tear those useful
> attributes off often at inopportune times.  Basically type
> systems/type safety have been too expensive or too difficult to use
> through history.
>
> Think of sitting at an SQL prompt as a counterpoint.  You can pretty
> easily get at the underlying representation and relationships of the
> data and the output is just a side effect.  Not saying SQL is the
> ultimate answer, just that most people have a bit of experience with
> it and UNIX so can mentally compare the two for themselves and see the
> pros and cons to preserving the underlying representations.
>
> Regards,
> Kevin
>
> On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > Kevin Bowling writes:
> > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > programming "Everything's a string maaaaan".  The output is seen as
> > > truth because the representation is for some reason too hard to get at
> > > or too hard to cascade through the system.
> > >
> > > There's a total comedy of work going on in the unix way of a wc
> > > pipeline versus calling a length function on a list.  Nonetheless, the
> > > unix pipeline was and is often magnitude easier for a single user to
> > > get at.  This kind of thing is amusing and endearing to me about our
> > > profession in modern day.
> > >
> > > Regards,
> > > Kevin
> >
> > Can you please elaborate?  I read your post, and while I can see that it
> > contains English words I can't make any sense out of what you said.
> >
> > Thanks,
> >         Jon

I wasn't being snarky.  You said

  "The output is seen as truth because the representation is for some
  reason too hard to get at or too hard to cascade through the system."

I honestly have no idea what that means.

Likewise, 

  "There's a total comedy of work going on in the unix way of
  a wc pipeline versus calling a length function on a list."

I just don't know what you mean.

Jon

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Kevin Bowling]

I honestly can't tell if this is genius level snark :) in case you're
sincere we generally go to great lengths to build up data types and
structures (in C lingo) when programming only to tear those useful
attributes off often at inopportune times.  Basically type
systems/type safety have been too expensive or too difficult to use
through history.

Think of sitting at an SQL prompt as a counterpoint.  You can pretty
easily get at the underlying representation and relationships of the
data and the output is just a side effect.  Not saying SQL is the
ultimate answer, just that most people have a bit of experience with
it and UNIX so can mentally compare the two for themselves and see the
pros and cons to preserving the underlying representations.

Regards,
Kevin

On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Kevin Bowling writes:
> > This is kind of illustrative of the '60s acid trip that perpetuates in
> > programming "Everything's a string maaaaan".  The output is seen as
> > truth because the representation is for some reason too hard to get at
> > or too hard to cascade through the system.
> >
> > There's a total comedy of work going on in the unix way of a wc
> > pipeline versus calling a length function on a list.  Nonetheless, the
> > unix pipeline was and is often magnitude easier for a single user to
> > get at.  This kind of thing is amusing and endearing to me about our
> > profession in modern day.
> >
> > Regards,
> > Kevin
>
> Can you please elaborate?  I read your post, and while I can see that it
> contains English words I can't make any sense out of what you said.
>
> Thanks,
>         Jon

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Jon Steinhart]

Kevin Bowling writes:
> This is kind of illustrative of the '60s acid trip that perpetuates in
> programming "Everything's a string maaaaan".  The output is seen as
> truth because the representation is for some reason too hard to get at
> or too hard to cascade through the system.
>
> There's a total comedy of work going on in the unix way of a wc
> pipeline versus calling a length function on a list.  Nonetheless, the
> unix pipeline was and is often magnitude easier for a single user to
> get at.  This kind of thing is amusing and endearing to me about our
> profession in modern day.
>
> Regards,
> Kevin

Can you please elaborate?  I read your post, and while I can see that it
contains English words I can't make any sense out of what you said.

Thanks,
	Jon

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Larry McVoy]

I'll counter with Linux's /proc where everything is a string.  It's super
pleasant and I say that coming from SysV /proc where it was all a mess.

If performance is the metric, everything is a string is not so much.
If performance is not the high order bit, a /proc that you can read
with cat or grep is super pleasant.

On Sun, Jan 12, 2020 at 01:25:13PM -0700, Kevin Bowling wrote:
> This is kind of illustrative of the '60s acid trip that perpetuates in
> programming "Everything's a string maaaaan".  The output is seen as
> truth because the representation is for some reason too hard to get at
> or too hard to cascade through the system.
> 
> There's a total comedy of work going on in the unix way of a wc
> pipeline versus calling a length function on a list.  Nonetheless, the
> unix pipeline was and is often magnitude easier for a single user to
> get at.  This kind of thing is amusing and endearing to me about our
> profession in modern day.
> 
> Regards,
> Kevin
> 
> On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> >>
> >> Mention of elevators at Tech Square reminds me of visiting there
> >> to see the Lisp machine. I was struck by cultural differences.
> >>
> >> At the time we were using Jerqs, where multiple windows ran
> >> like multiple time-sharing sessions. To me that behavior was a
> >> no-brainer. Surprisingly, Lisp-machine windows didn't work that
> >> way; only the user-selected active window got processor time.
> >>
> >> The biggest difference was emacs, which no one used at Bell
> >> Labs. Emacs, of course was native to the Lisp machine and
> >> provided a powerful and smoothly extensible environment. For
> >> example, its reflective ability made it easy to display a
> >> list of its commands. "Call elevator" stood out amng mundane
> >> programmering actions like cut, paste and run.
> >>
> >> After scrolling through the command list, I wondered how long
> >> it was and asked to have it counted. Easy, I thought, just
> >> pass it to a wc-like program. But "just pass it" and "wc-like"
> >> were not givens as they are in Unix culture.  It took several
> >> minutes for the gurus to do it--without leaving emacs, if I
> >> remember right.
> >
> >
> > It should have been something like  (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by.
> >
> > ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse...
> >
> > Warner

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Kevin Bowling]

This is kind of illustrative of the '60s acid trip that perpetuates in
programming "Everything's a string maaaaan".  The output is seen as
truth because the representation is for some reason too hard to get at
or too hard to cascade through the system.

There's a total comedy of work going on in the unix way of a wc
pipeline versus calling a length function on a list.  Nonetheless, the
unix pipeline was and is often magnitude easier for a single user to
get at.  This kind of thing is amusing and endearing to me about our
profession in modern day.

Regards,
Kevin

On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>>
>> Mention of elevators at Tech Square reminds me of visiting there
>> to see the Lisp machine. I was struck by cultural differences.
>>
>> At the time we were using Jerqs, where multiple windows ran
>> like multiple time-sharing sessions. To me that behavior was a
>> no-brainer. Surprisingly, Lisp-machine windows didn't work that
>> way; only the user-selected active window got processor time.
>>
>> The biggest difference was emacs, which no one used at Bell
>> Labs. Emacs, of course was native to the Lisp machine and
>> provided a powerful and smoothly extensible environment. For
>> example, its reflective ability made it easy to display a
>> list of its commands. "Call elevator" stood out amng mundane
>> programmering actions like cut, paste and run.
>>
>> After scrolling through the command list, I wondered how long
>> it was and asked to have it counted. Easy, I thought, just
>> pass it to a wc-like program. But "just pass it" and "wc-like"
>> were not givens as they are in Unix culture.  It took several
>> minutes for the gurus to do it--without leaving emacs, if I
>> remember right.
>
>
> It should have been something like  (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by.
>
> ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse...
>
> Warner

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[markus schnalke]

Hoi.

[2020-01-12 09:56] Warner Losh <imp@bsdimp.com>
>
> It should have been something like  (list-length (command-list-fn)) but I'll
> bet that ? was bound to a complicated function that just displayed the results
> and didn't properly abstract out the UI (printing) from the data collection
> (getting a list), which is what made it so hard. I've had so many gnu emacs
> experiences like this over the years, but to the community's credit, there's
> fewer and fewer as time goes by.
> 
> ObUnix: This shows the power of having the right abstractions and being
> disciplined to code to those ideal abstractions any time there might be
> reuse...

True words.

These concepts (what you call abstractions) is no optional geek
pleasure but the most important information for everyone using the
system or language. It's important to teach them, make them explicit,
deal with them, substract points in exams for correct solutions that
have bad style, keep the libraries and books on a high level, ...

This is one of the lesser regarded aspects of what Unix did really
well.


meillo

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Warner Losh]

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

On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Mention of elevators at Tech Square reminds me of visiting there
> to see the Lisp machine. I was struck by cultural differences.
>
> At the time we were using Jerqs, where multiple windows ran
> like multiple time-sharing sessions. To me that behavior was a
> no-brainer. Surprisingly, Lisp-machine windows didn't work that
> way; only the user-selected active window got processor time.
>
> The biggest difference was emacs, which no one used at Bell
> Labs. Emacs, of course was native to the Lisp machine and
> provided a powerful and smoothly extensible environment. For
> example, its reflective ability made it easy to display a
> list of its commands. "Call elevator" stood out amng mundane
> programmering actions like cut, paste and run.
>
> After scrolling through the command list, I wondered how long
> it was and asked to have it counted. Easy, I thought, just
> pass it to a wc-like program. But "just pass it" and "wc-like"
> were not givens as they are in Unix culture.  It took several
> minutes for the gurus to do it--without leaving emacs, if I
> remember right.
>

It should have been something like  (list-length (command-list-fn)) but
I'll bet that ? was bound to a complicated function that just displayed the
results and didn't properly abstract out the UI (printing) from the data
collection (getting a list), which is what made it so hard. I've had so
many gnu emacs experiences like this over the years, but to the community's
credit, there's fewer and fewer as time goes by.

ObUnix: This shows the power of having the right abstractions and being
disciplined to code to those ideal abstractions any time there might be
reuse...

Warner

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

Re: [TUHS] Tech Sq elevator (Was: screen editors)

[Doug McIlroy]

Mention of elevators at Tech Square reminds me of visiting there
to see the Lisp machine. I was struck by cultural differences.

At the time we were using Jerqs, where multiple windows ran
like multiple time-sharing sessions. To me that behavior was a
no-brainer. Surprisingly, Lisp-machine windows didn't work that
way; only the user-selected active window got processor time.

The biggest difference was emacs, which no one used at Bell
Labs. Emacs, of course was native to the Lisp machine and
provided a powerful and smoothly extensible environment. For
example, its reflective ability made it easy to display a
list of its commands. "Call elevator" stood out amng mundane
programmering actions like cut, paste and run.

After scrolling through the command list, I wondered how long
it was and asked to have it counted. Easy, I thought, just
pass it to a wc-like program. But "just pass it" and "wc-like"
were not givens as they are in Unix culture.  It took several
minutes for the gurus to do it--without leaving emacs, if I
remember right.

Doug