<https://youtu.be/R3MNcA2dpts> i really, really li...
# linking-together
g

https://youtu.be/R3MNcA2dpts

i really, really like the ux model from this demo of a concatenative programming environment—in particular, how the cursor gives you a live update of the stack and the definition of new words at ~2:40. anyone know of any similar projects?
😄 1
😍 4
👍 2
❤️ 2
a
This feels like the same family as loglo which is a stack based spreadsheet programming env https://loglo.app/2020-06-16/
g
definitely the same family with a wildly different interface
👍 1
k
This looks like any implementation of time-travel debugging?
g
it’s the coding interface, not the debugging interface
like. direct manipulation of source tokens, and definition of new functions is done by selecting the tokens that you’d like to be the definition and then giving a name
there’s live feedback throughout
k
Sorry, my question was just about the first of the two features that you pointed out.
g
oh—i guess time-travel debuggers let you “step through” code and place your cursor at it, but i’d say that this is different because the emphasis is on like... editing that timestream directly
💡 1
j
Some very nice affordances for concatenative programming! Appears abandoned, which is a shame because this deserves further development...
k
The little exchange between @Kartik Agaram and @Garth Goldwater is telling: we have come to consider the distinction between writing and debugging code as something fundamental. Which I think is mainly the fault of compilers. There's a development style popular with some Smalltalkers, a variant of test-driven development, in which most code is written in the debugger as a "fix" to failing tests. There is also a lot of overlap with @jonathoda’s work on subtext.
💯 4
👍 1
k
Funny thing was, as I was asking those questions the thing I was really thinking about was @Joshua Horowitz's PANE. It seemed somehow undesirable that the UI here had lots of "mutation" going on in the same part of the screen, where "the PANE way" would be to show all the states of the stack at once, which feels nice and "functional/immutable". But that property of PANE is also shared by logs if you set them up right. So I "simplified down" to time-travel debugging. Bret Victor's "Magic Ink" paper makes the same point: just show all the data so it can be just read, rather than requiring operations to see different peepholes of it: http://worrydream.com/MagicInk/#interactivity_considered_harmful
I finally got around to finishing the video. Extremely thought-provoking. It's kinda interesting to think of PANE and Brief as two poles with complementary strengths and weaknesses (with LoGlo in the uncanny valley in between) * PANE shows everything, but it's less dense. A single value is often printed in multiple places on screen. In Brief there's a designated place for showing runtime values, so less real estate is expended on them. * Brief shows a stack at the top level, but once definitions are created they get 'reified' into textual definitions. This is nice and dense, but solves just one level of the problem of not making me simulate in my head. I kept waiting for the author to show some way to "drill down" into a defined word to visualize how it constructs its intermediate results, but that still seems to be an open problem. It's also a little klunky that there are two ways visually to represent the same expression, one with boxes and the other in plain text. * LoGlo seems to have the drawbacks of both. It doesn't have any way to show intermediate stack states, and it also has no way to drill down into intermediate expressions the way PANE does.
👍 2
j
@Kartik Agaram In addition to sharing @Konrad Hinsen's impression, it also felt in reading that exchange that what stack means is rather special in this sort of language, which would wrong-foot someone who hasn't done a bit of programming in this paradigm.
2
o
Very interesting! I agree with previous comments and want to add that something nice here is some kind of programming by example then refactor to extract and create new abstractions.
☝️ 1
k
@Jack Rusher Hmm, can you elaborate on how 'stack' is special? I have done a bit of Forth, RPN isn't new to me..
j
@Kartik Agaram What I was vaguely gesturing towards is that in most high level languages the implicit mental model uses variables to represent an unbounded number of pseudo-registers while the stack is a largely invisible piece of machinery that facilitates function calls under the covers. In such a language, reifying the stack is a natural debugging affordance because it reveals that hidden mechanism. In concatenative languages, we invert that mental model by centering the stack and mostly pretending that there are no registers/variables. This makes the feeling of the stack very different in, say, FORTH vs Pascal.
👍 1
💯 2
k
The thing that was mind-bending to me a few years ago was that by splitting up the arg and return address stacks procedures could pass args to callees of callees! There's no well-defined stack-frame.
🙂 1
c
Finally watched this video and came here to make essentially the point @Konrad Hinsen made already. The phenomenal thing about this is unifying "actual debugging" with "brain debugging". When you are writing and reading code, moving the cursor, you are naturally "running" it and maintaining the state in your head. This offloads that to the computer.
👍 3