【问题标题】：Why is source code text-only?为什么源代码是纯文本的？
【发布时间】：2011-11-14 14:04:15
【问题描述】：

我一生都在使用基于文本的源代码编辑器。我不敢相信我们都还在这样做！一定有更好的办法。

我并不是说我想使用 WYSIWYG 编辑器，我通常讨厌那些，因为它们不能完全生成你想要的。

不，我的意思是基于文本的源代码编辑器，它通过以下额外功能大大增强：

包括图片、excel-data、pdf 等。在源代码中，解释某些数据结构，包括（模型）客户实际想要的屏幕截图等。当然可以选择缩小/隐藏/折叠这些东西。（与单独文件相比，这样做的优势很明显，您希望将此信息与源代码一起存储）
cmets 不是文本，而是更像便利贴式的项目，可调整大小、可移动、可点击等。
类定义和实例不是文本，而是可点击的对象框，甚至可能带有一个图标，以便在源代码中快速查看对象是哪个类）。
现在将 2 个字符作为 1 个符号的运算符。例如： -> 在 PHP 中作为一个真正的箭头。
可以在源代码中使用颜色、不同的文本大小和其他布局工具（我不是在谈论自动语法着色，有时通过使用布局工具来强调某些文本块可能很方便你在 Word 中做的）
在不同的文件中包含单独的文件，但仍然可以编辑/查看这些文件，就像它是 1 个文件一样（类似于 Adobe Illustrator，您可以在文档中放置单独的文件，但仍然可以编辑他们）。

我知道很多铁杆程序员对这类事情感到震惊，但他们仍然可以按照自己想要的方式进行编辑，我只是认为拥有这些额外的可能性会很好。为什么源代码仍然只有文本，而许多其他类型的文档要复杂得多？

有谁知道任何具有这些功能的源代码编辑器？？

【问题讨论】：

如果有需求，我相信有人会创建一个。我认为问题出在这句话的前半部分。
我认为这更多地与大多数程序员都是书呆子（无意冒犯！）这一事实有关，他们很难使用比纯文本更具创造性的工作方式。但只要是这样，编程总是会被认为对“普通”人来说太难了，在我看来这是一件坏事。
你知道lighttable.com吗？

标签： ide editor wysiwyg

【解决方案1】：

过去曾尝试制作可视化开发工具 - 但问题是计算机需要形式语言中非常精确的语句才能完全满足用户的特定需求。

事实上，如果你写下一个需求，然后以不同的重点阅读它，你会发现很难写出一个明确的陈述。

此示例来自软件工艺：Pete McBreen (978-0201733860) 的新命令。

玛丽有一只小羊羔 - 羊羔属于玛丽，而不是其他任何人

玛丽有一只小羊羔 - 她不再拥有它

玛丽有一只小羊羔 - 只有一只

玛丽有一只小羊羔 - 它非常小

玛丽吃了一点羊肉 - 其他人都吃鸡

这就是为什么我们需要一种要求我们比自然语言更明确的语言，以及为什么视觉辅助开发没有用的原因。

例如，使用“便利贴”注释代码不如编写易于阅读的干净可读代码有用。事实上，与其他开发人员共享代码意味着更改文本大小和颜色会要求其他开发人员以您的个人风格为代价，这并不酷。

你提到的一些想法现在实际上是可用的。能够通过单击类“框”来查看类图并导航到代码是 Visual Studio 的一项功能 - 在树视图中的单个文件后面组织多个文件也是如此。

【讨论】：

【解决方案2】：

这当然只是我的意见，所以请持保留态度。我认为这样的事情还没有完成的主要原因是编译器仍然期望纯文本。如果您有像您提到的那样的源代码编辑器，它将只是一个前端 - 实际的源文件仍然是纯文本。您遇到的问题是采用这种方法的每个源代码编辑器可能有不同的方式来实现某些功能，因此看似相同的源代码实际上在纯文本中会完全不同。

当您编译该源代码时，您将陷入困境。对于您提到的示例 PHP，它可能没问题，但对于我从事的工作类型（行业的实时 C++ 应用程序），我需要对源代码进行精确的低级别控制，以便我确切地知道我的代码是如何运行的编译。这对绝大多数程序员来说永远都行不通，这就是为什么它从来没有做过。目标受众充其量是很小的。

【讨论】：

好的，但是我提到的所有这些东西都只是普通源代码之上的一层。底层源代码将是相同的。额外的信息甚至不需要与源代码存储在同一个文件中，带有另一个扩展名的额外文件就可以了。拥有可以读取此信息的编辑器的人可以使用它，其他人仍然可以像往常一样使用源代码（我确实意识到使用普通编辑器更改源代码会造成麻烦，但大多数开发团队使用我认为相同的工具）
不，你错过了我的意思。当您使用这些编辑器之一编辑源文件时，如何实现所有这些功能完全取决于编辑器。很难知道编辑器实际上是如何在后端保存源代码的。它可能有一个单独的文件（有点像 Visual Studio 对 .suo 所做的那样）并保持源纯文本完全相同，但现在您有两个文件要跟踪。您是否要将两者都签入版本控制？基本上，我的观点是，我只是没有看到很多开发人员实际使用这种类型的编辑器。没有需求，就没有产品。
好吧，我提到的一些事情可以通过一个格式巧妙的评论块来完成。普通编辑器会将其显示为评论，而高级编辑器将显示所有额外酷的东西。图片可以保存为单独的文件，但在高级编辑器中显示为内部图片。但是你不同意纯文本有点石器时代的技术吗？ Excel 文件不再是逗号分隔的 TEXT。当您想要所有复杂的选项和功能时，它是一种复杂的二进制格式，每个人都可以接受。为什么源代码不能这样？
我同意您所要求的对某些环境和语言很有用，并且其中大部分是在这些语言的 IDE 中实现的。但是，纯文本仍将是王道，因为它是编译器作为输入的内容。如果您开发的编译器可以读取纯文本以外的符号，您将看到为支持该功能而构建的开发环境。

【解决方案3】：

在我看来，您所描述的内容很像 https://en.wikipedia.org/wiki/Literate_programming。

在这方面已经取得了一些进展，其中一些现在很有用

带有连字的字体（以及支持它们的编辑器）

(https://github.com/tonsky/FiraCode in https://www.jetbrains.com/idea/)

Jupyter Notebook，尽管您不能轻易地为最终用户“纠结”出可执行文件或库。

(http://jupyter.org/)

Fortress（来自 Sun 的编程语言）

Fortress 支持 utf-8 源代码并鼓励使用它，尤其是。用于用户定义的运算符。他们尝试在编辑器中排版源代码（因为其中大部分是计算科学，所以有很多数学）。

弹性制表位

(http://nickgravgaard.com/elastic-tabstops/)

结论

实际上，有很多这样的努力。目前还没有像开发人员工具的 UX 运动这样的东西，但我希望它会在未来几年积聚动力。

【讨论】：