硬包装线的危害 [英] The Harm of hard-wrapping Lines
问题描述
硬包装线的危害
20050222
计算行业人士：
请按照这里的概述，推断对他们这个他妈的unix-love fuckheads的截断线业务的揭穿：
http://xahlee.org/UnixResource_dir/w...cate_line.html
如果这个神话 - 揭穿被广泛了解，就不会有更多的线路截断业务。
emacs社区一直是一个想法社区而不是
unix罪犯。然而，根据历史事件，GNU的电子邮件
不是Unix本质上是一个unixes的程序，所以不可避免的是它必须处理并继承一些病unix的屎，如果没有，
但是要实用。
然而，截至今天，emacs并没有真正的理由/>
箭头向下行为取决于硬编码的换行。我希望
能够修复下一个emacs版本的向下箭头行为。 （并且
可选择作为EOL移动的另一种模式。）
这种改变的原因很简单。对于那些习惯于硬包裹的b
，这将没有任何区别。但是，对于那些
的线路在逻辑位置返回，这将是一个
的改进。 （这是直观的方式，并且所有非极客编辑器
都是这样的，即使是大多数编辑器或设计用于编程的IDE。）
需要这种变化很重要。通过EOL char的当前行为下行箭头，它阻止逻辑断行，
鼓励硬编码断线，并产生巨大的和/>
因此导致广泛传播的问题（在上面给出的
url中部分详细说明）：在线发布的节目被打破，谁说什么
引用系统是一个混乱的过程和理解，并且不必要的b / b
复杂的程序，处理和重新处理硬包裹的
线...而且它也是坏的种子创造一代人的概念
基于强硬换行的命令式语言（例如很多
语言的行注释;并且不能嵌套），以及误导
以及通过
EOL计数在IT中调整软件的有害习惯。 （这些都是功能性编程的障碍。）
此外，在编程中有大量章节和精力花在
上叫什么编码风格，指的是什么时候的小问题以及如何按回报所以线条全部以一些统一的方式j / b
方式。这种无处不在的编码风格。活动是由
硬包装思维习惯所帮助的，它首先创造了这些以EOL为中心的语言
语法。
（
当用编程语言编码时，为了显示格式化，程序员不应该为了返回而返回
。语言是
语法和编辑器应该能够通过简单的解析在
飞行中很好地显示代码。今天代码中约有90％的EOL在那里
$ b由程序员手动输入$ b，不提供任何其他功能
比硬编码漂亮打印。
（反对有时故意返回以表达观点在
代码中，或者作为逻辑中断，或者强调一个部分。）
由于这些以EOL为中心的语言是注意力/>
按行放置代码，而不是功能或逻辑
单位。例如，注释往往基于鳕鱼行e，因为
与功能单元或算法相反。
IF子句中的布尔子句每个跨越一行，而不是作为一个
谓词单元在一起。
（这扼杀了新的开发语言中的谓语单元
语法或语义）
IF块几乎总是跨越多行，而不是
连贯单位的想法a ??如果PREDICATE做BLOCKa ??。
（这样的以EOL为中心的代码往往会产生诸如
之类的做法，并且在代码内部和那里设置全局变量
块）。
临时变量本身占据一条线，反对在其功能单元内不明显地隐藏
等等等等等。
（一个不以EOL为中心的语言的例子是Mathematica，
，它显示代码有合理的理由，全部完成
自动幕后，就像一个文字处理器是写b
。
（并且语言也出现在显示排版垫上关于
飞行的hematics。）
类似的里程碑是LISP语言，但他们没有推动这个想法
进一步。
（也就是说，在LISP社区，他们有时仍然会这样做，并且b $ b谈论手动回复的小问题，甚至他们的
语言可能不受硬包装问题的影响。
）
）
）
我希望以上是关于硬包装和
线截断业务的一些说明。请传播信息。
---------
此电子邮件归档于
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
Xah
xa*@xahlee.org
a ?? http://xahlee.org/
The Harm of hard-wrapping Lines
20050222
Computing Folks of the industry:
please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
http://xahlee.org/UnixResource_dir/w...cate_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 don''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 an
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 (e.g. many
languages''s line comment; and cannot be nested), and the misleading
and harmful habituation in IT of sizing software by
EOL-counting. (both of these are hindrances to 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, the programer 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 simple parsing. Some 90% 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 consequence 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 algorithm. 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
coherent unit of a??if PREDICATE do BLOCKa??.
(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.
(and the language happens also to display typeset mathematics on the
fly.)
Similar mileu 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, even their
languages are potentially immune to the hard-wrap problems.
)
)
)
I hope the above is some elucidation on the hard-wrap and
line-truncation business. Please spread the info.
---------
This email is archived at
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
Xah
xa*@xahlee.org
a?? http://xahlee.org/
推荐答案
Xah Lee写道：
Xah Lee wrote:
硬包装线的危害
20050222
计算人员业界人士：
请点击这个他妈的unix-love fuckheads的截断线业务的揭穿，如下所示：
http://xahlee.org/UnixResource_dir/w...cate_line.html
我发现*非常有趣的是文档格式化....使用
最多80列:-)
What I find *really* funny is that document is formatted.... using
at most 80 columns :-)
" Xah Lee" < xa*@xahlee.org>写道：
"Xah Lee" <xa*@xahlee.org> writes:
硬包装线的危害
20050222
计算行业人士：
请传播对他们这个他妈的unix-love fuckheads的截断线业务的揭穿，如下所示：
The Harm of hard-wrapping Lines
20050222
Computing Folks of the industry:
please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
[snip]
感谢您将辱骂性语言放在帖子顶部附近，
所以我们马上就知道忽略了您可能要说的其他任何内容。
注意跟进。
-
Keith Thompson（The_Other_Keith） ks *** @ mib.org < http://www.ghoti.net/~kst>
圣地亚哥超级计算机中心< *> < http://users.sdsc.edu/~kst>
我们必须做点什么。这是事情。因此，我们必须这样做。
[snip]
Thank you for putting the abusive language near the top of your post,
so we know right away to ignore anything else you might have to say.
Note followups.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson< ks *** @ mib.org>写道：
Keith Thompson <ks***@mib.org> writes:
" Xah Lee" < xa*@xahlee.org>写道：
"Xah Lee" <xa*@xahlee.org> writes:
硬包装线的危害
20050222
计算行业人士：
请传播他妈的unix-love fuckheads的截断线业务的揭穿，如下所示：
The Harm of hard-wrapping Lines
20050222
Computing Folks of the industry:
please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
[snip]
感谢您将辱骂语言放在附近你的帖子的顶部，
所以我们立即知道你可能不得不说的其他任何事情。
注意后续内容。
[snip]
Thank you for putting the abusive language near the top of your post,
so we know right away to ignore anything else you might have to say.
Note followups.
你甚至不必阅读消息的顶部;
''来自：Xah Leeh''足以将消息标记为可忽略。
< br $> b $ b -
Raymond Wiker邮件： Ra *** ********@fast.no
高级软件工程师网址： http://www.fast.no/
Fast Search&转机ASA电话：+47 23 01 11 60
P.O.方框1677 Vika传真：+47 35 54 87 99
NO-0120挪威奥斯陆手机：+47 48 01 11 60
You don''t even have to read the top of the message;
''From: "Xah Leeh"'' is enough to flag the message as ignorable.
--
Raymond Wiker Mail: Ra***********@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
这篇关于硬包装线的危害的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
