Re: [9fans] Using the Acme Editor
marc.info
marc.info
The various ML dialects share the same flaw in their
syntax. They lack a simple property I call editor
friendliness. An editor friendly language has the property
that a simple calculation is all that is needed to locate the
beginning of an expression when one is at the end of an
expression.
As you can guess, Lisp is a very editor friendly language.
Because of this fact, an experienced Emacs user realizes
nearly all of the benefits of structure based editing
without suffering from its restrictions.
--- John D. Ramsdell
The various Lisp dialects share the same flaw in their
syntax. They lack a simple property I call human
friendliness. A human friendly language has the property
that syntactic constructs are different enough from one
another that a simple visual inspection is all that is
needed to locate the beginning of an expression when one
is at the end of an expression.
As you can guess, Lisp is a very human unfriendly
language. Because of this fact, an experienced Lisp user
realizes that it is virtually impossible to write Lisp
programs of any size without substantial mechanical
assistance.
--- Andrew Koenig
Or, something I'm sure would be controversial: > 08. Syntax highlighting of code
Just say no.You could also interpret those preferences as controversial if, for example, syntax highlighting or color themes had a body of empirical evidence showing they aided productivity, and Russ Cox fell on the wrong side of the evidence.
Programmers feel very strongly about these things. I consider them mostly cosmetic. I don't use Acme, but in vim I have syntax highlighting and color schemes turned off, always use tabs for indenting, don't use code folding, rarely use auto-completion. Other programmers I know have different preferences. No controversy because neither of us can base our opinions on evidence.
We have controversy where we don't have facts, or where they are willfully rejected.
I would venture that Russ Cox and Rob Pike (who dismissed syntax highlighting more strongly than Cox, calling it "juvenile") have demonstrated productivity far greater than the majority of programmers. I believe Linux Torvalds uses uemacs, which doesn't have syntax coloring. What other productive programmers use, or don't use, may not persuade anyone but I think such examples show that the relationship between syntax highlighting and actual programmer productivity may be weak, or more subjective than some people think.
Would you say that this is also of no help, and prefer to turn it off?
This prevents you from doing a round trip through the compiler for many an error.
(Or, in some systems, it actually doesn't; the compiler may be involved in determining syntax highlighting and pinpointing the first error, but it's done in real time under the hood as you type. You're not running a build and finding about the error in a log message.)
Showing possible syntax errors in the code during editing doesn't require full syntax coloring. I understand that syntax coloring can also show syntax errors, but the two features are independent, and you can flag errors without turning the editor window into a kaleidoscope.
"Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program." -- Richard Stallman
Good luck with secretaries extending an editor using C++
Expressions in Lisp often end together. This is extremely unimportant, so we lump these ends together ))))))).
When expressions don't end together ))) stuff))), we use line breaks and indentation.
(this (is one
unit))
more stuff
(this (is (another
unit))
inner stuff
ends here)
more stuff
In the typical style of C like languages and other Algols, even statements that end together have their end markers separated out: end if
end while
end for
}
}
}
Sometimes comments are added }
}
} // for
Some coding stylews in C likes call for opening braces being vertically aligned with closing ones, rather than "cuddled" into the same line: if (...)
{
for (...)
{
}
}
All these practices indicate that maybe it's not so easy to find the beginning of a construct from the end in the languages that Koenig has dedicated himself to.