Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]

[Steffen Nurpmeso <steffen@sdaoden.eu>]

Jon Steinhart wrote in
<202002111826.01BIQp2A1764361@darkstar.fourwinds.com>:
 |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.
 ...
 |> I cannot imagine any other real step forward but control-by-
 |> thought, aka brain computer interfaces.  (I personally am even
 ...
 |> 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.
 ...

 |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.

I was impressed what Steve Johnson said at the Unix 50
celebration, about that AI program which learned a game from
scratch in a few hours, just by interpreting "the pixels" that the
game produces on the screen ... and became better than every human
being.

 |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 :-)

Maybe visualized impressions will be interpretable at one time.
If i approach an "Oracle of Delphi" mind state with a "clear"
picture of where i want to go to, where i want the entire thing to
end up with, then i write good code.  I had this not seldom when
i was younger .. but maybe i just should take long walks more
often again.  Freud did one every day.

Of course you are right, you will likely need to focus your mind,
and that requires an intellectual context, knowledge, to base
upon.  That requires many small learning steps, that surely will
not change.  In fact in the western world times to learn are much
too short in my opinion, the normal way of other cultures is
a flatter learning curve, which gives humans more time for personal
development.  The latter in theory, of course.  But an imbalance
of technical knowledge and development of a personal state of mind
results in things like "have it magically appear".

This is not what i mean.  I would rather like it like those magnet
paint tablets from the 70s, where you paint something and then,
swoosh, everything is clean and you start from scratch.  This is
nothing new, we had this in many Science-Fictions, but mostly with
speech interaction, like "no, stop, not that; back two steps" or
something like this.  But by thought.  I think it must be fun,
today you see all the people looking into their smartphone, then
you are surrounded by truly autistic persons!

 |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.

Killing is a trigger for the human brain for sure.  Given the
substantial amount of thoughts which are put into first person
shooters, for the military and (other) young teenagers.
One must face that many, many brains not only have a deficit in
possible targets for thinking, but also lack the motivation or
overall interest in developing them.
Our educational system does not seem to be interested in
addressing this issue either.

 |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.

Linux kernel, horrific.  I currently write an audio-CD access tool
for Linux (since cdparanoia and its successor cd-paranoia seem to
be broken, and whereas cd-info seems to be ok its tarball is about
30 MB, and i thought i can fit this in about 10 KB, and i do rely
on the kernel to drive /dev/cdrom for me, anyway, we are not in
the 90s or so), and i had to look into the kernel source to figure
out the actual limit, and why there is one, of the number of audio
frames i can read at once.  The good news: it is open source!
(One may not read more than a second at once.)

 |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.

That is fantastic.  I absolutely agree, and how often have
i trapped myself because of missing comments, or non-talking
variable names.  It is all so logical and clear when you actually
write the thing down, you cannot imagine that you will be lost in
a forest in just a few months from now.  That is human brain pure.

 |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.

With the exception of some overall comment blocks at the beginning
of files, and from a very superficial point of view, i do agree.
It seems to be expected that you carefully grasp the entire code
context, so that the necessity for the rest has vanished by
itself.  I am not a kernel person, however.
But mind you, that is just how it is with Linux.  You do not even
get an acknowledgement if you report dramatical kernel bugs.
I think i reported four or five real in the ~9-10 months i now use
Linux on bare metal, iof which two/three would have been deadly in
earlier times (Linux kernel survives crashes of a thread).  I did
not get feedback for anything.  But two were fixed as time went
by, that is the good news.

 |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.

Interesting.  I have bookmarked a presentation of her to look at
when i have free time/download again.  I would think substantial
amount of money has been pumped in this area, but i never cared.
I work best when i take a long walk in nature, and hope that i get
kissed by the muse. ^_^  Then come back with a "mind map" of what
there shall be.  And implement it pretty naked vim(1).  ^_^
It seems i do not do all that good enough today.

What i think is that having those new possibilities could possibly
attract more people.  There are so many techniques to train your
brain, to strengthen memory, for example, to memorize tremendous
amount of data somehow, for example by "placing the data on
a virtual walk through the flat", and similar techniques.  If
people had the option to use their very own imagination, and
having computers map that, i think that would be interesting.

So i think, whereas the actual diversity in between people is
pretty minor, all that software now offers are colour themes and
possibly 3-d effects and whatever, but that is all optics and has
nothing much to do with touching peoples individual "brain needs",
aka it does not reach into their inner world in order to, i just
read that nice american term last week, "milk the shit out of it".
^_^

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)