Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What makes a good REPL?

vvvvalvalval.github.io

Post reply on HN
Print view View original

81–90 of 177 posts

Re: What makes a good REPL?

#81

Post by agentgt »

mjmein wrote: post #75
agentgt wrote: post #47

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynam…

The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL. Instead, you develop code in a file, but constantly evaluate code as you go along. When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions. Then, when I'm happy with the…

> The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL.

> Instead, you develop code in a file, but constantly evaluate code as you go along.

Yes but what you are describing is hot code replacement and evaluation. You do not need a REPL. For a concrete example Java + JRebel + Debugger (Eclipse calls it Display with a glasses icon) will do that for you.

In my mind a REPL is very much about the input and of course the output otherwise its basically what I mentioned above.

And I think the the article doesn't really go into any new innovation or attempts at making REPLs better (particularly because they mention Bret Victor)... ie better input and better output.

Yes advanced REPLs have history saving capabilities and what not but then they are basically competing with the rest of the editor, IDE and source control.

Really innovative REPLs I think are what Bret shows, as well Squeak, and Racket. Those environments offer really unique input and output.

Re: What makes a good REPL?

#83

Post by agentgt »

valw wrote: post #70
agentgt wrote: post #47

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynam…

Well, what are your thoughts on the 'Write fewer tests, faster' section of the article?

I assume you are the author? I think you make valid case/points but I have some kind counter points if you don't mind

> 1. Having too many unit tests makes your codebase harder to evolve. You ideally want to have as few tests as possible capture as many properties of your domain as possible.

Yes but I have found what often happened for me with with REPL environments is the actual code base would be littered with stuff to massage the REPL (commented out or left behind). At least with the unit tests that playing around stuff is away from the actual code.

For both cases there is always the delete button :) . Also for some reason many developers I have worked with don't seem to have a problem deleting or putting an ignore on a test. After all the tests are source controlled. I do get your point but I don't think its that strong.

> 2. Tests can only ever answer close-ended questions: "does this work?", but not "how does this work?", "what does this look like?" etc.

I fail to understand this point. I mean you can obviously write tests that just run stuff and not throw an exception or error. Furthermore you can share how you set stuff up with other developers.... and again you can just delete it if its obnoxious.

> 3. Tests typically won't run in real-world conditions: they'll use simple, artificial data and mocks of services such as databases or API clients. As a result, they don't typically help you understand a problem that only happens on real-life data, nor do they give you confidence that the real-life implementations of the services they emulate do work.

This is exactly what I do not like about REPLs. You setup a custom environment and its hard to keep track of what you have done. I don't like the "not repeatable" nature of it. I do think you make excellent points about how immutability helps that problem as stuff basically becomes a log but for other languages this is not the case.

However this is by far your strongest point. There are languages that allow you to play with a system while its running. Perhaps not through the command line but through a debugger. The Java debugger in Eclipse/IntelliJ can evaluate expressions and are not far off from being REPLs.... in some cases the debuggers are stronger than REPLs.

Re: What makes a good REPL?

#84

Post by _pmf_ »

Using Emacs' Elisp for a short while helped me unlearn some REPL antipatterns I acquired during Clojure development (some of them unfortunately presented in this article), especially this: instead of typing something in the REPL, executing it, then copying it back into your actual source file, you can just write it in your source file and use "evaluate current form" or "evaluate form before current point" to send it to the REPL process for evaluation instead of painstakingly entering it in the REPL and copying it back. Note that this is not a conventional hot-reload, but the form is sent as literal to the REPL (where indirectly, hot-reload may occur).

Re: What makes a good REPL?

#85

Post by abhirag »

agentgt wrote: post #47

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynam…

REPLs don't necessarily have to be ephemral, this is my REPL session(Jupyter Notebook) exported as HTML -- (http://abhirag.in/articles/train_of_thought_1.html), and also great REPLs can help in interactive static analysis, as a case in point consider the Idris REPL (http://docs.idris-lang.org/en/latest/reference/repl.html).

Re: What makes a good REPL?

#86

Post by junke »

yorwba wrote: post #78
junke wrote: post #67

Earlier quoted context omitted.

This is the kind of use cases where multiple dispatch is useful.

How so? I feel like single dispatch (as in Python) is already enough.

