On Repl-Driven Programming • Hacker News Board

Re: On Repl-Driven Programming

#41

Post by pjmlp » Sun, Jan 03, 2021, 12:41 PM UTC

andybak wrote: post #35

pjmlp wrote: post #9

Earlier quoted context omitted.

Dart, Java and .NET have a kind of edit-and-continue without images. It is all a matter of tooling.

> It is all a matter of tooling. I think the point of the article is that tooling can only get you so far. The abstraction they attempt to provide is leaky if the support for this style of development isn't firmly designed into the entire system.

Yeah, but in that regard developer culture is what matters.

I have seen very few people actually using these kind of workflows back when Smalltalk and Lisp were more relevant (I used Smalltalk/V back then).

It is like using gdb, many don't go beyond step, next, print, run, breakpoint and discover how powerful it actually is (same applies to other debuggers).

Re: On Repl-Driven Programming

#42

Post by crabmusket » Sun, Jan 03, 2021, 12:43 PM UTC

This reminds me of Unison's "codebase manager": https://www.unisonweb.org/docs/tour#-the-big-technical-idea

It's not exactly a repl, but it shares similarities to the idea of interacting with your source code itself via software, not just by typing bytes into a file.

Re: On Repl-Driven Programming

#43

Post by cutler » Sun, Jan 03, 2021, 12:44 PM UTC

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…

There's Hy (hylang.org) for Python which comes with a real repl.

Re: On Repl-Driven Programming

#44

Post by blunte » Sun, Jan 03, 2021, 1:23 PM UTC

globular-toast wrote: post #23

blunte wrote: post #6

This article helps us understand what real repls enable that interactive language shells do not. What would be very helpful next would be a video comparison of writing a program that is just complex enough to not be trivial or too artificial, first using the common approach, and next using repl-driven approach.

Why not just learn a Lisp yourself? You'll get far more out of it than watching a video. The old adage is still true: learning a Lisp makes you a better programmer. Your choices are: * Common Lisp: install emacs, SBCL and set up SLIME, * Clojure: install emacs, Clojure and set up CIDER, * Scheme: install emacs, racket (or guile) and set up Geiser, * Emacs Lisp: install emacs. You'll notice that they all involve emacs…

Nice reply. In my case, I'm already an effective amateur at Clojure, but I only use the repl for testing ideas and debugging.

In the same way there are guides that teach TDD, I would enjoy seeing a RDD (repl-driven ...) tutorial.

Re: On Repl-Driven Programming

#45

Post by Jugurtha » Sun, Jan 03, 2021, 1:46 PM UTC

nikhizzle wrote: post #29

magv wrote: post #24

For those of us that don't use Lisp (or Emacs+SLIME), and are stuck with Python/Julia/Lua/etc and Vim may I give a practical recommendation? The Vim-Slime plugin [1] is a half-decent way of making interactive development work. With a bit of tuning you can make it start a terminal emulator window inside Vim, and have it send the current paragraph of your source code into it with a press of a button. While not as great…

I also recommend jupyterlab for a similar experience. I was a hardcore vim terminal guy for 17 years, but now I won’t be going back. The ability to interactively develop functions in almost any language inside the same environment had been revolutionary for my productivity given my short attention span.

Would you mind sharing what you're doing with JLab? Do you use it in machine learning or are you doing something completely different?

Re: On Repl-Driven Programming

#46

Post by lebuffon » Sun, Jan 03, 2021, 1:47 PM UTC

Nobody has mentioned low-level programming in a REPL. Not as common to be sure. Forth works this way and even has REPL Assembly Language. It's been there for over 40 years.

Testing Forth and ASM code snippets in the REPL before committing to them helps eliminate those nasty assumptions about what "should" work.

Re: On Repl-Driven Programming

#47

Post by mikewarot » Sun, Jan 03, 2021, 1:51 PM UTC

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!

Re: On Repl-Driven Programming

#48

Post by qznc » Sun, Jan 03, 2021, 2:08 PM UTC

> If it now works correctly, then congratulations; you found the problem!

This notion if “correct” is “finished the current example as intended”. Running a suite of unit tests would give me more confidence.

Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there.

That means a REPL makes easy things easier and hard things are unaffected. Does not sound like a competitive advantage to me.

Re: On Repl-Driven Programming

#49

Post by mumblemumble » Sun, Jan 03, 2021, 2:08 PM UTC

psykotic wrote: post #16

He's right to emphasize the properties of the systems that support interactive development with a long-running image. In Common Lisp, the difference between defvar and defparameter is a simple example. Traditional Smalltalk systems only supported image-based development. But I always preferred the moderate approach exemplified by most Lisp systems where the source code isn't overly entangled with the image state. As…

Why not all of it?

Long ago, I was doing Objective-C development with an embedded F-script REPL, hot code swapping, and XCode's built-in debugger. It was very nearly as nice as Smalltalk in many ways, only without the whole IBD situation.

Re: On Repl-Driven Programming

#50

Post by twobitshifter » Sun, Jan 03, 2021, 2:10 PM UTC

For Ruby users, pry gets you most of the features discussed in this post. You can get the error break loop, and drop into the live environment with binding.pry. Code can be added and expressions adjusted at this point. It’s very powerful and the only “debugger” I’ve ever needed for Ruby.