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

171–180 of 210 posts

Re: On Repl-Driven Programming

#171

Post by wtetzner »

zmmmmm wrote: post #101

I have a concern about REPL driven development, which is around how maintainable the result is. The reason people like REPLs is because they can experiment to discover the right way to write the code in a very fast feedback loop. This alleviates a huge pain when you are operating with uncertainties or at the edge of your knowledge - 'does this function return null if no matching entries or an empty list?' - etc. The…

I really don't follow. If you're programming in a language without a REPL, don't you have the exact same problem? If the author doesn't document their knowledge, then it's lost for readers.

I don't really see how a REPL makes any difference there.

Re: On Repl-Driven Programming

#172

Post by Scarbutt »

reddit_clone wrote: post #165
zmmmmm wrote: post #101

I have a concern about REPL driven development, which is around how maintainable the result is. The reason people like REPLs is because they can experiment to discover the right way to write the code in a very fast feedback loop. This alleviates a huge pain when you are operating with uncertainties or at the edge of your knowledge - 'does this function return null if no matching entries or an empty list?' - etc. The…

When a certain thing is done in repl, it usually converts into a function or two in the source code. The ad-hoc testing code is converted into unit testing. That should help with maintenance no? One big theoretical advantage I see in repl driven development is, I can be sure that _all_ the code has been executed at one time atleast. (In a normal edit-compile-link-test language cycle, I can not be sure of that)

Sure, but the point is that it requires more discipline, since the REPL can encourage you to be more lazy/sloppy.

Re: On Repl-Driven Programming

#173

Post by reddit_clone »

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

You don't have to type up stuff in repl literally. You can write regular functions in emacs and send pieces of code to the running repl.

For adhoc testing code you can type on the repl buffer.

Re: On Repl-Driven Programming

#174

Post by fouric »

discardable_dan wrote: post #119
zmmmmm wrote: post #101

I have a concern about REPL driven development, which is around how maintainable the result is. The reason people like REPLs is because they can experiment to discover the right way to write the code in a very fast feedback loop. This alleviates a huge pain when you are operating with uncertainties or at the edge of your knowledge - 'does this function return null if no matching entries or an empty list?' - etc. The…

I have worked on massive LISP projects that were developed using REPL-driven development, and your fears are critically valid. Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it", which is, in my personal opinion, a completely unacceptable distribution model. And if you don't use emacs, good luck to you! Once se…

> Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it"

This seems like an incidental property (symptom of poor engineering discipline, which manifests itself in other ways in other development paradigms e.g. lack of documentation from "agile" teams) of the particular applications you've worked with and not an essential property of the (architecture decisions resulting from the) REPL-driven development style. What makes you think that this is actually due to REPL-driven development?

I develop several tools from the REPL and was able to easily convert each one to a standalone tool (when I attempted to do so).

Re: On Repl-Driven Programming

#175

Post by mikelevins »

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.

Oh, I forgot to mention that one of the cool features of Macintosh Common Lisp was its interactive assembler. You could write "LAP" ("Lisp Assembly Program") code in the repl, just like you could write Lisp code.

Around the time that MacFrames morphed into SK8, Apple hired an arcade-game programmer named Dave Vronay to work on the SK8 graphics subsystem. When I first met him, he was over the moon about MCL and how great it was to write assembly code in a repl and run it right now.

Re: On Repl-Driven Programming

#176

Post by Jtsummers »

Scarbutt wrote: post #172
reddit_clone wrote: post #165

Earlier quoted context omitted.

When a certain thing is done in repl, it usually converts into a function or two in the source code. The ad-hoc testing code is converted into unit testing. That should help with maintenance no? One big theoretical advantage I see in repl driven development is, I can be sure that _all_ the code has been executed at one time atleast. (In a normal edit-compile-link-test language cycle, I can not be sure of that)

Sure, but the point is that it requires more discipline, since the REPL can encourage you to be more lazy/sloppy.

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 to collaborate with others. Versus shouting from the hills, "It works on my machine!" and being confused when it turns out that you didn't commit "foo.c" and compiled it manually rather than updating your Makefile and committing both changes so others could use it.

Re: On Repl-Driven Programming

#177

Post by webmaven »

Jtsummers wrote: post #176
Scarbutt wrote: post #172

Earlier quoted context omitted.

Sure, but the point is that it requires more discipline, since the REPL can encourage you to be more lazy/sloppy.

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 eventually got to a point that they were stuck and needed to make the leap to a completely different workflow of development based on files on the filesystem and in version control instead for their code, while content (ie. application state) for each deployment of their app remained in the embedded object database.

A frequent lament was "if you knew I would eventually have to switch to filesystem based development, why didn't you have me start out that way?"

Re: On Repl-Driven Programming

#178

Post by mattmein »

Izkata wrote: post #135
Folcon wrote: post #131

Earlier quoted context omitted.

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…

One thing that has tripped me up with this workflow in the past is that you lose context - the code you copy/paste and execute in the repl is not evaluated in its module/namespace, so any other code calling it is not updated.

Is there a shortcut to evaluate the code in the correct module/namespace for Python? Maybe to switch the namespace in which the Python REPL evaluates the code you paste in?

Re: On Repl-Driven Programming

#179

Post by discardable_dan »

fouric wrote: post #174
discardable_dan wrote: post #119

Earlier quoted context omitted.

I have worked on massive LISP projects that were developed using REPL-driven development, and your fears are critically valid. Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it", which is, in my personal opinion, a completely unacceptable distribution model. And if you don't use emacs, good luck to you! Once se…

> Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it" This seems like an incidental property (symptom of poor engineering discipline, which manifests itself in other ways in other development paradigms e.g. lack of documentation from "agile" teams) of the particular applications you've worked with and not an ess…

The experience I have had on large, REPL-driven development is that continued development is assumed to also work under REPL-driven environments, so debugging or supporting them begins with "try typing X into your REPL." Many of the distributables I have seen also maintains REPL interactivity as part of the live deployment solution, with similar debugging solutions. While this may not be unilateral, "ship the deployment environment" seems to be a running theme.

I'm interested in your experience in avoiding this, and the process you used.

Re: On Repl-Driven Programming

#180

Post by discardable_dan »

mikelevins wrote: post #141
discardable_dan wrote: post #119

Earlier quoted context omitted.

I have worked on massive LISP projects that were developed using REPL-driven development, and your fears are critically valid. Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it", which is, in my personal opinion, a completely unacceptable distribution model. And if you don't use emacs, good luck to you! Once se…

Your observations are valid, and need to be kept in mind when developing in an exploratory, interactive way. Your alarm seems a little overblown. Maybe it reflects a particular bad experience? I've delivered a bunch of products built in the way I prefer to work, and it's been a long time since I've had the problems you're describing. Maybe that's because I ran into such such problems early in my career and learned wa…

Thanks for taking the time to respond. I wrote up my comment just to point out some of the weaknesses I have identified in REPL-based development, and how to watch out for those pitfalls as a program scales. For what it's worth, I agree with your sentiment, and believe REPL-based development should always be an option. I have a lot of success using REPL-based "prototyping", even in python, where I will quickly try/test something at a REPL before scaling it up, and having that utility to try/test/experiment quickly is often invaluable (especially if the standard build time is on the scale of minutes).
Post reply on HN