I've always written Lisp with an editor, into a file, and used the REPL only for exploratory and debugging tasks.<p>Some of my early Lisp programs used a Makefile.<p>Lisp is great even without the scatter-brained approaches that some Lisp programmers advocate in order to roll people's eyes and turn them away from Lisp.
Captured objects in closures are another problem in JavaScript.<p>A long time ago I was using a JavaScript framework where the memory usage went up steadily as you navigated the single page app. One cause was captured variables (referencing large object trees) in event handlers. The only viable way to fix the issue was to write my own custom framework taking extreme care with closures and sometimes nulling variables (the code for the existing framework was just too complex to fix - and memory references are hard to debug in browsers). I saw the same issue with memory usage growth in a different framework. Some of the issue was that Internet Explorer had problems with circular references between JavaScript and the DOM, but the captured variables in closures were their own problem.
"This would make functions second-class. [...] Is that really much of a loss?" Yes! A huge loss. The cons of live programming don't even come close to outweighing the pros. You can always fallback to edit-compile-restart if you need to.
This is moe interesting than it looks, probably because the best part (IMHO) is about the type system, that is what enables the other ideas.<p>> In Julia, types are first-class and every value has a type<p>This is what I do from the start in <a href="https://tablam.org" rel="nofollow noreferrer">https://tablam.org</a> and only later found that is not common! Is so intuitive this way and simpler to check, by a lot. In fact, I waste so much time adapting type inference algorithms that are hard to translate because for some reason graphs are imposed on trees, types are second-class and live at a distance (and erased) and all is a mess this way.<p>The relational model already makes this so simple: `project / rename / extend` relational operators cover you.<p>From this other facilities become possible. Note how in `SQL` you don't have functions as first-class per se, but now try to imagine that a function is a table and suddenly, is much better!
> At some point the only option is to kill it with fire turn it off and on again. Extinguish that spark of life and turn it back into a puppet.<p>That turns out to be the solution that nature has come up with, so while it <i>might</i> be possible to do an end-run around this constraint somehow and keep a dynamic system running forever, I'll give long odds against.
That animation is just so hilarious.<p>The craziest scene from the 1980s movie _The Thing_, recast in bird claymation. What kind of wild mind comes up with something like that...
> Methods overridden at runtime, traces that end with a call to a closure that no longer exists, event handlers whose execution order depends on side-effects during module loading, stack-traces which contain multiple different versions of the same function.<p>My experience is that the more orthogonal the data, logic, and presentation in the system, the more methodical the naming, the less important the system is and the more the creativity can be focused on the task, not dealing with the "personality" of the system.
Being able to skip the stop-edit-compile-(re)start cycle is <i>nice</i>.<p>I don't know that the evidence is overwhelming that it is <i>better</i>.
Late binding is programming for moties.[1]<p>[1] <a href="https://en.wikipedia.org/wiki/The_Mote_in_God%27s_Eye" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/The_Mote_in_God%27s_Eye</a>
I didn't expect determinism's usefulness to be ever under question but I guess there's first time for everything.<p>In Elixir most of us use the REPL to sketch out an idea; to shorten the development cycle a bit and have something that looks to be working. Once that's happened then we write the code properly, with tests and all.<p>REPL and tinkering are just one tool to make your work more deterministic. It's not a personality that wins over all other personalities.<p>And stop looking for ghosts in the machine, it ain't happening. I like me a good sci-fi as well but general AI is quite far away still.
Google outlawing dynamic code in Web Extensions/mv3 is a travesty of high order. There's no place I want to be able to be more alive than my agents. Yet my agents must all be dead. For shame, ye villains.<p><a href="https://github.com/w3c/webextensions/issues/139">https://github.com/w3c/webextensions/issues/139</a><p>This post definitely was quite a technical explanation. The opening framing, to me, means the world.
> It's not obvious what to do with long-running background tasks though.<p>You avoid them and chunk the work into pieces.<p>That's what every framework for long-running tasks do; that's what people that write them by hand ends-up doing after the first or second time they fat-finger a CTRL-C.<p>That's the only way to make those tasks viable.
Just passing around closures in Java as method arguments—or “callbacks” because this is a webapp so of course—is too dynamic to me. Even if you are just using it to abstract out something and it isn’t really more dynamic than using methods directly.