Live data from Hacker News

What makes a good REPL?

vvvvalvalval.github.io

91–100 of 177 posts

Re: What makes a good REPL?

#91
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…

I'd even say immutability can be a disadvantage.

I normally only use a repl when I don't know what I'm doing.

My normal process with a repl in an immutable language goes like this:

1. Assign something to a name

2. Realise that was wrong, try again.

3. Get told no. Remember to tell the repl to forget the wrong one and do it again (or choose a new name).

4. Try to assign something else to another name (probably 'foo')

5. Realise that I already used foo about an hour ago in a different experiment, and hadn't closed the repl in between.

Immutable is great for actual programming. Less so for quick experiments.

Re: What makes a good REPL?

#92
post #85
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 ).

Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text.

Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outputs are better.

That is traditional REPLs (ie commandline with maybe some readline capabilities) I think aren't that much better the inputs/outputs aren't that good.

To your point on the static analysis I agree but a truly interactive development system that allows google-esque querying I think is far more than a REPL or at least the REPLs I know/knew of but I guess REPL definition can be somewhat nebulous these days.

Re: What makes a good REPL?

#93
> Data literals. That is, the values manipulated in the programs have a textual representation which is both readable for humans and executable as code. --8This is not a dig at Kotlin/Java/Whoever but it bugs me (coming from Ruby) no end when regexen don't get to have a regex literal syntax and a match operator. I was going through the Kotlin language docs last night and its such a concise language with well thought out syntax and this omission jumped out at me.

Is it me? Do others really not think it's a big deal? I learned how to code via BASIC then ASM then C and early C++ and none of these had regex literals so for the longest time I literally (hah) did not know what I was missing. Now I can't imagine why a language wouldn't have them. I guess Ruby shows its Perl heritage. But Javascript has 'em, you go Javascript, and thus Typescript. And don't get me started on raw strings """Yuck!""" dear Lord, how gruesome. I think how Perl6 is brace savvy is the way forward. I'd also like to be able to specify my own braces to construct my own type as a shorthand, that'd be great DSL, so that,

     i = %something%
would construct an instance of type Foo assuming the correct %T% (by way of example) constructor syntax. That'd be neat-o.

Re: What makes a good REPL?

#94
post #90
post #89

Earlier quoted context omitted.

> 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 a…

Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments).

I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.

Re: What makes a good REPL?

#95
post #92
post #85

Earlier quoted context omitted.

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 ).

Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text. Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outp…

The interactive development workflow in Idris is best described as type driven development and the focus seems to be on making the REPL an interface where an intelligent dialog can happen in between the programmer and the compiler, with the compiler trying to nudge you in the right direction. It is kinda fun, you should definitely check it out[1].

And regarding your point about the modern IDE workflow, I personally think that the sweet spot is somewhere in between, I personally prefer having a REPL process in the background I can interact with while still writing code in my source file and a REPL kept open as a scratch space where I can experiment freely without messing up my source code, I feel much better experimenting in a REPL, but to each his own I suppose :)

Jupyter Notebook is a completely different beast though, modern REPL + literate programming, what's not to love.

[1] -- (https://www.manning.com/books/type-driven-development-with-i...)

Re: What makes a good REPL?

#96
post #71
post #63

Earlier quoted context omitted.

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-not…

That is partially what I was referring to. The other part, which might not be visible on that video is the integration of debugger into the REPL, and the ability to redo a piece of code after breaking into the debugger and fixing it. So you can do something like, REPL => error (ask to start debugger) => track down and fix error => restart error expression => finish the execution of the original REPL expression with t…

SLIME doesn't give you this?

Re: What makes a good REPL?

#97
post #91
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…

I'd even say immutability can be a disadvantage. I normally only use a repl when I don't know what I'm doing. My normal process with a repl in an immutable language goes like this: 1. Assign something to a name 2. Realise that was wrong, try again. 3. Get told no. Remember to tell the repl to forget the wrong one and do it again (or choose a new name). 4. Try to assign something else to another name (probably 'foo')…

I think there may be some confusion here, immutability is about the stability of values (e.g. I have a string, list, map etc and I want to pass it to others, view its value, make changes without affecting the original value).

Immutability is not the same as rebinding a name (in clojure at least) e.g. the following is perfectly valid (global and local binding of the same name repeatedly)

  (def a 1)
  (def a 2)
  (def a 3)
  (println a)
  => 3

  (let [a 4
        a 5
        a 6]
     (println a))
  => 6

Re: What makes a good REPL?

#98
post #95
post #92

Earlier quoted context omitted.

Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text. Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outp…

The interactive development workflow in Idris is best described as type driven development and the focus seems to be on making the REPL an interface where an intelligent dialog can happen in between the programmer and the compiler, with the compiler trying to nudge you in the right direction. It is kinda fun, you should definitely check it out[1]. And regarding your point about the modern IDE workflow, I personally t…

I have been meaning to look at Idris for so long! Thanks for the inspiration to move that higher up the queue :)

Re: What makes a good REPL?

#99
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…

Java is getting a REPL though. I believe it is part of Java 9 ;).

However to the author's point I believe some languages are inherently superior for REPLs particularly if they have powerful literal syntax.

Java is not a fun language to type expressions in and IMO neither is Python albeit for completely different reason. I can elaborate more if you like but I think most will agree.. Java will be a pain to type in a REPL.

Re: What makes a good REPL?

#100
post #87

Earlier quoted context omitted.

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).

As a person who has used the standard java debugger in intellij for clojure, could you expand on what features are missing?

I find I don't get much use out of it anyway, due to immutable values and (mostly) pure functions I find I don't usually need the whole program to be running and frozen in time.

However, I'd like to know what I'm missing.

Post reply on HN