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

201–210 of 210 posts

Re: On Repl-Driven Programming

#201

Post by Folcon »

sfsys wrote: post #200
Folcon wrote: post #131

Earlier quoted context omitted.

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…

I've been doing exactly this for a while now using Emacs built-in python mode and I think it's its quite nice. With just a few keystrokes I can send any part of the code I'm working on into a running python process and see the results in a separate repl buffer. The built-in python-mode already has a good selection of possible selections to send and I've written two extra ones working with indent levels dependent on w…

Thanks for the definitions =)...

I've not used emacs for python, but could give it a spin for this!

Bit unfortunate that you need to restart the process for re-evaluating classes though.

Re: On Repl-Driven Programming

#202

Post by sfsys »

Folcon wrote: post #201
sfsys wrote: post #200

Earlier quoted context omitted.

I've been doing exactly this for a while now using Emacs built-in python mode and I think it's its quite nice. With just a few keystrokes I can send any part of the code I'm working on into a running python process and see the results in a separate repl buffer. The built-in python-mode already has a good selection of possible selections to send and I've written two extra ones working with indent levels dependent on w…

Thanks for the definitions =)... I've not used emacs for python, but could give it a spin for this! Bit unfortunate that you need to restart the process for re-evaluating classes though.

Yeah. There are a quite few niggles like that. Even though you can get quite close by (automatically) sending code to the repl, Python is simply not set up for interactive development.

It's one of the main reasons why I love Common Lisp so much.

Still, it's not too bad and IMO a lot better then restarting the process on every single change

Re: On Repl-Driven Programming

#203

Post by webmaven »

pjmlp wrote: post #189
webmaven wrote: post #177

Earlier quoted context omitted.

> No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. Oh man, you are so wrong about that. It's worth noting that this style of development also hamstrung quite a few Python web app projects in the late 90s because the Zope application server encouraged the use of this style of development (except through a browser rather than the command line) and beginners e…

This is how any major CMS works to this day, and anyone doing serious development does have the engineering workflows in place to replicate the database content.

You're missing that Zope application-development-through-the-browser could (and did) allow you to do just about anything with a Turing-complete template language, and if that was too unwieldy, Python script objects (which executed in a sandbox to prevent direct access to the filesystem, etc.).

Nothing forced you to a saner development model except for wanting to include 3rd-party libraries and being able to distribute and version your code.

Remember, this was when servers were definitely pets and scaling a web app meant scaling up to a bigger server, not scaling out to more servers. It wasn't immediately obvious (especially to brand new developers) that having all the code for even a simple CRUD web app, which you only ever expected to have a single deployment to a single server, live as pickles inside an object database that had a transactional history of edits, was inherently a bad idea.

A lot of interesting stuff was created that way, and integration with the facilities that were missing such as version control led directly to capabilities like versioning content in cvs and svn (since code was just another kind of content).

Eventually, Zope's so-called "Z-shaped learning curve" hindered adoption and other Python-based web-app platforms surpassed it in popularity.

Re: On Repl-Driven Programming

#204

Post by scottjad »

alpaca128 wrote: post #38
nikhizzle wrote: post #29

Earlier quoted context omitted.

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.

If you're using Jupyter within the browser you can have both via the FireNVim plugin in Firefox. It connects to NeoVim in the background and lets you edit any multi-line text field with 100% of your personal Vim configuration, the only limitation is that the color scheme cannot be changed.

FYI I use firenvim daily and it can certainly change color scheme. Is it only when used with Jupyter that color scheme can't be changed?

Re: On Repl-Driven Programming

#205

Post by pjmlp »

webmaven wrote: post #203
pjmlp wrote: post #189

Earlier quoted context omitted.

This is how any major CMS works to this day, and anyone doing serious development does have the engineering workflows in place to replicate the database content.

You're missing that Zope application-development-through-the-browser could (and did) allow you to do just about anything with a Turing-complete template language, and if that was too unwieldy, Python script objects (which executed in a sandbox to prevent direct access to the filesystem, etc.). Nothing forced you to a saner development model except for wanting to include 3rd-party libraries and being able to distribut…

Nope I am not missing that, because enterprise CMS still allow that kind of stuff.

Re: On Repl-Driven Programming

#206

Post by fouric »

discardable_dan wrote: post #179
fouric wrote: post #174

Earlier quoted context omitted.

> 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" This seems like an incidental property (symptom of poor engineering discipline, which manifests itself in other ways in other development paradigms e.g. lack of documentation from "agile" teams) of the particular applications you've worked with and not an ess…

