The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Jon Steinhart <jon@fourwinds.com>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
Date: Tue, 11 Feb 2020 10:26:51 -0800	[thread overview]
Message-ID: <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> (raw)
In-Reply-To: <20200211170501.0N1Pu%steffen@sdaoden.eu>

Steffen Nurpmeso writes:
> Rob Pike wrote in
> <CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw@mail.gmail.com>:
>  |My general mood about the current standard way of nerd working is how \
>  |unimaginative and old-fashioned it feels. There are countless ways \
>  |we could be interacting with our terminals, editors, and shells 
>  |while we program, but for various sociological and historical reasons \
>  |we're pretty much using one from decades ago. I'm sure it's productive \
>  |for almost everyone, but it seems dull to me. We could be 
>  |doing something much more dynamic. I mean, xterm is hardly more sophisti\
>  |cated than the lame terminal code that ran in mpx (ca. 1982), other \
>  |than colors and cursor addressing, which date from the 1960s 
>  |via early PCs. IDEs don't sing to me, although they are powerful, because \
>  |they don't integrate well with the environment, only with the language. \
>  |And they are just lots of features, not a coherent 
>  |vision. No model to speak of.
>  |
>  |Compare what happened with our shell windows with what happened with \
>  |our "smart" phones in the last 20 years and you'll get some inkling \
>  |of what I think we're missing. It's not that we should program the 
>  |way we use iPhones, but that there are fields where user interface \
>  |work has made a real different recently. Not so in programming, though. \
>  |We're missing out.
>
> I cannot imagine any other real step forward but control-by-
> thought, aka brain computer interfaces.  (I personally am even
> convinced we will get the brain implant -- ever since i got all
> those B and C Hollywood movies from the 50s wrong, back when i was
> a kid.  It is convincing still, automatic emergency calls, health
> record and cases of incompatibility at hand when needed, and not
> to talk about the hints it will give the law enforcement side of
> the road.)
>
> Just last year i have seen a report on the current stage of
> affairs, Carnegie-Mellon and Minnesota Universities seem to have
> build a non-invasively controlled robotic arm, pretty high
> precision.
>
>   "Wir haben erhebliche Fortschritte im Bereich
>   Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate
>   gemacht.
>   We have made substantial progress in the region of
>   thought-controlled robotic devices via implants.
>
>   Das ist hervorragende Forschungsarbeit", sagt He.
>   "That is superb research work", says He [Professor Bin He,
>   Carnegie-Mellon].
>
>   "Nichtinvasiv ist jedoch unser ultimatives Ziel.
>   Fortschritte in der neuronalen Dekodierung und der praktischen
>   Auswirkungen auf die mögliche Entwicklung nichtinvasiver
>   Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche
>   Neurorobotik haben."
>
>   "Albeit non-invasive is our ultimate goal.
>   Progress in neuronal decoding, and the practical usability of
>   non-invasive control of robotic arms will have substantial
>   effect on the possible development of non-invasive
>   neuro-robotics."
>
>  |But I'm a grumpy old man and getting far off topic. Warren should cry, \
>  |"enough!".
>
> I personally would love it, if it where only in the hands of
> empathic beings, capable of reflection.  Yet it is us. ^_^
>
> --steffen

Well, I'm gonna give my two cents on this before Warren tells us that it's off-topic :-)

One way to look at it is that there are two stages to programming or any
other problem-solving discipline.  First, clearly express the problem.
Second, implement a solution.

There's been a lot of improvement in both of these areas during my lifetime.

Especially when I look at the "everybody must learn to code" movement I see
people looking for a magic bullet; they just want to think of something and
have it magically appear.  Problem is that the thinking of something isn't
that easy.  People want DWIT (do what I think), a step beyond DWIM :-)

I'm reminded of the awful virtual reality panel at SIGGRAPH some decades ago
now where people stood up and said "with virtual reality there will be no
misunderstanding and people will be able to know exactly what you're thinking."
My response was "wow, if people knew exactly what you were thinking they'd kill
you."  The fuzziness of our brains is an asset here, not a liability.  So I'm
not thinking that translating thoughts directly into programs is a good thing.

All that said, there is an area that I think needs some work, which reminds me
that I wrote Tamara Munzner at UBC about this and need to ping her again.  My
current troublemaking project is to make an unfortunately necessary change to
linux to accomplish something that I want to do.  Because I haven't mucked
around in the kernel before I've been keeping notes as I try to figure it out;
sort of a travelogue.

