On Repl-Driven Programming • Hacker News Board

Re: On Repl-Driven Programming

#131

Post by Folcon » Mon, Jan 04, 2021, 11:14 AM UTC

xkeysc0re wrote: post #124

ashtonkem wrote: post #72

Having used Clojure and Common Lisp professionally, I think advocates for REPL driven programming universally overstate the utility of a first rate REPL. Yes, it’s nicer than Python’s. Yes, it’s convenient. No, I never ended up doing my development in the REPL first . Why? Because editing mistakes in a REPL usually sucks, because a REPL is not a text editor. What I ended up using heavily was REPL to file integration,…

>What I ended up using heavily was REPL to file integration, which gave me the ability to write a function normally, evaluate it in the attached REPL session, and then play around with it in the REPL. This is far short of the “REPL driven development” that’s commonly discussed, and frankly something that’s probably possible with the Python REPL if they wanted to. I mean, yeah. You just import the Python module you're…

I'm personally of the opinion that this isn't the same thing and I'm saying this as someone who wants to do this in python.

Unless you've figured it out? In which case please say, because I want to code python like this.

Specifically I write code in my editor, hit a keystroke and all the code at the cursor gets sent to my running python and evaluated. The editor needs to be aware of python's indenting rules so it can do this, but once again if you've worked out a nice way to do this please say. Minimal keystrokes required would be great =)...

I'm not really requiring that the evaluated output gets sent to the editor, though of course that would be ideal, because in the worst case I can side-by-side the editor and the terminal.

From my perspective jupyter notebooks get kind of close, but I'm not coding in a file, so it's not quite ideal.

Re: On Repl-Driven Programming

#132

Post by marcosdumay » Mon, Jan 04, 2021, 12:49 PM UTC

tester756 wrote: post #117

marcosdumay wrote: post #110

Earlier quoted context omitted.

More than Lisp, SQL is a REPL-only language. The complexity you can achieve there without some interaction is very small. After some on the field experience, my conclusion is that this is not a large problem. Yes, you were not there on the initial design and does not have all of that acquired knowledge, but you can always run your own tests and formulate and verify your hypothesis. The REPL is there for debugging too…

>SQL is a REPL-only language. The complexity you can achieve there without some interaction is very small. ha ha. unless it's giant sql with 5 sub queries and poorly formated for bonus points good luck

Hum... 5 sub queries? Nope, I'm talking about bigger stuff.

Re: On Repl-Driven Programming

#133

Post by xg15 » Mon, Jan 04, 2021, 1:17 PM UTC

Question by someone who never used interacted development before: How do you save the results of your work? How do you ensure the state of your program is what you think it is.

E.g.: Imagine you're in a breakloop as described in the article. You find that local variable X is 5 when it really should be 4, so you quickly set it to 4. You find function foo() is not defined, so you define it. You continue and your program works. Great!

At the end of the day, you quit your environment and shut down. How do you ensure your interactive work is not lost and the environment is still what you expect it to be when you start again the next day. How would you compile such a program?

Is there some command that dumps the whole environment to a file as source code? Would you save your REPL history? Would you manually copy/paste relevant bits to s code file?

Also, if significant parts of the source code are written inside the REPL, wouldn't the lack of modern IDE features be a hassle? No syntax highlighting, no code completion, no code inspections etc. Or are there tools that offer those?

Re: On Repl-Driven Programming

#134

Post by mikelevins » Mon, Jan 04, 2021, 2:04 PM UTC

svnpenn wrote: post #125

mikelevins wrote: post #94

Earlier quoted context omitted.

As I said elsewhere, when I say "repl-driven programming", I do not mean "programming in a repl window", or "programming at a command shell". I'm talking about the runtime's read-eval-print loop, not the UI's repl window. When I'm working, there is little or no migrating of code from the repl buffer to a file because it's already all in a file. I almost always work in a file. I write snippets in a file, send them to…

If your code is in a file, and you're running the code from the file, that's not REPL. that's interpreting or compiling a file. REPL is opening interactive mode (if the language supports it) and entering "2+2". You calling anything else REPL is just wrong, misleading and confusing.

'REPL is opening interactive mode (if the language supports it) and entering "2+2".'

If I'm going to enter "(+ 2 2)" using my normal development tools, I'm probably going to start Emacs and tell it to start a SLIME session with one of the Common Lisps I use. When I do that, it'll create a repl buffer, because that's the way I have slime configured.

I mean, I don't have to load slime-repl. I could just interact with the Lisp's read, eval, and print functions directly from an arbitrary buffer without involving the SLIME repl display at all. But, y'know, force of habit. Also, I do occasionally type something in SLIME's repl buffer, especially if I want to see some big wad of output and don't want it spewed into the middle of the expressions I'm working with.

