我们有一个非常通用的终端/嗅探器应用程序，它可以通过 TCP、UDP 和串行连接执行各种操作。
我们希望使其可扩展——即，允许人们编写自己的协议解析器、荧光笔等。
我们创建了一种类似 C 的语言来扩展产品，然后发现对于一些编码人员来说，这呈现出陡峭的学习曲线。
我们现在正在思考这个问题：我们应该坚持使用 C 还是使用 Ruby 或 Lua 之类的东西？
C 非常适合低级的东西（比如解析二进制数据），因为它支持指针。但正是由于这个原因，学习起来可能很困难。
Ruby（等）很容易学习，但没有指针，所以与解析二进制数据有关的任何事情都会很快变得丑陋。
你怎么看？用于扩展解析二进制数据的产品——Ruby/Lua 还是 C/C++？
如果您能在回复时提供一些背景信息，那就太好了——尤其是如果您做过类似的事情。
与 TCL 一样，Lua旨在与应用程序紧密集成。就个人而言，我发现 Lua 的语法和习语比 TCL 更容易处理。
Lua 易于与现有系统集成，并且易于扩展。创建安全沙箱也相当容易，用户提供的代码可以在其中运行而无需完全访问产品的内部结构。
如果您编写了 API，是否会有所作为？使用类 C API 的人只需了解按值传递或引用传递之间的区别。
你的核心做一件事非常好，很好。就这样吧。我认为您应该创建一个基于 std in/out 的 API，就像良好的 unix 设计方式一样。然后任何人都可以用任何选择的语言对其进行扩展。
perl, sed, awk, lex, antler, ... 这些是我比较熟悉的语言，我想用这些语言编写类似的东西。不过，这取决于数据流。
真的很难说什么是正确的使用方法。我认为其他人没有提到的一点是要记住脚本会有错误。以这样的方式设计这样的东西非常容易，脚本中的错误（尤其是运行时错误）要么只是显示“脚本中的错误”，要么杀死整个系统。
您应该保持脚本应该是可单元测试的，并且失败应该是可重现的。
Tcl 的设计目标是允许为 C 程序编写脚本，因此它更容易实现。
http://en.wikipedia.org/wiki/Tcl#Interfacing_with_other_languages
我赞同约翰的想法。虽然过去当我不得不做这样的事情时，我坚持使用 C 语言 API，人们被限制只能使用 C 语言。但现在我看着它，我意识到如果我们按照 Johan 描述的方式去做会更有效率
PS：巧合的是，它是一个使用数据包嗅探器的协议测试应用程序
我认为你做什么并不重要，只要你做一件事，放弃内部语言。听起来您选择将 C 变成脚本语言。我看到的一个问题是 C 程序员看起来很熟悉，但不一样。我无法想象您已经模仿了 C 的语义，这会使现有的 C 程序员感到舒适。正如你所提到的，其他人会发现很难学习。
我工作的公司已经开发了自己的语言。它使用 XML 作为结构，因此解析很容易。语言“按需”增长。这意味着如果缺少某个功能，那么它将被添加。我很确定它从 XML 数据库变成了需要控制流的东西。但我的观点是，如果您不考虑将其构建为一种语言，那么您将无意中限制用户可以使用它做什么。
就我个人而言，我一直在研究如何让公司开始利用 Lua。特别是 Lua 有几个原因。Lua 是作为一种通用的扩展语言而开发的。它可以轻松地与包括 Python 和 Ruby 在内的语言交互。非程序员使用它既小又简单（在您的情况下并不真正需要）。它可以简单地替换 XML、INI... 进行配置设置，并且功能强大到可以替换另一种编程语言的需要。