vi editing is in my fingers by now but one unixy “good taste” I missed in
it is composability. External filters didn’t quite hit the right spot. As an
example, you can map a key to do a sequence of operations but you
you can’t then use it in conjunction with search to repeat them over a
range of lines. Eventually nvi added optional support for scripting but
full power of a general PL is not quite what I wanted. And vi didn’t have
to become another Emacs. May be an ability to define new commands,
If/while control structures, expressing its notion of objects (lines, para,
Sections etc) in this DSL and an ability use user commands just like
builtins would’ve gone a long way. Of course, the hard part is coming up
with a clear conceptual model.
On Oct 16, 2017, at 10:52 AM, Clem Cole
On Mon, Oct 16, 2017 at 12:39 PM, Jon Steinhart
I have a similar and maybe even more extreme position. When I was a manager
I placed restrictions on the tools and customizations for members of my team.
My goal was to make sure that any team member could go over to any other team
member's desk and get stuff done.
And I think this loops back to what started some of this threat. The idea of a
programmer with 'good taste.'
Rob (and Brian) railed on BSD in cat -v considered harmful and ‘Program Design in the
UNIX Environment’ (pdf version, ps version) but the points in it was then and are still
now, fresh: What is it that you need to get the job done - to me, that is Doug's
"Universal Unix" concept.
When I answer questions on quora about learning Linux and other UNIX derivative, I still
point them at their book: The Unix Programming Environment
I would say, if the can login into the system and complete the exercises in UPE without
having to make changes, you are pretty close to Doug's "Universal UNIX"
environment. And if you can use the tools, without having to think about them and they
pretty much are what you rely upon everyday, you are getting close to my ideal of