3 ms·
That would easily be using an integrated REPL. The more integrated it is (with your IDE/editor) the better the experience and productivity boost. And the diff
by dgb23 6y ago
That would easily be using an integrated REPL.
The more integrated it is (with your IDE/editor) the better the experience and productivity boost.
And the difference is quite large. When you are working with a language that has first class REPL support you start to
- 'get' why Emacs exists
- become faster at writing code in general
- write much more experimental and open
- become more motivated in testing smaller assumptions and asking questions about your or other peoples code
With "first class support" there are three dimensions:
(1) The REPL and the editor/IDE have to be understand each other well.
(2) The language itself has to be malleable and (de-)compose well in terms of syntax and idioms.
(3) many things in the language are first class expressions or in other words: there is a high degree of tangibility in the language constructs.
Most dynamic languages have workable/decent support for REPL driven development so it is always worth testing out.
You find excellent support in: Clojure (and of course other Lisps) and Julia from my experience.
- dvdt 6y agoI completely agree with the point about integrated REPL/IDE, and wanted to share some of the combinations I have used in the past, since it can be a concrete getting started point for those who are curious. Some of these are not literally repls, but IMO give a similar experience. - ClojureScript with Figwheel and the web browser - Clojure with Emacs Cider, Clojure with Cursive - R and Rstudio - Matlab - ipython jupyter notebook - Pycharm debug breakpoints that are triggered by unittests (Running the unittest to initiate a python repl at the breakpoint)
- mxschumacher 6y agoWhat I really love about R/Rstudio is that you can highlight a few lines of code and execute them in isolation
- jimbokun 6y agoMy main responsibility is developing and maintaining a microservice written in Java. However, one thing I've found invaluable over the years is developing operational tools to support my deployed code, in a language with a built in REPL. At different times, I have used Clojure and Jython for this (high level way to call my Java libraries, or to invoke APIs over the network), and most recently Ruby (has been easy to deploy and run scripts or ad hoc commands over irb for operational tasks, in the same environments where my service runs). This allows me to build up code over time that I can use to * Quickly make calls to my service to triage or debug production issues. * Write scripts to quickly validate a new install. * Script operational tasks at a high level that doesn't make sense to build into the service itself (can allow the service to be more stateless, for example). * Bypass layers and make calls to the underlying database (can be more powerful than the command line tools dedicated to a specific database). * Can be more powerful and composable than curl or Postman for making web calls. * Have used it to analyze the state of messages in a Kafka topic (with a custom gem). So I highly recommend building a tool set around a language with a good REPL for anyone responsible for a service with a REST API, or any other kind of API available over a network.
- zmmmmm 6y agoHave you tried Groovy? Sounds kind of ideal if your main work is with Java. I have a BeakerX (JupyterLab+Groovy) notebook open pretty much continuously next to my IDE while I code so that I can validate all my assumptions as I code. A nice workflow is that you start with a snippet of experimental code, which you tidy up in the REPL, then it splits into the actual function and test code, one part going to the unit test and the other to the real code.
- dgb23 6y agoYes, this is extremely useful, thank you for sharing. I also often use the REPL as a "tool" rather than just a editor feature. For example this week I'm working on a data integration. This is a very specific one-time task, so there is currently no need to write accessible production code. I can just use the REPL to do the "ETL" and leave the code as-is. There is merit in keeping it and find functionality to extract, abstractions/compositions in the future, but the point is that the integrated (Clojure) REPL itself is already sufficient, powerful and very ergonomic tool.