Programing: the Harm of Hard-wrapping Lines

By Xah Lee. Date:
Computing Folks of the industry:

Please spread the debunking of the truncating line business of the
faaking unix-loving faakheads, as outlines here:
http://xahlee.org/UnixResource_dir/writ/truncate_line.html

If this myth-debunking is known widely enough, there wouldn't be any
more line truncating business.

Emacs community has always been a thinking community as opposed to the
unix criminals. However by historical happenstance, the emacs of GNU's
Not Unix is essentially a program for unixes, so unavoidable it has to
deal with and inherit some of the ill shits of unix, if for nothing
but to be practical.

However, as of today, emacs doesn't really have reason to have
arrow-down behavior to be dependent on the hard-coded line wraps. I
want the next emacs version's down-arrow behavior to be fixed. (and
optionally as another mode to move by EOL.)

The reason for this change is easy. For those habituated with hard
wrapped lines, this would cause no difference. However, for those who
have lines that return at logical places, this would be a
improvement. (This is the intuitive way, and all non-geek editors
behave this way, even most editors or IDEs designed for programing.)

The need in this change is significant. By the current behavior of
down-arrow by EOL char, it discourages logical line breaking,
encourages hard-coded line breaking, and engenders the huge and
wide-spread problems as a consequence (as partially detailed in the
url given above): Programs posted online are broken, the who-said-what
quoting systems are a mess to process and comprehend, and needless
complex programs that processes and re-process the hard-wrapped
lines… And also it seeds the bad notions by creation of a generation
of imperative languages based on hard-line wraps (For example, many
language's line comment; and cannot be nested), and the misleading
and harmful habituation in Info Tech of sizing software by
EOL-counting. (both of these are hindrances to the prosperity of
functional programing.)

Further, in programing there's large chapters and energy spent on
what's called “coding style”, which refers to the petty issue of when
and how to press a return so the lines all jag in some uniform
way. This ubiquitous “coding style” activity is helped by the
hard-wrap habit of thinking, which created these EOL-centric language
syntaxes in the first place.

(When coding in a programing language, programers should never have to
enter returns for the sake of display-formatting. The language's
syntax and the editor should be able to display the code well on the
fly by a brainless parsing. Some 70% of EOL in codes today are there
manually entered by programer that does not serve any function other
than hard-coded pretty-printing.
 (as oppose to the sometimes a intentional return to make a point in
  the code, either as logical break, or emphasizing a section.)

And as a psychological and practical effects of these EOL-centric
languages is that attention are put on code by the lines, instead of
functional or logical units. For example, comments tends to be based
on lines of code, as opposed to on a functional unit or algorithmic
block. Boolean clauses inside IF clause each span a line, as opposed
to being together as a predicate unit.
 (which smother new developments of such predicate unit in language
  syntax or semantics)
IF blocks almost always span multiple lines, as opposed to the idea of
a single coherent unit of “if PREDICATE do BLOCK”.
 (and such EOL-centric code tends to engender practices such as
  calling and setting global variables here and there inside code
  blocks).
 Temporary variables occupy a line by themselves, as oppose to tucked
 inconspicuously inside its functional unit… etc and so on.

 (a example of a language that is not EOL-centric is Mathematica,
  which displays the code with sensible justification, all done
  automatically behind the scenes, just as a word processor is to
  writing.
 
  Similar milieu are in LISP languages, but they did not push this idea
  further.

  (That is to say, in LISP communities, they on occasion still do and
   talk about the petty issues of manual return-pressing for style, even
   their languages are potentially immune to the hard-wrap psychology.)
 )
)

I hope the above is some elucidation on the hard-wrap and
line-truncation business. Please spread the info.

The Harm of Manual Code Formatting

The following is a newsgroup post (edited), at comp.emacs, Xah Lee, 2007-10-11.

Someone wrote: «As for your code, I don't know why you are indenting interactive differently than the further forms;»

just sloppy… never really pay much attention about any so-called “coding style” (which often means the code formatting habit) Actually, i consider the rampant reference and concern about “coding style”, is a egregious faak up that can be attributed significantly to unix and C. The damage is far and wide, and also influenced negatively the lisp community.

In general, a programer should never have to press any returns, tabs, etc for the purpose of formatting his code. The editor should automatically wrap the code properly for display formatting. Many language, especially those turds from Unix/C's family {tcsh, Perl, C++, Java} has a syntax that this is impossible lex level. For Lisp the lang it is possible, but the thinking isn't there.

In Mathematica, i never have to spend time to fiddle with code formatting. (and when i do actually insert a indent or return, it is intentional and means something (usually indicating a break in {semantics, algorithm, code unit})) It's quite interesting to note that Mathematica not only formats codes automatically, but the fact that its code can contain 2-dimensional type-set mathematics (i.e. fractions, roots, powers, subs, parens, nesting, integrals, … variously combined.), and auto-render AND auto-wrap such type-set expressions on the fly. This feature, started in Mathematica version 3 about 1997, is today a decade-old technology. Most coders today (For example, Perl) are still arguing and wallowing about the fine points of how many spaces a indent should be. (not just inanely in newsgroups, but there are entire literature (For example, guides) devoted to it. Faaking morons and holes.)

As to lisp, it would be nice, if a programer can press a button in emacs, then the current code block would be formatted by a simple lexical scan. (similar to how fill-paragraph would work) I think it is relatively trivial to code his command, but to my surprise, it is not done. I was told by one Scheme expert Taylor R Campbell (aka Riastradh, author of paren-edit mode) that this is non-trivial, but i couldn't believe it and maybe he misunderstood what i wanted about this command.

In fact when i gained more lisp experience in ~2005, i was surprised to find that the concept of auto-wrap is basically non-existent among lispers. Lispers, to a lesser degree than C/Perl morons, still do discuss and debate now and then about formatting trivia.

For a outline of how this lisp formatter would work, see: A Simple Lisp Code Formatter.