Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Repl-Driven Programming

mikelevins.github.io

Post reply on HN
Print view View original

191–200 of 210 posts

Re: On Repl-Driven Programming

#191

Post by oblio »

adamkl wrote: post #82
irjoe wrote: post #78

Earlier quoted context omitted.

Interesting. I do the same thing in Elixir where I'll attach an iex session to a Phoenix application so I can interrogate modules and APIs as I'm building them out. I'm slightly disappointed that it's already something I do day to day. I had hoped that the power of the REPL wasn't overstated.

I think just because someone is able to do something similar in another language doesn’t mean that the power of a fully integrated REPL is overstated. Most developers are using languages where this sort of thing isn’t possible, and for them, experiencing a REPL driven development flow can be an eye opening experience (even if it’s just to add it to their tool box along side more common approaches like attaching debug…

> Most developers are using languages where this sort of thing isn’t possible

Which language can't do this?

Re: On Repl-Driven Programming

#193

Post by mikelevins »

nsm wrote: post #185
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…

> 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? Modern Smalltalks have solved this problem. Smalltalk has the concept of Packages just like Java, and as you go along building your environment, even though you are modifying…

Thanks for contributing from a Smalltalk perspective.

Yes, you're right: as I've repeated several times, when I say "repl-driven programming", I am not talking about a repl window or a command-line shell. I'm talking about the actual read-eval-print loop, the runtime feature that reads input, evaluates it, and presents results. I'm talking about a language and runtime that is designed to be modified while it runs by evaluating incremental changes offered interactively by the user.

It's not about a prompt in a terminal. It's about a software-construction system that is designed to be modified interactively as it runs. Smalltalk is quintessentially that.

It seems like some folks have encountered a repl UI with a prompt in a terminal and jumped to the conclusion that this specific kind of UI is the repl. It isn't. It's one particular kind of UI for a repl. There are others, and there have been others since forever. For heaven's sake, Smalltalk 76 had other kinds of UI for its repl in, well, 1976.

Re: On Repl-Driven Programming

#194

Post by mikelevins »

tylermw wrote: post #107
mikelevins wrote: post #92

Earlier quoted context omitted.

So go ahead and set up that working situation and try this: Define a function foo() in one module that calls a function bar() in another one, but don't define bar(). Now call foo(). Now, in the debugger that you break into, give a definition for bar(), and resume the execution of foo(). Don't quit the program and restart it; that's cheating! If that works fine, please tell me what tools you're using, because they'll…

I don’t know about MATLAB, but everything you describe is trivial to do in R. Being dropped into the debugger is standard on most R installs (it’s an option you can turn off) and everything you mentioned can be done in the REPL.

So I tried this with R:

1. Define an S4 class.

2. Create an instance of the S4 class (let's call it A).

3. Redefine the S4 class.

4. Examine A.

R complains that there's an error in slot(object, what), because A is missing a slot from the (re)definition of the S4 class.

This is promising, in that R realizes that A is supposed to be an instance of the redefined class. So far, so good.

What I would expect to see next is that either R automatically reinitializes A with the new slot (it has exactly as much information about the new slot as it had about the old ones when I created A), or, if it wants intervention from me, it presents an interactive session I can use to tell it how to initialize the new slots.

It didn't do that, but maybe I just don't have the options configured properly to make it happen.

Smalltalk and Common Lisp meet my expectations: they notice that A is an instance of a redefined class and they either reinitialize the instance automatically, or they present an interactive session that I can use to tell them how to do it.

It's entirely possible that R has this feature and I'm just missing it because I'm a noob.

Re: On Repl-Driven Programming

#195

Post by kernelsanderz »

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…

I use a vim plugin called slimux to send code from vim into a REPL running in another tmux pane. It works really well.

Here's the fork that I'm currently using https://github.com/grusky/slimux

I use it with python and node.is and MySQL and psql

It's great because it can work with any REPL.

I used to use jupyter notebooks but almost exclusively use slimux now unless I need to some data visualisation or computer vision.

VS code's ipython REPL is quite good and has support for images and graphs.

I will say that the main thing that triggered a REPL driven workflow was dealing with large state. When you do machine learning and you have to deal with large models and datasets, loading them each time you save your code and triggering a unit test really gets tedious. You can definitely do it with caching and reducing the dataset size, but it only gets you so far IMO. There's nothing like being to inspect the state of your environment. Particularly when it takes a long time to create that state.

Re: On Repl-Driven Programming

#196

Post by lebuffon »

0x445442 wrote: post #138
mikelevins wrote: post #90

Earlier quoted context omitted.

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.

Forth's answer to your need is: Write your own higher level utilities in Forth. :)

I find it better to think of Forth as a clever Macro Assembly language for a two stack VM.

When used as designed, one does not actually program in Forth. You first write a tiny "language" and program the App in that.

Not a popular choice today.

Re: On Repl-Driven Programming

#197

Post by Jtsummers »

webmaven wrote: post #177
Jtsummers wrote: post #176

Earlier quoted context omitted.

Only if you aren't delivering something. No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. If you write something in the REPL and never convert it to a proper function/class/struct/package in source, you're hosed when your system reboots and that image is lost. This requires no more discipline than, say, actually committing files to a version control system…

> No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. Oh man, you are so wrong about that. It's worth noting that this style of development also hamstrung quite a few Python web app projects in the late 90s because the Zope application server encouraged the use of this style of development (except through a browser rather than the command line) and beginners e…

I used the "sane" qualifier for a reason. Development like that is insane and moronic. It's unsustainable in the long term, and is not a counterargument to the idea of REPL-Driven Programming. REPL-Driven Programming does not preclude sanity and replicability and source files.

Re: On Repl-Driven Programming

#198

Post by nikhizzle »

Jugurtha wrote: post #45
nikhizzle wrote: post #29

Earlier quoted context omitted.

I also recommend jupyterlab for a similar experience. I was a hardcore vim terminal guy for 17 years, but now I won’t be going back. The ability to interactively develop functions in almost any language inside the same environment had been revolutionary for my productivity given my short attention span.

Would you mind sharing what you're doing with JLab? Do you use it in machine learning or are you doing something completely different?

Some amount of data science, some amount of node development of various kinds. Only about 10% ML work.

Re: On Repl-Driven Programming

#199

Post by randomswede »

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.

Potentially. But, as with all things, there's "the way you could do things" and "the way you should do things". Just because you can do manual testing doesn't mean you should avoid automated testing. It MAY be useful to do some manual exploration to find suitable test cases, but once found, they should totally be conserved in source.

It may also be faster to find an issue in the REPL, using various tracing tools ("hm, this function returns the wrong thing when I feed it X, let us enable tracing on a few things and see if anything stands out", followed by "aha, that other function over there is actually the problem, let me add some test cases, so we don't have a regression there").

None of these are impossible without a REPL, but may require extensive modification of the source and a recompilation to get the same effect (followed, probably, by either converting your tracing to debug logs, guarded by a verbosity flag, or by painstakingly track down each print and rip it out again).

Re: On Repl-Driven Programming

#200

Post by sfsys »

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…

I've been doing exactly this for a while now using Emacs built-in python mode and I think it's its quite nice. With just a few keystrokes I can send any part of the code I'm working on into a running python process and see the results in a separate repl buffer. The built-in python-mode already has a good selection of possible selections to send and I've written two extra ones working with indent levels dependent on where the cursor currently is. [1] It's nice to be able to, for example, run the if statement you're currently writing without running the while loop that if statement is in.

One important thing to keep in mind though is that it is not as dynamic as Lisp, so things like re-evaluating a class definition does not update existing objects. I end up restarting the python process and evaluating the buffers I'm working on often enough that I've bound it to its own key.

[1] https://pastebin.com/ctz5erD4

Post reply on HN