If you write a custom _repr_html_, you are likely to assemble subparts by recursively calling _repr_html_ on sub-elements (thanks to open recursion). If you have an object B which inherits from A, you can specialize on B, or use the existing method for A.

However, you cannot specializes the "html" part with inheritance. Say for example that you want to define a slightly different _repr_html_ method depending on the context (maybe you target the subset of HTML that works correctly in emails) or if you want to render "latex" with custom "tikz" macros instead of using matplotlib.

With multiple dispatch, you can specialize on the target too, which means you can specialize wherever required or fall back to a generic behavior if not.

Re: What makes a good REPL?

#87

Post by _pmf_ »

tikkabhuna wrote: post #66
agentgt wrote: post #47

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynam…

I'm interested to see how useful Java's REPL is going to be. Like you I will use a JUnit test, or maybe a standalone class with a main method, to test a small bit of code. With Eclipse's debug support I don't feel the need for a REPL.

> With Eclipse's debug support I don't feel the need for a REPL.

Clojure managed to make the tremendously powerful JVM debugging ecosystem completely useless (without providing any replacement with equal power).

Re: What makes a good REPL?

#88

Post by _pmf_ »

bitwize wrote: post #32
yoodenvranx wrote: post #4

Matlab has a nice sort-of-repl feature which I miss in every other language: you can separate the code in a file into several blocks and then execute the current block (the one with which contained the cursor) with ctrl+enter. With this feature you still have the full text editing capabilities but you also have a flexibility you get from a repl.

Most Lisp modes for Emacs have an eval-sexpr-at-point command which allows you to send the current sexpr to the REPL. This is in SLIME for CL but even the most basic Scheme mode has it as well.

Clojure's Emacs REPL also has this; it's strange that the article does not mention it, but talks about copying back and forth between REPL and suorce, which I consider a antipattern and really ugly workflow.

Re: What makes a good REPL?

#89

Post by agentgt »

pjmlp wrote: post #57
agentgt wrote: post #47

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynam…

REPLs are not ephemeral on Common Lisp environments. There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. On Mesa/Cedar's paper they refer that they wanted to provide the same experience as their Smalltalk and Interlisp-D environments. On Oberon's case, it required just recompiling/reloading a specific module, which given Oberon's compile speed, was pretty quick.…

> REPLs are not ephemeral on Common Lisp environments.

You'll have to patiently elaborate more for me. Do you mean because the editors keep track of it and that you are working with immutable/idempotent stuff? Otherwise IMO it is ephemeral because you are mutating things and you can forget what you have loaded and what not. I'm probably wrong though.

> There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind.

Yes many do including my favorite of OCaml's utop but not many allow hot code replacement for a currently running program. I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out.

> I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release.

I used Groovy as well but mainly because I didn't want to load a full IDE to test a couple of things. As I mentioned before I think with Eclipse/IntelliJ + JRebel + Debug attachment you can get damn close to a REPL.

And depending on how you define REPL I think hot code replacement + debugger might actually be more powerful than a REPL but I have to explore that thought some more.

Re: What makes a good REPL?

#90

Post by pjmlp »

agentgt wrote: post #89
pjmlp wrote: post #57

Earlier quoted context omitted.

REPLs are not ephemeral on Common Lisp environments. There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. On Mesa/Cedar's paper they refer that they wanted to provide the same experience as their Smalltalk and Interlisp-D environments. On Oberon's case, it required just recompiling/reloading a specific module, which given Oberon's compile speed, was pretty quick.…

> REPLs are not ephemeral on Common Lisp environments. You'll have to patiently elaborate more for me. Do you mean because the editors keep track of it and that you are working with immutable/idempotent stuff? Otherwise IMO it is ephemeral because you are mutating things and you can forget what you have loaded and what not. I'm probably wrong though. > There are/were true REPLs with static languages, Mesa/Cedar and O…

> You'll have to patiently elaborate more for me.

They are image based, so you can just save your session and continue using it later in another day.

> I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out.

On those systems, the unit of loaded code is a module and the whole OS only has dynamic libraries as executables.

So you can just reload a module and the next time you do module.proc on the repl, you will be referring to the newly loaded module.

For me an ideal REPL should be like the experience I used to have in Smalltalk.

Post reply on HN