Reped: A REPL-Centered Workflow for Data Science
Nowadays workflow for data science is editor-based. No matter vim, emacs, or IDE are all central parts when data scientists develop algorithms, or engineers develop new applications. People write scripts in the editors, copy them into the interactive shell (often called REPL, an acronym for Read, Evaluate, Print Loop), and execute the codes there. For better interactivity, people invent a bunch of tools, such as linter, auto-completion, and syntax highlighting, until LSP (language server protocol). However, all these tools are not free lunches. The editors are becoming more and more swollen and clumsy. We spend time and (sometimes) money to make ourselves skillful in VS Code or PyCharm. However, when we enjoy the fancy functions provided by these tools, we are bound with them, like an assembly line worker, rather than a free-minded, joyful coder. Some say, even though this is a fair argument in some way, most programmers nowadays do use IDEs. Yes, but with a historical reason. Today developing toolchains is dominated by software development, which is divided roughly into two camps: statically typed languages and dynamically typed languages. The former is much older than the latter (the LISP family has much fewer practitioners than the C family after all). So most dynamic programmers adopted the developing toolchains of static programming.
Last Friday morning on the way to the office, an idea hit me like an enlightenment: why not put REPL to the center of the stage, while keeping the editors playing their original role: save codes into files and disks? For the essential role of REPL in this settings, I call it reped (REPl + EDitor).
I'm really excited about this idea and spent two more days making it real. This toolchain is composed of 4 parts: an editor (of course) neovim. A REPL-editor communication tool "iron", written in Lua, initializes a REPL in neovim's built-in terminal, based on the language of the script edited, by far there are xonsh for Python, radian for R, and Julia with OhMyREPL package. The third part is a configuration system composed of Lua script, providing different functions and parameters for managed languages. The last part is a Python script to start the editor. It provides help messages, puts appropriate configuration files in the proper position, and set parameters that can't be determined beforehand.
After several days of usage, I must say its experiences outperformed any IDE I've used. First, it's blazing fast thanks to Lua's performance. And you know, timing really counts. Second, it's completely keyboard controlled. Your hands needn't leave your keyboard, turning coding into an exciting journey, like playing in the FC game console, back in childhood. Third, with the help of Lua and Python, you can control your system deep into every byte. It's your tool made by yourself.
Comments
Post a Comment