What is beagle? It doesn't look like you've mentioned it here before..

Ahh, yeah sorry. I've named my language I've been working on Beagle. So all the previous posts about a dynamically typed functional language I'm working on is about that.

Just so you know, there is also Beagle Smalltalk by David Buck.

That's wild. Can't wait to see the technique. Is it using attr() ?

Nope! In the screenshot, the left part is displayed with attr() , but the right part is “calculated” from the value of the variable and then output as CSS counters. Basically, the only way to output values from variables in CSS into content , and there is a lot going on in order to achieve this haha.

Comments? I often do exploratory programming and end up thinking "this worked just a 1/2 hour ago, maybe I should revert to that?" (Or "...just yesterday..."). I am learning to hate off-the-shelf git. I have always thought - but haven't done anything about - that I want an auto-git that saves every change and lets me rewind. Is this the kind of thing that you found to be too much trouble?

Paul Tarvydas I pointed out 💬 #devlog-together@2024-11-25 my idea of creating a commit at the point of a comment to self. I still like this approach a lot even though I stopped using it at some point as I grew more fluent with git.

I suppose it depends on what the goal is. In that previous thread the goal seemed to be to see a very fine-grained history. Oleksandr Kryvonos I don't follow what you mean here by "it turned out to be a lot of trouble to remember what I actually did". Doesn't the commit history show you exactly what you did? Is it just too noisy?

It seems to me the current approach of staging things drops the fine-grained history entirely. So maybe I was misconstruing your goal above. I'm curious to hear more.

On a tangent, I was reading about magit yesterday. I wonder how much of a difference using it would make to the experience of git.

Kartik Agaram previous goal indeed was to have a fine-grained history, but it was noisy

Paul Tarvydas in my workflow I always can roll-back to stable version - this is my "main" branch.

Now when I start to explore I create a new branch first,

but making commit on every change ruined already available diff tools

so this was one of the problems with previous approach.

Has the goal shifted now? What is it now?

The way that I read this, it sounds like you have to stop and make a comment to self, pulling yourself out of "The Zone" (aka "Flow state"). Did I understand this correctly? If so, I want to aim for tools that don't interrupt my train of thought. An aspect of "exploratory" programming is that it is not methodical, you can't plan ahead nor push buttons after/before-the-fact, you need to keep motoring forward without needing to notice your tools.

Paul Tarvydas yes it is correct - now I will need to get out of the flow "The Zone" and write the comment myself.

Kartik Agaram the global goal is to explore what works for me in programming and I am thinking of a short-lived project as a means for exploration. I thought that granular history was what I wanted but it was a mistake for me.

I'm definitely interested to hear more as you figure out what you want for yourself.

Have you looked at jj ? It has an interesting-looking flow where every edit is automatically part of an automatically updating commit -- until you decide to draw a line and create a new one. I haven't worked much with it myself, but in principle it seems like a promising best of both worlds: save from the start, but you aren't forced to prematurely attach a name to what you're doing.

Oleksandr Kryvonos I conclude that "staying in The Zone" is vital during design and exploration. Most programming languages and IDEs don't emphasize this aspect and tend towards a "waterfall" model of development, i.e. you need to predict where you're going instead of simply discovering it. This sounds loosey-goosey, but is critical to actual design work. It might be a big factor in why some people love early languages like Lisp, Smalltalk, Forth, etc.

Kartik Agaram thanks for the suggestion,

I try to use Unix philosophy of "one condenced and understandable tool for one job".

Next I want to create a pattern matching natural language agent similar to ELIZA ( github.com/norvig/paip-lisp/blob/main/docs/chapter5.md )

Paul Tarvydas totally agree that staying in the mental flow is important.

And that environment should support fast iterations.

Oleksandr Kryvonos are you aware of Prolog, miniKanren, Nova, Ceptre, etc., for pattern-matching? That stuff was shunned in 1950 because backtracking was considered too taxing on the hardware. Today, backtracking is cheap and cuts through problems like Eliza like a hot knife through butter. [I conjecture that LLMs are just massively parallel pattern-matching devices].

Paul Tarvydas yes I am aware of Prolog, the other names are new for me

Examples of coordinate spaces:

• Graphical game engines use the obvious 2D/3D cartesian systems. You position stuff using (x, y) or (x, y, z) . You could also imagine polar or other coordinate systems that are studied in geometry.
• The HTML DOM is a space where positions can be specified using CSS selectors or XSLT.
• You can imagine a text editor operating in a coordinate space as well. Emacs seems to use a 1D coordinate, just character count from start of buffer. My stuff so far uses 2D: (line index, UTF-8 codepoint index within line)

Example messages:

• In a text editor, the cursor tracks a position, and keyboard and mouse send messages to move the cursor or insert objects (characters or longer text) at the cursor.
• You can imagine print statements as a message from the "code" coordinate space to a different, 0-D (append-only so there's no notion of coordinate) space.
• Terminal buffers in Emacs take the mostly 0D space of a terminal and augment it with a cursor. When you scroll up to an earlier command and hit a hotkey, the buffer sends a message to itself with the text around the cursor. The message is received at the bottom of the buffer.
• Emacs Slime and other IDEs support keyboard shortcuts to send text from the current buffer to a REPL in some other buffer.
• Ronin and sketch-n-sketch support bidirectional messages between two spaces with very different coordinate systems.
• Live programming systems often show the results of a statement to its right. Examples: alv by Sol Bekic, Bret Victor (of course), Seymour as above. These too can be seen as a reflexive message from a space to itself. In addition, the message contains an implicit coordinate: the current line.
• GToolkit, Lisp Machines and other Smalltalk systems do a lot of stuff like this. I think all of this can be cast in terms of buffers, coordinate spaces and messages, though you can imagine them as a single, very complex coordinate space like the HTML DOM, or many simple spaces with different possible coordinate systems. For example, in any of them you can create a new "log" space that you can append graphical objects to. Maybe even self-contained interactive graphical widgets.

The major question for me now is: how do you configure a buffer? You need some concise way to specify the space (perhaps just by naming from a small menu of options), handlers that listen for messages (e.g. keypress or mousepress), handlers for sending messages (e.g. widgets on the space that perform tasks when you interact with them), and generic handlers for sending messages to other buffers (e.g. print ; here I'm imagining it to send a message from some arbitrary process, through say a socket, back into the environment, with enough information to route it to the appropriate buffer accompanied by a reasonable coordinate)

Elena and I explored this space a little and you might find a useful thing or two in github.com/alltom/debugview

I think session management was the most annoying part of our approach. Like if two parts of a program want to make bar charts, suddenly there was a coordination problem, because we wanted to stick to a tadi protocol that any process with a stdout could speak and wouldn’t require a library to effectively use.

Buffer configuration is what Emacs has modes for, and Smalltalk objects (what else?). In both cases, it's a finite but possibly large list of choices.

You could have Emacs-like modes and have programs specify their mode in an initial message.