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

71–80 of 210 posts

Re: On Repl-Driven Programming

#71

Post by pjmlp »

mikewarot wrote: post #47

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

"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"

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

"Alto System Project: Dan Ingalls demonstrates Smalltalk"

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

"Action!, the worlds first dynamic interface builder - 1988" (Interface Builder percursor, written in Lisp)

https://vimeo.com/62618532

"The Interlisp programming environment"

http://larry.masinter.net/interlisp-ieee.pdf

And the cherry, how Lucid used Lisp ideas for their Energize C++ IDE, including an image based format for AST storage

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

https://www.dreamsongs.com/Cadillac.html

Re: On Repl-Driven Programming

#72

Post by ashtonkem »

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

Editing data and functions in the REPL is a neat trick, but it’s a double edged sword, because a REPL can crash, and it provides incredibly rudimentary support for diffing current state and migrating changes back to permanent files. I would never start with anything more than a trivial “how do I manipulate this list” in the REPL for that reason. Oh, and we had a lot of issues with REPLs getting into a bad state with Clojure due to multi methods and protocols; if you’re doing your primary work in the REPL, then having to restart it due to it becoming unstable really sucks.

Re: On Repl-Driven Programming

#73

Post by irjoe »

Is there a simple way to get code I write in a lisp REPL back into my editor? That's the part missing for me and why I usually only use interactive shells (REPL or otherwise) for testing APIs or small pieces of code.

I can't imagine writing a program in its entirety in a REPL.

Re: On Repl-Driven Programming

#74

Post by gumby »

irjoe wrote: post #73

Is there a simple way to get code I write in a lisp REPL back into my editor? That's the part missing for me and why I usually only use interactive shells (REPL or otherwise) for testing APIs or small pieces of code. I can't imagine writing a program in its entirety in a REPL.

The standard technique is to run the loop inside the editor. This technique dates back to the 1970s.

Re: On Repl-Driven Programming

#75

Post by gumby »

Back in the early 80s a friend described this approach as "programming by successive approximation." I was stung by that, but I saw his point.

Nevertheless I felt it was wrong. The approach of designing a data structure, making a few functions to manipulate it, designing another, making sure they work together, etc isn't really that different in lisp from C++. The loop is tighter when you can interactively test.

Either way you have to think ahead.

Re: On Repl-Driven Programming

#76

Post by blandflakes »

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 class citizen I care about. Sending code to a REPL to be interacted with? Cool, and I think this is what a lot of people mean when they say REPL-driven.

I'd imagine convenience around that in a language or its tooling would be what convinces me to do more REPL-style things.

Re: On Repl-Driven Programming

#77

Post by tarboreus »

irjoe wrote: post #73

Is there a simple way to get code I write in a lisp REPL back into my editor? That's the part missing for me and why I usually only use interactive shells (REPL or otherwise) for testing APIs or small pieces of code. I can't imagine writing a program in its entirety in a REPL.

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 your editor. Or by attaching whatever other tools to the running session.

Re: On Repl-Driven Programming

#78

Post by irjoe »

adamkl wrote: post #58

For anyone who would like to see what REPL-driven programming looks like in practice, take a look at this video here: https://vimeo.com/230220635 The author uses the Clojure REPL to walk through the process of developing some non-trivial functionality (calling an API and parsing the results). It’s a good intro to what it looks like to interactively build a program while it’s running. Personally, I’ve found that havin…

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.

Re: On Repl-Driven Programming

#79

Post by rozap »

irjoe wrote: post #78
adamkl wrote: post #58

For anyone who would like to see what REPL-driven programming looks like in practice, take a look at this video here: https://vimeo.com/230220635 The author uses the Clojure REPL to walk through the process of developing some non-trivial functionality (calling an API and parsing the results). It’s a good intro to what it looks like to interactively build a program while it’s running. Personally, I’ve found that havin…

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.

It's nice to be able to do this in production for debugging. It's super powerful and one of the my favorite features of erlang.
Post reply on HN