Live data from Hacker News

On Repl-Driven Programming

mikelevins.github.io

101–110 of 210 posts

Re: On Repl-Driven Programming

#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 problem is that the reader of your code is not going on that journey with you. They are coming in naively without knowing all of that experimentation you did. The writer now has the opportunity to create code that "just happens" to work by a magic of coincidences and conveniences based on very subtle non-obvious properties of the APIs and systems they are working with. The reader is severely disadvantaged and will have a much harder time to reach parity with the state of knowledge that the writer had. 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?

So its a double edged sword in that the more you empower the original creator of the code, the greater imbalance you create to the later readers and maintainers of the code. Used well and with great discipline I could see it being very powerful and positive force to make better code. But in the worst case scenario, you'll end up with extremely unmaintainable code.

Re: On Repl-Driven Programming

#102

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

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…

Yeah, outside of simple use cases, I mainly interact with the clojure REPL by evaluating forms directly from my editor. It’s about being able to incrementally build something while having it running and updated as you go.

I also tend to often just reload changed namespaces and resetting the (component/mount/integrant based) application too. Or letting shadow-cljs live reload my clojurescript. But having the REPL directly accessible is still super useful.

Re: On Repl-Driven Programming

#103

Earlier quoted context omitted.

You write it in the editor and send statements to the REPL. You're not just sitting looking at a command line. The REPL is a conversation with running state, but the conversation doesn't have to take place only through a single blinking terminal window. In proper REPL-driven development, the editor is fully integrated with the running session, and you can evaluate either in an attached terminal session or through you…

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.

Re: On Repl-Driven Programming

#104

Earlier quoted context omitted.

Closer but still so far. As soon as you have more than one module in Python it completely falls apart, despite any autoreload magic. It just isn't the same at all as REPL based programming. In Lisps you can write your entire program with an instance and a REPL running the entire time. No restarting the instance required. It works because it's just how Lisp works. A REPL is a trivial thing you can write yourself that…

> Whenever I think about it I can't quite put my finger on exactly what Python would need to make it the same. It's something to do with the way imports and namespaces work, though. Python has a fundamentally broken module system, and Python 3 did nothing to fix it: https://nedbatchelder.com/blog/201908/why_your_mock_doesnt_w... https://docs.python.org/dev/library/importlib.html#importlib...

Right. That's it. Thanks for the links!

Re: On Repl-Driven Programming

#105
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 more you empower the original creator of the code, the greater imbalance you create to the later readers

REPL gives you more tools to shoot yourself in the foot, but you're not required to use those. Most programmers can write spaghetti code in many Turing-complete languages - not that they do that all the time.

In other words, REPL gives you powerful tools - which, yes, can be misused. They are still powerful, and can bring success when used well.

Re: On Repl-Driven Programming

#106
It seems like the closest thing to this in widespread use is a SQL database. If you want to change a table, you can run an ALTER TABLE command.

But of course you don't want to do this in the live, production database unless you're a DBA who is doing an upgrade manually for some (probably bad) reason.

So, you can try out your ALTER TABLE commands in a scratch database, but you'll need to save them to a migration script, and test the migration.

It seems like a weakness of this sort of live updating? Sure, you can modify your own running instance, but upgrading the production instance(s) will often still be a lot of work. Migrating a production database schema tends to be a tricky thing.

Re: On Repl-Driven Programming

#107

How is this different from, say, programming in Python and being forced to drop into a debugger whenever there is an error? The debugger also lets you see everything in the stack, modify definitions, etc. MATLAB and R both have options to drop you into a debugger if there is an error. Not sure if Python's debugger can do this, but other than that, this style of programming is perfectly doable outside of Lisp and Smal…

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.

Re: On Repl-Driven Programming

#108
post #71

I had no idea this was possible now, and to find it was commonplace for decades makes it even more amazing, and worrying what else I've missed. Thanks for sharing this here!

Be prepared to be amazed with what Xerox PARC and others were doing, while Bell Labs was busy pushing for UNIX. "Eric Bier Demonstrates Cedar" https://www.youtube.com/watch?v=z_dt7NG38V4 "Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0" https://www.youtube.com/watch?v=HP4hRUEIuxo "Documents as User Interfaces Video Demo" https://www.youtube.com/watch?v=0-_zVkrWCOk…

These lock-in IDE environments, while impressive, thankfully never got really popular.

I find superior languages like Lisp or Standard ML most enjoyable in text files.

Re: On Repl-Driven Programming

#109

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.

That's good to know; thanks!

Re: On Repl-Driven Programming

#110
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, not only for the original design.

Post reply on HN