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

141–150 of 210 posts

Re: On Repl-Driven Programming

#141

Post by mikelevins »

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…

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 ways of handling them.

And yeah, if you just iterate and explore, you can wind up in lacunae. You do need to develop some actual goal and a vision of how to get there. Interactive development can be really helpful for the exploring part, but it can't pick your goals for you.

In short, interactive development is a way of working that's good for some cases and some people (me, for instance). It's not a cure-all or an objectively superior methodology for all people or all cases. I don't want it to take over the world. I just want it to continue to be an option because it's the way I prefer to work.

Re: On Repl-Driven Programming

#142

Post by mikelevins »

thewebcount wrote: post #121
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 ev…

Well, no, you didn't fix the bug. You collected a datum about the bug: it caused a variable to have a value that it should not have had. Now you know something about it that you maybe didn't know before.

When you say "Great! You fixed the bug, right?" it sounds like a paraphrase of a passage in my essay that I had some misgivings about when I wrote it. But I thought, surely nobody's going to think I really mean the problem is definitely solved? Surely, people will realize its a bit of hyperbole.

Maybe not. Maybe I should have instead written it more soberly. Maybe I should have just said "Now you've collected a bit of data about the nature of the bug."

Re: On Repl-Driven Programming

#143

Post by mikelevins »

0x445442 wrote: post #138
mikelevins wrote: post #90

Earlier quoted context omitted.

Agreed, FORTH is repl-driven in the sense I mean. The main difference from Lisp and Smalltalk systems is that FORTH environments are, generally speaking, more spartan. In the late 1980s I had a group of friends at Apple that included Smalltalk, Lisp, and FORTH programmers. We certainly found plenty of things to admire and attempt to steal from one another, and everyone accepted the basic goodness of building systems…

Yeah, Factor's environment looks really similar to something like Smalltalk. The thing with Forth is that it looks really daunting to perform higher level tasks that I'd be interested in performing on a day to day basis.

It can definitely be done, but historically, that's not really been its sweet spot.

Re: On Repl-Driven Programming

#144

Post by mikelevins »

globular-toast wrote: post #25
lispm wrote: post #17

Earlier quoted context omitted.

The examples from Mikel are just not possible in a default Clojure setup. It does not have break loops and it does not have a dynamic object system (by design).

Yeah, true. I would still consider Clojure a "proper" REPL driven language, though.

I do not. I have used it to write quite a bit of code, and I generally like it as a language, but I don't consider it a reasonable substitute for Common Lisp or Smalltalk. Factor, on the other hand, is--as far as I know.

Re: On Repl-Driven Programming

#145

Post by O_H_E »

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…

Oh man, I appreciate your pragmatism and open-mindness. It is refreshing to see someone advocate for something without trying to "take over the world" and proving others wrong.

Thanks for sharing your experience amd positivity with the world.

Re: On Repl-Driven Programming

#146

Post by mikelevins »

tluyben2 wrote: post #14
globular-toast wrote: post #11

As someone who has used CL and Clojure to write non-trivial code using REPL driven programming it makes me mad that the word REPL has been hijacked to mean "interactive shell". I'm thankful for this article shedding light on what it really is. It's sad that most programmers haven't experienced.

I have some experience with clojure but besides using the repl as 'interactive shell' I never tried it further (for some reason I always thought it was a crippled lisp even though I did some fair amount of work in it); does it offer the full experience? I should try it again as that's something that's actually used in real life (and has a good client side cljs experience).

It does not offer the full experience. It has no breakloop and no ability to browse and edit the live running environment. It has no ability to rummage around inside the dynamic environment of a suspended function call, much less to redefine the suspended function or the types of its parameters, nor to restart the suspended call. Indeed, the JVM makes some of that stuff really inconvenient to do.

You cannot do everything from the Clojure repl in the way you can from a Common Lisp repl or from a Smalltalk worksheet.

I don't know that the Clojure language design forbids it; you might, for example, implement Clojure on top of a Lisp or Smalltalk environment and hook up their tools to Clojure through its interop. That might work, and ruricolist has been working on such an implementation called Cloture:

https://github.com/ruricolist/cloture

But existing Clojure implementations don't have the full set of tools.

Re: On Repl-Driven Programming

#147

Post by djha-skin »

What a surprise, the functional folks are arguing that

"Because your language is different than mine, therefore it's not as good as mine."

I've heard people say that Java or C++ isn't a language, because it doesn't have features x-y-z when Racket does. Garbage. Similarly, this guy is saying that because Python's shell doesn't have breakloops, it isn't a real REPL. Also garbage. 99.9% of the time when using REPLs/shells, if something doesn't run, I correct the code, copy and paste it into the shell, and run it again. Breakloops don't exist in the Python shell because they don't need to. Python shell works about as good as Clojure REPL for me.

I get really tired of these elitist holier-than-thou arguments. Functional programming is a thing. Procedural programming is a thing. REPL is a historical name... for an interactive language shell. They really are quite equivalent.

Re: On Repl-Driven Programming

#148

Post by Jtsummers »

xg15 wrote: post #133

Question by someone who never used interacted development before: How do you save the results of your work? How do you ensure the state of your program is what you think it is. E.g.: Imagine you're in a breakloop as described in the article. You find that local variable X is 5 when it really should be 4, so you quickly set it to 4. You find function foo() is not defined, so you define it. You continue and your progra…

You can edit the source file and send it to the listener.

Suppose I'm in my REPL and I do this:

  > (foo 'bar)
I get dropped into the debugger because foo doesn't exist. So I switch over to my .lisp file in another buffer and I type:

  (defun foo (symbol)
    (format t "Baz ~A~%" symbol))
  ;; this will print "Baz BAR" in the example
With the cursor anywhere within that function definition I type C-c C-c, go to the debugger and restart it. It works now.

My source file and my Lisp image are both synchronized.

In the case of changing a variable. Say I'm somewhere deep in some code and this tries to run:

  ;; in context x = 0
  (/ y x)
I'm dropped into the debugger. I know x was supposed to have a minimum of 1. I can do a couple things:

1. Examine the back trace in the debugger to see if I can locate where x got an incorrect value (maybe it was the line above, maybe 10 functions earlier). I make a note of what to fix, maybe I fix it now.

2. Change x to its proper minimum value and resume.

If I was able to trace how x got a wrong value, it's fixed already. If not, I'll have to explore more. But I don't have to restart way earlier, I can just restart at this point (assuming nothing else was broken by x having the wrong value here) and still get the result of my program (assuming x being wrong didn't break a lot of other things). Or I can quit back to the REPL and start exploring the problem.

Re: On Repl-Driven Programming

#149

Post by hirple »

Folcon wrote: post #131
xkeysc0re wrote: post #124

Earlier quoted context omitted.

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

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…

org-babel might work here. There are also repl keybindings in python mode in emacs.

Re: On Repl-Driven Programming

#150

Post by hcarvalhoalves »

pjmlp wrote: post #71
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…

Watching the Symbolics demo nowadays, it's amazing what they had back then.
Post reply on HN