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

111–120 of 210 posts

Re: On Repl-Driven Programming

#111

Post by TheAnswerMan »

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…

So REPL may make people less likely to document the code?

I don't see the correlation.

Re: On Repl-Driven Programming

#112

Post by discordance »

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…

Could this issue of expressing the journey be addressed by leaving code/markdown breadcrumbs in Juptyer notebook like cells?

Re: On Repl-Driven Programming

#113

Post by TheAnswerMan »

chris_j wrote: post #83
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 When I do REPL driven development in Clojure, that's exactly what I do and that's what other folks that I know mean by REPL driven development (in Clojure): define types, functions and variables in a source file, often…

You don't even need the "REPL" buffer to do REPL style development. You can just use the "eval" keybinds of your editor to eval the source code in the files.

For any test/scratch code, just create a scratch file outside your project and write the experiments there, eval'ing as you type. That file could even be an "official" unit test you include in the project.

Re: On Repl-Driven Programming

#114

Post by mikelevins »

O_H_E wrote: post #103
mikelevins wrote: post #91

Earlier quoted context omitted.

Yes, exactly. It's perhaps my fault for not making this more explicit in the essay, but the "repl" in "repl-driven programming" does not mean the repl window .

Yeah, I suggest you expand upon that, or perhaps another article showing that "conversation". Unfortunately, some people - including me - have only used a repl in "one-direction" and have to copy stuff back and forth.

That's a good suggestion. Walking through a set of interactions is a solid idea.

For what it's worth, there are some videos around of people actually doing it with Lisp and Smalltalk systems, and pjmlp already posted a pile of them elsewhere in this thread.

I can add a few more:

Kalman Reti walking through some interactions with a Symbolics LispM repl:

https://www.youtube.com/watch?v=o4-YnLpLgtk

Brian Mastenbrook demonstrating Interlisp's SEDIT structure editor in the Xerox Lisp environment:

https://www.youtube.com/watch?v=2qsmF8HHskg

Rainer Joswig (lispm here on HN) showing us a little bit of repl and Zmacs interaction on a Symbolics Lisp Machine:

https://www.youtube.com/watch?v=LIGt5OwkoMA&list=PLN1hNlVqKB...

Rainer again, showing some simple interactions with Macintosh Common Lisp, which was my daily driver for years:

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

Ruby programmer Avdi Grimm shows some things that he found cool about Pharo Smalltalk:

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

Dan Ingalls (one of the original authors of Smalltalk) in a 2017 demo of Smalltalk 76:

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

There are some other things I'd like to find for lists like this, but haven't been able to. In particular, a good demo of Apple's SK8 would be great.

If you can imagine a full-color Hypercard that could crack open and reprogram absolutely everything on the screen, including the machine code that drew the window system's widgets, all in a repl while the code was live; in which you could grab an arbitrary widget and drop it on the repl window to get a live variable reference to the widget, and then inspect it, operate on it, and reprogram it, again, while everything continued to run; in which you could build new window-system widgets by snapping together shapes and telling them to become widgets; in which you were not limited to HyperTalk for coding and text strings for data, but had a full Common Lisp at your disposal plus a Minsky-style frame system for representing data and knowledge, then you have some idea of what SK8 was like.

Re: On Repl-Driven Programming

#115

Post by dragonwriter »

> The catch is that the designers of your language system had to think that facility through in the planning stages. You don’t get a decent implementation of it by bolting it on after the fact. Breakloops need full access to the entire development system, interactively, with a computation and its call stack suspended in the breakloop’s environment.

Interestingly, while Ruby’s default REPL (irb) doesn’t have this, and Ruby’s (and irb’s) designers obviously didn’t think this facility through in the planning stages, Ruby does have an alternate REPL (pry) which has a lot of the advanced REPL functionality irb is missing but also doesn’t have this function built-in, but which does have a separate add-on (pry-rescue) which provides it.

Re: On Repl-Driven Programming

#116

Post by dragonwriter »

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…

> For example, some property of a function or object may not be documented at all, but through the REPL the writer has ascertained it is true. How can the reader know this?

