Live data from Hacker News

What makes a good REPL?

vvvvalvalval.github.io

141–150 of 177 posts

Re: What makes a good REPL?

#141
post #134
post #94

Earlier quoted context omitted.

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

> I had no idea that common lisp had image saving! Lisp has image saving since around 1960...

I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.

Re: What makes a good REPL?

#142
post #138
post #83

Earlier quoted context omitted.

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

Yes that's me :) >> 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. Yes, but th…

> It's not that the environment is custom, is that it's real. Do you call your payment service or your mail sending service from your tests? This is exactly the kind of thing you want to experiment with in a supervised, non-repeatable way.

The irony you mentioning that is I have actually written "tests" that call braintree and stripe...

Just to clarify when I say "test" I don't mean some precise definition of "unit test" or "integration test". I mean in a runner that runs your code. Unit tests basically allow you to make a whole bunch of entry points (aka static main(args)).

I have many times setup a particularly environment and then repeatedly ran a unit test against that environment (I then commented or deleted that code later).

I think in large part of what your saying is good about REPLs is that they allow hot code swapping but that is only IMO really one part of the REPL. The key to really good REPL should be human input (think Excel) and human output (think images and graphs). There was a company recently shown on HN called Luna [1] and I think that is what a REPL should be.

And I particularly pick on this because you mention Bret Victor who is (err I guess was) actually working on environments like this.

Otherwise call it a unit test... call it a REPL... call it hot code swapping but in current JVM environments the difference can be pretty nebulous.

[1]: https://news.ycombinator.com/item?id=14612680

Re: What makes a good REPL?

#143
post #128
post #59

Earlier quoted context omitted.

Java 9 is also bringing one.

I'm curious what makes this superior to Beanshell. Or any other style of REPL that you could do on the JVM. Not against the idea, per se, but it seems hardly new ground. And unlikely to be nearly as powerful as a REPL in CL. (Though, again, few things are. Not sure that any are, to be honest.)

Well, Beanshell is dead, last update was on 2005.

Then there is a big advantage on having it as standard tool, instead of something done by third parties.

Re: What makes a good REPL?

#144
post #139

Earlier quoted context omitted.

> When I am thinking about a REPL the image I have in mind is of Jupyter Notebook and Clojure, Elixir, Idris, Haskell REPLs in Emacs Thats my point is that the REPL case of using Emacs to run and evaluate your code is almost hardly different than letting an IDE run your unit test. With Java this evident because the IDE compiles incrementally and the debugger can hot code swap. The power of the REPL should not be the…

> Thats my point is that the REPL case of using Emacs to run and evaluate your code is almost hardly different than letting an IDE run your unit test. With Java this evident because the IDE compiles incrementally and the debugger can hot code swap. Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions. This is more visible when we use more d…

I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :)

> Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions.

Hmmm an IDE is supposed to be a REPL and more. I mean you can go look up the definition from wikipedia.

> This is more visible when we use more dynamic languages/runtimes than Java/JVM. Since the changes one can do and how they need to be done is not very advanced, the usefulness of a REPL is reduced.

Yes I completely agree as I mentioned dynamic languages are far easier to modify at runtime. However for the case with Java it can be done with JRebel and various other tools.

Furthermore going back to the whole conversation vs letter an IDE with a powerful debugger will let you evaluate expressions based on a state that is stuck... ie setting breakpoint (as well of course as investigating current variables and such). This is damn useful for dealing with a multithreaded environment.

By the way make no mistake... I do love Lisp... I just think there are better things than traditional REPLs considering to your other point in another thread this stuff has existed since the 70s.

Re: What makes a good REPL?

#145
post #143
post #128

Earlier quoted context omitted.

I'm curious what makes this superior to Beanshell. Or any other style of REPL that you could do on the JVM. Not against the idea, per se, but it seems hardly new ground. And unlikely to be nearly as powerful as a REPL in CL. (Though, again, few things are. Not sure that any are, to be honest.)

Well, Beanshell is dead, last update was on 2005. Then there is a big advantage on having it as standard tool, instead of something done by third parties.

My question in that vein is more of "why will this succeed, where beanshell failed?"

That is, I had REPL style environments for java a long time ago. And literally nobody used it. I can see arguments for having the REPL being in actual Java instead of a shell subset. But, Java has a long way to go from bootstrapping something in a repl and automatically saving it to something that will work as a normal entry point. (Though, again, even JRebel has existed for a long time now.)

Re: What makes a good REPL?

#146
post #139

Earlier quoted context omitted.

> Thats my point is that the REPL case of using Emacs to run and evaluate your code is almost hardly different than letting an IDE run your unit test. With Java this evident because the IDE compiles incrementally and the debugger can hot code swap. Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions. This is more visible when we use more d…

