Question

这是为什么？ Gcc现在提供“C-to-XML”转换，因为XML更易于解析。

如果我们的源代码是XML，我们不能受益吗？

当然，没有人希望手动编辑XML文件 - 但这就是IDE的用途。

一些语法较少的编程语言（LISP，Smalltalk）会更好地映射到XML吗？

Answer 1

 <comment>
 <statement-of-argument>
    I don't think everything is XML.
 </statement-of-argument>
 <p>
    You still see plenty of plain text and other forms of encoding.  
    I think you're just being <pejorative>silly</pejorative>.
    Or perhaps imagining things.
 </p>
 </comment>

Answer 2

如果我们的源代码是XML，我们不能受益吗？

让我从广义上讲这个问题：假设我们最喜欢的编程语言有一个标准的机器可读形式，只接受格式良好的树。我们不能受益吗？

这是在20世纪80年代用Ada完成的，抽象语法树的标准形式（我相信它被称为DIANA）。那些编写分析Ada的工具的人有一点点好处。
在20世纪80年代，使用康奈尔程序合成器和相关工具获得的其他经验表明，对于开发人员，您必须能够编辑不语法正确的程序。请记住，we are typists first, programmers second，以及我们从康奈尔合成器的经验中学到的是，使用任何 IDE强制您始终维护一个语法正确的程序（想想：格式良好的XML树）喜欢拖着球和链子。

优秀的程序员非常非常擅长快速输入文本。任何能够取消这种优势的代表或IDE最好提供一些令人信服的补偿优势。对于XML，我看不出那些补偿优势可能是什么样的。
使用XML获得的一件事是编写解析器更容易。（你仍然需要编写一个，但它更容易。）但是凭借我们自20世纪80年代以来获得的计算能力，以及可以利用这种能力的大量新解析技术，解析（将线性文本转换为树形）只是不再是那么大的交易了。创建优秀工具的所有工作都是在生成树的分析（类型检查，指针分析，信息流，优化，您命名）中。 XML不会在那里买任何东西。

我在编译器和相关工具方面做了我的声誉，虽然我看到抽象语法树的标准表示有一些非常适度的好处，并且愿意接受XML作为这样的表示，我看不到这样做的好处是值得同意标准的成本。

Answer 3

编程语言是为了程序员的方便，而不是为了便于解析。

Answer 4

与http://xplusplus.sourceforge.net/玩得很开心：P

现在一切都是XML - 但编程仍然使用一些遵循复杂语法的遗留文件

4 个答案: