Live data from Hacker News

What makes a good REPL?

vvvvalvalval.github.io

41–50 of 177 posts

Re: What makes a good REPL?

#41
post #8
post #7

Earlier quoted context omitted.

I like a good interpreted language as much as the next guy, but there are REPLs for compiled languages. Pretty sure Scala has one and maybe Haskell

Though, they are lacking the magic of a REPL in CL. Hotspot replacement in JVM languages is neat compared to the magic of redefinitions in CL. And it seems nobody ever tries hooking a REPL up to a running system anymore.

Some of us still do in Clojure land for run-time debugging, though skipping the crazy state mutation stuff I've seen in eg CL.

Re: What makes a good REPL?

#42
post #15
post #9

Earlier quoted context omitted.

What do you mean with "picking them all up?"

They mean the learning curve is steep.

Ah, fair enough. The nice thing is most repl's have the same bindings as each other. So, some basic drills can get you up to speed.

Re: What makes a good REPL?

#45
post #35

Earlier quoted context omitted.

REPL stands for read-eval-print loop. So yes, it is just a prompt that you can put code into that will print a result.

A 'command line interface', for example for bash, does the same. What is the difference to a REPL? Is it just another name for the same concept or are there differences? What do you think?

Yes, it's technically a REPL, just as bash is a scripting language.

Re: What makes a good REPL?

#46

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.

Compilation and a REPL are orthogonal concepts.

Lots of Common Lisp systems have very good REPLs and compile to machine code. A popular example is SBCL.

Re: What makes a good REPL?

#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 dynamic. I'm not entirely sure why but static type languages are not very good at allowing code modification while running (I mean I have ideas but I don't know precisely if there is an actual theoretical limitation).

I guess I prefer static analysis over the complete ability to modify the code base while running.

Only add my 2 cents because the article doesn't mention any negatives to REPLs.

Re: What makes a good REPL?

#48

Earlier quoted context omitted.

They aren't really REPLs. A REPL isn't just a prompt that you can put code into.

REPL stands for read-eval-print loop. So yes, it is just a prompt that you can put code into that will print a result.

If you want to be literal about it then sure, it just means read-eval-print loop. But I think that's akin to saying that a functional programming language is a language that has functions in it.

EDIT: To be clear, what I'm saying is that when people say 'I really love using Common Lisp because it has a REPL' they aren't saying 'I really love using Common Lisp because it has a prompt I can write raw strings of code into that executes that code and has no other features'. That's not a lovable feature.

People love Lisp REPLs because there's much more to them than that. In Lisp, the REPL is more like GDB than it is like Python's REPL.

Not really sure why the reaction to my comments here is so viscerally negative. Very few terms that we use are wholly literal. REPL isn't literal either.

Re: What makes a good REPL?

#50
post #21

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.

I don't think there's anything fundamental about a compiled language that prevents it from having a REPL. (If anything, you could always have a dedicated interpreter for interactive work—"compiled" and "interpreted" are functions of the implementation , no the language .) In practice the compiled languages I've used extensively (OCaml and Haskell) do have REPLs, but ones that aren't nearly as powerful as some other l…

> If anything, you could always have a dedicated interpreter for interactive work

CMUCL does that. There's an interpreter that's used for the REPL and optionally for loading files on the fly, and an optimizing AOT compiler.

SBCL drops the interpreter and just runs the compiler with settings that make it reasonably fast for interactive use as I recall. Clojure, too just uses the compiler interactively and not a separate interpreter.

Post reply on HN