yuyan
yuyan copied to clipboard
yuyan-lang
反馈（报错、警告、调试等）信息的风格与编程语言一致化
很高兴看到本项目以实用语言为目标，也许值得在早期将此方面纳入考虑。在文言提过 相关issue。 实践中用户很多耗时在理解错误信息和排错。各种反馈信息在划出语言功能边界的同时，也决定了对用户暴露的实现细节、用户需要了解的相关术语。 对使用自然语言语法的编程语言，一个优势是可以将反馈信息的风格与编程语言尽量一致化，个人认为可以提升用户体验，也是在现有编程语言中极少看到的。
实施上能想到的：
- 确定用户需要掌握的概念，及哪些反馈信息会用到（也许会反过来影响语言设计）
- 将需要包含在反馈信息中的术语中文化（像文言 此issue）
- 规划反馈信息格式风格：即便与编程语言的语法不完全相同，至少风格上可以逐步接近
嗯嗯。 谢谢你的中肯的建议。 报错信心优化会在语言功能设计完善后进行。目前（初期几个版本）的工作重心还是在语言的功能（Features）的设计。
》 确定用户需要掌握的概念 应当进行一些语言风格方面的探索，但目前的所有反馈信息只是因为不这样反馈编译器/解释器就无法进行下一步的操作，目前（至少在0.2版本前）我的设计是最大程度告知用户出错的代码位置的大概信息。用户确实需要知道他们想要表达的是什么以及如何运用语言提供的结构（users have to know what they are doing）。
》反馈信息中的术语中文化 这个确实可以，虽然第一步可以暂时采取现代汉语的直译，但最终目标是采用一些具有传统文化内涵的翻译。
》即便与编程语言的语法不完全相同，至少风格上可以逐步接近 当然因为现代语言设计脱胎于西方逻辑学，在语法和翻译方面还有很多哲学方面的前沿工作要做。另外一点就是鄙人以为，程序语言是和自然语言的差别还是挺大的，只能做到外观上一致，骨子里还是不同的东西。
随着语言功能（feature）的增加，报错信息的内容估计会逐渐增多，其中包含的各种术语也是。 最近觉得报错信息的水挺深，准确描述”用户在哪里做错了什么“已经不易，如果之外还要提出”如何改正“的建议的话，就要牵涉到对用户意图的推测。 期待这方面的探索和进展~
@nobodxbodon 其实在编程语言报错信息翻译方面，你有没有了解过的研究？
（尤其是目前直接的翻译晦涩难懂，不知道有没有从用户角度出发的报错信息研究）
@UltimatePea 之前看到的一些报错信息相关论文摘要：
- Do Enhanced Compiler Error Messages Help Students?: Results Inconclusive.
- Error messages are classifiers: a process to design and evaluate error messages
个人最近在尝试尽量不用术语、与编程语言语法一致的反馈信息设计：详见“某语言”设计帖。其中通过“获取最近语义”支持不符内置语法的用户输入，以省去语法相关的反馈信息。
另一种设计，是通过严格限定各语法要素的组合方式来尽量减少代码的语法问题，比如 Scratch。
各种设计都需将用户调试纳入考虑。即便像 Scratch 也需 各种调试技巧。个人感觉语言设计与调试手段是互相影响的，而报错信息与调试息息相关。
说回到报错信息，现在市面上的编程语言往往是一句话，但实际上详细解释相关内容可能要一大段（不妨找些具体例子讨论）。这往往意味着将语言内部运行机制暴露给用户。以API设计作对比，最好报错内容尽量与API业务相关，而不需将API内部实现暴露给用户。
也许这方面可以借鉴UX的报错信息，如 Avoid jargon and developer speak一节；或是web API的错误信息，如 此文。
一个python报错信息例子： My favorite terrible Python error message，“TypeError: object() takes no parameters”。
对新手用户来说几乎是无法一眼理解的，其背后牵涉到了许多python类型系统机制细节。
根据最近的实践来看，报错信息确实是一个很复杂的问题。
我自己在编程的时候很多报错信息都要看半天是什么意思，程序写不对就会报错。
目前我能想到的方法是根据社区的反馈逐步改进报错信息。所以这一块我们要非常重视社区给予的反馈。