I stumbled upon this blog while casually scanning hacker news.
So I thought Julia REPL + Revise is top notch until it described “true interactive development” as follows:
True interactive development is also about programming in such a way that your program never crashes. Instead, whenever an unhandled condition is raised, the program starts an interactive debugger. While interacting with the debugger you don’t lose any program state, not even the ephemera of the call stack, unless you choose to do so.
I have never used Common Lisp but that sounds really cool to me. I could imagine that when I encounter an undefined variable or unknown method that got called, and then I just define it immediately and continue computation.
Has anyone thought about doing something like that with Julia? Would you think that is useful?
Someone mentioned a few days ago how they missed the programming environment in the lisp machines and how everything was downhill from there. I think that may be one things he misses…
That’s very different and something that Debugger can already do — see “breakpoint on error” in the docs. Common Lisp supports fixing the implementation of your program from the debugger and continuing to run it with the fix. Which is cool but has always struck me as a bit too fancy and still doesn’t save you from needing to restart your program in all cases. What if, as often happens, it’s too late by the time you actually get an error and the mistake that caused the error has already been made and cannot be fixed by unwinding the stack? Does “true” interactive development then dictate that one be able to rewind the program execution and undo what has already been done? Of course, that can be done with rr, which is often billed as a “time traveling debugger”, but it seems like Common Lisp draws the line in the sand for “trve interactive develop\m/ent” at the location that they happen to be able to implement easily because of the language’s error handling model (which is exceptionally powerful). I’d rather see good Julia-level integration with rr and the resulting ability to walk backwards and forwards through a debugging session.
In Smalltalk we often did development directly in the debugger. Write a use-case as plausible source. If there was a ‘does not understand’ error - meaning there was no implementing method on the object. We’d pop a menu up to create a boiler-plate method on a relevant class. The boiler-plate method raised a 'not-implemented-yet exception, so you would run past it in the debugger.
You could restart, or re-run from anywhere on the stack. Best environments I’ve worked in. Alto System Project: Dan Ingalls demonstrates Smalltalk - YouTube Dan’s the Man. just watch the environment No better refactoring environment than a modern Smalltalk.
Worth noting that the ProcessScheduler, and Debugger are all written in Smalltalk
Smalltalk’s influence on language design and the discussions thenceforth is pretty unique imo. It’s relationship to the rest of programming is something like the relationship academia claims to have relative to the “real world”, but always falls short of.
OTI who I worked for for a while, built a very good Smalltalk and configuration management system, they did embedded software for hospital heart monitors, military fire-control systems, police radio systems, nuclear power control systems, machine production configuration for wafer-fab, Tektronix had Smalltalk in their top of the line oscilloscopes. Smalltalk was killed when IBM and Oracle pumped all that money into Java, and stole all the engineers responsible for JIT. The first and probably still the best IDE for Java ‘VisualAge for Java’ was written in IBM/OTI Smalltalk. IBM bought OTI, and redirected them into Java.
As much as I love Common Lisp, I think that this is a misfeature as it encourages tinkering with the state of the program as opposed to making sure that everything is ultimately kept in source code files with proper test coverage. Fixing methods on the fly in the debugger/REPL and forgetting to introduce the change in the source is something that can easily happen.
I would rather
have the program fail,
inspect the stack,
figure out the problem
(may do some refactoring)
write some unit tests
and restart.
Another related CL feature is restarts, which essentially amounts to using conditions for “regular” control flow. Very sophisticated, but ultimately encourages bad design.
The ENVY/Manager configuration management system we had in OTIs Smalltalk had an immutable database for source, and byte-codes, you could create a scratch for local tinkering but once stored, it was totally identified by hash. Anyone could do bit-accurate builds of a named configuration from any repository anywhere. First and second gen Smalltalkers tended not to like it. They preferred hand-crafted change-sets. I used make a living out of moving change-set based development efforts into ENVY. The weekly build effort would go from a three-day horror show, using your best engineer, to half an hour on Friday afternoon that we could take turns at. I don’t think continuous build and test was a thing then.
I really like using the Julia package system, just seems right. I haven’t done anything at scale though.
Yes there was quite good facilities for comparing and merging various structures.
This Envy FAQ is the best I can find at the moment. I can probably strip some noise from it. I worked with it as a customer, and as an engineer on the product. Some of the ideas in the ENVY/Packager which was used to build the stripped down runtime were from my fevered brain. There was a very good team at OTI - of which I was a small part, for a relatively small time.
I think there are some relevant ideas that might adapt to Julia’s structure. As the kungfu master said ‘ask me the right question, and I will ring like a bell’, though it is something like 20-30 years ago…
I agree with everyone that says it’s a misfeature, but as @tpapp put it, the ability to do
have the program fail,
inspect the stack,
figure out the problem
immediately whenever there’s an error is immensely powerful. Having to load Debugger.jl and rerun in slow mode really takes the wind out of my sails enough that I basically never use it. I’d rather do print/global-variable debugging than use Debugger and risk waiting a long time or introduce some change in behaviour that changes the error.
as I understand it the whole restarts / edit live code thing can be immensely helpful on stuff running 24/7 far away (in a telecom server closet or a rover on Mars for example). But I agree it’s not worthwhile when you’re talking stuff you can debug on your desktop machine.
I don’t really understand what is meant by ‘misfeature’ etc. here, but I can say from long experience that changing the program state interactively and updating the source during runtime is immensely powerful and useful. Of course you can misuse it or make mistakes, like with any other feature.
It is one of the truly good features of Matlab.
If this were combined with a ‘time traveling’ debugger, it would be an absolute killer feature.
This seems to be a wise warning and I’ve seen similar points by others. However, the first thing a programmer learns is that warning is to be ignored. So I made one in Julia: GitHub - tkf/Restarts.jl
agreed, the misfeature here is encouraging working on the image without making changes in the source code.
I am not familiar with ENVY, but I would prefer if Julia kept it simple. Specifically,
the source code, as read from the filesystem, is the source for all definitions
let’s make updating from this really convenient and automatic — redefining structs would be enough for me, but if people want to be able to do this while in a debugger, that’s useful too
source code should be managed as files, with version control.
enough that I basically never use it. I’d rather do print/global-variable debugging than use Debugger and risk waiting a long time or introduce some change in behaviour that changes the error.