【问题标题】:Proper usage of REPL for development正确使用 REPL 进行开发
【发布时间】:2014-03-15 12:10:35
【问题描述】:

我一直想知道如何正确使用 REPL 来编写可重用代码,而不是一次性试验。对于 REPL 开发风格的各种优势有很多强烈的意见,我想在实践中检查一下,但我不明白预期的工作流程是什么。

假设我在 REPL 中打开现有模块(+样本/测试数据),并以交互方式创建新功能/修复错误。取得了巨大的成功——它现在按预期使 foobar 实现了 frobnicates!但现在呢?我应该如何将更改和添加恢复到我的模块和版本控制中?

将所有 REPL 状态转储到文件仅适用于初始创建,不适用于修改或添加现有代码(因此,几乎所有开发) - 它需要保留模块、cmets 等之间的拆分等内容。从 REPL 历史复制粘贴到每个文件中的相关位置似乎是一项繁琐的工作,而且很容易出错。如何确保修改后的函数具有我在 REPL 中的确切最终版本,并且我没有忘记一些?

为此推荐的最佳做法是什么?

恕我直言,这个问题与语言无关,但如果不是,让我们假设 Haskell 或 Python,因为 Lisp 是它自己的世界,我对它还不够熟悉。

【问题讨论】:

  • 我一直在问自己这个确切的问题 - 它似乎确实是基于语言的,因为一些 REPL 胜过其他人。 REPL-Driven Development

标签: read-eval-print-loop


【解决方案1】:

REPL 并非设计用于持久性代码开发。 REPL 的主要用途是:

  • 确定代码和解释器行为的小测试。
  • 新用户的学习工具。
  • 临时场景的交互式执行环境。

有一些例外,例如微软基于 ROM 的解释性 BASIC 的 LOADSAVE 操作的行编辑器在 1970 年代末和 1980 年代初流行。然而,这确实是早期微型计算机提供的一个组件,这些微型计算机不具备更高级的基于文件系统的开发环境所需的存储、容量和操作系统功能。

另一个例外是各种操作系统命令 shell REPL 环境(例如 bash)的已保存历史记录和别名功能。在这种情况下,解释性语言虽然很重要,但对于管理文件系统和执行系统二进制文件来说是次要的。在这些环境中用户代码的可重用性是针对平台的管理和日常操作。

为了使用模块化和版本控制等高级持久性编程概念,建议使用解释器工具集提供的基于文件系统的编程工具。大多数开发语言都有单元测试框架,例如用于 Haskell 的 HUnit 和用于 Python 的 unittest,它们允许在应用程序开发过程中执行组件级测试和操作检查。

话虽如此,只要使用正确的语言和实现,就有可能打破这种范式并创建一个 REPL 环境,该环境可以从用户提供的小代码示例构建更大、更复杂的东西。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多