The experience I have had on large, REPL-driven development is that continued development is assumed to also work under REPL-driven environments, so debugging or supporting them begins with "try typing X into your REPL." Many of the distributables I have seen also maintains REPL interactivity as part of the live deployment solution, with similar debugging solutions. While this may not be unilateral, "ship the deploym…

The batch-processing tools I wrote (e.g. a simulator) had CLI shims that called the same interesting functions that you would at the REPL. The interactive tools I wrote all had functions that acted as a zero-effort entry point anyway, so the conversion to standalone tool just consisted of building an image that called that function.

Additionally, my development environment (SLIME) talked with my application over a network socket, so there's no linkage between it and the application - at least, any more so than the usual problem of "Common Lisp binaries are hard to make small" but that's not specific to REPL-driven development.

The simplicity of my "solution" makes me think that we might be talking at different levels here, but I can't think of what the disconnect might be.

Re: On Repl-Driven Programming

#207

Post by _theory_ »

mikelevins wrote: post #139
0x445442 wrote: post #137

Earlier quoted context omitted.

Having never developed code professionally in Lisp, my question would be; does the REPL work flow replace test code? Because if the REPL is being used as a replacement for tests, then I can see future readers having a harder time groking the code without the benefit of test driver code to analyze.

I'd say it's more like tests grow naturally out of repl interactions. Test-driven development as a discipline emerged from the Smalltalk community, and I don't think that's an accident. I think it's a formalization of the way that Smalltalk and Lisp programmers naturally tended to work. I generally start on something by making a naive model of what I'm trying to accomplish and interrogating it. In successive iteratio…

Thank you for explaining your process. I think I might benefit from this approach.

Re: On Repl-Driven Programming

#209

Post by discardable_dan »

fouric wrote: post #206
discardable_dan wrote: post #179

Earlier quoted context omitted.

The experience I have had on large, REPL-driven development is that continued development is assumed to also work under REPL-driven environments, so debugging or supporting them begins with "try typing X into your REPL." Many of the distributables I have seen also maintains REPL interactivity as part of the live deployment solution, with similar debugging solutions. While this may not be unilateral, "ship the deploym…

The batch-processing tools I wrote (e.g. a simulator) had CLI shims that called the same interesting functions that you would at the REPL. The interactive tools I wrote all had functions that acted as a zero-effort entry point anyway, so the conversion to standalone tool just consisted of building an image that called that function. Additionally, my development environment (SLIME) talked with my application over a ne…

As stated before, the fundamental disconnect is that you are imagining a world where all subsequent development on your code is done via SLIME and sockets or some similar REPL instance. You see this as simple because you wouldn't consider developing without SLIME / sockets in the application, but consider the other side of the coin. If I am a developer who does not use SLIME / socket connections as my default development pattern, my first step to contributing to your codebase is to either (i) convert to this workflow and toolset, or (ii) develop all of the CLI shims you described, including maintaining them as functionality changes. That leaves me between a rock and a hard place, especially if my text editor of choice doesn't have good SLIME support.

Also, I do not quite buy the simplicity of the standalone tool conversion; it assumes the relevant functions are naturally well-suited as entry points, including handling malformed inputs, etc., very cleanly. In my experience, many things that make sense at a REPL in a live system need to change dramatically to mature into robust command-line tools.

As for deployment, the interactivity I am describing is exactly the linkage you mention, and it really does come down to shipping a development environment as part of the deployment environment. Shipping a binary with a swank server or similar introduces binary size issues, portability issues (you have to ship dependent libraries along with the binary), and some serious security implications. And while this may be the "lisp way", modern languages manage to avoid these issues just fine.

Re: On Repl-Driven Programming

#210

Post by webmaven »

pjmlp wrote: post #205
webmaven wrote: post #203

Earlier quoted context omitted.

You're missing that Zope application-development-through-the-browser could (and did) allow you to do just about anything with a Turing-complete template language, and if that was too unwieldy, Python script objects (which executed in a sandbox to prevent direct access to the filesystem, etc.). Nothing forced you to a saner development model except for wanting to include 3rd-party libraries and being able to distribut…

Nope I am not missing that, because enterprise CMS still allow that kind of stuff.

Well, sure, but they aren't usually presented as the default path for development, but rather as an option for per-instance customization.

But if you understood my point about developing new functionality this way, why the non sequitur regarding content?

Y'know what? Nevermind. We're on the same page now.

Post reply on HN