One of the things that's important to me is writing code for the reader, not
the writer.  Being old, I remember working for companies where there was
warranty support for products, and that maintenance and support cost way more
than development.  So I've always written code for the maintainers because I
never wanted to become one because nobody could figure out my code.

Oh, Jon's rambling here, how is this relevant?  Something that I never gave
much thought about until I was a reviewer for Tamara's book is that my coding
style tries to maximize the brain's pre-attentive mode.  A lot of hunting
around in code involves visually scanning for patterns (vgrep), and one would
like to be able to do that in fixed time as opposed to linear time.

In my opinion, the linux code sucks at this.  The coding style of breaking up
functions to keep the number of indent levels low has what I'm calling poor
"meatspace locality of reference."  People have caches too, and we'd never
write code for a computer that thrashes as badly as code written for people.

Anyway, what I've been wondering about is whether anybody has examined the
UIs of different IDEs from a pre-attentive standpoint.  One of the weird
things about how our brains manage pre-attentive mode is that there are only
a handful of things that we can do in that mode before popping out, and that
those things have weird interactions.  So, for example, does coloring things
work?  Does bracket matching work?  Do they still work if you do both?  A
good thesis topic for someone younger than me.

Jon

  parent reply	other threads:[~2020-02-11 18:27 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey
2020-02-07 23:57 ` Rob Pike
2020-02-08  0:43   ` Warren Toomey
2020-02-08  3:37     ` Warner Losh
2020-02-08 15:15   ` Warner Losh
2020-02-08 21:50     ` Rob Pike
2020-02-08 22:29       ` Chet Ramey
2020-02-08 22:54         ` Rob Pike
2020-02-08 23:02           ` Chet Ramey
2020-02-08 23:11             ` Rob Pike
2020-02-08 23:13               ` Rob Pike
2020-02-08 23:21               ` Kurt H Maier
2020-02-08 23:26                 ` Rob Pike
2020-02-08 23:28                   ` Chet Ramey
2020-02-08 23:26               ` Chet Ramey
2020-02-08 23:29                 ` Rob Pike
2020-02-08 23:35                   ` Warner Losh
2020-02-08 23:36                   ` Chet Ramey
2020-02-08 23:54                     ` Rob Pike
2020-02-09  0:11                       ` Chet Ramey
2020-02-09  0:19                   ` Larry McVoy
2020-02-08 22:31       ` Richard Salz
2020-02-10 13:18       ` Tony Finch
2020-02-10 15:05       ` Dan Cross
2020-02-10 15:46         ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold
2020-02-10 18:39           ` Rob Pike
2020-02-10 18:59             ` Bakul Shah
2020-02-10 19:58             ` Angelo Papenhoff
2020-02-10 20:11               ` Chet Ramey
2020-02-11  9:33             ` arnold
2020-02-11  9:47               ` Noel Hunt
2020-02-11  9:47               ` Rob Pike
2020-02-11  9:59                 ` Rob Pike
2020-02-11 17:05                   ` Steffen Nurpmeso
2020-02-11 17:18                     ` Arthur Krewat
2020-02-11 18:22                     ` Kurt H Maier
2020-02-16 21:34                       ` Wesley Parish
2020-02-11 18:26                     ` Jon Steinhart [this message]
2020-02-11 23:56                       ` Steffen Nurpmeso
2020-02-12  0:12                         ` Jon Steinhart
2020-02-12  1:03                           ` [TUHS] V9 shell Warren Toomey
2020-02-12  5:54                           ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Rob Pike
2020-02-11 17:36                   ` Dan Cross
2020-02-11 18:35                   ` Christopher Browne
2020-02-11 18:54                     ` Rob Pike
2020-02-11 21:36                     ` Harald Arnesen
2020-02-11  3:32 Doug McIlroy
2020-02-11  3:53 ` Larry McVoy
2020-02-11 11:24   ` Ralph Corderoy
2020-02-11 15:51     ` Larry McVoy
2020-02-11  4:46 ` Warren Toomey
2020-02-11  5:12   ` Steve Nickolas
2020-02-11  6:33 ` Rob Pike
2020-02-11  9:40 ` arnold
2020-02-11 15:06   ` Chet Ramey
2020-02-11 14:36 ` Clem Cole
2020-02-11 15:29   ` Mike Markowski
2020-02-11 16:03   ` Bakul Shah
2020-02-11 17:12     ` Clem Cole
2020-02-11 17:17     ` Steve Nickolas
2020-02-11 17:21 ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202002111826.01BIQp2A1764361@darkstar.fourwinds.com \
    --to=jon@fourwinds.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).