A lot of bold comments in this response. For example:
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
You can interpret the opinions about syntax highlighting, color schemes, tabs vs. spaces, etc. as controversial, if you think one programmer's preferences amount to a dictate everyone must follow. Otherwise they reflect nothing more than personal preferences.
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.
If credible, scientific evidence shows someone's preferences as being the wrong, suboptimal ones, then in fact that makes them noncontroversial; I'm not going to maintain the controversy by arguing with that person beyond conveying to them the existence of the research.
We have controversy where we don't have facts, or where they are willfully rejected.
What one person considers optimal may not work for someone else. Optimal in the context of programmer productivity is a subjective measure or opinion, not a quality always improved for everyone by something like syntax highlighting.
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.
Syntax highlighting can not only colorize program tokens, but it can flag syntax errors. The first character of bad syntax is shown in some loud color, like black text on red background.
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.)
I would say that syntax highlighting, including flagging syntax errors in real time, is not useful enough to me to incur the overhead of linting the code in real-time, these days often requiring a language server. I have my editor set to lint the code on save. Other programmers may find real-time syntax checking useful.
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.
Andrew Koenig is someone who invested a big chunk of his life into C++ and stuff of the same ilk. There is a psychology that people invested in things have to defend their sunk cost against alternatives, using false arguments.
"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.
7 comments
[ 3.6 ms ] story [ 32.1 ms ] threadYou 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.
In the typical style of C like languages and other Algols, even statements that end together have their end markers separated out: Sometimes comments are added Some coding stylews in C likes call for opening braces being vertically aligned with closing ones, rather than "cuddled" into the same line: 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.