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

131–140 of 177 posts

Re: What makes a good REPL?

#131

Post by agentgt »

abhirag wrote: post #118
agentgt wrote: post #109

Earlier quoted context omitted.

I'm not against REPLs I just think they have been around since early Lisp and there are vast improvements that can be made. I use REPLs all the time... Bash is basically a REPL :) The reason I think Java REPL would be awful is not because I dislike REPLs but because Java is really painful for that kind of mutable command line like development. Like just making a damn struct like object is absolutely painful and Java…

Fair enough, I think I am having difficulty in understanding your views because firstly I have never worked with Java, closest language I have worked with is C# and I don't particularly dislike its REPL, its nothing to write home about but I don't particularly hate it either. Secondly the image we two have in mind of a REPL seems to be different. When I am thinking about a REPL the image I have in mind is of Jupyter…

> 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 evaluation portion but the input or the print otherwise you can just about do any quick evaluation for any language that compiles reasonable fast.

Other than Jupyter Notebook the ones you mention don't really have any amazing output other than pretty print. To the authors point it also helps for the pretty print if the language is homoiconic.

As for input there is even fewer that have Excel like rapid response feedback. See Bret Victor on this. There was a recent company presented here on HN called Luna [1] who have a very cool REPL. Now that is where I think REPLs should be.

> P.S. I didn't get your point about python having nominal types, duck typing seems closer to structural typing to me and mypy seems to support both, but maybe I misunderstood you. Thanks for the thought provoking discussion though :)

For the most part you need to name functions in Python (lambda support I believe is even on the way out but I can't recall the status). In fact other than I guess tuples you need to name everything in Python.

But to your point structural typing means less in a duck typing environment particularly one with really late dispatch.

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

Re: What makes a good REPL?

#132

Post by agentgt »

stevedonovan wrote: post #115
agentgt wrote: post #109

Earlier quoted context omitted.

I'm not against REPLs I just think they have been around since early Lisp and there are vast improvements that can be made. I use REPLs all the time... Bash is basically a REPL :) The reason I think Java REPL would be awful is not because I dislike REPLs but because Java is really painful for that kind of mutable command line like development. Like just making a damn struct like object is absolutely painful and Java…

I have to agree about Java, but hundreds of thousands of people seem to be happy using Python REPL, even if just to discover an API. At least it _does_ have a literal syntax for things like maps.

Yeah the Python one was a stretch and I often use the Python REPL as a calculator (I have no real strong idea why but I guess because numpy is what I know).

Re: What makes a good REPL?

#133

Post by kqr »

frobozz wrote: post #108
joncampbelldev wrote: post #97

Earlier quoted context omitted.

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

I see. When I see "immutable", I think of Prolog and Erlang (e.g. once X is 6, X can't be matched to 5 in the same scope) rather than languages that simply prefer byval over byref.

Unification and assignment are very different concepts, though, with only fleeting similarity in some cases.

Re: What makes a good REPL?

#134

Post by lispm »

agentgt wrote: post #94
pjmlp wrote: post #90

Earlier quoted context omitted.

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

> I had no idea that common lisp had image saving!

Lisp has image saving since around 1960...

Re: What makes a good REPL?

#135

Post by gumby »

baldfat wrote: post #111
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…

> Lisp doesn't have immutable data structures Racket does have immutable data structures and Dr. Racket has a good REPL IMHO. http://beautifulracket.com/explainer/data-structures.html

That's the converse of my point. The article claimed immutable data is important for a good REPL and I said that the claim was an overstatement. I didn't say that immutable data makes a REPL impossible.

I quite like immutable datastructures, as it happens.

Re: What makes a good REPL?

#136

Post by igravious »

junke wrote: post #103
igravious wrote: post #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. --8 This 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…

> 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 That's the purpose of readtables in Common Lisp, defining custom readers for converting external representation to internal ones.

Thanks, I'll check it out.

Re: What makes a good REPL?

#137

Post by valw »

joncampbelldev wrote: post #97
frobozz wrote: post #91

Earlier quoted context omitted.

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

Indeed, by immutability I really meant immutability of the values, but not of the name bindings. So I would say an optimal setup is to have a mutable execution environment which handles immutable values.

Re: What makes a good REPL?

#138

Post by valw »

agentgt wrote: post #83
valw wrote: post #70

Earlier quoted context omitted.

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 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 the point is that a test mostly gives you a Yes/No answer, not a visualization. What's more, sometimes you need to set up a fair amount of state as you explore (think of the examples in the video, where you call an external API based on a previous result of that external API etc.) - not something that is convenient to do in a test.

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

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.

You can put stuff in the REPL, or in your test suite, or both, and there are pitfalls in each case, but at least you have a choice; indeed, you have to use your best judgement to decide what will be persisted, repeated and shared with your team and what will be forgotten after your REPL session end, but I wouldn't call making the wrong choice a deficiency of the REPL, rather an error on the programmer's side.

Re: What makes a good REPL?

#139

Post by lispm »

agentgt wrote: post #131
abhirag wrote: post #118

Earlier quoted context omitted.

Fair enough, I think I am having difficulty in understanding your views because firstly I have never worked with Java, closest language I have worked with is C# and I don't particularly dislike its REPL, its nothing to write home about but I don't particularly hate it either. Secondly the image we two have in mind of a REPL seems to be different. When I am thinking about a REPL the image I have in mind is of Jupyter…

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

Re: What makes a good REPL?

#140

Post by RyanHamilton »

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 also used junit as a semi-REPL similar to how you describe. then I started playing with a REPL for a fully dynaimic language and when I came back to java, there were parts that I missed.

So I actually created a java REPL: http://jpad.io

I would say the things it does that the typical junit run does not are:

1. Explorative queries, send sql statements see the results quickly. What particularly helps here is that any collection is converted to a table with each column representing a getXXX method.

2. Command line instant queries. Sometimes I just want an advanced calculator on the command line. I do "jpad -e 2+2" and it returns 4. No messing around with IDEs.

3. Automatic smart guessing of imports and ability to upload results straight to website to share with colleagues.

That's what I liked, so I built it in. The lack of traffic may suggest others did not find it as useful :)

Post reply on HN