Well, the writer could document their code.

Or, the reader could discover behavior of undocumented code the same way the writer did; presumably the “reader” will also have a REPL available.

Re: On Repl-Driven Programming

#117

Post by tester756 »

marcosdumay wrote: post #110
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…

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

Re: On Repl-Driven Programming

#118

Post by koz_ »

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…

The author of the code is going to have to discover how these APIs work somehow, right? Why would the code end up worse if the author has access to a particular tool for interacting with these APIs? A shell and curl is a REPL for interacting with and exploring HTTP APIs but I don't think anybody would claim that the use of such tools makes code written to those APIs harder to follow.

In fact, one of the benefits of your REPL being integrated with one's editor, and being in the language of the system, is that the kinds of ad-hoc scripts you write when doing exploratory / debug coding which one would typically discard after use can often times simply be committed, either as utility functions or test cases. Far from pulling up the ladder on devs who come later, having a REPL makes it more likely for them to have access to the same tools used to build and understand the system in the first place.

Re: On Repl-Driven Programming

#119

Post by discardable_dan »

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 set up as REPL-based development, Smalltalk and LISP both have to essentially ship their "whole environment" to deploy the application. This only works out well for small projects that do not need to be distributed, or whose distribution you, the developer, have a lot of control over.

(There's an aside to be said about building binaries from a LISP compiler, but most binaries I have seen produced by such compilers still need access to the required libraries, which sort of hoses it as a distribution solution. This could be a result of the build system used on the projects I work on.)

And your documentation concern is valid, but I think even worse is the design concern: when designing an API, you have to stop and design it and consider the various concerns. If you develop it as you need it / as you go, it is possible to arrive at sub-optimal designs. Hacking the "next piece" out at each step is likely to lead to slanted designs with poor APIs, requiring future refactoring. You see this with programmers at every level: if you ask them to write a program to do a single thing, then add more (related) capabilities, and continue ad nauseum, at some point the program will need to be refactored. This suggests that, without prior planning, REPL-based design is set up to incur technical debt. Unfortunately, my real-life experience confirms this. Moreover, refactoring something in a REPL is... a chore, to say the least.

Re: On Repl-Driven Programming

#120

Post by tmsh »

Having gone through Rustlings these past few days (via https://users.rust-lang.org/t/best-way-to-learn-rust-program...), I feel like the speed of the Rust compiler has gotten a lot faster since I looked at it a few years ago.

And the compiler messages (once you get the hang of it; and the investment in learning the syntax is so trivially worth it in the long run) are so much richer and more helpful than other languages. So it really does "feel" like a REPL or most of the way there as a REPL (and I have one of the few wikis at our work advocating for Common Lisp that I wrote a year ago, and still actively follow Clojure groups, etc.).

It's just Rust starts and runs so fast (and Cargo makes it easy and clear like Go); so that being able to re-run periodically really fast is like a REPL. Yeah there's no retained state or ability to keep a REPL running for days, etc. (though Tmux.. and nix as a repl.... more on that later), but it's reached a point where compilation is an OOM faster than before, so the loop of: read, eval, print now can include the compiler.

And you get this amazing boost where if you're operating e.g. on large data (if you're a senior engineer, like Dan Luu blogs https://danluu.com/, you're often scanning codebases or log files or other metadata to answer questions); so being able to tweak and re-run even without caching at OOM faster speeds than other languages is wonderful.

I can create complex refactoring scripts in Rust on GBs of data and constantly re-run them until it's just right.

To my knowledge you can learn the ins and outs of CL or Rust; both fairly specific-knowledge-heavy languages at first (Rust with some syntax, CL with its non-uniformity of functions). It just seems like Rust is the future. It sort of "merges" dynamic languages with REPLs and *nix (with tmux) as the REPL. Pretty exciting.

And if someone wrote a CL-like REPL with something like SLIME/SLY for debugging for Rust it'd be kind of game over. And I could see that coming in the next few years (https://github.com/google/evcxr seems cool, but perhaps the dependency on Jupyter complicates it a bit).

Post reply on HN