Xah Emacs Tutorial Criticisms: Emacs Lisp, Coding Style, Language Idioms, Controversy
sometimes i see criticisms on my emacs lisp tutorial. They point out that i'm not following convention. Most of the time, they just pointing out that my trailing parenthesis are not tugged into a single line (aka hanging parenthesis). Other common complaints is that my code is not idiomatic.
I appreciate criticisms, and welcome negative ones. Though, coding style and idiomatic programing are two aspects of programing i've put a lot thought in, more so than most programers.
- Coding style conventions are mostly harmful. The language's syntax and semantics should naturally enforce it.
- Idiomatic programing are harmful. It should be ban'd, except the type of idiom that has a non-trivial effect on algorithm or computational complexity.
here's some excerpt from discussion on [Google Plus thread
+Nick Alcock +Elias Mårtenson, i think the concept of code formatting style is harmful, for a lang with regular syntax, such as lisp, xml, Mathematica. In the latter two, one don't hear much about code formatting style, yet we see it heavily in lisp. That impedes awareness and real progress of automatic formatter.
See: Programing: Lisp: Automatic Code Formatting, Lint, Auto Indentation.
idioms are not that good to have in a lang. Similar in natural languages. They are basically quirks, irregularities, ad hoc, and hard to learn.
i think there's one type of idiom that's very good, that is, the type that effects algorithmic complexity (due to the lang's quirks and implementation detail). For example, python string are not mutable, so when one needs to append string in a loop, one use a list instead, then convert it to string. [see Python: a Technique to Append String in a Loop]
See: Programing: Why Idiomatic Programing Are Bad. See also the article by Zed linked at bottom. He goes over Ruby.
for my tutorial, sometimes am sloppy, and the code is a learning process as well, and sometimes there's pedagogical constraints. I do appreciate comments, as well as criticisms. Thanks.
+Elias Mårtenson, yes, what you said is true. I agree. I've been there.
though, we can look deeper in this.
Idioms, just as in natural languages, are unavoidable. They develop naturally too. However, too often, we see the elitist type of programers, who insist on idioms. It's more about cult formation. This point Zed covered well. Often, these elitist programers do not see the nature of idioms, and kept on spreading something that's more coolness and fashion than real substance. Perl community is the best example of this.
what i wanted to point out in that essay, is a illustration that idioms are actually just quirks. Lang X speaker may not notice it, and thinks everyone must use it, but to all other speakers who are outsiders of X, they simply see it as full quirks and special cases, something that is not appetizing.
Again, idioms are not avoidable, but the zest for idioms, as typically seen in programing communities, are over-zealous.
as i mentioned, there is one type of idiom i can think of, that we should encourage their use. Namely, the type that makes a difference in algorithmic complexity. And the python immutable string case i posted before is a good example.
meanwhile, what i wanted to impart, is that as programers or languages designers, idioms should be actively avoided.
on elisp, i disagree somewhat with your stance, or in general with established norm. Note that, most conventions in programing, are simply habit, historical baggage. This includes formatting lines no longer than 80 chars.
the lisp convention of parenthesis placement, is also a problem. Because, such convention lessen awareness of automated formatting. Thus, we have thousands of style guides and people gets drawn in around it, arguing about it, while, a automated system doesn't come to mind. This is especially ironic for lang with regular syntax such as lisp. Meanwhile, in XML, Mathematica communities, they almost never talk about code formatting, because it's automatic and transparent to the user. This should happen to lisp.
why should we, spend the time to educate each other about formatting, and spend the thousands hours semi-manually do so perhaps with help of paredit, when we could have it to automatically and transparently?
I usually do tug in my trailing parenthesis, but i just don't take the extra mile to cater it, because i consider it harmful to spread this lisp lore.
some of these points i've been arguing with lispers in comp.lang.lisp for a decade. I have also written tens of articles on my site. It's a issue i'm afraid that cannot come to agreement, unless someday science based study on this became common. So, what you and many lisper's criticism of my elisp code i'm fully aware. Some are due to my code quality, but many are that way intentionally. We should throw out old precepts based on scientific validity. Newer generation usually adopt new style, without even thinking about it. (Clojure comes to mind, many Common Lispers just don't like Clojure or anything that's not Scheme or Common Lisp. It's more about habit than anything.)
in summary, idioms are necessary, but by itself is not a good thing. Good idioms are those have computational effect on the code's performance.
code formatting, should be entirely eliminated. And this effects the direction of language design too. Language's syntax, its chars, should have semantic markup builtin. This is so with Lisp and Mathematica and XML (in Lisp and Mathematica, the bracket characters carry with it a semantic info of code unit. In XML, it's a specific syntactical pattern)). For these languages, editors should be able to do it in real time, automatically, and transparent to user.
- rms Stole Emacs from Gosling
- 2020 Bozhidar Batsov RuboCop Incident
- 2019 rms Resigned from FSF
- 2019 rms at Microsoft
- 2018 rms is a Tyrant
- 2018 Linus: Respect is Earned Not Given
- 2017 rms Pushing for GPL3, Kicked Out Free Software from Free Software Platform
- 2016 Elisp Doc String Curly Quote Controversy
- 2016 rms Removes Color Emoji on Mac Emacs
- 2017 Language Server Protocol (LSP) Kills Elisp
- 2016 Ugly Redisplay Internals Hack
- 2015 rms: What's magit?
- 2013 Rants on Emacs Visual Lines by Don Hopkins, Mark Crispin
- 2013 rms Wants Emacs to be Word Processor
- 2013 How Much Donation FSF Get
- 2012 rms on Open Source
- 2012 Daniel Weinreb Died
- 2011 rms Speech Requirement
- 2007 Daniel Weinreb Rebuttal to rms's Lie
- Young rms on Software Freedom
The Emacs Cult
- 2010 Emacs Dev Inefficiency
- Emacs Dev Inefficiency, Emacs Web 2?
- 2001 Emacs and XEmacs Schism
- 2007 Emacs vs XEmacs
- 2008 Problems of Emacswiki
- 2011 Emacs vs Windows Notepad
- 2011 Emacs Undo Cult Problem
- 2010 Have You Read Emacs Manual