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

121–130 of 210 posts

Re: On Repl-Driven Programming

#121

Post by thewebcount »

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…

> But in the worst case scenario, you'll end up with extremely unmaintainable code.

Actually, isn't it far worse than that? Say you're stopped at a function call, you call it, and it does the wrong thing. You edit a variable that's passed as an argument to the function and call it again. Now it does the right thing. Great! You fixed the bug, right? Except that you don't actually know that your program can actually ever end up in that state naturally.

Where did that variable originally come from? Was it entered by the user? Was it read from a file? Was it from a table? If so, does the table contain the modified value? This seems like a recipe for problems to me. I'm sure it's fine in simple cases where you're just changing the value of a constant or something, but it seems really likely to lead to incorrect reasoning about the code while you're working with it in any but the simplest of cases. Am I blowing this out of proportion?

Re: On Repl-Driven Programming

#122

Post by jmchuster »

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, and always running large chunks of changes.

Re: On Repl-Driven Programming

#123

Post by pjmlp »

vblxt wrote: post #108
pjmlp wrote: post #71

Earlier quoted context omitted.

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.

Look better around you.

- macOS, Windows, Android, ChromeOS

- InteliJ, Visual Studio, XCode/Playgrounds

Re: On Repl-Driven Programming

#124

Post by xkeysc0re »

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 writing and you can call any function or inspect any object you want. iPython even has hot reload

Re: On Repl-Driven Programming

#125

Post by svnpenn »

mikelevins wrote: post #94
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,…

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.

Re: On Repl-Driven Programming

#126

Post by dragonwriter »

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.

> 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.

It is not “interpreting or compiling a file” if the tool you are using to evaluate code in the file is sending isolated blocks of code to a REPL and not, well, interpreting or compiling the file.

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

No, a Read-Eval-Print Loop (REPL) is not exclusively used by a user typing keystrokes at a terminal; like other terminal software, it is a candidate for being driven by other programs.

> You calling anything else REPL is just wrong, misleading and confusing.

You insisting a REPL isn't a REPL when the “Read” part is reading something other than keystrokes directly entered by a human user is just wrong, ignorant, and confused.

Re: On Repl-Driven Programming

#127

Post by koz_ »

blandflakes wrote: post #76
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,…

I 100% agree with you and another comment: https://news.ycombinator.com/item?id=25622990 I spent years in Clojure and found that writing code in the REPL just... isn't fun. This has been true for every interactive system I've ever used (including... the shell). The shell as a REPL for a succinct language is nice for interactive workflows, but for trying to build less ephemeral pieces of code, the editor is the first…

I think what people mean when they say REPL-driven is to have a headless REPL that one never actually interacts with directly, but rather sends it snippets of code for evaluation directly from one's editor. Typing code into a shell prompt is excruciating by comparison.

I think this is a huge barrier of entry to languages like Clojure. The syntax and dynamic nature of the language really lend themselves to an extremely interactive and productive workflow, but that is a hard thing to communicate. It seems most people think that when Clojure programmers refer to the joy of the REPL they imagine writing code into Python or Ruby's REPLs (e.g. https://repl.it/languages/python3), but that is about as far from what is meant as is possible. I mean, who would enjoy programming in an environment that deleted your work every time you finished a line of code?

Re: On Repl-Driven Programming

#128

Post by tieze »

avl999 wrote: post #18

Is there a modern non-Smalltalk, non-Lisp (or its derivatives) non functional imperative programming language that supports a "real repl" that the author is talking about? I don't know if that kind of environment is for me but I'd love to give it a spin. I have never found the REPL (the Python/Ruby REPL which is not a "real repl" according to this article) to be that useful beyond quickly playing with API of a librar…

In Emacs you can set up Python in a (quite neutered) similar way. Whenever I change a function, I just evaluate the whole buffer to load it in the attached Python process, and will switch over to the Python process to play with it if need be.

Also, Forth sports a repl.

Re: On Repl-Driven Programming

#129

Post by boxmonster »

I've been doing debugger driven development my entire adult life and consider it a bad habit. I'm much better off and happier when I plan out and compile in my head. Then I get a good feeling when it compiles and runs the first time. If not, then I need to think about it some more, not sit in the debugger trying things out.

Re: On Repl-Driven Programming

#130

Post by tareqak »

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…

If there was a way to “playback” the REPL and store it for later, then it would be possible for the subsequent users (or even the same user) to see how the person using the REPL got to that point. It would not be a replacement for documentation, but it could be in addition to documentation or even a starting point.
Post reply on HN