为什么我们仍然使用平面文件进行编程？
为什么平面文本文件是用于表示源代码的最新技术？
当然 – 预处理器和编译器需要查看文件的平面文件表示，但这很容易创build。
在我看来，某种forms的XML或二进制数据可能代表很多很难跟踪的想法，否则。
例如，您可以将UML图embedded到您的代码中。 它们可以半自动生成，并由开发人员进行注释以突出devise的重要方面。 交互图特别是。 哎呀，embedded任何用户绘图可能会使事情更清楚。
另一个想法是将代码评论的评论embedded到代码中。
可以有各种各样的帮助，使合并多个分支更容易。
我热衷的事情不仅仅是跟踪代码覆盖范围，还要考虑自动化testing覆盖的代码部分。 困难的部分是跟踪代码，即使源被修改。 例如，将一个函数从一个文件移动到另一个文件，等等。这可以用GUID来完成，但是它们在文本文件中embedded正确性相当侵入。 在丰富的文件格式，他们可以自动和不显眼。
那么为什么没有IDE（就我所知，无论如何）允许您以这种方式使用代码？
编辑：在2009年10月7日。
在我的问题中，你们中的大多数人都挂上了“二进制”这个词。 我收回它。 图片XML，非常简单地标记你的代码。 在将它交给正常的预处理器或编译器之前，你将所有的XML标记去掉，然后传递源代码。 在这种forms下，您仍然可以对文件执行所有正常的操作：比较，合并，编辑，使用简单和最less的编辑器，将它们提供给数千个工具。 是的，差异，合并和编辑，直接与最小的XML标记，确实有点复杂。 但是我认为价值可能是巨大的。
如果存在尊重所有XML的IDE，则可以添加比我们今天所能做的更多的东西。
例如，您的DOxygen注释可能看起来像最终的DOxygen输出。
当有人想进行代码审查时，例如代码协作者，他们可以标记源代码。
XML甚至可以隐藏在评论之后。
// <comment author="mcruikshank" date="2009-10-07"> // Please refactor to Delegate. // </comment> 然后，如果你想使用vi或emacs，你可以跳过评论。
如果我想用一个最先进的编辑器，我可以看到十几种不同的有用的方法。
所以，这是我粗略的想法。 这不是你在屏幕上拖动图片的“积木”…我不是那么疯狂。 🙂
- 你可以区分它们
- 你可以合并它们
- 任何人都可以编辑它们
- 他们很简单，很容易处理
- 他们是成千上万的工具普遍访问
在我看来，任何可能的好处都被束缚在一个特定的工具上。
使用纯文本来源（这似乎是你正在讨论的，而不是平面文件本身），我可以粘贴到一个电子邮件大块，使用简单的版本控制系统（非常重要！），编写代码到堆栈溢出评论，在任何平台上使用千文本编辑器中的一个。
用一些代码的二进制表示，我需要使用专门的编辑器来查看或编辑它。 即使可以生成基于文本的表示forms，也不能轻易地将更改回滚到规范版本。
Smalltalk是一个基于图像的环境。 您不再使用磁盘上的文件中的代码。 您正在使用和修改运行时的实际对象。 它仍然是文本，但类不存储在人类可读的文件。 整个对象内存（图像）以二进制格式存储在文件中。
但是那些尝试使用Smalltalk的人最大的抱怨是因为它没有使用文件。 我们拥有的大多数基于文件的工具（vim，emacs，eclipse，vs.net，unix工具）都将不得不放弃，以支持smalltalk自己的工具。 并不是说小工具提供的工具比较低劣。 这是不同的。
为什么用文字书写文章？ 为什么用文字写法律文件？ 为什么写在文本中的幻想小说？ 因为文字是人们持续思考的唯一最好的forms。
文本是人们如何思考，expression，理解和坚持概念 – 以及它们的复杂性，层次结构和相互关系。
Lisp程序不是平面文件。 他们是数据结构的序列化。 这种代码作为数据是一个古老的想法，实际上是计算机科学中最伟大的想法之一。
<？xml version =“1.0”encoding =“UTF-8”？> <code>平面文件更容易阅读。</ code> </ xml>
原因如下：
-
人类可读。 这使得在文件和parsing方法中更容易发现错误。 也可以大声朗读。 这是你无法用XML获得的，而且可能会有所作为，特别是在客户支持方面。
-
保险免于过时。 只要正则expression式存在，就可以用几行代码编写一个很好的parsing器。
-
杠杆。 几乎所有的东西，从修订控制系统到编辑，过滤，可以检查，合并和操作平面文件。 合并XML可能是一团糟。
-
能够很容易地将它们与UNIX工具（如grep，cut或sed）集成。
这是一个很好的问题。 FWIW，我很想看到一个维基风格的代码pipe理工具。 每个function单元都有自己的维基页面。 构build工具将源代码从wiki中提取出来。 将有一个“讨论”页面链接到该页面，人们可以争论algorithm，API等。
哎呀，从现有的Wiki实现中揪出一个并不难。 任何接受者…？
具有讽刺意味的是，编程结构正是使用你所描述的。
例如，SQL Server集成服务（包含通过将组件拖到可视化devise表面中的编码逻辑stream程）被保存为精确描述该后端的XML文件。
另一方面，SSIS很难源代码控制。 devise任何types的复杂逻辑也是相当困难的：如果需要多一点“控制”，则需要将VB.NET代码编写到组件中，这会将我们带回到我们开始的地方。
我想，作为一名编码员，你应该考虑一个事实，即对于一个问题的每个解决scheme都会有后果。 不是所有的东西都可以（也有人认为应该）用UML表示。 并不是所有的东西都可以用视觉performance 并不是所有的东西都可以被简化成具有一致的二进制文件表示。
话虽如此，但我认为将代码降级为二进制格式（其中大部分将趋于专有）的缺点远远超过了以纯文本格式进行编码的优势。
恕我直言，XML和二进制格式将是一个混乱，不会给任何显着的好处。
OTOH，一个相关的想法是写入一个数据库，可能每个logging有一个函数，或者是一个分层结构。 围绕此概念创build的IDE可以使导航源更加自然，并且更容易隐藏与您在给定时刻阅读的代码无关的任何内容。
人们试图创造一个超越平面文件的编辑环境，每个人都失败了。 我所看到的最接近的是Charles Simonyi的“故意编程”原型，但后来被降级为一个可视的DSL创build工具。
无论代码是如何在内存中存储或表示的，最终都必须以文本的forms呈现和修改（ 不需要格式变化 ），因为这是我们知道expression大多数抽象概念所需的最简单的方法通过编程解决问题。
对于平面文件，你可以免费得到这个，任何普通的旧文本编辑器（具有正确的字符编码支持）都可以工作。
史蒂夫·麦康奈尔（Steve McConnell）一如既往地说：你为其他程序员（包括你自己）编写程序，而不是为了电脑。
也就是说，Microsoft Visual Studio必须在内部pipe理您以非常结构化的格式编写的代码，否则您将无法像“查找所有引用”那样执行此类操作，或者轻松地重命名或重新分配variables和方法。 我会感兴趣的，如果有人有如何工作的链接。
实际上，大约十年前，查尔斯·西蒙尼（Charles Simonyi）早期的有意编程原型试图超越平面文件，变成可以以不同方式可视化的代码的树形表示。 从理论上说，领域专家，项目经理和软件工程师都可以以对他们有用的方式看到（并拼凑）应用程序代码，产品可以build立在声明式“意图”层次上，级别代码只根据需要。
ETA（问题中的每个请求）在微软研究网站上有一篇他早期的论文的副本。 不幸的是，自从西蒙尼在几年前离开MS开始一家独立的公司之后，我不认为原型还是可以下载的。 当我在微软时，我看到了一些演示，但是我不确定他早期的原型有多广泛的分布。
他的公司IntentSoft对于他们计划投放市场的东西还是有点安静的，但是一些早期的MSR产品是非常有趣的。
存储模型是一些二进制格式，但我不确定在MSR项目中披露了多less这些细节，而且我相信自早期实施以来，有些事情已经发生了变化。
Labview和Simulink是两个graphics编程环境。 它们在各自的领域都很受欢迎（分别来自PC的硬件和build模控制系统），但在这些领域之外并没有太多用处。 我曾经和两个大粉丝一起工作过，但从来没有亲自过。
你提到我们应该使用“某种forms的XML”？ 你认为XHTML和XAML是什么？
另外XML还只是一个平面文件。
我想，老习惯很难死。
直到最近，还没有很多高质量，高性能，广泛可用的库来存储结构化数据。 而且即使在今天，我也不会把XML放在这个类别中 – 太冗长，太密集而无法处理，太挑剔。
现在，我最喜欢使用的数据不需要是可读的SQLite，并且可以创build数据库。 将全function的SQL数据库embedded到任何应用程序中是非常容易的…对于C，Perl，Python，PHP等有绑定关系，而且它是开源的，而且非常快速，可靠和轻量级。
我<3 SQLite。
为什么文本文件的规则？ 因为麦克罗伊的考验。 将一个程序的输出作为另一个程序的源代码是可接受的，而文本文件是最简单的工作是非常重要的。
有人试过Mathematica ？
上面的图片来自旧版本，但这是最好的谷歌可以给我。
无论如何…比较第一个等式Math.Integrate（1 /（Math.Pow（“x”，3）-1），“x”）就像你将不得不写，如果你在大多数情况下用纯文本编码通用语言。 mathexpression式更容易阅读，这仍然是一个非常小的方程。
是的，如果你愿意，你可以input和复制粘贴代码作为纯文本。
将其看作下一代语法突出显示 。 我敢打赌，除了math以外，还有很多其他的东西可以从这种performance中获益。
为什么纯文本是国王，这是相当明显的。 但同样明显的是为什么一个结构化的格式会更好。
只是一个例子：如果你重命名一个方法，你的差异/合并/源代码控制工具将能够告诉只有一件事情已经改变。 我们今天使用的工具将显示一个长长的变化列表，一个用于调用或声明方法的地方和文件。
（顺便说一下，这个post并没有回答你可能已经注意到的问题）
我们看到DSL的趋势是在阅读您的问题时首先想到的。 问题是模型（如UML）和实现之间不存在一对一的关系。 其中微软正在努力实现这一目标，以便您可以将应用程序创build为类似于UML的应用程序，然后生成代码。 而重要的是 – 当你select改变你的代码时，模型会再次反映出来。
Windows Workflow Foundation是一个很好的例子。 因为在后台有平面文件和/或XML，但通常最终会在编排工具中定义业务逻辑。 这真是太酷了！
我们需要更多的“软件工厂”的思想，并将在未来看到更丰富的IDE体验，但只要计算机运行在零和一个，平面文本文件可能和（可能）将永远是一个中间阶段。 如前所述，已经有几个人，简单的文本文件非常灵活。
我渴望同样的事情，正如答案中所描述的那样： 你想要什么工具/应用程序/你想要什么？
虽然很容易想象得到很多好处，但我认为必须解决的最大障碍是没有人提出了一个可行的select。
当人们想到将文档存储为文本的替代方法时，他们似乎经常会立即想到graphics化表示（我在这里指的是可用的商业产品 – 例如HP-vee）。 而且，如果我们看看FPGAdevise人员的经验，我们发现编程（专有）graphics是行不通的，因此像Verilog和VHDL这样的语言。
但是，我并不认为源码的存储必须首先与其写作方法相联系。 来源的来源可以在很大程度上作为文本 – 这意味着复制/粘贴的问题仍然可以实现。 但是我也看到，通过允许合并和回滚在标记化元源的基础上完成，我们可以实现更精确和更强大的操作工具。
Visual FoxPro使用dbf表结构来存储表单，报表，类库等的代码和元数据。这些是二进制文件。 它也存储在实际文本文件prg文件中的代码…
我看到的唯一好处是能够使用内置的VFP数据语言对这些文件执行代码search…除了这是一个责任imo。 至less每几个月一次，这些文件中的一个将无缘无故地损坏。 与源代码控制整合，差异也非常痛苦。 有这个解决方法，但涉及将文件临时转换为文本！
有关废除传统文本编程的语言示例，请参阅Lava语言 。
我刚刚发现的另一件漂亮的事情是subtext2 （ video演示 ）。
程序的代码定义了用xml或二进制格式创build的结构。 你的编程语言是一个比XML或Binary表示更直接的程序结构表示。 你有没有注意到当你给文档的结构时，单词对你的误操作。 WordPerfect至less会“泄露代码”，让你看到什么在你的文件下。 平面文件为您的程序做同样的事情。
整洁的想法。 我自己想知道更小的规模，为什么IDE X不能生成这个或那个。
我不知道我是否能够像程序员一样能够开发出像您所谈论的或我正在思考的那样酷和复杂的东西，但我会对尝试感兴趣。
也许从.NET，Eclipse，Netbeans等一些插件开始？ 炫耀可以做什么，开始编码的新趋势。
我认为这另一个方面是代码是重要的。 这是将要执行的。 例如，在你的UML例子中，我认为不是让你的“源代码块”中包含的UML（大概是在一些编辑器中创build的，与“代码”没有直接关系）几乎是无用的。 更好的做法是让UML直接从你的代码中生成，所以它描述了代码作为理解代码的工具的确切状态，而不是提醒代码应该是什么。
自动化文档工具我们已经这么做了好几年了。 尽pipe实际编程人员在代码中生成的注释可能会与代码不同步，但像JavaDoc之类的工具忠实地代表了对象上的方法，返回types，参数等等。它们代表它们实际存在，而不是某些来自无尽的devise会议的神器。
在我看来，如果你可以随意添加随机文物到一些“源头”，这些文件可能会过时，而且不是很有用。 如果您可以直接从代码生成这样的工件，那么让您的构build过程这样做的小小的努力比以前提到的远离纯文本源文件的陷阱要好得多。
与此相关的是， 为什么要使用纯文本的UML工具 （ UMLGraph ），为什么要纯文本的源文件似乎也同样适用。
这可能不是完全回答你的问题，但这里是一个编辑器允许更高版本的代码： http : //webpages.charter.net/edreamleo/front.html
我认为为什么在开发中使用文本文件的原因是它们对各种开发工具是普遍的。 你可以在里面查看，甚至用一个简单的文本编辑器来修复一些错误（你不能用二进制文件来完成，因为你永远不知道任何修复会如何破坏其他数据）。 但是，这并不意味着文本文件是最适合所有这些用途的。
当然，你可以区分和合并它们。 但是，这并不意味着diff / merge工具可以理解由这个文本文件编码的数据的独特结构。 你可以做diff / merge，但是（尤其是在XML文件中看到的）diff工具不会正确地显示你的差异，也就是说，它会告诉你文件不同的地方以及工具“认为”是相同的。 但它不会告诉你在XML文件的结构上的差异 – 它只会匹配看起来相同的行。
无论我们使用的是二进制文件还是文本文件，diff / merge工具总是处理这个文件所代表的数据结构，而不是线和字符。 例如，对于C ++或Java文件，报告某个标识符更改了它的名称，则报告某个节被另外的if（）{}包围，但另一方面忽略缩进或EOL字符中的更改。 最好的方法是将文件读入内部结构并使用特定的格式规则进行转储。 这种方式将通过内部结构进行差异化，合并结果将从合并的内部结构生成。
现代节目由扁平的部分组成，但它们是平坦的吗？ 有使用，包括，和对象库等。一个普通的函数调用是偷看到一个不同的地方。 逻辑不平坦，由于有多个线程等
我有相同的愿景！ 我真的希望这会存在。
你可能想看一下Sun的研究语言Fortress。 它对源代码中的公式有特别的支持。 以下引用来自维基百科
Fortress从一开始就devise了多个语法样式表。 源代码可以呈现为ASCII文本，以Unicode格式，或作为一个漂亮的图像。 这将允许在渲染的输出中支持math符号和其他符号，以便于阅读。
文本作为源的持久性的主要原因是缺lesspowertools，如版本控制，非文本date。 这是基于我使用Smalltalk的经验，在这里，纯字节码始终保持在核心转储中。 在非文本系统中，使用当今的工具，团队开发是一场噩梦。
