I just make programs that have an "entry point" (e.g. main() in C or if __name__ == "__main__" in python) and run them off the shell. Oftentimes with some arguments. This is how I interact with most of my programs, and it works fine for my own ones too.

I agree that this is probably not for everybody, i.e. if you're not used to the CLI workflow. And admittedly it would be sometimes nice to have e.g. embedded graphics, but unfortunately the troubles usually outweigh the benefits (looking here at emulating damn 70's terminals too...).

I mostly do the introspection with print, dir and help straight in the code. Not ideal, but rarely fails you, and I've yet to find a debugger GUI or IDE that isn't more trouble than it's worth.

Something like autoupdating RMarkdown/Sweave/Pweave/etc would probably work often as well. I sometimes do use Pweave, although it tends to be a bit buggy as well, and doesn't have any caching logic (although it's easy to use your own).

Sadly most efforts seem to go to Jupyter notebooks and such, whose state/code inconsistency are simply a non-starter if one wants to keep some sanity.

> I mostly do the introspection with print, dir and help straight in the code.

This means you have to change your code in order to debug it. And you have to know what you're debugging before you change your code. This is really, in my opinion, much less than ideal, because you have to iteratively instrument your code while you figure out what is wrong. It's a cycle of You print out the first suspect thing, then that produces 5 potential suspects, and you have to decide which one to print next, or print all of them.

You're absolutely right that it rarely fails you, and so I surely want that facility to be at my finger tips. But getting a text representation of a value is literally 33% of what a REPL is for.

If I'm debugging something I'm writing myself it's usually quite obvious where the problem probably is. With other people's code it takes a bit of digging, but is usually found without a debugger. Just print enough stuff, with interpreted languages this is usually really fast. Something like Javascript's console.log is actually really nice for this (and browsers have hands down best debugging tools anyway).

I'm not sure how REPL helps you out of this. You still have to somehow change the state of the program, but if you "monkeypatch" it using REPL, you now have to keep in your head what the state is.

In the end code is just description of how to bring the program to some state. I like to have that description on file so I don't have to keep it in my head.