* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
@ 2020-02-11 3:32 Doug McIlroy
2020-02-11 3:53 ` Larry McVoy
` (5 more replies)
0 siblings, 6 replies; 36+ messages in thread
From: Doug McIlroy @ 2020-02-11 3:32 UTC (permalink / raw)
To: tuhs
> What i like is the autocorrect feature in v8:
>
> $ cd /usr/blot
> /usr/blit
> $ pwd
> /usr/blit
Here I am, editor of the v8 manual and unaware of the feature.
We now know that silent correction is a terrible idea.
Postel's principle: "be conservative in what you do, be liberal
in what you accept from others" was doctrine in early HTML
specs, and led to disastrous disagreement among browsers'
interpretation of web pages. Sadly, the "principle" lives on
despite its having been expunged from the HTML spec.
Today's "langsec" movement grew out of bitter experience
with malicious inputs exploiting "liberal" interpretation of
nonconforming data.
Today's NYT has an article about fake knockoffs of George Orwell
for sale on Amazon. It cites an edition of "Animal Farm"
apparently pirated by lowgrade OCR autocorrected and never
proofread. One of the many gaffes is that every instance of
"iv" beame ChapterIV, as in "prChapterIVacy".
I didn't like some Lisp systems' DWIM (do what I mean) when I
first heard about the feature, and I like it even less 40-some
years on. I would probably have remonstrated with Rob had I
realized the shell was doing it.
Doug
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy @ 2020-02-11 3:53 ` Larry McVoy 2020-02-11 11:24 ` Ralph Corderoy 2020-02-11 4:46 ` Warren Toomey ` (4 subsequent siblings) 5 siblings, 1 reply; 36+ messages in thread From: Larry McVoy @ 2020-02-11 3:53 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. I had the same thought, cd /some/place/I/want/to/remove $PWD is /some/place/I/want/dont/remove rm -rf ./* oops. > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. I think Jon had the right intentions. HTML is different than a command prompt. > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. Yep, agreed. There are places where that works and there are most definitely places where they do not. The shell should not guess. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:53 ` Larry McVoy @ 2020-02-11 11:24 ` Ralph Corderoy 2020-02-11 15:51 ` Larry McVoy 0 siblings, 1 reply; 36+ messages in thread From: Ralph Corderoy @ 2020-02-11 11:24 UTC (permalink / raw) To: tuhs; +Cc: Doug McIlroy Hi Larry, > Doug McIlroy wrote: > > We now know that silent correction is a terrible idea. > > I had the same thought, > > cd /some/place/I/want/to/remove > $PWD is /some/place/I/want/dont/remove > rm -rf ./* An extract from the Jargon File's DWIM entry echoes that. http://www.catb.org/~esr/jargon/html/D/DWIM.html In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost. The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type delete *$ twice. > > Postel's principle: "be conservative in what you do, be liberal in > > what you accept from others" was doctrine in early HTML specs, and > > led to disastrous disagreement among browsers' interpretation of web > > pages. Sadly, the "principle" lives on despite its having been > > expunged from the HTML spec. I often point to this Internet Draft when Postel's Law is brought up in modern discussions about letting standards slip. The Harmful Consequences of Postel's Maxim M. Thomson, Mozilla, 2015-03-09 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 After looking at divergence over time, and long-term costs, it suggests instead ‘Protocol designs and implementations should be maximally strict’. A shame it never became an RFC. Arguing Postel's Law for accepting to deviate is easy as those arguing for strictness have to work out how the laxness could cause a problem. (I'm sad to see Golang accepting deviations from standards. It has been a big enough language to take a stand for ages. https://github.com/golang/go/issues/34540 is one example of a CVE from allowing white-space where there shouldn't be any in the HTTP protocol. Just white-space, what could be harmful about accepting that? https://github.com/golang/go/issues/19989 was another HTTP white-space deviation from the spec. All to help one particular unnamed GPS system.) -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 11:24 ` Ralph Corderoy @ 2020-02-11 15:51 ` Larry McVoy 0 siblings, 0 replies; 36+ messages in thread From: Larry McVoy @ 2020-02-11 15:51 UTC (permalink / raw) To: Ralph Corderoy; +Cc: tuhs, Doug McIlroy On Tue, Feb 11, 2020 at 11:24:25AM +0000, Ralph Corderoy wrote: > > > Postel's principle: "be conservative in what you do, be liberal in > > > what you accept from others" was doctrine in early HTML specs, and > > > led to disastrous disagreement among browsers' interpretation of web > > > pages. Sadly, the "principle" lives on despite its having been > > > expunged from the HTML spec. > > I often point to this Internet Draft when Postel's Law is brought up in > modern discussions about letting standards slip. > > The Harmful Consequences of Postel's Maxim > M. Thomson, Mozilla, 2015-03-09 > https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > > After looking at divergence over time, and long-term costs, it suggests > instead ???Protocol designs and implementations should be maximally > strict???. A shame it never became an RFC. > > Arguing Postel's Law for accepting to deviate is easy as those arguing > for strictness have to work out how the laxness could cause a problem. Perhaps I'm being too kind, but I think people are being a little hard on Jon. I believe what he was pushing for was "it just works". Anyone who has been involved with a long lived software base knows that as you roll out new versions you can break backwards compat. Nobody likes it when you do that. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy 2020-02-11 3:53 ` Larry McVoy @ 2020-02-11 4:46 ` Warren Toomey 2020-02-11 5:12 ` Steve Nickolas 2020-02-11 6:33 ` Rob Pike ` (3 subsequent siblings) 5 siblings, 1 reply; 36+ messages in thread From: Warren Toomey @ 2020-02-11 4:46 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > Doug I misread that as "what the shell was going on", which seems appropriate. Warren ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 4:46 ` Warren Toomey @ 2020-02-11 5:12 ` Steve Nickolas 0 siblings, 0 replies; 36+ messages in thread From: Steve Nickolas @ 2020-02-11 5:12 UTC (permalink / raw) To: Warren Toomey; +Cc: tuhs, Doug McIlroy On Tue, 11 Feb 2020, Warren Toomey wrote: > On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: >> years on. I would probably have remonstrated with Rob had I >> realized the shell was doing it. >> Doug > > I misread that as "what the shell was going on", which seems appropriate. > > Warren > Too much Ninja Turtles '03? -uso. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy 2020-02-11 3:53 ` Larry McVoy 2020-02-11 4:46 ` Warren Toomey @ 2020-02-11 6:33 ` Rob Pike 2020-02-11 9:40 ` arnold ` (2 subsequent siblings) 5 siblings, 0 replies; 36+ messages in thread From: Rob Pike @ 2020-02-11 6:33 UTC (permalink / raw) To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 513 bytes --] On Tue, Feb 11, 2020 at 2:34 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > It was td, and there is an implementation of sorts in The Unix Programming Environment. -rob [-- Attachment #2: Type: text/html, Size: 938 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy ` (2 preceding siblings ...) 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 17:21 ` Dan Cross 5 siblings, 1 reply; 36+ messages in thread From: arnold @ 2020-02-11 9:40 UTC (permalink / raw) To: tuhs, doug Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. But this isn't *silent* correction. The shell tells you where it's putting you when it does this, same as in a 'cd' that happens via $CDPATH. Admittedly, you have to be paying attention, but Unix has always demanded that of its users. Note that I am not arguing with the idea that silent correction is bad; I'm merely pointing out that this is not an instance of that. Thanks, Arnold ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:40 ` arnold @ 2020-02-11 15:06 ` Chet Ramey 0 siblings, 0 replies; 36+ messages in thread From: Chet Ramey @ 2020-02-11 15:06 UTC (permalink / raw) To: arnold, tuhs, doug On 2/11/20 4:40 AM, arnold@skeeve.com wrote: > Doug McIlroy <doug@cs.dartmouth.edu> wrote: > >>> What i like is the autocorrect feature in v8: >>> >>> $ cd /usr/blot >>> /usr/blit >>> $ pwd >>> /usr/blit >> >> Here I am, editor of the v8 manual and unaware of the feature. >> We now know that silent correction is a terrible idea. > > But this isn't *silent* correction. The shell tells you where > it's putting you when it does this, same as in a 'cd' that > happens via $CDPATH. > > Admittedly, you have to be paying attention, but Unix has always > demanded that of its users. The one change I might consider is to disable this feature if the shell is executing a command list, so something like cd /usr/bon && rm -f sh* doesn't do something unexpected before a user has a chance to react. Does the v9 shell do that? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy ` (3 preceding siblings ...) 2020-02-11 9:40 ` arnold @ 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:21 ` Dan Cross 5 siblings, 2 replies; 36+ messages in thread From: Clem Cole @ 2020-02-11 14:36 UTC (permalink / raw) To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1980 bytes --] Amen. As a dyslexic (which most often shows when I'm typing as you folks have experienced) autocorrect generally is a PITA. FWIW: Grammerly works well for me. It underlines in dotted red and lets me look at what it thinks it should be - where I can accept it or not. Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also and let's just say it failed as I explain in a comment /answer on quora ( https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead ). Clem On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. > > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. > > Today's "langsec" movement grew out of bitter experience > with malicious inputs exploiting "liberal" interpretation of > nonconforming data. > > Today's NYT has an article about fake knockoffs of George Orwell > for sale on Amazon. It cites an edition of "Animal Farm" > apparently pirated by lowgrade OCR autocorrected and never > proofread. One of the many gaffes is that every instance of > "iv" beame ChapterIV, as in "prChapterIVacy". > > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > > Doug > [-- Attachment #2: Type: text/html, Size: 3948 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 14:36 ` Clem Cole @ 2020-02-11 15:29 ` Mike Markowski 2020-02-11 16:03 ` Bakul Shah 1 sibling, 0 replies; 36+ messages in thread From: Mike Markowski @ 2020-02-11 15:29 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1115 bytes --] My favorite example is a business trip my wife took. Her surname is Hsi which was "corrected" to His at the site she visited. Upon arrival it took her several *hours* to work out with the security folks that Ms Hsi was not impersonating Ms His. (That says as much about the security group as it does about autocorrect, I suppose.) Mike Markowski On Tue, Feb 11, 2020 at 9:38 AM Clem Cole <clemc@ccc.com> wrote: > Amen. As a dyslexic (which most often shows when I'm typing as you folks > have experienced) autocorrect generally is a PITA. FWIW: Grammerly > works well for me. It underlines in dotted red and lets me look at what it > thinks it should be - where I can accept it or not. > > Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried > it also and let's just say it failed as I explain in a comment /answer on > quora ( > https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead > ). > > Clem > > [-- Attachment #2: Type: text/html, Size: 2857 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 1 sibling, 2 replies; 36+ messages in thread From: Bakul Shah @ 2020-02-11 16:03 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Doug McIlroy [-- Attachment #1: Type: text/plain, Size: 2653 bytes --] I call it automiscorrect. First, it is very easy to mistype on these touch based interfaces and then they miscorrect using too large a vocabulary. At USC, back when I was a student, they started us off with PL/C, a subset of PL/I. The PL/C compiler tried its level best to make sense of the student programs it was given, with error messages such as “PL/C uses ....”. This was confusing to many students as they would do exactly what PL/C said it used and yet their program didn’t work. > On Feb 11, 2020, at 6:38 AM, Clem Cole <clemc@ccc.com> wrote: > > > Amen. As a dyslexic (which most often shows when I'm typing as you folks have experienced) autocorrect generally is a PITA. FWIW: Grammerly works well for me. It underlines in dotted red and lets me look at what it thinks it should be - where I can accept it or not. > > Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also and let's just say it failed as I explain in a comment /answer on quora (https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead). > > Clem > > > >> On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: >> > What i like is the autocorrect feature in v8: >> > >> > $ cd /usr/blot >> > /usr/blit >> > $ pwd >> > /usr/blit >> >> Here I am, editor of the v8 manual and unaware of the feature. >> We now know that silent correction is a terrible idea. >> >> Postel's principle: "be conservative in what you do, be liberal >> in what you accept from others" was doctrine in early HTML >> specs, and led to disastrous disagreement among browsers' >> interpretation of web pages. Sadly, the "principle" lives on >> despite its having been expunged from the HTML spec. >> >> Today's "langsec" movement grew out of bitter experience >> with malicious inputs exploiting "liberal" interpretation of >> nonconforming data. >> >> Today's NYT has an article about fake knockoffs of George Orwell >> for sale on Amazon. It cites an edition of "Animal Farm" >> apparently pirated by lowgrade OCR autocorrected and never >> proofread. One of the many gaffes is that every instance of >> "iv" beame ChapterIV, as in "prChapterIVacy". >> >> I didn't like some Lisp systems' DWIM (do what I mean) when I >> first heard about the feature, and I like it even less 40-some >> years on. I would probably have remonstrated with Rob had I >> realized the shell was doing it. >> >> Doug [-- Attachment #2: Type: text/html, Size: 4755 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 16:03 ` Bakul Shah @ 2020-02-11 17:12 ` Clem Cole 2020-02-11 17:17 ` Steve Nickolas 1 sibling, 0 replies; 36+ messages in thread From: Clem Cole @ 2020-02-11 17:12 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society, Doug McIlroy [-- Attachment #1: Type: text/plain, Size: 1620 bytes --] On Tue, Feb 11, 2020 at 11:03 AM Bakul Shah <bakul@bitblocks.com> wrote: > I call it automiscorrect. > I've been known to same something similar. Usually with a #$%^& before it. > First, it is very easy to mistype on these touch based interfaces and then > they miscorrect using too large a vocabulary. > +1, amen brother Shah, amen, > > At USC, back when I was a student, they started us off with PL/C, a subset > of PL/I. The PL/C compiler tried its level best to make sense of the > student programs it was given, with error messages such as “PL/C uses > ....”. This was confusing to many students as they would do exactly what > PL/C said it used and yet their program didn’t work. > FWIW: I referenced both PL/C and IBM PL/1 compiler in my quora answer. In an interactive world, offering a note like Grammerly's underline, seems reasonable to me - because it forces me to accept it. The automatic doing it for me, is what I dislike - as you said, on touch interfaces it's twice as bad. I remember having a conversation with Doug Cooper when we all were teaching the intro to CS course and I we were getting students turning in 'auto-corrected' code for assignments and wondering why the TAs were not amused. I had thought that having the compiler tell you what was in error and then maybe offering a suggestion, might make sense, but there needed to be some action on the student's part to accept >>and<< repair to code before the compiler would produce something that 'ran.' Anyway, I still think "*Damn Warren's Infernal Machine*" was always well named. Clem [-- Attachment #2: Type: text/html, Size: 4813 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 16:03 ` Bakul Shah 2020-02-11 17:12 ` Clem Cole @ 2020-02-11 17:17 ` Steve Nickolas 1 sibling, 0 replies; 36+ messages in thread From: Steve Nickolas @ 2020-02-11 17:17 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society, Doug McIlroy On Tue, 11 Feb 2020, Bakul Shah wrote: > I call it automiscorrect. First, it is very easy to mistype on these > touch based interfaces and then they miscorrect using too large a > vocabulary. "AutocoWRECKED" -uso. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Doug McIlroy ` (4 preceding siblings ...) 2020-02-11 14:36 ` Clem Cole @ 2020-02-11 17:21 ` Dan Cross 5 siblings, 0 replies; 36+ messages in thread From: Dan Cross @ 2020-02-11 17:21 UTC (permalink / raw) To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1482 bytes --] On Mon, Feb 10, 2020 at 10:34 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. > I think this is a bit unfair. Postel was working in an environment where he was fighting an uphill battle to get the Internet going and, perhaps more importantly, taken seriously: I still vividly remember the derision that was heaped on it as a "research toy" and how the "real" implementation was going to sweep it away, usually in the form of ISO/OSI. An argument can be made that the Internet's installed base and the fact that it largely worked despite imperfect implementations headed off that particular trainwreck. Indeed, one wonders if it would have even been viable as a research project had the early ARPAnet and Internet implementors taken a hard stance on correctness. That said, the HTML thing has always felt like a debacle to me, right from the beginning. It was an anaemic language delivered over a ridiculously bad protocol (HTTP 0.9 or whatever).I fully confess that I completely missed the World Wide Web thing when it first arrived on the scene. To my TeX and troff trained eyes used to interactive protocols, I couldn't see the point. Boy was I wrong! - Dan C. [-- Attachment #2: Type: text/html, Size: 1927 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* [TUHS] Warner's Early Unix Presentation @ 2020-02-07 22:25 Warren Toomey 2020-02-07 23:57 ` Rob Pike 0 siblings, 1 reply; 36+ messages in thread From: Warren Toomey @ 2020-02-07 22:25 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 245 bytes --] https://fosdem.org/2020/schedule/event/early_unix/ The video of Warner Losh's FOSDEM presentation "The Hidden Early History of Unix" is now available. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 322 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] Warner's Early Unix Presentation 2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey @ 2020-02-07 23:57 ` Rob Pike 2020-02-08 15:15 ` Warner Losh 0 siblings, 1 reply; 36+ messages in thread From: Rob Pike @ 2020-02-07 23:57 UTC (permalink / raw) To: Warren Toomey; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 727 bytes --] Very nice talk with lots of good background. It made me think of the boxes of DECTapes we had under the Unix room floor, and what we might have lost. (Volunteers did manage to recover a couple of them, but time was short). PWB inaccuracy: The talk said that tools like grep and sed came from PWB, but that's not true. They were original, as I'm sure Warner knows; he just misspoke. Slightly more important: PWB also did not introduce the idea of the shell (neither did Unix, for that matter), although there was a distinct shell for that system that included the legendary pump operator, later superseded by here documents. The flow from PWB back to the main research line was a trickle at best. We had bad NIH in 1127. -rob [-- Attachment #2: Type: text/html, Size: 831 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] Warner's Early Unix Presentation 2020-02-07 23:57 ` Rob Pike @ 2020-02-08 15:15 ` Warner Losh 2020-02-08 21:50 ` Rob Pike 0 siblings, 1 reply; 36+ messages in thread From: Warner Losh @ 2020-02-08 15:15 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3234 bytes --] On Fri, Feb 7, 2020 at 4:58 PM Rob Pike <robpike@gmail.com> wrote: > Very nice talk with lots of good background. It made me think of the boxes > of DECTapes we had under the Unix room floor, and what we might have lost. > (Volunteers did manage to recover a couple of them, but time was short). > That makes me sad... :( It seems weird: in the Unix room were also all the binders of PDP-7 code that we've retyped in. I wonder if that was considered the archive for early unix, and that may be why we don't have enough early unix artifacts before the 5th edition? I know it was a bit of a rolling release, but I would have thought that ken or dmr would have made archival copies of the system around 'manual edition day' given all the other artifacts they saved. > PWB inaccuracy: The talk said that tools like grep and sed came from PWB, > but that's not true. They were original, as I'm sure Warner knows; he just > misspoke. > Yes. I got confused. In the talk the organizers flashed the time signs too early so I got nervous and rushed through some bits (it didn't help that this was the largest room I've spoken to and it was in the 'lunch coma' spot so some people fell asleep). I also never have a script for the talks, just a good understanding of the material and a rough list of points I'd like to make... And at the last minute I thought it would be better to characterize all the v4-based systems as the early forks and de-emphasize that SCCS Unix -> CB Unix was the first fork, so I thought I made that point a little more awkwardly than I would have liked. > Slightly more important: PWB also did not introduce the idea of the shell > (neither did Unix, for that matter), although there was a distinct shell > for that system that included the legendary pump operator, later superseded > by here documents. > Yes. I'd only mean that pwb enabled people to start writing real, non-trivial shell scripts. There's other scripts in the tree prior to Bourne Shell... There's several 'runit' scripts that look to build things pre-make. There's also sources to 'goto.c' which implemented 'goto label' by rewinding stdin until it finds the label then exiting (I presume the older shell would then start reading again from stdin). Or maybe I've totally missed the point of s1/goto.c... there's no comments in it. It is a bit of a stretch, though, you're right. > The flow from PWB back to the main research line was a trickle at best. We > had bad NIH in 1127. > That matches other sources I've seen: bug fixes flowed into research relatively easily. Performance fixes sometimes (though often not). Some drivers did. And only the occasional program. It's my belief that this slow level of flow is why AT&T shifted from the Research line to the Unix/TS line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and roped other internal lines into Unix/TS 4.0 and/or System V. I also now wonder if we got the Bourne Shell because of NIH or because there was some clear technical defect in pwbsh that Steve Bourne was correcting... There were no env vars before V7, and I haven't looked at the pwb sh to see how that issue was handled. I'll have to also include the 'pump' operator in future talks. Warner [-- Attachment #2: Type: text/html, Size: 4319 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] Warner's Early Unix Presentation 2020-02-08 15:15 ` Warner Losh @ 2020-02-08 21:50 ` Rob Pike 2020-02-10 15:05 ` Dan Cross 0 siblings, 1 reply; 36+ messages in thread From: Rob Pike @ 2020-02-08 21:50 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3708 bytes --] > > > Yes. I'd only mean that pwb enabled people to start writing real, > non-trivial shell scripts. There's other scripts in the tree prior to > Bourne Shell... There's several 'runit' scripts that look to build things > pre-make. There's also sources to 'goto.c' which implemented 'goto label' > by rewinding stdin until it finds the label then exiting (I presume the > older shell would then start reading again from stdin). Or maybe I've > totally missed the point of s1/goto.c... there's no comments in it. It is a > bit of a stretch, though, you're right. > That's how goto worked, yes. The flow from PWB back to the main research line was a trickle at best. We >> had bad NIH in 1127. >> > > That matches other sources I've seen: bug fixes flowed into research > relatively easily. Performance fixes sometimes (though often not). Some > drivers did. And only the occasional program. It's my belief that this slow > level of flow is why AT&T shifted from the Research line to the Unix/TS > line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and > roped other internal lines into Unix/TS 4.0 and/or System V. > I think the SysV/Research split is just another variant of NIH and separate organizations. The development folks did what they did because it helped them (or perhaps just to have fun?). Features in CB Unix bothered us (like the way init worked) and although we were pressured to take them, we resisted. USG was more accommodating. They (USG, Unix Support Group) were just that: a support group, and they were under immense pressure from their users in the Bell System to add features. There was outright mockery from us at how complex stty became, and then the ultimate insult arrived, ioctl. So System V was theirs, managed by them, owned by them. Occasionally we'd go to meetings there to try to convince them to do something differently. I remember a meeting where I tried to talk them out of some truly awful shared memory or IPC thing, but the details are hazy. I'm sure they ignored me anyway; in general they didn't listen to us unless their users were asking for something we had. > I also now wonder if we got the Bourne Shell because of NIH or because > there was some clear technical defect in pwbsh that Steve Bourne was > correcting... There were no env vars before V7, and I haven't looked at the > pwb sh to see how that issue was handled. I'll have to also include the > 'pump' operator in future talks. > Mashey's shell was better than the v6 shell, no question, but it was still pretty clunky and undisciplined. If I remember right, it was a hacked up v6 shell, but I'm not sure. Steve Bourne, who understands formal languages and was (clearly!) a fan of Algol 68, decided a more structured approach was necessary. People malign the look of the code, but his research shell was lovely. For v8 I ripped the IF ELIF macros out; they were just sugar I could scrape off. I put in shell functions, which Steve had wanted to do anyway, made them exportable (fought for that hard at a POSIX meeting, with Ken) and did some cleanups to the printing etc. so it worked well when you cut and paste from the terminal. All that was easy to do because the code was so clean. I learned a lot working on that program. The parser is a jewel. I still think it's a great piece of code, and I miss the v8 shell every day. The GNU "Bourne again" shell is missing all that stuff I did. Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't portable, and I suspect the code will never run on a modern OS. Tom Duff's rc was done as a reaction to the shell being, despite its other glories, still a macro language. But that's another story. -rob [-- Attachment #2: Type: text/html, Size: 4816 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] Warner's Early Unix Presentation 2020-02-08 21:50 ` Rob Pike @ 2020-02-10 15:05 ` Dan Cross 2020-02-10 15:46 ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold 0 siblings, 1 reply; 36+ messages in thread From: Dan Cross @ 2020-02-10 15:05 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 811 bytes --] On Sat, Feb 8, 2020 at 4:52 PM Rob Pike <robpike@gmail.com> wrote: > [snip] I still think it's a great piece of code, and I miss the v8 shell > every day. [snip] > Unfortunately, Steve's memory allocation trick, mallocking on faults, > isn't portable, and I suspect the code will never run on a modern OS. Tom > Duff's rc was done as a reaction to the shell being, despite its other > glories, still a macro language. But that's another story. > Geoff Collyer wrote a nice paper about experiences porting the 9th Edition shell to SunOS 3 on the 68k some years ago. http://www.collyer.net/who/geoff/sh.tour.pdf There is a copy of source code on his personal web page: http://www.collyer.net/who/geoff/ I wonder if any of the 8th edition shell changes you mentioned survived in that code? - Dan C. [-- Attachment #2: Type: text/html, Size: 1558 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-10 15:05 ` Dan Cross @ 2020-02-10 15:46 ` arnold 2020-02-10 18:39 ` Rob Pike 0 siblings, 1 reply; 36+ messages in thread From: arnold @ 2020-02-10 15:46 UTC (permalink / raw) To: robpike, crossd; +Cc: tuhs Dan Cross <crossd@gmail.com> wrote: > Geoff Collyer wrote a nice paper about experiences porting the 9th Edition > shell to SunOS 3 on the 68k some years ago. > http://www.collyer.net/who/geoff/sh.tour.pdf > > There is a copy of source code on his personal web page: > http://www.collyer.net/who/geoff/ > > I wonder if any of the 8th edition shell changes you mentioned survived in > that code? It took less than 10 minutes to get it to compile under Linux. 'whatis' is there, although the pretty printing of function code leaves much to be desired. Lacking is both readline and job control. Arnold ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Rob Pike @ 2020-02-10 18:39 UTC (permalink / raw) To: arnold; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 851 bytes --] Readline and job control were less compelling when you had multiple command windows of editable typescript, which we all had with the Blit. -rob On Tue, Feb 11, 2020 at 2:46 AM <arnold@skeeve.com> wrote: > Dan Cross <crossd@gmail.com> wrote: > > > Geoff Collyer wrote a nice paper about experiences porting the 9th > Edition > > shell to SunOS 3 on the 68k some years ago. > > http://www.collyer.net/who/geoff/sh.tour.pdf > > > > There is a copy of source code on his personal web page: > > http://www.collyer.net/who/geoff/ > > > > I wonder if any of the 8th edition shell changes you mentioned survived > in > > that code? > > It took less than 10 minutes to get it to compile under Linux. 'whatis' > is there, although the pretty printing of function code leaves > much to be desired. > > Lacking is both readline and job control. > > Arnold > [-- Attachment #2: Type: text/html, Size: 1489 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-10 18:39 ` Rob Pike @ 2020-02-10 18:59 ` Bakul Shah 2020-02-10 19:58 ` Angelo Papenhoff 2020-02-11 9:33 ` arnold 2 siblings, 0 replies; 36+ messages in thread From: Bakul Shah @ 2020-02-10 18:59 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 11 Feb 2020 05:39:26 +1100 Rob Pike <robpike@gmail.com> wrote: > > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. ^Z is still useful, to stop forward progress temporarily. Analogous to what ^S/^Q does for output stream. As for editable typescript, I like how Dyalog's APL console app works. You can edit any previous expression but when you run it, the original expression is restored and the edited expression appears on a new line. This way you can see the real history of what you did, as opposed to in acme or rio, for example, where the original content of edited lines in an rc shell window is lost. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 2 siblings, 1 reply; 36+ messages in thread From: Angelo Papenhoff @ 2020-02-10 19:58 UTC (permalink / raw) To: The Eunuchs Hysterical Society On 11/02/20, Rob Pike wrote: > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. What i like is the autocorrect feature in v8: $ cd /usr/blot /usr/blit $ pwd /usr/blit aap ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-10 19:58 ` Angelo Papenhoff @ 2020-02-10 20:11 ` Chet Ramey 0 siblings, 0 replies; 36+ messages in thread From: Chet Ramey @ 2020-02-10 20:11 UTC (permalink / raw) To: Angelo Papenhoff, The Eunuchs Hysterical Society On 2/10/20 2:58 PM, Angelo Papenhoff wrote: > On 11/02/20, Rob Pike wrote: >> Readline and job control were less compelling when you had multiple command >> windows of editable typescript, which we all had with the Blit. > > What i like is the autocorrect feature in v8: > > $ cd /usr/blot > /usr/blit > $ pwd > /usr/blit Maybe unsurprisingly, bash has that as well (the `cdspell' option). I picked up a fair amount from the v8/v9 shells. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-10 18:39 ` Rob Pike 2020-02-10 18:59 ` Bakul Shah 2020-02-10 19:58 ` Angelo Papenhoff @ 2020-02-11 9:33 ` arnold 2020-02-11 9:47 ` Noel Hunt 2020-02-11 9:47 ` Rob Pike 2 siblings, 2 replies; 36+ messages in thread From: arnold @ 2020-02-11 9:33 UTC (permalink / raw) To: robpike, arnold; +Cc: tuhs Rob Pike <robpike@gmail.com> wrote: > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. Understandable. But the 99.9999% of us not in 1127 only had glass ttys. I did have a DMD 5620 for a while (which I loved), but I don't recall that it had editiable typescripts. I thought that that came in with 8-1/2 in Plan 9? Thanks, Arnold ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:33 ` arnold @ 2020-02-11 9:47 ` Noel Hunt 2020-02-11 9:47 ` Rob Pike 1 sibling, 0 replies; 36+ messages in thread From: Noel Hunt @ 2020-02-11 9:47 UTC (permalink / raw) To: arnold; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 308 bytes --] 2020年2月11日(火) 18:34 <arnold@skeeve.com>: > I did have a DMD 5620 for a while (which I loved), but I don't recall > that it had editiable typescripts. I thought that that came in > with 8-1/2 in Plan 9? > Muxterm, the default user-interface window under mux, was most definitely editable. [-- Attachment #2: Type: text/html, Size: 858 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 1 sibling, 1 reply; 36+ messages in thread From: Rob Pike @ 2020-02-11 9:47 UTC (permalink / raw) To: arnold; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1399 bytes --] There were three window systems that I know of that ran on the various incarnations of that machine. The first, mpx, was very basic. The second, mux, allowed editing of text on the screen and had some interesting properties, such as "hold mode", which stopped all reads to the host until hold mode was cancelled. This allowed one to use the terminal window as a general text editor for any application, and was obviously an influence on various followons. It also didn't satisfy any read to the host until you hit return, so all hold mode did was make its basic one-line operation multiline, but it felt liberating and was used constantly for writing mail messages and so on. Both these systems depended (eventually) on new v8 stuff like streams and select, so they didn't work on System 3 etc. USG did a thing for themselves called layers, which was more like mpx than mux. -rob On Tue, Feb 11, 2020 at 8:33 PM <arnold@skeeve.com> wrote: > Rob Pike <robpike@gmail.com> wrote: > > > Readline and job control were less compelling when you had multiple > command > > windows of editable typescript, which we all had with the Blit. > > Understandable. But the 99.9999% of us not in 1127 only had glass ttys. > > I did have a DMD 5620 for a while (which I loved), but I don't recall > that it had editiable typescripts. I thought that that came in > with 8-1/2 in Plan 9? > > Thanks, > > Arnold > [-- Attachment #2: Type: text/html, Size: 1871 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:47 ` Rob Pike @ 2020-02-11 9:59 ` Rob Pike 2020-02-11 17:05 ` Steffen Nurpmeso ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Rob Pike @ 2020-02-11 9:59 UTC (permalink / raw) To: arnold; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1280 bytes --] 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 sophisticated 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. But I'm a grumpy old man and getting far off topic. Warren should cry, "enough!". -rob [-- Attachment #2: Type: text/html, Size: 1457 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:59 ` Rob Pike @ 2020-02-11 17:05 ` Steffen Nurpmeso 2020-02-11 17:18 ` Arthur Krewat ` (2 more replies) 2020-02-11 17:36 ` Dan Cross 2020-02-11 18:35 ` Christopher Browne 2 siblings, 3 replies; 36+ messages in thread From: Steffen Nurpmeso @ 2020-02-11 17:05 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society 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 | |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) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 17:05 ` Steffen Nurpmeso @ 2020-02-11 17:18 ` Arthur Krewat 2020-02-11 18:22 ` Kurt H Maier 2020-02-11 18:26 ` Jon Steinhart 2 siblings, 0 replies; 36+ messages in thread From: Arthur Krewat @ 2020-02-11 17:18 UTC (permalink / raw) To: tuhs Sorry to top-post... To me, the biggest handicap to getting anything done, code-wise, command-line-wise, basically anything, is the keyboard/mouse. I use keyboard shortcuts as much as possible, being an old LA36 kind guy, but I would love to have something that just by looking at text, be able to highlight, copy/cut/paste, etc. Even action buttons. It would be great to look at the "Send" button in Thunderbird and press a key on the mouse or keyboard (or some other eye-contact type signal) and "do" it. Was anything ever done in terms of sub-vocalization? Lots of stories in Sci-Fi about that, nothing ever came out of it, I don't think. On 2/11/2020 12:05 PM, Steffen Nurpmeso wrote: > 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 > | > |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) > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 2 siblings, 1 reply; 36+ messages in thread From: Kurt H Maier @ 2020-02-11 18:22 UTC (permalink / raw) To: tuhs On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote: > > I cannot imagine any other real step forward but control-by- > thought, aka brain computer interfaces. I can't even trust computers to do the right thing with input specially crafted for the program I'm using. There is no way in hell I'm turning it loose on a direct neural interface. Software engineering, as a discipline, is going to require a lot more actual discipline before neural interfaces become anything but fuel for a dystopian hellscape. I'm not saying we can't get there. I'm saying we're not headed in that direction so far. khm ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 18:22 ` Kurt H Maier @ 2020-02-16 21:34 ` Wesley Parish 0 siblings, 0 replies; 36+ messages in thread From: Wesley Parish @ 2020-02-16 21:34 UTC (permalink / raw) To: tuhs It's the stuff of SF - hopefully a lot better than the glorified "one-man shooter action" DooM fictionalizations we've seen (or not) so many of ... COFF's Harbour ... Wesley Parish On 2/12/20, Kurt H Maier <khm@sciops.net> wrote: > On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote: >> >> I cannot imagine any other real step forward but control-by- >> thought, aka brain computer interfaces. > > I can't even trust computers to do the right thing with input specially > crafted for the program I'm using. There is no way in hell I'm turning > it loose on a direct neural interface. Software engineering, as a > discipline, is going to require a lot more actual discipline before > neural interfaces become anything but fuel for a dystopian hellscape. > > I'm not saying we can't get there. I'm saying we're not headed in that > direction so far. > > khm > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 17:05 ` Steffen Nurpmeso 2020-02-11 17:18 ` Arthur Krewat 2020-02-11 18:22 ` Kurt H Maier @ 2020-02-11 18:26 ` Jon Steinhart 2020-02-11 23:56 ` Steffen Nurpmeso 2 siblings, 1 reply; 36+ messages in thread From: Jon Steinhart @ 2020-02-11 18:26 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 18:26 ` Jon Steinhart @ 2020-02-11 23:56 ` Steffen Nurpmeso 2020-02-12 0:12 ` Jon Steinhart 0 siblings, 1 reply; 36+ messages in thread From: Steffen Nurpmeso @ 2020-02-11 23:56 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society 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) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 23:56 ` Steffen Nurpmeso @ 2020-02-12 0:12 ` Jon Steinhart 2020-02-12 5:54 ` Rob Pike 0 siblings, 1 reply; 36+ messages in thread From: Jon Steinhart @ 2020-02-12 0:12 UTC (permalink / raw) To: The Eunuchs Hysterical Society Steffen Nurpmeso writes: > > Of course you are right, you will likely need to focus your mind, > and that requires an intellectual context, knowledge, to base upon. Interesting that you mention this as I'm about to leave for a multi-day advanced yoga workshop. One of the things that I like about yoga is that you do have to learn to focus your mind, and it's amazingly difficult to be focused on something as seemingly simple as standing up straight. I don't think that it's reasonable to expect people to be able to focus without training. Can you imagine if a computer tried to follow all of your fleeting thoughts? In some respects, this takes me back to the early days of speech recognition. I remember people enthusiastically telling me how it would solve the problem of repetitive stress injuries. They were surprised when I pointed out that most people who use their voice in their work actually take vocal training; RSIs are not uncommon among performers. So really, what problem are we trying to solve here? I would claim that the problem is signal-to-noise ratio degradation that's a result of too many people "learning to code" who have never learned to think. Much like I feel that it became harder to find good music when MIDI was invented because there was all of a sudden a lot more noise masquerading as music. I'm reminded of a Usenix panel session that I moderated on the future of window systems a long time ago. Rob was on the panel as was some guy whose name I can't remember from Silicon Graphics. The highlight of the presentation was when Robin asked the question "So, if I understand what the SGI person is saying, it doesn't matter how ugly your shirt is, you can always cover it up with a nice jacket...." While she was asking the question Rob anticipated the rest of the question and started unbuttoning his shirt. So maybe I'm just an old-school minimalist, but I think that the biggest problem that needs solving is good low-level abstractions that are simple and work and don't have to be papered over with layer upon layer on top of them. I just find myself without the patience to learn all of the magic incantations of the package of the week. Jon ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-12 0:12 ` Jon Steinhart @ 2020-02-12 5:54 ` Rob Pike 0 siblings, 0 replies; 36+ messages in thread From: Rob Pike @ 2020-02-12 5:54 UTC (permalink / raw) To: Jon Steinhart, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 76 bytes --] Actually, I just took off a dull sweatshirt to reveal a bright shirt. -rob [-- Attachment #2: Type: text/html, Size: 136 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:59 ` Rob Pike 2020-02-11 17:05 ` Steffen Nurpmeso @ 2020-02-11 17:36 ` Dan Cross 2020-02-11 18:35 ` Christopher Browne 2 siblings, 0 replies; 36+ messages in thread From: Dan Cross @ 2020-02-11 17:36 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1961 bytes --] On Tue, Feb 11, 2020 at 4:59 AM Rob Pike <robpike@gmail.com> wrote: > 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 sophisticated 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. > What do you think of thinks like Jupyter or Lighttable? The early demos for the latter, I thought, were particularly compelling (though sadly the current implementation seems like much more of a traditional text editor and far removed from the original vision). Compare https://www.youtube.com/watch?v=H58-n7uldoU to www.youtube.com/watch?v=52SVAMM3V78 But I'm a grumpy old man and getting far off topic. Warren should cry, > "enough!". > One of the reasons we study history is to understand the present and inform our decisions for the future. Personally, I enjoy these sorts of explorations of where we might have done things differently. - Dan C. [-- Attachment #2: Type: text/html, Size: 3018 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 9:59 ` Rob Pike 2020-02-11 17:05 ` Steffen Nurpmeso 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 2 siblings, 2 replies; 36+ messages in thread From: Christopher Browne @ 2020-02-11 18:35 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2010 bytes --] On Tue, 11 Feb 2020 at 05:00, Rob Pike <robpike@gmail.com> wrote: > 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 sophisticated 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. > > But I'm a grumpy old man and getting far off topic. Warren should cry, > "enough!". > I recently saw indication that the UI for Sam and Acme were inspired by Oberon. (And per url [1] below, Rob Pike is quoted, sort of...) I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some elaboration on that. All that is said is that "Rob was blown away" and that this "influenced" Sam/Acme; is there some further explanation of that worth pointing at? (Or are some Oberon fans putting words in mouths? ;-) ) [1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" [-- Attachment #2: Type: text/html, Size: 2630 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 18:35 ` Christopher Browne @ 2020-02-11 18:54 ` Rob Pike 2020-02-11 21:36 ` Harald Arnesen 1 sibling, 0 replies; 36+ messages in thread From: Rob Pike @ 2020-02-11 18:54 UTC (permalink / raw) To: Christopher Browne; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2664 bytes --] Acme was definitely inspired by Oberon the system. I visited ETH a number of times in the '80s and there were some properties of Oberon I found attractive. Acme definitely grew out of thinking I did there, but of course it was not tied to any language (unlike Oberon or an IDE), but rather integrated the Plan 9 command environment. Also, the button 3 context-getting thing was completely new, and when I spoke at ETH later about Acme, Wirth singled out that feature as something of interest. Sam predates all that. -rob On Wed, Feb 12, 2020 at 5:35 AM Christopher Browne <cbbrowne@gmail.com> wrote: > On Tue, 11 Feb 2020 at 05:00, Rob Pike <robpike@gmail.com> wrote: > >> 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 sophisticated 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. >> >> But I'm a grumpy old man and getting far off topic. Warren should cry, >> "enough!". >> > > I recently saw indication that the UI for Sam and Acme were inspired by > Oberon. (And per url [1] below, Rob Pike is quoted, sort of...) > > I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some > elaboration on that. All that is said is that "Rob was blown away" and > that this "influenced" Sam/Acme; is there some further explanation of that > worth pointing at? (Or are some Oberon fans putting words in mouths? ;-) ) > > [1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" > [-- Attachment #2: Type: text/html, Size: 3579 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 2020-02-11 18:35 ` Christopher Browne 2020-02-11 18:54 ` Rob Pike @ 2020-02-11 21:36 ` Harald Arnesen 1 sibling, 0 replies; 36+ messages in thread From: Harald Arnesen @ 2020-02-11 21:36 UTC (permalink / raw) To: tuhs Christopher Browne [11/02/2020 19.35]: > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" I wqould ask: "How would MacGyver handle this?". -- Hilsen Harald ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2020-02-16 21:35 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-11 3:32 [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] 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 -- strict thread matches above, loose matches on Subject: below -- 2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey 2020-02-07 23:57 ` Rob Pike 2020-02-08 15:15 ` Warner Losh 2020-02-08 21:50 ` Rob Pike 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 2020-02-11 23:56 ` Steffen Nurpmeso 2020-02-12 0:12 ` Jon Steinhart 2020-02-12 5:54 ` 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
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).