9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Mike Haertel <mike@ducky.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] sam vs acme
Date: Fri, 20 Jul 2001 14:19:36 -0700	[thread overview]
Message-ID: <200107202119.f6KLJaA18833@ducky.net> (raw)
In-Reply-To: <20010718235706.235C4199EA@mail.cse.psu.edu>

A few days ago, Rob wrote:

>I believe - if you think my opinion is relevant about a program I wrote
>15 years ago but haven't used much for the last 7 or 8 - that sam has
>two major advantages:
>
>1) Structural regular expressions, and the command language that
>	derives from them.
>2) Sam -r
>
>Advantage 1) feels cool and makes a difference when you're working
>on a problem; advantage 2) is the deep, structural improvement that
>trumps all else.

I won't dispute (1), but claim (2) gnawing at me ever since I saw it.

I personally use sam in preference to, say, vi, but I want to
play devil's advocate for a moment...

How is "sam -r" be different from running vi (or another tty based
editor of your choice) in a telnet session in a terminal emulator?
(Leaving aside the obvious differences:  mouse-based vs. keyboard
based, different command language, sam's support for multiple
buffers.)  Why is "sam -r" a "deep, structural improvement"?

* Both approaches take advantage of pre-existing remote execution
facilities.

* Both approaches avoid having to send entire file contents
over a possibly low-bandwidth link.

* Both approaches have a low-bandwidth protocol for updating
the remote display.

But:

* Many different display engines (terminal emulators) have been
written that are compatible with vi, so when you move to a new
system chances are there will be one already.  By contrast, porting
samterm is nontrivial.

* On the other hand, you can easily port the sam back end to
just about any environment, since unlike a vi port you don't
have to worry about tty modes, curses libraries, and other
strange system dependent stuff.  In fact the sam back end could
probably be written as a strictly conforming ANSI C program
with no OS-specific code at all.

So, there are differences, but there also seem to be advantages
on both sides.  What makes "sam -r" so compelling?  Or is
"sam -r" just a hack to regain functionality that was lost
in the move away from cursor-addressed character terminals?

Does this mean that every interactive display program that
does large amounts of file I/O but has low information theoretic
bandwidth to the display (e.g. editors, spreadsheets, just
about anything but pictures in fact) should be written in a
split-process style similarly to sam?  Isn't that a pretty
big burden for programmers?  Isn't there some way to solve this
problem *once* and reuse the solution?


  parent reply	other threads:[~2001-07-20 21:19 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 23:57 rob pike
2001-07-19  0:03 ` Boyd Roberts
2001-07-19  3:20 ` Rick Hohensee
2001-07-20 21:19 ` Mike Haertel [this message]
2001-07-20 22:37   ` Boyd Roberts
2001-07-23  8:55   ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2001-07-20 22:41 forsyth
2001-07-20 21:55 rob pike
2001-07-23  8:54 ` Douglas A. Gwyn
2001-07-24 22:13   ` paurea
2001-07-19  6:14 forsyth
2001-07-19 13:30 ` Theo Honohan
2001-07-19 22:18   ` Boyd Roberts
2001-07-19 14:45 ` Dan Cross
2001-07-11 21:01 rog
2001-07-11 20:36 rob pike
2001-07-11 21:09 ` Dan Cross
2001-07-11 20:36 rog
2001-07-11 20:16 rob pike
     [not found] <rob@plan9.bell-labs.com>
2001-07-11 19:22 ` rob pike
2001-07-11 20:08   ` James A. Robinson
     [not found] <dhog@plan9.bell-labs.com>
2001-07-11 17:53 ` David Gordon Hogan
2001-07-11 19:19   ` James A. Robinson
2001-07-11 21:15     ` Steve Kilbane
2001-07-11 23:11   ` Boyd Roberts
2001-07-11  6:52 nemo
2001-07-10 10:32 rog
2001-07-10 10:43 ` Lucio De Re
2001-07-18  8:43   ` David Rubin
2001-07-18 21:17     ` Boyd Roberts
2001-07-18 21:40       ` Scott Schwartz
2001-07-18 21:51         ` Boyd Roberts
2001-07-18 22:55           ` George Michaelson
2001-07-18 23:00             ` Scott Schwartz
2001-07-19  0:00             ` Boyd Roberts
2001-07-19  0:12             ` suspect
2001-07-19  0:14               ` Boyd Roberts
2001-07-20  8:54             ` Douglas A. Gwyn
2001-07-20  9:47               ` George Michaelson
2001-07-20 10:08                 ` Boyd Roberts
2001-07-20 16:44                   ` Ozan Yigit
2001-07-20 21:57                     ` Boyd Roberts
2001-07-10 22:57 ` Steve Kilbane
2001-07-10 23:23   ` Boyd Roberts
2001-07-11  6:55     ` Steve Kilbane
2001-07-11 13:24       ` Boyd Roberts
2001-07-11 21:20         ` Steve Kilbane
2001-07-12 10:36           ` Boyd Roberts
2001-07-12  8:31         ` Ozan Yigit
2001-07-12 10:38           ` Boyd Roberts
2001-06-28 23:52 David Gordon Hogan
2001-06-29 21:28 ` Boyd Roberts
2001-06-26  4:55 anothy
2001-06-25 23:59 rob pike
2001-06-26  0:14 ` Howard Trickey
2001-06-25 13:29 William Staniewicz
2001-06-25  7:45 Richard Miller
2001-06-25  7:10 nigel
2001-06-25  7:25 ` Matt
2001-06-28 23:04   ` Boyd Roberts
2001-06-25  1:08 jmk
2001-06-25  0:28 anothy
2001-07-10  9:00 ` Ozan Yigit
     [not found] <aam396@mail.usask.ca>
2001-06-24 23:04 ` andrey mirtchovski
2001-06-24 22:14   ` Matt
2001-06-24 22:33   ` Scott Schwartz
2001-06-25  3:41     ` Dan Cross
2001-06-28 22:58     ` Boyd Roberts

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=200107202119.f6KLJaA18833@ducky.net \
    --to=mike@ducky.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

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

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