I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :) > Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions. Hmmm an IDE is supposed to be a REPL and more. I mean you can go look up the definition from wikipedia. > This is more visible when we use more dynamic languages/runtimes than Java/JVM.…

> I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :)

The main difference: I have a Lisp Machine at home. :-)

> Hmmm an IDE is supposed to be a REPL and more.

No, a Read Eval Print Loop came from Lisp in the early 60s. It originally means to read a data structure, treat it as code and evaluate it and print the result data structure. READ, EVAL, PRINT are actual functions in Lisp. This stuff executes in a LOOP and is enriched by all kinds of stuff.

An IDE does not need to have a REPL. If it can interact with a running application (for example via a debugger), this might still not be a REPL.

> However for the case with Java it can be done with JRebel and various other tools.

Even JRebel can not do to a running JVM application what some Lisp implementations can do. Not near of that.

> IDE with a powerful debugger will let you evaluate expressions based on a state that is stuck... ie setting breakpoint (as well of course as investigating current variables and such)

This is pretty basic.

> traditional REPLs

Check out Symbolics Dynamic Windows and McCLIM on the Lisp side...

Old demos from me:

https://www.youtube.com/watch?v=VU_ELJjbnWM

https://www.youtube.com/watch?v=9whxPd4haKc

http://lispm.de/videos/lispm-3a.mov

Re: What makes a good REPL?

#147

Take a look at Smalltalk's environment and take a look a t Common Lisp's REPL. They have all the features that make for a good 'REPL'. (As noted before, REPL is a Lisp term that stands for: read - from keyboard input, parse the input string into the syntactic structure of the language eval - eval the expression, this includes binding variables or defining new functions, also re-defining functions, even if such functi…

> Common Lisp's REPL

The SBCL and CCL REPLs do not support readline-style editing. This actually makes them infuriating to use outside of Emacs or some other IDE-like environment. There is definitely a market for a high-quality, implementation-independent Lisp REPL.

Re: What makes a good REPL?

#148
post #134

Earlier quoted context omitted.

> I had no idea that common lisp had image saving! Lisp has image saving since around 1960...

I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.

> given that is apparently how you distribute executable lisp code

LispWorks can:

* save images

* create optimized images/applications for delivery, using a treeshaker for removing unused stuff

* can generate Mac applications with the usual ceremony/ application bundles

* can generate shared libraries which can be linked into programs written in C or similar

Some other compilers can generate standalone C code doing whole-program compilation. For example mocl or some inhouse compilers used by companies.

Re: What makes a good REPL?

#149

Take a look at Smalltalk's environment and take a look a t Common Lisp's REPL. They have all the features that make for a good 'REPL'. (As noted before, REPL is a Lisp term that stands for: read - from keyboard input, parse the input string into the syntactic structure of the language eval - eval the expression, this includes binding variables or defining new functions, also re-defining functions, even if such functi…

> Common Lisp's REPL The SBCL and CCL REPLs do not support readline-style editing. This actually makes them infuriating to use outside of Emacs or some other IDE-like environment. There is definitely a market for a high-quality, implementation-independent Lisp REPL.

rlwrap FTW

Re: What makes a good REPL?

#150
post #146

Earlier quoted context omitted.

I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :) > Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions. Hmmm an IDE is supposed to be a REPL and more. I mean you can go look up the definition from wikipedia. > This is more visible when we use more dynamic languages/runtimes than Java/JVM.…

> I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :) The main difference: I have a Lisp Machine at home. :-) > Hmmm an IDE is supposed to be a REPL and more. No, a Read Eval Print Loop came from Lisp in the early 60s. It originally means to read a data structure, treat it as code and evaluate it and print the result data structure. READ, EVAL, PRINT are actual functio…

I think I'm in agreement with you. What I meant by the IDE is that "ideally" it should have REPL like offerings if the language can support hot code swapping.

I still don't think its REPL that makes Lisp or clojure magic (when I say magic I mean awesome). Its all the other stuff like macros and homoiconicity (which I see your point plays some part in academic REPL).

> Even JRebel can not do to a running JVM application what some Lisp implementations can do. Not near of that.

Well thats because of the Java compiler and in some parts the language of Java. It has nothing to do with the JVM otherwise Clojure wouldn't work. But I agree JRebel is far cry from the full reloading capabilities of Lisp, Erlang and other dynamic languages.

> IDE with a powerful debugger will let you evaluate expressions based on a state that is stuck... ie setting breakpoint (as well of course as investigating current variables and such)

> This is pretty basic

I agree but its still surprising how many languages do not do this well and I didn't mention that you can execute simple expressions in that mode something other static languages like C will not allow.

Besides.... I can change a function name in Java or Scala and see immediately everywhere in my code base with (e.g. red squiggle lines) how that impacts other code... for static languages that is pretty basic :P

I'm totally envious of your lisp machine (EDIT: in all honesty...I realize that originally sounded sarcastic).

Post reply on HN