Programming at the REPL: Guidelines for REPL-Aided Development
Table of Contents
- The REPL is a User Interface to your program
- Don’t get carried away by the REPL
- Don’t forget to save your work, and make it accessible
- The REPL is not the only tool for interactive development
Clojure REPLs are used for a broad spectrum of purposes, from learning the language to data exploration to live music performance. This chapter will provide some guiding principles for applying Clojure REPLs to the more common use case of pragmatic software development.
The REPL is a User Interface to your program
Programs commonly offer User Interfaces through a variety of media:
-
Graphical: web pages, mobile and desktop apps
-
Network-based: Web Services / HTTP APIs / …
-
Storage-based: the program keeps a database up to date, which can then be queried
-
Command-Line Interfaces (CLI): from interaction via a terminal
You should think of the REPL as another medium for user-to-program interaction; compared to those listed above, it requires advanced knowledge (programming in Clojure!), but it is also extremely expressive and cheap to develop, since it requires almost no anticipation of what parts of the code users will want to leverage. For instance, the REPL is a very suitable UI for ad hoc data exports.
In Clojure projects, it is common practice to define functions and namespaces solely intended for REPL interaction: consider it an alternative to CLI, dashboards, etc.
Don’t get carried away by the REPL
The REPL can give you a lot of velocity, but do not mistake motion for progress. You should always come to the REPL with a plan , otherwise the REPL will bring you more distraction than focus. If you find it difficult to keep the plan in your head while using the REPL, consider writing it down .
The REPL will only guide you through very incremental changes, which is prone to getting you stuck in 'local maxima'. When more strategic thinking is required, force yourself to take a step back. In particular, rapid feedback is no substitute for software design and methodic problem-solving.
Don’t forget to save your work, and make it accessible
The REPL is a very ephemeral and exclusive medium. If there is anything to take away from a REPL session, it should probably reside in other places than your flawed human memory (for instance in code, tests, commented-out code, documentation, data files, etc.).
If what you learned in the REPL is a prerequisite to your project, you should do some extra work to make it accessible to other contributors (including yourself in a few months).
The REPL is not the only tool for interactive development
There are other tools which provide a tight feedback loop while programming:
-
auto-reloading test suites (example: Midje )
-
static code analysis tools (linters, static type checkers)
-
hot-code reloading (example: Figwheel )
-
'visual' test suites (example: Devcards )
There is no reason to see these approaches as 'competing' with REPL-aided development, and oftentimes the REPL can assist you in using them. Each of these approaches has its strengths and weaknesses: for instance, the REPL makes the execution of programs very tangible, but is a poor tool for detecting breakage.
以上所述就是小编给大家介绍的《Programming at the REPL》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
