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

61–70 of 177 posts

Re: What makes a good REPL?

#61

Post by tedmiston »

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…

One nice thing about the Python REPL IPython is the ability to turn the ephemeral session into a file which contains every command in the session like a history file by just typing %logstart. Most of my projects start this way.

Re: What makes a good REPL?

#62

Post by gumby »

I am not convinced that immutability matters; this seems like a bias. After all the original REPL, and the name itself, was in Lisp (note that the first Lisp implementations were not interactive, but it was the first interactive language) and Lisp doesn't have immutable data structures.

(READ, EVAL, and PRINT are all old Lisp primitives, and the REPL was literally implemented with them. There's also a complex macro called LOOP but it was added much later, and is not integral to the language)

Re: What makes a good REPL?

#63

Post by abhirag »

pjmlp wrote: post #58
mclehman wrote: post #5

Earlier quoted context omitted.

Lisp + Emacs + SLIME: miss no longer. Picking them all up is a tall order though.

Emacs suffers from not being like Lisp machines REPL, meaning lacking graphical display on buffers. If I remember correctly, XEmacs used to support it (which was my favorite fork), but it seems to have faded away. For example, try to achieve this demo on Emacs. https://www.youtube.com/watch?v=o4-YnLpLgtk

I have never used a Lisp Machine so forgive my naivety but I saw the demo and you seem to be referring to the ability of displaying images inline in a buffer. Emacs can definitely do that, I have used Emacs IPython Notebook[1] which is a REPL supporting this. I could fire up a jupyter notebook and use pillow[2] to recreate the image manipulation part of the demo.

[1] -- (https://github.com/millejoh/emacs-ipython-notebook/blob/mast...) [2] -- (https://python-pillow.org/)

Re: What makes a good REPL?

#64

Post by msangi »

I like the idea of accessible code. It seems the next level after testable code.

Code with a lot of mockable dependencies is usually considered testable but sometimes it's a pain to setup.

Accessible code seems to fix this. Instead of taking dependencies, return some data so it's easy to check what your component does in isolation.

Re: What makes a good REPL?

#66

Post by tikkabhuna »

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.

Re: What makes a good REPL?

#67

Post by junke »

yorwba wrote: post #65
chrissnell wrote: post #39

Pretty-printing of data structures in a human-readable format.

I think Jupyter has the right idea here with various kinds of repr -alternatives that can render html or images directly into the notebook. http://ipython.readthedocs.io/en/stable/config/integrating.h...

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

Re: What makes a good REPL?

#68

Post by valw »

hamandcheese wrote: post #6

There's a lot of excitement about compiled languages lately, and many seem to wonder if interpreted languages are dying. Unfortunately I don't see the value of a good REPL brought up in those conversations very often.

The compiled or interpreted nature of a language (or its runtime) is a fuzzy concept at best (Java is interpreted on the JVM in the sense that it emits bytecode that is interpreted by the JVM; the main implementation of Clojure JVM compiles Clojure to Java bytecode that eventually gets interpreted). The notion you're looking for is probably that of incremental compilation / running.

Re: What makes a good REPL?

#69

Post by valw »

gumby wrote: post #62

I am not convinced that immutability matters; this seems like a bias. After all the original REPL, and the name itself, was in Lisp (note that the first Lisp implementations were not interactive, but it was the first interactive language) and Lisp doesn't have immutable data structures. (READ, EVAL, and PRINT are all old Lisp primitives, and the REPL was literally implemented with them. There's also a complex macro c…

Author here. I could be wrong of course, but this stems from my experience in using a REPL from JavaScript. I hit 2 sorts of hurdle with mutability there: 1- I wasn't sure what I was viewing in the REPL was what the code of interest was perceiving, could have been changed afterwards and 2- immutable values were more suited for exploratory work due to their speculative nature, e.g I could try a function calls with variants of a data structure without 'committing' to them. Maybe I had a bad REPL experience in JS and blamed it on immutability; OTOH, maybe other people had a great REPL experience in Common Lips for other reasons, and attribute it to mutability. This certainly makes me want to give a new try to Common Lisp :)

Re: What makes a good REPL?

#70

Post by valw »

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?
Post reply on HN