Most likely I won't type "(+ 2 2)" in the slime-repl buffer, though. I'm more likely to type it into a scratch buffer and send it to the Lisp by hitting C-x C-e. As soon as I start typing Lisp code, I know I'm probably going to want to add some more and maybe edit it and probably send it to the Lisp again. That's just more convenient if I have it sitting in a buffer in front of me, and not scrolling off the top of the repl buffer into infinity.

So am I working in a repl? Lisp is running a loop waiting for input. I'm sending expressions to it. It's reading them, evaluating the s-expressions produced by READ, and then printing the resulting values to a stream I can look at. Sounds like a repl to me. It's what I've always understood a repl to mean, including when I'm building them.

Does it count as working in a repl when I use a keystroke to send "(+ 2 2)" to the Lisp from the scratch buffer, or does it only count if I actually physically type the text in the buffer where the Lisp displays its prompt? What if there is no prompt? What if I start Lisp and SLIME but don't load the slime-repl extension? Does that mean that the loop that is reading, evaluating, and printing stops being a repl?

I'll probably save my scratch buffer to a file at some point, if there starts to be enough text in it that I think I might forget some of it. Does it stop being an interaction with the repl the instant I save the buffer to a file? I can save the slime-repl buffer to a file, too; does it stop being a repl when I do?

What about Lisp and Smalltalk environments where the read-eval-print loop doesn't display a prompt? Take a Smalltalk or INTERLISP worksheet, for example. Is it a repl if there's a loop reading, evaluating, and printing expressions, but no prompt? Does it stop being a repl if the incremental inputs and outputs get saved to a file? Does it count if it's not a text file, but the environment automatically saves the state of the worksheet to an image file that it automatically deserializes the next time you start the environment?

I don't think I'll adopt your lexicon, but I am sort of curious where its boundaries are.

Re: On Repl-Driven Programming

#135

Post by Izkata » Mon, Jan 04, 2021, 2:18 PM UTC

Folcon wrote: post #131

xkeysc0re wrote: post #124

Earlier quoted context omitted.

>What I ended up using heavily was REPL to file integration, which gave me the ability to write a function normally, evaluate it in the attached REPL session, and then play around with it in the REPL. This is far short of the “REPL driven development” that’s commonly discussed, and frankly something that’s probably possible with the Python REPL if they wanted to. I mean, yeah. You just import the Python module you're…

I'm personally of the opinion that this isn't the same thing and I'm saying this as someone who wants to do this in python. Unless you've figured it out? In which case please say, because I want to code python like this. Specifically I write code in my editor, hit a keystroke and all the code at the cursor gets sent to my running python and evaluated. The editor needs to be aware of python's indenting rules so it can…

> Specifically I write code in my editor, hit a keystroke and all the code at the cursor gets sent to my running python and evaluated. The editor needs to be aware of python's indenting rules so it can do this, but once again if you've worked out a nice way to do this please say. Minimal keystrokes required would be great =)...

...I call this "copy/paste". And since I use X clipboard and a tiled window manager, it's only a couple keystrokes and no mouse. Highlight the code in the editor, "super+" to switch windows, "shift+insert" to paste.

Re: On Repl-Driven Programming

#136

Post by 0x445442 » Mon, Jan 04, 2021, 2:19 PM UTC

svnpenn wrote: post #125

mikelevins wrote: post #94

Earlier quoted context omitted.

As I said elsewhere, when I say "repl-driven programming", I do not mean "programming in a repl window", or "programming at a command shell". I'm talking about the runtime's read-eval-print loop, not the UI's repl window. When I'm working, there is little or no migrating of code from the repl buffer to a file because it's already all in a file. I almost always work in a file. I write snippets in a file, send them to…

If your code is in a file, and you're running the code from the file, that's not REPL. that's interpreting or compiling a file. REPL is opening interactive mode (if the language supports it) and entering "2+2". You calling anything else REPL is just wrong, misleading and confusing.

I think most Lispers reckon REPL development the way it was described; analogous to editing code in a Smalltalk Browser and Doing/Inspecting it in a Smalltalk Workspace. WRT Smalltalk, you can Do/Inspect code in a Workspace and then create a class and copy it over but this typically isn't done that much.

Re: On Repl-Driven Programming

#137

Post by 0x445442 » Mon, Jan 04, 2021, 2:24 PM UTC

jmchuster wrote: post #122

ashtonkem wrote: post #72

