为什么我们仍然使用平面文件进行编程？
为什么平面文本文件是表示源代码的最先进技术？
当然 - 预处理器和编译器需要查看文件的平面文件表示，但这很容易创建。
在我看来，某种形式的 XML 或二进制数据可以代表许多很难跟踪的想法，否则的话。
例如，您可以将 UML 图直接嵌入到您的代码中。 它们可以半自动生成，并由开发人员进行注释以突出设计的重要方面。 特别是交互图。 哎呀，嵌入任何用户绘图可能会让事情变得更加清晰。
另一个想法是将代码审查的注释直接嵌入到代码中。
可能有各种辅助工具可以使合并多个分支变得更容易。
我热衷的事情不仅是跟踪代码覆盖率，而且还查看自动化测试覆盖的代码部分。 困难的部分是跟踪该代码，即使源代码已修改。 例如，将函数从一个文件移动到另一个文件等。这可以使用 GUID 来完成，但将它们直接嵌入到文本文件中相当具有侵入性。 在丰富的文件格式中，它们可以是自动且不引人注目的。
那么为什么没有 IDE（至少据我所知）允许您以这种方式处理代码呢？
编辑：2009 年 10 月 7 日。
你们中的大多数人都对我的问题中的“二进制”一词非常着迷。 我收回它。 图片 XML，非常简单地标记您的代码。 在将其交给普通预处理器或编译器之前，您将删除所有 XML 标记，并仅传递源代码。 在这种形式下，您仍然可以对文件执行所有常规操作：比较、合并、编辑、在简单且最小的编辑器中使用、将它们输入到数千个工具中。 是的，直接使用最少的 XML 标记进行比较、合并和编辑，确实变得有点复杂。 但我认为其价值可能是巨大的。
如果存在一个尊重所有 XML 的 IDE，您可以添加比我们今天能做的更多的东西。
例如，您的 DOxygen 注释实际上看起来就像最终的 DOxygen 输出。
当有人想要进行代码审查时，例如 Code Collaborator，他们可以就地标记源代码。
XML 甚至可以隐藏在注释后面。
// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>
然后如果你想使用 vi 或 emacs，你可以跳过注释。
如果我想使用最先进的编辑器，我可以通过大约十几种不同的有用方式来了解这一点。
这就是我的粗略想法。 它不是您在屏幕上拖动的图片的“构建块”……我没那么疯狂。 :)
Why are flat text files the state of the art for representing source code?
Sure - the preprocessor and compiler need to see a flat file representation of the file, but that's easily created.
It seems to me that some form of XML or binary data could represent lots of ideas that are very difficult to track, otherwise.
For instance, you could embed UML diagrams right into your code. They could be generated semi-automatically, and annotated by the developers to highlight important aspects of the design. Interaction diagrams in particular. Heck, embedding any user drawing might make things more clear.
Another idea is to embed comments from code reviews right into the code.
There could be all sorts of aids to make merging multiple branches easier.
Something I'm passionate about is not just tracking code coverage, but also looking at the parts of code covered by an automated test. The hard part is keeping track of that code, even as the source is modified. For instance, moving a function from one file to another, etc. This can be done with GUIDs, but they're rather intrusive to embed right in the text file. In a rich file format, they could be automatic and unobtrusive.
So why are there no IDEs (to my knowledge, anyway) which allow you to work with code in this way?
EDIT: On October 7th, 2009.
Most of you got very hung up on the word "binary" in my question. I retract it. Picture XML, very minimally marking up your code. The instant before you hand it to your normal preprocessor or compiler, you strip out all of the XML markup, and pass on just the source code. In this form, you could still do all of the normal things to the file: diff, merge, edit, work with in a simple and minimal editor, feed them into thousands of tools. Yes, the diff, merge, and edit, directly with the minimal XML markup, does get a tad more complicated. But I think the value could be enormous.
If an IDE existed which respected all of the XML, you could add so much more than what we can do today.
For instance, your DOxygen comments could actually look like the final DOxygen output.
When someone wanted to do a code review, like Code Collaborator, they could mark up the source code, in place.
The XML could even be hidden behind comments.
// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>
And then if you want to use vi or emacs, you can just skip over the comments.
If I want to use a state-of-the-art editor, I can see that in about a dozen different helpful ways.
So, that's my rough idea. It's not "building blocks" of pictures that you drag on the screen... I'm not that nuts. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（30）
在我看来，任何可能的好处都会被特定工具的束缚所抵消。
使用纯文本源（这似乎就是您正在讨论的内容，而不是平面文件本身），我可以将块粘贴到电子邮件中，使用简单的版本控制系统（非常重要！），编写将代码添加到 Stack Overflow 上的注释中，在任意数量的平台上使用一千个文本编辑器之一，等等。
对于代码的一些二进制表示形式，我需要使用专门的编辑器来查看或编辑它。 即使可以生成基于文本的表示，您也无法轻松地将更改回滚到规范版本中。
In my opinion, any possible benefits are outweighed by being tied to a particular tool.
With plain-text source (that seems to be what you're discussing, rather than flat files per se) I can paste chunks into an email, use simple version control systems (very important!), write code into comments on Stack Overflow, use one of a thousand text editors on any number of platforms, etc.
With some binary representation of code, I need to use a specialized editor to view or edit it. Even if a text-based representation can be produced, you can't trivially roll back changes into the canonical version.
Smalltalk 是一个基于图像的环境。 您不再使用磁盘上文件中的代码。 您正在运行时处理和修改真实对象。 它仍然是文本，但类不存储在人类可读的文件中。 相反，整个对象内存（图像）以二进制格式存储在文件中。
但那些尝试 Smalltalk 的人最大的抱怨是因为它不使用文件。 我们拥有的大多数基于文件的工具（vim、emacs、eclipse、vs.net、unix 工具）将不得不放弃，转而使用 Smalltalk 自己的工具。 并不是说smalltalk中提供的工具较差。 只是不同而已。
Smalltalk is an image-based environment. You are no longer working with code in a file on disk. You are working with and modifying the real objects in runtime. It still is text but classes are not stored in human readable files. Instead the whole object memory (the image) is stored on a file in binary format.
But the biggest complaints of those trying out smalltalk is because it doesn't use files. Most of the file-based tools that we have (vim, emacs, eclipse, vs.net, unix tools) will have to be abandoned in favor of smalltalk's own tools. Not that the tools provided in smalltalk in inferior. It is just different.
论文为什么要用文字来写？ 法律文件为何采用文本形式？ 奇幻小说为什么要用文字来写？ 因为对于人们来说，文本是坚持其思想的最佳形式。
文本是人们思考、表示、理解和坚持概念及其复杂性、层次结构和相互关系的方式。
Why are essays written in text? Why are legal documents written in text? Why are fantasy novels written in text? Because text is the single best form - for people - of persisting their thoughts.
Text is how people think about, represent, understand, and persist concepts - and their complexities, hierarchies, and interrelationships.
Lisp 程序不是平面文件。 它们是数据结构的序列化。 这种“代码即数据”是一个古老的想法，实际上是计算机科学中最伟大的想法之一。
Lisp programs are not flat files. They are serialization of data structures. This code-as-data is an old idea, and actually one of the greatest idea in computer science.
平面文件更易于阅读。<?xml version="1.0" encoding="UTF-8"?><code>Flat files are easier to read.</code></xml>
这是一个好问题。 FWIW，我很想看到一个 Wiki 风格的代码管理工具。 每个功能单元都有自己的维基页面。 构建工具将 wiki 中的源代码汇集在一起。 将会有一个链接到该页面的“讨论”页面，人们可以在其中讨论算法、API 等。
哎呀，从预先存在的 Wiki 实现中破解一个并不难。 有接盘者吗...
It's a good question. FWIW, I'd love to see a Wiki-style code management tool. Each functional unit would have its own wiki page. The build tools pull together the source code out of the wiki. There would be a "discuss" page linked to that page, where people can argue about algorithms, APIs and such like.
Heck, it wouldn't be that hard to hack one up from a pre-existing Wiki implementation. Any takers...?
原因如下：
人类可读。 这使得更容易发现文件和解析方法中的错误。 也可以大声朗读。 这是 XML 无法实现的，但可能会有所作为，特别是在客户支持方面。
防止过时的保险。 只要正则表达式存在，就可以用几行代码编写一个相当好的解析器。
杠杆。 几乎所有的东西，从版本控制系统到编辑器再到过滤器，都可以检查、合并和操作平面文件。 合并 XML 可能会造成混乱。
能够轻松地将它们与 UNIX 工具集成，例如 grep、cut 或 sed。
Here's why:
Human readable. That makes a lot easier to spot a mistake, in both the file and the parsing method. Also can be read out loud. That's one that you just cannot get with XML, and might make a difference, specially in customer support.
Insurance against obsolescence. As long as regex exist, it is possible to write a pretty good parser in just a few lines of code.
Leverage. Almost everything there is, from revision control systems to editors to filter, can inspect, merge and operate on flat files. Merging XML can be a mess.
Ability to integrate them rather easily with UNIX tools, such as grep, cut or sed.
具有讽刺意味的是，有些编程结构正是使用您所描述的内容。
例如，SQL Server Integration Services 涉及通过将组件拖入可视化设计界面来编码逻辑流，并保存为精确描述后端的 XML 文件。
另一方面，SSIS 很难进行源代码控制。 在其中设计任何类型的复杂逻辑也相当困难：如果您需要更多一点“控制”，则需要将 VB.NET 代码编码到组件中，这使我们返回 回到我们开始的地方。
我想，作为一名编码员，您应该考虑这样一个事实：对于问题的每一个解决方案都会产生随之而来的后果。 并非所有内容都可以（有些人认为应该）用 UML 表示。 并非所有事物都可以直观地表示。 并非所有内容都可以简化到足以具有一致的二进制文件表示形式。
话虽这么说，我认为将代码降级为二进制格式（其中大多数也往往是专有的）的缺点远远超过了纯文本格式的优点。
Ironically there ARE programming constructs that use precisely what you describe.
For example, SQL Server Integration Services, which involve coding logic flow by dragging components into a visual design surface, are saved as XML files describing precisely that back end.
On the other hand SSIS is pretty difficult to source-control. It is also fairly difficult to design any sort of complex logic into it: if you need a little bit more "control", you'll need to code VB.NET code into the component, which brings us back to where we started.
I guess that, as a coder, you should consider the fact that for every solution to a problem there are consequences that follow. Not everything could (and some argue, should) be represented in UML. Not everything could be visually represented. Not everything could be simplified enough to have a consistent binary file representation.
That being said, I would posit that the disadvantages of relegating code to binary formats (most of which will also tend to be proprietary) far outweight the advantages of having them in plain text.
人们长期以来一直试图创建一个超越平面文件的编辑环境，但每个人都在某种程度上失败了。 我见过的最接近的是 Charles Simonyi 的意向编程的原型，但后来它被降级为可视化 DSL 创建工具。
无论代码在内存中如何存储或表示，最终它都必须能够以文本形式呈现和修改（无需更改格式），因为这是我们所知道的表达大多数内容的最简单方式通过编程解决问题所需的抽象概念。
对于平面文件，您可以免费获得此文件，并且任何纯旧文本编辑器（具有正确的字符编码支持）都可以工作。
People have tried for a long time to create an editing environment that goes beyond the flat file and everyone has failed to some extent. The closest I've seen was a prototype for Charles Simonyi's Intentional Programming but then that got downgraded to a visual DSL creation tool.
No matter how the code is stored or represented in memory, in the end it has to be presentable and modifiable as text (without the formatting changing on you) since that's the easiest way we know to express most of the abstract concepts that are needed for solving problems by programming.
With flat files you get this for free and any plain old text editor (with the correct character encoding support) will work.
恕我直言，XML 和二进制格式将是一团糟，并且不会带来任何显着的好处。
OTOH，一个相关的想法是写入数据库，可能每条记录一个函数，或者可能是分层结构。 围绕这个概念创建的 IDE 可以使源代码导航更加自然，并且更容易隐藏与您在给定时刻正在阅读的代码无关的任何内容。
IMHO, XML and binary formats would be a total mess and wouldn't give any significant benefit.
OTOH, a related idea would be to write into a database, maybe one function per record, or maybe a hierarchical structure. An IDE created around this concept could make navigating source more natural, and easier to hide anything not relevant to the code you're reading at a given moment.
史蒂夫·麦康奈尔一如既往地说得对——你为其他程序员（包括你自己）编写程序，而不是为计算机编写程序。
也就是说，Microsoft Visual Studio 必须在内部管理您以非常结构化的格式编写的代码，否则您将无法轻松执行“查找所有引用”或重命名或重构变量和方法等操作。 如果有人有关于其工作原理的链接，我会很感兴趣。
Steve McConnell has it right, as always - you write programs for other programmers (including yourself), not for computers.
That said, Microsoft Visual Studio must internally manage the code you write in a very structured format, or you wouldn't be able to do such things as "Find All References" or rename or re-factor variables and methods so readily. I'd be interested if anyone had links to how this works.
实际上，大约 10 年前，Charles Simonyi 的有意编程的早期原型试图超越平面文件，转变为可以以不同方式可视化的代码树表示形式。 理论上，领域专家、PM 和软件工程师都可以以对他们有用的方式查看（并拼凑）应用程序代码，并且产品可以构建在声明性“意图”的层次结构上，深入挖掘低层次的内容。仅根据需要级别代码。
ETA（根据问题中的请求）有一份 他的早期作品之一微软研究网站上有关于此的论文。 不幸的是，由于西蒙尼几年前离开微软并创办了一家独立的公司，我认为该原型仍然无法下载。 我在微软时看过一些演示，但我不确定他的早期原型的分发范围有多大。
他的公司 IntentSoft 对于他们计划向市场推出的产品（如果有的话）仍然保持沉默，但是 MSR 早期的一些东西非常有趣。
存储模型是某种二进制格式，但我不确定在 MSR 项目期间披露了多少细节，而且我确信自早期实施以来有些事情已经发生了变化。
Actually, roughly 10 years ago, Charles Simonyi's early prototype for intentional programming attempted to move beyond the flat file into a tree representation of code that can be visualized in different ways. Theoretically, a domain expert, a PM, and a software engineer could all see (and piece together) application code in ways that were useful to them, and products could be built on a hierarchy of declarative "intentions", digging down to low-level code only as needed.
ETA (per request in the questions) There's a copy of one of his early papers on this at the Microsoft research web site. Unfortunately, since Simonyi left MS to start a separate company several years ago, I don't think the prototype is still available for download. I saw some demos back when I was at Microsoft, but I'm not sure how widely his early prototype was distributed.
His company, IntentSoft is still a little quiet about what they're planning to deliver to the market, if anything, but some of the early stuff that came out of MSR was pretty interesting.
The storage model was some binary format, but I'm not sure how much of those details were disclosed during the MSR project, and I'm sure some things have changed since the early implementations.
我想旧习惯很难改掉。
直到最近，还没有很多高质量、高性能、广泛可用的用于结构化数据通用存储的库。 即使在今天，我也强调不会将 XML 归为此类——太冗长、太密集而难以处理、太挑剔。
如今，对于不需要人类可读的数据，我最喜欢使用 SQLite 并创建一个数据库。 将功能齐全的 SQL 数据库嵌入到任何应用程序中非常容易……有 C、Perl、Python、PHP 等的绑定……而且它是开源的，非常快速、可靠且轻量级。
我<3 SQLite。
Old habits die hard, I guess.
Until recently, there weren't many good-quality, high-performing, widely-available libraries for general storage of structured data. And I would emphatically not put XML in that category even today--too verbose, too intensive to process, too finicky.
Nowadays, my favorite thing to use for data that doesn't need to be human-readableis SQLite and make a database. It's so incredibly easy to embed a full-featured SQL database into any app... there are bindings for C, Perl, Python, PHP, etc... and it's open-source and really fast and reliable and lightweight.
I <3 SQLite.
为什么文本文件占主导地位？ 因为麦克罗伊的测试。 让一个程序的输出能够被接受作为另一个程序的源代码是至关重要的，而文本文件是最简单的东西。
Why do text files rule? Because of McIlroy's test. It is vital to have the output of one program be acceptable as the source code for another, and text files are the simplest thing that works.
Labview 和 Simulink 是两个图形编程环境。 它们在各自的领域都很流行（分别从 PC 与硬件连接，以及对控制系统进行建模），但在这些领域之外使用得不多。 我曾与一些人一起工作过，他们都是这两种语言的忠实粉丝，但我自己却从未真正接触过它们。
Labview and Simulink are two graphical programming environments. They are both popular in their fields (interfacing to hardware from a PC, and modeling control systems, respectively), but not used much outside of those fields. I've worked with people who were big fans of both, but never got into them myself.
任何人曾经尝试过 Mathematica< /强> ？
上面的图片来自旧版本，但这是谷歌能给我的最好的。
无论如何...将第一个方程与 Math.Integrate(1/(Math.Pow("x",3)-1), "x") 进行比较，就像你必须写的那样使用最常见语言的纯文本进行编码。 在我看来，数学表示更容易阅读，而且这仍然是一个相当小的方程。
是的，如果需要，您可以以纯文本形式输入和复制粘贴代码。
将其视为下一代语法突出显示。 我敢打赌，除了数学之外，还有很多其他东西可以从这种表示中受益。
Anyone ever tryed Mathematica?
The pic above is from an old version but it was the best google could give me.
Anyway...compare the first equation there to Math.Integrate(1/(Math.Pow("x",3)-1), "x") like you would have to write if you were coding with plain text in most common languages. Imo the mathematical representation is much easier to read, and that is still a pretty small equation.
And yes, you can both input and copy-paste the code as plain text if you want.
See it as the next generation syntax highlighting. I bet there are alot of other stuff than math that could take benifit from this kind of representation.
您提到我们应该使用“某种形式的 XML”？ 您认为 XHTML 和 XAML 是什么？
而且 XML 仍然只是一个平面文件。
You mention that we should use "some form of XML"? What do you think XHTML and XAML are?
Also XML is still just a flat file.
很明显为什么纯文本是王道。 但同样明显的是，为什么结构化格式会更好。
仅举一个例子：如果您重命名一个方法，您的差异/合并/源代码控制工具将能够知道只有一件事发生了变化。 我们今天使用的工具将显示一长串更改，每个更改对应调用或声明该方法的每个位置和文件。
（顺便说一句，这篇文章并没有回答您可能已经注意到的问题）
It's pretty obvious why plain text is king. But it is equally obvious why a structured format would be even better.
Just one example: If you rename a method, your diff/merge/source control tool would be able to tell that only one thing had changed. The tools we use today would show a long list of changes, one for every place and file that the method was called or declared.
(By the way, this post doesn't answer the question as you might have noticed)
阅读您的问题时，我们首先想到的就是关于 DSL 的趋势。 问题在于模型（如 UML）和实现之间不存在一对一的关系。 Microsoft 等公司正在努力实现这一目标，以便您可以将应用程序创建为类似于 UML 的内容，然后可以生成代码。 重要的是 - 当您选择更改代码时，模型将再次反映这一点。
Windows Workflow Foundation 就是一个很好的例子。 当然，后台有平面文件和/或 XML，但您通常最终会在编排工具中定义业务逻辑。 这太酷了！
我们需要更多的“软件工厂”思维，并且将来会看到更丰富的 IDE 体验，但只要计算机在零和一上运行，平面文本文件就可以而且（可能）永远是一个中间阶段。 正如一些人已经说过的，简单的文本文件非常灵活。
The trend we are seeing about DSL's are the first thing that comes to mind when reading your question. The problem has been that there does not exist a 1-to-1 relationship between models (like UML) and an implementation. Microsoft among others are working on getting there, so that you can create your app as something UML-like, then code can be generated. And the important thing - as you opt to change your code, the model will reflect this again.
Windows Workflow Foundation is a pretty good example. Of cause there are flat files and/or XML in the background, but you usually end up defining your business logic in the orchestration tool. And that is pretty cool!
We need more of the "software factories" thinking, and will see a richer IDE experience in the future, but as long as computers run on zeroes and ones, flat text files can and (probably) will always be an intermediate stage. As stated be several people already, simple text files are very flexible.
我渴望地想知道同样的事情，正如答案中所描述的：
您希望存在什么工具/应用程序/什么？
虽然很简单想象一下有这么多好处，我认为必须解决的最大障碍是没有人提出可行的替代方案。
当人们想到将源代码存储为文本的替代方案时，他们似乎经常立即想到图形表示（我在这里指的是已经可用的商业产品 - 例如 HP-vee）。
如果我们看看像 FPGA 设计师这样的人的经验，我们会发现（仅）图形化编程是行不通的 - 因此像 Verilog 和 VHDL 这样的语言。
但我不认为源代码的存储首先必须与编写它的方法绑定。
源代码的输入很大程度上可以作为文本完成——这意味着复制/粘贴的问题仍然可以解决。
但我也看到，通过允许在标记化元源的基础上进行合并和回滚，我们可以实现更准确、更强大的操作工具。
I've wistfully wondered the same thing, as described in the answer to:
What tool/application/whatever do you wish existed?
While it's easy to imagine a great number of benefits I think the biggest hurdle that would have to be addressed is that no-one has produced a viable alternative.
When people think of alternatives to storing source as text they seem to often immediately think in terms of graphical representations (I'm referring here to the commercial products that have been available - eg. HP-vee).
And if we look at the experience of people like the FPGA designers, we see that programming (exclusively) graphically just doesn't work - hence languages like Verilog and VHDL.
But I don't see that the storage of source necessarily needs to be bound to the method of writing it in the first place.
Entry of source can be largely done as text - which means that the issues of copying/pasting can still be achieved.
But I also see that by allowing merges and rollbacks to be done on the basis of tokenised meta-source we could achieve more accurate and more powerful manipulation tools.
Visual FoxPro 使用 dbf 表结构来存储表单、报表、类库等的代码和元数据。这些是二进制文件。 它还将代码存储在实际文本文件的 prg 文件中...
我看到的唯一优点是能够使用内置的 VFP 数据语言对这些文件进行代码搜索...除此之外，在我看来这是一种责任。 至少每隔几个月，其中一个文件就会无缘无故地损坏。 与源代码管理和差异的集成也非常痛苦。 有一些解决方法，但涉及暂时将文件转换为文本！
Visual FoxPro uses dbf table structures to store code and metadata for forms, reports, class libs, etc. These are binary files. It also stores code in prg files that actual text files...
The only advantage I see is being able to use the built in VFP data language to do code searches on those files... other than that it is a liability imo. At least once every few months, one of these files will become corrupted for no apparent reason. Integration with source control and diffs very painful as well. There are workarounds for this, but involve converting the file to text temporarily!
谁使用平面文件？
Eclipse 为您提供了源代码视图，以便我可以看到所有已排序和分组的内部类、方法和数据。 如果我想编辑内部类，我点击它。 虽然从技术上讲，底层有一个平面文件，但我几乎从不这样浏览它。
Who works with flat files?
Eclipse gives you views into your source so that I can see inner classes, methods and data, all sorted and grouped. if I want to edit the inner class I click on it. While technically there is a flat file underlying I almost never navigate it like that.
有关取消传统文本编程的语言示例，请参阅 Lava 语言。
我最近发现的另一个有趣的事情是 subtext2 (视频演示）。
For a example of a language that does away with traditional text-programming, see the Lava Language.
Another nifty thing I just recently discovered is subtext2 (video demo).
程序代码定义使用 xml 或二进制格式创建的结构。 您的编程语言是比 XML 或二进制表示形式更直接的程序结构表示形式。 您是否注意到当您为文档赋予结构时，Word 如何对您做出不当行为？ WordPerfect 至少会“显示代码”，让您看到文档下面的内容。 平面文件对你的程序做同样的事情。
The code of your program define the structure that would be created with xml or the binary format. Your programming language is a more direct representation of your program's structure than an XML or Binary representation would be. Have you ever noticed how Word misbehaves on you as you give structure to your document. WordPerfect at least would 'reveal codes' to allow you to see what lay beneath your document. Flat files do the same thing for your program.
好主意。 我自己也想知道，在更小的范围内……小得多，为什么 IDE X 不能生成这个或那个。
我不知道我作为一名程序员是否有能力开发出像你所说的或我正在思考的那样酷而复杂的东西，但我有兴趣尝试。
也许从 .NET、Eclipse、Netbeans 等的一些插件开始？ 展示可以做什么，并开启编码的新趋势。
Neat idea's. I have myself wondered on a smaller scale ... much smaller, why can't IDE X generate this or that.
I don't know if I am capable as a programmer yet to develop something as cool and complex as your talking about or what I am thinking about, but I would be interested in trying.
Maybe start out with some plugins for .NET, Eclipse, Netbeans, and so on? Show off what can be done, and start a new trend in coding.
我认为另一个方面是代码很重要。 这就是将要执行的事情。 例如，在您的 UML 示例中，我认为将 UML（大概是在某些编辑器中创建的，与“代码”不直接相关）包含在您的“源 blob”中几乎是无用的。 更好的做法是直接从代码生成 UML，这样它描述了代码所处的确切状态，作为理解代码的工具，而不是提醒代码应该是什么。
关于自动化文档工具，我们多年来一直在这样做。 虽然实际程序员在代码中生成的注释可能与代码不同步，但像 JavaDoc 之类的工具忠实地表示了对象的方法、返回类型、参数等。它们将它们表示为实际存在的样子，而不是某些来自无休止的设计会议的工件。
在我看来，如果您可以任意地将随机工件添加到某些“源斑点”中，那么这些工件可能会过时并且立即用处不大。 如果您可以直接从代码生成此类工件，那么让您的构建过程这样做的小努力比前面提到的远离纯文本源文件的陷阱要好得多。
与此相关，解释你为什么想要使用纯文本 UML 工具 (UMLGraph) 似乎也几乎同样适用于为什么你需要纯文本源文件。
I think another aspect of this is that the code is what is important. It is what is going to be executed. For example, in your UML example, I would think rather than having UML (presumably created in some editor, not directly related to the "code") included in your "source blob" would be almost useless. Much better would be to have the UML generated directly from your code, so it describes the exact state the code is in as a tool for understanding the code, rather than as a reminder of what the code should have been.
We've been doing this for years regarding automated doc tools. While the actual programmer generated comments in the code might get out of sync with the code, tools like JavaDoc and the like faithfully represent the methods on an object, return types, arguments, etc. They represent them as they actually exist,not as some artifact that came out of endless design meetings.
It seems to me that if you could arbitrarily add random artifacts to some "source blob", these would likely be out of date and less than useful right away. If you can generate such artifacts directly from the code, then the small effort to get your build process to do so is vastly better than the previously mentioned pitfalls of moving away from plain text source files.
Related to this, an explanation of why you'd want to use a plain-text UML tool (UMLGraph) seems to apply nearly equally as well to why you want plain-text source files.
这可能无法准确回答您的问题，但这里有一个编辑器可以让您拥有更高的代码视图：
http://webpages.charter.net/edreamleo/front.html
This might not answer exactly your question but here is an editor allows having an higher view of code:
http://webpages.charter.net/edreamleo/front.html
我认为开发中使用文本文件的原因是它们对各种开发工具具有通用性。 您可以使用简单的文本编辑器查看内部甚至修复一些错误（您不能在二进制文件中执行此操作，因为您永远不知道任何修复会如何破坏其他数据）。 然而，这并不意味着文本文件最适合所有这些目的。
当然，您可以区分和合并它们。 但这并不意味着差异/合并工具理解此文本文件编码的数据的不同结构。 您可以进行比较/合并，但是（尤其是在 XML 文件中）比较工具不会正确显示差异，也就是说，它将显示文件的不同之处以及该工具“认为”数据的哪些部分是相同的。 但它不会向您显示 XML 文件结构的差异 - 它只会匹配看起来相同的行。
无论我们使用二进制文件还是文本文件，差异/合并工具处理该文件表示的数据结构而不是行和字符总是更好。 例如，对于 C++ 或 Java 文件，报告某些标识符更改了名称，报告某些部分被附加的 if(){} 包围，但另一方面，忽略缩进或 EOL 字符的更改。 最好的方法是将文件读入内部结构并使用特定的格式规则转储。 这样，将通过内部结构进行比较，并从合并的内部结构生成合并结果。
I think the reason of why text files are used in development is that they are universal against various development tools. You can look inside or even fix some errors using a simple text editor (you can't do it in a binary file because you never know how any fix would destroy other data). It doesn't mean, however, that text files are best for all those purposes.
Of course, you can diff and merge them. But it doesn't mean that the diff/merge tool understand the distinct structure of the data encoded by this text file. You can do the diff/merge, but (especially seen in XML files) the diff tool won't show you the differences correctly, that is, it will show you where the files differ and which parts of the data the tool "thinks" are the same. But it will not show you the differences in the structure of XML file - it will just match lines that look the same.
Regardless whether we're using binary files or text files, it's always better that the diff/merge tools take care of the data structure this file represents rather than the lines and characters. For C++ or Java files, for example, report that some identifier changed its name, report that some section was surrounded with additional if(){}, but, on the other hand, ignore changes in indents or EOL characters. The best approach would be that a file is read into internal structures and dumped using specific format rules. This way the diff-ing will be made through the internal structures and the merge result will be generated from the merged internal structure.
现代程序都是由扁平的部分组成的，但是它们是扁平的吗？ 有使用、包含和对象库等。普通的函数调用是对不同位置的查看。 由于具有多个线程等，逻辑不平坦。
Modern programs are composed of flat pieces, but are they flat? There are usings, and includes, and libraries of objects, etc. An ordinary function call is a peek into a different place. The logic isn't flat, due to having multiple threads, etc.