From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Haertel Message-Id: <200107202119.f6KLJaA18833@ducky.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] sam vs acme In-Reply-To: <20010718235706.235C4199EA@mail.cse.psu.edu> Date: Fri, 20 Jul 2001 14:19:36 -0700 Topicbox-Message-UUID: d2346a80-eac9-11e9-9e20-41e7f4b1d025 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?