Having used Clojure and Common Lisp professionally, I think advocates for REPL driven programming universally overstate the utility of a first rate REPL. Yes, it’s nicer than Python’s. Yes, it’s convenient. No, I never ended up doing my development in the REPL first . Why? Because editing mistakes in a REPL usually sucks, because a REPL is not a text editor. What I ended up using heavily was REPL to file integration,…

This is what I use as my canonical example of REPL-driven development. https://vimeo.com/230220635 The main thing that stands out to me is playing with small snippets of code in real-time as you're writing it. Contrast that with writing a class and methods, then writing unit tests, then running them. There might as much as ten minutes between the time you start writing your code and when you run any portion of it, an…

Having never developed code professionally in Lisp, my question would be; does the REPL work flow replace test code? Because if the REPL is being used as a replacement for tests, then I can see future readers having a harder time groking the code without the benefit of test driver code to analyze.

Re: On Repl-Driven Programming

#138

Post by 0x445442 » Mon, Jan 04, 2021, 2:29 PM UTC

mikelevins wrote: post #90

lebuffon wrote: post #46

Nobody has mentioned low-level programming in a REPL. Not as common to be sure. Forth works this way and even has REPL Assembly Language. It's been there for over 40 years. Testing Forth and ASM code snippets in the REPL before committing to them helps eliminate those nasty assumptions about what "should" work.

Agreed, FORTH is repl-driven in the sense I mean. The main difference from Lisp and Smalltalk systems is that FORTH environments are, generally speaking, more spartan. In the late 1980s I had a group of friends at Apple that included Smalltalk, Lisp, and FORTH programmers. We certainly found plenty of things to admire and attempt to steal from one another, and everyone accepted the basic goodness of building systems…

Yeah, Factor's environment looks really similar to something like Smalltalk. The thing with Forth is that it looks really daunting to perform higher level tasks that I'd be interested in performing on a day to day basis.

Re: On Repl-Driven Programming

#139

Post by mikelevins » Mon, Jan 04, 2021, 2:39 PM UTC

0x445442 wrote: post #137

jmchuster wrote: post #122

Earlier quoted context omitted.

This is what I use as my canonical example of REPL-driven development. https://vimeo.com/230220635 The main thing that stands out to me is playing with small snippets of code in real-time as you're writing it. Contrast that with writing a class and methods, then writing unit tests, then running them. There might as much as ten minutes between the time you start writing your code and when you run any portion of it, an…

Having never developed code professionally in Lisp, my question would be; does the REPL work flow replace test code? Because if the REPL is being used as a replacement for tests, then I can see future readers having a harder time groking the code without the benefit of test driver code to analyze.

I'd say it's more like tests grow naturally out of repl interactions.

Test-driven development as a discipline emerged from the Smalltalk community, and I don't think that's an accident. I think it's a formalization of the way that Smalltalk and Lisp programmers naturally tended to work.

I generally start on something by making a naive model of what I'm trying to accomplish and interrogating it. In successive iterations, I modify the model and the interrogations in the direction of what I need it to be, discovering details along the way.

I'd say that a majority of my actual activity is testing. That's one reason I prefer to interact with a repl from a file: because I want a record of my interactions. I want to be able to do them again and again.

The difference between that record and formal tests is a simple matter of copying the trail of my interactions into a test framework, and that, too, is how I normally work: make model; test it with interactions; keep the interactions around for later.

As I make progress, the models turn into data structures, and the interactions turn into functions and tests.

Re: On Repl-Driven Programming

#140

Post by nlitened » Mon, Jan 04, 2021, 2:41 PM UTC

xg15 wrote: post #133

Question by someone who never used interacted development before: How do you save the results of your work? How do you ensure the state of your program is what you think it is. E.g.: Imagine you're in a breakloop as described in the article. You find that local variable X is 5 when it really should be 4, so you quickly set it to 4. You find function foo() is not defined, so you define it. You continue and your progra…

The way I do it with Clojure, you never really write any code in REPL prompt directly. You write it in your source code file, then send a piece of code to the REPL to update the “in-memory” state of your running program.

So any modifications you make stay in your files, just like you would normally do with any other language. But you write your program while it’s running, and you grow/change it piece-by-piece, until it’s done (by that time, your source code is exactly your finished program).

If you want to re-start your REPL session, you just run your current file in the REPL as a whole, and maybe run some “Rich comments” (from the same file) to set up a limited test environment (to isolate the piece of program you’re working on).

This way, you make use of syntax highlighting and all the IDE features.

Edit: I’ve re-read your example with breakloop — I don’t really have experience with this style of REPLing. I agree that it raises a lot of questions, but thankfully functional nature of Clojure discourages this kind of programming.